WO2025086129A1

WO2025086129A1 - Methods and mechanisms for unified remote attestation for confidential applications in the cloud

Info

Publication number: WO2025086129A1
Application number: PCT/CN2023/126383
Authority: WO
Inventors: Quoc Do LE; Jun Li; Wei Wang
Original assignee: Huawei Cloud Computing Technologies Co Ltd
Current assignee: Huawei Cloud Computing Technologies Co Ltd
Priority date: 2023-10-25
Filing date: 2023-10-25
Publication date: 2025-05-01
Anticipated expiration: 2026-04-25

Abstract

A data processing apparatus for implementing remote attestation of an application executed in a trusted execution environment, the data processing apparatus comprising one or more processors configured to: generate attestation data for the application deployed in the trusted execution environment, the attestation data being electronically signed by the trusted execution environment; receive at one or more stored attestation library the generated attestation data; modify, during runtime of the application, the generated attestation data to include at least one indication of integrity of at least a portion of the application, the at least one indication of integrity being provided by a root of trust; and convert the modified attestation data into a standardised token for verification, the standardised token comprising information included in the modified attestation data.

Description

METHODS AND MECHANISMS FOR UNIFIED REMOTE ATTESTATION FOR CONFIDENTIAL APPLICATIONS IN THE CLOUD

FIELD OF THE INVENTION

This invention relates to a data processing apparatus and method for providing unified remote attestation, including runtime support, of an application executed in a trusted execution environment.

BACKGROUND

Confidential computing has become increasingly important as it a standard way for cloud users to store and process sensitive data in the cloud. In comparison to the traditional security techniques such as firewalls, encryption, confidential computing can protect sensitive data when it is being processed in the cloud by using Trusted Execution Environments (TEEs) , e.g., Intel SGX, Intel TDX, or AMD SEV SNP. Confidential computing supports remote attestation which allows user to establish trust to their application running in a secure enclave, or secure virtual machine deployed in a remote host in the cloud. However, to integrate current/existing cloud services with confidential computing, the transformation cost is high, and the API and SDK need to be upgraded, which is not ecologically friendly. Using the attestation attributes, offered by TEEs, directly in the security policy will make the authorization policy difficult to manage. In addition, supporting unified authorization policy management of multiple heterogeneous trusted hardware devices is difficult. Moreover, the limitation of current remote attestation offered by TEEs is that it performs the attestation only at the start/booting stage before running user application and cannot support remote attestation during runtime.

In industry, cloud providers such as Google cloud, AWS, Microsoft Azure, Alibaba, and Huawei Cloud have their own confidential computing platform to offer confidential computing services to their customers. As part of these confidential computing services, a remote attestation mechanism is provided to allow customers/users to remotely verify the integrity and security of the firmware, software and hardware configuration of a target customer service that deployed on the cloud environment or an untrusted environment. The remote attestation plays a crucial role in establishing the trust from users to cloud providers.

Unfortunately, currently none of these attestation services provide the unified remote attestation in their confidential computing service that can support multiple Trusted Execution Environments (TEEs) and support runtime attestation. The challenges involved in supporting multiple TEEs are that:

(i) integrating multiple TEEs into a unified remote attestation platform can be complex due to each TEE has its own unique architecture, features with different assumptions;

(ii) TEEs employs different attestation protocols and mechanisms for verifying the integrity. In addition, each TEE has its own format regarding attestation report. This requires the unified remote attestation platform to understand and support multiple protocol, measurement formats, thus making it more complex to implement and maintain;

(iii) since each TEE has its own set of security features, threat models, and vulnerabilities, ensuring the security and the trustworthiness of the remote attestation process requires a deep understanding of each TEE technology in order to address their specific security concerns. Some proposed solutions to this involve building remote attestation platforms but only for a specific and individual TEE technologies, but not for multiple TEEs.

Currently, TEEs perform the attestation only at the start/booting stage before running user application and cannot support remote attestation during runtime. This is a problem since, during runtime, software and configuration of customer services can change dynamically. This includes loading and unloading software components (e.g., libraries) , applying updates or patches, etc. Therefore, monitoring and attesting the integrity of these changes during runtime is a challenge for any remote attestation service. In addition, runtime attestation often involves frequent communication between attestation service with the target platform/application. Thus, ensuring secure and efficient communication at scale that can be challenging, especially in distributed systems or cloud environments with a large number of attestation requests.

In addition, TEE technologies currently only provide pre-attestation, i.e., measuring all the memory initialized in the confidential VM/enclave during boot/create time, but lack mechanisms to allow the software stack to extend the booting measurements. Therefore, they do not perform runtime attestation and integrity monitoring of an enclave or encrypted virtual machine.

Overcoming these challenges currently requires robust cryptographic mechanisms, efficient monitoring techniques, secure communication protocol, and careful design of attestation policies. It involves a combination of hardware support, software frameworks, and trusted computing technologies to establish a runtime remote attestation system that can effectively verify and maintain the integrity of a computing platform during its execution.

SUMMARY

A data processing apparatus for implementing remote attestation of an application executed in a trusted execution environment, the data processing apparatus comprising one or more processors configured to: generate attestation data for the application deployed in the trusted execution environment, the attestation data being electronically signed by the trusted execution environment; receive at one or more stored attestation library the generated attestation data; modify, during runtime of the application, the generated attestation data to include at least one indication of integrity of at least a portion of the application, the at least one indication of integrity being provided by a root of trust; and convert the modified attestation data into a standardised token for verification, the standardised token comprising information included in the modified attestation data. This allows for unified remote attestation of an application to executed in a trusted execution environment and include runtime attestation.

A data processing apparatus as described above, wherein the one or more processors are further configured to verify the standardised token using a verification service; and wherein the verification service is a user verification service. This provides the advantage that the standardised token must be verified by the user in order to utilise the application data thus introducing user security.

A data processing apparatus as described above, wherein the one or more processors are further configured to verify the standardised token using a verification service; wherein the verification service is a third-party verification service that is configured to convert the standardised token into a security service token; and the one or more processors are further configured to receive the security service token from the third-party verification service. This provides the advantage that the standardised token can be modified to take a form that will is capable of being analysed by known security systems and thus can be independently verified by current third-party software.

A data processing apparatus as described above, wherein the one or more processors are further configured to deploy the application comprising application data, application code, and request attestation of the application data and/or code from a module of the trusted execution environment in response to receiving an attestation request from a user. This provides the advantage that the apparatus is capable of running the apparatus once the attestation data and/or code associated with the application has been verified.

A data processing apparatus as described above, wherein the one or more processors are further configured to contact a cloud-based service requesting access to the cloud-based service; and receive a response from the cloud base service based on verification of the standardised token. This provides the advantage that the application implemented in this disclosure can be used to access verified cloud-based services thus ensuring the security of those services due to the attestation.

A data processing apparatus as described above, wherein the standardised token is a security token. This allows the standardised token to be converted to a form that is recognisable by security verification applications that are currently used.

A data processing apparatus as described above, wherein the indication of integrity is provided by integrity measurement architecture. This provides a measure of the integrity of at least a portion data (files, libraries, etc) at the time of measurement and thus allow the data of the system to be compared at different runtimes to determine whether the data has been modified or tampered with, thus raising security concerns.

A data processing apparatus as described above, wherein the root of trust is provided by a hardware-based security module. This provides an added aspect of security to the remote attestation since it provides a hardware module that is separate from the confidential virtual machine (s) , comprising the enclave deploying the application. This provides additional security since the additional hardware must be compromised to threaten the security of the system.

A data processing apparatus as described above, wherein the root of trust is an external root of trust comprising a combination of modules of the trusted execution environment and trusted platform modules. This provides the advantage that the root of trust is external to the TEE and can independently provide an additional layer of security.

A data processing apparatus as described above, wherein the one or more attestation library is located on a secure enclave or confidential virtual machine of the apparatus. This protects the user’s application from attacks from non-local threats.

A method of processing data to perform remote attestation of an application executed in a trusted execution environment, the method comprising: generating attestation data for the application deployed in the trusted execution environment, the attestation data being electronically signed by the trusted execution environment; receiving at one or more stored attestation library the generated attestation data; modifying, during runtime of the application, the generated attestation data to include at least one indication of integrity of at least a portion of the application, the at least one indication of integrity being provided by a root of trust; and converting the modified attestation data into a standardised token for verification, the standardised token comprising information included in the modified attestation data. This allows for unified remote attestation of an application to executed in a trusted execution environment and include runtime attestation.

A method as described above, further comprising verifying the standardised token using a verification service; and wherein the verification service is a user verification service. This provides the advantage that the standardised token must be verified by the user in order to utilise the application data thus introducing user security.

A method as described above, further comprising verifying the standardised token using a verification service; wherein the verification service is a third-party verification service that converts the standardised token into a security service token; and the method further comprises receiving the security service token from the third-party verification service. This provides the advantage that the standardised token can be modified to take a form that will is capable of being analysed by known security systems and thus can be independently verified by current third-party software.

A method as described above, wherein the method further comprises deploying the application, the application comprising application data and application code, and requesting attestation of the application data and/or code from a module of the trusted execution environment in response to receiving an attestation request from a user. This provides the advantage that the apparatus is capable of running the apparatus once the attestation data and/or associated with the application has been verified.

A method as described above, wherein the method further comprises contacting a cloud-based service requesting access to the cloud-based service; and receiving a response from the cloud base service based on verification of the standardised token. This provides the advantage that the application implemented in this disclosure can be used to access verified cloud-based services thus ensuring the security of those services due to the attestation.

A method as described above, wherein the standardised token is a security token. This allows the standardised token to be converted to a form that is recognisable by security verification applications that are currently used.

A method as described above, wherein the method further comprises providing the indication of integrity using integrity measurement architecture. This provides a measure of the integrity of at least a portion data (files, libraries etc) at the time of measurement and thus allow the data of the system to be compared at different runtimes to determine whether the data has been modified or tampered with, thus raising security concerns.

A method as described above, wherein the root of trust is provided by a hardware-based security module. This provides an added aspect of security to the remote attestation since it provides a hardware module that is separate from the confidential virtual machine (s) , comprising the enclave deploying the application. This provides additional security since the additional hardware must be compromised to threaten the security of the system.

A method as described above, wherein the root of trust is an external root of trust comprising a combination of modules of the trusted execution environment and trusted platform modules. This provides the advantage that the root of trust is external to the TEE and can independently provide an additional layer of security.

A method as described above, wherein the one or more attestation library is located on a secure enclave or confidential virtual machine of the apparatus. This protects the user’s application from attacks from non-local threats.

BRIEF DESCRIPTION OF THE FIGURES

The embodiments of the present disclosure will now be described by way of example with reference to the accompanying drawings. In the drawings:

Fig. 1 illustrates a general example of a remote attestation workflow in a TEE;

Fig: 2 illustrates an example data processing apparatus and method of this disclosure;

Fig. 3 illustrates a flowchart showing an example of the process of unified remote attestation for confidential applications in a cloud implemented by the data apparatus and method of this disclosure.

DETAILED DESCRIPTION OF THE INVENTION

This disclosure provides methods and techniques to overcome the above problems by designing a general abstraction/architecture for remote attestation in TEEs, also using Trusted Platform Module (TPM) together with Integrity Measurement Architecture (IMA) as the second root of trust to perform remote attestation during runtime.

It is therefore an object of this disclosure to solve the above problem of remote attestation services by providing a data processing apparatus for implementing remote attestation of an application executed in a trusted execution environment.

The embodiments of the present disclosure will now be described in detail in relation to the Figures.

First this disclosure provides some background regarding the technical building blocks to be used as part of this disclosure.

Firstly, Trusted Execution Environments (TEEs) , such as ARM TrustZone, IBM SecureBlue++, AMD SEV, Intel SGX and Intel TDX, support the design of complex, yet secure, applications. A TEE is a tamper-resistant processing environment that guarantees the authenticity, the integrity and the confidentiality of its executing code, data and runtime states (e.g., CPU registers, memory and sensitive I/O) . The content of a TEE remains resistant against software attacks even from privileged code, as well as any physical attacks performed on the main memory of the system. Out of these TEEs, Intel SGX has been widely adopted in practice. It enables a general-purpose ring 3-enabled TEE and yields a significantly smaller Trusted Computing Base (TCB) in comparison with other solutions where typically a whole Operating System (OS) is part of the TCB. Furthermore, running legacy applications without source code changes is supported by several SGX platforms, e.g., SCONE or Graphene-SGX or Occlum. Beside the shield execution, TEEs offer attestation for proving their trustworthiness to third-parties. However, TEEs are vulnerable to “reuse” attacks, one can use a previous measurement to impersonate a TEE with a different expected behaviour. The vulnerability is based on the fact that the application from the user dynamically load libraries, and configurations during runtime, which can change its behaviour.

A further technique utilised in this disclosure is remote attestation. Trusted Platform Modules (TPM) (remote) attestation is a mechanism that provides the ability for a verifier to assert a certain state of an application is running in a TEE (see Fig. 1) . On the example device as shown in Fig. 1, there is a prover entity (Quoting Enclave in Intel SGX) able to produce the evidence for the state of the application; and securely send it to the verifier. An attestation process may comprise two major parts: (i) Characterization of the application’s current state (the measurement process to create the evidence, called quote in Intel SGX/TDX) ; and the (ii) Secure transfer of the evidence to the verifier. The measurement may be used to prove the application is running in a correct state (e.g., correct code) inside enclaves of TEEs. It can be a cryptographic hash over the binary of an application or booting state of a secure virtual machine (VM) or could also contain other target information for the attestation. The measurement is then signed using a hardware-protected certified key unique to the device to create the evidence or quote that can be verified by the verifier. The certified key can be used to ensure the authenticity of the remote attestation protocol. To ensure the freshness of the evidence, the verifier includes a nonce (a randomly assigned number) into the challenge in its request to the remote enclave.

Fig. 1 summarizes a general remote attestation workflow in TEEs. Before launching an application in an enclave 101 deployed on the remote device/host, the measurement process creates the attestation evidence. When the verifier 102 wants to verify if the remote application has an expected state, it sends a request with a nonce (randomly assigned number) to the remote enclave (step 1 in Fig. 1) . The enclave may then combine the nonce with the measurement, signs it to create a report using attestation keys (stored in CPU hardware) , and sends it to the prover 103 (step 2 in Fig. 1) . The prover 103 verifies the report, signs it to create the evidence (i.e., quote) , and sends it back to the verifier (step 3 in Fig. 1) . The verifier 102 checks the signature and certificate with the help of the trusted third-party 104, e.g., the attestation service 206 of the TEE provider, and checks that the measurement indicates the start of the expected enclave (step 4 in Fig. 1) .

Another aspect of this disclosure is the use of Integrity Measurement Architecture (IMA) . IMA is designed to measure and verify the integrity of files and executables on a Linux-based system. It provides a means to determine if any unauthorized modification or tampering have occurred to critical system files, binaries, or configuration. IMA works by using cryptographic hash functions to calculate a digital fingerprint, known as an integrity measurement (IM) for each file or executable. These integrity measurements are stored in the extended attributes of the file system, associating each file with its corresponding IM.

During system operation, the IMA may calculate an integrity measurement (IM) of each file before it is accessed or executed. The calculated IM is compared with the stored IM, and if they match, the file is considered intact and trusted. If IMs do not match or if the file lacks an IM altogether, it indicates that the file has been modified or tampered with, raising an integrity violation alert. IMA can be configured to measure specific files, directories, or even entire file systems. It can also support custom policies to enforce stricter or more flexible integrity checks based on specific requirements. The measurements can be extended to cover additional attributes like the file metadata, such as permissions or owner information.

In this disclosure, IMA is used together with a Trusted Platform Module (TPM) 204 to perform the remote attestation during runtime. Before running the target application on a remote environment, the integrity of critical files (libraries) , executables and configuration may be measured using IM and then such files etc. may be securely stored. These IMs may then be bound with a TPM 204, which is a hardware-based security module that provides secure storage and cryptographic operations. During runtime, the integrity of files and executables of the application may be continually measured using IM, the IMs of these application components may be calculated as they are accessed or executed.

To securely run an application in a cloud, a user can make use of confidential computing services discussed above to run the application inside secure enclaves (Intel SGX enclaves, or secure virtual machines using Intel TDX/AMD SEV SNP or Arm CCA) . However, running such a confidential computing service is not sufficient to provide the requisite security since the user is required to trust the cloud provider which runs the applications inside secure enclaves or confidential virtual machines. Thus, to provide additional security for the user a remote attestation mechanism is required to allow the user to attest the execution of the application deployed in a remote environment, e.g., they can attest the confidentiality and integrity of the application (including code and data) and make sure that no one can interfere the application execution including attackers with privileged access.

In this disclosure, a data processing apparatus and method for implementing remote attestation of an application executed in a trusted execution environment is described that includes mechanisms that measure all aspects that determine the behaviour, and freshness, i.e., the measurement reflects the current behaviour of the application. During runtime, the application loads its dependency libraries. The measurement reflects the dynamic behaviour, and ensures the freshness (to protect against “reuse” attacks) , of the legacy application running inside enclaves. In addition, TEEs offer different format regarding attestation report, however, the apparatus and method of this disclosure provides a way to handle this issue by converting all different formats into a unified attestation format.

Fig. 2 illustrates an example data processing apparatus and method of this disclosure. In Fig. 2 the architecture for unified remote attestation with runtime support is depicted. The data processing apparatus may comprise one or more processors. The one or more processors may be configured to deploy a user application inside a TEE enclave. The TEE enclave 201 may be an SGX enclave, Qingtian/Nitro enclave or confidential virtual machine using Intel TDX or AMD SEV SNP) .

A verifier 202 may be used in order to authenticate the safety of the application/services. A verifier 202 in this disclosure may be a user service or service provided by a third party, which may send an attestation request to the user application deployed on the one or more processors of the data processing apparatus and running inside the enclave. This can be seen in step 1 of Fig. 2. As such, the one or more processors may be configured to receive an authentication request from a verifier. In other words, the one or more processors are further configured to deploy the application comprising application data and code. The one or more processors are further configured to request attestation of the application data and/or code from a module of the trusted execution environment in response to receiving an attestation request from a user.

The one or more processors may then be configured to forward the attestation request to one or more attestation library 203 which may also be running inside the enclave as shown in step 2 of Fig. 2. The one or more processors may then be configured to generate attestation data for the application deployed in the trusted execution environment, the attestation data being electronically signed by the trusted execution environment. This may include step 2 of forwarding the attestation request to the attestation libraries in addition to the following or may be achieved by the one or more processors causing the attestation libraries to send a request to TEE modules to obtain attestation document, i.e., attestation fingerprint (quote) as shown in step 3 of the Fig. 2, in addition to step 2. This process performed by the one or more processors of the apparatus of this disclosure may comprise local attestation to get the attestation report and sign the report using the TEE hardware keys to obtain the attestation document. In other words, the one or more processors of the apparatus of this disclosure may be configured to receive at one or more stored attestation library attestation libraries 203 the generated attestation data as shown in the return arrow of step 3 of Fig. 2.

In order to support attestation during runtime, the one or more processors of the data processing apparatus of this disclosure may perform an integrity measurement (IM) for libraries, other components and configuration of the application using IMA. These IMs are bonded with a Trusted Platform Module (TPM) 204 to ensure the tamper-proof property of the data. The TPM 204 can be a physical TPM or a virtual TPM in each confidential virtual machine.

In doing this the one or more processors may be configured to modify, during runtime of the application, the generated attestation data to include at least one indication of integrity of at least a portion of the application, the at least one indication of integrity being provided by a root of trust. This may be achieved by binding the IMA measurement during runtime to generated attestation data, which may be in the form of a remote attestation document. Binding of the IMA measurement may be actioned on a portion of the attestation data or the data (for example a file) or the data as a whole (for example the complete library) . The root of trust in this case may be a second root of trust (second to the attestation already provided by the attestation key of the TEE) . The root of trust may be embodied in a hardware-based security module and/or may be an external root of trust comprising a combination of modules of the trusted execution environment and trusted platform modules.

The one or more processors may then be configured to send the modified attestation data (including the IMA measurement) to an attestation service 206 as shown in step 4 of Fig. 2. The attestation service 206 may be performed by the one or more processors of the apparatus or by an external processor/apparatus. This remote attestation provides proof for the integrity of user application and the authenticity of TEE hardware, signed by TEE specific attestation keys. Since the TEEs are vulnerable to side-channel attacks which can retrieve attestation keys the one or more processors being configured to bind the attestation data (quote/proof) to a second hardware root of trust e.g., TPMs, allow side-channel attacks to be mitigated.

To support a unified remote attestation for multiple TEEs, the one or more processors of the apparatus of this disclosure may be configured to, by the attestation service 206, verify and convert the attestation data from its current format (SGX attestation report, AMD SEV SNP attestation report, or Nitro/Qingtian attestation report) into a standardised token. This standardisation token may be a standard attestation token with a common format, e.g., JWT token (OpenID Connect) , as shown in step 5 of Fig. 2. The standardised token for verification may comprise the modified attestation data. The standardised token may then be returned to the attestation libraries. In other words, the one or more processors are configured to convert the modified attestation data into a standardised token for verification, the standardised token comprising information included in the modified attestation data.

The attestation service 206 and the attestation libraries may be open-source, thus, can be attested by the user (verifier) or a third relying party. In this disclosure, the verifier may attest the attestation service 206 component at beginning of the process performed by the one or more processors using the tools provided by TEE providers such as Intel Attestation Service (IAS) as a precursor to further attestation, this would be a step prior to step 1 seen in Fig. 2 (step 0 in Fig. 2) . This prior step would make sure the attestation service 206 component is not modified by anyone e.g., an attacker. Such a prior step performed before step 1 of Fig. 2 may in some situations also be performed by the one or more processors of the data processing apparatus of this disclosure.

After converting the modified attestation doc into the standardised token (attestation token) , the one or more processors may be further configured to cause an attestation service component of the apparatus (attestation service) 206 to sends the standardised token back to the attestation libraries inside the enclave. The one or more processors may then be configured to instruct the attestation libraries to send the standardised token to the verifier (user service) 202 as shown in step 6 of Fig. 2.

In some cases, there may be a plurality of standardised tokens each comprised of modified attestation data from a different iteration during the runtime of the application. As such, the attestation data may be iteratively modified during runtime to include new integrity measurements for different points in the runtime. The one or more processors may be configured to carry out this generation of modified attestation data and standardised tokens as described above. This ensures that the use of the application by the user can remain secure during runtime by continually performing attestation.

The one or more processors are further configured to verify the standardised token using a verification service. In one case the one or more processors can be configured to cause the verifier from the user to verify the standardised token and if the token is valid the verifier will provide the configuration or secrets necessary in order to run the application inside the enclave. This step is shown in step 7’ of Fig. 2.

In addition, or alternatively, the one or more processors may also be configured such that the attestation libraries send the standardised token to agencies to verify the standardised token. Such agencies may be verifiers 202’ deployed in cloud regions that may or may not form part of the data processing apparatus of the present disclosure. Such verification by agencies 202’ can be seen in step 7 of Fig. 2. In other words, the verification service may be a third-party verification service.

The agencies may then convert the attestation token to STS token (Security Token Service) as shown in step 8 of Fig. 2. The security token may be a JSON web token. This process is to associate the attestation token with an IAM role of the user to allow the application to request credentials to access other cloud-based service such as KMS or storage service. By doing this way, it is possible to smoothly integrate the confidential computing service with other cloud-based services (cloud services) 205 in the sense that only applications that have been attested to, and thus for which it can be confirmed that no one modified them, and include the correct IAM authorization can access the cloud services 205. In other words, the one or more processors may be configured such that the verification service is a third-party verification service that is configured to convert the standardised token into a security service token. The processors may further be configured to receive the security service token from the third-party verification service.

Once the security service token has been created, the one or more processors which deploy the application can use it to request to access the cloud services 205 for the application as shown in step 9 of Fig. 2. On requesting such access, the one or more processors may be configured to receive responses from cloud services 205, as shown by step 10 of Fig. 2, and therefore do not need to store any long-term security credentials inside the application itself. This feature enables single sign on service with integrity attestation support in cloud applications. This can be used as a building block to build complex services in the cloud such as landing zone service.

A further summary of the steps that may be performed by the data processing apparatus of the present disclosure, particularly by the one or more processing apparatus of the data processing apparatus are described as follows described in relation to Fig. 3. It should be noted that not the one or more processes are not required to performed all of these functions and may instead only perform a subset of the below steps. These steps are also described in relation to Fig. 2.

As shown in Fig. 3, which is a flow chart representing the steps of Fig. 2, the one or more processors are configured such that the user application running inside an enclave or secure virtual machine of the apparatus receives S301 (step 1 in Fig. 2) remote attestation request from user or external component (a verifier) . The user application may send/forward the attestation request to TEE modules (e.g., Quoting Enclave) via attestation libraries S302 (step 2 in Fig. 2) . The TEE module of the present apparatus may generate attestation data in the form of an attestation report S303 (step 3 in Fig. 2) . The attestation may be signed by the TEE hardware to create an attestation quote/doc and sends it back to attestation libraries located on the same enclave or secure virtual machine as the application where it is received S304 (step 3 in Fig. 2) . The attestation libraries, implemented by the one or more processors, combines into the attestation quote/doc the (Integrity Measurement Architecture) IMA integrity measurement list associated with a TPM 204 for attestation during runtime S305 (step 4 in Fig. 2) . In other words, the one or more processors modify, during runtime of the application, the generated attestation data to include at least one indication of integrity of at least a portion of the application, the at least one indication of integrity being provided by a root of trust. The indication of integrity may be provided by integrity measurement architecture. The attestation libraries may then send the attestation quote/doc to the attestation service component 206. The attestation service converts S306 the attestation quote/doc into a standardised token that may be an attestation token, e.g., JWT token (OIDC) format, regardless the format of the attestation quote/doc generated by any TEEs (step 5 in Fig. 2) . Then the attestation service 206 may send the attestation token back to the attestation libraries. The one or more processors may then be configured to verify S307 the standardised token using a verification service in one of two ways (step 6 in Fig. 2) . If the verifier is provided by user, the application/attestation libraries may send the attestation token to the verifier, wherein the verifier will send the secrets (encrypt/decrypt keys) and configuration to application after verifying the attestation token (step 7’ in Fig. 2) . If, however, the verifier is provided by a cloud-based provider then the application sends a creating session request to agencies 202’ in cloud using the standardised token (JWT attestation token) (step 7 in Fig. 2) . Agencies may then verify the attestation token and convert it into a security token service (STS) token to create a credential that allows application to access other cloud services 205 such as cloud storage, without the need to include IAM info into the application S308 (step 8 in Fig. 2) . The final steps are that once an STS token has been generated, this can be used by the application implemented by the one or more processors to request access to other cloud services 205 such as storage or KMS using the STS token S309 (step 9 in Fig. 2) . In response the cloud services 205 will verify the STS token and provide back their responses to application S310 (step 10 in Fig. 2) .

The methods and mechanisms provided in this disclosure allow the integration of confidential computing services into existing cloud services 205 without the need to change changing application programming interfaces or software development kits of these services. This helps cloud users to deploy their applications/service while keeping their IP (code, data) confidential. The proposed attestation service implemented on the data processing apparatus of this disclosure provides unified abstraction for remote attestation regardless of which TEE is used. The attestation service converts remote attestation quote/document generated by TEEs such as Intel TDX, Intel SGX, AMD SEV SNP, AWS Nitro, Huawei Qingtian enclave into a standardised JWT token format which is used as standard in communicating between micro cloud services 205. Furthermore, the attestation service may itself also be running inside a TEE enclave and can be attested by user verifying service in a step prior to step 1 of Fig. 2 discussed above. The proposed agencies, which may be deployed by the one or more processors in the cloud nearby the TEE enclave running user application, can convert the attestation token into STS token to create credentials for the application to connect to other cloud services 205 such as a storage OBS service, a Key Management Service (KMS) , or similar services.

The enclave/encrypted VM on which the application may be deployed by the one or more processors may require an extra root-of-trust. In this disclosure, the apparatus and method use a TPM/virtualTPM 204 for the (extra) root-of-trust. As described herein the attestation libraries implemented may combine attestation quote/doc generated by TEEs with integrity measurement architecture (IMA) that measure the integrity of file system during the runtime. This allows continuous runtime attestation as described above by the determining of the attestation data including determining the IMA measurement during runtime to ensure the system remains secure.

The remote attestation can be done in the remote attestation service by comparing entries in the measurement using TEEs and IMA logs with a pre-defined set of expected values defined in an attestation policy and reporting any measurements that fail to conform to policy expectations. This integrity measurement is also included in the attestation token.

As such the present disclosure provides a data processing method and apparatus configured to execute users’ applications inside TEE enclave/encrypted virtual machines, ensure confidentiality and integrity of user software (including sensible user data) , such that no one can interfere with the application execution including attackers with privileged access. This is achieved by providing attestation mechanisms to enable users to ensure their application is running inside TEE enclave/encrypted virtual machine. This remote attestation mechanism helps users to establish the trust of the cloud provider infrastructure while providing unified remote attestation abstraction/APIs for multiple heterogeneous TEEs. This disclosure also allows for the introduction of an attestation service component to convert different TEE attestation quote/documents into a standardised token format that can be used between cloud services. Such a standard token then lends itself to use by agencies in the cloud to convert these standardised attestation tokens into STS tokens as credentials to communicate with other cloud services 205 such storages, caching, or KMS in the cloud.

The solution of this disclosure therefore allows confidential computing service integrate smoothly with other services in the cloud e.g., Identity and Access Management (IAM) , while providing the ability to attest an application during runtime. Furthermore, the present disclosure describes combining attestation data (quote/doc) generated by TEEs with integrity measurement architecture (IMA) that measure the integrity of file system in the application enclave/encrypted VM during the runtime. These measurements reflect the stages of user application during runtime.

The applicant hereby discloses in isolation each individual feature described herein and any combination of two or more such features, to the extent that such features or combinations are capable of being carried out based on the present specification as a whole in the light of the common general knowledge of a person skilled in the art, irrespective of whether such features or combinations of features solve any problems disclosed herein, and without limitation to the scope of the claims. The applicant indicates that aspects of the present invention may consist of any such individual feature or combination of features. In view of the foregoing description, it will be evident to a person skilled in the art that various modifications may be made within the scope of the invention.

Claims

A data processing apparatus for implementing remote attestation of an application executed in a trusted execution environment, the data processing apparatus comprising one or more processors configured to:

generate attestation data for the application deployed in the trusted execution environment, the attestation data being electronically signed by the trusted execution environment;

receive at one or more stored attestation library the generated attestation data;

modify, during runtime of the application, the generated attestation data to include at least one indication of integrity of at least a portion of the application, the at least one indication of integrity being provided by a root of trust; and

convert the modified attestation data into a standardised token for verification, the standardised token comprising information included in the modified attestation data.
A data processing apparatus according to claim 1, wherein the one or more processors are further configured to verify the standardised token using a verification service; and

wherein the verification service is a user verification service.
A data processing apparatus according to claim 2, wherein the one or more processors are further configured to verify the standardised token using a verification service;

wherein the verification service is a third-party verification service that is configured to convert the standardised token into a security service token; and

the one or more processors are further configured to receive the security service token from the third-party verification service.
A data processing apparatus according to any one of claims 1 to 3, wherein the one or more processors are further configured to deploy the application comprising application data and application code, and

request attestation of the application data and/or code from a module of the trusted execution environment in response to receiving an attestation request from a user.
A data processing apparatus according to any one of claims 1 to 4, wherein the one or more processors are further configured to contact a cloud-based service requesting access to the cloud-based service; and

receive a response from the cloud base service based on verification of the standardised token.
A data processing apparatus according to any one of claims 1 to 5, wherein the standardised token is a security token.
A data processing apparatus according to any one of claims 1 to 6, wherein the indication of integrity is provided by integrity measurement architecture.
A data processing apparatus according to any one of claims 1 to 7, wherein the root of trust is provided by a hardware-based security module.
A data processing apparatus according to any one of claims 1 to 8, wherein the root of trust is an external root of trust comprising a combination of modules of the trusted execution environment and trusted platform modules.
A data processing apparatus according to any one of claims 1 to 9, wherein the one or more attestation library is located on a secure enclave or confidential virtual machine of the apparatus.
A method of processing data to perform remote attestation of an application executed in a trusted execution environment, the method comprising:

generating attestation data for the application deployed in the trusted execution environment, the attestation data being electronically signed by the trusted execution environment;

receiving at one or more stored attestation library the generated attestation data;

modifying, during runtime of the application, the generated attestation data to include at least one indication of integrity of at least a portion of the application, the at least one indication of integrity being provided by a root of trust; and

converting the modified attestation data into a standardised token for verification, the standardised token comprising information included in the modified attestation data.
A method according to claim 11, further comprising verifying the standardised token using a verification service; and

wherein the verification service is a user verification service.
A method according to claim 12, further comprising verifying the standardised token using a verification service;

wherein the verification service is a third-party verification service that converts the standardised token into a security service token; and

the method further comprises receiving the security service token from the third-party verification service.
A method according to any one of claims 11 to 13, wherein the method further comprises deploying the application, the application comprising application data and application code, and

requesting attestation of the application data and/or code from a module of the trusted execution environment in response to receiving an attestation request from a user.
A method according to any one of claims 11 to 14, wherein the method further comprises contacting a cloud-based service requesting access to the cloud-based service; and

receiving a response from the cloud base service based on verification of the standardised token.
A method according to any one of claims 11 to 15, wherein the standardised token is a security Token.
A method according to any one of claims 11 to 16, wherein the method further comprises providing the indication of integrity using integrity measurement architecture.
A method according to any one of claims 11 to 17, wherein the root of trust is provided by a hardware-based security module.
A method according to any one of claims 11 to 18, wherein the root of trust is an external root of trust comprising a combination of modules of the trusted execution environment and trusted platform modules.
A method according to any one of claims 11 to 19, wherein the one or more attestation library is located on a secure enclave or confidential virtual machine of the apparatus.