WO2022066076A1

WO2022066076A1 - Binding a subscriber's identity in a mobile network to transactions in a distributed ledger network

Info

Publication number: WO2022066076A1
Application number: PCT/SE2020/050903
Authority: WO
Inventors: Remi ROBERT; Aleksandra OBESO DUQUE
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2020-09-25
Filing date: 2020-09-25
Publication date: 2022-03-31

Abstract

The invention addresses the problem experienced in a distributed ledger network that after a transaction has been verified as valid, it can be difficult in the future to analyse the identity of the person who inputted the transaction. The solution presented in form of two methods is based on the transaction comprising on top of the payload an authentication parameter and an authentication identifier, which are both checked on their validity before accepting the transaction, said authentication parameter being in association with the user subscription identity.

Description

BINDING A SUBSCRIBER’S IDENTITY IN A MOBILE NETWORK TO TRANSACTIONS

IN A DISTRIBUTED LEDGER NETWORK

TECHNICAL FIELD

[0001] The present disclosure relates to the field of distributed ledger networks; and more specifically, to binding a subscriber’s identity in a mobile network to a transaction in a distributed ledger network.

BACKGROUND

[0002] Distributed ledger technology (DL) networks are platforms used for building, running, and deploying a decentralized, distributed digital ledger. In a DL network a digital ledger permanently records digital records of transactions that occur between participants. The records cannot be altered retroactively without the alteration of all subsequent transactions in the digital ledger and without consensus from multiple nodes in the DL technology network. Recordation of transactions in the digital ledger allows the participants to verify and audit transactions inexpensively and securely. A digital ledger is maintained without a central authority or implementation. In a DL technology network the data can be spread across multiple organizations, potentially in different countries, under different legislations, with different level of technical expertise.

[0003] DL networks may be public or private. Public DL networks are available to anyone who wants to join and use the network. In this type of DL network, anyone is allowed to read, write, or join the public DL network. In public DL networks, anyone, anywhere, can use the DL network to input transactions and data. In contrast, while private DL networks can be similar to public DL networks in certain aspects, they have access controls that restrict those that can join the network. Private DL networks have one or multiple entities that control the network.

[0004] A DL network can be used to record transaction between participants in the DL network that include subscribers of mobile network. In these systems, there is a disconnect between the identity of the participant in the DL network and their identity in the mobile network.

SUMMARY

[0005] The embodiments described herein present a solution for binding a subscriber’s identity in a mobile network to a transaction in a distributed ledger network.

[0006] One general aspect includes a method in a network node of validating transactions stored in a digital ledger of a distributed ledger (DL) network. The method includes receiving a first transaction stored in the digital ledger of the DL network, where the first transaction includes a payload, an authentication parameter that results from an authentication procedure between a user equipment (UE) and a network node of a mobile network for authenticating the UE in association with a subscription in the mobile network and the authentication parameter binds the first transaction (112) to the subscription, and an identifier of the authentication procedure; verifying authenticity of the first transaction based on the authentication parameter and the identifier of the authentication procedure; and responsive to verifying authenticity of the first transaction, determining that the first transaction is valid in the DL network.

[0007] One general aspect includes a network device for validating transactions stored in a digital ledger of a distributed ledger (DL) network. The network device comprises one or more processors; and a computer readable storage medium storing instructions which when executed by the one or more processors cause the network device to perform operations receiving a first transaction stored in the digital ledger of the DL network, where the first transaction includes a payload, an authentication parameter that results from an authentication procedure between a user equipment (UE) and a network node of a mobile network for authenticating the UE in association with a subscription in the mobile network and the authentication parameter binds the first transaction (112) to the subscription, and an identifier of the authentication procedure; verifying authenticity of the first transaction based on the authentication parameter and the identifier of the authentication procedure; and responsive to verifying authenticity of the first transaction, determining that the first transaction is valid in the DL network.

[0008] One general aspect includes a method of binding a subscriber’s identity in a mobile network to transactions in a distributed ledger (DL) network. The method includes generating, in a user equipment (UE) and based on an identifier of a subscription in the mobile network and one or more cryptographic keys obtained through an authentication procedure between the UE and a network device of the mobile network that authenticates the user equipment as a valid UE for the subscription, an authentication parameter; and submitting a transaction to be stored in a digital ledger of the DL network, where the transaction includes a payload, an identifier of the authentication procedure, and the authentication parameter that is to be used to prove that the UE is a valid UE for the subscription and to bind the transaction to the subscription.

[0009] One general aspect includes a system for binding a subscriber’s identity in a mobile network to transactions in a distributed ledger (DL) network. The system includes one or more processors; and one or more computer readable storage media storing instructions which when executed by the one or more processors cause the system to perform operations including: generating, in a user equipment (UE) and based on an identifier of a subscription in the mobile network and one or more cryptographic keys obtained through an authentication procedure between the UE (104) and a network device of the mobile network that authenticates the user equipment as a valid UE for the subscription, an authentication parameter; and submitting a transaction to be stored in a digital ledger of the DL network, where the transaction includes a payload, an identifier of the authentication procedure, and the authentication parameter that is to be used to prove that the UE is a valid UE for the subscription and to bind the transaction to the subscription.

BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The present disclosure may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the present disclosure. In the drawings:

[0011] Fig. 1 illustrates a block diagram of an exemplary DL network, in accordance with some embodiments.

[0012] Fig. 2A illustrates a block diagram of exemplary operations that can be performed in a DL network for inserting a first transaction in a digital ledger of the DL network, in accordance with some embodiments.

[0013] Fig. 2B illustrates a block diagram of exemplary operations that can be performed in a DL network for validating the first transaction, in accordance with some embodiments.

[0014] Fig. 3 A illustrates a flow diagram of exemplary operations that can be performed in a DL network for binding a subscription’s identity in a mobile network to transactions in the DL network, in accordance with some embodiments.

[0015] Fig. 3B illustrates a flow diagram of exemplary operations that can be performed for validating transactions stored in a digital ledger of a distributed ledger (DL) network, in accordance with some embodiments.

[0016] Fig. 4 illustrates a block diagram for a network device that can be used for implementing one or more of the nodes described herein, in accordance with some embodiments.

[0017] Fig. 5 illustrates a block diagram for network devices that can be used for implementing a node described herein, in accordance with some embodiments.

[0018] Fig. 6 illustrates an exemplary embodiment of a user equipment, in accordance with some embodiments.

DETAILED DESCRIPTION

[0019] The following description describes methods and apparatus for binding a subscriber’s identity in a mobile network to transactions in a distributed ledger network. In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, resource partitioning/sharing/duplication implementations, types and interrelationships of system components, and logic partitioning/integration choices are set forth in order to provide a more thorough understanding of the present disclosure. It will be appreciated, however, by one skilled in the art that the embodiments may be practiced without such specific details. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the embodiments. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

[0020] References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0021] Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dotdash, and dots) may be used herein to illustrate optional operations that add additional features to some embodiments. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments.

[0022] In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other.

[0023] When a DL network is used to record transaction between participants in the DL network that include subscribers of mobile network, a participant in the DL network is identified independently of their identity in the mobile network. There is a disconnect between the identity of the participant in the DL network and their subscription in the mobile network. For example, when a subscriber to a mobile network needs to provide consent to a third party application (that is different from the mobile network and different from the DL network in which the transactions are recorded), the subscriber records the transaction including the consent in the DL network. However, this transaction is linked to the identity of the subscriber in the DL network and not to their identity in the mobile network. There is a need to link or bind the identity of the subscriber in the DL network with the transaction they submit to be inserted in the DL network. [0024] The embodiments described herein present methods and systems for binding a subscriber’s identity in a mobile network to transactions in a distributed ledger (DL) network. In one embodiment, a user equipment generates an authentication parameter, based on an identifier of a subscription in the mobile network and one or more cryptographic keys obtained through an authentication procedure between the UE and a network device of the mobile network that authenticates the user equipment as a valid UE for the subscription. The UE submits a transaction to be stored in a digital ledger of the DL network. The transaction includes a payload, an identifier of the authentication procedure, and the authentication parameter that is to be used to prove that the UE is a valid UE for the subscription and to bind the transaction to the subscription.

[0025] In some embodiments, a transaction validator receives the first transaction stored in the digital ledger of the DL network. The first transaction includes a payload, an authentication parameter that results from an authentication procedure between the UE and a network node of a mobile network for authenticating the UE in association with a subscription in the mobile network, and an identifier of the authentication procedure. The transaction validator verifies authenticity of the first transaction based on the authentication parameter and the identifier of the authentication procedure. In response to verifying authenticity of the first transaction, the transaction validator determines that the first transaction is valid in the DL network.

[0026] The embodiments described herein present several advantages when compared with existing DL network platforms or mobile network infrastructures. The embodiments herein allow to have auditable evidence of the association between a mobile subscription in a mobile network and a participant in the DL network that generates a transaction in the DL network. In some embodiments, the identifier of a subscription in the mobile network is integrated into the logic of a smart contract allowing for multiple use cases such as consent management. The solution presented herein allows to link the identity of the subscriber in the mobile network and their identity in the DL network without requiring a common identifier in the DL network and the mobile network.

Overview:

[0027] Fig. 1 illustrates a block diagram of an exemplary DL network for binding a subscriber’s identity in a mobile network to a transaction in a distributed ledger network, in accordance with some embodiments. In some embodiments, the DL network supports smart contracts. However, the embodiments described herein generally apply to other types of DL networks, which do not necessarily need to implement and support smart contracts.

[0028] The DL network 101 includes a set of DL nodes 102A-N that are owned or operated by participants in the DL network 101. A participant in the DL network 101 is associated with one or more DL nodes and optionally one or more client devices. The various nodes and client devices communicate through a physical network (wired, wireless, or a combination of wired and wireless networking technology) that is not illustrated. In some embodiments, the DL network 101 is a blockchain network. In some embodiments, the DL network is a public DL network, while in other embodiments, the DL network is a private DL network. In some embodiments, the DL nodes 102A-N, may be permissioned to join the DL network 101 via, for example, an access control list. In some embodiments, the access control list can be managed by smart contract.

[0029] A participant in the DL network 101 is an entity that can participate and contribute to transactions with other participants in the ledger. The participant can be a person, an organization, a program run on a processor, etc. The participant is associated with a node that is used to access the DL network 101. The node of the participant can be a DL node, e.g., DL node 102A or DL node 102N, or a client device, e.g., user equipment (UE) 104, that is not part of the DL network 101. In a non-limiting example, the DL network 101 includes multiple participants 103A-N. The first participant 103 A owns and/or operate one or more DL nodes 102A. Optionally, the first participant can own and/or operate one or more other DL nodes. The first participant 103 A further owns and/or operate one or more other types of nodes, e.g., UE 104 that enable users associated with the participant 103 A to access the DL network 101. The second participant 103N owns and/or operate one or more DL nodes 102N. Optionally, the second participant can own and/or operate one or more other nodes (not illustrated) that enable users associated with the participant 103B to access the DL network 101. In some embodiments, the DL network 101 may further include additional participants and nodes, which are not illustrated. While the DL network 101 is illustrated as including two participants, each associated with a given number of DL nodes and/or client devices, this is intended to be exemplary only, and different numbers of participants can be part of the DL network 101 with different numbers of DL nodes or client devices. In some embodiments, the mobile network 105 can be a participant in the DL network. In other embodiments, the mobile network 105 is not a participant in the DL network.

[0030] UE 104 is an electronic device that allows to interface with the DL network 101 through a DL node. It can be used, for instance, to build and submit a transaction request to one or more nodes of the DL network 101. Further, UE 104 is operative to communicate with one or more network nodes of the mobile network infrastructure 105. UE 104 has access to one or more services offered by the mobile network. UE 104 is associated with a subscription in the mobile network 105. For example, the user 130 of the UE 104 may have subscribed or registered for a service to access networking resources in the mobile network 105. UE 104 is configured to wirelessly connect to, or be paged by, a base station (not illustrated) of the mobile network 105 to access these services. UE 104 is operative to generate a transaction that is to be inserted in the digital ledger 110 of the DL network 101. UE 104 can be a client of the DL network. In some embodiments, UE 104 can include a DL node.

[0031 ] A DL node is a node that is operative to perform some, or all operations related to updating and maintaining the digital ledger. For example, a DL node can be a full node that stores the entire digital ledger. Alternatively, the DL node can be a light node, which may include only a partial list of the digital ledger. The DL node may further be operative to receive transaction requests from client devices, evaluate the transactions, and validates them to be added to the digital ledger based on a consensus algorithm (such as Proof of Work (PoW), Proof of Stake (PoS), or other). Thus, the DL node is operative to synchronize the state of the digital ledger, as well as receive request from users to alter the state (receive, evaluate, and validate transactions). In some embodiments, the DL node is operative to participate in a mechanism of binding a transaction in the DL network with a subscription in the mobile network.

[0032] A DL node includes a digital ledger. In some embodiments, the DL node is operative to store public data. In some embodiments, the DL node is operative to store private data and public data. The private data can belong to the participant that owns the DL node or data that belongs to one or more participants different from the participant that owns the DL node. The DL node may include additional elements that are not illustrated. For example, a DL node may include a DL network state(s), and a transaction manager.

[0033] The digital ledger 110A is a list of transactions that occurred on the DL network 101. Once transactions are written to the digital ledger 110A, they cannot be modified; the record of transactions (i.e., the digital ledger 110A) is immutable. While the DL nodes 102A-N are illustrated as including digital ledgers 110A, 110N, typically each one of the DL nodes 102A-N includes an identical copy of the digital ledger. The digital ledger stored on each one of the DL nodes 102A-N includes the same data. In some embodiments, some of the nodes may be light DL nodes including a subset of the entire digital ledger for the DL network 101. Thus, one or more of the DL nodes may include a copy of all or a portion of the digital ledger 110A.

[0034] The transactions stored in the digital ledger 110 may include private transactions and public transactions. A public transaction is a transaction that is available to be viewed by all of the participants of the DL network 101. In contrast, a private transaction is only available to be viewed by some of the participants but not by all of the participants of the DL network 101. For private transactions, an identifier of each private transaction is stored in the digital ledger 110A instead of the payload of the transaction. The payload of a transaction contains the details about the transaction and is not stored in the digital ledger. This ensures that the payload of any private transaction is not accessible to participants that are not recipients of the transactions. In one example, the identifier of the transaction can be a hash of the payload of the transactions. For public transactions, the digital ledger 110A stores the payload of the transactions consequently allowing any participant of the DL network 101 to access/view the payload of these public transactions by accessing the digital ledger 110A.

[0035] The payload can be the details of a transaction between two participants in the DL network (in terms of transfer of currency) or more generally an invocation of a smart contract (or a method of a smart contract) with parameter values that change the state of the DL network. In some embodiments, the payload of the transaction may include data for providing consent from the subscriber of the mobile network to a third-party application. For example, an application 120 may request access to the location of the subscriber or details about the subscription in the mobile network, or more generally the details of a digital contract with the subscriber. When the transaction is used for providing consent from the subscriber (user of the UE 104) to an application or another participant in the DL network 101, the payload can include a validity period indicating the time interval during consent is valid, a scope of the consent indicating what the subscriber is consenting to, etc. While the example herein is described with respect to the subscriber giving consent to an application in relation to use of information with respect to the subscription, other exemplary uses of the mechanisms described herein for binding the subscription in the mobile network with a transaction in the DL network 101 can be contemplated without departing from the scope of the embodiments described herein.

[0036] In one example, the digital ledger 110A can be a blockchain. In this example, transactions are collected inside blocks that are appended to the blockchain. In addition to the transactions, each block may include additional fields (e.g., a block header). In other examples, the digital ledger 110A can include another structure different from the blockchain that is operative to store private and/or public transactions.

[0037] In some embodiments, the DL network supports smart contracts. In some embodiments, the smart contracts are stored as part of the digital ledger 110A. In other embodiments, the smart contracts are stored independently of the digital ledger 110A. A smart contract is computer code that implements a computer protocol intended to digitally facilitate, verify, or enforce the negotiation or performance of a contract. A smart contract is usually written in a human readable language that is then compiled to a machine language before execution. Consensus is achieved, using the ledger protocols, regarding the definition of each smart contract. A smart contract allows the execution of transactions between two parties without a third party. Once executed, the transactions of a smart contract are stored in the digital ledger 110A and are trackable and irreversible.

[0038] The system further includes a mobile network infrastructure 105. In the following description a mobile network infrastructure and mobile network will be interchangeably used. The mobile network is owned by a mobile network operator. The mobile network may include radio network resources, transport network resources, and/or a core network. In some embodiment, the mobile network operator may own both radio network resources and transport resources. In some embodiments, in addition to the radio network resources, the mobile network operator may further own computing resources (e.g., data centers, servers, etc.) that implement components of a core network. Thus, the RAN resources, the transport network infrastructure, and the infrastructure that implements the core network can be owned by the same administrative entity. A mobile network operator can be a standard public landline mobile network (PLMN) operator offering radio access to mobile devices. In some embodiments, the DL network 101 includes multiple mobile network operators as participants.

[0039] The mobile network (MN) authenticator 107 is a network node in the mobile network 105 which provides application-independent functions for mutual authentication of user equipment(s) and applications unknown to each other. The MN authenticator 107 allows the bootstrapping of an exchange of cryptographic keys between a UE and an application. The MN authenticator 107 allows application(s) (e.g., the DL network, or application 120) to authenticate the UE 104 with respect to a subscription in the mobile network. In some embodiments, the MN authenticator 107 is operative to communicate with one or more DL nodes of the DL network 101 to enable verification of the authenticity of a transaction submitted by UE 104 to the DL network 101.

[0040] The system 100 further includes a transaction validator 108. The transaction validator is a network node. The transaction validator is communicatively coupled with DL nodes of the DL network 101 and with network nodes of the mobile network 105. The transaction validator is operative to validate transactions stored in the digital ledger 110A of the DL network 101. [0041] At operation 1, UE 104 participates in an authentication procedure with the MN authenticator 107. The authentication procedure between the UE 104 and the MN authenticator 107 authenticates the UE 104 for the subscription. From the authentication, UE 104 obtains an identifier of the authentication procedure and one or more cryptographic keys. UE 104 generates an authentication parameter based on the cryptographic keys (also referred to as first cryptographic keys) and a subscription identifier (also referred to as subscription ID) that is associated with the subscription for which the UE 104 was authenticated. At operation 2, UE 104 submits a first transaction 112 to be stored in the digital ledger 110A of the DL network 101. The transaction 112 includes a payload, an identifier of the authentication procedure, and the authentication parameter. The authentication parameter is to be used to prove that the UE 104 is a valid UE for the subscription and to bind the transaction to the subscription.

[0042] The transaction validator 108 receives the first transaction 112 stored in the digital ledger 110A. The transaction validator 108 verifies authenticity of the first transaction 112 based on the authentication parameter and the identifier of the authentication procedure, at operation 3. In some embodiments, the verification of the authenticity of the first transaction 112 includes the participation in an authentication procedure between the transaction validator 108 and the MN authenticator 107, at operation 3 a. In response to verifying authenticity of the first transaction 112, the transaction validator 108 determines that the first transaction 112 is valid in the DL network 101. In some embodiments, upon determining that the transaction is valid, the transaction validator 108 submits a second transaction 114 to be stored in the digital ledger 110A, at operation 4. The second transaction includes a verification parameter that allows to prove the authenticity of the first transaction 112. In some embodiments, one or more additional DL nodes in the DL network can use the second transaction, in particular the verification parameter, to validate the first transaction.

[0043] In some embodiments, the mechanism described herein enable to record in the digital ledger of the DL network consent from the UE 104 to an application 120 for usage or access of data related to the subscription 113 in the mobile network 105. In a non-limiting example, the application requests, at operation 5, access to data related to a subscription, such as the location of UE 104, etc. UE 104 provides the access rights to the application and records the access rights as a payload of the first transaction 112. The generation of the transaction triggers the operation (1) and (2) in which the first transaction 112 is bound to the subscription 113. The application 120, the transaction validator 108, and/or one or more DL nodes of the DL network 101 can access the first transaction and verify its validity as described with respect to operations (3) and optionally (4). Other use cases of the embodiments described herein can be contemplated. For example, an application 120 can provide access to one or more services to UE 104 by authenticating the UE 104 with respect to the subscription 113 based on the first transaction or a combination of the first and the second transactions.

Inserting a first transaction

[0044] Fig. 2A illustrates a block diagram of exemplary operations that can be performed in a DL network for inserting a first transaction in a digital ledger of the DL network, in accordance with some embodiments. [0045] At operation 202, UE 104 and MN authenticator 107 participates in an authentication procedure. The authentication procedure between the UE 104 and the MN authenticator 107 authenticates the UE 104 for the subscription. From the authentication procedure, UE 104 obtains an identifier of the authentication procedure and or more cryptographic keys for the UE. The identifier of the authentication procedure (or authentication procedure ID) identifies the authentication procedure between UE 104 and the MN authenticator 107. The authentication is possible if the user of the UE 104 owns a valid identity on an HLR (Home Location Register) or on an HSS (Home Subscriber Server) of the mobile network. This identity is associated with a subscription to a service in the mobile network. The authentication procedure includes an exchange of messages between UE 104 and the MN authenticator 107. In some embodiments, the authentication procedure may involve an exchange of messages between the MN authenticator 107 and an HLR or HSS of the mobile network. In some embodiments, the authentication procedure can further enable authentication of the MN authenticator for UE 104. UE 104 may be in possession of a secret (e.g., a secret cryptographic key) that is shared with the MN authenticator 107, which can be used for mutual authentication of the UE 104 and the MN authenticator 107. In some embodiments, the shared secret is stored in a subscriber identity module (SIM) of the UE 104, which can also be referred to as a subscriber identification module, or a SIM card. The SIM can be a physical SIM or a virtual SIM. In a non-limiting example, the authentication procedure can be a bootstrapping authentication procedure from the Generic Bootstrap Architecture (GBA), for example 3rd Generation Partnership Project (3GPP) Authentication and Key Agreement (AKA) protocol. In this example, the ID of the authentication procedure is Bootstrapping Transaction Identifier (B-TID).

[0046] In some embodiments, the authentication procedure is launched when UE 104 initiates the generation of a transaction that is to be stored in the DL network 101. In some embodiments, the authentication procedure can be part of a process for generating and submitting the transaction to the DL network implemented in the UE 104. In some embodiments, the authentication procedure can be requested by a DL node of the DL network 101 from UE 104 after UE 104 has attempted to submit a transaction in the DL network 101 without authentication.

[0047] At operation 204, UE 104 generates an authentication parameter based on a subscription identifier (here subscription ID) that is associated with the subscription for which the UE 104 was authenticated. The subscription ID uniquely identifies the subscription in the mobile network. For example, the subscription ID can be an international mobile subscriber identity (IMSI). The authentication parameter is further generated based on the cryptographic keys obtained from the authentication procedure. In some embodiments, generating the authentication parameter includes using the identifier of the subscription and the one or more cryptographic keys as inputs of a cryptographic function to obtain the authentication parameter. In some embodiments, the payload of the transaction is also used as an input to the cryptographic function. The cryptographic function allows to prove authenticity of the transaction and the integrity of the transaction. For example, the cryptographic function allows to prove that the subscriber of the mobile network is the originator of the transaction. When the authentication parameter is generated using the payload of the transaction as input, the authentication parameter can be used to prove integrity of the payload, i.e., that the payload was not tampered with. In some embodiments, the cryptographic function is a message authentication code (MAC). In some embodiments, the cryptographic function is a hashing function. For example, the generation of the authentication parameters is performed with a hashbased message authentication code (HMAC) with the keys obtained from the authentication procedure, the subscription ID, and optionally the payload of the transaction as inputs.

[0048] At operation 206, UE 104 submits a first transaction to be stored in the digital ledger 101 A of the DL network 101. The transaction includes a payload, the identifier of the authentication procedure, and the authentication parameter. The authentication parameter is to be used to prove that the UE 104 is a valid UE for the subscription and to bind the transaction to the subscription. In some embodiments, the transaction further includes an identifier of the mobile network 105. In some embodiments, submitting the first transaction includes storing, by the UE 104, the transaction in the digital ledger of the DL network 101. For example, when UE 104 is a DL node in the DL network 101, the UE 104 is operative to store the transaction in the digital ledger. In some embodiments, submitting the transaction can includes transmitting from the UE 104 to a DL node 102 A of the DL network 101 a request for the transaction. The request for the transaction causes the DL node 102 A to store the transaction in the digital ledger 110A of the DL network 101.

[0049] In some embodiments, when the transaction is stored in the digital ledger, it is initially marked as pending authentication until validation of the transaction is performed as described with reference to Fig. 2B. In other embodiments, the transaction can be marked as invalid until validation of the transaction is performed as described with reference to Fig. 2B. In other embodiments, the transaction is considered valid and can be authenticated based on the authentication parameter.

Validation of the first transaction

[0050] Fig. 2B illustrates a block diagram of exemplary operations that can be performed in a DL network for validating the first transaction, in accordance with some embodiments. [0051] At operation 212, the transaction validator 108 receives a first transaction 112 stored in the digital ledger 110 of the DL network 101. The first transaction 112 includes a payload, an authentication parameter, and an identifier of the authentication procedure. The authentication parameter results from an authentication procedure between a UE and a network node of a mobile network for authenticating the UE in association with a subscription in the mobile network. For example, the authentication procedure is performed between UE 104 and MN authenticator 107. The authentication parameter binds the first transaction 112 to the subscription 113. In some embodiments, the first transaction 112 further includes an identifier of the mobile network. The identifier of the mobile network identifies the mobile network that authenticated the UE with respect to the transaction.

[0052] In some embodiments, the flow of operations moves to operation 214. In other embodiments, the operation 214 is optional and can be skipped. For example, the system 100 is implemented for a single mobile network operator and the transaction validator is always authorized to verify transactions for the mobile network operator. In another example, the system 100 may be implemented for multiple mobile network operators and the transaction validator 108 is authorized to validate transactions for the multiple network operators. Alternatively, a transaction validator 108 can be authorized to validate transactions of a subset of multiple network operators (e.g., one or more MNOs) and the operation 214 is performed.

[0053] At operation 214, the transaction validator 108 determines whether the network node is authorized to validate the first transaction 112. In some embodiments, determining that the network node is authorized to validate the first transaction is performed based on an identifier of the mobile network operator. The identifier of the mobile network operator is included in the first transaction. The transaction validator 108 verifies that the network node is associated with the identifier of the mobile network. Upon determining that it is associated with the ID of the mobile network, the transaction validator 108 confirms that it is authorized to validate the first transaction and the flow moves to operation 216 or to operation 220. Upon determining that it is not associated with the ID of the mobile network, the transaction validator 108 determines that it is not authorized to validate the first transaction and the process of validation can be terminated. [0054] In some embodiments, the flow of operations moves to operation 220 and operation 216 is optional. For example, when verification of the authenticity of the transaction can be performed without cryptographic keys or subscription ID, operation 216 can be skipped. In other embodiments, the flow of operations moves to operation 216. At operation 216, the transaction validator 108 determines one or more second cryptographic keys and an identifier of the subscription (subscription ID) in the mobile network based on the identifier of the authentication procedure. In some embodiments, the determination of the second cryptographic keys and the subscription ID is performed by participating in an authentication procedure with the MN authenticator 107 of the mobile network 105. During the authentication procedure, the transaction validator 108 transmits the ID of the authentication procedure to the MN authenticator 107, and receives the second cryptographic keys and the subscription ID from the MN authenticator. In some embodiments, during the authentication procedure, the transaction validator 108 transmits the ID of the authentication procedure to the MN authenticator 107, and receives data from the MN authenticator that is used for generating at least one of the cryptographic keys and the subscription ID. In a non-limiting example, the transaction validator 108 and the MN authenticator 107 can participate in a bootstrapping usage procedure of the GBA. In some embodiments, the determination of the second cryptographic keys and the subscription ID is performed by accessing a data structure (e.g., a database, the digital ledger, or other) using the ID of the authentication procedure as a key without the need to communicate with the MN authenticator 107. In some embodiments, the data structure can be stored in the transaction validator 108. In other embodiments, the data structure can be stored in a different network node that is remote from but accessible to the transaction validator through a network. The data structure can be accessible by one or more transaction validators 108.

[0055] In some embodiments, the second cryptographic keys obtained by the transaction validator are the same as the first cryptographic keys obtained by the UE 104 during the first authentication procedure. In other embodiments, the second cryptographic keys obtained by the transaction validator 108 are different from the ones obtained by UE 104 during the first authentication procedure. The second cryptographic keys of the transaction validator 108 enable the verification of the authentication parameter of the first transaction.

[0056] At operation 218, the transaction validator 108 determines whether the second cryptographic keys, the authentication parameter, or the identifier of the authentication procedure (authentication procedure ID) have been revealed. For example, the transaction validator 108 may determine whether the digital ledger 110 includes another transaction that is different from the first transaction and which includes the same cryptographic keys, the same authentication parameter, or the same authentication procedure ID. In another example, the transaction validator 108 determines whether at least one of the second cryptographic keys, the authentication parameter, or the authentication procedure ID is blacklisted. Upon determining that the second cryptographic keys, the authentication parameter, or the authentication procedure ID have not been revealed, the flow of operations moves to operation 220. Alternatively, in response to determining that one of the second cryptographic keys, the authentication parameter, or the authentication procedure ID is revealed, the first transaction is determined to be invalid. [0057] At operation 220, the transaction validator 108 verifies authenticity of the first transaction. The transaction validator verifies authenticity of the first transaction 112 based on the authentication parameter and the identifier of the authentication procedure. In some embodiments, the verification of the authenticity of the first transaction includes verifying based on the authentication parameter that the first transaction originated from UE 104 that is authenticated by the mobile network for a valid subscription in the mobile network 105. In other words, verifying authenticity of the first transaction 112 includes verifying that the UE 104 from which the transaction originated is a valid user of an existing subscription for a service in the mobile network 105. In some embodiments, verifying authenticity of the first transaction further includes verifying that the payload of the first transaction has not been tempered with.

[0058] In some embodiments, the verification of the authenticity of the transaction includes determining a verification parameter based on the second cryptographic keys and the subscription ID. The verification parameter can be used in combination with the authentication parameter of the first transaction to validate authenticity of the first transaction. For example, the verification parameter can be compared to the authentication parameter. In some embodiments, the verification parameter is a data structure that includes the first cryptographic keys and the subscription ID.

[0059] In one embodiment, the transaction validator 108 determines the verification parameter based on the subscription ID. The verification parameter is further determined based on the second cryptographic keys. In some embodiments, generating the verification parameter includes using the subscription ID and the second cryptographic keys as inputs of a cryptographic function to obtain the verification parameter. In some embodiments, the payload of the transaction is also used as an input to the cryptographic function. In some embodiments, the cryptographic function can be the same as the one used for the generation of the authentication parameter. Alternatively, the cryptographic function can be different. The cryptographic function allows to determine authenticity of the first transaction and the integrity of the first transaction. In some embodiments, the cryptographic function is a MAC. In some embodiments, the cryptographic function is a hashing function. For example, the generation of the authentication parameters is performed with a HMAC with the second cryptographic keys, the subscription ID, and optionally the payload of the transaction as inputs.

[0060] In some embodiments, the transaction validator 108 verifies that the first transaction is authenticated when the verification parameter is identical to the authentication parameter. In some embodiments, the transaction validator 108 verifies that the first transaction is authenticated when the inputs used for the generation of the authentication parameter (e.g., the subscription ID, the first cryptographic keys, and/or the payload of the transaction) are retrieved from the authentication parameter. Retrieving the inputs can be performed by applying an inverse function on the authentication parameter. Other mechanism of authentication verification can be used without departing from the scope of the embodiments herein.

[0061 ] Responsive to verifying authenticity of the first transaction, the transaction is considered valid. Thus, the authentication of the transaction with respect to a subscription in the mobile network, based on the authentication parameter, allows to validate the transaction at the DL network level. The embodiments herein allow to rely on an authentication mechanism of the mobile network to bind a transaction in a DL network with an identity of a subscriber (i.e., a subscription) in the mobile network. In some embodiments, once the transaction is considered valid, the transaction validator 108 can perform operation 224. At operation 224, the transaction validator submits a second transaction including the verification parameter to be inserted in the digital ledger 110 of the DL network 101. The verification parameter is to be used to validate the first transaction in the DL network. The verification parameter can be used by other nodes in the DL network for verifying that the first transaction is valid. In some embodiments, the transaction can be marked as valid and the other nodes do not need to rely on the verification parameter for validating the first transaction. For example, the transaction can be marked as valid in a data structure stored in the digital ledger 110. In some embodiments, the validation of the first transaction can be performed through a consensus mechanism in which two or more DL nodes of the DL network verify the authenticity of the first transaction. In these embodiments, the first transaction is considered valid (operation 322) after two or more DL nodes agree through the consensus mechanisms by verifying its authenticity.

[0062] Responsive to determining that the first transaction is not authenticated at operation 220, the first transaction is considered invalid.

Operations

[0063] Fig. 3 A illustrates a flow diagram of exemplary operations that can be performed in a DL network for binding a subscription’s identity in a mobile network to transactions in the DL network, in accordance with some embodiments. In some embodiments, the operations of Fig.

3 A can be performed by UE 104. In some embodiments, the operations of Fig. 3 A can be performed by a combination of UE 104 and a DL node 102 A of the DL network 101.

[0064] At operation 302, UE 104 participates in an authentication procedure with a network device of the mobile network. The network device implements the MN authenticator 107. The authentication procedure between the UE 104 and the MN authenticator 107 authenticates the UE 104 for the subscription. UE 104 obtains an identifier of the authentication procedure, also referred to herein as authentication ID, and one or more cryptographic keys from the authentication procedure. The identifier of the authentication procedure (or authentication procedure ID) identifies the authentication procedure between UE 104 and the MN authenticator 107.

[0065] In some embodiments, the authentication procedure is launched when UE 104 initiates the generation of a transaction that is to be inserted in the DL network 101. In some embodiments, the authentication procedure can be part of a process for generating and submitting the transaction to the DL network implemented in the UE 104. In some embodiments, the authentication procedure can be requested by a DL node of the DL network 101 from UE 104 after UE 104 has attempted to submit a transaction in the DL network 101 without authentication.

[0066] The flow of operations moves to operation 304. At operation 304, UE 104 generates an authentication parameter based on a subscription identifier (here subscription ID) that is associated with the subscription for which the UE 104 was authenticated. The subscription ID uniquely identifies the subscription in the mobile network. For example, the subscription ID can be an international mobile subscriber identity (IMSI). The authentication parameter is further generated based on the cryptographic keys obtained from the authentication procedure. In some embodiments, generating the authentication parameter includes using the identifier of the subscription and the one or more cryptographic keys as inputs of a cryptographic function to obtain the authentication parameter. In some embodiments, the payload of the transaction is also used as an input to the cryptographic function. The cryptographic function allows to prove authenticity of the transaction and the integrity of the transaction. For example, the cryptographic function allows to prove that the subscriber of the mobile network is the originator of the transaction. When the authentication parameter is generated using the payload of the transaction as input, the authentication parameter can be used to prove integrity of the payload, i.e., that the payload was not tampered with. In some embodiments, the cryptographic function is a MAC. In some embodiments, the cryptographic function is a hashing function. For example, the generation of the authentication parameters is performed with a HMAC with the keys obtained from the authentication procedure, the subscription ID, and optionally the payload of the transaction as inputs.

[0067] The flow of operations moves to operation 306. At operation 306, UE 104 submits a first transaction to be stored in the digital ledger 101 A of the DL network (101). The transaction includes a payload, the identifier of the authentication procedure, and the authentication parameter. The authentication parameter is to be used to prove that the UE 104 is a valid UE for the subscription and to bind the transaction to the subscription. In some embodiments, the transaction further includes an identifier of the mobile network 105. In some embodiments, submitting the first transaction includes operation 308 or operation 310. At operation 308, UE 104 stores the transaction in the digital ledger of the DL network 101. For example, when UE 104 is a DL node in the DL network 101, UE 104 is operative to store the transaction in the digital ledger. At operation 310, UE 104 transmits to a DL node 102 A of the DL network 101 a request for the transaction. The request for the transaction causes the DL node 102 A to store the transaction in the digital ledger 110A of the DL network 101.

[0068] In some embodiments, when the transaction is stored in the digital ledger, it is initially marked as pending authentication until validation of the transaction is performed as described with reference to Fig. 3B. In other embodiments, the transaction can be marked as invalid until validation of the transaction is performed as described with reference to Fig. 3B. In other embodiments, the transaction is considered valid and can be authenticated based on the authentication parameter.

[0069] Fig. 3B illustrates a flow diagram of exemplary operations that can be performed for validating transactions stored in a digital ledger of a distributed ledger (DL) network, in accordance with some embodiments. In some embodiments, the operations of Fig. 3B are performed by a transaction validator 108. In some embodiments, the transaction validator is part of a DL node in the DL network 101. In some embodiments, several DL nodes of the DL network 101 may include a transaction validator and are operative to perform the operations described herein with respect to Fig. 3B for validation of the first transaction.

[0070] At operation 312, the transaction validator receives a first transaction 112 stored in the digital ledger 110 of the DL network 101. The first transaction 112 includes a payload, an authentication parameter, and an identifier of the authentication procedure. The authentication parameter results from an authentication procedure between a user equipment and a network device node of a mobile network for authenticating the UE in association with a subscription in the mobile network. For example, the authentication procedure is performed between UE 104 and MN authenticator 107. The authentication parameter binds the first transaction 112 to the subscription 113. In some embodiments, the first transaction 112 further includes an identifier of the mobile network. The identifier of the mobile network identifies the mobile network that authenticated the UE with respect to the transaction.

[0071] In some embodiments, the flow of operations moves to operation 314. In other embodiments, the operation 314 is optional and can be skipped. For example, the system 100 is implemented for a single mobile network operator and the transaction validator is always authorized to verify transactions for the mobile network operator. In another example, the system 100 may be implemented for multiple mobile network operators and the transaction validator 108 is authorized to validate transactions for the multiple network operators. Alternatively, a transaction validator 108 can be authorized to validate transactions of a subset of multiple network operators (e.g., one or more MNOs) and the operation 314 is performed.

[0072] At operation 314, the transaction validator 108 determines whether the network node is authorized to validate the first transaction 112. In some embodiments, determining that the network node is authorized to validate the first transaction is performed based on an identifier of the mobile network operator. The identifier of the mobile network operator is included in the first transaction. The transaction validator 108 verifies that the network node is associated with the identifier of the mobile network. Upon determining that it is associated with the ID of the mobile network, the transaction validator 108 confirms that it is authorized to validate the first transaction and the flow moves to operation 316 or to operation 320. Upon determining that it is not associated with the ID of the mobile network, the transaction validator 108 determines that it is not authorized to validate the first transaction and the process of validation can be aborted. [0073] In some embodiments, the flow of operations moves to operation 320 and operation 316 and/or 318 are optional. For example, when verification of the authenticity of the transaction can be performed without cryptographic keys or subscription ID, operation 316 can be skipped. In other embodiments, the flow of operations moves to operation 316. At operation 316, the transaction validator 108 determines one or more second cryptographic keys and an identifier of the subscription (subscription ID) in the mobile network based on the identifier of the authentication procedure. In some embodiments, the determination of the second cryptographic keys and the subscription ID is performed by participating in an authentication procedure with the MN authenticator 107 of the mobile network 105. During the authentication procedure, the transaction validator 108 submits the ID of the authentication procedure to the MN authenticator 107. In a non-limiting example, the transaction validator 108 and the MN authenticator 107 can participate in a bootstrapping usage procedure of the GBA. In some embodiments, the determination of the second cryptographic keys and the subscription ID is performed by accessing a data structure (e.g., a database, the digital ledger, or other) using the ID of the authentication procedure as a key without the need to communicate with the MN authenticator 107. In some embodiments, the data structure can be stored in the transaction validator 108. In other embodiments, the data structure can be stored in a different network node that is remote from the transaction validator. The data structure can be accessible by one or more transaction validators 108.

[0074] The transaction validator 108 obtains the cryptographic keys and the subscription ID associated with the ID of the authentication procedure. In some embodiments, the second cryptographic keys obtained by the transaction validator are the same as the first cryptographic keys obtained by the UE 104 during the first authentication procedure. In other embodiments, the second cryptographic keys obtained by the transaction validator 108 are different from the ones obtained by UE 104 during the first authentication procedure. The second cryptographic keys of the transaction validator 108 enable the verification of the authentication parameter in the first transaction.

[0075] The flow of operations moves to operation 318. In some embodiments, the operation 318 is optional and can be skipped. At operation 318, the transaction validator 108 determines whether the second cryptographic keys or the subscription ID have been revealed. For example, the transaction validator 108 may determine whether the digital ledger 110 includes another transaction that is different from the first transaction and which includes the same cryptographic keys, the authentication parameter, or the authentication procedure ID. In another example, the transaction validator 108 determines whether at least one of the second cryptographic keys, the authentication parameter, or the authentication procedure ID is blacklisted. Upon determining that the second cryptographic keys, the authentication parameter, or the authentication procedure ID have not been revealed, the flow of operations moves to operation 320. Alternatively, in response to determining that one of the second cryptographic keys, the authentication parameter, or the authentication procedure ID is revealed, the flow of operations moves to operation 326. At operation 326, the first transaction is determined to be invalid.

[0076] At operation 320, the transaction validator 108 verifies authenticity of the first transaction. In some embodiments, the verification of the authenticity of the first transaction is performed in response to determining that the second cryptographic keys, the authentication parameter, and the authentication procedure ID have not been revealed. At operation 320, the transaction validator verifies authenticity of the first transaction 112 based on the authentication parameter and the identifier of the authentication procedure. In some embodiments, the verification of the authenticity of the first transaction includes verifying based on the authentication parameter that the first transaction originated from UE 104 that is authenticated by the mobile network for a valid subscription in the mobile network 105. In other words, verifying authenticity of the first transaction 112 includes verifying that the UE 104 from which the transaction originated is a valid user of an existing subscription for a service in the mobile network 105. In some embodiments, verifying authenticity of the transaction further includes verifying that the payload has not been tempered with.

[0077] In some embodiments, the verification of the authenticity of the transaction includes determining a verification parameter based on the second cryptographic keys and the subscription ID. The verification parameter is used to validate the authentication parameter. For example, the verification parameter can be compared to the authentication parameter. In another example, the verification parameter can be used to retrieve from the authentication parameter the inputs used for the generation of the authentication parameter (e.g., the subscription ID, the first cryptographic keys, and/or the payload of the transaction). In some embodiments, the verification parameter is a data structure that includes the first cryptographic keys and the subscription ID.

[0078] In one embodiment, the transaction validator 108 determines the verification parameter based on the subscription ID. The verification parameter is further generated based on the first and/or second cryptographic keys. In some embodiments, determining the verification parameter includes using the subscription ID and the second cryptographic keys as inputs of a cryptographic function to obtain the verification parameter. In some embodiments, the payload of the transaction is also used as an input to the cryptographic function. In some embodiments, the cryptographic function can be the same as the one used for the generation of the authentication parameter. Alternatively, the cryptographic function can be different. The cryptographic function allows to determine authenticity of the transaction and the integrity of the transaction. In some embodiments, the cryptographic function is a MAC. In some embodiments, the cryptographic function is a hashing function. For example, the generation of the authentication parameters is performed with a HMAC with the second cryptographic keys, the subscription ID, and optionally the payload of the transaction as inputs.

[0079] In some embodiments, the transaction validator 108 verifies that the first transaction is authenticated when the verification parameter is identical to the authentication parameter. In some embodiments, the transaction validator 108 verifies that the first transaction is authenticated when the inputs used for the generation of the authentication parameter (e.g., the subscription ID, the first cryptographic keys, and/or the payload of the transaction) are retrieved from the authentication parameter. Retrieving the inputs can be performed by applying an inverse function on the authentication parameter. Other mechanism of authentication verification can be used without departing from the scope of the embodiments herein.

[0080] Responsive to verifying authenticity of the first transaction, the flow of operations moves to operation 322, at which the transaction is considered valid. Thus, the authentication of the transaction with respect to a subscription in the mobile network, based on the authentication parameter, allows to validate the transaction at the DL network level. The embodiments herein allow to rely on an authentication mechanism of the mobile network to bind a transaction in a DL network with an identity of a subscriber (i.e., a subscription) in the mobile network. In some embodiments, once the transaction is considered valid, the transaction validator 108 can perform operation 324. At operation 324, the transaction validator submits a second transaction including the verification parameter to be inserted in the digital ledger 110 of the DL network 101. The verification parameter is to be used to validate the first transaction in the DL network. The verification parameter can be used by other nodes in the DL network for verifying that the first transaction is valid. In some embodiments, the transaction can be marked as valid at operation 322, and the other nodes do not need to rely on the verification parameter for validating the first transaction. For example, the transaction can be marked as valid in a data structure stored in the digital ledger 110. In some embodiments, the validation of the first transaction can be performed through a consensus mechanism in which two or more DL nodes of the DL network verify the authenticity of the first transaction. In these embodiments, the first transaction is considered valid (operation 322) after two or more DL nodes agree through the consensus mechanisms by verifying its authenticity.

[0081] Responsive to determining that the first transaction is not authenticated at operation 320, the flow of operations moves to operation 326. At operation 326, the first transaction is considered invalid. In some embodiments, the transaction can be marked as invalid in the digital ledger.

Architecture:

[0082] An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, solid state drives, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors (e.g., wherein a processor is a microprocessor, controller, microcontroller, central processing unit, digital signal processor, application specific integrated circuit, field programmable gate array, other electronic circuitry, a combination of one or more of the preceding) coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code/data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower nonvolatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set or one or more physical network interface(s) (NI(s)) to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. For example, the set of physical NIs (or the set of physical NI(s) in combination with the set of processors executing code) may perform any formatting, coding, or translating to allow the electronic device to send and receive data whether over a wired and/or a wireless connection. In some embodiments, a physical NI may comprise radio circuitry capable of receiving data from other electronic devices over a wireless connection and/or sending data out to other devices via a wireless connection. This radio circuitry may include transmitted s), received s), and/or transceiver(s) suitable for radiofrequency communication. The radio circuitry may convert digital data into a radio signal having the appropriate parameters (e.g., frequency, timing, channel, bandwidth, etc.). The radio signal may then be transmitted via antennas to the appropriate recipient(s). In some embodiments, the set of physical NI(s) may comprise network interface controller(s) (NICs), also known as a network interface card, network adapter, or local area network (LAN) adapter. The NIC(s) may facilitate in connecting the electronic device to other electronic devices allowing them to communicate via wire through plugging in a cable to a physical port connected to a NIC. One or more parts of an embodiment of the disclosure may be implemented using different combinations of software, firmware, and/or hardware.

[0083] A network device (ND) is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, end-user devices). Some network devices are “multiple services network devices” that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 aggregation, session border control, Quality of Service, and/or subscriber management), and/or provide support for multiple application services (e.g., data, voice, and video, etc.). In the embodiments described above the components of the DL network 101 can be implemented on one or more network devices coupled through a physical network. For example, each of the DL nodes 102A-N, the transaction validator 108, the MN authenticator 107 can be implemented on one ND or distributed over multiple NDs.

[0084] Fig. 4 illustrates a block diagram for a ND that can be used for implementing one or more of the nodes described herein, in accordance with some embodiments. According to one embodiment, the ND is an electronic device which includes hardware 405. Hardware 405 includes one or more processors 414, network communication interfaces 460 coupled with a computer readable storage medium 412. The computer readable storage medium 412 may include a computer program 411.

[0085] While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization - represented by a virtualization layer 420. In these embodiments, the instance 440 and the hardware that executes it form a virtual server which is a software instance of the modules stored on the computer readable storage medium 412. [0086] The computer program 411 includes instructions which when executed by the hardware 405 causes the instance 440 to perform the operations described with reference to Figs. 1-3B. In this embodiment, the DL node 102A is implemented on a single network device.

[0087] Fig. 5 illustrates an exemplary embodiment in which a node is implemented on multiple network devices. In the illustrated example, the DLT node 500 is distributed over multiple network devices 530A-530K, where each network device has a similar architecture as network device 430. The multiple network devices 530A-530K are coupled through one or more links and can be located in a same geographical location or remote from one another. The operations described with reference to the embodiments of Figs. 1-3B can be distributed over the multiple network devices, such as each network device is operative to perform a subset of the operations described herein.

[0088] Fig. 6 illustrates an exemplary embodiment of a user equipment, in accordance with some embodiments. UE 104 includes software 601 and hardware 605. The hardware 605 may include a radio interface 607 configured to set up and maintain a wireless connection with a base station of the mobile network 105 serving a coverage area in which the UE 604 is currently located. The hardware 605 of the UE 104 further includes processing circuitry 608, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 104 further comprises software 601, which is stored in or accessible by the UE 104 and executable by the processing circuitry 608. The software 601 includes a client application 602. The client application 602 may be operable to provide a service to a human or non-human user via the UE 104.

[0089] While the flow diagrams in the figures show a particular order of operations performed by certain embodiments of the disclosure, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0090] While the disclosure has been described in terms of several embodiments, those skilled in the art will recognize that the disclosure is not limited to the embodiments described, can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.

Claims

CLAIMS What is claimed is:

1. A method in a network node of validating transactions stored in a digital ledger of a distributed ledger (DL) network (101), the method comprising: receiving (212, 312) a first transaction (112) stored in the digital ledger (110A) of the DL network (101), wherein the first transaction (112) includes a payload, an authentication parameter that results from an authentication procedure between a user equipment (UE) (104) and a network node (107) of a mobile network for authenticating the UE in association with a subscription in the mobile network and the authentication parameter binds the first transaction (112) to the subscription, and an identifier of the authentication procedure; verifying (220, 320) authenticity of the first transaction (112) based on the authentication parameter and the identifier of the authentication procedure; and responsive to verifying (220, 320) authenticity of the first transaction, determining that the first transaction (112) is valid in the DL network (101).

2. The method of claim 1, wherein responsive to verifying (220, 320) authenticity of the first transaction (112), further submitting (224, 324) a second transaction (114) including a verification parameter to be inserted in the digital ledger (110) of the DL network (101), wherein the verification parameter is to be used to validate the first transaction (112) in the DL network (ioi).

3. The method of any one of claims 1-2, wherein the verifying (220, 320) authenticity of the first transaction (112) includes: determining (216, 316) based on the identifier of the authentication procedure one or more cryptographic keys and an identifier of the subscription in the mobile network; determining (218, 318) whether the one or more cryptographic keys, the authentication parameter, or the identifier of the authentication procedure have been revealed; and wherein the verifying (220, 320) authenticity of the first transaction (112) is performed in response to determining that the one or more cryptographic keys, the authentication parameter, and the identifier of the authentication procedure have not been revealed.

25

4. The method of any one of claims 1-3 further comprising: determining (214, 314) whether the network node is authorized to validate the first transaction (112); and wherein the verifying (220, 320) authenticity of the first transaction (112) is performed in response to determining (214, 314) that the network node is authorized to validate the first transaction (112).

5. The method of any one of claims 3-4, wherein the verifying (220, 320) authenticity of the first transaction (112) includes using the one or more cryptographic keys and the identifier of the subscription as inputs of a hashing function to determine the verification parameter.

6. The method of any one of claims 3-5, the verifying (220, 320) authenticity of the first transaction (112) includes using the payload of the first transaction (112) as input.

7. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any one of claims 1-6.

8. A non-transitory readable storage medium that stores the computer program of claim 7, which when executed by the at least one processor causes the at least one processor to perform the method according to any one of claims 1-6.

9. A network device for validating transactions stored in a digital ledger of a distributed ledger (DL) network (101), the network device comprising: one or more processors; and a computer readable storage medium storing instructions which when executed by the one or more processors cause the network device to perform operations including: receiving (212, 312) a first transaction (112) stored in the digital ledger (110A) of the DL network (101), wherein the first transaction (112) includes a payload, an authentication parameter that results from an authentication procedure between a user equipment (UE) (104) and a network node (107) of a mobile network for authenticating the UE in association with a subscription in the mobile network and the authentication parameter binds the first transaction (112) to the subscription, and an identifier of the authentication procedure; verifying (220, 320) authenticity of the first transaction (112) based on the authentication parameter and the identifier of the authentication procedure; and responsive to verifying (220, 320) authenticity of the first transaction, determining that the first transaction (112) is valid in the DL network (ioi).

10. The network device of claim 9, wherein responsive to verifying (220, 320) authenticity of the first transaction (112), further submitting (224, 324) a second transaction (114) including a verification parameter to be inserted in the digital ledger (110) of the DL network (101), wherein the verification parameter is to be used to validate the first transaction (112) in the DL network (101).

11. The network device of any one of claims 9-10, wherein the verifying (220, 320) authenticity of the first transaction (112) includes: determining (216, 316) based on the identifier of the authentication procedure one or more cryptographic keys and an identifier of the subscription in the mobile network; determining (218, 318) whether the one or more cryptographic keys, the authentication parameter, or the identifier of the authentication procedure have been revealed; and wherein the verifying (220, 320) authenticity of the first transaction (112) is performed in response to determining that the one or more cryptographic keys, the authentication parameter, and the identifier of the authentication procedure have not been revealed.

12. The network device of any one of claims 9-11, wherein the operations further comprise: determining (214, 314) whether the network node is authorized to validate the first transaction (112); and wherein the verifying (220, 320) authenticity of the first transaction (112) is performed in response to determining (214, 314) that the network node is authorized to validate the first transaction (112).

13. The network device of any one of claims 11-12, wherein the verifying (220, 320) authenticity of the first transaction (112) includes using the one or more cryptographic keys and the identifier of the subscription as inputs of a hashing function to determine the verification parameter.

14. The network device of any one of claims 11-13, the verifying (220, 320) authenticity of the first transaction (112) includes using the payload of the first transaction (112) as input.

15. A method of binding a subscriber’s identity in a mobile network to transactions in a distributed ledger (DL) network (101), the method comprising: generating (204, 304), in a user equipment (UE) (104) and based on an identifier of a subscription in the mobile network and one or more cryptographic keys obtained through an authentication procedure between the UE (104) and a network device of the mobile network that authenticates the user equipment as a valid UE for the subscription, an authentication parameter; and submitting (206, 306) a transaction (112) to be stored in a digital ledger of the DL network (101), wherein the transaction (112) includes a payload, an identifier of the authentication procedure, and the authentication parameter that is to be used to prove that the UE (104) is a valid UE for the subscription and to bind the transaction (112) to the subscription.

16. The method of claim 15 further including: participating (202, 302) in the authentication procedure with the network device of the mobile network to authenticate the UE (104) for the subscription and obtain the or more cryptographic keys for the UE (104) and the identifier of the authentication procedure.

17. The method of any one of claims 15-16, wherein the transaction (112) further includes an identifier of the mobile network.

18. The method of any one of claims 15-17, wherein the generating (204, 304) the authentication parameter includes using the identifier of the subscription and the one or more cryptographic keys as inputs of a hashing function to obtain the authentication parameter.

19. The method of any one of claims 15-18, wherein the generating (204, 304) the authentication parameter includes using the payload of the transaction (112) as input.

20. The method of any one of claims 15-19, wherein the submitting (206, 306) the transaction (112) to be inserted in the digital ledger of the DL network (101) includes: storing (308), by the UE (104), the transaction (112) in the digital ledger of the DL network (101).

28

21. The method of any one of claims 15-19, wherein the submitting (206, 306) the transaction (112) to be inserted in the digital ledger of the DL network (101) includes: transmitting (310) from the UE (104) to a DL node (102) of the DL network (101) a request for the transaction (112) that causes the DL node (102) to store the transaction (112) in the digital ledger (110A) of the DL network (101).

22. A computer program comprising instructions which, when executed on at least one processor, cause the at least one processor to carry out a method according to any one of claims 15-21.

23. A non-transitory readable storage medium that stores the computer program of claim 22, which when executed by the at least one processor causes the at least one processor to perform the method according to any one of claims 15-21.

24. A system (100) for binding a subscriber’s identity in a mobile network to transactions in a distributed ledger (DL) network, the system comprising: one or more processors; and one or more computer readable storage media storing instructions which when executed by the one or more processors cause the system to perform operations including: generating (204, 304), in a user equipment (UE) (104) and based on an identifier of a subscription in the mobile network and one or more cryptographic keys obtained through an authentication procedure between the UE (104) and a network device of the mobile network that authenticates the user equipment as a valid UE for the subscription, an authentication parameter; and submitting (206, 306) a transaction (112) to be stored in a digital ledger of the DL network (101), wherein the transaction (112) includes a payload, an identifier of the authentication procedure, and the authentication parameter that is to be used to prove that the UE (104) is a valid UE for the subscription and to bind the transaction (112) to the subscription.

25. The system of claim 24, wherein the operations further include: participating (202, 302) in the authentication procedure with the network device of the mobile network to authenticate the UE (104) for the subscription and obtain the or more cryptographic keys for the UE (104) and the identifier of the authentication procedure.

29

26. The system of any one of claims 24-25, wherein the transaction (112) further includes an identifier of the mobile network.

27. The system of any one of claims 24-26, wherein the generating (204, 304) the authentication parameter includes using the identifier of the subscription and the one or more cryptographic keys as inputs of a hashing function to obtain the authentication parameter.

28. The system of any one of claims 24-27, wherein the generating (204, 304) the authentication parameter includes using the payload of the transaction (112) as input.

29. The system of any one of claims 24-28, wherein the submitting (206, 306) the transaction (112) to be inserted in the digital ledger of the DL network (101) includes: storing (308), by the UE (104), the transaction (112) in the digital ledger of the DL network (101).

30. The system of any one of claims 24-29, wherein the submitting (206, 306) the transaction (112) to be inserted in the digital ledger of the DL network (101) includes: transmitting (310) from the UE (104) to a DL node (102) of the DL network (101) a request for the transaction (112) that causes the DL node (102) to store the transaction (112) in the digital ledger (110A) of the DL network (101).

30