SIM encryption key storage

Abstract

A method and system for recording transactions in a distributed ledger, the method including the steps of creating a secure channel between the device and a BSF using a pre-provisioned key stored in a UICC of the device and in a bootstrapping server function, the BSF; sharing a secret between the device and the BSF over the secure channel; storing the shared secret on the UICC of the device; and adding one or more transactions to a block of the distributed ledger, where the one or more transactions are identified using the shared secret.

Description

[Technical field]

[0001] FIELD OF THEINVENTION The present invention relates to a system and method for recording transactions on a distributed ledger, and in particular for a device or object to securely generate such transactions. [Background technology]

[0002] 2. Background of the Invention There is a common need for different entities to interact and transact with each other to exchange value. However, for this to occur in a manner that is safe and secure 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 agencies 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 currencies) and 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, purchasing services, or obtaining data. Digital currencies therefore 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 "Bitcoin: A Peer-to-Peer Electronic Cash System", which outlines the basics of Bitcoin technology and principles, 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 exchanges 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 party or entity. This usually 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 power.

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

[0007] Trust can be built by determining and verifying the identity or other characteristics of an entity, but this effort introduces overhead and additional work, which can lead to inefficiencies and additional load on computer or telecommunication networks. Moreover, such verification or checking often relies on separate sources of information, each of which may also need to be verified and approved or trusted. This may require significant bandwidth and processing resources. Thus, this approach may only be appropriate for certain entities transacting above a certain value, where the overhead is not a significant burden. This also prevents the exchange of new value between new entities with each other, or low-value but high-volume ephemeral exchanges. For small or large numbers of entities or devices, such as those that form the Internet of Things or other low-computational power devices, the overhead may significantly outweigh small value exchanges. Thus, this 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 Transactions are recorded in a distributed ledger, preferably by adding blocks to a blockchain. The distributed ledger does not need to be a public ledger or a blockchain that uses a proof-of-work and reward system to prevent individual entities from taking over control. Instead, the distributed ledger can be private. Trust needs to be built between the entities exchanging value with the distributed ledger, which provides a verifiable record of events and transactions. Furthermore, different parties need to know with certainty who they are transacting with. To achieve this, the device on which the transaction occurs includes a UICC, such as a SIM. When the SIM is manufactured or personalized, a unique key or keys are stored in a secure memory within the SIM. The same key (unique to the SIM) is stored or available to the telecommunications network that issues or owns the SIM. This key may be associated with an identifier for the SIM. This key is used to create a secure communication channel between the SIM (or the device housing the SIM) and a Bootstrapping Server Function (BSF). The BSF is an element within the telecommunications network used to implement the Generic Bootstrapping Architecture (GBA).

[0010] Once a communication channel is secured between the device and the BSF using the pre-stored key, a secret is shared (in the device) between the BSF and the SIM over this secured channel. This shared secret is stored in the SIM's secure storage. The device then uses this shared secret to identify entries or transactions that are added to blocks in the distributed ledger. Since transactions can be identified using or based on the shared secret shared using the GBA, either party can trust that the transaction and its origin or origin is as declared. This provides additional security and maintains trust, since the data store on the SIM is cryptographically protected and tamper-proof (even by the device).

[0011] Adding a transaction may use the shared secret directly in the transaction identifier, for example, by using this shared secret itself as part or all of the transaction identifier, or by being derived from it. However, a server such as a proxy server (i.e., an intermediary between the device and the distributed ledger) may add a transaction to a block using its own identifier or a wallet identifier (or one of a set of wallet identifiers) and perform the function of mapping the transaction to a shared secret associated with the SIM and the device. Such a mapping may be stored in a database or other data store within the proxy server or external to, but accessible by, the proxy server. Thus, the transaction, and thus the entity at which the transaction occurs, may be trusted by other parties or entities due to the trusted nature of the SIM. In this implementation, different servers may operate for different entities, functions, or transaction types.

[0012] According to a first aspect, there is provided a method of recording a transaction on a distributed ledger, the method comprising: creating a secure channel between the device and a Bootstrapping Server Function, the BSF, using a pre-provisioned key stored in the UICC of the device and in the BSF; Sharing a secret between the device and the BSF over a secure channel; storing a shared secret on a UICC of the device; adding one or more transactions to a block of a distributed ledger, where the one or more transactions are identified using a shared secret; Transactions or entries into the distributed ledger can therefore be more trusted as their identifiers can be linked to specific devices in a way that is difficult or impossible to tamper with without invalidating the highly secure SIM key distribution.

[0013] Optionally, the method further comprises: transmitting a shared secret from the BSF to a server, where the shared secret is used to secure a communication channel between the device and the server, and the server adds one or more transactions to a block of the distributed ledger; The server thus acts as a proxy between the devices and the distributed ledger or blockchain, which allows for improved scalability. For example, there may be multiple servers, each serving a different set of devices or functions, or for load balancing purposes.

[0014] Preferably, the one or more transactions may be associated with a wallet identifier of a server in the distributed ledger, the one or more transactions being: the server stores, remotely from the device, transaction identifiers of one or more transactions that have been added to a block of the distributed ledger; and The server maps the stored transaction identifier to a shared secret. Association with a device may be achieved using other alternative mechanisms.

[0015] Optionally, the transaction identifier may be based on the UICC identity and the shared secret. The transaction identifier may additionally be based on or derived from an identifier of the device (e.g., the IMSI).

[0016] Optionally, transactions that may be added to a block are identified by a wallet identifier based on the identity of the UICC and a shared secret.

[0017] Preferably, the shared secret may be stored in the Trusted Execution Environment, TEE, of the UICC, which further improves security.

[0018] Advantageously, the shared secret may be a symmetric key. Exemplary algorithms used to generate and use the symmetric key include, but are not limited to, Twofish, Serpent, AES, Camellia, Salsa20, ChaCha20, Blowfish, CAST5, Kuznyechik, DES, etc.

[0019] Optionally, creating a secure channel between the device and the BSF and sharing a secret between the device and the BSF over the secure channel may use a Generic Bootstrap Architecture, GBA, and / or may follow the GSMA IoT Security Applet Interface Description, IoT SAFE.

[0020] Optionally, the device may be any one of an IoT device, a UE, a smartphone, a vehicle, an automobile, or an unmanned aerial vehicle. Other devices may be used or may implement the method.

[0021] According to a second aspect, Distributed ledger and Bootstrapping Server Function, BSF, A device having a UICC; One or more processors and a memory, the memory providing to the one or more processors: creating a secure channel between the device and the BSF using a pre-provisioned key stored in the UICC of the device and in the BSF; Sharing a secret between the device and the BSF over a secure channel; and storing a shared secret on a UICC of the device; and Adding one or more transactions to a block in a distributed ledger, where one or more transactions are identified using a shared secret one or more processors and memory including program instructions for causing the A system is provided comprising: The system may have components that communicate over a telecommunications network.

[0022] Optionally, the system further comprises: Further comprising a server; The BSF is configured to transmit a shared secret to a server; The program instructions further cause the one or more processors to use the shared secret to secure a communication channel between the device and a server, where the server adds the one or more transactions to a block of the distributed ledger.

[0023] Optionally, the one or more transactions may be associated with a wallet identifier of the server, the server further comprising a database configured to store transaction identifiers of the one or more transactions added to a block of the distributed ledger, and a mapping of the stored transaction identifiers to a shared shared secret.

[0024] Optionally, the transaction identifier may be based on the identity of the UICC and a shared secret.

[0025] Preferably, transactions added to a block may be identified by a wallet or other identifier based on the identity of the UICC and a shared secret.

[0026] Preferably, the device comprises one or more processors and a memory including program instructions for causing the one or more processors to add one or more transactions to a block of the distributed ledger.

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

[0028] The 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 collective graphics processing unit (GPU). 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, Java, UNIX, Windows (RTM), or Linux.

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

[0030] BRIEF DESCRIPTION OF THE DRAWINGS The invention can be put into practice in a number of ways and embodiments will now be described, by way of example only, with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0031] [Figure 1] 1 illustrates a flowchart of an exemplary method for recording a transaction in a distributed ledger. [Diagram 2] FIG. 1 shows a schematic diagram of a system for recording transactions on a distributed ledger, including a device having a SIM. [Diagram 3] FIG. 3 is a schematic diagram showing the high level functionality of the system of FIG. [Figure 4] 3 shows a schematic diagram of some architectural components of the system of FIG. 2. [Diagram 5] 3 shows a schematic diagram of an example implementation of the system of FIG. 2, including a device and a SIM, a proxy server, and a distributed ledger. [Figure 6] 3 shows a schematic diagram of a further exemplary implementation of the system of FIG. 2; [Figure 7] 6 shows a schematic diagram of a system of devices operating according to the system of FIG. 5. [Figure 8] FIG. 6 shows a more detailed schematic diagram of a system of devices operating according to the system of FIG. 5. [Figure 9] 6 shows a schematic diagram of an example implementation of the system of FIG. 5. [Figure 10] 3 shows a schematic diagram of a further example implementation of the system of FIG. 2 including one or more nodes. [Figure 11] 11 shows a schematic diagram of the node of FIG. 10. [Figure 12] 11 shows a schematic diagram of the method steps performed by the system of FIG. 10; [Figure 13] 7 shows a schematic diagram of an example implementation of the system of FIG. 6. [Figure 14] 6 shows a schematic diagram of an example implementation of the SIM of FIG. 5. [Figure 15] 6 shows a schematic diagram of an exemplary implementation of the device of FIG. 5. [Figure 16] 2 shows a flow chart of a method for managing keys used in the method of FIG. 1; [Figure 17]7 shows a schematic diagram of components used in the exemplary implementation of FIG. 6. [Figure 18] FIG. 7 shows a schematic diagram of the interaction of components used in the exemplary implementation of FIG. 6. [Figure 19] FIG. 7 is a schematic diagram illustrating the method steps used to generate a key in the exemplary implementation of FIG. 6. [Figure 20] 7 is a schematic diagram illustrating method steps used to exchange data in the exemplary implementation of FIG. 6. [Figure 21] 3 shows a schematic diagram of the device architecture within the system of FIG. 2. [Figure 22] 3 shows a schematic diagram of an architecture middleware used to interact with the secure element in the SIM of FIG. [Diagram 23] FIG. 2 shows a sequence diagram of the steps for signing a transaction according to the method of FIG. 1. [Figure 24] FIG. 23 shows a schematic diagram of method steps within a procedure for signing a transaction using the secure element of the SIM of FIG. [Diagram 25] FIG. 23 shows a schematic diagram of a TLS authentication process using PKI and a SIM in FIG. [Figure 26] FIG. 3 illustrates a schematic diagram of an exemplary implementation of the distributed ledger of FIG. [Figure 27] 2 illustrates an exemplary use case for implementing the method of FIG. 1. [Figure 28] 1 shows a sequence diagram of a portion of a method for matching offers within a data exchange. [Figure 29] 29 shows a sequence diagram of a portion of the method of FIG. 28. [Diagram 30] 3 shows a schematic diagram of a messaging system used within the system of FIG. 2; [Diagram 31] 3 shows a schematic diagram of an example implementation of the system of FIG. 2. [Diagram 32] 31 shows a sequence diagram of method steps used within the messaging system of FIG. 30. [Diagram 33]31 shows a sequence diagram of further method steps used within the messaging system of FIG. 30; [Diagram 34] 2 shows a sequence diagram of an exemplary implementation of the method of FIG. 1; [Diagram 35] FIG. 2 is a schematic diagram illustrating method steps for provisioning a device for use in the method of FIG. 1; [Diagram 36] FIG. 2 is a schematic diagram showing method steps for setting up a device for use in the method of FIG. 1. [Figure 37] FIG. 2 is a schematic diagram showing method steps for setting up a device for use in the method of FIG. 1. [Figure 38] FIG. 38 is a schematic diagram showing method steps for authenticating a user for use with the device of FIGS. 36 and 37. [Figure 39] FIG. 38 is a schematic diagram showing method steps for authenticating a user for use with the device of FIGS. 36 and 37. [Diagram 40] 2 is a schematic diagram illustrating method steps of an exemplary implementation of the method of FIG. 1; [Diagram 41] 2 is a schematic diagram illustrating further method steps of an exemplary implementation of the method of FIG. 1. [Diagram 42] 2 is a schematic diagram illustrating further method steps of an exemplary implementation of the method of FIG. 1. [Diagram 43] 2 is a schematic diagram illustrating further method steps of an exemplary implementation of the method of FIG. 1. [Diagram 44] 3 shows a schematic diagram of an example implementation of the system of FIG. 2. [Diagram 45] FIG. 3 is a schematic diagram illustrating example architectural components of the system of FIG. 2. [Figure 46] FIG. 3 is a schematic diagram illustrating an example implementation of a portion of the system of FIG. 2. [Figure 47] 3 is a schematic diagram illustrating an example implementation of a device in the system of FIG. 2. [Figure 48] FIG. 3 is a schematic diagram illustrating an example implementation of interaction with the system of FIG. 2. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0032] It should be noted that the figures are illustrated for simplicity and are not necessarily drawn to scale, and similar features are given the same reference numbers.

[0033] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The "Internet of Things" is growing and moving towards an "Economy of Things" (EoT). The number of IoT devices is increasing and generating huge amounts of data. IoT devices and smart services offer the possibility to interact and interoperate across ownership domains and automatically support data and smart service value transactions in near real time. This allows for improved interoperability and functionality.

[0034] The "economy of things" requires the ability for devices / services to identify and trust each other and automatically transact value, either directly or using peer-to-peer capabilities as appropriate. 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, but they are fragmented, costly and not sufficiently scalable.

[0035] Various components are used to implement a system and method for securely generating transactions. Figure 1 shows a flow chart of a method 10 for recording transactions in a distributed ledger. Figure 2 shows a high-level schematic diagram of a system 100 for implementing the method. In this exemplary implementation, the distributed ledger is a blockchain (generated by suitable components) 150 and the device 110 is a mobile device such as a smartphone. However, many different devices may be used. Examples of suitable blockchain technologies are described below.

[0036] Symmetric encryption is performed in method 10. In step 20, a secure communication channel is created between device 110 (or SIM 120 in device 110) and a bootstrapping server function (BSF). In step 30, a secret (i.e., a symmetric key) is shared between the BSF and the device. In step 40, this shared secret is stored in the SIM (e.g., in a secure storage location in the SIM). In step 50, a transaction or entry is added to the distributed ledger 150. An identifier for the transaction is generated based on the shared secret, derived from the shared secret, or identifiable using the shared secret. This identifier may, for example, be derived using a particular algorithm or may be indirectly identified using a mapping with the shared secret (e.g., a database).

[0037] GBA (e.g., SIM Trust) may be used to create a secure channel between the device 110 and the IoT backend or server 140. It provides a secure key management solution that can quickly generate, distribute, and update secure keys between devices and application servers. SIM Trust generates symmetric keys (e.g., 256-bit). Customers and other entities can use the symmetric keys in many ways, including:

[0038] Non-repudiation: Proving the source (authentication) and integrity of a message or transaction.

[0039] Confidentiality: Provide end-to-end encryption (not just over the air interface).

[0040] Thus, this mechanism builds a secure channel on the application layer on top of mutual authentication and key agreement between the SIM card 120 and the core network (HLR, Home Location Register). As a result, a distributed ledger technology (DLT) node can use the SIM's identity to interact with the blockchain and verify who the device 110 is.

[0041] Transactions may be added to the distributed ledger 150 directly (i.e., by the device 110 interacting directly with the distributed ledger 150 to add blocks onto the blockchain) or through an intermediary, server, or proxy server 140, which may be described as a digital asset broker, DAB, or DAB service. In this example implementation, the proxy server 140 adds transactions to the blockchain with an identifier that identifies the proxy server 140. The proxy server 140 may then maintain a data store of transactions added against identifiers based on the public keys of one or more devices (although a system may have one or more proxy servers 140), with more devices each associated with one or more proxy servers.

[0042] Thus, an identifier for a transaction on the blockchain may include or be derived from a public key stored on the UICC 120 of the device 110, or may be a transaction identifier that is mapped to an identifier derived from a public key. Deriving the identifier may also use a unique identity of the device 110 or user. This may be, for example, the IMSI. Other derivation schemes may be used. The use of a proxy server 140 may simplify distributed ledger processing such that less identifying information is required.

[0043] FIG. 3 shows a schematic of the high level functionality of the system. UICC (SIM) Role in the system: Provides a secure entry point into the chain of trust (SIM as customer's asset). Throughout this disclosure, the terms SIM and UICC may be used interchangeably, as well as application and applet.

[0044] variant: A Secure Element on the SIM, preferably supporting the GSMA IoT SAFE applet, or · Vodafone SIM Trust based on 3GPP Generic Bootstrapping Architecture (GBA).

[0045] There are different implementations of the system. In one implementation, the SIM or UICC applet generates one or more cryptographic key pairs. In another implementation, the SIM or UICC may be provisioned with cryptographic material. For example, this may use 3GPP GBA. However, any of the example features and implementations or combinations described throughout may be used with either or both implementations.

[0046] device Role in the system: Provides integrator for higher layers (Digital Asset Broker, DAB, Management Core) and harmonizes communication (for SIM or non-SIM devices from different telecommunication networks). Devices can take different forms, for example from simple IoT devices (e.g. utility meters) to vehicles.

[0047] Components DAB Middleware for IoT SAFE applets (as an illustrative example); or A DAB middleware for SIM Trust (an example implementation used in method 10 described with reference to FIG. 1 ); Sensor data extraction for monetizable event detection DAB Management Core Role within the ecosystem: Mediating interactions within the DAB system to use on-chain and off-chain functionality.

[0048] Components Flow Orchestration Engine Common API DAB Management Service Role in the Ecosystem: Simplifying flows and customizing DAB for MVPs (MasterCard, VISA, PayPal).

[0049] Components Customized off-chain processing (off-chain) Customized API DAB Blockchain Services Role in the Ecosystem: Provides a connector to translate DAB interactions into blockchain language.

[0050] Components Ledger of Things DAB Exchange · Blockchain hub including smart contract engine Architectural Building Blocks FIG. 4 illustrates diagrammatically various architectural components of the systems and methods.

[0051] While the IoT SAFE applet implementation (one illustrative example) provides convenience functionality, the use of GBA provisioning (e.g., Vodafone SIM Trust) allows for the use in the system of legacy SIMs that may already be deployed. Thus, the combination of both implementations (which can function simultaneously or separately in the system) allows as many participants as possible to use the system. Device firmware can be updated over the air for legacy devices, and thus the GBA implementation (e.g., SIM Trust) can be used without modifying the UICC or SIM in the device.

[0052] 5 and 6 illustrate at a high level the use of both implementations by the system 100. The mechanisms are independent but interchangeable and may be suitable for different use cases. As well as providing flexibility for new and legacy SIMs, each implementation option has different advantages. For example, banks and public services may prefer to interact with the GBA implementation (e.g., SIM Trust) shown in FIG. 6 since it supports symmetric keys. The SIM Applet implementation (e.g., IoT SAFE) shown in FIG. 5 offers improved blockchain interaction since transactions can be signed directly by the UICC or SIM without the need for an intermediate or proxy server 140. Thus, both mechanisms anticipate each other and meet specific technical requirements.

[0053] At a high level, the main difference between these two mechanisms is in the cryptographic approach: the IoT SAFE applet primarily uses a Secure Element on the SIM to store and manage keys for asymmetric encryption (also known as Public Key Infrastructure, PKI), where public and private key pairs are generated and stored; in the GBA (e.g. SIM Trust) approach, mobile network capabilities are used to establish symmetric encryption between the SIM and the endpoint (e.g. a server such as a DAB server).

[0054] Asymmetric encryption or PKI is a technology used by many IT infrastructures to secure https and other connections between servers using public / private key pairs.

[0055] Figures 7 and 8 show generally how a secure communication channel may be set up between an IoT device and a server using an IoT Safe applet running with the SIM 120. Figure 8 shows in more detail how the device initiates a secure connection with the server.

[0056] The device is pre-provisioned with a client PKI certificate (e.g., in the UICC or SIM). In the example shown in FIG. 9, the device is a vehicle, but it may be mobile or any other device. The client PKI certificate is preferably a public trust certificate procured and signed by a certificate authority. The server holds a similar server certificate. When a communication channel is initiated by the client to the server, an exchange takes place in which both parties authenticate each other using a certificate authority (CA) to verify the legitimacy of the other party.

[0057] The mechanism implemented using a CA utilizes a pair of keys that are used together, one to encrypt and the other to decrypt. Either key can be used to perform the first encryption function, while the other key can be used to perform the decryption operation. Due to the asymmetry of the two different keys performing these functions, this is often referred to as "asymmetric" cryptography. One of these keys is public and the other is private. In a public encryption system, anyone can encrypt a message using the recipient's public key, but only the recipient can decrypt it using their private key.

[0058] Apart from the cryptographic techniques, the IoT SAFE-based solution offers several additional features that facilitate further functionality that can be used in distributed ledger (e.g., blockchain) related environments.

[0059] Symmetric encryption algorithms use the same cryptographic key for both encryption and decryption. The key actually represents a shared secret between two or more parties that can be used to maintain a personal information link. The requirement that both parties have access to the same private key is one of the main drawbacks of symmetric key encryption compared to asymmetric encryption. In the mobile communications space, this solution is facilitated by devices that contain a mobile SIM with a connection to telecommunications network services. Mobile phones have many of the requirements that originally exist in the IoT device space and use standards-based solutions to these problems. These have been developed and vetted over a period of over 20 years and therefore can be trusted by many entities and organizations.

[0060] When the telephone device connects to the mobile cellular network, the telephone device: Authenticating with the mobile network; and Agreeing on a key that can be used to encrypt communications with the mobile network Perform at least two actions, including:

[0061] This is typically accomplished using the standards-based Authentication and Key Agreement (AKA) protocol. The AKA protocol thus creates trust between a mobile device (roaming or otherwise) and the (possibly untrusted) cellular network, so that the two parties can communicate with confidentiality.

[0062] This alternative technology uses the same AKA protocol, formalized as a Generic Bootstrapping Architecture (GBA), for example the Vodafone implementation of SIM Trust, but unlike traditional cellular use cases, trust is created between the device and the application platform under the direct control of the user or customer.

[0063] Figure 13 illustrates this GBA implementation. While the UICC or SIM creates a standard mobile connection to the application server, the AKA protocol is used to create secure communication between the device and the visited mobile network. SIM Trust (using the GBA protocol) adds another layer of trust by repeating the AKA flow to create symmetric encryption between the device and the app server. The result is a mutually authenticated and secure channel for communication between the two endpoints.

[0064] Figure 10 illustrates an exemplary network configuration in which individual devices communicate with nodes in a distributed ledger network. This network configuration may be independent of a particular encryption method (e.g., symmetric or asymmetric encryption may be used). Figure 11 illustrates the configuration of an individual node in a schematic manner. One or more nodes may be present in the network.

[0065] In more detail, Figures 10 and 11 show the following features: A secure applet (e.g., DLT applet) on the SIM (in the device) or on the node securely generates and holds keys. These keys can be wallets, certificates, and / or other modes of representation of digital trust used for secure value exchange (using blockchain). The secure applet may logically be an extension of the Home Subscriber Server (HSS) hardware secure module (an existing network element deep inside the carrier or operator's core network). The HSS relationship with the secure applet on the SIM may be managed by another existing network element (e.g., an over-the-air OTA server), which may be the machine used to create a secure communication channel directly with the SIM. The Telco node plays the role of a DLT notary that operates in management with the decentralized authority of each DAB node, for example to create and manage the certificates required to manage the lifecycle of secure application delivery, update, authorization, and decommissioning activities.

[0066] The telco nodes also act as CAs (certification authorities) for services offered by the system (e.g. DLT Secure services). When the enhanced security of the HSS is extended to the SIM via DLT Secure services, DAB DLT uses the SIM and stored keys to create a new consensus protocol ("Proof of Secure SIM"), where the SIM is asked to prove its validity on the system (DAB) at the time of each transaction, without requiring expensive and high-processing proof-of-work / stake type processing across the network. This makes each DAB node lightweight and limits the computational requirements of the SIM (as PUB / PRV keys can be generated asynchronously and provided to DAB DLT for validation at the time of transaction initiation).

[0067] A device owner or other entity can program or define smart contracts or other terms to allow disparate devices from different systems to interact with each other using a common root of trust (i.e., SIM and secure applet or GBA-enabled device). This provides the mechanisms and protocols that allow devices to interact. This can be done at scale with multiple devices (and their SIMs) interacting with one or more nodes. The protocol allows devices to exchange tokens for tokens and further exchange tokens for data, use cases that have traditionally been solved using APIs. Furthermore, devices thus enabled (DAB devices) may autonomously exchange tokens in their one or more wallets for value ranging from actions (e.g., access control) to data streams (e.g., device location), and secondary "parent" nodes can recharge these wallets, for example, to manage and track service consumption. The system provides for micropayment and microbilling systems, as well as request / send / settle value exchanges that can be coupled with credit / debit on a decentralized ledger.

[0068] The following describes the steps taken when operating the exemplary network configuration of Figure 10. The numbers below correspond to those shown in Figure 12, which indicate the method steps occurring between the different components. Again, any encryption scheme (symmetric or asymmetric) may be used.

[0069] 0. Background: A and B are registered in the DAB NW and are authorized to exchange value with each other.

[0070] 1. The owners of A and B agree to a smart contract (i.e. "if you give me data X, I'll give you Y tokens").

[0071] 2.B requests data from A based on a given smart contract (C). 3.B’s request is signed with DLT Secure B and verified by Dapp C (Proof of Secure SIM).

[0072] 4. A “Buy” transaction is published on behalf of B on the DAB DLT network.

[0073] 5. A downloads the applicable requests for transaction decisions. 6. DLT Secure A verifies request (4).

[0074] 7. Device A signals to the DAB DLT that it wants to "sell". 8. Device A receives and packages data A from sensor A.

[0075] 9. DLT Secure A signs package A. 10.A acknowledges the exchange on the DLT call on smart contract C to be invoked.

[0076] 11.A sends package A to B (either on-chain or off-chain).

[0077] 12.DLT Secure B updates the DLT, DLT record and initiates the payment using smart contract C.

[0078] 13. Device B satisfies C. 14. Device A acknowledges receipt of the token.

[0079] 15. DLT verifies C closure. 16. Device B analyzes package A and decides to perform action A.

[0080] The next two sections provide more details on how the two implementations work.

[0081] The UICC applet implementation uses a secure element within the UICC (e.g., SIM). The SIM acts as a hardware wallet that protects cryptographic keys and communications. This implementation allows the SIM to provide a root of trust for IoT devices, for easy and efficient implementation of critical security features. The SIM can securely store transaction signing keys and perform crypto-asset transaction signing safely within a secure environment.

[0082] Figure 14 shows a schematic diagram of the SIM and OTA server architectural design. The SIM may be equipped with the GSMA IoT SAFE applet. In addition to holding the SIM crypto wallet for transaction signing, this allows for a mutually authenticated TLS connection bound to the SIM hardware root of trust as defined in the GSMA specification https: / / www.gsma.com / iot / wp-content / uploads / 2019 / 12 / IoT.05-v1-IoT-Security-Applet-Interface-Description.pdf.

[0083] GSMA IoT SAFE-based solutions provide chip-to-cloud security for IoT deployments. Using a hardware Secure Element, or "Root of Trust", IoT SAFE-based solutions provide end-to-end security. The use of GSMA standardized Secure Elements and IoT SAFE applets further ensures interoperability between different companies and consistent usage by IoT device manufacturers.

[0084] For communication between the IoT SAFE applet located on the SIM and the outside world (e.g., proxy servers, blockchain, etc.), a cryptographic middleware library also runs within the device, but not necessarily within the SIM.

[0085] In this implementation, standard authentication mechanisms occur between the SIM and the device, and between the SIM and an over-the-air (OTA) server. These mechanisms may also include a secure element on the SIM. This is coupled with basic mechanisms for unlocking applications and / or the SIM (e.g., by using PIN protection), SIM locking mechanisms, mutual authentication between the SIM and device applications, etc. Blockchain transactions are verified by blockchain nodes using a protocol that includes digital signatures sent as part of the transaction.

[0086] Universal Smart SIM Wallet Through the use of the IoT SAFE applet, the SIM provides access to one or more key containers or storage within the SIM's secure element. These containers may be used for different use cases or may be used to provide multiple identities for the same use case or operation. Figure 15 illustrates the storage of multiple identities within the SIM diagrammatically. Each identity can be used as a SIM wallet allowing users to authenticate and sign transactions within different applications. This is not limited to blockchain, but can also be used within off-chain mechanisms such as traditional payment rails (e.g., direct communication with other devices or businesses). The over-the-air (OTA) update capabilities of the SIM allow for the addition of new containers and key management functions for use in a particular implementation.

[0087] The SIM can be personalized with additional key containers for signing keys for different blockchain networks. In the preferred implementation, the SIM has three key containers available by default: two containers hold SECP256 K1 ECDSA key pairs and one container holds SECP256 R1 ECDSA key pairs. However, different key pair types may be used in any combination.

[0088] Considering an end-to-end solution, a SIM crypto wallet in an IoT (or other) device using the SIM as a hardware root of trust may provide any or all of the following features:

[0089] Hardware wallets (signing payment / digital asset sending transactions) · Validation of signed transactions Secure communication · Secure storage of sensitive data Thus, the SIM itself may provide any or all of the following functions:

[0090] Additional encryption features IoT device ID metadata storage Secure backup / restore, key management Device start bootstrap The use of a cryptographic key vault within the SIM keeps private keys and secrets tamper-proof and secure. The SIM is typically tamper-proof hardware with a dedicated crypto-processor and a highly secure SIM OS, providing the necessary level of assurance to keep private keys secure. Keys stored in this way on the SIM are generated on the SIM and preferably never leave the SIM.

[0091] Table 1 summarizes the list of preferred cryptographic algorithms used. Other algorithms may also be used.

[0092] [Table 1]

[0093] Blockchain and cryptocurrency networks typically rely on asymmetric cryptography because their transactions are peer-to-peer or within a group of participants. The list of participants between different transactions may differ. Given this peer-to-peer nature of blockchain transactions, the use of symmetric cryptography may not be feasible. Furthermore, the use of asymmetric cryptography allows blockchain and DLT transactions to be auditable by a third party. The use of PKI within the current system makes it possible for an entity or person to verify transactions without having access to the private key.

[0094] EMV Tokens EMV is an abbreviation for Eurocard (RTM), MasterCard (RTM), Visa (RTM) and represents a defined specification for payment applications, implemented in most bank card chips today. It works with symmetric cryptography by accessing authentication information securely stored on the bank card chip. In the current environment, EMV can be used to sign payment transactions and send them to existing payment rails to enable the transaction. Thus, the SIM wallet is used to hold (symmetric) key values ​​for the payment application, which are then used by the device middleware to facilitate EMV payments through the system.

[0095] In this extended or optional feature (used with any of the implementations described), it offers users the option to choose to pay using blockchain or existing payment rails via EMV. From a security perspective, SIM cards can already pass the authentication of bank cards.

[0096] Wallet within wallets The SIM is used to provide keys associated with the desired payment method. The wallets used for payments do not themselves need to be stored in the SIM (but may be). Wallets used to directly interact with the distributed ledger may be provided by a separate entity, a server or proxy server, or a broker (e.g., DAB), and may be selected based on payment method preferences depending on the particular use case.

[0097] The third party document may be deployed over the SIM air (OTA). The wallet application on the device interacts securely with the SIM portion of the application (applet) and establishes a binding (also via OTA), subject to the security and authentication processes of the security domain, as well as approval for integration with the external application.

[0098] key management Well-defined mechanisms may be implemented to manage the lifecycle of keys used in transaction management. Cryptographic key lifecycle management includes key backup, restoration, key revocation and renewal, and security policies may be implemented to handle lost, stolen, and / or compromised devices. Private keys are the most sensitive asset and are not backed up in the clear or in an unsecured environment. There are several different mechanisms used for backup and restoration of blockchain transaction signing keys.

[0099] For example, Bitcoin defines deterministic key generation based on a human-readable sequence of words to generate a seed and generate a key pair using the seed based on the BIP39 / BIP32 specifications. BIP39 implementations specify that keys are derived from a mnemonic that can be memorized and re-entered to recover the key. BIP32 defines hierarchical deterministic wallets that derive keys based on a seed and index value. Such mechanisms can be used in the present system and are shown diagrammatically in FIG. 16.

[0100] In another example implementation, the SIM backup vault service transparently backs up components or portions of the private key on other SIMs so that no single SIM has the complete value. Restoring the key can be a coordinated effort that involves collecting components of the backed-up value (k out of N) from a cluster of SIMs used in the backup process.

[0101] In a further exemplary implementation, a blockchain smart contract based solution reduces the complexity of the backup and restore process. For example, a smart contract account holds digital assets similar to an escrow mechanism until specified conditions are met. The accounts associated with IoT devices only handle micropayments and do not hold digital value or cryptocurrency on their own. The smart contract accounts can define rules for resolving scenarios where some devices are faulty, for example, and how to send accounts to other devices.

[0102] Generic Bootstrapping Architecture (GBA) The Vodafone SIM Trust Architecture is based on a technical specification (3GPP TS 33 220) also known as the Generic Bootstrapping Architecture (GBA). Similar to certificates, GBA is used to establish trust between parties. Certificates, on the other hand, rely on asymmetric cryptography to create different key pairs that can be used in conjunction with each other to support cryptographic functions. GBA provides the ability to use a hardware-based Trusted Execution Environment (TEE) to store symmetric keys and to use these symmetric keys to derive ephemeral keys that can be used to support at least three functions: authentication, confidentiality, and integrity protection. Further details on the GBA standard can be found in ETSI Technical Specification TS 33.221 V14.0 (2017-05).

[0103] In an IoT environment, the GBA TEE is provisioned with a SIM, which is used to store credentials to support authentication key derivation and key agreement functions.

[0104] Symmetric encryption has the disadvantage that a key must be distributed and shared between all parties that need to communicate with each other. This is called the key distribution problem. The telecommunications industry relies on symmetric encryption where the key is distributed during the SIM manufacturing process and the symmetric key is stored in two places:

[0105] 1. A Subscriber Identity Module (SIM), which is a hardware token device stored in a User Equipment (UE), which can be a mobile phone or an IoT device; and 2. Located in the center of the operator core network on the Authentication Center (AuC) and accessed via the Home Location Register (HLR).

[0106] The security of this distribution process relies on the secure processes followed by SIM manufacturers and mobile operators in managing this key material.

[0107] However, many entities are known to target the processes and people involved in the distribution of this key material. Industries that rely on SIMs to protect their assets have combated this problem of key distribution attacks by using rigorous security processes and vendor selection. However, this can be costly.

[0108] Communication Flow The SIM card is used as a root of trust to derive a shared key that can be used to achieve end-to-end authentication and encryption at scale at the application layer. In general, this process relies on the 3G AKA process (AKA = Authentication and Key Agreement). The AKA process is used when any mobile device connects to a mobile network (>2G) and performs mutual authentication and key agreement. Figures 17 and 18 show at a high level the communication flow used for the GBA's SIM Trust implementation.

[0109] Establishing a secure channel between a device and a back-end application consists of two steps: generating a key and exchanging data over the secure channel using the key.

[0110] The Key Generation Process The key generation process is shown diagrammatically in Figure 19. The SIM interacts with a device API in the device, which obtains a symmetric key from a SIM Trust Server in communication with the core network. The device communicates with the SIM Trust Server over http to derive a shared secret in the form of a symmetric key. This symmetric key is authenticated and stored in the SIM.

[0111] The keys are used to exchange data over a secure channel. Once a shared secret (symmetric key) has been derived, it can be used to protect a channel for communicating data. This is shown diagrammatically in FIG.

[0112] The communication flow through each network entity is described below. A Device Management (DM) client queries a Generic Authentication Architecture (GAA) server for a key.

[0113] The GAA server establishes the identity of the SIM (AT+CSIM). Meanwhile, the GAA server notifies the DM client to wait.

[0114] The DM client can handle other tasks while it waits. The GAA server uses the identity to ask UbProxy for an authentication vector.

[0115] UbProxy validates the request and routes it to the correct Bootstrapping Server Function (BSF).

[0116] BSF will request AV from HLR. The HLR returns the AV to the BSF.

[0117] BSF stores the credentials and returns a version of the vector to UbProxy with a 401 code.

[0118] UbProxy returns the same message and error code to the GAA server. This requires authentication from the SIM.

[0119] The valid response (DB at start-up) allows the valid response to be extracted and sent to the UbProxy.

[0120] It then transmits it to the BSF. It verifies the response contained in the message against the one previously received from the HLR and sends a 200 response.

[0121] UbProxy returns a 200 response to the GAA server. The GAA server calculates the key and returns it to the DM client.

[0122] The DM client uses the key as needed to pass the identity to the server. When the DM server needs a key, it queries the UbProxy via the NAF using the ID.

[0123] The UbProxy sends a key request to the appropriate BSF. It computes the key and returns it.

[0124] UbProxy returns the key to the DM server. The DM server uses the keys as needed.

[0125] Starting from SIM Trust (e.g. from Vodafone), the middleware on the device side enables the device to send messages between the SIM in the network and the SIM Trust Platform (Bootstrapping Server Function, BSF). The device supports the SIM Trust Device Library and has a Dedicated Software Library (DDK). On the backend side, the application gets the shared key from the SIM Trust Platform using an Application Processing Interface (API) call via the API Hub.

[0126] A particular Global Data Service Platform (GSDP) may enable GBA (e.g., SIM Trust) for a particular SIM card or IMSI range.

[0127] device General Purpose Architecture To use the device as an integrator layer between SIM and DAB, four exemplarily interconnected components can be provided.

[0128] SIM-centric: The SIM card (containing a secure element and a hardware component that stores cryptographic keys and can authenticate and sign transactions and data).

[0129] Libraries provided by the SIM manufacturer: A set of libraries that expose the functionality of the SIM for use by connected applications (e.g., the cryptographic middleware described).

[0130] Middleware: A middleware component that exposes infrastructure functionality of the SIM applet for applications that cannot directly incorporate the SIM manufacturer's libraries or for applications and devices that run outside the device (e.g., data collection networks).

[0131] Event Detection: Applications / algorithms that detect and transact events either with the rest of the DAB service or directly with the blockchain and marketplaces and / or exchanges.

[0132] These components are shown diagrammatically in FIG. Together with the use of this service and existing capabilities such as GDSP (Vodafone's Global Data Services Platform for managed IoT connectivity), SIM Trust, or IoT SAFE, the devices can be seen as edge integration points acting as blockchain wallets and trusted authenticators. They also open up the ability to provide secure autonomous events or be used as simple Hardware Secure Modules (HSMs).

[0133] The middleware enables devices to seamlessly participate in the transaction ecosystem, allowing applications to incorporate manufacturer libraries and consume SIM capabilities for key provisioning and transaction signing. Applications running outside of the connected device can also take advantage of these capabilities and access the middleware through its API.

[0134] The devices process or collect data, ranging from direct reading to computational analysis (e.g. cargo occupancy assessment), which, once encrypted (with PKI in the case of the SIM) and signed with the SIM card's private key, can be tokenized onto a blockchain of your choice or stored elsewhere within the platform for cross-vertical use.

[0135] Middleware for secure elements on SIM cards A typical IoT deployment, such as that shown in Figure 22, can directly benefit from GSMA IoT SAFE, which provides secure transmission of sensitive data and device authentication. Nevertheless, the above mentioned middleware on the device is required to facilitate communication between the SIM applet and the application side.

[0136] architecture The middleware for the Secure Element on the SIM abstracts heterogeneous applet management through modular applications and enables the integration of devices with the Digital Asset Broker (DAB) service platform. It provides a single unified RESTful API (SIM Service API) for applet management, regardless of manufacturer.

[0137] To expose SIM capabilities to the device, the crypto middleware library provides and interfaces with an applet execution platform. The library may include OS-level C libraries and / or framework-enabled modules for Java, Android, or Swift, providing methods for managing the applets themselves (deploying, deleting, updating, etc.) as well as the operations made available by each. An overview of the DAB middleware components is shown in Figure 22.

[0138] The SIM Service API is a set of base endpoints that expose the uniform behaviors mentioned above, and for each received request, the cryptographic core is responsible for orchestrating the steps necessary to interact with third-party vendor integration options, be they external or embedded Java libraries for example. Each of these comes with its own logic flow for applet management and utilization, so that the individual adapter components can be interfaced by the DAB middleware provider commons layer. This allows the behaviors provided by different manufacturers to be utilized.

[0139] implementation In an example implementation, two device configurations are provided that are aligned with an IoT SAFE applet running within the secure element of the SIM card.

[0140] 1. A DAB application running on a mobile phone has direct access to its SIM card via built-in Android libraries to sign and verify data sets as instructed by the DAB service.

[0141] The 2.4G connected automotive M2M router (for testing, simulated using a RaspberryPi and a Vodafone USB Connect 4G v2 dongle, but other suitable hardware may be used) contains a SIM but exposes its encryption capabilities to other applications via the DAB middleware.

[0142] The implemented DAB middleware uses the following exemplary techniques: Spring Boot; OpenAPI; Java Native Interface(JNI);and iot-safe-middleware. Other technologies may also be used.

[0143] In one exemplary implementation, Java Spring Boot covers a large number of possible integration scenarios with manufacturer libraries. This also opens the possibility of including it in several types of devices, including smart devices or IoT gateways, as long as they can run a JVM. For low-end devices, where CPU and memory may be constrained, using a JVM is not the most efficient implementation, but it abstracts the hardware differences.

[0144] This is a technique to provide easier integration of the integration method, which can be split into configurable modules that can be extended for each library provided, either by directly importing the code modules or by interacting with OS-level libraries (e.g., if a C library provided by a SIM manufacturer needs to be interfaced via a JNI external function interface). This may be instantiated as a standalone application running on the same device connected to the communication unit, or may be embedded in the event detection software (e.g., if Java-based).

[0145] Four example SIM service operations can be defined regarding the cryptographic capabilities made available by the IoT SAFE applet installed on the SIM. These operations mirror very similar signatures of the API methods made available by the Thales crypto middleware C++ library (see also https: / / github.com / ThalesGroup / iot-safe-middleware). The crypto middleware library provided by Thales can be used in two ways or compilations on its own: as a Java Android library for direct applet communication from within a regular Android app, or as a C++ build suited to the middleware approach described above.

[0146] DAB Middleware API In an exemplary implementation, SIM service operations related to cryptographic capabilities made available by an IoT SAFE applet installed on the SIM are invoked by applications in response to the need to obtain a public key or sign a message. They all follow a "container" based approach (a "container" is a secure memory space that holds a client certificate and key pair, respectively), and each deployed DAB use case can know which key type or digital signature algorithm it requires. It can therefore also know which parameters / containers to use when invoking the DAB middleware.

[0147] In one example, the API can be briefly summarized as follows: / container: Lists information about the SIM's containers, / certificate:Get the client certificate for a specific container, / publickey: Read the public key of a specific client certificate / container, and / sign: Sign the message using a specific client certificate / container.

[0148] This business logic is shown in Figure 23. application Transaction Signing with SIM Wallets Blockchains, cryptocurrency networks, and other micropayment solutions rely on the ability of nodes to sign transactions. Due to this peer-to-peer nature of these transactions, it is important that nodes can prove that they participated in a transaction to ensure it cannot be repudiated. It is therefore important to keep the private keys associated with blockchain addresses in a secure location, ideally a tamper-proof cryptographic module.

[0149] Transactions prepared by the DAB middleware are signed using a private key stored securely in the SIM, an example of which is shown diagrammatically in Figure 24.

[0150] TLS Authentication The client key and server root certificate securely stored in the SIM (e.g., IoT SAFE SIM) can be used not only to support the DAB blockchain application, but also to perform mutually authenticated TLS sessions between the device and services running in the cloud. This is shown diagrammatically in Figure 25.

[0151] The DAB middleware can also deliver control over key generation, wallet management, and management (installation, removal, etc.) of applets installed on the SIM. This may involve exposing control over the IoT SAFE applet, for example, to generate new key pairs or modify the digital signature algorithm.

[0152] Due to the diversity of SIM and device manufacturers, the DAB middleware is available as a software development kit (SDK) for multiple languages ​​and operating systems, allowing OEMs to smoothly incorporate it into their own devices. Given its Java-based nature, another option involves porting it to Java Card technology and delivering a single application that can be pre-installed on all SIMs for out-of-the-box DAB accessibility.

[0153] The SIM Service API is available in the DAB API inventory for direct device management by application accelerators or third party applications connected to the DAB platform (where permitted). Preferably, this can be consumed by each DAB Service instance to control the device it is transacting with for its own use case.

[0154] Sensor Data Extraction for Event Detection In an example implementation, an IoT deployment may use devices as end nodes that may have a variety of functions. These may include:

[0155] Directly forward the sensor data to a higher layer (cloud or server), or It communicates with a gateway that performs the same function.

[0156] The sensor data may originate within the device, for example. Smart devices and secure elements are becoming more and more prevalent, and the ability to extract knowledge or generate actions based on the resulting data is becoming key to IoT autonomy. The ability to authenticate datasets,applications running detection algorithms can directly incorporate compatible libraries to access SIM encryption applets, or use DAB middleware to sign information with a selectable private key, resulting in immutable datasets.

[0157] The DAB device may also act as a control point for deploying device-side functions that can function in DAB-driven use cases (e.g., detection algorithm deployment, wallet management, etc.) The DAB-driven device may be accessible to DAB services to manage their detection software and SIM applets.

[0158] DAB Framework In an exemplary implementation, the DAB service is an instantiated component of the DAB stack and serves as the transaction and authentication platform for the DAB ecosystem. It provides the ability for IoT devices to transact value for services / data and handles connectivity between mobile IoT devices, multiple types of blockchain technologies, and any third-party external systems. To this end, the DAB service can provide REST-based APIs for the setup of use case orchestration, for transaction committals, digital identity management, and third-party service access.

[0159] Preferably, the system uses the Java Spring Boot framework, which allows for modularity that allows it to run on most on-premise or cloud-based machines. It is also a flexible environment for interconnecting different kinds of software and hardware applications, even libraries, drivers, and communication stacks. However, other frameworks may be used.

[0160] In an exemplary implementation, the DAB service may use the following techniques: Spring Boot, Web3J, OpenAPI, Firebase Java SDK, Spring Quartz, Liquibase, Failsafe SDK, JJWT lib, Paho MQTT, PostgreSQL 10, and / or Spring Reactor.

[0161] Roles in the ecosystem The DAB Service is an engine for the ecosystem, managing devices, use cases, flows and entities. In addition to all functionality exposed through APIs, the DAB Service integrates external systems from third-party marketplaces, other telecommunication components or additional blockchain networks.

[0162] In addition to connecting to the network, devices are managed and accessed, and the DAB service is used to connect, manage, authenticate, and certify devices. If an external entity (e.g., a company) wants to participate in the ecosystem, it may use the DAB service "as a service." If another entity wants to gain more control around the devices, an instance of the DAB service can be deployed for specific use on their own device and control their own part of the ecosystem.

[0163] IoT devices can act as sensors or low-energy devices with low computational power. Also, devices do not need to connect every time and do not necessarily need to be permanently connected to a distributed ledger (e.g., blockchain) or other type of network. To reduce the computational load on the devices, the DAB service can act as a proxy (or proxy server) to connect the devices with any kind of network. This relieves the burden of processing data from the devices and allows less powerful devices to be part of the ecosystem.

[0164] DAB Management Core The DAB Management Core serves as the main communication layer between all parties, consisting of the Flow Orchestration Engine and API components. The Flow Orchestration Engine consists of three components, each of which is accessible through an API:

[0165] Flow Orchestration Engine The Provisioning Engine handles both the setup and management of the use cases instantiated in each DAB Service instance and is responsible for abstracting the link-up of use cases with specific implementations or technologies. Additionally, the Provisioning Engine handles the configuration of these technologies and third-party services. It delivers the access layer for the management of devices participating in the DAB stack for deploying algorithms and key management (through the SIM Service API). The following functions are handled by this component:

[0166] Business Rules: A set of rules that define the interactions each device can have with a particular network or marketplace / exchange.

[0167] Use Case Management: Managing (create / edit / delete) the available use cases for each DAB instance. Also responsible for provisioning devices with the available use cases they can trigger.

[0168] Connectivity: Integration with other platforms such as GDSPs for SIM management, location services, etc.

[0169] Algorithms: Management, cataloging and deployment of algorithms to DAB powered devices leveraging the SIM Services API. This capability provides a high level of customization and possibilities on devices that are preferably upgraded over the air, so that the devices can discover new events based on their own data without losing data.

[0170] Authentication Engine The Authentication Engine is responsible for handling all the digital identity logic for connected devices and created smart services. Entities ranging from devices to partners or services have a digital identity that can be used to pair and connect businesses (manage what is accessible to each other at a given time). This engine therefore provides the ability to create IoT device entities within the network of external backends and authenticate them against their respective registries. The Authentication Engine therefore unambiguously asserts identity across the DAB ecosystem, preferably by unique identifier. Devices that hold provisioned keys and provide context regarding identity and transaction authenticity can be authorized to plug in and provide verified provable provenance to data.

[0171] Transaction Engine Depending on the use case, different functionalities can be activated, and this customization is an added benefit of the DAB platform. Authenticating the device in this way ensures that received transactions are encrypted and signed from a trusted device, i.e. via the private key of the SIM card, ensuring provenance and identity. Thus, transactions can be immediately executed on multiple marketplaces / exchanges (each typically focused on a specific domain).

[0172] Thus, the transaction engine may be responsible for handling the logic that tends to process the device transactions and API calls received. This may involve redirecting information across the DAB service layers and making inter-component requests. For example, this may include accessing databases, external systems, or blockchain integrations. Upon receiving a candidate event, the DAB service may decide which use case to apply depending on more than just the data contained, and may check the algorithms selected on the device or insights generated on those data.

[0173] If a transaction requires "long" processing or a marketplace-type offer / demand matching procedure, the transaction engine provides an interface to an off-chain processing component of the DAB managed service that provides services to run special algorithms within a secure CPU enclave. This may involve the DAB service or a service controlled by a third party.

[0174] The Transaction Engine provides an ingress endpoint where datasets enter the DAB stack: they may be delivered by synchronous HTTP POST to DAB (or other communication protocols), where they are parsed and routed to applicable use cases, initiating the associated (composed) orchestrated flows.

[0175] A typical value exchange process can follow three steps that are applicable to most use cases and show how the use case implementation is approached:

[0176] The received message triggers the initiation of a value exchange process. For example, this may be a transaction sent by a DAB-powered device (see Transaction Engine) or a specific message received on a custom API deployed by the DAB service for consumption by third parties.

[0177] The identity of the producer is verified and an activated use case is identified, which generates a resulting action, such as deploying a transaction to the blockchain or delivering a message or signal to an external system or DAB device.

[0178] The application can cover several types of use cases beyond simple token transfer, such as the notion of session recording and data set matching that arise as viable practical applications for commercial use. In order to generalize the many types of data that can be transacted, the transaction engine can implement the outlined API message format to be as general as possible so as to include all the information necessary to indicate which use case flow to activate.

[0179] In an exemplary implementation, an exemplary JSON code is shown below: Message properties can indicate:

[0180] transactionId - a UUID generated by the device and unique for each message, usecaseType - Must unambiguously identify both the blockchain technology used and the mode of operation of the use case (e.g., Ethereum, session-based, etc.), transactionType - used in all use cases, but limited to the keywords required to describe each step of that mode of operation (e.g., start session, open session, payment), fromDevice-SSID - a globally unique identification code for each SIM - used for device identification, creationDate - timestamp generated by the device, transactionObject - contains the data to be inserted into the blockchain (blockchainObject), along with a "locationObject" property that carries the GPS data sent by the device indicating its current location. dataType - Used to indicate the type of data being inserted into the blockchain (the data contained within the "blockchainObject"). This can be used to differentiate its JSON format.

[0181] { “transactionId”:“{{v4uuid}}”, “transactionType”:“newdata”, “fromDevice”:“8981300999090900006F”, “creationDate”:“2020-04-27T17:32:47.020154Z”, “useCaseType”:“service”, “dataType”:“generaldata”, "transactionObject":{ “blockchainObject”:“{\“borrower\”:\“Daimler\”,…}”, “locationObject”:“{\“location_data\”:{\“lat\”:51…}}”} } Supporting features such as data persistence services The Data Persistence Service handles all the database connectivity required by the DAB Service to store information describing use case orchestration, device configurations, device service related data, and dataset hashes, which may be used especially when timing is critical.

[0182] The functionality of the DAB Management Core may be supported by a Platform GUI, which may be implemented by INVENT, but may also use other technologies.

[0183] Common API A flow orchestration engine may require a common API set of core functionality to provide suitable endpoints for building and managing use cases, authorizations and transactions.

[0184] DAB Management Service The DAB Management Service Function serves as a place where customized data processing related to a specific industry vertical or use case can be implemented. It may be independent of the DAB Management Core and may have its own API that can be defined and developed whenever the need arises to integrate third-party services for DAB interaction. To improve scalability, the core elements may be independent of the customized elements.

[0185] Customized off-chain processing If the transaction requires reconciliation processing (e.g., trucking capacity) or for micropayment aggregation (e.g., toll collection services), the algorithms can run in Python and Software Guard Extensions (SGX) enclaves.

[0186] Customized API Endpoints exposed by DAB services can be organized into this component if a use case requires specific integration to be triggered by an external system. These use cases generally rely on data already present in the DAB stack, such as querying DAB for the identity of a digital device, requesting a signature, or triggering a blockchain transaction. These bespoke control points can go beyond REST and be made available with any other technology supported by Java, such as SOAP, MQTT, etc.

[0187] DAB Blockchain Services Ledger of things The Thing Ledger provides the ability to create, maintain, and use digital identities, for example based on the Corda network (other distributed ledger technologies may be used). This is then consumed by the DAB Management Core for authentication and transaction signing. Bulk provisioning of devices on the Thing Ledger allows enterprises to easily and simultaneously create digital twins of many devices. The DAB Exchange includes event detection, a key differentiator, to automatically map devices and use cases to each other.

[0188] Blockchain Hub and Smart Contract Engine Blockchain Hub The Blockchain Hub manages the different integration mechanisms chosen by the blockchain implementation and provides the interconnection capabilities to the DAB Core Services. These mechanisms may range from the use of built-in Java libraries to system-level interactions with external applications that run alongside the DAB Services themselves. The layers therefore provide different classes that separate all the logic required for their use by technology or partner. When building a use case (through the provisioning engine), the programmer expects to easily select one of these connectors, configure it to use a specific node, server or credentials, and be provided with a simple way for transaction management.

[0189] Different types of distributed ledgers may be used. For example, three different blockchains may be used:

[0190] In the Corda network, transactions are made via a RESTful API with several nodes in the DLT network. While it is possible to use RPC connectors, the RESTful API offers low friction and easy integration.

[0191] In the iExec network, a continuous set of operating system processes run, issuing an ordered set of commands (as described in the partner documentation) to a NodeJS client (the iExec SDK) installed alongside the DAB instance, which synchronously executes and returns textual JSON output that must be processed and interpreted by DAB.

[0192] EWF has built a system that uses the Ethereum blockchain as a data marketplace, but considers that device participation is limited to dumb devices that only receive MQTT messages. Therefore, to integrate their EWF into the DAB service, an MQTT client / connector manages all EWF flows for all devices that the DAB service allows.

[0193] Considering the complexity of existing blockchain implementations, further connectors based on libraries such as Geth and Web3 can be integrated to enhance fine-grained connectivity options.

[0194] Example Use Cases Use case: "Payment for a service" This use case shows how a token exchange can be used to use and pay for services like parking or tolling (cars). R3 Corda technology implements a Token SDK framework to create one-time token / payment transactions. The five nodes in the network include one notary acting as an authority node, two nodes for services, and two nodes for consumers. Each node on the R3 Corda blockchain represents a main entity, such as a service company (e.g., parking, tolling company or EV charging provider), and a consumer company, such as a car company. Each device can trigger transactions, but their identity is not necessarily mirrored on the blockchain itself, but may be represented on the triggering smart contract. This is shown diagrammatically in Figure 26.

[0195] In terms of smart contracts (flows on Corda), there is a main flow for creating and recording transactions made by each device of each entity, in addition to all the flows for managing the network (including browsing all transactions, gathering information or performing calculations). CoinTokenTypeContract represents a CreateEvolvableTokenFlow object. When triggering that flow, there are some required fields such as the identity of the device that is initiating the flow, and the entity represents that device that is the consumer of the service. The API manages and triggers transactions on the network and integrates them with external portals and applications.

[0196] The network can be deployed in an AWS (or other) environment, separated by entities with a defined structure based on access and network available ports and APIs. Each node has its own web server that provides its own API and can operate independently from the rest of the available network.

[0197] The integration of the functionality is done within a smartphone or other device (e.g., an Android phone). The platform can monitor the network and trigger actions manually. The solution uses REST and SSH to interface with the R3 Corda instance directly on the node, providing managed functionality such as monitoring network transactions, triggering new transactions, and controlling the node via Node-CLI. The following image shows the functionality in detail:

[0198] In the automotive scenario, payment for services can be achieved automatically by using the R3 Corda blockchain capabilities.

[0199] Interfaces / Dependencies Various interfaces allow for control and triggering of transactions on the nodes via a RESTful (or other) API. Other interfaces may also be used, including RPC and SSH (see Figure 26).

[0200] The following provides a list of example APIs that may be used along with a description of their functionality. These APIs may be used internally or may be accessed by external entities.

[0201] Name Description getMe Gets information about who a node is.

[0202] getPeers Gets information about other nodes on the network. getNetworkMap Gets the network map of the connection.

[0203] getNetworkFeed Gets the network feed of the transaction.

[0204] getNetworkParameters Gets the network implementation parameters.

[0205] getRegisteredFlows Gets the list of executable flows for that node.

[0206] getTransactionsID Gets a list of transaction IDs in which the node was involved.

[0207] getTransactionsInfoByID Get transaction information by ID.

[0208] getNumberOfTransactions Gets the number of transactions in the network.

[0209] getTransactionsInvolved Gets a list of transaction information in which the node was involved.

[0210] getNumberOfTransactionsInvolved Gets the number of transactions in which the node was involved.

[0211] getNodeInfo Gets information about the node itself. getNodeTime Gets the current time of the node.

[0212] getTransactions Gets a list of all transaction information.

[0213] getVodacoins Gets the "Vodacoins" balance number. postCreateTx Creates a transaction on the network. Described in the Business Logic section. For each node in a distributed ledger (e.g., a blockchain network), the API can be replicated and the same types of flows can be executed to interact with the rest of the network.

[0214] Business Logic Since interactions with DLTs (e.g., Corda) are done through a set of established REST endpoints and SSH connections, the DAB Blockchain Service Connector orchestrates the call flows required to insert and retrieve data from the ledger. To trigger these scenarios, a collection of user layouts within the DAB app constructs transactions according to message formats described in the public layer.

[0215] For this feature, service payment scenarios (useCaseType "service") only require the "newdata" transaction type. It is possible to manually trigger some use cases and scenarios using an application (DAB app), for example.

[0216] For payment of services like congestion charging, one-time parking, or any other service, the user selects the menu entry "New monetizable data" on the DAB app, the tab "Services" and fills in the fields.

[0217] Borrower - the party wishing to transfer the token / value (service provider) Value - number of tokens type: MIN - duration amount (e.g., minutes) CC - Congestion charge in monetary value Payment - any other payment in monetary value Subvalue - A numeric value that corresponds to the selected payment type (e.g. 3min, 3Euro, 3BorderCoin) VIN - Vehicle Vin Slot ID - an optional field that can be used to specify, for example, a parking slot or a toll booth Location - an optional field that can be used to specify, for example, a congestion area entrance point or a parking location. ICCID - SIM card ICCID or UICC This can be converted to a JSON object.

[0218] Automatic triggers and integrations (e.g., car integration) provide improved direct interaction with the blockchain. Additionally, settlements between network parties can be facilitated. The blockchain can register every transaction made between consumers or parties, so services can transact on the same network while settlements are made between them. Smart contracts / flows can determine specific debts and automatically send funds from one party to another. Alternatively, external billing systems can aggregate every single transaction present on the network.

[0219] Use case: "Event-driven fleets" This use case can be used directly to generate data and provide a blockchain-based marketplace / exchange. This can be implemented in different situations and scenarios. In an exemplary implementation, a logistics company may not fully utilize its freight transport capacity. The sensor-generated data can be processed using the edge private computation unit and once shared in the marketplace or exchange, an "offer" data set can be constructed that can be searched and bid on or purchased by other parties or entities. In this example, the iExec platform was used to collate jobs queued by the DAB service and executed by a custom off-chain algorithm scripted using iExec, which runs using Intel SGX engraving. This is shown diagrammatically in Figure 27.

[0220] Whenever a seller wants to sell a route, they enter it into the DAB app UI, either manually or automatically, and ask the DAB Service to insert it into other exchanges in the iExec marketplace. Another entity may use a similar process or layout within the application to describe their needs. It may search for and match compatible offers (both past and future). The DAB Service receives these queries, deploys matching jobs, and notifies both parties if a match is found.

[0221] Automated unfolding of the data set generated by the detection algorithm may be used. Interfaces / Dependencies In the test system, a set of user interfaces has been created in a DAB app (Android or iOS based) to construct offer and demand transactions and submit them to the transaction engine of the DAB service.

[0222] To use the marketplace / exchange, the DAB service interacts with the iExec SDK. This application is a command-line NodeJS tool that wraps proprietary Ethereum transaction logic, and another blockchain integration layer connector to orchestrate data insertion and retrieval. Each of these operations involves several OS calls to be executed, and an ordered set of commands is issued to the SDK, which synchronously executes and returns a textual JSON output that is processed and interpreted by the DAB service. Since all iExec off-chain algorithms run in a secure enclave, the datasets they use are not inserted directly into their blockchain. Instead, they are deployed to the public IPFS network (or other file system) once encrypted with a secret generated by the SDK. This secret, along with an IPFS hash of the dataset, is each pushed to iExec during the insertion flow, which sends the secret to a secret management service and the hash to the blockchain. For IPFS pinning services, Pinata may be used. This implementation also uses the API.

[0223] The iExec SDK v4.0.3 was installed alongside a DAB service instance in the same machine and required configuration of NodeJS 8.10.0 and Docker 19.03.6.

[0224] The DAB app is used to create a set of user interfaces that construct transactions to be sent to the DAB service. This simulates offers and demand capacities. However, such a process is automated in the generation system where offers and allowances are generated by different entities and processes. Similar message formats are used for the two different types of transactions.

[0225] If "transactionType" is equal to "newdata", it contains the offer dataset and triggers the DAB service to deploy it to the blockchain / marketplace / exchange; If equal to "lookingfordata", carries a demand data set containing the desired trip parameters.

[0226] The matching algorithm prepared by iExec works with a strict dataset format similar to both offers and demands, a JSON structure that characterizes a test scenario in which a shipping company sells available truck space for hire at a specific price, date and route, so both datasets are located within the property “transactionObject”.

[0227] Transaction Information To manually create a dataset describing the spatial provision for a truck trip, the user selects on the DAB app the menu entry "New monetizable data", the tab "Truck volume" and fills in the fields. In the generating system, a dataset is created by each individual truck that has a sensor capable of indicating a volume. The dataset includes:

[0228] Service Provider – the name of the service provider; Offered space - the number of cargo units available; Origin - Trip origin, End Point - Trip destination, Date - Trip date, Price - Asking price, To manually create a dataset describing a truck trip request, the user selects the menu entry "Find Data" on the DAB app and fills in the fields.

[0229] Service Provider - the name of the entity searching for cargo space; space required - cargo units required, Origin - Trip origin, End Point - Trip destination, Date - Trip date, Price - the bid price.

[0230] Again, in the generation system, bids for cargo space may be automatically generated to entities requiring such services.

[0231] Upon receiving "newdata" or "lookingfordata", the DAB service will initiate a series of system-level interactions with the iExec SDK: it is not the offer dataset itself that is inserted into the iExec blockchain, but rather its IPFS hash (along with other associated iExec data).

[0232] If a “newdata” transaction identifies a dataset to be inserted into the marketplace / exchange, “lookingfordata” triggers a DAB-side flow that entails looping through previously inserted “newdata” datasets to sequentially deploy and poll off-chain matching tasks (running on an Intel SGX enclave worker pool managed by iExec). This process is shown diagrammatically in Figure 28.

[0233] The matching process involves the DAB service selecting hashes of unpaired offer and demand datasets and inserting them into "tasks" in the iExec worker pool. These tasks are picked up and executed by the iExec worker pool and are repeatedly polled by the DAB service until a result is calculated. The DAB service maintains an updated list of all dataset hashes in its database. This process is shown diagrammatically in Figure 29.

[0234] Since these off-chain tasks cannot perform multiple comparisons at the same time, the DAB service is responsible for issuing executions for each dataset. If a match is found between an offer and a demand, those dataset hashes are registered in the DAB service database and notified to the buyer's device.

[0235] To communicate the matches to devices that have inserted both the offer and demand datasets, the Firebase cloud messaging platform may be used, being a cross-platform cloud solution especially for Android application messages and push notifications. A component handles Firebase messaging for DAB-driven devices, and all devices are made to register their Firebase connection token on startup (sent along with the device registration message posted to the DAB service) so they are ready to start up. Again, the generating system may process the messages differently.

[0236] The automated feeding of data into the marketplace / exchange may be achieved using different mechanisms. For example, AI and sensor networks can be set up for automated market negotiation. Off-the-shelf matching algorithms may be deployed to secure the worker pool.

[0237] Alternative implementations include: Replacing IPFS with a faster distributed storage solution; Developing matching algorithms that can handle multiple data sets simultaneously; This involves setting up a dedicated pool of workers where the DAB service unloads the demand dataset and provides the dataset hashing for continuous analysis providing asynchronous notification when a match is found.

[0238] Use Case: "Energy Identity and Payments" This use will enable "DAB-enabled devices" (having a SIM and a secure element on the respective middleware) to integrate into the Energy Web Foundation smart energy platform and become active participants.

[0239] Connected devices exclusively read and digitally sign messages (all encoded in JWT strings) from the Flexhub MQTT broker. Asset owners program offer allocations (to buy and sell power), which are managed and processed by the FlexHub platform. The DAB platform adds domain interconnection, which requires the DAB service to be aware of and act on transacted data. Thus, the integration architecture uses a DAB service broker for devices and handles messaging with FlexHub nodes on their behalf. The EWF device-side code (originally written in Python) is ported to a Spring Boot component running on the DAB core that now serves multiple devices, without any impact on FlexHub functionality. A schematic of this system is shown in Figure 30.

[0240] Relevant users / parties / roles defined by EWF include: The TSO (Transmission System Operator) submits flexibility requests, defines constraints and limitations, and activates confirmed assets.

[0241] Asset owners define offer parameters so that each of their personal assets can submit offers that match those parameters.

[0242] The installer approves the asset owner's asset registration. The competent authority will approve the registration of the roles of other parties participating in the market.

[0243] TSOs submit their energy flexibility requirements and constraints to the system, asset owners submit their offers (either on their own or through a third-party provider of intelligence), and the Flex system determines the least-cost way to fulfill the requirements.

[0244] Other enhancements may include: Automate registration, provisioning, and offer creation.

[0245] Any device other than Android or one using Java. Devices are requested to sign transactions and are notified of offer activations. These are triggered by the DAB service. This avoids devices polling each FlexHub MQTT queue for instructions from each device. The DAB app provides functionality including:

[0246] The device receives a message containing the EWF transaction for signing, which is then posted to a custom endpoint on the DAB Core Services API, triggering the DAB Core to complete the respective EWF business flow.

[0247] Whenever an activation message is received, the DAB app displays a user notification, which may be replaced by a useful real action (e.g. turning on / off a device reachable from the mobile application), as shown diagrammatically in Figure 31.

[0248] Business Logic The flow is initiated from inputs made by various EWF actors within the Flex WebApp. The DAB service is the only component that implements the EWF business logic (and any kind of flow state observability), so it asks the device to sign the various JWTs required by FlexHub.

[0249] After signing the requested messages, the device returns them to the DAB service with enough information to determine which flow was performed for the device that sent the signed messages. The device may need to sign other JWTs apart from the one related to the use case at hand (one of the DAB stack goals). Thus, the Firebase Data Message format allows for fast adaptation to other scenarios. The "useCase" property specifies the DAB use case for which signing is sought, and the inventors felt it appropriate to include an additional "useCaseAction" property that allows the server to distinguish additional courses of action within that particular use case to identify the action to trigger at the DAB service upon submission. Figures 32 and 33 show a sequence diagram of this process.

[0250] For this integration, the property "useCase" was tagged as "ewf" and the "useCaseAction" field was used to indicate the specific EWF business flow that initially required device signing.

[0251] The Flex WebApp can also be used by asset owners to check the activation charts of a given offer executed by a particular asset, and via the dashboard users can access the list of offers created and select the "datasheet" icon of the offer they wish to chart.

[0252] Devices become part of the EWF network, which can be extended to further utility actions such as turning on / off generators, batteries, etc. The same is applicable to other marketplaces outside of flex grid, including electric vehicle charging (EVC) or simple smart meter data monetization.

[0253] Use case: "Corporate and consumer parking" In this use case, digital identities (for people, services, and things) are used to create a complete end-to-end experience where a car can be paired with a service with or without payment.

[0254] 1. Either by the driver (consumer B2C scenario - using the driver's digital identity and associated personal account in the banking platform), 2. Charges are made for the car itself, whose usage is kept on DLT for later processing (corporate B2B scenario - where the car belongs to a third party, e.g. a rental company), The DAB service manages and orchestrates the flows (and hosts the Corda DLT for use in B2B payments). The vehicle may include an internal router running a DAB middleware application and a customized version of a DAB app (e.g., a tablet app). This can be installed on an embedded (e.g., iOS or Android-based) dashboard computer.

[0255] Interfaces / Dependencies The SPOT parking system can be installed in the same location and on the Corda ledger, as can the "payment for service" use case.

[0256] SIM protection To sign transactions, the secured by SIM technique described above may be used, consuming the PKI on the SIM. The SIM is added to a USB dongle plugged into a processor or other device (e.g., a vehicle). The DAB middleware runs on the device and exposes the DAB middleware API for signing, as described above.

[0257] The SPOT parking system, installed in the parking infrastructure, detects vehicles crossing its gates and works with the DAB service by calling endpoints in a custom API set (see above). This customization is used by the SPOT to send license plate and gate information to the DAB service, which then expects a return code if:

[0258] On receipt: An enabled payment has been set so the barrier can be opened, When leaving the parking lot: The settlement is completed and the car can be left.

[0259] FINN To manage the B2C scenario, we used FINN(RTM), which specializes in monetizing IoT solutions built on a commercial platform that includes a toolkit to add IoT payments to smart devices. A "product" defines the different actions for providing and interacting with a service, and assigns a usage price to each.

[0260] The device registers to use a "product" and the action is charged to a payment method set up by the device owner, such as a credit card.

[0261] Whenever a device triggers a “product” action, a micropayment is registered in the FINN ecosystem.

[0262] In the case of FINN, a "product" can be an abstract entity representing any real system operating in the real world (integrating with FINN IOT SDK to connect "product" actions with any automated activity) or offline service. All usage logic within the SPOT is controlled by the DAB service component. The configured actions for this "product" include gated entry and exit, with 0 and parking fees charged respectively based on duration of stay.

[0263] A sequence diagram of a parking session is shown in FIG. To trigger these scenarios, a collection of user layouts in the DAB app builds a transaction according to the message format described in the DAB Management Core. For the parking scenario (use case type "parking"), session initiation and termination are differentiated by their "transactionType" value ("newdata" and "endcordasession"), and by the content of the "transactionObject". This last field carries both buyer (car) and supplier (parking lot) information that is committed to the DLT. Together with the geographic information, the DAB service acts as a proxy server for each device (used to validate the device's location if necessary).

[0264] To start a simulated parking session, the user selects the menu entry “New monetizable data”, tab “Parking”, on the DAB app and fills in the following fields:

[0265] Initiator - the device that initiates the parking session (the SIM ID of the device is automatically filled in), Target - the Corda node where the vehicle is registered, Target UUID - the code identifier (UUID) of the initiator vehicle, Source UUID - the code identifier (UUID) of the parking slot selected to park the vehicle, GPS options: MOCK_HAPPY_PATH - Start a parking session using GPS location: always results in a successful action. REAL_GPS - Start the parking session using the real GPS location, as read from the Android OS. When using this option to start a successful parking session, the initiator device and the parking slot must be at most 6m from each other.

[0266] To end a parking session, the user Open a session in the "Transactions" menu entry and fill in the following fields:

[0267] Minutes / value units charged to blockchain, GPS options: MOCK_HAPPY_PATH - Stop the parking session using the GPS location, this results in a successful action, REAL_GPS - End the parking session using the device's actual GPS location, MOCK_END_SESSION_CAR_STILL_PARKE D - A test flag that instructs the Corda DApp to behave as if the car has never left the parking spot.

[0268] Business Logic In this use case, the device using the "product" is a vehicle. However, the "action" may also be activated in a B2C scenario. Hence the concept of "smart services" is used, an association between the user's digital identity and the services offered by the DAB stack.

[0269] DAB associates the device (car) with the SIM: As this is a FINN based smart service, the DAB service needs to know all the FINN data related to the SPOT parking "product" in order to pass it on to the device that wants to use it. This is done every time the vehicle tablet app (or other processor in the vehicle or device) starts up, and installed alongside it is a FINN provisioned app (embedding the FINN IOT SDK) that contains the code to register with the FINN core backend and automatically set up that vehicle so that it is ready to use the SPOT parking "product" whenever required. This provisioning flow is shown in Figure 35 and includes the following:

[0270] Step Description Trigger 1. Manufacturer adds new vehicles to the SCB-DAB system Manufacturer 2 DAB will deploy new smart contracts for its vehicle identity on the DDI blockchain network 3 The DDI Blockchain Network responds with the corresponding did DDI Blockchain 4 DAB associates it with car number plates DAB 5 DAB transmits vehicle DID to compatible vehicles 6 Cars store their own did in their database Cars Smart Services Onboarding: Whenever a user wants to perform "Smart Services" onboarding, it is done using a specially developed Android application (hereafter known as the "Smart Services Application"). The App cooperates with the DID Application to select a Digital Identity and associate it with the Smart Services selected from its UI. This is shown diagrammatically in Figure 36.

[0271] At this point, if the user is onboarded to use the "SPOT Parking Smart Service", the DAB service has responded with enough data (data initially sent by the tablet app) to configure the user's FINN payment method, and for this the smart service app automatically communicates via intent with another FINN-supplied application (incorporating the FINN Mobile SDK) that first requests a valid payment credit card from the user and then registers it as a consumer of the SPOT parking product. This is shown diagrammatically in Figure 37. In this exemplary implementation, the following steps can be taken:

[0272] Onboarding for B2C Services (Figure 37) Step Description Trigger 1 Smart Service App triggers DAB to create a new service for the user Smart Service App 2 DAB checks the profile type (individual) and saves the user data DAB 3 DAB responds with data required for user-side initialization: user profile data + service data DAB 4 The Smart Services app triggers the Finn mobile app to create a new service (via an intent) Smart Services app 5 Finn mobile app forwards the request to FINN core FINN mobile application 6 FINN core responds with success or an error message FINN core 7 Finn Mobile App responds with success or an error message (via intent return) FINN Mobile App 9 Smart Services app posts Finn's onboarding confirmation to / services / confirmation Smart Services app Identify the device (e.g. car): To determine which car the user is driving (and to understand which vehicle triggers the FINN SPOT parking "product" action), a login mechanism is established on the DAB platform that leverages the digital identity capabilities to create a session between the user and the thing. In this way, whenever a car crosses the entrance gate, the DAB service knows who is driving it. The flow is triggered when the driver enters the car's license plate in the DAB app (pre-installed on the car's on-board tablet), and the subsequent activity can be divided into two stages:

[0273] QR Code generation: the DAB app generates a QR code on the tablet for the driver to scan to proceed with the authentication process; and Driver Authentication: The driver scans the QR code, triggering and opening the DDI app. From there, the driver authorizes (or does not authorize) what personal information they want to share with the vehicle. Some of this data is mandatory, while others are optional, which is a design decision configured in the DAB (which acts as a proxy for all vehicles). All authorized information shared by the user can be stored in the DAB. This is shown diagrammatically in Figure 38.

[0274] Driver-Car Login via QR Code (Figure 38) Step Description Trigger 1. The driver enters the license plate number into the tablet app in the car. Tablet app 2 The tablet app sends a login request to the DAB. 3 DAB generates a random topic UUID that identifies that login "session" 4 DAB requires nonce + authorization ID in GCL DAB 5 GCL response: nonce+authID GCL 6 DAB associates a topic with a nonce + authID + step 2 data 7 DAB sends the necessary data to generate a QR code to the tablet app. DAB 8 The tablet app generates a QR code for authentication. Driver-Vehicle Login via Decentralized Digital ID (DDI) (Figure 39) Step Description Trigger 1 Driver reads the QR code with his / her phone (contains topic + car DID identity) Driver 2 The DDI app opens and the driver selects and / or authorizes the data they want to share about themselves. DDI app 3 DDI apps share their information GCL 4 GCL requests the DAB return URL stored in the provided car identity from the blockchain GCL 5 GCL posts its endpoint and checks for the existence of the topic If the topic exists, DAB stores the indicated userDid which pertains to the user trying to log in GCL 6 DAB sends Ok or error response to GCL DAB 7 GCL sends the login result to the DDI app GCL 8 If the login result is successful, the DDI app posts the user profile + profile type to the DAB. DDI app 9 DAB saves user profile + profile type for this user / car session DAB 10 DAB sends the login result to the tablet app. DAB 11 Tablet app displays success message Tablet app DAB Service: The DAB Service is triggered every time a SPOT posts information about a detected vehicle license plate to a custom REST endpoint of a custom API (implemented according to the specifications of the existing SPOT infrastructure). The following logic required an additional component to be integrated within DAB Core to manage the SPOT business flow, which can be summarized as follows:

[0275] When the vehicle enters the parking lot, If the smart service has a B2B profile onboarded, the DAB service will open a session for that vehicle on the Corda DLT (mirroring the “Parking and Tolling” use case) using the blockchain integration layer’s Corda connector. If the smart service has been onboarded with a B2C profile, a Firebase message is pushed to the vehicle's tablet app, triggering product activation in the Finn backend for the SPOT product identifier.

[0276] When the vehicle leaves the parking lot, If the smart service has a B2B profile onboarded, the DAB service will close any previously opened DLT sessions for that vehicle, If the smart service was onboarded with a B2C profile, a Firebase message is pushed to the vehicle's tablet app, triggering product deactivation in the Finn backend for the SPOT product identifier.

[0277] B2B initiates the parking flow details (Figure 40). Step Description Trigger 1. The camera at the entrance gate scans the license plate. Parking gate 2 The parking gate requests DAB to start a new parking session for that license plate. 3 DAB checks the user's DID profile type used for onboarding the parking service (if corporate) DAB 4 DAB triggers a new parking session in the Corda parking blockchain 5 Blockchain to DAB response - success or error Parking Blockchain 6 DAB sends a Firebase notification to the tablet app informing it of the new parking session, replies with step 2 with an appropriate message, and then triggers the gate to open 7 The tablet app displays information about the new parking session on the screen. B2C Initiate Parking Flow Details (Figure 41) Step Description Trigger 1. The camera at the parking gate scans the license plate. 2 The parking gate requests DAB to start a parking session for that license plate. 3 DAB checks the user's DID profile type used for onboarding the parking service (if private) DAB 4 DAB sends Firebase notification to tablet app and triggers Finn action (stock) DAB 5 The tablet app triggers an inventory action to the FINN IoT SDK via an intent. Tablet app 6 FINN IoT SDK uses DAB middleware to sign transactions with the corresponding key pair FINN IoT SDK 7 FINN IoT SDK triggers in-stock actions in FINN Core FINN IoT SDK 8 Response from FINN Core to FINN IoT SDK - Success or Error FINN Core 9 FINN IoT SDK signals the operation result via intent return, and the tablet app displays a notification popup FINN IoT SDK 10 DAB returns from the post made in step 2, triggering the gate to open the tablet app B2B completes the parking flow details (Figure 42).

[0278] Step Description Trigger 1. Cameras at the exit gate scan license plates Parking gate 2 The gate requests DAB to end the parking session for that number plate. Parking Gate 3 DAB checks the user's DID profile type used for onboarding the parking service (if corporate) DAB 4 DAB triggers the closure of a parking session in the Corda parking blockchain 5 Blockchain to DAB response - success or error Parking Blockchain 6 DAB sends a Firebase notification with the price and duration of the parking session to the tablet app, which returns step 2 with an appropriate message, which then triggers the gate to open. 7 The tablet app displays information about the new parking session on the screen. B2B completes the parking flow details (Figure 43).

[0279] Step Description Trigger 1. Cameras at the exit gate scan license plates Parking gate 2 The gate requests DAB to end the parking session for that number plate. Parking Gate 3 DAB checks the user's DID profile type used for onboarding the parking service (if private) DAB 4 DAB sends a Firebase notification to the tablet application containing the price and duration of the parking session, triggering a Finn action (leave) DAB 5 The tablet app triggers a shipping action to the FINN IoT SDK via an intent. Tablet app 6 FINN IoT SDK uses DAB middleware to sign transactions with the corresponding key pair FINN IoT SDK 7 FINN IoT SDK triggers withdrawal actions in FINN Core FINN IoT SDK 8 Response from FINN Core to FINN IoT SDK - Success or Error FINN Core 9 FINN IoT SDK signals the operation result via intent return, and the tablet app displays a notification popup FINN IoT SDK 10 DAB returns from the post made in step 2, triggering the gate to open the tablet app Similar solutions can be applied to different parking solutions and also to different domains, for example in smart cities where EV charging and tolling can follow the same flow. End-to-end experience improvements are being made regarding consumer digital identity and payments.

[0280] DAB User Interface The test environment has two main user interfaces (UI):

[0281] DAB APP: Android (or other) mobile application DAB AEP: Thingworx extension for connecting DAB Corda blockchains The UI is important not only to enable customers to take advantage of all functionality, but also to enable operations and maintenance teams to manage the ecosystem and solutions, and to monitor and extract information.

[0282] 44-48 show an exemplary platform environment. Other server types and services may be used.

[0283] Although this describes a test scenario, a real parking session may be handled in a similar but application-less manner: all messages may be initiated from sensors and detected events in or around the vehicle (or parking location).

[0284] As those skilled in the art will appreciate, the details of the above embodiments can be changed without departing from the scope of the invention as defined by the appended claims.

[0285] For example, different distributed ledgers or ledger technologies may be used. The UICC may, for example, be an embedded SIM. Many different types of devices may be used, including, for example, mobile, movable, fixed, supervised, unsupervised, domestic, commercial or industrial devices.

[0286] 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 specific reference to one embodiment or example may be used in any other embodiment by making appropriate modifications.

Claims

1. 1. A method of recording a transaction on a distributed ledger, the method comprising: creating a secure channel between the device and the BSF using a pre-provisioned key stored in the UICC of the device and in a Bootstrapping Server Function, BSF; Sharing a secret between the device and the BSF over a secure channel; storing the shared secret on the UICC of the device; adding one or more transactions to a block of a distributed ledger, the one or more transactions being identified using the shared secret; A method comprising:

2. transmitting the shared secret from the BSF to a server, where the shared secret is used to secure a communication channel between the device and the server, and the server adds the one or more transactions to the block of the distributed ledger; The method of claim 1 further comprising:

3. The one or more transactions are associated with a wallet identifier of the server in the distributed ledger, and the one or more transactions include: the server stores transaction identifiers of the one or more transactions added to the block of the distributed ledger remotely from the device; and the server mapping the stored transaction identifier to the shared secret. The method of claim 2 , wherein the first and second vertices are identified by:

4. The method of claim 2 or 3, wherein the transaction identifier is based on the identity of the UICC and the shared secret.

5. 2. The method of claim 1, wherein the transaction added to the block is identified by a wallet identifier based on the identity of the UICC and the shared secret.

6. The method according to any one of claims 1 to 3, wherein the shared secret is stored in a Trusted Execution Environment, TEE, of the UICC.

7. The method of claim 1 , wherein the shared secret is a symmetric key.

8. 4. The method of claim 1, wherein creating the secure channel between the device and the BSF and sharing the secret between the device and the BSF over the secure channel uses a Generic Bootstrap Architecture, GBA, and / or complies with a GSMA IoT Security Applet Interface Description, IoT SAFE.

9. The method of claim 1 , wherein the device is one of an IoT device, a UE, a smartphone, a vehicle, an automobile, or an unmanned aerial vehicle.

10. Distributed ledger and A Bootstrapping Server Function, BSF; A device having a UICC; One or more processors and a memory, the memory providing to the one or more processors: creating a secure channel between the device and the BSF using a pre-provisioned key stored in the UICC of the device and in the BSF; Sharing a secret between the device and the BSF over the secure channel; and storing the shared secret on the UICC of the device; and adding one or more transactions to a block of the distributed ledger, the one or more transactions being identified using the shared secret; one or more processors and memory including program instructions for causing the A system comprising:

11. server Further equipped with the BSF is configured to transmit the shared secret to the server; 11. The system of claim 10, wherein the program instructions further cause the one or more processors to use the shared secret to secure a communication channel between the device and the server, the server adding the one or more transactions to a block of the distributed ledger.

12. 12. The system of claim 11, wherein the one or more transactions are associated with a wallet identifier of the server, the server further comprising a database configured to store transaction identifiers of the one or more transactions added to the block of the distributed ledger, and a mapping of the stored transaction identifiers to the shared shared secret.

13. The system of claim 11 or 12, wherein the transaction identifier is based on the identity of the UICC and the shared secret.

14. 11. The system of claim 10, wherein the transactions added to the block are identified by a wallet identifier based on the identity of the UICC and the shared secret.

15. 15. The system of claim 14, wherein the device comprises the one or more processors and the memory containing program instructions for causing the one or more processors to add the one or more transactions to the block of the distributed ledger.

Images