The present disclosure relates to identification and monitoring of devices of a network.
Large-scale dynamic networks such as 4G (LTE/LTE-Advanced) and 5G networks connect billions of heterogeneous devices produced by different manufacturers and managed by a range of network operators. As such, identifying a device in order to determine if it is trustworthy is a complicated task. First, most devices do not have means of authentication. Second, devices may have different software or hardware configurations, and may have been handled by multiple parties—what hampers the task of checking if a device is in a trustworthy state.
One viable option is to collect information on the device lifecycle. However, lifecycle information of a network device, if available, is currently fragmented across databases of manufacturers, supply-chain parties, network companies, cloud service providers and end-users. Most of the time such databases are private. In addition, even when public, there is no means to verify that the information available has not been maliciously manipulated. It is, therefore, difficult to gather information on a device and tell if it is trustworthy.
In an embodiment, the present disclosure provides a method for identification and monitoring of devices of a network. The devices of the network are provided and/or operated by different participating entities. The method includes: setting up a distributed ledger network, where each of the participating entities maintains one or multiple nodes in the distributed ledger network; setting up a public key infrastructure that assigns each device, before being deployed to the network, a unique certified public key; and keeping an updated status of the devices in a ledger of the distributed ledger network by identifying, by the participating entities, a change of a status of a device and issuing a transaction related to the status change of the device to the ledger. The device's public key is recorded in the transaction.
Subject matter of the present disclosure will be described in even greater detail below based on the exemplary figures. All features described and/or illustrated herein can be used alone or combined in different combinations. The features and advantages of various embodiments will become apparent by reading the following detailed description with reference to the attached drawings, which illustrate the following:
Embodiments of the present disclosure improve and further develop a method and a system for identification and monitoring of devices of a network in a way that facilitates a determination of whether a device is trustworthy or not.
In accordance with embodiments of the disclosure, the aforementioned object is accomplished by a method for identification and monitoring of devices of a network, wherein the devices of the network are provided and/or operated by different participating entities, the method comprising: (a) setting up a distributed ledger network, wherein each of the participating entities maintains one or multiple nodes in the distributed ledger network, (b) setting up a public key infrastructure that assigns each device, before being deployed to the network, a unique certified public key, and (c) keeping an updated status of the devices in a ledger of the distributed ledger network by providing for the execution of: identifying, by the participating entities, a change of a status of a device and issuing a transaction related to the status change of the device to the ledger, wherein the device's public key is recorded in the transaction.
Furthermore, the above mentioned object can be accomplished by a system for identification and monitoring of devices of a network, the system comprising: a plurality of participating entities that provide and/or operate the devices of the network; a public key infrastructure that assigns each device, before being deployed to the network, a unique certified public key; a distributed ledger network, wherein each of the participating entities maintains one or multiple nodes in the distributed ledger network; wherein the participating entities are configured to keep an updated status of the devices in a ledger of the distributed ledger by identifying changes of a status of a device and by issuing a transaction related to the status change of the device to the ledger, wherein the device's public key is recorded in the transaction.
Methods and systems disclosed herein provide a distributed approach to identify and monitor devices of a large-scale dynamic network. In such an environment, different operators deploy heterogeneous devices from a range of manufacturers. As such, information on a given device are fragmented across administrative domains and generally, it is be difficult to tell a genuine device from a counterfeited one.
To address this issue and to enable simplified device identification in a global dynamic network, methods and systems according to embodiments of the disclosure combine a public key infrastructure (PKI) and permissioned distributed ledger technology (DLT) and, in some embodiments, trusted execution environments (TEE). A public key infrastructure provides a) an identity to each device and b) means for a device to prove its identity. In this context, TEEs can ensure that the secret key of a device is not leaked and may allow for verifying (e.g. via remote attestation) the hardware and software configuration of a device.
In embodiments, the distributed ledger provides decentralized storage among participated nodes. Specifically, the ledger may be used to integrate device identity management, device history management, and software update management. Each stakeholder, i.e. each of the participating entities, holds at least one node in a distributed ledger network. Stakeholders can use their nodes within the distributed ledger network to issue and retrieve records to/from the ledger of the distributed ledger network.
According to embodiments, the ledger may be permissioned so that only authorized peers can access/update the ledger. In any case, the ledger provides a robust system because the distributed copies of the data of the ledger prevent single point of failure or attack. Meanwhile, the consensus protocol of the ledger ensures the consistency of the data across all participating nodes by information broadcasting, transaction validation and block mining. As such, the present disclosure provides a distributed database where devices history and status can be queried in order to decide whether a device is trustworthy. At the current status, such information is fragmented across multiple databases that face issues in terms of scalability and integrity.
According to embodiments, device manufacturers or hardware vendors may act as PKI certification authorities and pre-load a unique certified public key in each device at manufacturing time. PKI information may be provided or casted to the distributed ledger to obtain a tamper-proof log of existing network devices and their public keys. Further, any time a network device migrates from one stakeholder to another (e.g., when it is offloaded from the manufacturer to a supply-chain member, e.g. a shipping company, or when it is delivered from a shipping company to the recipient, e.g. a network operator) a record is added to the distributed ledger. Manufacturers may also distribute firmware/software updates for their devices and signal the availability of an update on the distributed ledger.
According to embodiments, a device owner, e.g., a network operator, may run an attestation service that is configured to attests the status of its own devices, for instance periodically or event-based. The type of attestation may depend on the device being attested. If the device has a TEE, the attestation may verify the software running on the device and that the device's public key is certified. If the device has no TEE but presents a public key, the attestation may verify that the device holds the corresponding secret key and that the device manufacturer certifies the public key. If the device has neither a TEE nor a public key, the attestation service may try to identify/fingerprint the device. Independent of the attestation mechanism actually applied, it may be provided that each time a device is attested, the network operator adds a record to the distributed ledger with the result of the attestation.
As such, the distributed ledger can be queried, by authorized parties, on a given device to learn its public key and its history on a) shipping from manufacturing to deployment, b) firmware/software updates, and c) attestation. The acquired information may be fed to a risk assessment service that is configured to decide, based on the device information fetched or learned from the distributed ledger and by applying predefined or configurable risk assessment rules, whether the device is trustworthy or not. In case the risk assessment is successfully passed, the device may be qualified as trustworthy or genuine, and the network operator may put the device into operation and may offer the device connectivity to the network. Otherwise, the network operator may consider the device as being compromised or counterfeit and may reject the device.
There are several ways how to design and further develop teachings of the present disclosure in an advantageous way. To this end it is to be referred to the dependent patent claims on the one hand and to the following description of advantageous embodiments of the disclosure, which by way of example, reference the appended figures. In connection with the explanation of advantageous embodiments of the disclosure with the aid of the figures, generally advantageous embodiments and further developments of the teaching are explained.
Generally, the present disclosure describes methods and systems for identification and monitoring of devices in a network, in particular a large-scale dynamic network, such as a 4G/5G communication network, wherein the devices are provided, operated and/or controlled by different participating entities. Embodiments described hereinafter in detail assume hardware vendors, supply-chain members and network operators to constitute the participating entities of the network. However, as will be appreciated by those skilled in the art, the disclosure is not restricted to these particular participating entities, i.e. further entities with different functionalities, duties, areas of activity and/or responsibilities may likewise participate in the network by providing, operating and/or controlling devices in the network.
According to an embodiment, a distributed ledger network 5 is established where each of the above entities is a member of the ledger network 5. To be a member of the distributed ledger network 5 means that each participating entity maintains one or multiple nodes 6 in the distributed ledger network 5. As such, i.e. via these nodes 6, the participating entities are able to issue and retrieve records to/from a ledger or blockchain of the distributed ledger network 5. Moreover, any of the above entities may also act as a “miner”, thereby participating in the consensus algorithm of the distributed ledger. Hereinafter, the terms distributed ledger and blockchain will be used synonymously.
According to an embodiment, the distributed ledger, which may be implemented as a permissioned distributed ledger, features an identity service. The identity service may be used to provide certified public keys to each of the participating entities of the mobile communication network 1. As such, communication between any two participating entities is authenticated; also, records issued to the distributed ledger are authenticated.
According to an embodiment, the distributed ledger maintains the lifecycle information of all network devices 4 being involved in the mobile communication network 1, possibly within multiple different administrative domains 7. For instance, this enables network operators 3 to check the status of any device 4, both in shipment and in operation, as will be described in more detail below.
The hardware vendors 2 maintain a Public Key Infrastructure (PKI) for the network devices 4, while the private keys of the network devices 4 may be protected in Trusted Computing Bases (TCBs), if the respective device 4 is equipped with a TEE, or in Read-Only Memories (ROMs), if the respective device 4 is not equipped with a TEE. The public keys of the devices 4 will be recorded in transactions that the participating entities issue to the ledger of the distributed ledger network 5. Whenever a status of a device 4 is updated or changed, a respective transaction indicating the updated or changed device status is issued to the distributed ledger network 5 so that the ledger always stores the latest device information. This device information may include information such as the device owner, maintainer, status (shipped/received/deployed/revoked), attestation result, firmware version, etc. According to embodiments of the disclosure, network operators 3 are configured to always check the status of a device 4 before granting access to the device 4 to connect to the network operator's 3 network/administrative domain 7. On the other hand, as indicated by the configuration databases 18, the configuration of the devices 4 in each network, such as routing policies, may be maintained independently by each network operator 3, as it is orthogonal to the lifecycle information of the devices 4.
According to embodiments, the distributed ledger may be used for identity management of all devices 4. In particular, the device status in the supply chain as well as in operation may be updated in the ledger and is thus available to all stakeholders. Furthermore, the distributed ledger may be used, e.g., for the management of the software running on all devices 4, as well as for the management of the history of ownership/lease/rental of every device 4. As will be appreciated by those skilled in the art, further use cases may be envisioned.
According to embodiments, it may be provided that each hardware vendor 2 sets up its own PKI (Public Key Infrastructure) embedding certified public keys in each of its devices 4 before they leave the factory. Public keys are used as identities for the devices 4. If the device 4 has a TEE (Trusted Execution Environment), the device's 4 private key may be saved in the secure storage of the TCB of the device's TEE. Otherwise, the private key may be hardcoded in the device's 4 firmware/OS (Operating System), specifically in a memory area that is hard to be modified such as ROM. While the private key is securely hidden within the device 4, the device's 4 public key may be made perceivable to the outside. For instance, according to an embodiment the private key may be visible, e.g. by printing it on the device's 4 package (e.g., in form of a QR-code). It should be noted that, by displaying the public key of a device 4 on its packaging, device attestation can be tied to the device's 4 shipping history.
According to an embodiment, hardware vendors 2 also handle revocation of its devices' 4 public keys. Revocation decisions may take into account information available on the distributed ledger or obtained through other sources.
Finally, hardware vendors 2 may handle firmware updates by publishing new firmwares. An update of a firmware on a device 4 may be carried out by the hardware vendor 2 over-the-air, or it may require manual intervention of the device owner (e.g., the network operators 3 or cloud providers 3a). In the latter case, the hardware vendor 2 may simply distribute or publish the updated firmware.
As illustrated in
It should be noted that the above list is non-exhaustive and that different events may be envisioned that trigger a hardware vendor 2 to issue a record to the ledger. More specifically, when a device 4 is produced, the hardware vendor 2 generates a respective transaction messages, which may be configured as follows:
The transaction message is published to the distributed ledger. It should be noted that transaction message contains a parameter “current status”, which in the above example is set to “produced”. The id of the device 4 is unique. For instance, for easy look-up the id can be the cryptographic hash of the device's 4 public key public_key. The firmware_version includes information such as the version number, the digest and the URL to download the firmware.
Upon creation of the transaction message Txcreate and publishing it to the distributed ledger, the contents of the transaction message are then stored in the ledger. In this context, it is important to note that the information of id, model_name, manufacturer, serial_number, and public_key should be immutable in the ledger, unless a particular use case specifies differently. The other information can be updated via subsequent transaction messages.
For instance, when the firmware of a device is updated, the respective hardware vendor 2, in order to update the firmware information, may send a new transaction message to the distributed ledger as follows:
Moreover, when the key of a device 4 is revoked, the respective hardware vendor 2, in order to update the status as “revoked”, may send a new transaction message to the distributed ledger as follows:
According to embodiments, the above-mentioned transaction messages also carry along the authentication information of the respective hardware vendor 2. This authentication information can be verified by all nodes 6 of the distributed leger network 7 in order to accept the Tx_create, Tx_upgrade, and Tx_revoke messages. In this context, an access control approach may be implemented according to which a sender of a transaction message will be authenticated and authorized when the respective transaction message is validated. Moreover, upon acceptance of every transaction message, it may be timestamped by the distributed ledger.
Supply-chain members, which are not explicitly shown in the embodiment of
Generally, records issued by supply-chain members to the distributed ledger reflect the shipment history of a device 4. According to embodiments, a supply-chain member issues a record to the distributed ledger upon the following events: (1) A device 4 has been delivered from a hardware vendor 2 or network operator 3: In this case, the record (exemplarily depicted as ‘tx1’ and ‘tx3’ in the lower part of
Like in the case of hardware vendors 2, other events different from the ones mentioned above may be envisioned that trigger a supply-chain member to issue a record to the ledger.
More specifically, when a device 4 is shipped through a supply-chain member, the status of the device 4 is updated to “shipped” with the recipient information (i.e., network operator 3) via the following transaction:
Upon reception of a new device 4, a network operator 3 may first perform actions to obtain the public key (or ID) of the device 4. For instance, depending on the specific implementation, the network operator 3 may execute a scan (in case the public key is visibly is displayed or indicated, e.g. on a package of the device 4). According to an alternative embodiment, the network operator 3 may query the device information from the distributed ledger. If the device information from the ledger matches the description of the received package, the network operator 3 sends a transaction to the ledger to update the device status as “received”. This transaction may have the following form:
Network operators 3 are responsible of handling devices 4 within their own network domains 7, as shown in
More specifically, according to an embodiment illustrated in
In any case, i.e. regardless of whether the verification failed or succeeded, the network operator 3 issues a new record to the distributed ledger providing information on the verification. This transaction record may be implemented as follows:
If the operator 3 deploys the device 4, then the status can be updated to “deployed” only if the blockchain checked that the verification_result is positive.
Network operators 3 may also handle firmware updates that cannot be executed by hardware vendors 2 over-the-air. In accordance with an embodiment of the present disclosure it may be provided that a network operator 3 only updates a specific device 4 within its domain 7 with a specific firmware version if the respective device 4 has been posted to the distributed ledger by the device manufacturer, i.e. the respective hardware vendor 2. The outcome of a firmware update procedure may once again be signaled by issuing a record to the distributed ledger. This allows members of the distributed ledger network 5 to be aware of the software/firmware version running on a given device 4. A transaction record that advertises the results of a device firmware update may be implemented as follows:
As shown in
As depicted in
Generally, the attestation service 8 may identify the device type together with the hardware security capabilities of the device 4 and, depending on the capability of the underlying hardware, the attestation service 8 may perform the following operations:
If none of the above listed options is available, the attestation service 8 may initiate a software-based attestation. If this option is not viable, the attestation service 8 may perform device radio fingerprinting (for instance, as described in K. B. Rasmussen and S. Capkun: “Implications of radio fingerprinting on the security of sensor networks”, 2007 Third International Conference on Security and Privacy in Communications Networks and the Workshops—SecureComm 2007, the entire disclosure of which is hereby incorporated by reference herein).
The measurement results are saved in a secure storage of the TCB 14 (Trusted Computing Base) of the device's TEE 9. As shown in
Then, during the attestation process, the network operator 3 first establishes a secure channel 16 with the TEE application 15. In this context it should be noted that the TEE application 15 has hard-coded a list 17 of public keys of network operators 3, so that the TEE application 15 is able to authenticate the network operator 3, e.g. in a Diffie-Hellman key exchange, and get a shared key Kshared. In the authentication process only integrity should be guaranteed, not necessarily confidentiality.
After the secure channel 16 is established, the network operator 3 challenges a nonce to the TEE 9, which will prepare a Quote as response. The quote includes the measurement result of the loaded components recorded during the booting sequence, the nonce, and the signature over these information. The quote is signed with the device-wise attestation key SKattest in the TCB 14. This key is only used to sign attestation quotes by the TEE application 15. In this context it should be noted that the key SKattest is different from the application-wise private key SK, which is used for device authentication or other application purpose.
The returned quote is then forwarded and verified by the attestation service 8, which can be hosted by the network operator 3 itself or, like in the embodiment shown in
The TEE information includes the type of TEE 9 and the version of TEE 9.
If the device 4 is not equipped with a TEE 9, the network operator 3 can perform a software attestation based on pseudorandom memory traversal, as shown in
According to an embodiment the network operator 3 may also check the response time (ts for challenge start time and te for response end time) from the device 4. If the response time takes too long, i.e. Δt=te−ts exceeds a predefined threshold, the network operator 3 may be configured to suspects the integrity of the device 4.
In any case, the attestation result may be updated to the blockchain as follows:
If none of the approaches described above is applicable, then the network operator 3 may perform device radio fingerprinting to verify whether a model of the device 4 matches the profile of the emitted signal of a certain device model. A fingerprint result may be updated via the following transaction:
Irrespective of which specific attestation procedure is actually implemented, the outcome of the attestation may be stored in the blockchain. In case of a software attestation, the current state of software can be compared against a whitelist of software that is either stored in the blockchain or in a cloud back end storage.
According to embodiments of the present disclosure, it may be provided that network operators 3 decide whether or not to offer connectivity to a device 4 depending on information about the respective device 4 available in the distributed ledger. This may include setting up a risk assessment service that fetches device information maintained by multiple stakeholders through the distributed ledger to decide the trustworthiness of the device. According to an embodiment it may be provided that the network operators 3 are equipped with a risk assessment module that is configured to retrieve relevant device information from the distributed ledger, including device public keys, shipment history, attestation results, firmware version, etc., and to analyze the retrieved information according to configurable risk assessment rules. In case the device 4 successfully passes the risk assessment, the network operator 3 will offer connectivity to the device 4, otherwise the network operator 3 will not offer connectivity, e.g. by rejecting any respective request received from the device 4.
While subject matter of the present disclosure has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive. Any statement made herein characterizing the invention is also to be considered illustrative or exemplary and not restrictive as the invention is defined by the claims. It will be understood that changes and modifications may be made, by those of ordinary skill in the art, within the scope of the following claims, which may include any combination of features from different embodiments described above.
The terms used in the claims should be construed to have the broadest reasonable interpretation consistent with the foregoing description. For example, the use of the article “a” or “the” in introducing an element should not be interpreted as being exclusive of a plurality of elements. Likewise, the recitation of “or” should be interpreted as being inclusive, such that the recitation of “A or B” is not exclusive of “A and B,” unless it is clear from the context or the foregoing description that only one of A and B is intended. Further, the recitation of “at least one of A, B and C” should be interpreted as one or more of a group of elements consisting of A, B and C, and should not be interpreted as requiring at least one of each of the listed elements A, B and C, regardless of whether A, B and C are related as categories or otherwise. Moreover, the recitation of “A, B and/or C” or “at least one of A, B or C” should be interpreted as including any singular entity from the listed elements, e.g., A, any subset from the listed elements, e.g., A and B, or the entire list of elements A, B and C.
Number | Date | Country | Kind |
---|---|---|---|
19173850.9 | May 2019 | EP | regional |
This application is a U.S. National Phase application under 35 U.S.C. § 371 of International Application No. PCT/EP2019/083899, filed on Dec. 5, 2019, which claims priority to European Patent Application No. EP 19173850.9, filed on May 10, 2019. The International Application was published in English on Nov. 19, 2020, as WO 2020/228976 A1 under PCT Article 21(2), which is hereby incorporated by reference in its entirety.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2019/083899 | 12/5/2019 | WO | 00 |