WO2023186328A1

WO2023186328A1 - Method and apparatus for providing an application-level attestation for trusted applications

Info

Publication number: WO2023186328A1
Application number: PCT/EP2022/058792
Authority: WO
Inventors: Sandeep TAMRAKAR; Pekka Laitinen; Jan-Erik Ekberg; Sampo Sovio; Arto NIEMI
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2022-04-01
Filing date: 2022-04-01
Publication date: 2023-10-05

Abstract

A method of providing an application-level attestation for trusted applications includes a Trusted Service Manager, TSM, (206) communicating with a Trusted Execution Environment, TEE, (106, 214A) of a computing device to verity levels of security of the TEE (106, 214A) and an Application Specific Key Usage Module, ASKUM (104, 204). The method then includes creating a Security Domain, SD, (220) in the TEE (106, 214A) by means of an application programming interface, API, of the TEE (106, 214A) in response to a request of the TSM (206) that has verified the levels of security of the TEE (106, 214A) and the ASKUM (104, 204). The method further includes providing the TEE (106, 214A) by the TSM (206) with one or more key certificates and one or more application keys dedicated to a Trusted Application, TA, (222) installed to the SD (220) by the TSM (206).

Description

METHOD AND APPARATUS FOR PROVIDING AN APPLICATION-LEVEL ATTESTATION FOR TRUSTED APPLICATIONS

TECHNICAL FIELD

The disclosure relates to attestation guarantees, more particularly, the disclosure relates to a method and an apparatus for providing an application-level attestation for trusted applications.

BACKGROUND

Mobile devices include execution environments in executing applications on the mobile devices. The mobile devices may include more than one execution environment including a regular execution environment, REE, and a secure, trusted execution environment, TEE. The REE is used to host rich Operating Systems, OSs such as Android, and the TEE is a restrictive environment that executes security-critical operations. The applications running on the TEE are Trusted Applications, TAs, and the applications running on the REE that communicates with the TA are client applications. Most of the TAs include a relationship with the client applications, i.e. TA may be a part of an application package of the client application. Normally, the TAs and the client applications are signed using a same application signing keys. Some TAs may be designed only to communicate with corresponding client applications. Some TAs can be accessed from multiple client applications, where access control on the client applications are proprietary and may require support from the TEE OS. Global Platform, an industrial consortium, defines and maintains standards for one or more aspects of the TEE, and defines a TA-to-TA interface that allows the TA to communicate with another TA running on the same TEE. Further, the TAs may use whitelist as an Access Control List, ACL, where the whitelist includes TA identifiers i.e. UUIDs of the TAs for communicating with the target TA.

Nowadays, the mobile devices are capable of hosting more than one TEEs. TEEs in many computing devices assisted with a could technology enables services and applications to move around from one computing device to another one or to a cloud environment providing new user experiences. The TA-to-TA interface allowing two TAs within the TEE to communicate is no longer sufficient as TAs are expected to communicate with a range of other entities outside the TEE. For example, in a mobile wallet, that serves as digital identity of users. Most services including banking, and e-govemance services, include their user credentials and mechanisms for authorizing users. The mobile wallet unifies the identity service where there will be a single wallet application with a TA, that acts as government-issued digital identity of users. Most of the services rely on the mobile wallet TA for identity proof of users before authorizing the users to access the services. So, there is a need for other TAs to communicate with the wallet TA, and other entities outside the TEE.

The TEE assures a target TA that the source TA is running within the TEE, where it cannot provide guarantees during a TA-to-TA communication in an inter-TEE environment. To allow the source TA running on a different TEE to communicate with a target TA or service, the target TA requires one or more assurances including the source TA who it claims to be with identity, and the source TA has not been compromised and is running in a secure environment with an adequate level of security, from a trusted authority. Based on the assurances, the target TAs and other remote services authorize the source TA to access their services.

Attestation is one of the ways to provide such guarantees that allow the source TA to prove that the TA is a legitimate TA and meets the required criteria, where claims are certified by a trusted entity by signing them with an attestation key. The certified claims may be used as attestation evidence. The target entity verifies the attestation evidence before authorizing the source TA to access its functionality. The verification of the attestation evidence requires the target entity to have access to the attestation verification keys and trust the trusted authority that produces the attestation evidence.

Global Platform specified Authorization Token (TMF ASN.l profile) that allows TSMs to interact with security domains, SDs to create or update the sub-SDs or the TA, which does not define the authorization tokens for the TA to communicate with remote entities or other TAs outside the TEE. Further, the Global Platform specifications does not include any application-specific attestation for TA where the TEE can attest the TA, using TA-specific attestation key with identity, and integrity guarantees.

Another existing method includes an Android key attestation that ensures verifier that a key is protected by hardware-backed security. Android Keystore has been primarily used to create, store, and use cryptographic keys with a hardware-backed key storage. Android key and ID attestation is a mechanism that aims to assure verifiers that a key is protected by the hardware-backed security. The ID attestation allows the device to provide proof of its hardware identifiers including a serial number or IMEI number. The key attestation has been included since Android 7.1, where the android device consists of a factory- provisioned class key that is used for attestation. The attestation evidence is signed using a class key to produce an attestation certificate which is a standard X.509 certificate with an attestation extension containing a description of the attested key. This method may increases key exposure by reusing of single keys which can become a privacy issue, as the same key is used to produce attestation for various applications or keys secured by hardware security. A malicious authority can discover a number of applications or keys that a user device has based on the attestation key. For example, a malicious authority can keep track of all applications that use attestion evidences on various online services, that have been signed by (attested using) the attestation key, especially in the case when the attestation key is device-specific. . Attestation using class keys or device-specific attestation keys are not scalable to apply fine-grain policy on keys for a large number of TAs in different devices. Further, the android key attestation cannot be used to attest application-specific claims made by the TAs, instead the android key attestation attests that a key is protected using hardware-backed security.

Another existing method includes the TA with integrated attestation functionality within the TA itself. The TA receives and maintain TA-specific attestation keys provisioned by service providers. The TA generates claims that are allowed within the logic of the TA code. The TA may use the attestation key to sign the claims to produce attestation evidence that can be verified by a verifier. But this method requires TAs that integrate attestation functionality and manages attestation keys individually. Integrating attestation functionality requires additional TA logic that increases the code size and also increases the attack surface.

These existing methods providing such attestation can be used to provide identity guarantee but cannot guarantee the state of the TA or the state of the TEE, and it cannot provide a guarantee to a verifier that the TA is uncompromised and is running in a TEE with an adequate level of trust. A compromised TA can attest any data that the malicious entity directs it to attest by using the attestation key. In view of the existing methods, there remains a need for TA independent mechanism for providing application-level attestation for the TA that provides identity and integrity guarantees, allows one or more TAs to use attestation with their application specific attestation keys, privacy aware that a remote entity can’t profile various TAs installed on user’s device based on the attestation key, flexible that allows authorities to define policies, hassle-free that doesn’t require TAs to maintain keys and attestation, and compatible with different TAs from different TA vendors and service providers.

Therefore, the present invention aims to improve attestation guarantees of existing apparatuses or methods with higher level of trust guarantees and privacy.

SUMMARY

It is an object of the disclosure to provide a method and an apparatus of providing an application-level attestation for trusted applications with a higher level of trust guarantees and privacy while avoiding one or more disadvantages of prior art approaches.

This object is achieved by the features of the independent claims. Further implementations are apparent from the dependent claims, the description, and the figures.

The disclosure provides a method and an apparatus of providing an application-level attestation for trusted applications.

According to a first aspect, there is provided a method of providing an application-level attestation for trusted applications. The method includes communicating of a Trusted Service Manager, TSM, with a Trusted Execution Environment, TEE, of a computing device to verify levels of security of the TEE and an Application Specific Key Usage Module, ASKUM. The method includes creating a Security Domain, SD, in the TEE by means of an application programming interface, API, of the TEE in response to a request of the TSM that has verified the levels of security of the TEE and the ASKUM. The method includes providing the TEE by the TSM with one or more key certificates and one or more application keys dedicated to a Trusted Application, TA, installed to the SD by the TSM. The method includes sending an attestation request from the TA to the ASKUM through the API. The attestation request specifies a cryptographic operation requiring an application key and supplies data to be subject to the cryptographic operation. The method includes accessing by the ASKUM the one or more key certificates in response to receiving the attestation request to select an application key among the one or more application keys that can be used for the specified cryptographic operation. The method includes performing by the ASKUM the specified cryptographic operation on the supplied data using the selected application key. The method includes providing a result of the cryptographic operation from the ASKUM to the TA through the API.

This method uses TSMs to issue application specific keys and usage policies that TAs may use for cryptographic operations. At that, the TEE provides assurances for (i) assuring the level of its security that it provides to supports the ASKUM to the TSM, where the level of security can be attested using a device specific key, (ii) provides a statement to the TSM that ensures application specific keys provisioned by the TSM on SDs are not exposed to TAs and other SDs, but are allowed to be used by the TAs via interfaces to the ASKUM, and the ASKUM operates at least on same security level as the TEE and can be considered as a part of Trusted Computing Base, and verifies a key usage policy before operating on the keys, (iii) provides an interface that allows TSMs to create SDs, provision keys and data to be stored in SD specific private storage, and install TAs, and (iv) provides an interface that allows TAs to request cryptographic operations on supplied data using application specific keys, which the interface allows the TA to specify the cryptographic operation, the priority order of the key, and supply data on which the cryptographic function is to be operated.

This method allows the TA to use APIs for operations on keys without the knowledge of the keys, allows dynamic provisioning of keys in SD for application specific purposes, and allows remote authorities to define policies on the key usages that will be enforced by the trusted computing-based of the device. This method assures policy enforcement on the key usage by the TEE and allows TSMs to share application specific keys among various TAs under same SD or use the same key across all the SDs with the same UUID installed on various devices. This method also provides a higher level of trust guarantees where keys are maintained by key issuer and key operations are handled by TEEs.

This method enables maintaining of the application specific keys and policy on keys by the TSM on the SDs in the TEEs, which the TEE provides secure storage for the SDs, keys can be updated by the TSM as needed without firmware updates, or support from TEE providers, or updating TAs, and provides quicker response to key revocation. This method provides policy enforced application specific key operations for TAs where the ASKUM and the TEE ensure that the policy associated with the keys are enforced during key operations. This method enables the TA as an independent module where key operations and policy enforcements are handled by the ASKUM, and the TA uses TEE API for key usage. This method enables scalable policy definition by defining each key with a different policy, where the TSM creates a hierarchical SD structure where keys and policies can be shared among TAs installed in the same SD or shared among sub- SDs, different levels of SDs can have different keys with independent usage policies, and TAs can be installed in the SD with desired key usage policies. This method enables a flexible and dynamic key structure that improves privacy with multiple keys on the SDs, where the SDs include TA-specific key or SD-specific keys shared among TAs under the SD. This method provides a higher level of trust guarantees and relies on industrial standard.

Optionally, the providing of the TEE by the TSM with one or more key certificates and one or more application keys in the method includes providing one or more key usage policies associated with the one or more application keys. The key usage policies define conditions of a use of the one or more application keys. The method includes accessing by the ASKUM of the one or more key certificates in response to receiving the attestation request including reading the one or more key usage policies to select the application key that can be used for the specified cryptographic operation. The method further includes before performing the specified cryptographic operation, checking by the ASKUM if conditions of the use of the selected application key for the TA and the specified cryptographic operation are met, the conditions being defined by the key usage policy associated with the selected application key.

Optionally, the communicating of the TSM with the TEE in the method includes providing from the TEE to the TSM a special attestation claims signed with a special attestation key pre-provisioned to the computing device during its manufacture. The special attestation claims are configured to verify that the ASKUM is at the same or higher level of security as the TEE, application keys will be stored in a private storage and will be used in accordance with key usage policies associated with them.

Optionally, the method includes providing the TEE by the TSM with one or more key certificates, one or more application keys, and one or more key usage policies including storing the one or more key certificates, the one or more application keys and the one or more key usage policies into a private storage in the SD. Optionally, the key usage policies define that the one or more application keys can be read only by the ASKUM and for what cryptographic operations the one or more application keys can be used, and the ASKUM is implemented within the TEE or in a separate secure component.

Optionally, the API is an operation-specific interface, and the attestation request comprises an identifier of the cryptographic operation.

Optionally, the one or more application keys include several application keys available for one cryptographic operation, and the attestation request related to said one cryptographic operation further includes a priority order in which the available application keys are to be used for said one cryptographic operation.

Optionally, the method includes providing of a result of the cryptographic operation to the TA includes providing an attestation evidence.

Optionally, each key usage policy includes a set of claims, and the ASKUM is configured to include the set of claims into the attestation evidence as attested claims.

Optionally, the set of claims define application-specific claims that the TA can supply in the attestation request for the inclusion into the attestation evidence, and the ASKUM is configured to verify that the supplied application-specific claims are allowed by the set of claims of the key usage policy and/or correspond to allowed types of claims listed in the key usage policy associated with the application key.

Optionally, the ASKUM is configured to add further claims into the attestation evidence in accordance with the key usage policy.

Optionally, the attestation evidence includes a verifiable statement signed by an attestation key associated with the TA stored in the SD. Optionally, the SD stores one or more attestation keys associated with the TA, and the attestation request indicates a priority order in which the one or more attestation keys are to be used.

Optionally, the method further includes sending the attestation evidence by the TA to a verifier configured to verify the attestation evidence using an attestation verification key.

Optionally, the attestation key includes an asymmetric key pair, where a private part of the key pair is used to generate the attestation evidence and a public part of the key pair is used as the attestation verification key. Optionally, the method further includes the TA sending a public key certificate of the attestation key and an associated key usage policy to the verifier, using by the verifier the public key from the public key certificate as the attestation verification key to verify the signature of the attestation evidence, and using by the verifier the associated key usage policy to verify claims comprised in the attestation evidence.

Optionally, the method further includes the verifier obtaining the attestation verification key from a certificate issuer or a key provisioner.

Optionally, the attestation key and the attestation verification key include a symmetric key. Optionally, the method further includes the verifier obtaining the attestation verification key from a key issuer directly using a trusted mechanism.

Optionally, the one or more key usage policies are defined by using an Object Identifier, OID, or a separate policy language and stored in the one or more key certificates as an extension or in a separate policy file.

Optionally, each key usage policy associated with an application key includes a hash value stored in a common policy file.

Optionally, each key usage policy is stored in a policy file that includes an associated application key or an associated application key identifier.

Optionally, the policy file is signed by a trusted entity.

Optionally, the one or more application keys are dedicated for SDs with certain Universally Unique Identifier, UUID, in a plurality of computing devices, and the attestation key is configured as a class key shared among a plurality of SDs with the same UUID.

Optionally, the verifier includes one of another TA running in the same TEE, another TA running in another TEE on the same computing device, a client application running on a Regular Execution Environment, REE, on the same computing device or another computing device, another TA running on another computing device, another TEE, and a remote service hosted on a cloud. Optionally, the method further includes the verifier authorizing the TA to access services provided by the verifier in response to the verification of the attestation evidence. Optionally, the method further includes the TSM dedicating the SD as a local certificate authority, CA, by defining one of the application keys as a certificate signing key to be used by the SD for issuing certificates to other keys generated by TAs installed in the SD, and the ASKUM associating anew policy to each of the other keys generated by the TAs in accordance with the key usage policy associated with the application key defined as the certificate signing key.

Optionally, the method further includes the TEE allowing the one or more application keys provided for the SD to attest data by TAs installed on a child SD.

Optionally, the one or more application keys are configured to be used for a limited number of times or during certain period of time which is indicated in the associated key usage policies.

Optionally, the one or more application keys are configured to be used for signing and/or encrypting and decrypting other keys generated by the TA. This enables other service providers that communicate with the TA to use the application specific keys to securely provision other keys.

According to a second aspect, there is provided an apparatus for providing an applicationlevel attestation for trusted applications in a computing device. The apparatus includes an Application Specific Key Usage Module, ASKUM, and a Trusted Execution Environment, TEE, with an application programming interface, API. The TEE with the API is configured for communicating with a Trusted Service Manager, TSM, to verify levels of security of the TEE and the ASKUM, and creating a Security Domain, SD, in the TEE in response to a request of the TSM that has verified the levels of security of the TEE and the ASKUM, receiving, from the TSM, one or more key certificates and one or more application keys dedicated to a Trusted Application, TA, installed to the SD by the TSM, and sending an attestation request from the TA to the ASKUM, wherein the attestation request specifies a cryptographic operation requiring an application key and supplies data to be subject to the cryptographic operation. The ASKUM in response to receiving the attestation request is configured for: accessing the one or more key certificates to select an application key among the one or more application keys that can be used for the specified cryptographic operation, performing the specified cryptographic operation on the supplied data using the selected application key, and providing a result of the cryptographic operation to the TA through the API.

The apparatus uses TSMs to issue application specific keys and usage policies that TAs may use for cryptographic operations, At that, the TEE provides assurances for (i) assuring the level of its security that it provides to supports the ASKUM to the TSM, where the level of security can be attested using a device specific key, (ii) provides a statement to the TSM that ensures application specific keys provisioned by the TSM on SDs are not exposed to TAs and other SDs, but are allowed to be used by the TAs via interfaces to the ASKUM, and the ASKUM operates at least on same security level as the TEE and can be considered as a part of Trusted Computing Base, and verifies a key usage policy before operating on the keys, (iii) provides an interface that allows TSMs to create SDs, provision keys and data to be stored in SD specific private storage, and install TAs, and (iv) provides an interface that allows TAs to request cryptographic operations on supplied data using application specific keys, which the interface allows the TA to specify the cryptographic operation, the priority order of the key, and supply data on which the cryptographic function is to be operated.

The apparatus allows the TA to use APIs for operations on keys without the knowledge of the keys, allows dynamic provisioning of keys in SD for application specific purposes, and allows remote authorities to define policies on the key usages that will be enforced by the trusted computing based of the device. The apparatus assures policy enforcement on the key usage by the TEE, and allows TSMs to share application specific keys among various TAs under same SD or use same key across all the SDs with same UUID installed on various devices. The apparatus also provides higher level of trust guarantees where keys maintained by key issuer and key operations are handled by TEEs.

The apparatus enables maintaining of the application specific keys and policy on keys by the TSM on the SDs in the TEEs, which the TEE provides secure storage for the SDs, keys can be updated by the TSM as needed without firmware updates, or support from TEE providers, or updating TAs, and provides quicker response to key revocation. The apparatus provides policy enforced application specific key operations for TAs where the ASKUM and the TEE ensure that the policy associated with the keys are enforced during key operations. The apparatus enables the TA as an independent module where key operations and policy enforcements are handled by the ASKUM, and the TA uses TEE API for key usage. The apparatus enables scalable policy definition by defining each key with a different policy, where the TSM creates a hierarchical SD structure where keys and policies can be shared among TAs installed in the same SD or shared among sub- SDs, different levels of SDs can have different keys with independent usage policies, and TAs can be installed in the SD with desired key usage policies. The apparatus enables a flexible and dynamic key structure that improves privacy with multiple keys on the SDs, where the SDs include TA-specific key or SD-specific keys shared among TAs under the SD. The apparatus provides a higher level of trust guarantees and relies on industrial standard.

Optionally, the API is configured for providing the TEE with one or more key usage policies received from the TSM, wherein the one or more key usage policies are associated with the one or more application keys and define conditions of a use of the one or more application keys. Optionally, the ASKUM is configured for reading the one or more key usage policies to select the application key that can be used for the specified cryptographic operation, and checking if conditions of the use of the selected application key for the TA and the specified cryptographic operation are met before performing the specified cryptographic operation, the conditions being defined by the key usage policy associated with the selected application key.

Optionally, the API is configured for providing the TSM with a special attestation claims signed with a special attestation key pre-provisioned to the computing device during its manufacture. Optionally, the special attestation claims are configured to verify that the ASKUM is at the same or higher level of security as the TEE, application keys will be stored in a private storage and will be used in accordance with key usage policies associated with them.

Optionally, the API is configured for storing the one or more key certificates, the one or more application keys and the one or more key usage policies into a private storage in the SD. Optionally, the key usage policies define that the one or more application keys can be read only by the ASKUM and for what cryptographic operations the one or more application keys can be used, and the ASKUM is implemented within the TEE or in a separate secure component.

Optionally, the API is an operation-specific interface, and the attestation request comprises an identifier of the cryptographic operation. Optionally, the one or more application keys include several application keys available for one cryptographic operation, and the attestation request related to said one cryptographic operation further includes a priority order in which the available application keys are to be used for said one cryptographic operation.

Optionally, the ASKUM is configured for providing the result of the cryptographic operation to the TA with an attestation evidence.

Optionally, each key usage policy includes a set of claims, and the ASKUM is configured for including the set of claims into the attestation evidence as attested claims.

Optionally, the set of claims define application-specific claims that the TA can supply in the attestation request for the inclusion into the attestation evidence, and the ASKUM is configured for verifying that the supplied application-specific claims are allowed by the set of claims of the key usage policy and/or correspond to allowed types of claims listed in the key usage policy associated with the application key.

Optionally, the attestation evidence includes a verifiable statement signed by an attestation key associated with the TA stored in the SD. Optionally, the SD is configured for storing one or more attestation keys associated with the TA, and the attestation request indicates a priority order in which the one or more attestation keys are to be used.

Optionally, the API is configured for sending the attestation evidence from the TA to a verifier configured to verify the attestation evidence using an attestation verification key.

Optionally, the attestation key includes an asymmetric key pair, where a private part of the key pair is used to generate the attestation evidence and a public part of the key pair is used as the attestation verification key. Optionally, the API is configured for sending a public key certificate of the attestation key and an associated key usage policy to the verifier.

Optionally, the attestation key and the attestation verification key include a symmetric key. Optionally, the one or more key usage policies are defined by using an Object Identifier, OID, or a separate policy language and stored in the one or more key certificates as an extension or in a separate policy file.

Optionally, the policy file is signed by a trusted entity.

Optionally, the verifier includes one of another TA running in the same TEE, another TA running in another TEE on the same computing device, a client application running on a Regular Execution Environment, REE, on the same computing device or another computing device, another TA running on another computing device, another TEE, and a remote service hosted on a cloud.

Optionally, the TSM is configured for dedicating the SD as a local certificate authority, CA, by defining one of the application keys as a certificate signing key to be used by the SD for issuing certificates to other keys generated by TAs installed in the SD, and the ASKUM is configured for associating a new policy to each of the other keys generated by the TAs in accordance with the key usage policy associated with the application key defined as the certificate signing key.

Optionally, the TEE is configured for allowing the one or more application keys provided for the SD to attest data by TAs installed on a child SD.

Optionally, the one or more application keys are configured to be used for a limited number of times or during certain period of time which is indicated in the associated key usage policies. Optionally, the one or more application keys are configured to be used for signing and/or encrypting and decrypting other keys generated by the TA. This enables other service providers that communicate with the TA to use the application specific keys to securely provision other keys. Therefore, in contradistinction to the prior art, according to the method and the apparatus, of providing an application-level attestation for trusted applications with a higher level of trust guarantees and privacy.

These and other aspects of the disclosure will be apparent from the implementations described below.

BRIEF DESCRIPTION OF DRAWINGS

Implementations of the disclosure will now be described, by way of example only, with reference to the accompanying drawings, in which:

FIG. 1 illustrates a block diagram of an apparatus for providing an application-level attestation for trusted applications in a computing device in accordance with an implementation of the disclosure;

FIG. 2 illustrates a system view of an application-specific key usage module, ASKUM in accordance with an implementation of the disclosure; and

FIGS. 3A-3B are flow diagrams that illustrate a method of providing an application-level attestation for trusted applications in accordance with an implementation of the disclosure.

DETAILED DESCRIPTION OF THE DRAWINGS

Implementations of the disclosure provide a method and an apparatus of providing an application-level attestation for trusted applications with a higher level of trust guarantees and privacy.

To make solutions of the disclosure more comprehensible for a person skilled in the art, the following implementations of the disclosure are described with reference to the accompanying drawings.

Terms such as "a first", "a second", "a third", and "a fourth" (if any) in the summary, claims, and foregoing accompanying drawings of the disclosure are used to distinguish between similar objects and are not necessarily used to describe a specific sequence or order. It should be understood that the terms so used are interchangeable under appropriate circumstances, so that the implementations of the disclosure described herein are, for example, capable of being implemented in sequences other than the sequences illustrated or described herein. Furthermore, the terms "include" and "have" and any variations thereof, are intended to cover a non-exclusive inclusion. For example, a process, a method, a system, a product, or a device that includes a series of steps or units, is not necessarily limited to expressly listed steps or units but may include other steps or units that are not expressly listed or that are inherent to such process, method, product, or device.

FIG. 1 illustrates a block diagram of an apparatus 102 for providing an application-level attestation for trusted applications in a computing device in accordance with an implementation of the disclosure. The apparatus 102 includes an Application Specific Key Usage Module, ASKUM 104, and a Trusted Execution Environment, TEE 106 with an application programming interface, API. The TEE 106 is configured for communicating with a Trusted Service Manager, TSM to verify levels of security of the TEE 106 and the ASKUM 104. The TEE 106 is configured for creating a Security Domain, SD, in the TEE 106 in response to a request of the TSM that has verified the levels of security of the TEE 106 and the ASKUM 104. The TEE 106 with the API is configured for receiving, from the TSM, one or more key certificates and one or more application keys dedicated to a Trusted Application, TA, installed to the SD by the TSM. The TEE 106 is further configured for sending an attestation request from the TA to the ASKUM 104. The attestation request specifies a cryptographic operation requiring an application key and supplies data to be subject to the cryptographic operation. The ASKUM 104 in response to receiving the attestation request is configured for accessing the one or more key certificates to select an application key among the one or more application keys that can be used for the specified cryptographic operation, performing the specified cryptographic operation on the supplied data using the selected application key, and providing a result of the cryptographic operation to the TA through the API.

The apparatus 102 uses TSMs to issue application specific keys and usage policies that TAs may usefor cryptographic operations. At that, the TEE 106 provides assurances for (i) assuring the level of its security that it provides to supports the ASKUM 104 to the TSM, where the level of security can be attested using a device specific key, (ii) provides a statement to the TSM that ensures application specific keys provisioned by the TSM on SDs are not exposed to TAs and other SDs, but are allowed to be used by the TAs via interfaces to the ASKUM 104, and the ASKUM 104 operates at least on same security level as the TEE 106 and can be considered as a part of Trusted Computing Base, and verifies a key usage policy before operating on the keys, (iii) provides an interface that allows TSMs to create SDs, provision keys and data to be stored in SD specific private storage, and install TAs, and (iv) provides an interface that allows TAs to request cryptographic operations on supplied data using application specific keys, which the interface allows the TA to specify the cryptographic operation, the priority order of the key, and supply data on which the cryptographic function is to be operated.

The apparatus 102 allows the TA to use APIs for operations on keys without the knowledge of the keys, allows dynamic provisioning of keys in SD for applicationspecific purposes, and allows remote authorities to define policies on the key usages that may be enforced by the trusted computing-based of the device. The apparatus 102 assures policy enforcement on the key usage by the TEE 106, and allows TSMs to share application specific keys among various TAs under same SD or use same key across all the SDs with same UUID installed on various devices. The apparatus 102 also provides a higher level of trust guarantees where keys are maintained by key issuer and key operations are handled by TEEs.

The apparatus 102 enables maintaining of the application specific keys and policy on keys by the TSM on the SDs in the TEEs, which the TEE 106 provides secure storage for the SDs, keys can be updated by the TSM as needed without firmware updates, or support from TEE providers, or updating TAs, and provides quicker response to key revocation. The apparatus 102 provides policy enforced application specific key operations for TAs where the ASKUM 104 and the TEE 106 ensures that the policy associated with the keys are enforced during key operations. The apparatus 102 enables the TA as an independent module where key operations and policy enforcements are handled by the ASKUM 104, and the TA uses TEE API for key usage. The apparatus 102 enables scalable policy definition by defining each key with a different policy, where the TSM creates hierarchical SD structure where keys and policies can be shared among TAs installed in the same SD or shared among sub-SDs, different level of SDs can have different keys with independent usage policies, and TAs can be installed in the SD with desired key usage policies. The apparatus 102 enables flexible and dynamic key structure that improves privacy with multiple keys on the SDs, where the SDs include TA-specific key or SD-specific keys shared among TAs under the SD. The apparatus 102 provides a higher level of trust guarantees and relies on industrial standard.

The TA uses policy-enforced, application specific keys for cryptographic operations. Optionally, the TA is a source TA. The TSM may create SD, installs TA, and provisions application specific keys, certificates for the keys, and key usage policies. The TA may run on the TEE 106. Optionally, one or more TAs can run on the TEE 106. The TEE 106 provides interfaces that allow the one or more TAs to use policy-enforced, applicationspecific keys for a cryptographic operation. Optionally, the TEE 106 provisions interface for TSM to create SD, install TAs, and provision application specific keys, certificates, and key usage policies. The ASKUM 104 performs a cryptographic operation on supplied data using application specific keys and enforcing the key usage policy while using the key. The ASKUM 104 may be implemented as part of the TEE 106 or a separate security component. Optionally, the application specific keys are directly stored on a component. Optionally, the apparatus 102 includes a verifier that verifies the attestation evidence of the cryptographic operation.

Optionally, the API is configured for providing the TEE 106 with one or more key usage policies received from the TSM, wherein the one or more key usage policies are associated with the one or more application keys and define conditions of a use of the one or more application keys. Optionally, the ASKUM 104 is configured for reading the one or more key usage policies to select the application key that can be used for the specified cryptographic operation, and checking if conditions of the use of the selected application key for the TA and the specified cryptographic operation are met before performing the specified cryptographic operation, the conditions being defined by the key usage policy associated with the selected application key.

Optionally, the API is configured for providing the TSM with a special attestation claims signed with a special attestation key pre-provisioned to the computing device during its manufacture. Optionally, the special attestation claims are configured to verify that the ASKUM 104 is at the same or higher level of security as the TEE 106, application keys will be stored in a private storage and will be used in accordance with key usage policies associated with them. Optionally, the API is configured for storing the one or more key certificates, the one or more application keys, and the one or more key usage policies into a private storage in the SD. Optionally, the key usage policies define that the one or more application keys can be read only by the ASKUM 104 and for what cryptographic operations the one or more application keys can be used, and the ASKUM 104 is implemented within the TEE 106 or in a separate secure component.

Optionally, the ASKUM 104 is configured for providing the result of the cryptographic operation to the TA with an attestation evidence.

Optionally, each key usage policy includes a set of claims, and the ASKUM 104 is configured for including the set of claims into the attestation evidence as attested claims.

Optionally, the set of claims define application-specific claims that the TA can supply in the attestation request for the inclusion into the attestation evidence, and the ASKUM 104 is configured for verifying that the supplied application-specific claims are allowed by the set of claims of the key usage policy and/or correspond to allowed types of claims listed in the key usage policy associated with the application key.

Optionally, the ASKUM 104 is configured to add further claims into the attestation evidence in accordance with the key usage policy.

Optionally, the API is configured for sending the attestation evidence from the TA to a verifier configured to verify the attestation evidence using an attestation verification key. Optionally, the atestation key includes an asymmetric key pair, where a private part of the key pair is used to generate the atestation evidence and a public part of the key pair is used as the atestation verification key. Optionally, the API is configured for sending a public key certificate of the atestation key and an associated key usage policy to the verifier.

Optionally, the atestation key and the atestation verification key include a symmetric key.

Optionally, the policy file is signed by a trusted entity.

Optionally, the one or more application keys are dedicated for SDs with certain Universally Unique Identifier, UUID, in a plurality of computing devices, and the atestation key is configured as a class key shared among a plurality of SDs with the same UUID.

Optionally, the TSM is configured for dedicating the SD as a local certificate authority, CA, by defining one of the application keys as a certificate signing key to be used by the SD for issuing certificates to other keys generated by TAs installed in the SD, and the ASKUM 104 is configured for associating a new policy to each of the other keys generated by the TAs in accordance with the key usage policy associated with the application key defined as the certificate signing key.

Optionally, the TEE 106 is configured for allowing the one or more application keys provided for the SD to attest data by TAs installed on a child SD.

Optionally, the one or more application keys are configured to be used for signing and/or encrypting and decrypting other keys generated by the TA.

FIG. 2 illustrates a system view of an application specific key usage module, ASKUM 204 in accordance with an implementation of the disclosure. The system view includes one or more devices 202A-N, the ASKUM 204, a Trusted Service Manager, TSM 206, and a remote service provider 208 that can comprise a group of remote service providers. The one or more devices 202A-N includes a first device 202A, and a Nth device 202N. The first device 202A includes a first regular execution environment, REE 210, an isolator controller software 212, and one or more first Trusted Execution Environment, TEE 214A-N. The Nth device 202N includes a Nth REE 216, and a Nth TEE 218. The first REE 210 and the Nth REE 216 may run applications on the one or more devices 202A-N.

The TSM 206 may communicate with the first TEE 214A to obtain a level of security in the first TEE 214A. The first TEE 214A may use a factory installed device key together with certificate associated with the device key to obtain the level of security. Optionally, the factory installed device key includes any of a device specific key or a class key. The TSM 206 is configured to create a Security Domain, SD, 220 in a first TEE 214A based on the level of security in the first TEE 214A. The TSM 206 is configured to provide application specific keys, certificates for the keys and policies to the SD 220, to create a Trusted Application, TA, 222. Optionally, the provisioned application specific keys are asymmetric or symmetric. The keys, certificates to the keys and associated key usage policies may be stored in a private storage of a storage disk 224 which cannot be accessed by any other SDs and TAs. The TSM 206 may also install the TA 222 under the SD 220. The provisioning of keys, certificates, and policies may be occurred during any of the creation of the SD 220, or afterwards prior to or after installation of the TA 222. Optionally, the TSM 206 can update the keys, certificates and policies at any time whenever required. Optionally, an association of keys with the TA 222 is defined by including universally unique identifier, UUID of the TA 222 in the certificate. The TSM 206 may provision more than one key in a single operation along with a priority order for the operations in the TA 222. Optionally, the priority order can be a key identifier which may be in ascending order. A key with a smallest numeric value may be a highest priority. The key may be defined by a particular TA or to be shared as among other TAs under the SD 220, which are included as a part of the key usage policy.

When the TA 222 requires to use application specific keys for various operations, it calls an application program interface, API provided by the first TEE 214A. The TA 222 may specify the cryptographic operation, the priority order of the key, and supply data on an applied operation. A priority order of value 1 may be indicated for a use of highest priority key. The first TEE 214A returns an output of the cryptographic operation and may also return attestation evidence together. The attestation evidence may assure that the first TEE 214A enforces an associated policy during the key usage, which may be verified by a verifier. For example, the TA 222 calls key operation interface for attestation on claims, supplied as data, using highest priority order attestation key.

The ASKUM 204 accesses the policy associated with the key stored in the private storage of the storage disk 224. The ASKUM 204 may enforce the policies associated with the key during the key usages. For example, the ASKUM 204 verifies the claims supplied by the TA 222 and measure a status of the TA 222 before attesting the claims. The TA 222 may use an output of the key operation for one or more purposes, i.e. sending the attestation evidence to the verifier, which verifies the attestation evidence using an attestation verification key. Optionally, the verifier is a TA in another TEE on a same device or a TA in another TEE of a different device, or a remote server or an application running on the REE of the one or more devices 202A-N. The verifier may authorize the source TA to access its services after verifying the attestation evidence. For example, the TA 222 requests the ASKUM 204 to attest the claims using an application specific key. The TA 222 may use the attested claims the attestation evidence to access services from the remote service provider 208, a target TA running on a different device (i.e. it may be the Nth device 202N), or a target TA running on a different TEE (i.e. it may be a first TEE 214N) in the same device. The Nth TEE 218 including a SD 226 includes a TA which is the target TA. The AKSUM 204 enables TA-to-TA communication by providing assurances to the target TA using attestation evidences.

Optionally, interfaces allow the TSM 206 to interact with the first TEE 214A and allow the TA 222 to use the application specific keys. Remote administration protocols of the TSM 206 may be extended to remotely provisions keys, certificates, and policies on the ASKUM 204. The remote administration protocols may be a GlobalPlatform TEE Management Framework including ASN.l Profile and TEE Management Framework: Open Trust Protocol (OTrP) Profile. The extension includes attestation of the first TEE 214A using signed claims with a special attestation key provisioned on the device during manufacturing stage, which provides same level of security for the ASKUM 204 as the first TEE 214A or higher, and store the application specific attestation keys in a secure storage by the first TEE 214A that is only accessible by the SD 220 and not exposing the keys to any other SDs or TAs. Optionally, the keys are allowed to be used by the TA 222 or by a group of TA, as indicated in a TA-key association, according to the policies associated with the keys. Optionally, the extension allows the TA 222 to call TEE functionalities to provide access to the ASKUM 204 through TEE interface. The interface may be a general cryptographic operation interface that allows TAs to use policy-enforce, application specific keys available to it. Optionally, the interface takes an identifier that defines the cryptographic operation as an input parameter, and allows the TA 222 to indicate the priority order of the keys to be used and data on which the operation is to be performed as parameters. The interface may return an output of the cryptographic operation and may also return attestation evidence.

Optionally, the policy includes a set of claims that may be included in the attestation evidence as attested claims. The set of claims may also define application specific claims that the TA 222 can add in addition to the attested claims. The ASKUM 204 may verify whether the claims are allowed using the set of claims in a policy file, for applicationspecific claims. Optionally, a common set of policies can be defined and registered using Object Identifier, OID, which can be included in to the certificate for the keys as an extension. Policies may be defined using separate policy languages and stored in a separate file together with the key. The policy associated with the key is a hash value of a common policy file that is accessible to the ASKUM 204. The policy file may include an associated key and may be sent to the SD 220 during keys and certificate provisioning. Optionally, the policy file is signed by a trusted entity, which is the TSM 206. Optionally, the TA 222 utilizes an interface of the ASKUM 204 to produce attestation evidence. The TA 222 may add one or more certain claims in the attestation evidence during the attestation request. Optionally, the one or more certain claims that the TA 222 allowed may be in a policy approved by the TSM 206 and the associated key. The ASKUM 204 verifies the one or more certain claims before including in the attestation evidence. Optionally, the ASKUM 204 includes one or more claims as required by the policy associated with the key. The attestation evidence is a verifiable statement signed using the application specific attestation key in the SD 220. Optionally, one or more attestation keys can be associated with the TA 222. The TA 222 may indicate the priority order of the key while requesting attestation from the ASKUM 204. The TA 222 may receive back the attestation evidence from the TEE interface. The TA 222 may send the attestation evidence to a verifier which verifies the attestation evidence using attestation verification key. Optionally, the verifier is any of another TA running on the same TEE, a TA running on a different TEE on the same device, a client application running on the REE on the same device or different device, a TA running on a different device, a different TEE where a target TA may be hosted, or a remote service hosted on a cloud. Optionally, the verifier authorizes the source TA to access various services after verification of the attestation evidence. For example, a target TEE authorizes the source TA to communicate with the target TA.

An asymmetric key pair may be used as an attestation key that includes a private part of the key to generate the attestation evidence and a public part of the key used as an attestation verification key. The TA 222 may send a public key certificate of the attestation key together with the key usage policy to the verifier. Optionally, the verifier uses the public key in the certificate as the attestation verification key to verify the signature associated with the attestation evidence and use associated policy definition to verify the claims. The verifier may obtain the attestation verification key from a certificate issuer or a key provisioner. The attestation and attestation verification key may be a symmetric key, where the verifier obtains the attestation verification keys from the key issuer directly using a trusted mechanism. Optionally, the TSM 206 issue the application keys and policies to the SDs with same UUIDs on one or more devices, where the attestation key acts as a class key shared among all SDs with the same UUID.

The application specific keys may be used for signing or encrypting/decrypting of the keys, where the ASKUM 204 enforces the policies associated with the keys before performing the cryptographic operations with the keys. The TSM 206 may dedicate an SD 220 for a role of a local certificate authority, CA. The TSM 206 allows the SD 220 to issue certificates to other keys generated by TAs installed under the SD 220. The keys generated by TAs may be used for any of signing, encryption, or decryption. During certification of the newly generated keys, the ASKUM 204 may also assign a new policy as instructed in the key usage policy of the provisioned certificate signing key.

Optionally, the key can be used by a specific TAs, where the association of the key-TA is indicated i.e. associating key identifier together with UUID of the TA 222 in the key usage policy or the certificate of the key. The key may be shared among all the TAs installed under the SD 220. Optionally, the key provisioned to parent SD may be used to attest the TAs installed on a set of children SDs. More than one keys may be provisioned for similar usages. The priority order in which the keys can be used by the TAs may be defined, and the priority order of the key may depend on the key identifier which may be in ascending order. The interface to use the key may include an input parameter that allows the TA 222 to indicate the priority of the key. Optionally, the TA 222 indicates the ASKUM 204 to choose a key in any order for privacy protection. For example, a priority order of value 0 may indicate the use of the key in random order, where the ASKUM 204 chooses to use a key in the random order. A key may be allowed to be used for n number of times or during a certain time period i.e. a time, or a day.

FIGS. 3A-3B are flow diagrams that illustrate a method of providing an application-level attestation for trusted applications in accordance with an implementation of the disclosure. At a step 302, a Trusted Service Manager, TSM, is communicated with a Trusted Execution Environment, TEE, of a computing device to verify levels of security of the TEE and an Application Specific Key Usage Module, ASKUM. At a step 304, a Security Domain, SD, is created in the TEE by means of an application programming interface, API, of the TEE in response to a request of the TSM that has verified the levels of security of the TEE and the ASKUM. At a step 306, the TEE is provided by the TSM with one or more key certificates and one or more application keys dedicated to a Trusted Application, TA, installed to the SD by the TSM. At a step 308, an attestation request from the TA is sent to the ASKUM through the API, where the attestation request specifies a cryptographic operation requiring an application key and supplies data to be subject to the cryptographic operation. At a step 310, the one or more key certificates are accessed by the ASKUM in response to receiving the attestation request to select an application key among the one or more application keys that can be used for the specified cryptographic operation. At a step 312, the specified cryptographic operation is performed by the ASKUM on the supplied data using the selected application key. At a step 314, a result of the cryptographic operation is provided from the ASKUM to the TA through the API.

This method allows the TA to use APIs for operations on keys without the knowledge of the keys, allows dynamic provisioning of keys in SD for application specific purposes, and allows remote authorities to define policies on the key usages that may be enforced by the trusted computing based of the device. This method assures policy enforcement on the key usage by the TEE, and allows TSMs to share application specific keys among various TAs under same SD or use same key across all the SDs with same UUID installed on various devices. This method also provides a higher level of trust guarantees where keys are maintained by key issuer and key operations are handled by TEEs.

This method enables maintaining of the application specific keys and policy on keys by the TSM on the SDs in the TEEs, which the TEE provides secure storage for the SDs, keys can be updated by the TSM as needed without firmware updates, or support from TEE providers, or updating TAs, and provides quicker response to key revocation. This method provides policy enforced application specific key operations for TAs where the ASKUM and the TEE ensure that the policy associated with the keys is enforced during key operations. This method enables the TA as an independent module where key operations and policy enforcements are handled by the ASKUM, and the TA uses TEE API for key usage. This method enables scalable policy definition by defining each key with different policy, where the TSM creates a hierarchical SD structure where keys and policies can be shared among TAs installed in the same SD or shared among sub-SDs, different levels of SDs can have different keys with independent usage policies, and TAs can be installed in the SD with desired key usage policies. This method enables a flexible and dynamic key structure that improves privacy with multiple keys on the SDs, where the SDs include TA-specific key or SD-specific keys shared among TAs under the SD. This method provides a higher level of trust guarantees and relies on industrial standard.

Optionally, the policy file is signed by a trusted entity.

Optionally, the verifier includes one of another TA running in the same TEE, another TA running in another TEE on the same computing device, a client application running on a Regular Execution Environment, REE, on the same computing device or another computing device, another TA running on another computing device, another TEE, and a remote service hosted on a cloud. Optionally, the method further includes the verifier authorizing the TA to access services provided by the verifier in response to the verification of the attestation evidence.

Optionally, the method further includes the TSM dedicating the SD as a local certificate authority, CA, by defining one of the application keys as a certificate signing key to be used by the SD for issuing certificates to other keys generated by TAs installed in the SD, and the ASKUM associating anew policy to each of the other keys generated by the TAs in accordance with the key usage policy associated with the application key defined as the certificate signing key.

It should be understood that the arrangement of components illustrated in the figures described are exemplary and that other arrangement may be possible. It should also be understood that the various system components (and means) defined by the claims, described below, and illustrated in the various block diagrams represent components in some systems configured according to the subject matter disclosed herein. For example, one or more of these system components (and means) may be realized, in whole or in part, by at least some of the components illustrated in the arrangements illustrated in the described figures.

In addition, while at least one of these components are implemented at least partially as an electronic hardware component, and therefore constitutes a machine, the other components may be implemented in software that when included in an execution environment constitutes a machine, hardware, or a combination of software and hardware.

Although the disclosure and its advantages have been described in detail, it should be understood that various changes, substitutions, and alterations can be made herein without departing from the spirit and scope of the disclosure as defined by the appended claims.

Claims

1. A method of providing an application-level attestation for trusted applications, the method comprising: communicating of a Trusted Service Manager, TSM, (206) with a Trusted Execution Environment, TEE, (106) of a computing device to verify levels of security of the TEE (106,214A) and an Application Specific Key Usage Module, ASKUM (104,204), creating a Security Domain, SD, (220) in the TEE (106,214A) by means of an application programming interface, API, of the TEE (106,214 A) in response to a request of the TSM (206) that has verified the levels of security of the TEE (106,214 A) and the ASKUM (104,204), providing the TEE (106,214 A) by the TSM (206) with one or more key certificates and one or more application keys dedicated to a Trusted Application, TA, (222) installed to the SD (220) by the TSM (206), sending an attestation request from the TA (222) to the ASKUM (104,204) through the API, wherein the attestation request specifies a cryptographic operation requiring an application key and supplies data to be subject to the cryptographic operation, accessing by the ASKUM (104,204) the one or more key certificates in response to receiving the attestation request to select an application key among the one or more application keys that can be used for the specified cryptographic operation, and performing by the ASKUM (104,204) the specified cryptographic operation on the supplied data using the selected application key, and providing a result of the cryptographic operation from the ASKUM (104,204) to the TA (222) through the API.

2. The method of claim 1, wherein the providing of the TEE (106,214 A) by the TSM (206) with one or more key certificates and one or more application keys comprises providing one or more key usage policies associated with the one or more application keys, wherein the key usage policies define conditions of a use of the one or more application keys, the accessing by the ASKUM (104,204) of the one or more key certificates in response to receiving the attestation request comprises reading the one or more key usage policies to select the application key that can be used for the specified cryptographic operation, and the method further comprises, before performing the specified cryptographic operation, checking by the ASKUM (104,204) if conditions of the use of the selected application key for the TA (222) and the specified cryptographic operation are met, the conditions being defined by the key usage policy associated with the selected application key.

3. The method of claim 2, wherein the communicating of the TSM (206) with the TEE (106,214A) comprises providing from the TEE (106,214A) to the TSM (206) a special attestation claims signed with a special attestation key pre-provisioned to the computing device during its manufacture, wherein the special attestation claims are configured to verify that the ASKUM (104,204) is at the same or higher level of security as the TEE (106,214A), application keys will be stored in a private storage and will be used in accordance with key usage policies associated with them.

4. The method of claim 2, wherein the providing of the TEE (106,214A) by the TSM (206) with one or more key certificates, one or more application keys and one or more key usage policies comprises storing the one or more key certificates, the one or more application keys and the one or more key usage policies into a private storage in the SD (220), the key usage policies define that the one or more application keys can be read only by the ASKUM (104,204) and for what cryptographic operations the one or more application keys can be used, and the ASKUM (104,204) is implemented within the TEE (106,214A) or in a separate secure component.

5. The method of any of claims 1 to 4, wherein the API is an operation-specific interface, and the attestation request comprises an identifier of the cryptographic operation.

6. The method of any of claims 1 to 5, wherein the one or more application keys comprise several application keys available for one cryptographic operation, and the attestation request related to said one cryptographic operation further comprises a priority order in which the available application keys are to be used for said one cryptographic operation.

7. The method of any of claims 1 to 6, wherein the providing of result of the cryptographic operation to the TA (222) comprises providing an attestation evidence.

8. The method of claim 7, wherein each key usage policy comprises a set of claims, and the ASKUM (104,204) is configured to include the set of claims into the attestation evidence as attested claims.

9. The method of claim 8, wherein the set of claims define application-specific claims that the TA (222) can supply in the attestation request for the inclusion into the attestation evidence, and the ASKUM (104,204) is configured to verify that the supplied application-specific claims are allowed by the set of claims of the key usage policy and/or correspond to allowed types of claims listed in the key usage policy associated with the application key.

10. The method of claim 8 or 9, wherein the ASKUM (104,204) is configured to add further claims into the attestation evidence in accordance with the key usage policy.

11. The method of any of claims 7 to 10, wherein the attestation evidence comprises a verifiable statement signed by an attestation key associated with the TA (222) stored in the SD (220), the SD (220) stores one or more attestation keys associated with the TA (222), and the attestation request indicates a priority order in which the one or more attestation keys are to be used.

12. The method of any of claims 7 to 11, further comprising: sending the attestation evidence by the TA (222) to a verifier configured to verify the attestation evidence using an attestation verification key.

13. The method of claim 12, wherein the attestation key comprises an asymmetric key pair, wherein a private part of the key pair is used to generate the attestation evidence and a public part of the key pair is used as the attestation verification key, and the method further comprises: the TA (222) sending a public key certificate of the attestation key and an associated key usage policy to the verifier, using by the verifier the public key from the public key certificate as the attestation verification key to verify the signature of the attestation evidence, and using by the verifier the associated key usage policy to verify claims comprised in the attestation evidence.

14. The method of claim 12, further comprising the verifier obtaining the attestation verification key from a certificate issuer or a key provisioner.

15. The method of claim 12, wherein the attestation key and the attestation verification key comprise a symmetric key, and the method further comprises the verifier obtaining the attestation verification key from a key issuer directly using a trusted mechanism.

16. The method of any of claims 2 to 15, wherein the one or more key usage policies are defined by using an Object Identifier, OID, or a separate policy language and stored in the one or more key certificates as an extension or in a separate policy file.

17. The method of any of claims 2 to 16, wherein each key usage policy associated with an application key comprises a hash value stored in a common policy file.

18. The method of any of claims 2 to 16, wherein each key usage policy is stored in a policy file that comprises an associated application key or an associated application key identifier.

19. The method of any of claims 16 to 18, wherein the policy file is signed by a trusted entity.

20. The method of any of claims 1 to 19, wherein the one or more application keys are dedicated for SDs with certain Universally Unique Identifier, UUID, in a plurality of computing devices, and the attestation key is configured as a class key shared among a plurality of SDs with the same UUID.

21. The method of any of claims 12 to 20, wherein the verifier comprises one of another TA running in the same TEE, another TA running in another TEE on the same computing device, a client application running on a Regular Execution Environment, REE, on the same computing device or another computing device, another TA running on another computing device, another TEE, and a remote service hosted on a cloud, and the method further comprises the verifier authorizing the TA (222) to access services provided by the verifier in response to the verification of the attestation evidence.

22. The method of any of claims 1 to 21, further comprising: the TSM (206) dedicating the SD (220) as a local certificate authority, CA, by defining one of the application keys as a certificate signing key to be used by the SD (220) for issuing certificates to other keys generated by TAs installed in the SD (220), and the ASKUM (104,204) associating a new policy to each of the other keys generated by the TAs in accordance with the key usage policy associated with the application key defined as the certificate signing key.

23. The method of any of claims 1 to 22, further comprising the TEE (106,214A) allowing the one or more application keys provided for the SD (220) to attest data by TAs installed on a child SD.

24. The method of any of claims 2 to 23, wherein the one or more application keys are configured to be used for a limited number of times or during certain period of time which is indicated in the associated key usage policies.

25. The method of any of claims 1 to 24, wherein the one or more application keys are configured to be used for signing and/or encrypting and decrypting other keys generated by the TA.

26. An apparatus for providing an application-level attestation for trusted applications in a computing device, the apparatus comprising: an Application Specific Key Usage Module, ASKUM, (104,204) and a Trusted Execution Environment, TEE, (106,214 A) with an application programming interface, API, configured for: communicating with a Trusted Service Manager, TSM (206) to verify levels of security of the TEE (106,214A) and the ASKUM (104,204), creating a Security Domain, SD, (220) in the TEE (106,214A) in response to a request of the TSM (206) that has verified the levels of security of the TEE (106,214A) and the ASKUM (104,204), receiving, from the TSM (206), one or more key certificates and one or more application keys dedicated to a Trusted Application, TA, (222) installed to the SD (220) by the TSM (206), and sending an attestation request from the TA (222) to the ASKUM (104,204), wherein the attestation request specifies a cryptographic operation requiring an application key and supplies data to be subject to the cryptographic operation, wherein the ASKUM (104,204) in response to receiving the attestation request is configured for: accessing the one or more key certificates to select an application key among the one or more application keys that can be used for the specified cryptographic operation, performing the specified cryptographic operation on the supplied data using the selected application key, and providing a result of the cryptographic operation to the TA (222) through the API.

27. The apparatus of claim 26, wherein the API is configured for providing the TEE (106,214A) with one or more key usage policies received from the TSM (206), wherein the one or more key usage policies are associated with the one or more application keys and define conditions of a use of the one or more application keys, the ASKUM (104,204) is configured for: reading the one or more key usage policies to select the application key that can be used for the specified cryptographic operation, and checking if conditions of the use of the selected application key for the TA (222) and the specified cryptographic operation are met before performing the specified cryptographic operation, the conditions being defined by the key usage policy associated with the selected application key.

28. The apparatus of claim 27, wherein the API is configured for providing the TSM (206) with a special attestation claims signed with a special attestation key preprovisioned to the computing device during its manufacture, wherein the special attestation claims are configured to verify that the ASKUM (104,204) is at the same or higher level of security as the TEE (106,214A), application keys will be stored in a private storage and will be used in accordance with key usage policies associated with them.

29. The apparatus of claim 27, wherein the API is configured for storing the one or more key certificates, the one or more application keys and the one or more key usage policies into a private storage in the SD (220), the key usage policies define that the one or more application keys can be read only by the ASKUM (104,204) and for what cryptographic operations the one or more application keys can be used, and the ASKUM (104,204) is implemented within the TEE (106,214A) or in a separate secure component.

30. The apparatus of any of claims 26 to 29, wherein the API is an operation-specific interface, and the attestation request comprises an identifier of the cryptographic operation.

31. The apparatus of any of claims 26 to 30, wherein the one or more application keys comprise several application keys available for one cryptographic operation, and the attestation request related to said one cryptographic operation further comprises a priority order in which the available application keys are to be used for said one cryptographic operation.

32. The apparatus of any of claims 26 to 31, wherein the ASKUM (104,204) is configured for providing the result of the cryptographic operation to the TA (222) with an attestation evidence.

33. The apparatus of claim 32, wherein each key usage policy comprises a set of claims, and the ASKUM (104,204) is configured for including the set of claims into the attestation evidence as attested claims.

34. The apparatus of claim 33, wherein the set of claims define application-specific claims that the TA (222) can supply in the attestation request for the inclusion into the attestation evidence, and the ASKUM (104,204) is configured for verifying that the supplied application-specific claims are allowed by the set of claims of the key usage policy and/or correspond to allowed types of claims listed in the key usage policy associated with the application key.

35. The apparatus of claim 33 or 34, wherein the ASKUM (104,204) is configured for adding further claims into the attestation evidence in accordance with the key usage policy.

36. The apparatus of any of claims 32 to 35, wherein the attestation evidence comprises a verifiable statement signed by an attestation key associated with the TA (222) stored in the SD (220), the SD (220) is configured for storing one or more attestation keys associated with the TA (222), and the attestation request indicates a priority order in which the one or more attestation keys are to be used.

37. The apparatus of any of claims 32 to 36, wherein the API is configured for sending the attestation evidence from the TA (222) to a verifier configured to verify the attestation evidence using an attestation verification key.

38. The apparatus of claim 37, wherein the attestation key comprises an asymmetric key pair, wherein a private part of the key pair is used to generate the attestation evidence and a public part of the key pair is used as the attestation verification key, the API is configured for sending a public key certificate of the attestation key and an associated key usage policy from the TA (222) to the verifier.

39. The apparatus of claim 37, wherein the attestation key and the attestation verification key comprise a symmetric key.

40. The apparatus of any of claims 27 to 39, wherein the one or more key usage policies are defined by using an Object Identifier, OID, or a separate policy language and stored in the one or more key certificates as an extension or in a separate policy file.

41. The apparatus of any of claims 27 to 40, wherein each key usage policy associated with an application key comprises a hash value stored in a common policy file.

42. The apparatus of any of claims 27 to 40, wherein each key usage policy is stored in a policy file that comprises an associated application key or an associated application key identifier.

43. The apparatus of any of claims 40 to 42, wherein the policy file is signed by a trusted entity.

44. The apparatus of any of claims 26 to 43, wherein the one or more application keys are dedicated for SDs with certain Universally Unique Identifier, UUID, in a plurality of computing devices, and the attestation key is configured as a class key shared among a plurality of SDs with the same UUID.

45. The apparatus of any of claims 37 to 44, wherein the verifier comprises one of another TA running in the same TEE, another TA running in another TEE on the same computing device, a client application running on a Regular Execution Environment, REE, on the same computing device or another computing device, another TA running on another computing device, another TEE, and a remote service hosted on a cloud.

46. The apparatus of any of claims 26 to 45, wherein the TSM (206) is configured for dedicating the SD (220) as a local certificate authority, CA, by defining one of the application keys as a certificate signing key to be used by the SD (220) for issuing certificates to other keys generated by TAs installed in the SD (220), and the ASKUM (104,204) is configured for associating a new policy to each of the other keys generated by the TAs in accordance with the key usage policy associated with the application key defined as the certificate signing key.

47. The apparatus of any of claims 26 to 46, wherein the TEE (106,214A) is configured for allowing the one or more application keys provided for the SD (220) to attest data by TAs installed on a child SD.

48. The apparatus of any of claims 27 to 47, wherein the one or more application keys are configured to be used for a limited number of times or during certain period of time which is indicated in the associated key usage policies.

49. The apparatus of any of claims 26 to 48, wherein the one or more application keys are configured to be used for signing and/or encrypting and decrypting other keys generated by the TA.