Methods used for end-entity authentication

Abstract

A method for authenticating the control flow integrity (CFI) of an application (4) running on a terminal entity (1), wherein an asymmetric key pair including a private key (6) and a public key (7) is generated by a key management module (KMM), and then the public key (7) is signed (103) using a unique device key (3) of the terminal entity (1), thereby generating (102) a public key certificate (8) authenticating that the private key (7) belongs to the terminal entity (1). The asymmetric key pair is based on an execution code (5) of the application (4) and the device key (3). A certification statement (9) about the CFI of the application (4) is signed using a private key (6) in a dedicated signature module (20).

Description

Technical Field

[0001] The present invention relates to data security, and more specifically, to a method and system for authenticating the control flow integrity (CFI) of an application running on a terminal entity. Background Art

[0002] End-entity authentication is the process by which a relying party, such as a network server, verifies certain properties of the entity that is requesting a service. For example, the end entity may be a Digital Rights Management (DRM) compliant mobile device that is trusted enough to decrypt content in a secure manner. In this DRM example, a relying party (e.g., a DRM license server) may wish to verify that the mobile device is in a list of trusted vendors (e.g., that the device's property.vendor.ID has not been tampered with).

[0003] Another typical attribute that is authenticated is whether the private key is owned by a Trusted Execution Environment (TEE).

[0004] A third example of such a property to be authenticated is the configuration of the device itself. An existing scheme for such authentication was developed by the Trusted Computing Group (TCG), where a Trusted Platform Module (TPM) in the device monitors the boot process and measures all software processes executed during device boot. These measurements are recorded and accumulated in so-called Platform Configuration Registers (PCRs). The TPM provides a way for a relying party to extract the TPM-signed PCR values, which can then verify that the PCRs match a known approved configuration.

[0005] It is also necessary to authenticate the Control Flow Integrity (CFI) of the application, in other words, to prove to the relying party that the running code of the application has not been modified by the attacker. According to a known method to solve this problem, the authentication device vendor can be reliably identified, and then the relying party only trusts that the vendor provides sufficient countermeasures to prevent tampering with the CFI. These countermeasures can use Pointer Authentication (PA) for Return Oriented Programming (ROP) or use TEE to measure certain segments of the application code. According to another known method, the TEE is used to sign evidence that these countermeasures have actually been implemented.

[0006] The problem with the first approach is that, for example in the case of Spectre or Meltdown attacks that exploit critical vulnerabilities in modern processors, identifying and fixing tampered CFI is a very complex security problem because the CFI origin is often hardware-related. While applications are generally not allowed to read data from other applications, malicious programs can exploit Meltdown and Spectre to obtain secrets stored in the memory of other running programs, such as passwords stored in password managers or browsers, personal photos, emails, instant messages, and even critical business documents. Therefore, it is unreasonable to assume that vendors have no CFI issues at all and that their best efforts are sufficient to prevent malicious attacks.

[0007] The problem with the second approach is that it requires the device to be configured with a TEE. In addition, the TEE must be authenticatable and should implement services that verify the integrity of the applications involved. Summary of the invention

[0008] The object of the present invention is to provide an improved method and apparatus for generating a verifiable authentication statement about the Control Flow Integrity (CFI) of an application program so as to eliminate or reduce the above-mentioned problems.

[0009] The above and other objects are achieved by the features of the independent claims. Further embodiments are apparent from the dependent claims, the detailed description and the drawings.

[0010] According to a first aspect, there is provided a computer-implemented method for authenticating a control flow integrity (CFI) of an application running on a terminal entity, the method comprising:

[0011] Generate an asymmetric key pair based on the execution code of the application and a unique device key of the terminal entity, wherein the asymmetric key pair includes a private key and a public key;

[0012] Generate a public key certificate by signing the public key with the device key, wherein the public key certificate authenticates that the private key belongs to the terminal entity;

[0013] generating a certification statement regarding the CFI of the application;

[0014] signing the authentication statement using the private key; and

[0015] The relying party verifies the signature of the authentication statement using the public key certificate,

[0016] The relying party is not part of the terminal entity.

[0017] In the above manner, a verifiable authentication statement about the control flow integrity (CFI) of the application can be generated by using the unique device key of the terminal entity and the execution code of the application without configuring a trusted execution environment on the terminal entity. Therefore, the method provides a low-cost way to build a lightweight signature and authentication service using major existing hardware blocks on the device.

[0018] Furthermore, when performing the above steps, the unique device key is never shared with the application itself, nor with the relying party, thereby increasing the security and confidentiality of the authentication method. This is a benefit especially in highly complex applications, where a public key certificate provides sufficient evidence that a private key is owned by a specific end entity. Thus, the relying party obtains hardware-level and kernel-level evidence that the application has been measured (not modified) and the device identity has been determined.

[0019] In one embodiment, both the relying party and the end entity are contained in the same physical device.

[0020] In another embodiment, the relying party and the end entity are physically different devices or parts of physically different devices.

[0021] In another embodiment, the private key is provided in the kernel of the terminal entity, and then the signing operation of the authentication statement is performed.

[0022] In another embodiment, the private key is provided in a TEE configured in a secure area of ​​a processor of the terminal entity, and then a signing operation of the authentication statement is performed.

[0023] In another embodiment, a key management module (KMM) is provided as part of the terminal entity, and the KMM is used to generate the asymmetric key pair and generate the public key certificate. In one embodiment, the KMM is also used to securely inject the private key into a separate module dedicated to authentication statement signing.

[0024] In a possible implementation form of the first aspect, the asymmetric key pair is generated based on a secure hash calculated from a text segment of an execution code of the application.

[0025] In one embodiment, the secure hash h is calculated from the text segment (TEXT) of the application code by a keyed hash function such as HMAC-SHA256 as h=SHA256(TEXT).

[0026] In another embodiment, the application code further includes an ELF header (HEAD) and one or more other segments (OTHER).

[0027] In another embodiment, a dedicated key management module is provided as part of the terminal entity, said KMM being used to initiate application code measurement.

[0028] In another possible implementation form of the first aspect, the authentication statement is generated in the form of an application attestation token (AAT), and the AAT includes an identifier of the application (app_id), an identifier of the terminal entity (device_id), the public key certificate (cert), and a signature (signature) generated using the private key.

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

[0030] app_id|device_id[|other-info]|signature|cert, where

[0031] The symbol "|" refers to concatenation, and the symbol "[]" refers to optional elements. app_id, device_id, and other-info are the relevant identifiers of the authenticated terminal entity, and signature is the signature of these identifiers signed using the private key.

[0032] In another possible implementation form of the first aspect, the method further includes:

[0033] Prior to verifying the signature of the authentication statement, the relying party verifies the public key certificate.

[0034] In one embodiment, the relying party verifies the certificate and then uses the certificate to verify the signature of the authentication statement.

[0035] In yet another possible implementation form of the first aspect, the private key and the public key are both generated as a sequence of pairs; the private key is generated as a pseudo-random byte block in the form of ((x_1, y_1), ..., (x_k, y_k)); and

[0036] The public key is calculated from the private key according to the following formula:

[0037] ((f1(x_1),f1(y_1)),…,(f1(x_k),f1(y_k)), where

[0038] f1 refers to the one-way function and k refers to the security level.

[0039] In one embodiment, the private key is generated as 2k*n pseudo-random byte blocks, where n is the output length of the one-way function f1.

[0040] In another possible implementation form of the first aspect, the authentication statement is signed using the private key through an asymmetric signature algorithm such as a Rivest–Shamir–Adleman (RSA) algorithm, a Digital Signature Algorithm (DSA) or an Elliptic Curve Digital Signature Algorithm (ECDSA).

[0041] In yet another possible implementation form of the first aspect, the asymmetric key pair is further generated based on a random nonce value;

[0042] The private key is derived from the device secret, where the device secret is calculated as a one-way function f2 using the execution code, the random nonce value and the device key as variables, as follows:

[0043] secret = f2(code, nonce, priv_dev), where

[0044] The one-way function f2 uses the QARMA cipher or a keyed hash function such as HMAC-SHA256.

[0045] Using a random nonce value eliminates the need to perform the arithmetic operations required for RSA, ECDSA, or DSA operations, which would require relatively complex logic to be implemented in software or hardware. The random nonce guarantees that the signature will always be completed with a new key.

[0046] In another possible implementation form of the first aspect, the private key and the public key pair are generated using an elliptic curve cryptography algorithm (ECC) or an RSA algorithm, and the method further includes:

[0047] generating an additional random asymmetric key pair comprising a random private key and a random public key; and

[0048] Generate a random public key certificate by signing the random public key using the private key through an asymmetric signature algorithm such as RSA, DSA or ECDSA;

[0049] The authentication statement is signed by the random private key.

[0050] This implementation can be applied when an asymmetric key pair generated based on the execution code and the device key is not suitable for signing the authentication statement, but the key pair can be generated as an ECC or RSA key pair. In this embodiment, no random nonce is required because an additional key pair is randomly generated and helps provide a one-time signature scheme.

[0051] In one embodiment, a dedicated key management module (Key Management Module, KMM for short) is provided as a part of the terminal entity, and the KMM is configured as a separate entity to generate the asymmetric key pair and the additional random asymmetric key pair as RSA or ECC keys.

[0052] In another possible implementation form of the first aspect, the authentication statement is generated in the form of a random application attestation token (RAAT), which includes an identifier of the application (app_id), an identifier of the terminal entity (device_id), the random public key certificate (cert_pack), the public key certificate (cert), the random public key (pack_pub_app), and a signature (signature) generated using the private key.

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

[0054] app_id|device_id[|other-info]|pack_pub_app|signature|cert_pack|cert, where

[0055] The symbol "|" refers to concatenation, and the symbol "[]" refers to optional elements. app_id, device_id, and other-info are the relevant identifiers of the authenticated terminal entity, and signature is the signature of these identifiers signed using the private key.

[0056] In yet another possible implementation form of the first aspect, the authentication statement is signed by securely injecting the private key or the random private key into a signature module (signature module, SM for short) dedicated to signing the authentication statement.

[0057] In this embodiment, the authentication statement is not directly signed using the private key, so no additional logic is required to implement the asymmetric signing function. This can be seen as a significant advantage in restricted environments where there is a hardware module to take on this signing function.

[0058] In another possible implementation form of the first aspect, the signature module is an extension of a Pointer Authentication (PA) engine;

[0059] The PA engine generates a Pointer Authentication Code (PAC) using the QARMA cipher; and

[0060] After the public key certificate is generated, the one-way function f3 of the private key or the random private key is set as a Pointer Authentication Key (PAK).

[0061] According to this implementation, the relying party obtains evidence that the data was signed using a key derived from the PA key. If a PA engine is present, this signature scheme requires minimal additional logic because the QARMA primitives already exist on the hardware. Therefore, only additional software may be required, and no new kernel interfaces are required for signing. In addition, using the QARMA cipher results in shorter keys and signatures than using traditional hash functions.

[0062] In another possible implementation form of the first aspect, the authentication statement is signed according to the Lamport one-time signature scheme; the signature of the bit string m_1...m_k is z_1...z_k, where

[0063] If m_i=0, then z_i=x_i;

[0064] If m_i=1, then z_i=y_i;

[0065] The verification of the signature includes: checking

[0066] When m_i=0, f4(z_i)=f4(x_i);

[0067] When m_i=1, f4(z_i)=f4(y_i), where

[0068] f4 refers to a one-way function.

[0069] In one embodiment, k is the size of the one-way function output in bits (usually 256, f4=SHA256), and the private key and the public key each include k pairs of sequences.

[0070] In another embodiment, a random nonce value is used to generate an asymmetric key pair, wherein the random nonce ensures that signing will always be done with a new key.

[0071] In yet another possible implementation form of the first aspect, the QARMA cipher is used as the one-way function f4.

[0072] According to a second aspect, there is provided a computer-based system comprising: a relying party; and

[0073] a terminal entity connected to the relying party;

[0074] The terminal entity includes: a processor;

[0075] a storage medium connected to the processor; and

[0076] The unique device key assigned to

[0077] The storage medium is used to store the execution code and remote authentication instructions of the application program;

[0078] When the remote authentication instruction is executed by the processor, it enables the terminal entity and the relying party to perform the method as described in any possible implementation form of the first aspect.

[0079] By using the unique device key of the terminal entity and the execution code of the application and the remote authentication instruction executed by the processor, a verifiable authentication statement about the control flow integrity (CFI) of the application can be generated without configuring a trusted execution environment on the terminal entity. In addition, according to this setting, the unique device key is never shared with the application itself or with the relying party, thereby improving the security and confidentiality of the authentication method. This is a benefit especially in highly complex applications.

[0080] In one embodiment, both the relying party and the end entity are contained in the same physical device.

[0081] In another embodiment, the relying party and the end entity are physically different devices or parts of physically different devices.

[0082] In another embodiment, a kernel is provided for the terminal entity to perform a signing operation of the authentication statement.

[0083] In another embodiment, a TEE configured in a secure area of ​​a processor of the terminal entity is provided to the terminal entity, and the TEE is used to perform a signing operation of the authentication statement.

[0084] In a possible implementation form of the second aspect, the terminal entity further includes a key management module (Key Management Module, KMM for short), configured to:

[0085] generating an asymmetric key pair based on the execution code, the device key, and an optional random nonce value, the asymmetric key pair comprising a private key and a public key; and

[0086] A public key certificate is generated by signing the public key using the device key.

[0087] The use of dedicated modules to generate asymmetric key pairs and public key certificates ensures efficient and secure operation of the end entity. The use of random nonce values ​​eliminates the need to perform the arithmetic operations required for RSA, ECDSA, or DSA operations, which would require relatively complex logic to be implemented in software or hardware. The random nonce guarantees that the signature will always be completed with a new key.

[0088] In one embodiment, the KMM is further used to securely inject the private key into a separate module dedicated to authentication statement signing.

[0089] In another embodiment, the KMM is used to initiate measurements of the application code. In one embodiment, the KMM is also used to generate a secure hash from a text segment of the application code.

[0090] In another possible implementation form of the second aspect, the terminal entity further includes a signature module (Signature Module, SM for short), which is dedicated to signing the authentication statement and is used to:

[0091] optionally generating an authentication statement about the CFI of the application in the form of an application attestation token (AAT); and

[0092] After receiving the private key from the KMM through secure injection, the authentication statement is signed.

[0093] In this embodiment, the authentication statement is not directly signed using the private key, so no additional logic is required to implement the asymmetric signing function. This can be seen as a significant advantage in restricted environments where there is a hardware module to take on this signing function.

[0094] In one embodiment, the signature module is an extension of a Pointer Authentication (PA) engine.

[0095] In this case, the relying party obtains evidence that the data was signed using a key derived from the PA key. If a PA engine is present, this signature scheme requires minimal additional logic. Only additional software may be required, and no new kernel interface is required for signing. In one embodiment, a QARMA cipher is used to generate the signature, which results in shorter keys and signatures than using a traditional hash function.

[0096] In yet another possible implementation form of the second aspect, the KMM is further used for:

[0097] generating an additional random asymmetric key pair comprising a random private key and a random public key; and

[0098] Generate a random public key certificate by signing the random public key using the private key through an asymmetric signature algorithm such as RSA, DSA or ECDSA;

[0099] The signature module is also used to:

[0100] After receiving the random private key from the key management module, the authentication statement is signed.

[0101] This implementation can be applied when an asymmetric key pair generated based on the execution code and the device key is not suitable for signing the authentication statement, but the key pair can be generated as an ECC or RSA key pair. In this embodiment, no random nonce is required because an additional key pair is randomly generated and helps provide a one-time signature scheme.

[0102] These and other aspects will become apparent from the embodiments described below. BRIEF DESCRIPTION OF THE DRAWINGS

[0103] In the following detailed description of the present invention, these aspects, embodiments and implementations will be explained in more detail in conjunction with exemplary embodiments shown in the accompanying drawings, in which:

[0104] Figure 1 A flowchart of a method provided by an embodiment of the first aspect is shown;

[0105] Figure 2A flowchart showing a method provided by another embodiment of the first aspect;

[0106] Figure 3 A flowchart showing a method provided by another embodiment of the first aspect;

[0107] Figure 4 A flowchart showing a portion of a method provided by another embodiment of the first aspect;

[0108] Figure 5 A flowchart showing a method provided by another embodiment of the first aspect;

[0109] Figure 6 A flowchart showing a method provided by another embodiment of the first aspect;

[0110] Figure 7 A flowchart showing a portion of a method provided by another embodiment of the first aspect;

[0111] Figure 8 A flowchart showing a portion of a method provided by another embodiment of the first aspect;

[0112] Fig. 9 A block diagram of a computer-based system provided by an embodiment of the second aspect is shown. DETAILED DESCRIPTION

[0113] Figure 1 The core elements and steps of the control flow integrity (CFI) authentication method for an application running on a terminal entity provided by the first aspect are shown. In general, CFI limits the control flow of an application to valid execution traces. CFI performs this property by monitoring the program at runtime and comparing its state with a set of pre-computed valid states. If an invalid state is detected, an alarm is issued, usually terminating the application. Therefore, the method can prove to the relying party that the running code of the application has not been modified by an attacker.

[0114] An authentication assertion is a statement made by an end entity about itself to establish access to a service or other entity, where the end entity can be any type of computer-based device capable of running an application, such as a mobile device such as a smartphone. Relying party is a term often used to refer to a server that provides access to a secure software application, but in this context a relying party can be any entity that is not part of the end entity and is capable of accepting and verifying an authentication assertion.

[0115] The method generates an asymmetric key pair including a private key 6 and a public key 7 in a first step 101 using the execution code 5 of the application 4 whose CFI needs to be authenticated and a device key 3 unique to the terminal entity 1 on which the application is executed.

[0116] Asymmetric key pairs are generated based on the principles of asymmetric encryption (also known as public key encryption), where the public key can be widely disseminated, while the private key is known only to the owner. The generation of the keys depends on a cryptographic algorithm based on a mathematical problem to produce a one-way function. Effective security requires only that the private key 6 be kept private, while the public key 7 can be distributed publicly without compromising security.

[0117] In the next step 102, a public key certificate 8 is generated. This step includes: using the device key 3 to sign the public key 7 103. The public key certificate 8 can authenticate that the private key 6 belongs to the terminal entity 1.

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

[0119] In a next step 104, an authentication statement 9 is generated about the CFI of the application 4, and then the authentication statement 9 is signed 105 using the private key 6. In one embodiment, the authentication statement 9 is signed using the private key 6 by an asymmetric signature algorithm such as the Rivest–Shamir–Adleman RSA algorithm, the digital signature algorithm DSA, or the elliptic curve digital signature algorithm ECDSA.

[0120] In a next step 107 , the signature of the authentication statement 9 is verified by the relying party 2 using the public key certificate 8 .

[0121] In one embodiment, both the relying party and the end entity are contained in the same physical device.

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

[0123] In another embodiment, the private key is provided in the kernel of the terminal entity, and then the signing operation of the authentication statement is performed.

[0124] In one embodiment, both the private key 6 and the public key 7 are generated as a sequence of pairs, and the private key 6 is generated as a pseudo-random byte block in the form of ((x_1, y_1), ..., (x_k, y_k)). In one embodiment, the private key is generated as 2k*n pseudo-random byte blocks, where n is the output length of the one-way function f1. Then, the public key 7 is calculated from the private key 6 according to the following formula:

[0125] ((f1(x_1),f1(y_1)),…,(f1(x_k),f1(y_k)), where

[0126] f1 refers to the one-way function and k refers to the security level. The one-way function may be the QARMA cipher or a keyed hash function such as HMAC-SHA256.

[0127] QARMA is a lightweight, tunable block cipher developed by Qualcomm, where "tunable" means that the permutations computed on the plaintext using the cipher are determined by a secret key and an additional user-selectable adjustment. QARMA targets a very specific set of use cases, such as generating very short tags by truncation. It is also designed to be suitable for memory encryption and the construction of keyed hash functions. It is intended to be used in a fully expanded hardware implementation.

[0128] A hash function is any function that can be used to map data of arbitrary size to data of fixed size. The value returned by a hash function is called a hash value, hash code, digest or simply hash. A keyed (cryptographic) hash function is a special class of hash functions that has certain properties that make it suitable for use in cryptography. It is a mathematical algorithm that maps data of arbitrary size to a fixed-size bit string (hash) and is designed to be a one-way function, i.e., irreversible.

[0129] Figure 2 A flow chart of a possible implementation of the method is shown, wherein the asymmetric key pair is also generated 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 represented by the same reference numerals as previously used for simplicity.

[0130] This method also differs from previous implementations in that the private key 6 is derived from the device secret 14, where the device secret 14 is calculated as a one-way function f2 using the execution code 5, the random nonce value 13 and the device key 3 as variables, as follows:

[0131] secret = f2(code, nonce, priv_dev), where

[0132] The one-way function f2 uses the QARMA cipher or a keyed hash function such as HMAC-SHA256.

[0133] A nonce is an arbitrary number that can only be used once in an encrypted communication. It can be random or pseudo-random to ensure that old communications cannot be reused in a replay attack. Including this random nonce as a variable ensures that signing will always be done with a new key.

[0134] Figure 3 A flow chart of a possible implementation of the method is shown, wherein a dedicated Key Management Module (KMM) 22 is provided as part of the terminal entity 1. In this implementation, steps and features that are identical or similar to corresponding steps and features previously described or shown herein are denoted by the same reference numerals as previously used for simplicity. In a first step, the execution code 5 of the application is loaded into the memory 25 of the terminal entity 1 for execution. Then, the KMM 22 initiates the measurement of the application code, wherein the text segment (TEXT) 11 of the execution code 5 of the application 4 is used to calculate a secure hash (HASH) 12, preferably by a keyed hash function such as HMAC-SHA256, as follows: h=SHA256(TEXT). The application code 5 may also include an ELF header (HEAD) and one or more other segments (OTHER), but the ELF header (HEAD) and one or more other segments (OTHER) are not used to calculate the secure hash.

[0135] The KMM 22 then generates a private key 6 (as part of an asymmetric key pair) and securely injects the private key 6 into a signature module (SM) 20 dedicated to generating and signing authentication statements 9. The KMM also generates a public key certificate 8 (by signing the public key 7 with the device key 3) that authenticates that the private key 7 belongs to the terminal entity 1.

[0136] The signature module 20 in this embodiment is an extension of the Pointer Authentication (PA) engine 21. Pointer Authentication (PA) is a technology developed to protect the CFI of applications. Its working principle is that when the application code is executed on the device, the PA engine verifies the Pointer Authentication Code (PAC) from the instruction, so the device itself obtains the guarantee that the application code will not be attacked at runtime. PA technology uses the QARMA cipher to generate the Pointer Authentication Code (PAC). When used for pointer verification, the two inputs of QARMA are the pointer and the context. PAC is the truncated output of QARMA.

[0137] The extended PA engine with a signature module (SM) 20 provided in this embodiment uses a new asymmetric scheme based on the QARMA cipher (or any one-way function) to calculate a symmetric authentication tag. An example of such a function is a keyed hash function.

[0138] Figure 4 A flow chart of a possible implementation of the method is shown, wherein the authentication statement 9 is generated in the form of an application authentication token AAT 10, which includes an identifier (app_id) of the application 4, an identifier (device_id) of the terminal entity 1, a public key certificate (cert) 8, and a signature (signature) generated using a private key 6. app_id, device_id, and other-info are related identifiers of the terminal entity to be authenticated, and signature is the signature of these identifiers signed using the private key.

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

[0140] app_id|device_id[|other-info]|signature|cert, where

[0141] The symbol "|" refers to concatenation, and the symbol "[]" refers to optional elements.

[0142] Figure 5A flow chart of a possible implementation of the method is shown, wherein a 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 represented by the same reference numerals as previously used for simplicity.

[0143] The KDF is responsible for the task of deriving 101 an asymmetric application-specific key pair (pub_app, priv_app) from a secure hash 12 and a device secret 14. The KMM 22 then uses the application-specific public key (pub_app) 7 and the device key (priv_dev) 3 to initiate the generation of a public key certificate (cert_app) 8, which can be further authenticated by a trusted third party.

[0144] The KMM 22 also ensures that the private key (priv_app) 6 is securely injected into the Signature Module (SM) 20, which signs the application authentication token AAT 10 using a dedicated algorithm (called pack_sign).

[0145] The relying party 2 may then verify 106 the public key certificate (cert_app) 8 and use the verified public key certificate 8 to verify 107 the signature of the AAT 10. After verification, the result may be shared with the end entity 1 or a third party service.

[0146] Figure 6 A flow chart of another possible implementation of the method is shown, wherein the private key 6 and the public key 7 pair are generated using an elliptic curve cryptography algorithm ECC or an RSA algorithm. In this implementation, steps and features that are identical or similar to corresponding steps and features previously described or shown in this document are represented by the same reference numerals as previously used for simplicity.

[0147] The method also differs from the previous implementation in that the method comprises: generating 201 an additional random asymmetric key pair comprising a random private key (pack_priv_app) 15 and a random public key (pack_pub_app) 16; and signing 203 the random public key (pack_pub_app) 16 using the private key (priv_app) 6 by an asymmetric signature algorithm such as RSA, DSA or ECDSA to generate 202 a random public key certificate (cert_pack) 17. The authentication statement in the present implementation is generated in the form of a random application attestation token (RAAT) 18 and signed 204 by the random private key (pack_priv_app) 15.

[0148] The relying party 2 may then verify 106 the public key certificate (cert_app) 8 and the random public key certificate (cert_pack) 17 and use these verified certificates to verify 107 the signature of the RAAT 18. After verification, the results may be shared with the end entity 1 or a third party service.

[0149] In one embodiment, the pack_sign function is implemented by constructing from the Lamport one-time signature scheme as follows; 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 (usually 256, f=SHA256), and the private key 6 and the public key 7 each include a sequence of k pairs;

[0150] If m_i=0, then z_i=x_i;

[0151] If m_i=1, then z_i=y_i;

[0152] The verification 106 of the signature includes: checking

[0153] When m_i=0, f4(z_i)=f4(x_i);

[0154] When m_i=1, f4(z_i)=f4(y_i), where

[0155] f4 refers to a one-way function.

[0156] Figure 7A flow chart of a possible implementation of the method is shown, wherein the authentication statement 9 is generated in the form of a random application attestation token (RAAT) 18, the RAAT includes an identifier (app_id) of the application 4, an identifier (device_id) of the terminal entity 1, a random public key certificate (cert_pack) 17, a public key certificate (cert) 8, a random public key (pack_pub_app) 16, and a signature (signature) generated using a private key 6. app_id, device_id, and other-info are related identifiers of the terminal entity being authenticated, and signature is the signature of these identifiers signed using 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, where

[0159] The symbol "|" refers to concatenation, and the symbol "[]" refers to optional elements.

[0160] Figure 8 A flow chart of a possible implementation of the method is shown, wherein a Signature Module (SM) 20 is an extension of a Pointer Authentication (PA) engine 21, and the PA engine 21 generates a Pointer Authentication Code (PAC) using a QARMA cipher. In this implementation, steps and features that are identical or similar to corresponding steps and features previously described or shown herein are represented by the same reference numerals as previously used for simplicity.

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

[0162] The authentication statement is generated in the form of an application attestation token (AAT) 10 or a random application attestation token (RAAT) 18, and is signed by securely injecting the private key 6 or the random private key 15 into a signature module (SM) 20.

[0163] Fig. 9 A block diagram showing an example of a hardware configuration of a computer-based system provided by the second aspect. Steps and features that are the same or similar to corresponding steps and features previously described or shown herein are represented by the same reference numerals as previously used for simplicity.

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

[0165] The terminal entity 1 may include: a processor (CPU) 23 for performing data processing and executing software-based instructions; a storage medium (HDD) 24 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 the execution code 5 of the application 4. The terminal entity 1 may also include: an input device (IN) 26 for receiving input from a user 31; an output device (OUT) 27, such as an electronic display 14, for transmitting information to the user 31; and a communication interface (COMM) 28 for communicating directly or indirectly with an external device via a computer network 30.

[0166] Alternatively, if Fig. 9 As shown, the terminal entity 1 may further include the key management module (Key Management Module, KMM for short) 22 and the pointer authentication (PA for short) engine 21 described above in combination with the first aspect, wherein the PA engine 21 may further include a signature module (Signature Module, SM for short) 20 specifically used for authenticating the statement signature. The KMM 22 and the SM 20 may be configured to allow the private key 6 or the random private key 15 generated by the KMM 22 to be directly and securely injected into the SM 20 in order to generate a signature.

[0167] The mentioned hardware elements within the terminal entity 1 may be connected via an internal bus 29 to handle data communications and processing operations.

[0168] Relying Party 2 may have a similar configuration as End Entity 1. However, Relying Party 2 may have more storage and processing resources, thereby being able to serve multiple End Entities 1 at once or sequentially. Some Relying Parties 2 may not have the same Fig. 9 For example, the relying party 2 may only include a processor (CPU) 23, a storage medium (HDD) 24, a random-access memory (RAM) and a communications interface (COMM) 28, and thus may not require an output device (display) or a user input device. It should be noted that Fig. 9 This is just one example of a possible hardware configuration, and many other components may be provided in the illustrated device.

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

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

[0171] In another embodiment, a kernel is provided for the terminal entity 1 for performing a signing operation of the authentication statement 9 .

[0172] In another embodiment, a TEE configured in a secure area of ​​the processor 23 of the terminal entity 1 is provided for the terminal entity 1 , and the TEE is used to perform a signing operation of the authentication statement 9 .

[0173] Various aspects and implementations are described herein in conjunction with various embodiments. However, those skilled in the art can understand and obtain other variations of the disclosed embodiments by practicing the present subject matter, studying the drawings, the present invention, and the appended claims. In the claims, the word "comprising" does not exclude other elements or steps, and the quantifier "one" or "an" does not exclude a plurality. A single processor or other unit may satisfy the functions of several items described in the claims. The mere fact that certain measures are recorded in mutually different dependent claims does not mean that the combination of these measures cannot be effectively used. The computer program may be stored or distributed on a suitable medium, such as an optical storage medium or solid-state medium provided together with other hardware or as part of other hardware, and may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunications systems.

[0174] Reference signs used in the claims should not be construed as limiting the scope.

Claims

1. A computer-implemented method for authenticating the Control Flow Integrity (CFI) of an application (4) running on a terminal entity (1), characterized in that: The method comprises: Generate an asymmetric key pair based on the execution code (5) of the application (4) and a unique device key (3) of the terminal entity (1), wherein the asymmetric key pair includes a private key (6) and a public key (7); Generate a public key certificate (8) by signing the public key (7) using the device key (3), wherein the public key certificate (8) authenticates that the private key (6) belongs to the terminal entity (1); generating a certification statement (9) about the CFI of the application (4); using the private key (6) to sign the authentication statement (9); and The relying party (2) verifies the signature of the authentication statement (9) using the public key certificate (8), wherein The relying party (2) is not a part of the terminal entity (1).

2. The method according to claim 1, characterized in that The asymmetric key pair is generated based on a secure hash (12) calculated from a text segment (11) of the execution code (5) of the application (4) by a keyed hash function, wherein the keyed hash function includes HMAC-SHA256.

3. The method according to any one of claims 1 or 2, characterized in that The authentication statement (9) is generated in the form of an application attestation token (AAT) (10), which includes an identifier of the application (4), an identifier of the terminal entity (1), the public key certificate (8) and a signature generated using the private key (6).

4. The method according to claim 1, characterized in that: Also includes: Prior to verifying the signature of the authentication statement (9), the relying party (2) verifies the public key certificate (8).

5. The method according to claim 1, characterized in that The private key (6) and the public key (7) are both generated as a sequence of pairs; The private key (6) is generated as a pseudo-random byte block in the form of ((x_1, y_1), ..., (x_k, y_k)); and The public key (7) is calculated from the private key (6) according to the following formula: ((f1(x_1),f1(y_1)),…,(f1(x_k),f1(y_k))), where f1 refers to the first one-way function, and k refers to the security level.

6. The method according to claim 1, characterized in that The authentication statement (9) is signed using the private key (6) through an asymmetric signature algorithm, wherein the asymmetric signature algorithm using the private key (6) for signing includes a Rivest–Shamir–Adleman (RSA) algorithm, a Digital Signature Algorithm (DSA) or an Elliptic Curve Digital Signature Algorithm (ECDSA).

7. The method according to claim 1, characterized in that Also generating the asymmetric key pair based on the random nonce value (13); The private key (6) is derived from a device secret (14), wherein the device secret (14) is calculated as a second one-way function f2 using the execution code (5), the random nonce value (13) and the device key (3) as variables; The second one-way function f2 uses the QARMA cipher or a keyed hash function, wherein the keyed hash function includes HMAC-SHA256.

8. The method according to claim 1, characterized in that The private key (6) and the public key (7) pair are generated using an elliptic curve cryptography algorithm (ECC) or an RSA algorithm, and the method further comprises: generating an additional random asymmetric key pair comprising a random private key (15) and a random public key (16); and The random public key (16) is signed by the private key (6) through an asymmetric signature algorithm to generate a random public key certificate (17), wherein The asymmetric signature algorithm includes RSA, DSA or ECDSA; The authentication statement (9) is signed by the random private key (15).

9. The method according to claim 8, characterized in that The authentication statement (9) is generated in the form of a random application attestation token (RAAT) (18), wherein the random application attestation token includes an identifier of the application (4), an identifier of the terminal entity (1), the random public key certificate (17), the public key certificate (8), the random public key (16), and a signature generated using the private key (6).

10. The method according to claim 8, characterized in that The authentication statement (9) is signed by securely injecting the private key (6) or the random private key (15) into a signature module (20) dedicated to authentication statement signing.

11. The method according to claim 10, characterized in that The signature module (20) is an extension of the Pointer Authentication (PA) engine (21); The PA engine (21) generates a Pointer Authentication Code (PAC) using the QARMA cipher; as well as After the public key certificate (8) is generated, the third one-way function f3 of the private key (6) or the random private key (15) is set as a pointer authentication key (PAK).

12. The method according to claim 1, characterized in that The authentication statement (9) is signed according to the Lamport one-time signature scheme; The signature of the bit string m_1...m_k is z_1...z_k, where if m_i=0, then z_i=x_i; if m_i=1, then z_i=y_i; The verification of the signature includes: checking that when m_i=0, f4(z_i)=f4(x_i); when m_i=1, f4(z_i)=f4(y_i), where f4 refers to the fourth one-way function.

13. The method according to claim 12, characterized in that The fourth one-way function f4 uses the QARMA cipher.

14. A computer-based system, characterized in that include: Relying Party (2); as well as A terminal entity (1) connected to the relying party (2); The terminal entity (1) comprises: a processor (23); a storage medium (24) connected to the processor (23); and The assigned unique device key (3), where The storage medium (24) is used to store the execution code (5) of the application program (4) and the remote authentication instruction; When the remote authentication instruction (19) is executed by the processor (23), it causes the terminal entity (1) and the relying party (2) to perform the method according to any one of claims 1 to 13.

15. The computer-based system of claim 14, wherein: The terminal entity (1) further comprises a key management module (22) for: generating an asymmetric key pair based on the execution code (5), the device key (3) and an optional random nonce value (13), the asymmetric key pair comprising a private key (6) and a public key (7); and A public key certificate (8) is generated by signing the public key (7) using the device key (3).

16. The computer-based system of claim 15, wherein: The terminal entity (1) further comprises a signature module (20) which is dedicated to signing the authentication statement and is used to: optionally generating an authentication statement (9) about the CFI of the application (4) in the form of an application attestation token (AAT) (10); as well as After receiving the private key (6) from the key management module (22) through secure injection, the authentication statement (9) is signed.

17. The computer-based system of claim 16, wherein: The key management module (22) is also used for: generating an additional random asymmetric key pair comprising a random private key (15) and a random public key (16); and Using the private key (6) to sign the random public key (16) using an asymmetric signature algorithm to generate a random public key certificate (17), wherein the asymmetric signature algorithm includes RSA, DSA or ECDSA; The signature module (20) is also used for: After receiving the random private key (15) from the key management module (22) through secure injection, the authentication statement (9) is signed.

Images