Temporary device identifier

Abstract

A method and system for secure interaction between a first device and a second device, the method comprising the steps of 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. It is determined whether the second device has registered with the server and whether the second device has not registered with the server, and then the server allocates a symmetric key to the second device, where the symmetric key is associated with a UICC of the second device. And generating a public key and private key pair of the second device, wherein the private key and public key pair is associated with the symmetric key. The server generates a wallet of the second device on the account book, where the wallet has a wallet ID, and the wallet ID is associated with a public key and private key pair. The HSS provides credentials of the second device to the server. The server associates the provided credentials with a symmetric key. A transaction is generated on the account book between the wallet of the second device and the wallet on the account book of the first device, wherein the transaction is signed by the private key of the second device.

Description

Technical Field

[0001] The present invention relates to a system and method for enabling secure interaction of devices by recording transactions on a distributed ledger. Background Art

[0002] There is a general need for interaction and transactions between different entities to exchange value and data. However, for all parties to a transaction to transact in a secure and reliable manner, there needs to be a certain degree of trust between the transaction entities. In the absence of such trust, other structures and procedures are required, such as enforceable contracts and third-party institutions or intermediaries.

[0003] Cryptocurrencies are digital currencies, which are a form of alternative currency (or private money). They are generally distinct from centrally controlled government-issued currencies (such as fiat currencies) and provide a decentralized or distributed currency and / or medium of exchange. Digital currencies can be transacted or transferred from one owner or entity to another and can be used for any purpose, such as purchasing goods, purchasing services, or even obtaining data. Thus, digital currencies are a substitute for traditional currencies.

[0004] An example of a cryptocurrency is Bitcoin, although many other cryptocurrency systems have also been designed. Bitcoin was developed by Satoshi Nakamoto, and its original paper "Bitcoin: A Peer-to-Peer Electronic Cash System" outlines the basic principles of Bitcoin technology and principles and is available at https: / / bitcoin.org / bitcoin.pdf for reference.

[0005] The underlying technology of distributed cryptocurrencies, such as distributed ledgers, can also be used to record other types of transactions and can form a verifiable exchange history or other forms of data without the need for trust between entities. Distributed ledgers, such as blockchains, can conduct transactions and value exchanges without such trust. However, this requires the use of a public blockchain to form a consensus, which is difficult for any individual or entity to disrupt or control. This typically takes the form of a proof-of-work-based competition to reach a consensus, but this itself consumes a large amount of computing and power resources.

[0006] Another approach is to use a private blockchain, but this again requires trust to be established between the parties and the owner and controller of the private blockchain itself.

[0007] Trust can be established by determining and verifying the identity or other characteristics of an entity, but such efforts can incur overhead and additional work, leading to inefficiencies and additional burdens in computer systems or telecommunications networks. Additionally, such verification or checking often relies on different sources of information, and each source may itself require verification and approval or trust. This can require significant bandwidth and processing resources. As a result, this approach may only be suitable for entities where certain transactions exceed a specific value, as in such cases the overhead does not become a significant burden. This also prevents the development of new value and data exchanges between entities that are strangers to each other, or prevents low-value but high-volume instantaneous exchanges. For small-scale or numerous entities or devices, such as those that make up the Internet of Things (IoT) or other low-computing-capability devices, the overhead greatly exceeds the small-scale value exchanges. Thus, this limits the efficiency and scalability required for exchanging value or data packets, especially for autonomous or unsupervised devices.

[0008] Accordingly, a method and system are needed to overcome these problems. SUMMARY OF THE INVENTION

[0009] The present disclosure provides a system and method that enables two or more devices to securely interact and exchange information or conduct other transactions. At least one of the devices has been pre-registered or is otherwise known to the system. Another device is 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 needs to 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 UICC or SIM of the unregistered device. A public key and private key pair are also generated and associated with or assigned to the symmetric key. Additionally, a wallet and ledger account are created and associated with or assigned to the public key and private key pair. A device identifier (such as an IMSI) can also be associated with the wallet ID and account identifier. The Home Subscriber Server (HSS) provides credentials for the unregistered device, which are associated with the symmetric key. Thus, the HSS of the telecommunications network can utilize the security of the UICC or SIM to provide a verifiable wallet identity on the ledger. It also provides a means to generate payments for any transaction (e.g., using the billing system of the telecommunications network). This enables secure interaction with other devices or entities registered in the system (in a similar manner). Then, transactions can be generated and signed using the private key of the unregistered device (now securely registered in the system). The system can be, for example, a server or platform.

[0011] A method for secure interaction between a first device and a second device is provided according to a first aspect. The method includes the following steps:

[0012] Receiving a request to create a transaction between the first device and the second device, the request being received by a server communicating with a ledger (such as a distributed ledger or a blockchain);

[0013] Determining whether the second device has been registered with the server and whether the second device has not been registered with the server:

[0014] The server allocates a symmetric key to the second device, where the symmetric key is associated with the UICC of the second device,

[0015] Generating a public and private key pair for the second device, where the private key and the public and private key pair are associated with the symmetric key,

[0016] The server generates a wallet for the second device on the ledger, where the wallet has a wallet ID, and the wallet ID is associated with the public and private key pair;

[0017] A Home Subscriber Server (HSS) provides credentials of the second device to the server;

[0018] The server associates the provided credentials with the symmetric key; and

[0019] Generating a transaction on the ledger between the wallet of the second device and the wallet on the ledger of the first device, where the transaction is signed by the private key of the second device. Thus, a device (the second device) unknown to the system (such as a system that does not yet have a wallet on the ledger) can securely interact and transact (exchange information and value) with a device known and registered by the system. Preferably, the first device already has a wallet ID and an associated public and private key pair on the ledger, and the public and private key pair has an allocated 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 can be part of a server or platform that provides services (such as parking or charging services) to the second (or first) device. It is also advantageous to record data exchange (i.e., without exchanging value or currency) in this verifiable and secure manner, as such data can be securely shared between devices that were not initially registered in the same system.

[0020] Preferably, the method further includes the step of registering the UICC of the second device with the HSS. This is preferably done in advance before other steps. Thus, the second device will be registered on the network (such as roaming) to be able to access data services, and its identity will also be verified in advance (i.e., using its UICC or SIM).

[0021] Optionally, the step of generating the wallet of the second device further includes providing a credit limit to the wallet. The credit limit may represent a currency credit limit or other forms of value. Thus, this can improve efficiency as the second device can exchange value without having to add funds to the wallet in advance. The risk of default (not repaying the credit limit) is low because the identity of the second device has been verified by the HSS, and roaming changes can be recorded and generated and used to repay any spent credit limit.

[0022] Optionally, the credit limit can be stored in the wallet as a token. Other mechanisms can also be used, including directly storing the numerical value of the credit limit.

[0023] Advantageously, the transaction can transfer at least a portion of the credit limit in the wallet of the second device to the wallet of the first device. Additionally or alternatively, the transaction can involve the transfer of data or information, and such transfer can be recorded on a ledger.

[0024] Optionally, the second device may be roaming, and the method further includes the step of using a roaming charging platform associated with the HSS to settle the sum of one or more transactions of the wallet of the second device. Thus, a network visitor (e.g., from abroad) can securely transact with other local users or services (i.e., the first device). When the second device is not roaming, the usual home charging system can be used.

[0025] Preferably, the step of settling the sum of one or more transactions of the wallet of the second device further includes the roaming charging platform generating a call detail record CDR, including the roaming fee on the HSS. Other payment mechanisms can also be used.

[0026] Optionally, the method further includes the step of signing the CDR using the private key of the second device. The signed CDR can also be recorded on the ledger. The signed CDR can be verified before the charge is issued or added to the charging system.

[0027] Optionally, the numerical value of the roaming fee on the CDR can be recorded as roaming minutes.

[0028] Preferably, the method further includes the step of providing additional credit limit to the wallet of the second device. This can be done before or after any original credit limit is used up or expires.

[0029] Optionally, the settlement step further includes the step of verifying one or more transactions on the ledger using the public key of the second device. Thus, the transactions are verifiable and the occurrence of disputed transactions can be reduced.

[0030] Optionally, the step of the server distributing the symmetric key to the second device may be triggered by a smart contract. The smart contract may also trigger other events, including providing a service to the second device or a user of the second device, or providing a service by the second device or a user of the second device (e.g., to the first device or by the first device).

[0031] Optionally, the step of the HSS providing the credentials of the second device to the server may be triggered by the smart contract or another smart contract.

[0032] Optionally, the symmetric key can be configured to expire after a predetermined time. For example, the symmetric key can be replaced using a similar procedure before or after expiration.

[0033] Preferably, the wallet ID may be further associated with the International Mobile Subscriber Identity IMSI of the second device. Thus, the wallet ID may be directly or indirectly associated with the second device using different unique identifiers.

[0034] According to a second aspect, there is provided a system comprising:

[0035] server;

[0036] The ledger associated with the server;

[0037] Home User Server HSS;

[0038] Roaming Settlement System; and

[0039] A computer program comprising instructions which, when executed by one or more computers, can cause the one or more computers to perform any or all of the aforementioned methods.

[0040] The above method can be implemented as a computer program, which includes instructions to operate a computer. The computer program can be stored on a computer readable medium.

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

[0042] It should be noted that any of the features described above may be used in connection with any particular aspect or embodiment of the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] The present invention can be implemented in various ways. Now, embodiments of the present invention will be described only by way of example and with reference to the accompanying drawings:

[0044] Figure 1 A method flowchart showing the secure interaction of two or more devices;

[0045] Figure 2 Showing for implementing Figure 1 The system schematic diagram of the method, for reference only;

[0046] Figure 3 Showing for implementing Figure 1 The schematic diagram of another system of the method;

[0047] Figure 4 Showing for implementing Figure 1 The schematic diagram of another system of the method; and

[0048] Figure 5 Showing the sequence diagram of other aspects of the method for explaining Figure 1 The method.

[0049] It should be noted that these drawings are for simplicity and are not necessarily drawn to scale. The same features are denoted by the same reference numerals. Detailed Description of the Invention

[0050] The "Internet of Things" is evolving and transitioning towards the "Economy of Things (EoT)". The number of IoT devices is increasing continuously and generating a large amount of data. IoT devices and intelligent services can interact and interoperate across ownership domains and have the potential to automatically support data and intelligent service value transactions almost in real time. This can improve interoperability and functionality.

[0051] The "Economy of Things" requires devices / services to be able to identify and trust each other and, when necessary, automatically transact value and / or information directly or using peer-to-peer functions. Currently, there is a series of technologies, including distributed ledgers, secure elements, cryptography, and device wallets, which can support the digital IDs, joint security, and transaction applications and services required by the IoT. However, these technologies are scattered, costly, and lack scalability.

[0052] The secure interaction between different entities and devices is very important. In some cases, devices that are registered and known to the system (e.g., based on a distributed ledger) need 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 blockchain). For example, this allows devices that may roam into a telecommunications network to use other devices and entities and provide services to them.

[0053] There are currently billions of devices in operation, but these devices may be isolated in different systems. Without a clear contract between system operators, including an expensive integration process, these independent devices are restricted in how they interact with each other and dynamically interoperate, thus unable to conduct transactions to exchange information, provide services, and exchange value.

[0054] The described system and method solve this problem by introducing intelligent encryption triggers to authenticate devices that may be operating on other users' networks or are not registered in the system. In summary, the method uses PKI asymmetric encryption technology by using the private key of a public-private key pair, configuring or storing it on the device's UICC or SIM, so that the device can be externally signed on the distributed ledger technology (DLT). The smart contract triggers the Home Subscriber Server (HSS) to authenticate the device (device ID). In the case where the device does not have a private key (because this may be the first time the device uses this method and system for transactions and the device is not currently registered), the smart contract triggers the generation of a unique symmetric key, which is associated with the device's UICC or SIM card. This symmetric key is associated with the private key, ledger ID, and an account associated with the device ID key (such as IMSI) on the DLT.

[0055] When a transaction is requested (e.g., by one party to the transaction or an external system), but the corresponding account and private key of a party or device cannot be found on the ledger, a symmetric key (preferably time-limited) is generated, and the corresponding private key, wallet, and account are associated with the device on the migration node. This migration node is used for devices that require additional verification by the HSS. This also involves creating a temporary ledger ID.

[0056] The device on this migration node may be associated with a smart contract to trigger the HSS to verify the UICC or SIM card. However, this account (wallet) does not have any credit available for transactions.

[0057] The HSS transaction token balance needs to be loaded into the device wallet. After device authentication is established, a time-limited token can be created and loaded into the device wallet, setting a roaming balance to pay for one or more transactions. The HSS identity and authentication credentials (obtained from the HSS) will be associated with the temporary ledger ID, and the device status within the system will change to "transaction ready".

[0058] Token HSS settlement is achieved by interacting with the cellular billing system. The hash value of the token balance of each device is written to the migration node. The smart contract for token settlement generates synthetic call detail records (CDRs) (i.e., synthetic because it is not generated by telecommunications services such as SMS, voice, or data) for settlement on the roaming platform of the cellular communication system (such as the Syniverse RTM or Vodafone VRS billing evolution engine). If the HSS cannot resolve the identity of the device, a decentralized device ledger or other trusted blockchain can be used for verification, and the verification transaction is signed using other private keys issued by these systems. However, these other trusted blockchains are not necessary when implementing HSS verification. In cases where device or verification cannot be achieved, the temporary credentials associated with the device may expire (e.g., immediately or after a predefined period).

[0059] Figure 1 The flowchart of method 10 for implementing this function is shown. At step 20, the system or platform receives a transaction request. This system can be referred to as a Digital Asset Broker (DAB) or DAB platform. At step 30, it is determined whether one of the devices (in this case, the second device) has been registered in the system or platform (i.e., already has the private key for signing transactions). If the second device has been registered, then method 10 can directly generate a signed transaction on the ledger (step 95). However, if it is determined that the second device is not registered, a series of subsequent steps (40 - 70) need to be executed.

[0060] At step 40, the system or platform assigns a symmetric key to the second device. The symmetric key can be generated by a hardware security module or any other suitable means within the system. The symmetric key is transmitted (e.g., securely using cellular communication) to the second device. This can be achieved through any suitable security configuration. At step 50, a private key - public key key pair (secret key 私有 secret key 公共 ) is generated. This key pair can be stored by the UICC or other secure elements of the second device.

[0061] 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 be configured for a cellular telecommunications network. The cellular telecommunications network has a Home Subscriber Server (HSS). In step 80, the HSS provides credentials of the second device 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 is capable of signing transactions using its private key. In step 95, the originally requested transaction (see step 20) is now added to the ledger in a form signed by the private key of the second device for future verification. In this way, the first device and the second device can interact and transact securely. In some example embodiments, a smart contract triggers these steps when specific conditions are met. For example, the smart contract can test whether the second device is registered and, if not, continue with the registration steps 40 to 90. In one example embodiment, a service provider (e.g., the operator of the first device) can trigger the smart contract to perform the registration steps.

[0062] Figure 2 Illustrates a schematic diagram of an example system 100 (at a high level) for implementing the method 10 described in reference Figure 1 A first device 110 with a SIM 120 (already registered before requesting a transaction) and a server 140 (DAB) communicate securely via a communication channel, such as a cellular communication channel. A second device 160 (not registered on the server 140 before requesting a transaction) also has a SIM 170 and communicates with the first device 110 and the server 140 of the platform. The distributed ledger 150 receives instructions to execute transactions from the server 140. The HSS 155 enables the second device 160 to access the cellular telecommunications network (not shown in the figure) and provides the credentials of the second device 160 to the server 140. The private keys, public keys, and symmetric keys of each device are securely stored in the secure memories 130 and 180 of the first and second devices respectively.

[0063] Scalability and interoperability are key capabilities for IoT transactions and payments. In the described system and method, the HSS 150 is used for fast and scalable verification of IoT devices so that devices can trust each other and verify their associated wallets for transactions.

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

[0065] In the second case, the registered device 110 (as described above) wishes 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 been previously registered on the ledger and has set up its private and public key pair, its symmetric key, and has a wallet ID and account on the ledger 155. Both devices have been verified, and the status of the roaming device being registered or set up as a certificate authority (CA) credential has been checked. The devices are verified and approved, and a proxy wallet and ledger ID are assigned on the ledger 155 for the transaction. Symmetric SIM trust (or other security application instances running within the SIM or UICC) can be used to sign the transaction.

[0066] In the third case, the registered device 110 wishes to transact with an unregistered device 160 (e.g., a device that has not interacted with the system at all). In this case, the unregistered device 160 is not registered on the ledger 155, so the system 100 can check if there is another trusted device blockchain (not shown in this figure) to authorize the unregistered device 160. If the device ID is confirmed to be valid, the device 160 will be approved, and a proxy wallet and ID will be assigned by the server 140 for processing the transaction. Again, symmetric SIM trust (or other security application examples running within the SIM or UICC) can be the key used to sign the transaction on the ledger 155.

[0067] In the second and third cases, the proxy ID and wallet can be used to create a permanent ID and wallet on the ledger 155. If the device or the user of the device wishes to port into the system, then their ledger ID can become their primary ID, and the HSS 150 can be used to configure a virtual overlay SIM profile for the migration.

[0068] This approach 10 helps improve functionality and interoperability between different entities and can optionally enhance compatibility between different blockchains. This includes "classic" wallet functionality as well as the ability to handle traditional payment infrastructure.

[0069] Figure 3Schematic diagram showing another exemplary embodiment 200. In this exemplary embodiment 200, the first device 110 is a vehicle including a SIM 120. This first device 110 has been registered in the system 100. The second device 160 provides a charging service but is not registered in the system 100. The second device 160 roams into the same cellular telecommunications system used by the first device 110, but this is not necessary. The server 140 in this example is designated as DAB. In this example, the transaction is for value (ultimately currency) in exchange for the charging service. The HSS 150 provides credentials for the second device 160. Two additional verification services perform verification functions. The ID auth DAB external 210 provides external verification (e.g., using a separate blockchain). The ID auth DABVF 220 verifies the device within the ledger 155 (e.g., a transaction signed with its private key).

[0070] Figure 4 Schematically shows the components of the system 400 and the data flow and method steps of an exemplary embodiment Figure 3 The DAB SIM 120 is located within the vehicle (first device) 110. The SIM management component 410 provides a symmetric key, a public key, and a private key pair for the SIM within the device and manages verification. The DAB ID management component 430 is part of the system 100, can generate a wallet ID for the ledger 155, and interacts with the roaming settlement system 440, which can generate call detail records (CDRs) for paying the transaction costs. The roaming settlement system 440 includes a payment infrastructure for obtaining payments for roaming fees and other billing costs. The automatic configuration component 450 associates the device credentials obtained from the HSS 150 with the wallet ID, the device identifier (such as IMSI), and the device account on the ledger 155.

[0071] Starting from the DAB SIM 120, the SIM management component 410 issues a device authorization request. The authorization request is sent to the Auth service 210. If the HSS 150 cannot resolve (cannot provide device credentials), then the Auth DAB ledger 220 communicates with the DAB ID management component 430, which determines that the device 160 is not found on the DAB ledger 155 and thus attempts to verify the device 160 using another trusted blockchain.

[0072] The DAB ledger 155 assigns an agent ID and an agent wallet for the requested transaction (such as paying for a charging service). These are added to the migration node of the DAB ledger 155.

[0073] Figure 5A sequence diagram of method 10 is shown in more detail. A device (i.e., an unregistered device or a second device 160) issues a transaction request to the DAB platform or server 140. The DAB platform (server) 140 responds, asking the device 160 to sign the transaction using its DAB (private) key. The device 160 responds with no DAB key. This triggers the smart contract (in the server 140) to assign a temporary (symmetric) key to the device 160. The DAB platform (server) 140 also generates a temporary ledger ID (DAB ID) and a wallet with a wallet ID. This constitutes the step of accessing the migration node of the DAB ledger 155 for the device 160.

[0074] The device 160 can continue to transact with another device 110, which can be a stand-alone device or part of a larger (e.g., external) system. The smart contract issues a request to the HSS 150 for the credentials of the device 160. The HSS 150 responds with the requested credentials. These credentials are associated with the ledger ID (DAB ID), and the status of the account is changed to transaction ready. The DAB platform (server) 140 generates a credit limit for the device in the form of a token with a token balance. The device 160 can now pay for the transaction.

[0075] The DAB key (the public key now stored in the SIM 170 of the device 160) can be used to sign the transaction. However, the provided credit limit may be exhausted or need to be replenished. Therefore, tokens can be exchanged according to the CDRs generated by the billing system or the roaming settlement system 440. The roaming settlement system 440 confirms the transactions on the ledger 155 within the DAB platform 140 by checking the hash values. For the transactions verified in this way, the roaming settlement system 440 will settle each CDR with the HSS 150, thus generating a charge (or a credit in the case of providing a service) on the next bill or statement of the user or entity owning the device 160. Once the settlement is complete, the balance can be updated and the wallet ID is recorded in the DAB ledger 155.

[0076] As those skilled in the art will understand, the details of the above embodiments can be modified without departing from the scope of the invention defined by the appended claims.

[0077] For example, by using machine learning, some or all of the verification steps can be avoided or omitted. The machine learning model can determine that devices acting in a specific way or exhibiting specific behaviors are more trustworthy and thus require fewer verification steps. This can be determined dynamically over time. Although only two devices are shown in the example, any number of devices (including registered and unregistered ones) can be part of the system.

[0078] Many combinations, modifications or variations of the features of the above embodiments will be apparent to those skilled in the art and are intended to form part of the present invention. Any feature specifically related to one embodiment or example can be used in any other embodiment with appropriate modifications.

Claims

1. A method for secure interaction between a first device and a second device, the method comprises 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 communicating with a ledger; Determining whether the second device has been registered with the server and whether the second device has not been registered with the server: The server allocates a symmetric key to the second device, wherein the symmetric key is associated with the UICC of the second device, Generating a public key and private key pair for the second device, wherein the private key and public key pair are associated with the symmetric key, The server generates a wallet for the second device on the ledger, wherein the wallet has a wallet ID, and the wallet ID is associated with the public key and private key pair; A Home Subscriber Server (HSS) provides credentials of the second device to the server; The server associates the provided credentials with the symmetric key; and Generating a transaction on the ledger between the wallet of the second device and the wallet on the ledger of the first device, wherein the transaction is signed by the private key of the second device.

2. The method according to any one of the preceding claims, the method further comprising the step of registering the UICC of the second device on the HSS.

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

4. The method according to claim 3, wherein the credit limit is stored in the wallet as a token.

5. The method according to claim 3 or 4, wherein the transaction transfers at least a portion of the credit limit in the wallet of the second device to the wallet of the first device.

6. The method according to any one of claims 3 to 5, wherein the second device is roaming, the method further comprising the step of settling the sum of one or more transactions of the wallet of the second device using a roaming charging platform associated with the HSS.

7. The method according to claim 6, wherein the step of settling the sum of one or more transactions of 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 according to claim 7 further comprises the step of signing the CDR using the private key of the second device.

9. The method according to claim 7 or 8, wherein the value of the roaming charges on the CDR is recorded as roaming minutes.

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

11. The method according to any one of claims 6 to 10, wherein the settlement step further comprises the step of verifying one or more transactions on the ledger using the public key of the second device.

12. The method according to any one of the preceding claims, wherein the step of the server allocating a symmetric key to the second device is triggered by a smart contract.

13. The method according to any one of the preceding claims, wherein the step of the HSS providing the credentials of the second device to the server is triggered by a smart contract.

14. The method according to any one of the preceding claims, wherein the symmetric key is configured to expire after a predetermined time.

15. The method according to any one of the preceding claims, wherein the wallet ID is further associated with the international mobile subscriber identity (IMSI) of the second device.

16. A system comprising: a server; a ledger associated with the server; a home subscriber server (HSS); a roaming settlement system; and a computer program containing instructions that, when executed by one or more computers, cause the one or more computers to perform the method according to any one of the preceding claims.

Images