CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority from South African provisional patent application numbers 2022/11368 filed on 18 October 2022 and 2023/09624 filed on 16 October 2023, both of which are incorporated by reference herein.

FIELD OF THE INVENTION

This invention relates to a security protocol system and method, including, but not limited to, systems and methods for conducting a transaction on a distributed ledger technology-based infrastructure and for secure communication.

BACKGROUND TO THE INVENTION

There has been an unprecedented growth of identity fraud which threatens the financial landscape, with many fraud attacks targeting mobile transactions. Despite this growing concern, a drive to use a mobile device in conducting transactions continues to increase.

In many cases, the identity of a mobile or other computing device may be confirmed by a central authority. For example, when a first computing device receives a request for a protected resource from a second computing device, a certificate authority may sign a digital certificate with its private key and attach the certificate to a public key belonging to the first computing device. The certificate may be considered verification by the certificate authority that: the first computing device is who it says it is; and the first computing device owns the public key. The second computing device may then verify the certificate by querying a table of pre-installed public keys.

In the model described above, the authenticity of the first computing device is dependent on the authenticity of the certificate, and the certificate's authenticity is dependent on the maintained privacy of the certificate authority's private key, which may be susceptible to hacking and other security breaches. If the certificate authority's private key is compromised, all certificates signed by the certificate authority may also be compromised, representing a large user base. It can also be important to communicate securely with a computing device of an end-user. While techniques for secure communication exist, they often require internet access and/or special adaptors at the institution wishing to communicate with the end-user.

There is accordingly scope for improvement.

The preceding discussion of the background to the invention is intended only to facilitate an understanding of the present invention. It should be appreciated that the discussion is not an acknowledgment or admission that any of the material referred to was part of the common general knowledge in the art as at the priority date of the application.

SUMMARY OF THE INVENTION

In accordance with an aspect of the invention there is provided a method implemented at a first computing device, the method comprising: collecting a number of parameters, wherein at least one parameter is a unique identifier associated with the first computing device; and deriving a first cryptographic key from the collected parameters according to protocol of a distributed ledger technology-based infrastructure.

The first cryptographic key may be derived for use with the distributed ledger-based infrastructure. The first cryptographic key may be derived for use in secure messaging.

The parameters may include a parameter accessible by only the first computing device. The unique identifier may be an IMSI number. The unique identifier may be an ICCID number.

The first cryptographic key may be a first private key. The method may include deriving a first public key from the first private key. The first public key may be configured such that the association between the first public key and the first private key may be verified without ever revealing the first private key.

The first public key may be associated with a store of value. The method may further include, in response to receiving a transaction request, initiating a transfer in favour of a second public key associated with a second computing device. The method may further include, in response to receiving a transaction request, signing a record of the transfer using the first private key. The method may further include, in response to receiving a transaction request, transmitting the signed record to the distributed ledger technology-based infrastructure for verification by at least a third computing device. The method may further include verifying the transaction request. The method may include: receiving a message including an encrypted payload; detecting, by a listening service, the received message; in response to the listening service detecting the received message, obtaining a decrypted payload by decryption of the encrypted payload using the first cryptographic key; storing the decrypted payload in a storage of a secure messaging application; and, outputting, via a user interface, a notification by the secure messaging application.

The message may be an SMS message. The method may include diverting the SMS message from an operating system-provided messaging inbox.

The SMS message may be a class 0 message, and wherein the method includes, in response to the listening service detecting the received SMS message, intercepting the received SMS message and dismissing a class 0 notification associated therewith. Dismissing the class 0 notification may include using operating system-provided accessibility services capabilities. Obtaining the decrypted payload may include decrypting the encrypted payload using the first cryptographic key to output the decrypted payload.

Obtaining the decrypted payload may include: passing the encrypted payload to an encryption service; and, receiving the notification from the encryption service, wherein the notification includes the decrypted payload. The notification may be received from the encryption service via a push notification service, wherein the notification includes an instruction to an operating system to store the SMS message in an operating system-provided junk folder, and wherein the method includes storing the SMS message in the junk folder.

The notification may include a message display in which the decrypted payload is displayed. The notification may include one or both of a first user-input element and a second user-input element, and wherein the method includes: in response to receiving activation of the first user-input element, dismissing the notification; or, in response to receiving activation of the second userinput element, launching the secure messaging application, wherein launching the secure messaging application includes displaying one of: the decrypted payload and a history of previously decrypted payloads including the decrypted payload.

Launching the secure messaging application may include: prompting for end-user credentials; receiving input of the end-user credentials; and, validating the end-user credentials before completing launching of the secure messaging application.

In accordance with a further aspect of the invention there is provided a system including a first computing device, comprising: a processor and a memory configured to provide computer program instructions to the processor to execute functions of components; a collecting component configured to collect a number of parameters, wherein at least one parameter is a unique identifier associated with the first computing device; and a cryptographic key deriving component configured to derive a first cryptographic key from the collected parameters according to protocol of a distributed ledger technology-based infrastructure.

The collecting component may include an accessing component configured to access one or more components of the first computing device. The collecting component may include a retrieving component configured to retrieve at least a unique identifier associated with the computing device from a component of the first computing device. The parameters may include a parameter accessibly by only the first computing device. The unique identifier may be an IMSI number. The unique identifier may be an ICCID number.

The first cryptographic key may be a first private key. The cryptographic key deriving component may be configured to derive a first public key from the first private key, the first public key being configured such that the association between the first public key and the first private key may be verified without ever revealing the first private key.

The first public key may be associated with a store of value. The system may further include a request receiving component configured to receive a transaction request. The system may further include a verifying component configured to verify the transaction request. The system may further include a transfer initiating component configured to initiate a transfer in favour of a second public key associated with a second computing device. The system may further include a signing component configured to sign a record of the transfer using the first private key. The system may further include a transmitting component configured to transmit the signed record to the distributed ledger technology-based infrastructure for verification by at least a third computing device. The system may further include a promulgating component configured to promulgate information to other communication devices within the distributed ledger technology-based infrastructure. The system may further include a connection initiating component configured to initiate a connection with the distributed ledger technology-based infrastructure.

In accordance with a further aspect of the invention there is provided a computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of, at a first computing device: collecting a number of parameters, wherein at least one parameter is a unique identifier associated with the first computing device; and deriving a first cryptographic key from the collected parameters according to protocol of a distributed ledger technology-based infrastructure. Further features provide for the computer-readable medium to be a non-transitory computer- readable medium and for the computer-readable program code to be executable by a processing circuit.

In accordance with a further aspect of the invention there is provided a computer-implemented method conducted at a first computing device comprising: receiving an SMS message including an encrypted payload; detecting, by a listening service, the received SMS message; in response to the listening service detecting the received SMS message, obtaining a decrypted payload by decryption of the encrypted payload using a first cryptographic key; storing the decrypted payload in a storage of a secure messaging application; and, outputting, via a user interface, a notification by the secure messaging application.

The method may include diverting the SMS message from an operating system-provided messaging inbox.

Obtaining the decrypted payload may include: passing the encrypted payload to an encryption service; and, receiving the notification from the encryption service, wherein the notification includes the decrypted payload. The notification may be received from the encryption service via a push notification service. The notification may include an instruction to an operating system to store the SMS message in an operating system-provided junk folder , and the method may include storing the SMS message in the junk folder.

The SMS message may be a class 0 message, and the method may include, in response to the listening service detecting the received SMS message, intercepting the received SMS message and dismissing a class 0 notification associated therewith. Dismissing the class 0 notification may include using operating system-provided accessibility services capabilities. Obtaining the decrypted payload may include decrypting the encrypted payload using the first cryptographic key to output the decrypted payload.

The notification may include a message display in which the decrypted payload is displayed. The notification may include one or both of a first user-input element and a second user-input element, and the method may include: in response to receiving activation of the first user-input element, dismissing the notification; or, in response to receiving activation of the second user-input element, launching the secure messaging application, wherein launching the secure messaging application includes displaying one of: the decrypted payload and a history of previously decrypted payloads including the decrypted payload. Launching the secure messaging application may include: prompting for end-user credentials, such as input of a passcode or biometric; receiving input of the end-user credentials; and, validating the end-user credentials before completing launching of the secure messaging application.

In accordance with another aspect of the invention there is provided a computer-implemented method conducted at an encryption service comprising: receiving, from a second computing device, a payload for encryption and a communication address of a first computing device to which the payload is to be transmitted; checking that the communication address is enrolled for secure communication; responsive to determining that the communication address is enrolled for secure communication, encrypting the payload using a second cryptographic key to generate an encrypted payload, wherein the second cryptographic key is unique to the communication address; and, transmitting an SMS message including the encrypted payload to the first computing device using the communication address.

Checking that the communication address is enrolled for secure communication may include querying an enrolment database for an enrolment record associated with the communication address, and wherein the communication address is determined to be enrolled when an enrolment record exists for the communication address.

The method may include, responsive to determining that the communication address is enrolled for secure communication, retrieving the second cryptographic key from a storage location associated with the communication address.

The method may include, responsive to determining that the communication address is not enrolled for secure communication, transmitting an SMS message to the first computing device using the communication address and including a prompt instructing an end-user of the first computing device to enrol the communication address for secure communication.

The method may include, responsive to determining that the communication address is enrolled for secure communication, determining whether the communication address is associated with a computing device of a first type or a second type. Transmitting the SMS message may include transmitting a type 0 SMS message when the communication address is associated with a computing device of the first type. Transmitting the SMS message may include transmitting a type 1 (standard) SMS message when the communication address is associated with a computing device of the second type. The method may include: receiving the encrypted payload from the first computing device; decrypting the encrypted payload using a first cryptographic key to generate a decrypted payload; and, transmitting a notification including the decrypted payload to the first computing device. Transmitting the notification may include transmitting the notification via a push notification service. The notification may include an instruction to an operating system of the first computing device to store the SMS message in an operating system-provided junk folder.

The method may include: receiving an enrolment request from the first computing device, wherein the enrolment request includes enrolment data elements including one or more of: the communication address; a device identifier which uniquely identifies the first computing device; a first cryptographic key; the second cryptographic key; and, an indication as to whether the first computing device is of a first type or a second type; and, enrolling the communication address, including storing, in an enrolment database, the enrolment data elements in an enrolment record associated with the communication address.

The first cryptographic key and second cryptographic key may be one and the same cryptographic key. The cryptographic key may be a symmetric encryption/decryption key.

In accordance with a further aspect of the invention there is provided a system including a first computing device having a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the system comprising: a messaging component for receiving an SMS message including an encrypted payload; a listening service for detecting the received SMS message; a decryption obtaining component for, in response to the listening service detecting the received SMS message, obtaining a decrypted payload by decryption of the encrypted payload using a first cryptographic key; a storing component for storing the decrypted payload in a storage of a secure messaging application; and, an output component for outputting, via a user interface, a notification by the secure messaging application.

In accordance with a further aspect of the invention there is provided a system including an encryption service having a memory for storing computer-readable program code and a processor for executing the computer-readable program code, the system comprising: a payload receiving component for receiving, from a second computing device, a payload for encryption and a communication address of a first computing device to which the payload is to be transmitted; a checking component for checking that the communication address is enrolled for secure communication; an encrypting component for, responsive to determining that the communication address is enrolled for secure communication, encrypting the payload using a second cryptographic key to generate an encrypted payload, wherein the second cryptographic key is unique to the communication address; and, a transmitting component for transmitting an SMS message including the encrypted payload to the first computing device using the communication address.

In accordance with a further aspect of the invention there is provided a computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: receiving an SMS message including an encrypted payload; detecting, by a listening service, the received SMS message; in response to the listening service detecting the received SMS message, obtaining a decrypted payload by decryption of the encrypted payload using a first cryptographic key; storing the decrypted payload in a storage of a secure messaging application; and, outputting, via a user interface, a notification by the secure messaging application.

In accordance with a further aspect of the invention there is provided a computer program product comprising a computer-readable medium having stored computer-readable program code for performing the steps of: receiving, from a second computing device, a payload for encryption and a communication address of a first computing device to which the payload is to be transmitted; checking that the communication address is enrolled for secure communication; responsive to determining that the communication address is enrolled for secure communication, encrypting the payload using a second cryptographic key to generate an encrypted payload, wherein the second cryptographic key is unique to the communication address; and, transmitting an SMS message including the encrypted payload to the first computing device using the communication address.

Further features provide for the computer-readable medium to be a non-transitory computer- readable medium and for the computer-readable program code to be executable by a processing circuit.

Embodiments of the invention will now be described, by way of example only, with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

Figure 1 is a schematic diagram which illustrates an example system according to aspects of the present disclosure; Figure 2 is a swim-lane flow diagram which illustrates an enrolment process in which a communication address is enrolled for secure communication;

Figure 3 is a swim-lane flow diagram which illustrates a method for secure communication in which a payload is sent from a second computing device to a first computing device;

Figure 4A is a swim-lane flow diagram which illustrates one example implementation for obtaining decryption of an encrypted payload;

Figure 4B is a schematic diagram which illustrates message hashing according to aspects of the present disclosure;

Figure 5 is a swim-lane flow diagram which illustrates a method for secure communication in which a payload is sent from a first computing device to a second computing device;

Figure 6 is a schematic diagram which illustrates an example system for conducting a transaction on a distributed ledger technology-based infrastructure according to aspects of the present disclosure;

Figure 7 is an example visualisation of a cube identifier according to aspects of the present disclosure;

Figure 8 is a flow diagram which illustrates an example method by which a computing device may generate first and/or second cryptographic keys according to aspects of the present disclosure;

Figure 9 is a swim-lane flow diagram which illustrates an example method for conducting a transaction on a distributed ledger technology-based infrastructure according to aspects of the present disclosure;

Figure 10 is a block diagram which illustrates exemplary components which may be provided by a system for conducting a transaction on a distributed ledger technology-based infrastructure according to aspects of the present disclosure; and Figure 11 illustrates an example of a computing device in which various aspects of the disclosure may be implemented.

DETAILED DESCRIPTION WITH REFERENCE TO THE DRAWINGS

Aspects of the present disclosure relate generally to security protocols for transactions and/or communications. Aspects of the present disclosure provide a system and method for generating a cryptographic key for use in secure communication and/or for conducting transactions on a distributed ledger technology-based infrastructure. Further, aspects of the present disclosure provide a system and method for secure communication using a cryptographic key. Furthermore, aspects of the present disclosure provide a system and method for conducting a transaction on a distributed ledger technology-based infrastructure using a cryptographic key.

Figure 1 is a schematic diagram which illustrates an example system (1 ) for secure communication according to aspects of the present disclosure. The system may include a first computing device (3) and a second computing device (5). The system may further include an encryption service (7) and a messaging service (9). The first computing device, second computing device, messaging service and encryption service may communicate with each other (e.g. by sending and receiving messages, data and the like) via a communication network (11), which may include a mobile telephone network, the Internet, and the like.

The first computing device (3) may be an end-user computing device and may have a communication functionality. The first computing device (3) may for example be in the form of a mobile phone or other suitable computing device having a communication functionality (such as a tablet computer, wearable computing device, laptop computer or the like). The first computing device (3) may be associated with a communication address by way of which messages and optionally other communications may be transmitted to the first computing device.

In some embodiments, a secure messaging application (3A) is downloadable onto and executable by the first computing device (3). The secure messaging application (3A) may be operated, maintained and/or provided by the encryption service and/or another entity (such as an entity associated with the second computing device). The secure messaging application may be downloadable from a third-party application repository.

The secure messaging application (3A) together with the encryption service (7) may implement a method for encrypting and decrypting SMS messages (or other such instant messages) to protect the confidentiality and integrity of the communication over the network. The secure messaging application (3A) may implement the Advanced Encryption Standard (AES), optionally with Electronic Codebook (ECB) mode, for encrypting and decrypting payloads included in SMS (or other such) messages. AES is a symmetric encryption algorithm that offers strong security and is widely used for data encryption. One or more predefined values for the cryptographic key (which may be termed the “SECRET KEY”) may be used in the AES/ECB encryption and decryption. To further enhance security, The secure messaging application may generate unique salts using a combination of identifiers or “parameters”, including one or more of: a Bluetooth Address (or any other suitable unique identifier associated with the Bluetooth adapter of the device); a WLAN MAC Address (or any other unique identifier associated with the wireless network interface of the device); a DeviceJD or derivative thereof (such the DeviceJD having the order of one or more groupings or parts of symbols thereof reversed or otherwise altered); an “identifierForVendor” (IDFV) value (or other suitable, unique identifier issued to a vendor (application developer) of the secure messaging application specifically for an end-user of the first computing device); SIM card information (such as one or more of: IMEI, ICCID, IMSI and the like); etc. The DeviceJD may be a unique identifier generated by the operating system of the computing device during setup. The IDFV value may be an alphanumeric string that uniquely identifies a device to the app’s vendor. The IDFV may be the same across apps from a specific company for a specific end-user and it may persist across uninstalls/installs of the secure messaging application. Some operating systems may not allow applications to access the DeviceJD, in which case the IDFV value may be used as the DeviceJD. In some embodiments, the secure messaging application combines these hardware-specific identifiers to generate a unique value (which may be termed a “salt”), which is unique and difficult for attackers to guess or brute-force. This unique value may be used in generating the first and/or second cryptographic keys. For example in some embodiments, a cryptographic token is generated by hashing the unique value (being a combination or concatenation of one or more of the above identifiers or parameters). The cryptographic token may be a SHA256 hash derived from the unique salt. SHA256 is a secure cryptographic hash function that produces a fixed-length output (256 bits). By hashing the unique salt, the secure messaging application may ensure that the cryptographic token is resistant to preimage attacks, making it difficult for an attacker to reverse-engineer the original salt or hardware identifiers. One or both of the DeviceJD and the cryptographic token may be used as unique identifiers for the first computing device. In some implementations, the first and/or second cryptographic key are generated using the cryptographic token. In some embodiments, the first and second cryptographic keys are one and the same as the cryptographic token. These values may be sent from the secure messaging application to the backend (or encryption service) via an sms/enrol API call or other suitable mechanisms. The secure messaging application may therefore use AES/ECB encryption for protecting SMS messages and may generate unique salts from a combination of hardware identifiers. A cryptographic token in the form of a SHA256 hash of the unique salt may be generated, providing additional security.

The secure messaging application may be configured, upon startup, to request the necessary permissions to intercept incoming SMS messages and access unique identifiers on the device, such as one or more of: the DeviceJD, Bluetooth Address, WLAN MAC Address, IDFV, SIM identifiers, etc. The secure messaging application may be configured to prompt the user to enter a communication address (such as a phone number of the first computing device) during the initial setup. The secure messaging application may be configured to generate one or more of: a cryptographic token, unique device ID; first cryptographic key; and, second cryptographic key, and may use this information together with the communication address to enrol the device and/or communication address using a suitable API call to the encryption service, for example. The secure messaging application may include a background service that starts listening for SMSs automatically after initial setup. The secure messaging application may be configured, upon receiving an encrypted SMS, to use operating system-based message filtering capabilities to initiate a call to the encryption service using a suitable API endpoint. In some cases, the secure messaging application may detect receipt of an encrypted Class 0 SMS, and may be configured to intercept the message, decrypt it on the device, and then make use of operating system-based accessibility service capabilities to dismiss the Class 0 notification.

The secure messaging application may be configured to store decrypted payloads in a local database implemented on the device. In some implementations, for example, each SMS body will be saved with a unique ID, allowing easy retrieval using a helper class. The following operating system technical APIs, components, services, classes etc. may be utilised. Core Data, an iOS framework for managing object graphs and persisting data to local storage, may be employed to create and manage the local database in the case of an iOS-based device. Shared Preferences, a key-value-based database provided by the Android operating system may be used for such devices. The SMS database schema may include a single table named “sms” with the following columns: id, a unique identifier for each SMS message; and, “messageBody” which stores the decrypted payload; and, “timestamp”, which may be the time in milliseconds since 1 Jan 1970, formatted into a human-readable date upon display of the message. A helper class named “SmsManager” may be implemented to facilitate interactions with the local database. The class may include the following methods: saveSMS(uniquelD: String, smsBody: String), which saves a decrypted SMS message with a unique ID to the local database; fetchAIISMS(), which retrieves all SMS messages stored in the local database; and, fetchSMS(uniquelD: String), which retrieves a specific SMS message using its unique ID. The secure messaging application may be provided with a public key (which may be termed an enrolment public key) corresponding to a private key (which may be termed an enrolment private key) securely stored at the encryption service (or enrolment server). The enrolment public key may be stored in and/or accessible to the secure messaging application for use, for example, in encrypting an enrolment request.

The background listening service (3B) may execute on the first computing device (3) and may be configured to monitor or listen for incoming SMS messages. The listening service may be configured to detect predefined signals or flags in SMS messages and to instantiate the secure messaging application in response to detecting SMS messages with such signals or flags.

The second computing device (5) may be in the form of a server computer, server computer cluster, cloud-based server computer or the like. The second computing device (5) may be associated with (e.g. under the control of) an entity, such as a bank or the like.

The messaging service (9) may be provided by an SMSC of an MNO, an SMS aggregator, or the like. The messaging service (9) may be used by the second computing device (5) to send and receive messages to and from the first computing device (3) via a communication network (11) (e.g. including a mobile telephone network). The messaging service (9) and second computing device (5) may exchange messages, data (including payloads) and the like via a secure communication channel (e.g. using SSL or the like).

The encryption service (7) may include one or both of an enrolment server (13) and an encryption server (15). The enrolment server (13) may be configured to enrol the first computing device (3) and/or associated communication address for secure communication with the second computing device (5). The enrolment server may have access to and/or maintain an enrolment database (15A) in which an enrolment record including enrolment data elements associated with a communication address is stored when the communication address is enrolled for secure communication. The encryption server may be configured to encrypt and decrypt messages sent between the first and second computing devices when the communication address is enrolled for secure communication. The encryption service (7) may be used by the messaging service (9) to encrypt and decrypt messages being sent between the first and second computing devices when the communication address is enrolled for secure communication. In some embodiments, the encryption service forms a part of (e.g. is built into or integrated with) the messaging service.

The encryption service (7) may provide the backend required to encrypt and/or decrypt an SMS message. The encryption service (7) may use AES optionally with ECB mode to encrypt and/or decrypt payloads sent or received via SMS messages. The backend may be configured to receive a message (or set of message data elements) and a communication address (such as a phone number), encrypt the message and transmit it to a computing device associated with the communication address if the communication address has been enrolled for secure communication. The backend may use SQLite as a database in which “sms” and “enrolment” tables may be maintained. The backend may handle incoming requests from the devices, such as sms/enrol API requests. An enrol request may include hardware identifiers unique to the device, such as one or more of a cryptographic token, Device ID, first and/or second cryptographic key and the communication address. The backend may also consume an API exclusive to iOS for handling sms/ios-received requests, for example including requests which may be sent from a computing device running the iOS operating system device when an encrypted payload has been intercepted. The API may be configured to transmit a push notification back to computing devices, with the decrypted message contents.

In some circumstances, the backend may handle the sanitising of the encrypted message and may send back a decrypted message via a push notification (e.g. using APNS, Apple Push Notification Service or other such service) to the secure messaging application. The push notification or another response sent to the secure messaging application may also instruct the operating system on the device: not to show a notification of the raw, encrypted SMS; and, to place it in the junk folder on the system Messages application, a custom filtered list of messages that is obscured from the user.

In this manner, the system described above may implement secure communication between a first computing device associated with an end-user and a second computing device associated with an entity. By providing an encryption service (7), optionally integrated into a messaging service (9), and a secure messaging application (3A) executing on a first computing device, encrypted payloads may be sent and received via SMS messages, which may alleviate integration burden on the entity wishing to send and receive secure communications. In other words, entities with existing integrations into messaging services would not need to implement any integration changes in order to start sending and receiving encrypted communications.

It should be appreciated that while only one of each of the first and second computing devices is described herein, it should be appreciated that in a practical implementation there may be a plurality of each of these.

The system described above may implement a method for secure communication. Figures 2 to 5 are swim-lane flow diagrams which illustrate various stages or parts of a method for secure communication in accordance with embodiments of the present disclosure.

Figure 2 illustrates an enrolment process in which the communication address is enrolled for secure communication.

The method may include the first computing device (3) downloading and installing (31 ) a secure messaging application (3A). The secure messaging application may be downloaded from a third- party application repository. The first computing device (3) may launch the secure messaging application, which may in turn obtain (33) a communication address for the first computing device (3). The communication address may for example be a phone number, such as an MSISDN. Obtaining the communication address may include prompting an end-user for the communication address and receiving the communication address as user-input via a user interface. In other embodiments, the secure messaging application may obtain the communication address from the first computing device.

The secure messaging application may generate (35) one or more of: a device identifier which uniquely identifies the first computing device; a cryptographic token; a first cryptographic key; and a second cryptographic key. In some embodiments, the secure messaging application may generate a device identifier and may use the device identifier to generate the first cryptographic key, for example by inputting the device identifier into an algorithm that generates a symmetric encryption/decryption key. Each of the algorithm that generates the device identifier and the algorithm that generates the symmetric encryption/decryption key may be configured to reliably generate the same output for the same input, such that the same symmetric encryption/decryption key is generated for the same device identifier that is input. This may allow for a storage-free implementation in which the device identifier and/or first cryptographic key are not permanently stored on the first computing device and are, instead, generated on-demand by collecting parameters from the device as described herein.

The secure messaging application may generate and transmit (37) an enrolment request to an encryption service (7). This may include transmitting the enrolment request to an enrolment server (13) of the encryption service (7). The enrolment request may include enrolment data elements including one or more of: the communication address; the device identifier; the cryptographic token; the first cryptographic key; the second cryptographic key; and, an indication as to whether the first computing device is of a first type or a second type. In some embodiments the first cryptographic key is a symmetric encryption/decryption key, and the enrolment request includes a copy of the first cryptographic key for storage at the enrolment server (or in an HSM accessible thereto) as the second cryptographic key. In other embodiments, the first cryptographic key is a private key, the second cryptographic key is a public key, and the enrolment request includes a copy of the public key for storage at the enrolment server (or in an HSM accessible thereto) as the second cryptographic key. The type indications may indicate the type of operating system executing on the first computing device. A first type indicator may for example correspond to computing devices executing the Android™ operating system while a second type indicator may for example correspond to computing devices executing the iOS™ operating system.

Generating the enrolment request may include encrypting the enrolment data elements to generate an encrypted enrolment payload. The encryption may use a public key (e.g. the enrolment public key) corresponding to a private key (e.g. the enrolment private key) securely stored at and accessible only to the enrolment server. Transmitting the enrolment request may include transmitting the encrypted enrolment payload in an SMS message. The SMS message may be sent to the enrolment server of the encryption service (7) via a messaging service (9).

The encryption service (7) may receive (39) the enrolment request from the first computing device. This may include the enrolment server receiving the SMS message including the encrypted enrolment payload from the first computing device (3). In some cases, the enrolment server receives the encrypted payload from the messaging service. The enrolment server may decrypt the encrypted enrolment payload to obtain the enrolment data elements. This may include using the private key of the enrolment server.

The encryption service may enrol (41 ) the communication address for secure communication. This may include the enrolment server storing in an enrolment database (15A) the enrolment data elements in an enrolment record associated with the communication address. In some embodiments, this may include securely storing one or more of the device identifier; the cryptographic token; the first cryptographic key; the second cryptographic key in a secure storage location accessible to the enrolment server, such as a hardware security module (HSM). Because one or more of the device identifier; the cryptographic token; the first cryptographic key; and the second cryptographic key are uniquely associated with the first computing device (i.e. by virtue of being generated based on hardware or related identifiers of the first computing device), enrolling the communication address for secure communication may include enrolling the first computing device for secure communication using the communication address.

The encryption service may transmit an enrolment confirmation to the first computing device using the communication address. This may include transmitting the enrolment confirmation. In some embodiments, the enrolment confirmation is sent using the secure messaging techniques described herein (e.g. with reference to Figure 3). The first computing device receives the enrolment confirmation and outputs it to the end-user to confirm enrolment.

Once the communication address has been enrolled for secure communication, the first computing device and encryption service can exchange secure communications over an otherwise in-the-clear communication channel (being SMS or other such messaging). The encryption service may for example be accessible to a second computing device associated with an entity, such as a financial institution, wishing to communicate securely with the end-user via the communication address and/or first computing device.

Referring now to Figure 3, the second computing device (5) may for example transmit (47) to a messaging service (9) a payload including the communication address and a set of message data elements for transmitting to the first computing device using the communication address. The messaging service may receive and in turn forward (49) the payload to the encryption service (7). Receiving the payload may include receiving the payload in the clear (i.e. in unencrypted form), although communication between the second computing device and the messaging service may be secured (e.g., using SSL). Receiving the payload may include receiving the payload with no logging. The encryption service (7), and in some embodiments, an encryption server (15) of the encryption service, may receive (51 ) the payload and in response may check (53) that the communication address is enrolled for secure communication. Checking that the communication address is enrolled for secure communication may include querying an enrolment database for an enrolment record associated with the communication address. The communication address may be determined to be enrolled when an enrolment record exists for the communication address. If no enrolment record exists for the communication address, the address may be determined not to be enrolled for secure communication.

The encryption service may, responsive to determining that the communication address is not enrolled for secure communication, transmit an SMS message to the first computing device using the communication address and including a prompt instructing an end-user of the first computing device to enrol the communication address for secure communication. The message may be sent using the messaging service.

Alternatively, the encryption service may, responsive to determining (55) that the communication address is enrolled for secure communication, retrieve (57) the second cryptographic key from a storage location associated with the communication address. This may include retrieving the second cryptographic key from the enrolment database and/or from an HSM. The second cryptographic key may be unique to the communication address and/or the first computing device. The encryption service may determine (59) a type indicator for the communication address, for example including determining whether the communication address is associated with a computing device of a first type or a second type. This may include retrieving the type identifier stored in the enrolment record associated with the communication address.

The encryption service (7) may encrypt (61 ) the payload using the second cryptographic key to generate an encrypted payload. The second cryptographic key may be a symmetric encryption/decryption key and encrypting the payload may include using AES optionally with ECB mode. Encryption of the payload may be performed by the encryption server.

The encryption service may transmit (63) an SMS message including the encrypted payload to the first computing device (3) using the communication address. In some embodiments, transmitting the SMS message may include transmitting a type 0 SMS message when the communication address is associated with a computing device of the first type. Transmitting the SMS message may include transmitting a type 1 (i.e. a standard) SMS message when the communication address is associated with a computing device of the second type. Transmitting the SMS message may include the encryption service (7) using the messaging service (9) to transmit the SMS message to the first computing device using the communication address.

The first computing device (3) may receive (71) the SMS message including the encrypted payload. A listening service executing on the first computing device may detect the received SMS. For example, the SMS message may include a flag or signal which is detectable by the listening service.

As mentioned, in some cases (e.g. where the first computing device is a first type of device), the SMS message may be a class 0 message, in which case the method may include, in response to the listening service detecting the received SMS message, intercepting the received SMS message and dismissing a class 0 notification associated therewith. Dismissing the class 0 notification may include using operating system-provided accessibility services capabilities to dismiss the notification. By following this approach, the encrypted SMS is never stored in the operating system’s message inbox.

In response to the listening service detecting the received SMS message, the first computing device (3), or the secure messaging application (3A) executing thereon, may obtain (73) a decrypted payload by decryption of the encrypted payload using a first cryptographic key. This may include generating the first cryptographic key before obtaining decryption. The first cryptographic key may correspond to the second cryptographic key used to encrypt the encrypted payload. In some embodiments, for example, the first and second cryptographic keys are one and the same (i.e. identical) symmetric encryption/decryption key. In other embodiments, the first cryptographic key is a private key and the second cryptographic key is a public key derived from and/or corresponding to the public key. In some embodiments, the secure messaging application may validate a message hash stored in the secure messaging inbox.

The secure messaging application may for example validate a most recently stored message hash. A most recently stored message hash may for example have been generated by inputting a previous, most recently received, decrypted payload and a previous message hash. Validating the message hash may include regenerating the most recently stored message hash using the previous, most recently received, decrypted payload and a previous message hash and comparing the output to the most recently stored message hash stored in the inbox. In such embodiments, the secure messaging application may obtain the decrypted payload when the message hash is successfully validated (i.e. when the re-generated message hash is the same as the stored message hash. Otherwise, the secure messaging application may report an error or abort the method.

In this manner, the first communication device or secure messaging application creates a message hash of a payload combined with a previous message hash for the same MSISDN. The first communication device or secure messaging application may then validate the message hash before committing (or storing) a new payload. The first communication device or secure messaging application may then create a new message hash using the previous message hash and the new payload. This process may ensure that a miscreant cannot create new message rows without having previous messages stored on device. This means that if a spurious (or cloned) device is created without the message history, then new messages cannot be decrypted and stored. Message hash validation may thus form part of identification and authentication of the first computing device.

In some embodiments, for example in cases where the first computing device is a second type of device, and referring now to Figure 4A, obtaining the decrypted payload may include passing (75) (e.g. transmitting) the encrypted payload to the encryption service. This may include the secure messaging application obtaining the encrypted payload from the SMS message and transmitting the encrypted payload to the encryption service (or the encryption server). The encryption service (or encryption server) may receive (77) the encrypted payload from the first computing device; decrypt (79) the encrypted payload using the first cryptographic key (or the second cryptographic key in implementations where the first and second keys are the same symmetric key) to generate the decrypted payload; and, transmit (81) a notification including the decrypted payload to the first computing device. Transmitting the notification may include transmitting the notification via or using a push notification service (such as the Apple Push Notification Service, APNS). The notification may thus be a push notification. The notification may include an instruction to an operating system of the first computing device to store the SMS message in an operating system- provided junk folder. The first computing device (3) may receive (83) the notification including the decrypted payload from the encryption service. The notification may include an instruction to an operating system to store the SMS message in an operating system-provided junk folder, and the first computing device may store (85) the SMS message in the junk folder.

The method may therefore include diverting the SMS message from an operating system- provided messaging inbox, either by using a type 0 SMS message or by instructing the operating system to store the SMS message in a junk folder instead.

In some cases (e.g., in cases where the first computing device is of the first type), obtaining (73) the decrypted payload may include the first computing device (or the secure messaging application) decrypting the encrypted payload using the first cryptographic key to output the decrypted payload. This may include retrieving the first cryptographic key from a storage location accessible only to the secure messaging application. In some embodiments, the method does not distinguish between types of devices. For example, in some implementations, the steps described above with reference to Figure 4A are implemented for all device types. In other implementations, the payload is decrypted locally at the device for all device types.

Either way, and returning now to Figure 3, the first computing device (or secure messaging application) may store (87) the decrypted payload in a storage of a secure messaging application. The storage may be a secure messaging inbox in which payloads sent to and from the first communication device are stored. In some embodiments, referring now to Figure 4B, storing the decrypted payload includes inputting the decrypted payload and a message hash stored in association with a previously decrypted payload into a hash algorithm to obtain an updated message hash. The updated message hash may be stored in association with the decrypted payload. In this way, each decrypted payload is associated with a message hash based on a previous decrypted payload and previous message hash to effectively chain the messages together. The chain of message hashes may begin with the enrolment request (900) which is hashed to produce a first message hash (902). When an enrolment confirmation (904) is received, the first message hash (902) together with the enrolment confirmation (904) may be input into the hash algorithm to output a second message hash (906). Thereafter, a payload (908) (either obtained from decrypting an encrypted payload or having been input for encrypting and sending) together with the second message hash (906) are input into the hash algorithm to output a next message hash (910). This repeats for each new payload such that each payload is stored in association with a message hash based on the payload and a previous hash. By validating the message hash before obtaining decryption of a decrypted payload, security threats (e.g. relating to spoofed identifiers) can be detected. In other words, only when the first computing device has the complete and valid history is the decryption of encrypted payloads possible.

Returning to Figure 3, the first computing device (or secure messaging application) may output (89) a notification via a user interface thereof. The notification may be the notification (e.g. the push notification) received via the push notification service or may be generated and output by the secure messaging application.

The notification may include a message display in which the decrypted payload is displayed in a human readable format for the end-user. The notification may include one or both of a first userinput element (which may be labelled “acknowledge”, “read” etc.) and a second user-input element (which may be labelled “view history”, “launch application” etc.). The first computing device may, in response to receiving activation of the first user-input element, dismiss the notification; or, in response to receiving activation of the second user-input element, launch the secure messaging application. Launching the secure messaging application may include displaying the decrypted payload and/or a history of previously decrypted payloads including the decrypted payload. Launching the secure messaging application may include: prompting for enduser credentials, such as input of a passcode or biometric; receiving input of the end-user credentials; and, validating the end-user credentials before completing launching of the secure messaging application.

Referring now to Figure 5, sending a secure message from the first computing device (3) to the second computing device (5) may include the first computing device (or secure messaging application) receiving (91) a communication address associated with the second computing device and a set of message data elements for transmitting to the second computing device using the communication address. The communication address and data elements may be input into the secure messaging application by an end-user or may be received from another application executing on the computing device via an inter-application messaging protocol and/or an API.

The first computing device (3) (or secure messaging application) may compile the message data elements into a payload and encrypt (93) the payload using the first cryptographic key to generate an encrypted payload. This may include first generating the first cryptographic key before obtaining encryption. In some cases, once the payload has been compiled, the secure messaging application may store the payload in a secure messaging inbox in association with a message hash generated by inputting the payload and a previous message hash into a hashing algorithm to generate a message hash for the payload. The first computing device (3) may transmit (94) the encrypted payload to the second computing device in an SMS message using the communication address. This may include the secure messaging application using an operating system provided messaging application to transmit an SMS message including the encrypted payload. The SMS message may be transmitted to the second computing device via a messaging service.

The messaging service (9) may receive the SMS including the encrypted payload and may forward (95) the encrypted payload to the encryption service (7). Forwarding the encrypted payload may include forwarding the communication address of the first computing device from which the SMS message is received. The encryption service (7) may receive the encrypted payload and communication address and decrypt (96) the encrypted payload using the second cryptographic key to generate a decrypted payload. This may include retrieving the second cryptographic key from a storage location associated with the communication address. Retrieving the key may include retrieving the second cryptographic key from the enrolment database and/or from the HSM. The encryption service (7) may transmit (97) the decrypted payload to the messaging service (9) which may receive and forward (98) the decrypted payload to the second computing device (5). Forwarding the decrypted payload may include forwarding the decrypted payload in the clear, although communication between the second computing device and the messaging service may be secured (e.g., using SSL or the like). The second computing device (5) may receive (99) the decrypted payload from the messaging service. The second computing device may in response transmit a response message, which may be encrypted (e.g. using the method described above with reference to Figure 3).

As mentioned, aspects of the present disclosure further relate to a system and method for conducting a transaction on a distributed ledger technology-based infrastructure. Aspects of the present disclosure relate to the generation and use of a private key within a distributed ledger technology-based infrastructure, particularly the generation and use of a private key derived at least in part from a unique identifier associated with a computing device.

The distributed ledger technology-based infrastructure as referred to herein may be in the form of a blockchain infrastructure or the like.

In cryptocurrencies and other distributed ledger technology-based infrastructure, a private key allows a user to gain access to their wallet. Typically, the person who holds the private key fully controls the coins in that wallet. According to aspects of the present disclosure, a computing device may collect a number of parameters, wherein at least one parameter is a unique identifier associated with the computing device. The computing device may derive a private key from the collected parameters. The private key may for example be used to derive or generate a public key for use with a distributed ledger technology-based infrastructure; to sign or authorise transactions; and/or the like.

As seen in Figure 6, an example system (100) for implementing a method may include a number of computing devices (102A-102D) connected via a network (103). The network (103) may be any suitable network, such as the Internet. The computing devices (102A-102D) may be any suitable computing devices having, among other components, a processor, memory and at least one unique identifier with which the respective computing device is associated.

Example computing devices include communication devices such as a mobile handset, tablet, smartphone, personal computer or the like, as well as a server, collection of servers or the like. It should be appreciated that the computing devices (102A-102D) connected via the network (103) need not be of the same type. There may for example be mobile handsets and servers both present in the system (100). It should further be appreciated that computing devices may all be communication devices such as mobile handsets or the like. In some embodiments, one or more of the computing devices has a security protocol application installed and/or executing thereon. The security protocol application may for example include one or both of a secure messaging module and a secure transacting module. In other embodiments, one or more of the computing devices has one or both of a secure messaging application and a secure transacting application installed and/or executing thereon, respectively.

The computing devices (102A-102D) are assumed to be operated by entities (104A-104D), or users of the devices. In Figure 6, four computing devices, each with its own user, are illustrated, though it should be appreciated that there may be any number of computing devices and users. Multiple computing devices (102A-102D) may form part of a chain (with the knowledge of the associated user or without). For example, a cube chain using thousands or more computing devices that is the entire distributed ledger is envisioned as an embodiment of the disclosure.

The computing devices (102A-102D) may collectively implement a distributed ledger technologybased infrastructure. The distributed ledger technology-based infrastructure may, for example in the case of a blockchain infrastructure, be comprised of "blocks" or "cubes" of information "chained" together through application of a hashing algorithm to each block, wherein each block contains data and the hash (or cryptographic string) of the previous block. The data and previous hash comprising the block may be hashed, producing a new hash, which may form part of the information of the next block. The hashing algorithms may be configured such that the same data always results in the same hash and any change in the data will result in a different hash; this may preserve both the order of the blocks and the data comprising the block.

The blocks of information comprising the blockchain may include records of transactions between entities, with each entity represented on the blockchain as a string indicating the entity's "wallet address" (which may also be the entity's "public key"). That is, the public key may be associated with or used to identify a store of value or a representation of a store of value, such as a digital wallet. According to aspects of the present disclosure, the wallet address may be associated with a specific computing device such that any transaction from the wallet address must be initiated by the associated computing device. Association of the computing device with the wallet address may be through the use of a private key derived at least in part from a unique identifier associated with the computing device.

In order to derive the private key, the computing device may collect one or more parameters from components thereof. The collected parameters may be parameters unique to the computing device, such as unique identifiers of one or more components thereof, and may be stored in or accessible from one or more components thereof. The collected parameters may for example include one or more of: a Bluetooth™ address (which may for example be a static address, such as a 48-bit randomly generated address stored within and identifying a Bluetooth radio of the computing device), an identifierForVendor (IDFV, being an alphanumeric string that uniquely identifies a device to the vendor of an application), a wireless Local Area Network (WLAN) address stored within and identifying a WLAN radio of the computing device, a WLAN media access control (MAC) address uniquely associated with a WLAN radio of the computing device, a Device ID (e.g. being a unique identifier generated by an operating system of the device), an I MEI , an international mobile subscriber identity ( IMS I) number stored within a subscriber identity module (SIM) card of the computing device, an integrated circuit card identification (ICCID) number of the SIM card, a random number, or the like. At least one parameter may be stored within (and thus only accessible to) the computing device. The at least one parameter may be a unique identifier associated with the computing device. It should be appreciated that there may be other parameters collectable by the computing device and the ones mentioned are only exemplary. The collection of parameters or identifiers may be a list, matrix, array or the like, or the parameters or identifiers may be visualised each as a surface of a cube or a hypercube. An exemplary visualisation of the parameters (202) as a cube (200) can be seen in Figure 7.

Returning to Figure 6, each computing device (102A-102D) may maintain a copy of the distributed ledger in memory and may verify the addition of new blocks to the chain. In the case of a blockchain, verifying the addition of a new block to the blockchain may include verifying a specialised digital signature derived from the private key, the signature being attached to a transaction within a block, or attached to a block.

Computing devices may also "mine" or add blocks to the chain by computing complex algorithms (also known as the "proof of work").

The network (103) may be the means by which distributed ledger-related information is transmitted and received between and among computing devices (102A-102D).

Figure 8 illustrates an example method by which a computing device may generate a first cryptographic key according to aspects of the present disclosure. In some embodiments, this may include setting up a first cryptographic key in the form of a private key or a wallet address to be used with the distributed ledger technology-based infrastructure. In some embodiments, generating the first cryptographic key may include generating a private key for use in secure communication systems and methods described herein. The method may execute on the computing device. In some embodiments, the method may execute in a secure environment provided by the computing device and/or an application executing on the computing device. The secure environment may be resistant to external access.

In some embodiments, the computing device may initiate (302) a connection to the network of computing devices which maintain the distributed ledger. Initiating a connection may be in response to the user requesting an account.

The computing device may then collect (304) required parameter(s). Collecting the parameters may include accessing (306) memory or other components of the computing device and retrieving the parameters therefrom. The components may be internal to the computing device or they may be external components associated with the computing device, such as memory located on a subscriber identity module (SIM) card. Collecting parameters may further include retrieving (308) one or more unique identifiers associated with the computing device, such as one or more of the parameters described in the foregoing.

The computing device may then derive (310) the first cryptographic key from the collected parameters. This may include generating a private key based on or using the parameters. For example, the parameters may be input into a process which generates and outputs a first cryptographic key based on or using the parameters. The process may be a key generation process, a hashing process or the like. For example, the computing device may hash a collection of the parameters to output a first cryptographic key in the form of a hash of the collection of parameters. Example hash algorithms include SHA-256. The first cryptographic key may be derived according to protocol of the distributed ledger technology-based infrastructure. For example, the protocol may define a length of the key in terms of the number of bits or bytes; a maximum value of the key (e.g. so as to fall within a predefined curve order); and the like. For example, in one implementation, the first cryptographic key may be required to be 32 bytes; may be required to be positive; and, may be required to exceed the value: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD036 4141 . Other protocols may have other requirements.

Since the resulting first cryptographic key may be derived from the collection of parameters which may be visualized each as a surface of a cube or a hypercube, the first cryptographic key may therefore also be termed “a cube ID.” The cube ID may function as a private key which is uniquely associated with the computing device.

In some embodiments (e.g., when the first cryptographic key is a private key), the computing device may further derive (312) a corresponding second cryptographic key based on the first cryptographic key. Deriving the second cryptographic key based on the first cryptographic key may include generating the second cryptographic key using the first cryptographic key. In some embodiments, generating the second cryptographic key may include using Elliptic Curve Digital Signature Algorithm (ECDSA). Some implementations may for example use a particular curve called secp256k1 while other implementations may use other curves.

In some implementations, the second cryptographic key may be derived from the first cryptographic key such that the association between the second cryptographic key and the first cryptographic key may be verified without ever having knowledge of the first cryptographic key, for example by using the second cryptographic key to decrypt a challenge or other information having been encrypted using the first cryptographic key. The computing device may then, in some implementations, promulgate (314) the derived second cryptographic key (which in some implementations may represent a wallet address) to all the computing devices maintaining the distributed ledger. The computing device may then use the first cryptographic key to initiate transactions to be recorded on the distributed ledger. The computing device may also begin to maintain the distributed ledger. In some implementations, once the second cryptographic key has been derived, the method may include deleting from memory any temporary storage of the first cryptographic key. In other implementations, the first cryptographic key may be securely stored for use in encrypting/decrypting operations. Figure 9 illustrates an example method by which a computing device (102C) may initiate a transaction which results in the transfer of a value from its (102C) wallet address to a different wallet address. The method may execute on the computing device. In some embodiments, the method may execute in a secure environment provided by the computing device and/or an application executing on the computing device.

The computing device (102C) may receive (402) a transaction request. The request may be in response to a user requesting a transaction using the communication device.

In some embodiments, the request may be received from another computing device which has been previously authorised or designated as being within "a circle of trust" of the computing device. In embodiments where the request is received from another computing device, the receiving computing device (102C) may first verify if the sending computing device is within the circle of trust before proceeding. Verification may include querying a list, table, database or the like which includes the public keys of computing devices within the circle of trust. Verifying may include verifying the transaction request (which may have been signed with the private key of the sending computing device) using a public key from the database.

In response to receiving a valid transaction request, the computing device (102C) may set up or initiate (403) a transaction to be recorded on the distributed ledger. Initiating a transaction may include providing data required for a transaction, such as an amount, a wallet address of the recipient and the like. The computing device may also collect (404) parameters from its (102C) associated memory. At least one parameter may be known only to the computing device (102C). The at least one parameter may be a unique identifier associated with the computing device. The computing device (102C) may derive (406) a private key from the collected parameters. Collecting the parameters and deriving the private key may be implemented as per the method described above with reference to Figure 8.

The computing device (102C) may then sign (408) the transaction with the private key. If the computing device (102C) initiating the transaction is the same computing device that first generated the cube ID, the newly-generated private key will be identical to the cube ID associated with the wallet address from which the transaction is to be initiated, and therefore the transaction will effectively be signed with the cube ID associated with the wallet address. The computing device (102C) may then promulgate (410) the signed transaction to the other computing devices (102A, 102B) which maintain the distributed ledger. Once the signed transaction has been promulgated, the computing device may delete from memory any temporary storage of the private key. A number of other computing devices (102A, 102B) may then, in a blockchain-based implementation, "mine" for a potential block by which the transaction may be added to the blockchain and verify (412A, 412B) the transaction signature using the wallet address (which is also the public key). Since the public key was derived from the cube ID (or private key) such that the association between the public key and the private key may be verified without ever having knowledge of the private key, the computing devices (102A, 102B) may verify (412A, 412B) the transaction was initiated by the same computing device associated with the wallet. If the transaction is verified by a threshold number of computing devices, the computing devices may accept the additional block to their copy of the blockchain, immutably committing the transaction to the blockchain.

Various components may be provided for implementing the methods described above with reference to Figures 2 to 5 and 8 to 9. Figure 10 is a block diagram which illustrates exemplary components which may be provided by a security protocol system according to aspects of the present disclosure. The system may include a first computing device (3) and an encryption service (7).

The first computing device (3) may include a processor (502) for executing the functions of components described below, which may be provided by hardware or by software units executing on the computing device. The software units may be stored in a memory component (504) and instructions may be provided to the processor (502) to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the first computing device (3) may be provided remotely. Some or all of the components may be provided by a security protocol application (505) including a secure messaging module (505A) and a secure transacting module (505B). In other implementations, the different components are provided by separate applications, for example including a secure messaging application and a secure transacting application respectively. The application(s) may be downloadable onto and executable on the first computing device (3).

The computing device (3) may include a collecting component (506) arranged to collect a number of parameters. At least one parameter may be a unique identifier associated with the computing device.

The collecting component (506) may include an accessing component (507) arranged to access one or more components of the first computing device. Accessing the one or more components may include accessing memory internal to the computing device (3) or external from but associated with the computing device (3), such as memory located on a subscriber identity module (SIM) card.

The collecting component (506) may include a retrieving component (508) arranged to retrieve at least the unique identifier associated with the computing device (3).

The computing device (3) may further include a cryptographic key deriving component (509) arranged to derive a cryptographic key (which in some embodiments may be a private key) from the collected parameters. Deriving may be according to protocol of a distributed ledger technology-based infrastructure. The derived private key may be for use with the distributed ledger technology-based infrastructure. The cryptographic key deriving component (509) may be arranged to derive a public key from the private key. The public key may be configured such that the association between the first public key and the first private key may be verified without ever having knowledge of the first private key.

The computing device (3) may further include a request receiving component (512) arranged to receive a transaction request. The computing device (3) may further include a transfer initiating component (514) arranged to initiate a transfer in favour of a second public key associated with a second computing device. The computing device (3) may further include a signing component (516) arranged to sign a record of the transfer with the private key. The computing device (3) may further include a record transmitting component (518) arranged to transmit the signed record to the distributed ledger technology-based infrastructure for verification by at least a third computing device. The computing device (3) may further include a verifying component (520) arranged to verify the transaction request. The computing device (3) may further include a promulgating component (522) arranged to promulgate information to other communication devices within the distributed ledger technology-based infrastructure. The computing device (3) may further include a connection initiating component (524) arranged to initiate a connection with the distributed ledger technology-based infrastructure.

The computing device (3) may include a messaging component (556) configured to transmit and receive SMS messages including encrypted payloads. The messaging component may be provided by an operating system of the first computing device. The computing device (3) may include a listening service (3B) arranged to detect received SMS messages. The computing device (3) may include a decryption obtaining component (558) arranged to obtain a decrypted payload by decryption of the encrypted payload using a first cryptographic key. The decryption obtaining component (558) may be configured to obtain decryption in response to the listening service detecting the received SMS message. The computing device (3) may include a storing component (560) arranged to store the decrypted payload in a storage of or accessible to secure messaging application. The computing device (3) may include an output component (562) arranged to output a notification via a user interface of the first computing device.

The encryption service (7) may include a processor (572) for executing the functions of components described below, which may be provided by hardware or by software units executing on the encryption service (7). The software units may be stored in a memory component (574) and instructions may be provided to the processor (572) to carry out the functionality of the described components. In some cases, for example in a cloud computing implementation, software units arranged to manage and/or process data on behalf of the encryption service (7) may be provided remotely.

The encryption service (7) may include a payload receiving component (576) arranged to receive a payload for encryption and a communication address of a first computing device to which the payload is to be transmitted. The payload receiving component may receive the communication address and payload from a second computing device. The encryption service (7) may include a checking component (578) arranged to check that the communication address is enrolled for secure communication. The encryption service (7) may include an encrypting/decrypting component (580) arranged to encrypt and decrypt payloads using a second cryptographic key. The encrypting/decrypting component may be configured to encrypt a payload responsive to the checking component determining that the communication address is enrolled for secure communication. The second cryptographic key may be unique to the communication address. The encryption service (7) may include a message transmitting/receiving component (582) arranged to transmit and receive SMS messages including encrypted payloads to and from the first computing device.

The use of a secure SIM overlay and/or cube identifier within the distributed ledger technologybased infrastructure may enable a computing device to develop a unique personality using the characteristics of the device, actions and personal interactions. It should be appreciated that according to aspects of the present disclosure, the computing device is part of the authorization process of the distributed ledger. Applying a cube ID without the associated computing device in the chain may always fail a transaction that was initiated from the incorrect computing device.

Figure 11 illustrates an example of a computing device (1 100) in which various aspects of the disclosure may be implemented. The computing device (1 100) may be embodied as any form of data processing device including a personal computing device (e.g. laptop or desktop computer), a server computer (which may be self-contained, physically distributed over a number of locations), a client computer, or a communication device, such as a mobile phone (e.g. cellular telephone), satellite phone, tablet computer, personal digital assistant or the like. Different embodiments of the computing device may dictate the inclusion or exclusion of various components or subsystems described below.

The computing device (1100) may be suitable for storing and executing computer program code. The various participants and elements in the previously described system diagrams may use any suitable number of subsystems or components of the computing device (1 100) to facilitate the functions described herein. The computing device (1100) may include subsystems or components interconnected via a communication infrastructure (1105) (for example, a communications bus, a network, etc.). The computing device (1100) may include one or more processors (1 110) and at least one memory component in the form of computer-readable media. The one or more processors (11 10) may include one or more of: CPUs, graphical processing units (GPUs), microprocessors, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs) and the like. In some configurations, a number of processors may be provided and may be arranged to carry out calculations simultaneously. In some implementations various subsystems or components of the computing device (1100) may be distributed over a number of physical locations (e.g. in a distributed, cluster or cloud-based computing configuration) and appropriate software units may be arranged to manage and/or process data on behalf of remote devices.

The memory components may include system memory (1115), which may include read only memory (ROM) and random access memory (RAM). A basic input/output system (BIOS) may be stored in ROM. System software may be stored in the system memory (1115) including operating system software. The memory components may also include secondary memory (1120). The secondary memory (1120) may include a fixed disk (1121), such as a hard disk drive, and, optionally, one or more storage interfaces (1122) for interfacing with storage components (1123), such as removable storage components (e.g. magnetic tape, optical disk, flash memory drive, external hard drive, removable memory chip, etc.), network attached storage components (e.g. NAS drives), remote storage components (e.g. cloud-based storage) or the like.

The computing device (1100) may include an external communications interface (1130) for operation of the computing device (1100) in a networked environment enabling transfer of data between multiple computing devices (1100) and/or the Internet. Data transferred via the external communications interface (1130) may be in the form of signals, which may be electronic, electromagnetic, optical, radio, or other types of signal. The external communications interface (1130) may enable communication of data between the computing device (1 100) and other computing devices including servers and external storage facilities. Web services may be accessible by and/or from the computing device (1100) via the communications interface (1130).

The external communications interface (1 130) may be configured for connection to wireless communication channels (e.g., a cellular telephone network, wireless local area network (e.g. using Wi-Fi™), satellite-phone network, Satellite Internet Network, etc.) and may include an associated wireless transfer element, such as an antenna and associated circuitry. The external communications interface (1130) may include a subscriber identity module (SIM) in the form of an integrated circuit that stores an international mobile subscriber identity and the related key used to identify and authenticate a subscriber using the computing device (1100). One or more subscriber identity modules may be removable from or embedded in the computing device (1100).

The external communications interface (1130) may further include a contactless element (1150), which is typically implemented in the form of a semiconductor chip (or other data storage element) with an associated wireless transfer element, such as an antenna. The contactless element (1150) may be associated with (e.g., embedded within) the computing device (1 100) and data or control instructions transmitted via a cellular network may be applied to the contactless element (1150) by means of a contactless element interface (not shown). The contactless element interface may function to permit the exchange of data and/or control instructions between computing device circuitry (and hence the cellular network) and the contactless element (1150). The contactless element (1 150) may be capable of transferring and receiving data using a near field communications capability (or near field communications medium) typically in accordance with a standardized protocol or data transfer mechanism (e.g., ISO 14443/NFC). Near field communications capability may include a short-range communications capability, such as radiofrequency identification (RFID), Bluetooth™, infra-red, or other data transfer capability that can be used to exchange data between the computing device (1100) and an interrogation device. Thus, the computing device (1100) may be capable of communicating and transferring data and/or control instructions via both a cellular network and near field communications capability.

The computer-readable media in the form of the various memory components may provide storage of computer-executable instructions, data structures, program modules, software units and other data. A computer program product may be provided by a computer-readable medium having stored computer-readable program code executable by the central processor (1 110). A computer program product may be provided by a non-transient or non-transitory computer- readable medium, or may be provided via a signal or other transient or transitory means via the communications interface (1130). Interconnection via the communication infrastructure (1105) allows the one or more processors (1110) to communicate with each subsystem or component and to control the execution of instructions from the memory components, as well as the exchange of information between subsystems or components. Peripherals (such as printers, scanners, cameras, or the like) and input/output (I/O) devices (such as a mouse, touchpad, keyboard, microphone, touch-sensitive display, input buttons, speakers and the like) may couple to or be integrally formed with the computing device (1100) either directly or via an I/O controller (1135). One or more displays (1145) (which may be touch-sensitive displays) may be coupled to or integrally formed with the computing device (1100) via a display or video adapter (1140).

The foregoing description has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure.

Any of the steps, operations, components or processes described herein may be performed or implemented with one or more hardware or software units, alone or in combination with other devices. Components or devices configured or arranged to perform described functions or operations may be so arranged or configured through computer-implemented instructions which implement or carry out the described functions, algorithms, or methods. The computer- implemented instructions may be provided by hardware or software units. In one embodiment, a software unit is implemented with a computer program product comprising a non-transient or non- transitory computer-readable medium containing computer program code, which can be executed by a processor for performing any or all of the steps, operations, or processes described. Software units or functions described in this application may be implemented as computer program code using any suitable computer language such as, for example, Java™, C++, or Perl™ using, for example, conventional or object-oriented techniques. The computer program code may be stored as a series of instructions, or commands on a non-transitory computer-readable medium, such as a random access memory (RAM), a read-only memory (ROM), a magnetic medium such as a hard-drive, or an optical medium such as a CD-ROM. Any such computer-readable medium may also reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

Flowchart illustrations and block diagrams of methods, systems, and computer program products according to embodiments are used herein. Each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may provide functions which may be implemented by computer readable program instructions. In some alternative implementations, the functions identified by the blocks may take place in a different order to that shown in the flowchart illustrations.

Some portions of this description describe the embodiments of the invention in terms of algorithms and symbolic representations of operations on information. These algorithmic descriptions and representations, such as accompanying flow diagrams, are commonly used by those skilled in the data processing arts to convey the substance of their work effectively to others skilled in the art. These operations, while described functionally, computationally, or logically, are understood to be implemented by computer programs or equivalent electrical circuits, microcode, or the like. The described operations may be embodied in software, firmware, hardware, or any combinations thereof.

The language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention set forth in any accompanying claims.

Finally, throughout the specification and any accompanying claims, unless the context requires otherwise, the word ‘comprise’ or variations such as ‘comprises’ or ‘comprising’ will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.