METHOD FOR END ENTITY ATTESTATION

Abstract

A method for attestation of Control Flow Integrity (CFI) of an application running on an end entity whereby an asymmetric key pair is generated by a Key Management Module (KMM) comprising a private key and a public key, then the public key is signed with a device key unique to the end entity thereby generating a public key certificate which attests to the private key being in possession of the end entity. The asymmetric key pair is based on the executing code of the application and the device key. The attestation claims regarding CFI of the application are signed by the private key in a dedicated signature module.

Claims

1. A computer-implemented method for attestation of Control Flow Integrity (CFI) of an application running on an end entity, the method comprising: generating an asymmetric key pair based on executing code of said application and a device key unique to said end entity, said asymmetric key pair comprising a private key and a public key, generating a public key certificate by signing said public key with said device key, wherein said public key certificate attests to said private key being in possession of said end entity, generating attestation claims regarding CFI of said application, signing said attestation claims by said private key, and validating the signature of said attestation claims by a relying party using said public key certificate, wherein said relying party is not part of said end entity.

2. A method according to claim 1, wherein the generating said asymmetric key pair is based on a secure hash calculated from a text segment of the executing code of said application using a keyed-hash function.

3. A method according to claim 1, wherein said attestation claims are generated in the form of an application attestation token (AAT), said application attestation token comprising an identifier for said application, an identifier for said end entity, said public key certificate, and the signature by said private key.

4. A method according to claim 1, further comprising validating said public key certificate by said relying party before validating the signature of said attestation claims.

5. A method according to claim 1, wherein both said private key and said public key are generated as a sequence of pairs, and wherein said private key is generated as blocks of Pseudo-Random bytes in the form of ((x_1, y_1), . . . , (x_k, y_k)), and wherein said public key is calculated from said private key according to the formula
((f.sub.1(x_1), f.sub.1(y_1)), . . . , (f.sub.1(x_k), f.sub.1(y_k)), where f.sub.1 refers to a one-way function, and k refers to the security level.

6. A method according to claim 1, wherein the attestation claims are signed by said private key using an asymmetric signing algorithm, wherein the asymmetric signing algorithm includes one of a Rivest-Shamir-Adleman (RSA) algorithm, a Digital Signature Algorithm (DSA), or an Elliptic Curve Digital Signature Algorithm (ECDSA).

7. A method according to claim 1, wherein the generating said asymmetric key pair is further based on a random nonce value; and wherein said private key is derived from a device secret, wherein said device secret is calculated as a one-way function f.sub.2 using said executing code, said random nonce value, and said device key as variables; wherein said one-way function f.sub.2 uses the QARMA cipher or a keyed-hash function.

8. A method according to claim 1, wherein said pairs of said private key and said public key are generated using Elliptic Curve Cryptography (ECC) or a Rivest-Shamir-Adleman (RSA) algorithm, the method further comprising generating an additional, random, asymmetric key pair comprising a random private key and a random public key, and generating a random public key certificate by signing said random public key with said private key using an asymmetric signing algorithm, wherein the asymmetric signing algorithm includes one of a Rivest-Shamir-Adleman (RSA) algorithm, a Digital Signature Algorithm (DSA), or an Elliptic Curve Digital Signature Algorithm (ECDSA), wherein said attestation claims are signed by said random private key.

9. A method according to claim 8, wherein said attestation claims are generated in the form of a random application attestation token (RAAT), said random application attestation token comprising an identifier for said application, an identifier for said end entity, said random public key certificate, said public key certificate, said random public key, and the signature by said private key.

10. A method according to claim 8, wherein the attestation claims are signed by securely injecting said private key or said random private key into a signature module dedicated to attestation claim signing.

11. A method according to claim 10, wherein said signature module is an extension of a Pointer Authentication (PA) engine, wherein said PA engine uses a QARMA cipher for generating a Pointer Authentication Code (PAC), and wherein, after generating said public key certificate, a one-way function f.sub.3 of the private key or said random private key is set as a Pointer Authentication Key (PAK).

12. A method according to claim 11, wherein said attestation claims are signed following a Lamport one-time signature scheme wherein a signature of the bit string m_1 . . . m_k is z_1 . . . z_k, where z_i=x_i if m_i=0 and z_i=y_i if m_i=1; and the validating the signature comprises checking that f.sub.4(z_i)=f.sub.4(x_i) when m_i=0 and f.sub.4(z_i)=f.sub.4(y_i) when m_i=1, where f.sub.4 refers to a one-way function.

13. A method according to claim 12, wherein the QARMA cipher is used as the one-way function f.sub.4.

14. A computer-based system comprising: a relying party, and an end entity connected to said relying party, said end entity comprising a processor, a storage medium connected to said processor, and an assigned unique device key, wherein said storage medium is configured to store executing code of an application, and remote attestation instructions, wherein when said remote attestation instructions are executed by said processor the attestation instructions cause said end entity and said relying party to perform a method according to claim 1.

15. A computer-based system according to claim 14, wherein said end entity further comprises a key management module configured to: generate an asymmetric key pair based on said executing code, said device key, and an optional random nonce value, said asymmetric key pair comprising a private key and a public key; and generate a public key certificate by signing said public key with said device key.

16. A computer-based system according to claim 15, wherein said end entity further comprises a signature module dedicated to attestation claim signing, and configured to: generate attestation claims regarding Control Flow Integrity (CFI) of said application in the form of an application attestation token (AAT), and sign said attestation claims after receiving said private key from the key management module by secure injection.

17. A computer-based system according to claim 16, wherein said key management module is further configured to: generate an additional, random, asymmetric key pair comprising a random private key and a random public key, and generate a random public key certificate by signing said random public key with said private key using an asymmetric signing algorithm, wherein the asymmetric signing algorithm includes one of a Rivest-Shamir-Adleman (RSA) algorithm, a Digital Signature Algorithm (DSA), or an Elliptic Curve Digital Signature Algorithm (ECDSA), and wherein said signature module is further configured to sign said attestation claims after receiving said random private key from the key management module by secure injection.

18. A method according to claim 2, wherein the keyed-hash function includes HMAC-SHA256

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0104] In the following detailed portion of the present disclosure, the aspects, embodiments and implementations will be explained in more detail with reference to the example embodiments shown in the drawings, in which:

[0105] FIG. 1 shows a flow diagram of a method in accordance with one embodiment of the first aspect;

[0106] FIG. 2 shows a flow diagram of a method in accordance with another embodiment of the first aspect;

[0107] FIG. 3 shows a flow diagram of a method in accordance with another embodiment of the first aspect;

[0108] FIG. 4 shows a flow diagram of a part of a method in accordance with another embodiment of the first aspect;

[0109] FIG. 5 shows a flow diagram of a method in accordance with another embodiment of the first aspect;

[0110] FIG. 6 shows a flow diagram of a method in accordance with another embodiment of the first aspect;

[0111] FIG. 7 shows a flow diagram of a part of a method in accordance with another embodiment of the first aspect;

[0112] FIG. 8 shows a flow diagram of a part of a method in accordance with another embodiment of the first aspect; and

[0113] FIG. 9 shows a block diagram of a computer-based system in accordance with one embodiment of the second aspect.

DETAILED DESCRIPTION

[0114] FIG. 1 illustrates the core elements and steps of a method of Control Flow Integrity (CFI) attestation of an application running on an end entity in accordance with the first aspect. At a high level, CFI restricts the control-flow of an application to valid execution traces. CFI enforces this property by monitoring the program at runtime and comparing its state to a set of precomputed valid states. If an invalid state is detected, an alert is raised, usually terminating the application. Thus, the method is capable of proving for a relying party that the running code of an application is not modified by an attacker.

[0115] An attestation claim is a statement an end entity makes about itself in order to establish access to a service or other entity, wherein an end entity can be any type of computer-based device capable of running an application, for example a mobile device such as a smartphone. A relying party is a term usually used to refer to a server providing access to a secure software application, however, in this context the relying party can be any entity that is not part of the end entity and that is capable of accepting and validating attestation claims.

[0116] The method uses the executing code 5 of the application 4 that needs its CFI attested, and a device key 3 unique to the end entity 1 on which the application is executed to generate in a first step 101 an asymmetric key pair comprising a private key 6 and a public key 7.

[0117] The asymmetric key pair is generated according to the principles of asymmetric cryptography (also known as public-key cryptography), whereby public keys may be disseminated widely, and private keys are known only to the owner. The generation of the keys depends on cryptographic algorithms based on mathematical problems to produce one-way functions. Effective security only requires keeping the private key 6 private; the public key 7 can be openly distributed without compromising security.

[0118] In a next step 102 a public key certificate 8 is generated. This step comprises signing 103 the public key 7 with the device key 3. The public key certificate 8 can attest to the private key 6 being in possession of the end entity 1.

[0119] The public key certificate is an electronic document that can be used to prove the ownership of a public key, and an associated private key. The certificate includes information about the key, information about the identity of its owner, and the digital signature of an entity that has verified the certificate's contents. If the signature is valid, and the software examining the certificate trusts the issuer, then it can use that key to communicate securely with the certificate's subject.

[0120] In a next step 104 the attestation claims 9 regarding CFI of the application 4 are generated, and subsequently signed 105 by the private key 6. In one embodiment the attestation claims 9 are signed by the private key 6 using an asymmetric signing algorithm, such as the Rivest-Shamir-Adleman RSA algorithm, the Digital Signature Algorithm DSA, or the Elliptic Curve Digital Signature Algorithm ECDSA.

[0121] In a next step 107 the signature of the attestation claims 9 is validated by a relying party 2, using the public key certificate 8.

[0122] In one embodiment both the relying party and the end entity are both included in the same physical device.

[0123] In one embodiment the relying party and the end entity are, or are part of, physically different devices.

[0124] In another embodiment the private key is provisioned in the kernel of the end entity, which then performs the signature operation of the attestation claims.

[0125] In one embodiment both the private key 6 and the public key 7 is generated as a sequence of pairs, wherein the private key 6 is generated as blocks of Pseudo-Random bytes in the form of ((x_1, y_1), . . . , (x_k, y_k)). In one embodiment the private key is generated as 2k*n blocks of Pseudo-Random bytes, where n is output length of one-way function f.sub.1. The public key 7 is then calculated from the private key 6 according to the formula:

((f.sub.1(x_1), f.sub.1(y_1)), . . . , (f.sub.1(x_k), f.sub.1(y_k)),

[0126] where f.sub.1 refers to a one-way function, and k refers to the security level. Possibilities for the one-way functions are the QARMA cipher or a keyed-hash hash function like HMAC-SHA256.

[0127] QARMA is a family of lightweight tweakable block ciphers developed by Qualcomm, where tweakable means that the permutation computed by the cipher on a plaintext is determined by a secret key and an additional user selectable tweak. QARMA is targeted to a very specific set of use cases such as the generation of very short tags by truncation, and it is also designed to be suitable for memory encryption, and the construction of keyed-hash functions. It is meant to be used in fully unrolled hardware implementations.

[0128] A hash function is any function that can be used to map data of arbitrary size to data of a fixed size. The values returned by a hash function are called hash values, hash codes, digests, or simply hashes. A keyed (cryptographic) hash function is a special class of hash function that has certain properties which make it suitable for use in cryptography. It is a mathematical algorithm that maps data of arbitrary size to a bit string of a fixed size (a hash) and is designed to be a one-way function, that is, a function which is infeasible to invert.

[0129] FIG. 2 shows a flow diagram illustrating a possible implementation of the method, wherein generating the asymmetric key pair is further based on a random nonce value 13. In this implementation, steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

[0130] This method further differs from the previous implementation in that the private key 6 is derived from a device secret 14, where the device secret 14 is calculated as a one-way function f.sub.2 using the executing code 5, the random nonce value 13, and the device key 3 as variables as follows:

[0131] secret=f.sub.2(code, nonce, priv_dev);

[0132] wherein the one-way function f.sub.2 uses the QARMA cipher or a keyed-hash function such as HMAC-SHA256.

[0133] The nonce is an arbitrary number that can be used just once in one cryptographic communication. It can be a random or pseudo-random number to ensure that old communications cannot be reused in replay attacks. The inclusion of this random nonce as variable guarantees that the signature will always be done with fresh key.

[0134] FIG. 3 shows a flow diagram illustrating a possible implementation of the method, wherein a dedicated Key Management Module (KMM) 22 is provisioned as part of the end entity 1. In this implementation, steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity. In a first step the application's executing code 5 is loaded in the memory 25 of the end entity 1 for execution. The KMM 22 then initiates measurement of the application code, wherein the text segment (TEXT) 11 of the executing code 5 of the application 4 is used to calculate a secure hash (HASH) 12, preferably using keyed-hash function such as HMAC-SHA256 as follows: h=SHA256(TEXT). The application code 5 can further comprise an elf header (HEAD) and one or more other segments (OTHER) that are however not used for calculating the secure hash.

[0135] The KMM 22 then generates the private key 6 (as part of an asymmetric key pair) and securely injects this private key 6 into a Signature Module (SM) 20 dedicated to generating and signing attestation claims 9. The KMM also generates the public key certificate 8 (by signing the public key 7 with the device key 3), which public key certificate 8 attests to the private key 7 being in possession of the end entity 1.

[0136] The signature module 20 in this embodiment is an extension of a Pointer Authentication (PA) engine 21. Pointer Authentication (PA) is a technology developed to protect CFI of an application and works based on the principle that when the application code is executed on a device the PA engine validates Pointer Authentication Codes (PACs) from instructions, so the device itself gains assurance that the application code is not under run-time attack. The PA technology uses the QARMA cipher for generating a Pointer Authentication Code (PAC). When used for Pointer Authentication, two inputs to QARMA are the pointer and the context. The PAC is the truncated output of QARMA.

[0137] The extended PA engine with the Signature Module (SM) 20 according to this embodiment uses a new asymmetric scheme that is based on the QARMA cipher (or any one-way function) which can compute symmetric authentication tags. Examples of such functions are keyed-hash functions.

[0138] FIG. 4 shows a flow diagram illustrating a possible implementation of the method, wherein the attestation claims 9 are generated in the form of an application attestation token AAT 10, the AAT 10 comprising an identifier for the application 4 (app_id), an identifier for the end entity 1 (device_id), the public key certificate 8 (cert), and the signature by the private key (signature) 6. The app_id, device_id and other-info are relevant identifiers for the end entity that is attested, and signature is the signature of these identifiers signed by the private key.

[0139] In one embodiment the AAT is constructed as follows:

[0140] app_id|device_id[|other-info]|signature|cer

[0141] where notation “|” refers to concatenation and notation “[ ]” refers to an optional element.

[0142] FIG. 5 shows a flow diagram illustrating a possible implementation of the method, wherein the Key Management Module (KMM) 22 runs a Key Derivation Function (KDF). In this implementation, steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

[0143] The KDF is responsible for the tasks of derivation 101 of the asymmetric application specific key pair (pub_app, priv_app) from the secure hash 12 (hash) and the device secret 14. The KMM 22 then initiates generation of the public key certificate 8 (cert_app) using the application specific public key 7 (pub_app) and using the device key 3 (priv_dev), which public key certificate 8 (cert_app) may be further certified by a trusted 3.sup.rd party.

[0144] The KMM 22 also ensures securely injection of the private key 6 (priv_app) into the Signature Module (SM) 20 which is using a dedicated algorithm (called pack_sign) for signing the application attestation token AAT 10.

[0145] The relying party 2 can then validate 106 the public key certificate 8 (cert_app) and use the validated public key certificate 8 for validating 107 the signature of the AAT 10. After the validations the results can be shared with the end entity 1 or a 3.sup.rd party service.

[0146] FIG. 6 shows a flow diagram illustrating a further possible implementation of the method, wherein the pairs of the private key 6 and the public key 7 are generated using Elliptic Curve Cryptography ECC or the RSA algorithm. In this implementation, steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

[0147] This method further differs from the previous implementation in that it comprises generating 201 an additional, random, asymmetric key pair comprising a random private key 15 (pack_priv_app) and a random public key 16 (pack_pub_app), and generating 202 a random public key certificate 17 (cert_pack) by signing 203 the random public key 16 (pack_pub_app) with the private key 6 (priv_app) using an asymmetric signing algorithm such as the RSA, DSA, or ECDSA. The attestation claims in this implementation are generated in the form of a random application attestation token (RAAT) 18 and are signed 204 by the random private key 15 (pack_priv_app).

[0148] The relying party 2 can then validate 106 the public key certificate 8 (cert_app) and the random public key certificate 17 (cert _pack) and use these validated certificates for validating 107 the signature of the RAAT 18. After the validations the results can be shared with the end entity 1 or a 3.sup.rd party service.

[0149] In one embodiment the pack_sign function is implemented by following construction from Lamport One-Time signature scheme, wherein the signature of the bit string m_1 . . . m_k is z_1 . . . z_k, where k is the size of the one-way function output in bits (typically 256, f=SHA256), and the private key 6 and the public key 7 both comprises a sequence of k pairs;

[0150] z_i=x_i if m_i=0 and

[0151] z_i=y_i if m_i=1; and

[0152] the validating the signature 106 comprises checking that

[0153] f.sub.4(z_i)=f.sub.4(x_i) when m_i=0 and

[0154] f.sub.4(z_i)=f.sub.4(y_i) when m_i=1,

[0155] where f.sub.4 refers to a one-way function.

[0156] FIG. 7 shows a flow diagram illustrating a possible implementation of the method, wherein the attestation claims 9 are generated in the form of a random application attestation token (RAAT) 18, the RAAT comprising an identifier for the application 4 (app_id), an identifier for the end entity 1 (device_id), the random public key certificate 17 (cert_pack), the public key certificate 8 (cert), the random public key 16 (pack_pub_app), and the signature by the private key 6 (signature). The app_id, device_id and other-info are relevant identifiers for the end entity that is attested, and signature is the signature of these identifiers signed by the private key.

[0157] In one embodiment the RAAT is constructed as follows:

[0158] app_id|device_id[|other-info]|pack_pub_app|signature|cert_pack|cert

[0159] where notation “|” refers to concatenation and notation “[ ]” refers to an optional element.

[0160] FIG. 8 shows a flow diagram illustrating a possible implementation of the method, wherein the Signature Module (SM) 20 is an extension of a Pointer Authentication (PA) engine 21, and wherein the PA engine 21 uses the QARMA cipher for generating a Pointer Authentication Code (PAC). In this implementation, steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

[0161] After generating the public key certificate 8, a one-way function f.sub.3 of the private key 6 or the random private key 15 is set as a Pointer Authentication Key (PAK).

[0162] The attestation claims are generated in the form of an application attestation token (AAT) 10 or a random application attestation token (RAAT) 18 and are signed by securely injecting the private key 6 or the random private key 15 into the Signature Module (SM) 20.

[0163] FIG. 9 shows a block diagram illustrating an example of a hardware configuration of a computer-based system in accordance with the second aspect. Steps and features that are the same or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numeral as previously used for simplicity.

[0164] The computer-based system may comprise a relying party 2 and an end entity 1 connected to the relying party 2, wherein the type of connection between the two can be direct or indirect, as will be described below. A unique device key 3 may also be assigned to the end entity.

[0165] The end entity 1 may comprise a processor (CPU) 23 for performing data processing and executing software-based instructions, a storage medium 24 (HDD) for storing data to be processed and software-based instructions to be executed by the CPU 23, and a random-access memory (RAM) for temporarily storing an executing code 5 of an application 4. The end entity 1 may also comprise an input device (IN) 26 for receiving input from a user 31, an output device (OUT) 27 such as an electronic display 14 for conveying information to a user 31, and a communication interface (COMM) 28 for communicating with external devices directly or indirectly via a computer network 30.

[0166] Optionally, as shown in FIG. 9, the end entity 1 may also comprise a Key Management Module (KMM) 22 and a Pointer Authentication (PA) engine 21 as described above in relation to the first aspect, wherein the PA engine 21 may further comprise a Signature Module (SM) 20 dedicated to attestation claim signing. The KMM 22 and SM 20 may be configured so as to allow direct, secure injection of a private key 6 or random private key 15 generated by the KMM 22 into the SM 20 for signature generation.

[0167] The mentioned hardware elements within the end entity 1 may be connected via an internal bus 29 for handling data communication and processing operations.

[0168] The relying party 2 may have a similar configuration to the end entity 1. However, the relying party 2 may have more storage and processing resources to be able to serve multiple end entities 1 at once or in a sequence. Some relying parties 2 may not have all the components shown in FIG. 9 in relation with the end entity 1. For example, a relying party 2 may simply comprise a processor (CPU) 23, a storage medium 24 (HDD), a random-access memory (RAM), and a communication interface (COMM) 28 and so may not need an output (display) or user input device. It is noted that FIG. 9 is just one example of a possible hardware configuration and many other components could also be provided within the illustrated devices.

[0169] In one embodiment the relying party 2 and the end entity 1 are both included in the same physical device, connected via the internal bus 29.

[0170] In another embodiment the relying party 2 and the end entity 1 are, or are part of, physically different devices, and are connected via the communication interface (COMM) 28 either directly, or indirectly via a computer network 30.

[0171] In another embodiment the end entity 1 is provisioned with a kernel configured to performs the signature operation of the attestation claims 9.

[0172] In another embodiment the end entity 1 is provisioned with a TEE configured in a secure area of a processor 23 of the end entity 1, wherein the TEE is configured to perform the signature operation of the attestation claims 9.

[0173] The various aspects and implementations has been described in conjunction with various embodiments herein. However, other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed subject-matter, from a study of the drawings, the disclosure, and the appended claims. In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measured cannot be used to advantage. A computer program may be stored/distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems.

[0174] The reference signs used in the claims shall not be construed as limiting the scope.