Temporary Device Identifiers

Abstract

A method and system for a first device to securely interact with a second device includes the following steps: receiving a request to create a transaction between the first device and the second device, the request being received by a server in communication with a ledger; determining whether the second device is registered with the server; if the second device is not registered with the server, the server assigns a symmetric key to the second device, and the symmetric key is associated with a UICC of the second device; generating a public / private key pair for the second device, the private / public key pair being associated with the symmetric key; the server creating a wallet for the second device on the ledger, the wallet having a wallet ID, and the wallet ID being associated with the public / private key pair; the HSS providing credentials for the second device to the server; the server associating the provided credentials with the symmetric key; and creating a transaction on the ledger between the wallet of the second device and the wallet on the ledger of the first device, the transaction being signed by the private key of the second device.

Description

[Technical Field]

[0001] FIELD OF THE INVENTION The present invention relates to a system and method for devices to interact securely by recording transactions on a distributed ledger. [Background technology]

[0002] Background of the Invention There is a common need for different entities to interact and transact with each other to exchange value and data. However, for this to occur in a safe and secure manner for each party to the transaction, a level of trust must exist between the transacting entities. In the absence of such trust, other structures and procedures, such as enforceable contracts and third-party entities or intermediaries, are necessary.

[0003] Cryptocurrencies are digital currencies that are a form of alternative currency (or private currency). They typically differ from centrally controlled, government-issued currencies (e.g., fiat currency) in that they provide a decentralized or decentralized currency and / or medium of exchange. Digital currencies may be traded or transmitted from one owner or entity to another and may be used for any purpose, such as purchasing goods, services, or obtaining data. As such, digital currencies represent an alternative to traditional currencies.

[0004] One example of a cryptocurrency is Bitcoin, although many other cryptocurrency systems have been devised. Bitcoin was developed by Satoshi Nakamoto, and the original paper outlining the basics of Bitcoin technology and principles, "Bitcoin: A Peer-to-Peer Electronic Cash System," can be found at https: / / bitcoin.org / bitcoin.pdf.

[0005] The technologies underlying decentralized cryptocurrencies, such as distributed ledgers, can also be used to record other types of transactions, forming a verifiable history of exchange or other forms of data without the need for trust to exist between entities. Distributed ledgers, such as blockchains, allow transactions and exchanges of value to occur in the absence of such trust. However, this requires the use of a public blockchain to form a consensus that is difficult to subvert or control by any individual actor or entity. This typically takes the form of a race to reach consensus based on proof-of-work, which itself can consume very high levels of resources in the form of computation and electricity.

[0006] An alternative approach is to use a private blockchain, but this again creates the need to establish trust between the parties and the owners and controllers of the private blockchain itself.

[0007] While trust can be established by determining and verifying an entity's identity or other characteristics, this effort introduces overhead and additional work, potentially leading to inefficiencies and additional load on computer systems or telecommunications networks. Furthermore, such verification or checks often rely on separate sources of information, each of which may also need to be verified and authorized or trusted. This may require significant bandwidth and processing resources. Therefore, this approach may only be appropriate for certain entities transacting above a certain value, where the overhead is not a significant burden. It also precludes the exchange of new value and data between new entities or low-value but high-volume, ephemeral exchanges. For small or numerous entities or devices, such as those forming the Internet of Things (IoT) or other low-computational-power devices, the overhead can significantly outweigh small value exchanges. This therefore limits the efficiency and scalability required to exchange value or data packages, especially for autonomous or unsupervised devices.

[0008] Therefore, there is a need for a method and system that overcomes these problems. Summary of the Invention [Means for solving the problem]

[0009] Summary of the Invention Systems and methods are provided that allow two or more devices to securely interact and exchange information or perform other transactions. At least one of the devices is pre-registered or known to the system. The other devices are unregistered. For example, the unregistered device may be roaming on a visited telecommunications network but includes a UICC or SIM to enable roaming. Transactions between the devices are recorded and can be verified using a blockchain or distributed ledger.

[0010] The unregistered device must have a wallet (with a wallet ID) on the ledger. The system generates a symmetric key for the unregistered device and associates this symmetric key with the unregistered device's UICC or SIM. A public / private key pair is also generated and associated or assigned to the symmetric key. Additionally, a wallet and ledger account are created and associated or assigned to the public / private key pair. A device identifier (e.g., its IMSI) may also be associated with the wallet ID and account identifier. The home subscriber server (HSS) provides the unregistered device's credentials, and these credentials are associated with the symmetric key. Thus, the telecommunications network's HSS can use the security of the UICC or SIM to provide a verifiable identity for the wallet on the ledger. It also provides a means for generating payments for any transactions (e.g., using the telecommunications network's billing system). This allows for secure interactions with other devices or entities registered in the system (in a similar manner). Transactions can then be generated and signed using the private key of the unregistered device (now securely registered in the system). The system may be, for example, a server or a platform.

[0011] According to a first aspect, there is provided a method for a first device to securely interact with a second device, the method comprising: receiving a request to create a transaction between a first device and a second device, the request being received by a server in communication with a ledger (e.g., a distributed ledger or a blockchain); Determining whether the second device is registered with the server, and if the second device is not registered with the server, the server assigns a symmetric key to the second device, the symmetric key being associated with a UICC of the second device; generating a public and private key pair for the second device, the private and public key pair being associated with the symmetric key; the server generates a wallet for the second device on the ledger, the wallet having a wallet ID, the wallet ID being associated with a public / private key pair; a home subscriber server (HSS) providing credentials of the second device to the server; The server associates the provided credentials with a symmetric key; generating a transaction on the ledger between a wallet on the second device and a wallet on the ledger on the first device, the transaction being signed by the private key of the second device; Thus, a device (second device) unknown to the system (e.g., not yet having a wallet on the ledger) can securely interact and transact (exchange information and value) with a registered device known to the system. Preferably, the first device already has a wallet ID on the ledger and an associated public and private key pair with an assigned symmetric key associated with the UICC or SIM of the first device. Preferably, the ledger is a distributed ledger. Preferably, the ledger is a blockchain. The first (or second) device may be part of a server or platform that provides a service (e.g., parking or charging services) to the second (or first) device. Recording exchanges of data only (i.e., not involving the exchange of value or currency) in this verifiable and secure manner is also advantageous because it allows such data to be securely shared between devices not originally registered in the same system.

[0012] Preferably, the method may further include registering the UICC of the second device with the HSS, which is preferably performed in advance, before the other steps, so that the second device is registered on the network (e.g., roaming) to be able to access data services, and its identity has been verified in advance (i.e., using its UICC or SIM).

[0013] Optionally, generating a wallet for the second device may further include providing credits to the wallet. The credits may represent currency credits or other forms of value. This may therefore improve efficiency, as value can be exchanged without the second device having to add funds to the wallet in advance. The risk of default (not refunding credits) is low, as the identity of the second device has been verified by the HSS, roaming changes have been recorded, and used credits have been accrued and can be used for refunds.

[0014] Optionally, the credits may be stored as tokens in the wallet. Other mechanisms may be used, including directly storing the value of the credits.

[0015] Advantageously, the transaction may transfer at least a portion of the credits on the wallet of the second device to the wallet of the first device. The transaction may also, or alternatively, include a transfer of data or information, which may be recorded in the ledger.

[0016] Optionally, the second device may be roaming, and the method may further include settling one or more transaction totals in the wallet of the second device using a roaming charging platform associated with the HSS. Thus, visitors to the network (e.g., from overseas) can securely transact with other local users or services (i.e., the first device). When the second device is not roaming, the regular home charging system can be used.

[0017] Preferably, settling the total of the one or more transactions in the wallet of the second device may further include the roaming charging platform generating a call detail record (CDR) including the roaming charges on the HSS. Other payment mechanisms may be used.

[0018] Optionally, the method may further include signing the CDR using a private key of the second device. The signed CDR may be recorded in a ledger. The signed CDR may be verified before the charge is issued or added to a billing system.

[0019] Optionally, the value of the roaming charge on the CDR may be recorded as a roaming minute. Optionally, the method may further include providing additional credit to a wallet on the second device, which may occur before or after the original credit is used up or expires.

[0020] Optionally, the settlement step may further include authenticating one or more transactions on the ledger using the public key of the second device, thus making the transactions verifiable and reducing the occurrence of disputed transactions.

[0021] Optionally, the server's assignment of the symmetric key to the second device may be triggered by a smart contract, which may also trigger other events, including provisioning of services to or from the second device or a user of the second device (e.g., to or from the first device).

[0022] Optionally, the HSS providing the second device's credentials to the server may be triggered by the smart contract or another smart contract.

[0023] Optionally, the symmetric key may be configured to expire after a predetermined time, and may be replaced using a similar process, for example, before or after the expiration date.

[0024] Preferably, the wallet ID may be further associated with the international mobile subscriber identity (IMSI) of the second device, and thus the wallet ID may be directly or indirectly associated with the second device using a different unique identifier.

[0025] According to a second aspect, A server; a ledger associated with the server; a home subscriber server (HSS); Roaming payment system, a computer program comprising instructions that, when executed by one or more computers, cause the one or more computers to perform any or all of the methods described herein; A system is provided comprising:

[0026] The above-described methods may be implemented as a computer program comprising program instructions for operating a computer, which may be stored on a computer-readable medium.

[0027] A computer system may include one or more processors (e.g., local, virtual, or cloud-based), such as a central processing unit (CPU), and / or a single or collection of graphics processing units (GPUs). The processor may execute logic in the form of a software program. The computer system may include memory, including volatile and non-volatile storage media. Computer-readable media may be included for storing logic or program instructions. Different parts of the system may be connected using a network (e.g., wireless and wired networks). The computer system may include one or more interfaces. The computer system may include a suitable operating system, such as, for example, UNIX, Windows (RTM), or Linux.

[0028] It should be noted that any of the features described above may be used in any particular aspect or embodiment of the present invention.

[0029] BRIEF DESCRIPTION OF THE DRAWINGS The invention can be carried out in several ways and embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief explanation of the drawings]

[0030] [Figure 1] 1 shows a flowchart of a method for two or more devices to interact securely. [Figure 2] 2 shows, by way of example only, a schematic diagram of a system that may be used to implement the method of FIG. 1; [Figure 3] 2 shows a schematic diagram of a further system that can be used to implement the method of FIG. 1; [Figure 4] 2 shows a schematic diagram of a further system that can be used to implement the method of FIG. 1; [Figure 5] 2 shows a sequence diagram illustrating a further aspect of the method of FIG. 1; DETAILED DESCRIPTION OF THE INVENTION

[0031] It should be noted that the drawings are illustrated for simplicity and are not necessarily drawn to scale, and like features are numbered the same.

[0032] Detailed Description of the Preferred Embodiments The "Internet of Things" is growing, transitioning to an "Economy of Things" (EoT). The number of IoT devices is increasing and generating large amounts of data. IoT devices and smart services offer the possibility to interact and interoperate across ownership domains and automatically support transactions of data and smart service value in near real time. This allows for improved interoperability and functionality.

[0033] The "economy of things" requires the ability for devices / services to identify and trust each other and automatically transact value and / or information, either directly or using peer-to-peer capabilities as needed. While there are a variety of technologies ranging from distributed ledgers, secure elements, cryptography, and device wallets that support the digital identity, federated security, and transactional applications and services required for IoT, they are fragmented, costly, and not sufficiently scalable.

[0034] It is important that various entities and devices interact securely. In some situations, a device that is registered and known to a system (e.g., based on a distributed ledger) needs to interact with another device or entity that is currently unknown to the system. These interactions can be recorded as transactions on a ledger (e.g., a distributed ledger implementing a blockchain). For example, this allows devices that may be roaming on a telecommunications network to use services and provide services to other devices and entities.

[0035] There are billions of devices in operation today, but these devices may be isolated within separate systems. Without explicit contracts between system operators that involve expensive integration processes, these separate devices are limited in how they can interact with each other and dynamically interoperate to exchange information, provide services, and execute transactions to exchange value.

[0036] The described system and method solve this problem by introducing smart cryptographic triggers to authenticate devices that may be operating on other subscriber networks or not registered in the system. In summary, the method uses PKI asymmetric cryptography by using the private key of a public-private key pair provisioned or stored on the device's UICC or SIM, allowing the device to externally sign on a distributed ledger technology (DLT). The smart contract triggers the Home Subscriber Server (HSS) to authenticate the device (device ID). If the private key is not available to the device (because this is the first transaction using the method and system and the device is currently unregistered), the smart contract triggers the generation of a unique symmetric key associated with the device's UICC or SIM. The symmetric key is linked to the private key associated with the device ID key (e.g., IMSI) on the DLT and to the ledger ID and account.

[0037] When a transaction is requested (e.g., by a party to the transaction or by an external system) and a corresponding account and private key cannot be found on the ledger for one of the parties or device, a symmetric key (preferably time-limited) is generated and the corresponding private key and wallet and account are associated with the device on the mobile node, which is for devices that require additional authentication provided by the HSS. This also includes the creation of a temporary ledger ID.

[0038] A device on a mobile node may be associated with a smart contract to trigger authentication of the UICC or SIM by the HSS, but the account (wallet) does not have any credits to make transactions.

[0039] The HSS transaction token balance needs to be loaded into the device wallet. Once device authentication is established, a time-limited token can be created and loaded into the device wallet establishing a roaming balance covering one or more transactions. The HSS identity and authentication credentials (obtained from the HSS) are associated with the pseudo-ledger ID and the device state in the system transitions to Transaction Ready.

[0040] Token HSS settlement is achieved by interacting with the cellular billing system. A hash of each device's token balance is written to the mobile node. The smart contract for token settlement generates synthetic call detail records (CDRs) (i.e., synthetic in that they are not generated from telecommunication services such as SMS, voice, or data) for settlement on the cellular communication system's roaming platform (e.g., Syniverse RTM or Vodafone VRS Billing Evolution Engine). If the HSS cannot resolve the device's identity, a decentralized device ledger or other trusted blockchain may be used for authentication, and other private keys issued by those systems may be used to sign authentication transactions. However, these other trusted blockchains are not required if HSS authentication is achieved. If the device or authentication is not possible, temporary credentials associated with the device may expire (e.g., immediately or after a predetermined period of time).

[0041] FIG. 1 shows a flowchart of a method 10 for achieving this functionality. In step 20, a transaction request is received by a system or platform. The system may be known as a digital asset brokerage (DAB) or DAB platform. In step 30, a determination is made as to whether one of the devices (in this example, the second device) is registered with the system or platform (i.e., already possesses the private key used to sign the transaction). If the second device is already registered, method 10 may proceed directly to generating a signed transaction on the ledger (step 95). However, if it is determined that the second device is not registered, a series of further steps (40-70) are performed.

[0042] In step 40, the system or platform assigns a symmetric key to the second device. The symmetric key may be generated by a hardware security module or any other suitable means within the system. The symmetric key is transmitted to the second device (e.g., securely using cellular communications). This may be accomplished by any suitable secure provisioning. In step 50, a private-public key pair (Key priv Key pub ) is generated. This key pair may be stored by the UICC or other secure element of the second device.

[0043] In step 50, a wallet with a wallet ID is generated for operation on a ledger (distributed ledger or blockchain). In step 70, the wallet ID is associated with a key pair. The second device should already be provisioned for use on a cellular telecommunications network. The cellular telecommunications network has a Home Subscriber Server (HSS). In step 80, the HSS provides the second device's credentials to a server or platform. In step 90, the server or platform associates the credentials with a symmetric key. Thus, the server or platform has now registered the second device, which can execute and sign transactions using its private key. In step 95, the originally requested transaction (see step 20) is added to the ledger in a form signed by the second device's private key for future verification. In this way, the first and second devices interact and transact securely. In some example implementations, a smart contract triggers these steps when certain conditions are met. For example, the smart contract may perform a test as to whether the second device is registered, and if not, proceed to registration steps 40 to 90. In an example implementation, a service provider (e.g., the operator of the first device) may trigger the smart contract to perform the registration steps.

[0044] FIG. 2 shows a schematic diagram (at a high level) of an exemplary system 100 used to implement the method 10 described with reference to FIG. 1. A first device 110, having a SIM 120 (registered before a transaction is requested), and a server 140 (DAB) communicate securely over a communication channel, such as a cellular communication channel. A second device 160 (not registered with the server 140 before a transaction is requested), also has a SIM 170 and communicates with both the first device 110 and the platform's server 140. A distributed ledger 150 receives instructions to execute transactions from the server 140. An HSS 155 enables the second device 160 to both access a cellular telecommunications network (not shown in this figure) and provide the second device 160's credentials to the server 140. The private and public keys and symmetric keys of each device are securely stored in the secure storages 130 and 180 of the first and second devices, respectively.

[0045] Scalability and interoperability are key capabilities for IoT transactions and payments. In the described systems and methods, the HSS 150 is used for fast, scalable authentication of IoT devices so that devices can trust each other and authenticate associated wallets for transactions.

[0046] In a first scenario, a registered or first device 110 (e.g., registered in the ledger and operating within its home network that is also configured to use the described system and method 10) interacts with a similarly registered device to create an exchange of data, services, and other transactions. The home HSS 150 is used to authenticate both devices, and the transaction is routed to the ledger 155 for the devices to sign the transaction.

[0047] In a second scenario, a registered device 110 (i.e., as described above) wants to transact with a device 160 that is not operating within its home network (e.g., it may be roaming). However, the roaming device 160 has previously registered with the ledger and is already configured with its private / public key pair, its symmetric key, and has a wallet ID and account on the ledger 155. Authentication is achieved for both devices, and the roaming device is registered or configured with the status of its certificate authority (CA) credentials checked. The device is verified and authorized, and a proxy wallet and ledger ID is assigned to the ledger 155 for performing the transaction. Symmetric SIM Trust (or other exemplary secure application running within the SIM or UICC) may be used to sign the transaction.

[0048] In a third scenario, registered device 110 wants to transact with unregistered device 160 (e.g., one that has never had any interaction with the system). In this scenario, because unregistered device 160 is not registered in ledger 155, system 100 may check whether other trusted device blockchains (not shown in this figure) are available to authorize unregistered device 160. Once the device ID is verified, device 160 is authorized and assigned a proxy wallet and ID by server 140 to process the transaction. Again, Symmetric SIM Trust (or other exemplary secure application running within the SIM or UICC) may be the key used to sign the transaction on ledger 155.

[0049] In the second and third scenarios, a proxy ID and wallet may be used to create a persistent ID and wallet on ledger 155. When a device or device user wants to port into the system, the ledger ID can become its master ID and may provision a virtual overlay SIM profile using HSS 150 for the port.

[0050] This method 10 facilitates improved functionality and interoperability between different entities and optionally improves compatibility between different blockchains, including enabling "classic" wallet functionality, as well as processing of traditional payment rails.

[0051] 3 shows a schematic diagram of a further exemplary implementation 200. In this exemplary implementation 200, a first device 110 is a vehicle including a SIM 120. The first device 110 is already registered with the system 100. A second device 160 provides charging services but is not registered with the system 100. The second device 160 is roaming on the same cellular telecommunications system used by the first device 110, although this is not required. The server 140 in this example is designated as a DAB. In this example, the transaction is to provide charging services in exchange for value (ultimately currency). The HSS 150 provides the credentials of the second device 160. Two additional authentication services perform authentication functions: an ID authentication DAB external 210 provides external authentication (e.g., using a separate blockchain); and an ID authentication DAB VF 220 authenticates devices in the ledger 155 (e.g., transactions signed using their private keys).

[0052] FIG. 4 schematically illustrates the components of system 400 and the flow of data and method steps for operating the exemplary implementation of FIG. 3 . A DAB SIM 120 resides in the vehicle (first device) 110. A SIM management component 410 provides symmetric and public-private key pairs to the SIM in the device and manages authentication. A DAB ID management component 430 is part of system 100 and interacts with a roaming payment system 440, which can generate wallet IDs for ledger 155 and generate call detail records (CDRs) used to cover transaction costs. The roaming payment system 440 includes a payment rail for obtaining payments to cover roaming charges and other billed fees. An auto-provisioning component 450 associates device credentials obtained from HSS 150 with wallet IDs, device identifiers (e.g., IMSIs), and device accounts on ledger 155.

[0053] Starting with the DAB SIM 120, a device authentication request is made with the SIM management component 410. The authentication request is made to the authentication service 210. If the HSS 150 is not resolved (no device credentials can be provided), the authentication DAB ledger 220 communicates with the DAB identity management component 430, which determines that the device 160 is not found on the DAB ledger 155, and therefore attempts to authenticate the device 160 using another trusted blockchain.

[0054] The DAB ledger 155 assigns a proxy ID and a proxy wallet to the requested transaction (e.g., payment for a billing service), which are added to the mobile node on the DAB ledger 155.

[0055] 5 shows a sequence diagram of method 10 in more detail. A device (i.e., an unregistered device or second device 160) makes a transaction request to the DAB platform or server 140. The DAB platform (server) 140 responds by asking the device 160 to sign the transaction using its DAB (private) key. The device 160 responds that it does not have a DAB key. This triggers a smart contract (in the server 140) to assign the device 160 an ephemeral (symmetric) key. The DAB platform (server) 140 also generates a wallet with a temporary ledger ID (DAB ID) and a wallet ID. This constitutes a step for onboarding the device 160 to a mobile node on the DAB ledger 155.

[0056] The device 160 can continue a transaction with another device 110, which can be a standalone device or part of a larger (e.g., external) system. A request is triggered by the smart contract to the HSS 150 to provide the device 160's credentials. The HSS 150 responds with the requested credentials. These credentials are associated with a ledger ID (DAB ID) and the account status is changed to Transaction Ready. The DAB platform (server) 140 generates credit for the device in the form of tokens with a token balance. The device 160 can then pay for the transaction.

[0057] The DAB key (the public key currently stored in the SIM 170 of the device 160) can be used to sign transactions. However, the provided credits may be depleted or require replenishment. Tokens can therefore be redeemed against CDRs generated by the billing system or roaming settlement system 440. The roaming settlement system 440 verifies the transactions on the ledger 155 in the DAB platform 140 by checking their hash. For transactions thus authenticated, the roaming settlement system 440 settles each CDR with the HSS 150, which generates the cost (or credit, if service is provided) for the next bill or statement to the user or entity owning the device 160. When such a settlement occurs, a balance update can be made to credit the wallet ID on the DAB ledger 155.

[0058] Those skilled in the art will appreciate that details of the above-described embodiments can be changed without departing from the scope of the invention as defined by the claims that follow.

[0059] For example, by using machine learning, some or all of the authentication steps may be avoided or omitted. Devices that operate in a certain way or exhibit certain behaviors may be determined by the machine learning model to be more trustworthy and therefore require fewer authentication steps. This can be determined dynamically and over time. Although only two devices are shown in the example, any number of devices (both registered and unregistered) may be part of the system.

[0060] Many combinations, modifications, or variations on the features of the above-described embodiments will be readily apparent to those skilled in the art and are intended to form part of the present invention. Any of the features described with particular reference to one embodiment or example may be used in any other embodiment, by making appropriate modifications.

Claims

1. 1. A method for a first device to securely interact with a second device, the method comprising: receiving a request to create a transaction between the first device and the second device, the request being received by a server in communication with a ledger; determining whether the second device is registered with the server; and if the second device is not registered with the server, the server assigns a symmetric key to the second device, the symmetric key being associated with a UICC of the second device; generating a public / private key pair for the second device, the private / public key pair being associated with the symmetric key; the server creates a wallet for the second device on the ledger, the wallet having a wallet ID, the wallet ID being associated with the public / private key pair; a Home Subscriber Server (HSS) providing credentials of the second device to the server; the server associating the provided credentials with the symmetric key; generating a transaction on the ledger between the wallet of the second device and a wallet on the ledger of the first device, the transaction being signed by the private key of the second device; A method comprising:

2. 10. The method of any preceding claim, wherein the method further comprises registering the UICC of the second device with the HSS.

3. The method of claim 1 or claim 2, wherein generating the wallet for the second device further comprises providing credit to the wallet.

4. The method of claim 3 , wherein the credits are stored as tokens in the wallet.

5. 5. The method of claim 3, wherein the transaction transfers at least a portion of the credits in the wallet of the second device to the wallet of the first device.

6. 6. The method of claim 3, wherein the second device is roaming, and the method further comprises settling one or more transaction sums in the wallet of the second device using a roaming charging platform associated with the HSS.

7. 7. The method of claim 6, wherein settling the total of one or more transactions in the wallet of the second device further comprises the roaming charging platform generating a call detail record (CDR) including roaming charges on the HSS.

8. The method of claim 7 , further comprising signing the CDR using the private key of the second device.

9. The method of claim 7 or claim 8, wherein the value of the roaming charge on the CDR is recorded as a roaming minute.

10. The method of any of claims 7 to 9, further comprising providing additional credit to the wallet of the second device.

11. 11. The method of claim 6, wherein the settling further comprises authenticating the one or more transactions on the ledger using the public key of the second device.

12. 10. The method of any preceding claim, wherein the server's assignment of a symmetric key to the second device is triggered by a smart contract.

13. 10. The method of any preceding claim, wherein the HSS providing the second device's credentials to the server is triggered by a smart contract.

14. 10. A method according to any preceding claim, wherein the symmetric key is configured to expire after a predetermined time.

15. 10. The method of any preceding claim, wherein the wallet ID is further associated with an International Mobile Subscriber Identity (IMSI) of the second device.

16. A server; a ledger associated with the server; a home subscriber server (HSS); Roaming payment system, - a computer program comprising instructions which, when executed by one or more computers, cause said one or more computers to carry out a method according to any of the preceding claims; A system comprising:

Images