Methods for device identity attestation and devices thereof

Abstract

Embodiments of the invention relate to methods for device identity attestation. Thus, a method for a device identity attestation module (120) of a device (100) comprises: deriving (202) an attestation key pair, AKP, by inputting a unique hardware secret, UHS, and an immutable hardware identity, HID, of the device (100) into a first key derivation function, KDF, wherein the UHS is a main key and the HID is at least one key derivation factor in the first KDF; transmitting (204) a certificate request (510) for the AKP to a certificate authority (300), the certificate request (510) indicating a public key of the AKP and the HID; and receiving (206) an attestation key certificate (520) for the AKP from the certificate authority (300), the attestation key certificate (520) indicating the public key of the AKP and the HID. Thereby, a secure ID attestation (540) may be transmitted to an application (130) of the device (100). Furthermore, embodiments of the invention also relate to corresponding devices.

Description

METHODS FOR DEVICE IDENTITY ATTESTATION AND DEVICES THEREOFTECHNICAL FIELD

[0001] Embodiments of the invention relate to methods for device identity attestation. Furthermore, embodiments of the invention also relate to corresponding devices.BACKGROUND

[0002] Attestation technologies are important components in modern computer systems. For example, such technologies allow a client application (also known as an attester) running on a client device to supply evidence about certain security attributes of the client system, which can then be validated by another computer system (also known as a verifier) , such as another device or a cloud server. The evidence is typically cryptographically signed by a trusted key on the client device, and the term attestation is often used to refer to the signed evidence, or the action of generating such signed evidence.

[0003] There are a few types of attestation technologies. For example, so-called remote attestation is commonly used by an attester to prove to a remote server that the client device runs a trusted firmware or software and that the client device is in a good state. This may be achieved by including measurement values of various firmware / software components during device boot-time into the attestation procedure, which can then be compared with a database of known “good values” by the verifier. Such schemes are e.g., employed by the   Software Guard Extensions (SGX) technology, to allow applications to be sure that they run in a protected execution environment.

[0004] Key attestation is another type of attestation technology, typically for consumer devices hosting third-party applications. In many cases, a third-party application may need to interact with a cloud service provided by the application developer securely to perform tasks for the end-user, such as password-less login, making purchases and / or payments. To authenticate a transaction request from the end-user, the third-party service provider typically requires that the transaction to be signed by a strong cryptographic key that is properly protected on the consumer device, e.g., by a trusted execution environment (TEE) or a secure enclave processor (SEP) . In addition, the third-party service provider may require that the application should be run on a real device and not in an emulated environment.

[0005] In the case of Android applications, its key attestation feature is also used to perform identity (ID) attestation, where the device generates proofs of device identifiers by including these identifiers into a key attestation certificate. This allows Android applications to prove the identity of the device from which they are hosted to a remote server. Due to the fact that these identifiers are often trackable, the access to such ID attestation, application programing interface (API) is typically permission restricted to avoid abusing. In the case of iOS devices, applications are not allowed to obtain permanent device identifiers at all.SUMMARY

[0006] An objective of embodiments of the invention is to provide a solution which mitigates or solves the drawbacks and problems of conventional solutions.

[0007] Another objective of embodiments of the invention is to provide an attestation solution with improved security compared to conventional solutions for attestation.

[0008] The above and further objectives are solved by the subject matter of the independent claims.

[0009] Further embodiments of the invention can be found in the dependent claims.

[0010] According to a first aspect of the invention, the above mentioned and other objectives are achieved with a method for a device identity attestation module of a device, the method comprising: deriving an attestation key pair, AKP, by inputting a unique hardware secret, UHS, and an immutable hardware identity,  HID, of the device into a first key derivation function, KDF, wherein the UHS is a main key and the HID is at least one key derivation factor in the first KDF; transmitting a certificate request for the AKP to a certificate authority, the certificate request indicating a public key of the  AKP and the HID; and receiving an attestation key certificate for the AKP from the certificate authority, the attestation key certificate indicating  the public key of the AKP and the HID.

[0011] An advantage of the method according to the first aspect is that by using one or more HIDs as key derivation factors in the first KDF, the binding between the AKP and the hardware of the device is even stronger in the sense that devices with different HIDs can never derive the same AKP. The key derivation factors may also be denoted salt values for the KDF.

[0012] In an implementation form of a method according to the first aspect, the method comprises: deleting the APK after having received the attestation key certificate. An advantage with this implementation form is that the risk of leaking the APK is minimized since the APK is not stored  permanently but deleted after being used.

[0013] In an implementation form of a method according to the first aspect, the method comprises: receiving an ID attestation request from an application of the device; deriving the AKP by inputting the UHS and the HID into the first KDF, wherein the UHS is a main key and the HID is at  least one key derivation factor in the first KDF; signing an ID attestation with the private key of the AKP, wherein the ID attestation indicates the HID; and transmitting the signed ID attestation to the application.

[0014] An advantage with this implementation form is that it allows an application to obtain an attestation of immutable identifiers of the device, where the attestation is signed by the AKP that is also strongly bound to the device hardware. Since device identifiers are typically privacy sensitive, access control mechanisms may be applied to ensure that such ID attestation services are not abused.

[0015] In an implementation form of a method according to the first aspect, the method comprises: deleting the APK after having signed the ID attestation.

[0016] An advantage with this implementation form is that the risk of leaking the APK is minimized since the APK is not stored permanently but deleted after being used.

[0017] In an implementation form of a method according to the first aspect, the UHS is an immutable UHS programmed into a one-time-programmable, OTP, memory of the device, or computed from a physical unclonable function, PUF.

[0018] An advantage with this implementation form is that the UHS is bound to the device hardware. The UHS may comprise binary data.

[0019] In an implementation form of a method according to the first aspect, the HID is an immutable HID programmed into an OTP memory of the device, or computed from a PUF.

[0020] An advantage with this implementation form is that HID is bound to the device hardware.

[0021] In an implementation form of a method according to the first aspect, the deriving of the AKP comprises: deriving a private key of the AKP by performing a symmetric key derivation by inputting the HID and the UHS in a  second KDF; and deriving the public key of the APK by computing an X-coordinate of the public key of the APK by performing a key  agreement using the private key of the AKP, and computing a Y-coordinate of the public key of the APK by solving a curve equation.

[0022] An advantage with this implementation form is that all these steps can be performed efficiently with a TEE Internal API, which is widely available in TEE runtime implementations. This reduces the cost of implementing the present solution.

[0023] In an implementation form of a method according to the first aspect, the key derivation factor further comprises a type of the device, a serial number of the device, an international mobile number equipment identity, IMEI, a mobile equipment identifier, MEID, a fixed value encoded into a software or a firmware of the device, and a service identity of the device.

[0024] An advantage with this implementation form is that it allows to support many different services on the same device, where the APKs are bound to the device hardware but may be different for each service.

[0025] In an implementation form of a method according to the first aspect, the certificate request is signed with a device key of the device and a private key of the AKP.

[0026] An advantage with this implementation form is that the certificate authority is able to verify that the attestation request is indeed from a particular unique device, as identified by the device key, and that the device is able to generate the AKP correctly.

[0027] In an implementation form of a method according to the first aspect, the device key is a factory provisioned device key.

[0028] An advantage with this implementation form is that the association between the device key and the device is established during manufacturing, and thus can be trusted.

[0029] According to a second aspect of the invention, the above mentioned and other objectives are achieved with a method for a certificate authority, the method comprising: receiving a certificate request from a device identity attestation module of a device, the certificate request indicating a  public key of a AKP and a HID of the device; generating an attestation key certificate when an association between the AKP and the HID is unique; and transmitting the attestation key certificate to the device identity attestation module, wherein the attestation key certificate  indicates the public key of the AKP and the HID.

[0030] An advantage of the method according to the second aspect is that the certificate authority makes sure that the HID and AKP cannot be abused, since even when a device is compromised and its HID and / or AKP are known by an attacker, the attacker cannot reuse the HID and the AKP for other devices. The HID is also included in the issued certificate so that it allows the device to confirm that the locally derived AKP is correct, when the AKP is needed.

[0031] In an implementation form of a method according to the second aspect, the certificate request is signed with a device key of the device and a private key of the; and wherein the method comprises: generating the attestation key certificate when the association between the AKP and the HID is unique and an association  between device key and the AKP is unique.

[0032] An advantage with this implementation form is that the HID and the AKP cannot be abused even when the factory provisioned device key is leaked from a device, since the factory provisioned device key can be associated with the device during manufacturing.

[0033] In an implementation form of a method according to the second aspect, the association between the AKP and the HID is a one-to-one mapping, and / or the association between device key and the private key of the AKP is a one-to-one mapping.

[0034] An advantage with this implementation form is that by ensuring one-to-one mapping between the device key, the HID and the AKP, the chance of abusing the keys is minimized.

[0035] In an implementation form of a method according to the second aspect, the HID is an immutable HID programmed into an OTP memory of the device, or computed from a PUF.

[0036] An advantage with this implementation form is that the HID is bound to the device hardware.

[0037] According to a third aspect of the invention, the above mentioned and other objectives are achieved with a device identity attestation module of a device, wherein the device comprises a processor and a memory, the memory being configured to store instructions, and the processor being configured to read the instructions to perform the method according to the first aspect.

[0038] The device identity attestation module according to the third aspect can be extended into implementation forms corresponding to the implementation forms of the method according to the first aspect. Hence, an implementation form of the device identity attestation module comprises the feature (s) of the corresponding implementation form of the method according to the first aspect.

[0039] The advantages of the device identity attestation module according to the third aspect are the same as those for the corresponding implementation forms of the method according to the first aspect.

[0040] According to a fourth aspect of the invention, the above mentioned and other objectives are achieved a certificate authority comprising a processor and a memory, the memory being configured to store instructions, and the processor being configured to read the instructions to perform the method according to the second aspect.

[0041] The certificate authority according to the fourth aspect can be extended into implementation forms corresponding to the implementation forms of the method according to the second aspect. Hence, an implementation form of the certificate authority comprises the feature (s) of the corresponding implementation form of the method according to the second aspect.

[0042] The advantages of the certificate authority according to the fourth aspect are the same as those for the corresponding implementation forms of the method according to the second aspect.

[0043] Embodiments of the invention also relate to a computer program, characterized in program code, which when run by at least one processor causes the at least one processor to execute any method according to embodiments of the invention. Further, embodiments of the invention also relate to a computer program product comprising a computer readable medium and the mentioned computer program, wherein the computer program is included in the computer readable medium, and may comprises one or more from the group of: read-only memory (ROM) , programmable ROM (PROM) , erasable PROM (EPROM) , flash memory, electrically erasable PROM (EEPROM) , hard disk drive, etc.

[0044] Further applications and advantages of embodiments of the invention will be apparent from the following detailed description.BRIEF DESCRIPTION OF THE DRAWINGS

[0045] The appended drawings are intended to clarify and explain different embodiments of the invention, in which:

[0046] Fig. 1 shows a flow chart of a method for a device identity attestation module according to embodiments of the invention;

[0047] Fig. 2 shows a device identity attestation module according to embodiments of the invention;

[0048] Fig. 3 shows a flow chart of a method for a certificate authority according to embodiments of the invention;

[0049] Fig. 4 shows a certificate authority according to embodiments of the invention;

[0050] Fig. 5 shows a system for attestation according to embodiments of the invention;

[0051] Fig. 6 shows a signaling diagram for derivation of an AKP according to embodiments of the invention;

[0052] Fig. 7 shows a signaling diagram for certificate enrolment process according to embodiments of the invention; and

[0053] Fig. 8 shows a signaling diagram for the interaction between an application and a DIAM according to embodiments of the invention.DETAILED DESCRIPTION OF EMBODIMENTS

[0054] Although there are many forms of attestation procedures and thus the details about attestation procedures may vary, the general principle for providing a trust relationship is the same. First, a device key (DK) is provisioned to, or generated from, a computing device during its manufacturing process. The DK is typically protected by a secure region in the device, such as the TEE, so that it is considered as infeasible to extract the DK out of the device and use it somewhere else. The DK is also certified, so that another party can validate digital signatures generated from the DK. A typical way to certify the DK is to issue an X. 509 certificate when the DK is an asymmetric key pair. If the DK is a symmetric key, only the device vendor can validate the digital signatures.

[0055] The DK is sometimes also referred to as a root-of-trust (RoT) key to indicate that the main use case of the DK is to establish trust relationships. In recent Android and iOS devices, such DKs are not used directly for attestation, but new attestation key pairs will be generated / provisioned to individual applications when attestation features and functions are requested by the applications. The provisioning process of such attestation keys depends on secure channels established between the devices and the vendor web services, using the DK as a basis for authentication and / or verification proofing that the devices are legitimate. It is worth noting in this context that the key pair generation process in the consumer devices, regardless whether it is DK or secondary attestation keys, typically involves two steps. Firstly, a random private key is generated, and secondly its corresponding public key is computed by using arithmetic primitive libraries available in the devices. In some cases, such computations are performed using hardware accelerators.

[0056] However, the following limitations may be noted in regards of key attestation in conventional solutions. Lack of attestable immutable hardware identifiers i.e., the lack of truly hardware-bound attestation keys that are persistent throughout the life-cycle of the devices. Further, sub-optimal performance has been identified since conventional attestation solutions either requires a high-performance certificate authority, or high complexity and risk during manufacturing and attestation.

[0057] Although most applications should not have access to trackable identifiers of consumer devices to protect end-user privacy, there are use cases where it is needed to reliably identify the hardware. For example, for a consumer to be certain that a phone to be purchased is not a stolen phone, typically a web service is required with a database of all phones that are reported as stolen or lost. In this case, it is important for the device to be able to prove that it is not in this list by attesting its immutable hardware identifiers to the web service. Similarly, for an enterprise to keep track of all the devices that are connected to its network, it may be required as part of the mobile device management (MDM) solution that immutable identifiers of authorized devices are recorded and checked against those can be proved (i.e., attested) by the devices that attempt to connect to its network. It is also noted that in iOS and recent Android versions, each attestation may require one or more round-trips to cloud servers, which may be undesirable.

[0058] Therefore, the present disclosure addresses these challenges among other things and provides methods and devices for immutable hardware identifier attestation that can be implemented efficiently. A novel device identity (ID) attestation scheme that addresses the limitations of conventional solutions is disclosed. In particular, the ID attestation scheme introduces the use of attesting immutable hardware identifiers to support consumer and enterprise use cases. This ID attestation scheme may be built on top of a key attestation scheme where the attestation key is cryptographically bound to the hardware, and can be certified by certificate authorities for easier verification of such ID attestations. The present scheme is also designed to be practical to implement, where the required cryptographic operations may be implemented using only the TEE internal API as specified by GlobalPlatform or corresponding API.

[0059] Fig. 1 shows a flow chart of a method 200 which may be executed in a device identity attestation module (DIAM) 100, such as the one shown in Fig. 2. The method 200 comprises: deriving 202 an attestation key pair (AKP) by inputting a unique hardware secret (UHS) and an immutable hardware identity (HID) of the device 100 into a first key derivation function (KDF) , wherein the UHS is a main key and the HID is at least one key derivation factor in the first KDF; transmitting 204 a certificate request 510 for the AKP to a certificate authority 300, the certificate request 510 indicating a public key of the AKP and the HID; and receiving 206 an attestation key certificate 520 for the AKP from the certificate authority 300, the attestation key certificate 520 indicating the public key of the AKP and the HID.

[0060] Fig. 2 shows a DIAM 100 according to embodiments of the invention. In the embodiment shown in Fig. 1, the DIAM 100 or the device 100 comprises a processor 102, a transceiver 104 and a memory 106. The processor 102 is coupled to the transceiver 104 and the memory 106 by communication means 108 known in the art. The DIAM may be configured for wireless and / or wired communications in a communication system. The wireless communication capability may be provided with an antenna or antenna array 110 coupled to the transceiver 104, while the wired communication capability may be provided with a wired communication interface 112 e.g., coupled to the transceiver 104.

[0061] The processor 102 may be referred to as one or more general-purpose central processing units (CPUs) , one or more digital signal processors (DSPs) , one or more application-specific integrated circuits (ASICs) , one or more field programmable gate arrays (FPGAs) , one or more programmable logic devices, one or more discrete gates, one or more transistor logic devices, one or more discrete hardware components, or one or more chipsets. The memory 106 may be a read-only memory, a random access memory (RAM) , or a non-volatile RAM (NVRAM) . The transceiver 104 may be a transceiver circuit, a power controller, or an interface providing capability to communicate with other communication modules or communication devices, such as network nodes and network servers. The transceiver 104, memory 106 and / or processor 102 may be implemented in separate chipsets or may be implemented in a common chipset. That the DIAM 100 is configured to perform certain actions can in this disclosure be understood to mean that the DIAM 100 comprises suitable means and devices, such as e.g., the processor 102 and the transceiver 104, configured to perform the actions.

[0062] According to embodiments of the invention the DIAM 100 is configured to derive an AKP by inputting a UHS, and an HID of the device 100 into a first KDF wherein the UHS is a main key and the HID is at least one key derivation factor in the first KDF; transmit a certificate request 510 for the AKP to a certificate authority 300, the certificate request 510 indicating a public key of the AKP and the HID; and receive an attestation key certificate 520 for the AKP from the certificate authority 300, the attestation key certificate 520 indicating the public key of the AKP and the HID.

[0063] Thus, the DIAM 100 comprises a processor and a memory, the memory being configured to store instructions, and the processor being configured to read the instructions to perform the method 200 according to embodiments of the invention.

[0064] In embodiments of the invention, the UHS is an immutable UHS programmed into a one-time-programmable (OTP) memory of the device 100, or computed from a physical unclonable function (PUF) of the device 100. The same may also apply for the HID, and thus the HID may be an immutable HID programmed into an OTP memory of the device 100, or computed from a PUF of the device 100. The UHS and the HID may be represented as binary data but are not limited thereto.

[0065] Fig. 3 shows a flow chart of a method 400 which may be executed in a certificate authority 300, such as the one shown in Fig. 4. The method 400 comprises: receiving 402 a certificate request 510 from a DIAM 120 of a device 100, the certificate request 510 indicating a public key of a AKP and a HID of the device 100; generating 404 an attestation key certificate 520 when an association between the AKP and the HID is unique; and transmitting 406 the attestation key certificate 520 to the DIAM 120, wherein the attestation key certificate 520 indicates the public key of the AKP and the HID.

[0066] Fig. 4 shows a certificate authority 300 according to embodiments of the invention. In the embodiment shown in Fig. 3, the certificate authority 300 comprises a processor 302, a transceiver 304 and a memory 306. The processor 302 is coupled to the transceiver 304 and the memory 306 by communication means 308 known in the art. The certificate authority 300 may be configured for wireless and / or wired communications in a communication system. The wireless communication capability may be provided with an antenna or antenna array 310 coupled to the transceiver 304, while the wired communication capability may be provided with a wired communication interface 312 e.g., coupled to the transceiver 304.

[0067] The processor 302 may be referred to as one or more general-purpose CPUs, one or more DSPs, one or more ASICs, one or more FPGAs, one or more programmable logic devices, one or more discrete gates, one or more transistor logic devices, one or more discrete hardware components, one or more chipsets. The memory 306 may be a read-only memory, a RAM, or a NVRAM. The transceiver 304 may be a transceiver circuit, a power controller, or an interface providing capability to communicate with other communication modules or communication devices. The transceiver 304, the memory 306 and / or the processor 302 may be implemented in separate chipsets or may be implemented in a common chipset. That the CA 300 is configured to perform certain actions can in this disclosure be understood to mean that the CA 300 comprises suitable means and devices, such as e.g., the processor 302 and the transceiver 304, configured to perform the actions.

[0068] According to embodiments of the invention, the certificate authority 300 is configured to: receive a certificate request 510 from a DIAM 120 of a device 100, the certificate request 510 indicating a public key of a AKP and a HID of the device 100; generate an attestation key certificate 520 when an association between the AKP and the HID is unique; and transmit the attestation key certificate 520 to the DIAM 120, wherein the attestation key certificate 520 indicates the public key of the AKP and the HID.

[0069] Thus, the certificate authority 300 comprises a processor and a memory, the memory being configured to store instructions, and the processor being configured to read the instructions to perform the method 400 according to embodiments of the invention.

[0070] Fig. 5 shows an exemplary system 600 for attestation according to embodiments of the invention. Embodiments of the disclosed invention may concern the following devices and scenarios but are not limited thereto.

[0071] A consumer device 100, also known as a client device 100 or just a device 100, is configured to host applications that may be developed by 3rd party service providers. The device 100 comprises a DIAM 120 in a secure region of the device 100 e.g., in its TEE 140. A DK may be factory-provisioned for the DIAM 120 for each device. Each device 100 comprises one or more unique and immutable HIDs, which may either be programmed into its OTP memory, or computed from a PUF. Each device 100 also comprises one or more immutable UHSs that may be provisioned during manufacturing. The UHSs are only accessible to the DIAM 120 of the device 100.

[0072] A DIAM 120 is a special application hosted in a secure region of the device 100. The DIAM 120 may be provided by the device vendor to provide an ID attestation API for privileged applications running in the device 100. The DIAM 120 is responsible for deriving one or more AKPs. Furthermore, the DIAM 120 may also enroll certificates for the derived AKPs from a cloud certificate authority 300 which may be managed by the device vendor.

[0073] A cloud service 610 is configured to provide useful services to end users that require strong ID proof. The cloud service 610 may be operated by the device vendor or a 3rd party e.g., for enterprise use cases. The cloud service 610 acts as the verifier 610 in these exemplary schemes.

[0074] An application (App) 130 of the device 100 is configured to provide useful functions to end users by making use of the cloud service 610. The application 130 act as the attester in these exemplary schemes. The application 130 may be provided by the device vendor or a 3rd party, and need to have the privilege to use the ID attestation feature provided by the DIAM 120 of the device 100.

[0075] A certificate authority (CA) 300 may be run by the device vendor, and is configured to issue certificates to various keys for devices, such as the previously mentioned DKs and AKPs. The certificate authority 300 may be implemented in a cloud server.

[0076] Three main use case scenarios may be envisaged but are not limited thereto. Firstly, the DIAM 120 in a device 100 derives at least one AKP. Secondly, the DIAM 120 enrolls an attestation certificate for the derived AKP from a certificate authority 300 operated by the device vendor. During the certificate enrolment process, the DIAM 120 may use a factory-provisioned DK to authenticate itself by signing and thus prove to the certificate authority 300 that this is a legitimate device. Thirdly, an application 130 may request for an ID attestation using an API provided by the DIAM 120. The resulting signed ID attestation is returned to the application 130 and sent by the application 130 to the cloud service 610, the latter acting as the verifier for independent verification of the signed ID attestation.

[0077] In this section the steps of deriving a hardware bound elliptic curve cryptography (ECC) AKP from at least one UHS are presented. Generally, in embodiments of the invention, the deriving of an AKP comprises deriving a private key D of the AKP by performing a symmetric key derivation by inputting at least one HID and at least one UHS in a second KDF. The public key of the APK is derived by computing an X-coordinate of the public key of the APK by performing a key agreement using the private key D of the AKP, and computing a Y-coordinate of the public key of the APK by solving a curve equation. The steps below are performed by the DIAM 120 when an AKP is needed for attestation in an attestation procedure involving interaction between the DIAM 120, the TEE Runtime 140 and the system-on-chip (SoC) 150 as illustrated in Fig. 6.

[0078] The DIAM 120 performs a symmetric key derivation using a second KDF to obtain a new secret key D from an immutable UHS, and uses the private key D as the private key of the AKP which has a private key and a public key. The private key D may be a number. The second KDF may be any suitable KDF such as HKDF (HMAC-based KDF) .

[0079] Step 1.0: The DIAM 120 request a HID from the TEE 140. Steps 1.1 –1.2: The TEE 140 loads the HID from the SoC 150. Step 1.3: The DIAM 120 receives the HID from the TEE 140.

[0080] Step 2.0: The DIAM 120 request the private key D. Steps 2.1 –2.2: The TEE 140 loads UHS from SoC 150. Step 2.3: The TEE 140 derives the private key D based on UHS and HID. Step 2.4: The DIAM 120 receives the private key D from the TEE 140.

[0081] The DIAM 120 in step 3 performs a key agreement based on a function for key agreement provided by the API using the private key D as the private key of the AKP and the elliptic curve (EC) base-point G which has a X-value and a Y-value as the public key and is thus a point in a 2D space. The result X of the key agreement may be denoted the X-coordinate of the public point or the same as the public key of the AKP. The X-coordinate may be a number.

[0082] Step 3.1: The TEE 140 computes the elliptic curve Diffie-Hellman (ECDH) key agreement. Step 3.2: The DIAM 120 receives the X-coordinate of the public point of the AKP from TEE 140.

[0083] The DIAM 120 in step 4 computes the Y-coordinate of the public point of the AKP by solving a curve equation. This means that the AKP comprises values [D, (X, Y) ] , where D is the private key of the AKP and (X, Y) -coordinates forms the public key of the AKP.

[0084] Steps 4.1 –4.2: To solve Y for the curve equation given the value of X, the following steps may be performed by the DIAM 120 invoking the TEE internal API, using the widely used P256 elliptic curve defined by the National Institute of Standards and Technology (NIST) as an example. The P256 curve requires that every point (X, Y) on the curve satisfies the equation Y2 = X3 + a X + b (mod p) where a, b and p are constant values specified as curve parameters and “mod p” is the modulo operation where the modulus is p. · Step 4.1: compute the right-hand-side equation: r = X3 + a X + b (mod p) ; · Step 4.2: compute a candidate Y’ for Y by solving equation: Y’ = r (p+1)  / 4 (mod p) . · Step 4.3: The DIAM 120 receives the candidate Y′from the TEE 140. Due to the nature of the curve equation, (p –Y’ )  is another candidate of Y.

[0085] Step 5: The DIAM 120 signs data M with the private key D. Data M can be random data or other data such as dummy data. Step 5.1: The TEE 140 computes ECC signature S. Step 5.2: The DIAM 120 receives the signature S for the ECC from the TEE 140.

[0086] Step 6: The DIAM 120 verifies signature S of data M using the candidate public key (X, Y’ ) . Step 6.1: The TEE 140 verifies the ECC signature. Step 6.2: The DAIM 120 receives the signature verification result. The public key of AKP is determined by the verification result as follows: If the verification is successful, i.e., if the signature verification result is positive, the public key of AKP is (X, Y’ ) , otherwise the public key of AKP is (X, p –Y’ ) .

[0087] Step: 7: The DIAM 120 loads the APK as computed by above steps in the TEE 140 for further use.

[0088] Step: 8: The DIAM 120 uses the loaded AKP according to embodiments of the invention.

[0089] Step 9: The DIAM 120 after the application request has been served, deletes the derived APK from the memory to avoid key leakage in embodiments of the invention.

[0090] The correctness of the above steps for computing the Y value follows from the mathematical properties of the elliptic curve and the specifications for mentioned parameters a, b and p. In embodiments of the invention, the above steps can be implemented using the TEE 140 internal API specified by GlobalPlatform (GP) . This allows for easy implementation of the above steps in a trusted application (TA) hosted in a GP compliant TEE.

[0091] In this section further details about the symmetric key derivation step described previously are given. In a typical symmetric key derivation algorithm, two inputs are accepted. One input is a secret key also denoted the main key, and the other input is often referred to as the so-called salt or key derivation factor, which can be made public without affecting the security of the KDF. Hence, the key derivation can be written as D = KDF1 (UHS, salt) , where the first key derivation function (KDF1) is the underlying key derivation function supported by the software run-time or hardware accelerator and the UHS is the main key.

[0092] Given that the key derivation factor or the salt value should remain the same during the life-time of the device 100 so that the derived AKP is consistent, there are a few strategies by which the salt value can be specified or in other words the key derivation factors in Step 1. The key derivation factors can be, or be derived from, or be based on any of: · A type of the device 100; · A serial number of the device 100; · An international mobile number equipment identity (IMEI) of the device 100; · A mobile equipment identifier (MEID) of the device 100; · A fixed value encoded into a software or a firmware of the device 100; · A service identity of the device 100; and · Any combination of the previous key derivation factors. This is possible since the length of the salt value is typically not  limited. And even when there is a limit to salt values, a combination function can always be applied, such as a cryptographic hash function, to limit the size of the salt value to a specific value.

[0093] It may further be noted that although the device information mentioned above often are constant values that should not change under normal circumstances, such information in practice may actually be stored in a mutable storage area in the device 100 and is subject to tampering if the device 100 is under an attack. The immutable HIDs as defined in the present disclosure may refer to data / information that cannot be changed without replacing the hardware parts of the device 100, i.e., being hardware bounded.

[0094] In this section the enrolling procedure for attestation certificate i.e., the interaction between the DIAM 120 and the certificate authority 300 using the herein disclosed AKPs are presented. In particular, during the device initialization, the following steps may be performed to certify the AKP (s) with reference to Fig. 7.

[0095] Steps 1.0 –1.1: The DIAM 120 derives an AKP according to embodiments of the invention. Thus, the DIAM 120 obtains the AKP from the TEE 140 in step 1.1.

[0096] Steps 2.0 –2.1: The DIAM 120 obtains one or more immutable HIDs of the device 100 from the TEE 140 if not already done previously.

[0097] Step 3.0 –3.1: The DIAM 120 optionally requests a nonce value N from the cloud certificate authority 300, or computes such a nonce value N locally. Both cases are possible and withing embodiment of the invention. The nonce value N is used to prove the freshness of a certificate request and hence to prevent replay attacks.

[0098] Step 4: The DIAM 120 generates a certificate request 510 comprising a public key of AKP, the one or more immutable HIDs, and possibly the nonce value N.

[0099] Steps 5.0 –5.1: The DIAM 120 double-signs the certificate request 510 with a unique factory provisioned DK of the device 100 and also with the private key of the AKP using the TEE 140.

[0100] Step 6: The DIAM 120 deletes the AKP from the memory of the device 100.

[0101] Step 7: The DIAM 120 sends the double-signed certificate request 510 to a certificate authority 300 possibly operated by the device vendor. The certificate authority 300 receives the double-signed certificate request 510 from the DIAM 120. Step 7.1: The certificate authority 300 requests the public key of DK and other device information associated with the HID from a device database 160. Step 7.2: The certificate authority 300 receives the DK and the requested information from the device database 160. Step 7.3: The certificate authority 300 checks the signatures of the certificate request 510 against the factory-provisioned DK and the public key of the AKP. Step 7.4: The certificate authority 300 checks and ensures that the HID matches the factory-provisioned DK, and that the same HID cannot be certified by different devices. Step 7.5: The certificate authority 300 generates or issues an attestation key certificate 520 when an association between the AKP and the HID is unique and an association between device key and the AKP is unique. The purpose of these additional checks is to ensure that the DK, the HID and the AKP cannot be abused (e.g., reused by attackers) even when they are leaked from the device 100, as a result of an attack. In embodiments of the invention, the association between the AKP and the HID may be one-to-one mapping and / or the association between device key and the private key of the AKP is a one-to-one mapping. The attestation key certificate 520 may also be signed with the private key of the certificate authority 300. Step 7.6: The DIAM 120 receives the signed attestation key certificate 520 from the certificate authority 300. The signed attestation key certificate 520 comprises the public key of the AKP, one or more immutable HIDs, and optionally the purpose for the attestation certification and other device information such as a device type and a device security level. A certificate chain issued to the certificate authority 300 by its parent certificate authority may also be received by the DIAM 120 to form a complete certificate chain.

[0102] In embodiments of the invention, one-way functions such as cryptographic hash functions may be applied to the HIDs and the nonce value (s) N before they are included in the certificate request 510 and the attestation key certificate 520. Thus, the HIDs and the nonce value N may be represented as hash values in such cases for improved security.

[0103] It may further be noted that for the certificate authority 300 to check the correct association between the HIDs and the factory-provisioned DK, a device database 160 may be maintained. During manufacturing, the HIDs may be collected together with information about the DK e.g., the public key of the DK. Such information may be stored in the device database, which is then made available to the certificate authority 300. However, the overall enrollment process can be performed without this check if maintaining such a device database is infeasible due to manufacturing constraints. Simply by ensuring that each HID can only be authenticated by a unique DK would eliminate most attacks.

[0104] In this section how an application 130 can make use of the API provided by the DIAM 120 to perform an ID attestation is described. In particular, the application 130 may request a hardware ID attestation from the DIAM 120. Thus, the following steps may be performed with reference to Fig. 8.

[0105] Step 1.0: The application 130 sends an ID attestation request 530 to the DIAM 120. The ID attestation request 530 may optionally comprise a challenge value C which the application 130 has received from the verifier 610. Mentioned challenge value C is used to guarantee the freshness of the ID attestation request 530 to prevent replay attacks.

[0106] Step 1.1: The DIAM 120 checks if the application 130 is allowed to make such an ID attestation request based on a security policy of the device 100, and rejects the request if not allowed by the policy.

[0107] Step 1.2: The DIAM 120 else derives a hardware-bound AKP according to embodiments of the invention if the ID attestation request 530 from the application 130 is accepted. Hence, the DIAM 120 derives the AKP by inputting at least one UHS and at least one HID into a first KDF running in the TEE 140. The UHS is a main key and the HID is at least one key derivation factor in the first KDF as previously mentioned.

[0108] Steps 1.3 –1.4. : The DIAM 120 retrieves one or more immutable HIDs from the TEE 140 according to embodiments of the invention.

[0109] Step 1.5: The DIAM 120 checks if a valid certificate chain from the certificate authority 300 exists, and further checks that: the public key in the attestation key certificate 520 matches the public key of the AKP, and the HID comprised in the attestation key certificate 520 matches the identifier retrieved in previous step. The DIAM 120 also checks that a purpose specified in the attestation key certificate 520 is ID attestation. If such an attestation key certificate 520 does not already exist, the DIAM 120 obtains an attestation key certificate 520 from the certificate authority 300 according to embodiments of the invention.

[0110] Step 1.6: The DIAM 120 generates an ID attestation 540 indicating one or more immutable HIDs and optionally an ID of the calling application, the challenge value C comprised in the ID attestation request 530, and at least one nonce value N. One-way functions, such as cryptographic hash functions, may be applied to these HIDs before they are included in the ID attestation 540. Thus, the HIDs may be represented as hash values for improved security.

[0111] Steps 1.7 –1.8: The ID attestation 540 is signed by the TEE 140 with the private key of the derived hardware-bound AKP.

[0112] Step 1.9: The DIAM 120 may delete the APK after having received the signed ID attestation 540 for reducing the risk of key leakage.

[0113] Step 2.0: The DIAM 120 sends the signed ID attestation 540 to the application 130. The application 130 receives the signed ID attestation 540 from the DIAM 120 and sends the signed ID attestation 540 to another party that needs to verify the identity of the device 100, i.e., the verifier 600 in Fig. 5. If the signed ID attestation 540 is approved by the verifier 600, the application 130 is allowed to use the requested services such password-less logins, purchases and payments.

[0114] A consumer device or a client device or a device 100 herein may be denoted as a user device, a user equipment (UE) , a mobile station, an internet of things (IoT) device, a sensor device, a wireless terminal and / or a mobile terminal, and is enabled to communicate wirelessly in a wireless communication system, sometimes also referred to as a cellular radio system. The UEs may further be referred to as mobile telephones, cellular telephones, computer tablets or laptops with wireless capability. The UEs in this context may be, for example, portable, pocket-storable, hand-held, computer-comprised, or vehicle-mounted mobile devices, enabled to communicate voice and / or data, via a RAN, with another communication entity, such as another receiver or a server. The UE may further be a station, which is any device that contains an IEEE 802.11-conformant MAC and PHY interface to the WM. The UE may be configured for communication in 3GPP related LTE, LTE-advanced, 5G wireless systems, such as NR, and their evolutions such as mobile networks for the future, as well as in IEEE related Wi-Fi, WiMAX and their evolutions.

[0115] Furthermore, any method according to embodiments of the invention may be implemented in a computer program, having code means, which when run by processing means causes the processing means to execute the steps of the method. The computer program is included in a computer readable medium of a computer program product. The computer readable medium may comprise essentially any memory, such as previously mentioned a ROM, a PROM, an EPROM, a flash memory, an EEPROM, or a hard disk drive.

[0116] Moreover, it should be realized that the he DIAM 120, the device 100 and the certificate authority 300 comprise any necessary communication capabilities in the form of e.g., functions, means, units, elements, etc., for performing or implementing embodiments of the invention. Examples of other such means, units, elements and functions are: processors, memory, buffers, control logic, encoders, decoders, rate matchers, de-rate matchers, mapping units, multipliers, decision units, selecting units, switches, interleavers, de-interleavers, modulators, demodulators, inputs, outputs, antennas, amplifiers, receiver units, transmitter units, DSPs, TCM encoder, TCM decoder, power supply units, power feeders, communication interfaces, communication protocols, etc. which are suitably arranged together for performing the solution.

[0117] Therefore, the processor (s) of the DIAM 120, the device 100 and the certificate authority 300 may comprise, e.g., one or more instances of a CPU, a processing unit, a processing circuit, a processor, an ASIC, a microprocessor, or other processing logic that may interpret and execute instructions. The expression “processor” may thus represent a processing circuitry comprising a plurality of processing circuits, such as e.g., any, some or all of the ones mentioned above. The processing circuitry may further perform data processing functions for inputting, outputting, and processing of data comprising data buffering and device control functions, such as call processing control, user interface control, or the like.

[0118] Finally, it should be understood that the invention is not limited to the embodiments described above, but also relates to and incorporates all embodiments within the scope of the appended independent claims.

Claims

1.A method (200) for a device identity attestation module (120) of a device (100) , the method (200) comprising:deriving (202) an attestation key pair, AKP, by inputting a unique hardware secret, UHS, and an immutable hardware identity, HID, of the device (100) into a first key derivation function, KDF, wherein the UHS is a main key and the HID is at least one key derivation factor in the first KDF;transmitting (204) a certificate request (510) for the AKP to a certificate authority (300) , the certificate request (510) indicating a public key of the AKP and the HID; andreceiving (206) an attestation key certificate (520) for the AKP from the certificate authority (300) , the attestation key certificate (520) indicating the public key of the AKP and the HID.2.The method (200) according to claim 1, wherein the method (200) comprises:deleting the APK after having received the attestation key certificate (520) .3.The method (200) according to claim 1 or 2, wherein the method (200) comprises:receiving an ID attestation request (530) from an application (130) of the device (100) ;deriving the AKP by inputting the UHS and the HID into the first KDF, wherein the UHS is a main key and the HID is at least one key derivation factor in the first KDF;signing an ID attestation (540) with the private key of the AKP, wherein the ID attestation (540) indicates the HID; andtransmitting the signed ID attestation (540) to the application (130) .4.The method (200) according to claim 3, wherein the method (200) comprises:deleting the APK after having signed the ID attestation (540) .5.The method (200) according to any one of the preceding claims, wherein the UHS is an immutable UHS programmed into a one-time-programmable, OTP, memory of the device (100) , or computed from a physical unclonable function, PUF.6.The method (200) according to any one of the preceding claims, wherein the HID is an immutable HID programmed into an OTP memory of the device (100) , or computed from a PUF.7.The method (200) according to any one of the preceding claims, wherein the deriving of the AKP comprises:deriving a private key (D) of the AKP by performing a symmetric key derivation by inputting the HID and the UHS in a second KDF; andderiving the public key of the APK by computing an X-coordinate of the public key of the APK by performing a key agreement using the private key (D) of the AKP, and computing a Y-coordinate of the public key of the APK by solving a curve equation.8.The method (200) according to any one of the preceding claims, wherein the key derivation factor further comprises a type of the device (100) , a serial number of the device (100) , an international mobile number equipment identity, IMEI, a mobile equipment identifier, MEID, a fixed value encoded into a software or a firmware of the device (100) , and a service identity of the device (100) .9.The method (200) according to any one of the preceding claims, wherein the certificate request (510) is signed with a device key of the device (100) and a private key of the AKP.10.The method (200) according to claim 9, wherein the device key is a factory provisioned device key.11.A method (400) for a certificate authority (300) , the method (400) comprising:receiving (402) a certificate request (510) from a device identity attestation module (120) of a device (100) , the certificate request (510) indicating a public key of a AKP and a HID of the device (100) ;generating (404) an attestation key certificate (520) when an association between the AKP and the HID is unique; andtransmitting (406) the attestation key certificate (520) to the device identity attestation module (120) , wherein the attestation key certificate (520) indicates the public key of the AKP and the HID.12.The method (400) according to claim 11, wherein the certificate request (510) is signed with a device key of the device (100) and a private key of the AKP; and wherein the method (400) comprises:generating the attestation key certificate (520) when the association between the AKP and the HID is unique and an association between device key and the AKP is unique.13.The method (400) according to claim 11 or 12, whereinthe association between the AKP and the HID is a one-to-one mapping, and / orthe association between device key and the private key of the AKP is a one-to-one mapping.14.The method (400) according to any one of claims 11 to 13, wherein the HID is an immutable HID programmed into an OTP memory of the device (100) , or computed from a PUF.15.A device identity attestation module (120) of a device (100) , wherein the device (100) comprises a processor and a memory, the memory being configured to store instructions, and the processor being configured to read the instructions to perform the method (200) according to any one of claims 1 to 10.16.A certificate authority (300) comprising a processor and a memory, the memory being configured to store instructions, and the processor being configured to read the instructions to perform the method (400) according to any one of claims 11 to 14.

Images