Device Authentication

Abstract

A method and system for authenticating a device comprising receiving an authentication request from the device at a node of a distributed ledger, the authentication request including data indicative of one or more steps of an authentication method, authenticating the device across multiple nodes of the distributed ledger, each of the multiple nodes following the one or more steps indicated by the data received from the device.

Description

[Technical field]

[0001] FIELD OF THEINVENTION The present invention relates to a system and method for authenticating devices, in particular for authenticating devices in a distributed system using blockchain technology. [Background technology]

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

[0003] Secure authentication between different entities allows for secure interaction between parties that are otherwise remote or unrelated. For example, a SIM may be preloaded with individual keys known to an issuing authority. The issuing authority can securely share these individual (symmetric) keys with the owner of the SIM. Because the SIM does not allow these keys to be copied, when a device with a particular SIM communicates with the owner (or a system under the owner's control), the owner can be sure of the device's identity and secure communications can be established. This system is effective in telecommunications communications, where it is convenient and efficient to distribute physical SIMs to devices.

[0004] For short-lived interactions requiring secure communications, key material can be shared and verified using a trusted intermediary such as a certificate authority, however this requires the establishment of such a trusted intermediary, which is not always efficient or desirable and can introduce latency.

[0005] Furthermore, different device types with different security and authentication capabilities may need to be authenticated by various entities for different purposes, which may increase the complexity of the system and the need to provide security.

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

[0007] Summary of the Invention Devices such as mobile devices, low power commodities or other components may have access to and enable different authentication protocols and methods. Individual devices may have the capability to use multiple authentication methods or may be limited to a single method. In some example implementations, devices may be updated with different authentication methods, or a particular available authentication method may be deactivated and activated at different times. When a device requires authentication from a particular system or service, the device generates an authentication request. The request includes information or data that defines or describes the particular authentication method to be used. Different devices may generate requests using different authentication methods (or defining one or more steps of an authentication method).

[0008] The distributed ledger (or a single node of the distributed ledger) receives these requests from one or more devices. The requests include information identifying or describing the authentication method or process to be used, so that such requests can be received from devices capable of different authentication methods. The nodes of the distributed ledger attempt to authenticate the device using the authentication method described or referenced in each request. Preferably, requests that include details of or identify an authentication method also include the credentials or cryptographic material used to authenticate the device according to the authentication method. Advantageously, the information describing or identifying the authentication method is included in the header of the request and the cryptographic material is included in the payload or body of the request, although other formats may be used.

[0009] Each device may be pre-registered or may issue authentication requests without being pre-registered, however pre-registration may provide additional performance and security enhancements since the device may be better prepared to handle the request.

[0010] According to a first aspect, there is provided a method for authenticating a device, the method comprising: receiving, at a node of the distributed ledger, from a device, a request for authentication, the request including data indicative of one or more steps of a method for authentication; and authenticating the device across multiple nodes of the distributed ledger, each of the multiple nodes authenticating according to one or more steps indicated by data received from the device. Thus, authentication of different devices using different authentication protocols can be processed and authenticated using the same distributed ledger. Thus, different devices using different authentication methods can be more easily authenticated with the same system or systems.

[0011] Preferably, the request may further include credentials, and authenticating the device across multiple nodes of the distributed ledger may further include authenticating the credentials. For example, the payload in the request may be signed with a private key known only to the device (or the UICC or SIM of the device). In another example, the request may include a token encrypted with a symmetric key, which may provide a seed for authentication performed by the nodes of the distributed ledger.

[0012] Optionally, authentication of the device may fail unless two or more of the plurality of nodes authenticate the device according to one or more steps indicated by the data received from the device, thus increasing security since more than one node must successfully verify authentication.

[0013] Optionally, authentication of a device may fail unless a majority of the multiple nodes involved in the authentication authenticate the device. Thus, security may be increased because more than one node must verify the authentication. A small number of the nodes involved in the authentication may fail the authentication for various reasons (e.g., inability to complete, timeout, etc.), and authentication may succeed with a majority of the nodes completing the authentication.

[0014] Preferably, data indicative of one or more steps of the authentication method may be included in a header of the request. The request may, for example, include a header containing details of the authentication method and a payload containing credentials or other cryptographic material used in the authentication performed by the node.

[0015] Optionally, the instruction for one or more steps of the authentication method indicates one authentication protocol out of a number of possible or alternative authentication protocols. For example, the instruction may include an identifier of the particular authentication method to use. There may be several different authentication protocols available to the device, and the data indicates in the request which authentication protocol to use for the particular authentication. A device may only be able to authenticate using a single authentication method. Again, the data may indicate the particular authentication method to use with the device. Different devices or groups of devices may use different authentication methods.

[0016] Optionally, the multiple authentication protocols can include symmetric encryption, asymmetric encryption, public key infrastructure (PKI), SIM Trust, IoT SAFE, TLS, DTLS, and Generic Bootstrapping Architecture (GBA). Other authentication methods or protocols may be used.

[0017] Optionally, the method may further include the step of the device selecting an authentication method from a plurality of authentication methods available to the device before generating the request including data indicating one or more steps of the selected authentication method. Thus, the device may control which authentication method to use for each particular system or purpose. The device may receive instructions in advance to use a particular authentication method under different circumstances or for use with a different system.

[0018] According to a second aspect, there is provided an authentication system, the authentication system comprising: one or more devices, each of the one or more devices configured to generate an authentication request, the authentication request including data indicative of one or more steps of an authentication method; A distributed ledger having a plurality of nodes, each of the plurality of nodes comprising: receiving an authentication request from one of the devices indicating one or more steps of an authentication method; and a distributed ledger having a plurality of nodes configured to authenticate the device according to one or more steps dictated by data received from the device.

[0019] Advantageously, another of the one or more devices may be configured to generate another authentication request indicating another step or steps of the second authentication method that are different from the step or steps of the authentication method. Thus, any number of different devices (or devices, or different or of the same type) may each use a different authentication method with the same distributed ledger.

[0020] Optionally, authentication of the device may fail unless two or more nodes of the plurality of nodes authenticate the device according to one or more steps indicated by the data received from the device.

[0021] Optionally, each of the one or more devices may be further configured to select an authentication method from a plurality of authentication methods available to the device before generating the request including data indicative of one or more steps of the selected authentication method.

[0022] Advantageously, each of the one or more devices may be further configured to receive data defining a new authentication method for use in another authentication request. Thus, the device may change the one or more authentication methods (or method steps) it uses. This adds flexibility, allowing the device to continue to operate with new or improved authentication methods with limited reconfiguration. The new authentication method definition may be received, for example, from one or more nodes of the distributed ledger or from another entity or server.

[0023] Preferably, the original authentication method and / or the new authentication method may have an expiration date, so that security can be improved by refreshing the authentication method periodically or after a predefined or configured period of time.

[0024] Preferably, the one or more devices further comprise a UICC or SIM configured to protect the request. Alternatively, other techniques may be used to protect the request and / or generate the cryptographic material used by the defined authentication method.

[0025] According to a third aspect, there is provided an authentication method and system incorporating a step of registration and any or all steps of the authentication method described above. Registration may include determining which one or more authentication methods are possible from the device or attributes of the device, and enabling the device to use this information to generate a request (including data indicative of one or more steps of the authentication method).

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

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

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

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

[0030] [Figure 1] 1 shows a flowchart of a method for authenticating a device. [Diagram 2] 2 shows a schematic diagram of a system and data flow for registering one or more devices for use in the authentication method of FIG. 1; [Diagram 3] 1 shows a schematic diagram of a system and data flow for authenticating one or more devices, including an authentication request. [Figure 4] 5 shows a schematic diagram of the authentication request of FIG. 4. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

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

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

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

[0034] The technologies underlying distributed cryptocurrencies, such as distributed ledgers, can also be used to record other types of transactions and form a verifiable history of exchanges or other forms of data without requiring that trust exist between entities. Distributed ledgers, such as blockchains, allow transactions, exchanges of value, and verifiable event recording to occur in the absence of trust. This requires the use of blockchains to form a consensus between the nodes of the distributed ledger that is difficult to corrupt or control by any individual party or entity. This typically takes the form of a consensus competition based on proof of work.

[0035] Individual devices require authentication from different systems and for different reasons. These systems may include telecommunications systems, service providers, computer networks or other types. Devices may also require authentication from a distributed network to access services. The system may provide services using a distributed system. Advantageously, the same distributed system that provides the service may also perform authentication of individual devices. Using a distributed ledger to authenticate devices removes the requirement for a trusted entity such as a certificate authority (CA). This is because multiple nodes of a distributed system (e.g., a distributed ledger) may be required before a device can be successfully authenticated. For example, a device is not authenticated until two or more nodes, or a majority of nodes, each authenticate the device individually. This significantly reduces the risk of a single certificate authority being corrupted.

[0036] To allow different devices to use different security protocols or authentication methods, the information or data received from each device as a request for authentication includes data indicating one or more steps of the authentication method. This may be included in a cryptographic header of the request, which may also include information for authenticating the device identity using the specified authentication method. This cryptographic header may include a cryptographic nonce, for example a token signed with a private key known only to the device, or a token encrypted with a symmetric key shared with the distributed ledger.

[0037] 1 shows a flow chart of a method 10 for performing authentication of a device using the system. At step 20, the device generates an authentication request. This may be upon initial power-up or at another time. The request includes data or information that includes, describes, or otherwise defines or identifies an authentication method (e.g., a recipe for the authentication method).

[0038] The device sends this request to the system (e.g., a node of the distributed ledger). This may be direct communication between the device and the node, or communication via an indirect route (e.g., via a telecommunications network). At step 30, the node of the distributed ledger receives the request from the device.

[0039] The request is distributed to one or more other nodes of the distributed ledger. A node receiving the request attempts to authenticate the device using a particular authentication method defined by the data in the request. The node may already have access to a particular authentication method (e.g., a particular security protocol) or may have received software or parameters that enable the node to perform the particular requested authentication method. This may be received from different entities, for example, based on data indicating the authentication step in the request.

[0040] Authentication of a device requires at least two of the nodes to successfully authenticate the device according to a defined authentication method or method steps. In certain exemplary implementations, a minimum number of nodes must authenticate the device for overall authentication to be successful. In other examples, a majority of the nodes must authenticate the device for device authentication to be successful. The request may define such criteria, or this may be predetermined (or set by the customer backend). Thus, security can be enhanced on demand. Success can be indicated by the process of adding a block to the blockchain, which becomes the final next block across the nodes of the distributed ledger. For example, services may be provided once a block indicating success has been added.

[0041] In this example implementation, process 50 stores the results (success or failure) of authentication within the same distributed network (i.e., between nodes). In other examples, successful device authentication can take other forms (e.g., a particular service is provided).

[0042] Thus, the system (including the distributed ledger) can provide "authentication as a service." Each device can install a software development kit (SDK) that triggers a registration request on the distributed ledger (or at least one node of the distributed ledger) upon initial power-up or at another time. Figure 2 illustrates the data flow within the system 100 used to register or configure a device to enable it to use or perform method 10.

[0043] Registering a device can include determining the attributes of the device and the authentication methods available (or that it is capable of). The registration process can also include a description of the device's hardware (e.g., modem, SIM, hardware security module, etc.). Thus, registration can add details of an authentication method (to be used in the future) to the device. This particular authentication method (or steps included in the method) can be based on device attributes (e.g., hardware). Following registration, the device can generate future authentication requests that include data defining this particular authentication method. In other words, pre-registration allows the device to send out requests for possible authentication methods without the device having to determine these methods itself. This can be useful when new authentication methods are defined and deployed. Re-registration of the device can conveniently obtain or enable new authentication methods.

[0044] For example, attributes of the device can be determined when the device registers with the system or a particular service of the system. This may be explicit with the device issuing a registration request that includes the particular attributes, or they may be inferred from the registration request. The request may take a form that implies the presence of a SIM, and the communication format of the request may indicate that the SIM has a particular SDK (or other processing logic) installed.

[0045] A device 110 can have any one or more of different security capabilities. Figure 2 shows a device 110 with a SIM (or UICC) and IoT SAFE and SIM Trust capabilities. However, a device may have either, both, or none of these capabilities. IoT SAFE is an example of a security technology that uses a SIM applet to provide end-to-end secure communications. IoT SAFE can perform operations defined according to GSMA standards using pre-shared keys stored in the SIM. SIM Trust is based on the 3GPP Generic Bootstrapping Architecture (GBA) and can provision new keys as needed. Either or both of the security architectures can be used in a particular device.

[0046] In order to provide a unique and immutable identity for the SIM (and with it the device), a Secure Element on the SIM (having a standardized interface and capable of performing operations defined according to the IoT SAFE standard - GSMA) can be used to create one or more sets of asymmetric keys in the HSM (PKI on the SIM).

[0047] IoT SAFE can also be used to create a secure channel ((D)TLS) between the device and the IoT backend. It uses a secure element on the SIM to hold the asymmetric keys needed for the (D)TLS connection, although these keys may be used for other purposes.

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

[0049] Asymmetric cryptography or PKI is a technology used by many IT infrastructures to secure https and other connections between servers using public / private key pairs. It is these cryptographic materials that devices can use to authenticate with various systems upon request.

[0050] Distributed ledger 120 is shown in FIG. 2 as receiving a request (in this example, "Register Device") in step 1. Internally to distributed ledger 120 (e.g., within the SDK of one or more nodes of distributed ledger 120), it is discovered which specific authentication methods may be used and supported by the device. This may be derived from an explicit definition in the registration request, or may be determined from a combination of the device (e.g., device type), modem, SIM (e.g., identifier or type), and any other hardware or attributes. However, this information may also be determined from the received request.

[0051] For example, the following scenarios may be encountered and determined by a node from a request for registration: 1) If the device 110 carries a SIM with an IoT SAFE applet (which provides PKI for the secure element on the SIM), the authentication method or method step selected for this device is "IoT SAFE."

[0052] 2) If the device and modem and SIM have access to the IoT SIM Trust APN but the SIM does not carry the IoT SAFE SIM applet, then the authentication method or method step “SIM Trust” is selected.

[0053] 3) If a SIM is not available (or does not exist), the device must carry a hardware (HW) secure element or other secure mechanism. In this case, the authentication method is determined as "Secure element without SIM".

[0054] 4) Future authentication methods may be based on network authentication (such as PCRF), for example. During this discovery or decision phase, the SDK (or other processing logic) in each node of the distributed ledger 120 automatically configures itself and generates cryptographic information using the selected authentication method (e.g., extracts a public key from the PKI on the SIM in Example 1 above). If more than one authentication method is available (e.g., the device has access to IoT SAFE and SIM Trust), the selection can be made by the node and / or device 110. Preferably, the most secure combination is selected, as defined by pre-configured rules or attributes in the SDK (either device 110 or node or both). Additionally, device developers using the SDK can manually override the pre-configured authentication method if more than one authentication method is available on the device (e.g., a request can define which authentication method step to use).

[0055] Once an authentication method has been selected (chosen, inferred, or indicated), the registration of the device 110 to the distributed ledger 120 “authentication as a service” procedure can be started automatically at the next power-on of the device 110. This registration leads to populating the nodes of the distributed ledger 120 with data that can be used to generate a trusted digital identifier for the device 110. In some examples, cryptographic material related to the device 110 (e.g., the device’s IoT SAFE public key, SIM Trust symmetric key, etc.) can be stored in the nodes of the distributed ledger 120. This storage is not done centrally (as in a traditional CA) but in a decentralized manner using distributed ledger technology. This allows for a higher level of security since there is no point of failure and two or more nodes manage the trustworthiness of the cryptographic proofs.

[0056] When the device 110 then sends data to the customer backend 130 or another device or entity, the data stream includes a cryptographic header describing the required authentication method, providing a “recipe” for the distributed ledger to prove the authenticity of the data according to the method 10 described with reference to FIG. 1.

[0057] As a simple example, the payload can be signed with a private key known only to the device 110 and the SIM, or can contain a token encrypted with a symmetric key. These seeds (or other cryptographic material) for authentication can be shared with the distributed ledger 120 during registration (see FIG. 2).

[0058] FIG. 3 illustrates an exemplary flow of data used to implement the method 10 described with reference to FIG. 1. A customer backend 130 or other entity requiring authentication of a device 110 can verify the cryptographic header received from a particular device 110 with a node in the distributed ledger 120. This is shown as step 2 in FIG. 3 and can be accomplished using an application programming interface (API) or by direct blockchain integration. This differs from traditional centralized CAs because a decentralized ledger is used to verify these data. In this example, a request received from a device 110 for authentication passes through the customer backend 130 and is passed to a node in the distributed ledger 120. Two or more nodes on the distributed ledger 120 verify whether the sender's cryptographic proof is authentic according to specific authentication method steps defined or determined from information in the request (e.g., the cryptographic header).

[0059] If the checks are successful, i.e., the cryptographic information is trustworthy and, optionally, the device ID is associated with a pre-registered device 110 and stored in the distributed ledger 120, the nodes of the distributed ledger 120 each perform the defined authentication method steps on the cryptographic material received with the request. If these individual authentications (performed within the nodes) are successful, the distributed ledger verifies the authenticity of the device and the data received in the request (step 3 in FIG. 3).

[0060] Optionally, the distributed ledger 120 can push new authentication inputs to the device 110 (step 4 in FIG. 3) if the cryptographic information needs to be changed or updated frequently for increased security. This mechanism can also be used for lifecycle management of the cryptographic information (e.g., certificate revocation or renewal).

[0061] Thus, the present system 100 and method unifies authentication methods across different device types and more easily enables trust checks across architectures.

[0062] The partner systems 140 shown in FIGS. 2 and 3 may include payment systems or other systems that provide services to the devices 110 and / or the customer backend 130.

[0063] 4 shows high-level details of an exemplary request sent by device 110 to customer backend 130. The request includes a cryptographic header (which describes the authentication method steps) and a payload that includes any required cryptographic material.

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

[0065] For example, devices without a SIM or hardware security element may also utilize this method. A different registration procedure may be used (or the device may use method 10 without prior registration). In this case, the request may include, for example, additional data (e.g., identification data). Although the figure shows only one device, the system and method may be used with multiple devices of the same or different types and capabilities. Multiple customer backends may be present and configured in similar or different ways. Furthermore, while a customer backend is described in the example, this may be, for example, a different external entity or another node of the distributed ledger. The data indicative of one or more steps of the authentication method may provide direct instructions (e.g., describing these steps) or take the form of indirect instructions (e.g., providing an identifier of such a method or method steps). The data may also be a pointer or reference to a database entry (e.g., in the distributed ledger or elsewhere). The services provided may include parking, access to the location, electricity of other utilities, telecommunication services, payment, data access, etc. Authentication may be provided automatically without user intervention (such as when the vehicle approaches a toll road or parking lot).

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

Claims

1. 1. A method for authenticating a device, comprising: receiving, at a plurality of nodes of a distributed ledger, from the device, an authentication request including data indicating one or more steps of an authentication method; authenticating the device across multiple nodes of the distributed ledger, each of the multiple nodes authenticating according to the one or more steps of an authentication method indicated by the data received from the device, wherein the data indicating the one or more steps of the authentication method indicates an authentication protocol of a plurality of authentication protocols.

2. 2. The method of claim 1 , wherein the request further includes credentials, and wherein authenticating the device across the plurality of nodes of the distributed ledger further includes authenticating the credentials.

3. 3. The method of claim 1, wherein authentication of the device fails unless two or more nodes of the plurality of nodes authenticate the device according to the one or more steps indicated by the data received from the device.

4. The method of claim 1 , wherein authentication of the device fails unless a majority of the plurality of nodes involved in the authentication authenticate the device.

5. The method of claim 1 , wherein the data indicating one or more steps of an authentication method is included in a header of the request.

6. 10. The method of claim 1, wherein the plurality of authentication protocols include symmetric encryption; asymmetric encryption; public key infrastructure (PKI); SIM Trust; IoT SAFE; TLS; DTLS; and Generic Bootstrapping Architecture (GBA).

7. 10. The method of claim 1, further comprising the step of: the device selecting the authentication method from a plurality of authentication methods available to the device before generating the request including data indicating the one or more steps of the selected authentication method.

8. 1. An authentication system comprising: one or more devices, each configured to generate an authentication request, the authentication request including data indicative of one or more steps of an authentication method; A distributed ledger having a plurality of nodes, each of the plurality of nodes: receiving an authentication request from one of the devices indicating the one or more steps of the authentication method; a distributed ledger having a plurality of nodes configured to authenticate the device according to the one or more steps of an authentication method indicated by the data received from the device, wherein the data indicating the one or more steps of the authentication method indicates an authentication protocol of a plurality of authentication protocols.

9. 9. The authentication system of claim 8, wherein another device of the one or more devices is configured to generate another authentication request indicating another one or more steps of a second authentication method that are different from the one or more steps of the authentication method.

10. 10. The authentication system of claim 8 or claim 9, wherein authentication of the device fails unless two or more nodes of the plurality of nodes authenticate the device according to the one or more steps indicated by the data received from the device.

11. 9. The authentication system of claim 8, wherein each of the one or more devices is further configured to select the authentication method from a plurality of authentication methods available to the device before generating the request including data indicating the one or more steps of the selected authentication method.

12. 9. The authentication system of claim 8, wherein each of the one or more devices is further configured to receive data defining a new authentication method for use in another authentication request.

13. The authentication system of claim 12 , wherein the original authentication method and / or the new authentication method have an expiration date.

14. The authentication system of claim 8 , wherein the one or more devices further comprise a UICC or a SIM configured to protect the request.

Images