Patent Description:
As more data is moved to the cloud, mobile, or loT devices - where processing takes place in remote and difficult to secure locations - the protection of data and applications during execution is increasingly important.

Confidential computing thus provides a solution for protecting data in use by using hardware-based Trusted Execution Environments (henceforth HW TEE). A Trusted Execution Environment (TEE) is a secure area of a processor that assures data integrity, data confidentiality, and code integrity. The hardware-based TEE uses hardware-backed techniques to provide increased security guarantees for the execution of code and protection of data within that environment.

HW TEE basically provides security though the lowest layer of hardware, down to the silicon components, with a minimum of dependencies, by removing the operating system, device driver and peripheral vendors from the list of required trusted parties, thereby reducing exposure to potential compromise. Examples of HW TEE chip providers are Intel with Software Guard Extensions (Intel SGX), or AMD with Secure Encrypted Virtualization (SEV-SNP).

Service providers or cloud service providers such as Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure (Azure), OVHCloud, or AlibabaCloud normally comprise one or several HW TEE in their infrastructure in order to offer to their customers the means to use confidential computing for their payload(s). These customers (henceforth "owners") own piece(s) of computing resources e.g., code or data (henceforth "payload") that wishes to execute in the CSP infrastructure.

Nevertheless, confidential computing services are not coming as a simple turnkey solution, especially for going beyond basic security properties. One of these basic security properties is known as remote attestation or simply "attestation", that is, a mechanism to provide a verifiable signature of the running payload provided by the HW TEE and to be verified by either the owner or a 3rd party of trust. This type of evidence must be signed by hardware that can be vouched for by a manufacturer (e.g., Intel or AMD), so that the party checking the evidence has some assurance that it was not generated by malware or other unauthorized parties.

However, HW TEE from different vendors have their own attestation mechanisms (i.e., different technically implemented mechanisms), that are not interoperable among them and only share a minimum set of security features for the attestation verification. Indeed, all HW TEE default attestation mechanisms ensure that the HW TEE is genuine and the payload is the expected one (measurement signature indicating that it was not modified) further being able to inform about its current state in the execution.

Furthermore, in order to prevent replay attacks against the attestation, the attestation mechanism may involve a nonce sent from the owner.

In addition to these basic security features, there is no built-in mean to guarantee that any subsequent communication from the owner will occur with the same attested payload (and not a modified one). For instance, if the owner wishes to provision some secret(s) to that payload, he/she will be uncertain if the very same payload is being provisioned with these secret(s) if the attestation was already performed.

Finally, as of today, the attestation mechanism is not handled as a first class citizen by the CSP or commonly used software stacks of the public cloud. There are various prior art techniques to facilitate authentic remote attestation process, for example, one disclosed in reference <CIT> (hereinafter US'<NUM>) and another disclosed in <CIT> (hereinafter WO'<NUM>). The reference US'<NUM> mentions about electronic transaction platform <NUM> for receiving and processing secure consumer data such that the platform requires a separate Trusted Platform Module (TPM) to realize trust in remote attestation process and the reference WO'<NUM> is intended for distributing attestation key and certificate in trusted computing. The prior art techniques are not efficient in enabling a secure and trusted attestation process with a great ease.

Thus, there is a need in the confidential computing industry for an easier and interoperable solution that allows the owner to provision secret(s) in the very same attested payload.

The present invention provides a solution for the aforementioned problems by a method to establish a secure channel between a party (e.g., the owner of a payload or a broker), and the software payload itself when running into a hardware-based trusted execution environment, HW TEE according to claim <NUM>, a related system according to claim <NUM>, a party according to claim <NUM>, a software payload according to claim <NUM> and a HW TEE according to claim <NUM>. In dependent claims, preferred embodiments of the invention are defined.

In a first inventive aspect, the invention provides a computer-implemented method to establish a secure channel between a party, for instance a broker, and a software payload of an owner when running into a hardware-based trusted execution environment, HW TEE, at the instance of a cloud service provider, the method comprising the following steps:.

As mentioned, the attestation process requires that the party eventually send a nonce to the payload (or to HW TEE) for verification purposes. As known, the HW TEE is the entity handling the nonce, but usually it passes through the payload. Throughout the following description, a nonce will be understood as a data string generated at the party side (either by the party's device or by another interconnected device) to be used only once in a cryptographic communication. The fact that the nonce is sent by the party does no presuppose that the attestation flow is started by the party. It may be equally started by the payload itself, when starting for example.

That is, in a particular embodiment, the workflow starts either because the payload sends a message on start-up or because the CSP sends a notification that the payload is ready or because the party checks periodically whether the payload is ready.

The nonce may be either a random or a pseudo-random number, or also contain blocks of different information such as a timestamp or identifiers (owner's, payload's, HW TEE's, etc.). Nevertheless, the skilled person shall recognize that the actual format, size and other informative data sent in the nonce is specific to the technology of the HW TEE vendor. For instance, some technologies require that the original nonce be first hashed to maintain a length.

Then, in a typical process, once the party provides the payload with the nonce, it is passed to the HW TEE as part of the traditional attestation process on the HW TEE side. In other words, the nonce becomes part of the data signed by the HW TEE and, therefore, if the owner is able to verify the attestation it means that the same nonce was used.

The present invention proposed mixing with this nonce other data generated by the payload (in particular a generated payload public key), to be also signed by the HW TEE. In a preferred embodiment, the payload generates an ECDSA key pair (payload private key, payload public key).

Consequently, if the party also knows this payload public key, it will be able to perform the same mixing operation and by verifying the attestation, it will be sure that these data were indeed signed by the HW TEE.

In this way, the method according to the invention binds a key pair generated by the payload to the HW TEE. Therefore, if the owner is able to verify the attestation then it is certain that this key pair was generated by (or inside) the payload running under confidential computing.

From this point, both the software payload and the party can generate a session key (shared secret) to establish a secure channel between them from the point of view of the party. Then, this shared session key can be used as the key for a symmetric algorithm like Advanced Encryption Standard (AES) or Triple Data Encryption Algorithm (3DES) thereby establishing the secure channel.

Advantageously, the present invention allows leveraging the capabilities in common of HW TEEs from different vendors to guarantee the authenticity of these public elements while providing a multi-CSP method to establish a secure channel between party and payload.

Once the secure channel is established, the party itself (or other player benefiting from this secure channel) is certain that can inject or provision some secret(s) in the very same attested payload without being exposed.

As mentioned, the party according to the invention may be the owner of the payload or a broker. While the owner may be any customer of the CSP wanting to use confidential computing to run its payload, a broker is a <NUM>rd party of trust handling flows and processes on the behalf of the owner. In the present invention, the broker provides payload life cycle management regarding attestation and provisioning for confidential computing purposes. It does require a relationship of trust between the broker and the owner up to the initial provisioning.

In a preferred embodiment, the party is a broker.

The skilled person would recognize that his <NUM>rd party of trust is other than the CSP because, among others, one of the key properties in confidential computing is to be protected against the CSP which can be verified by the attestation mechanism. In other words, the CSP is not legitimate to report to the owner that the attestation was verified.

Thus, the present invention allows the CSP to provide HW TEE infrastructure as a service not being involved in the attestation/provisioning flow for a clear separation of duties.

By using a broker, the CSP is kept out of the scope of the confidential computing attestation verification and, advantageously, the owner can delegate to it this complex process while, in addition, the broker will be entrusted to generate traditional credentials for the payload to be able to access the native cloud environment.

Accordingly, by using a broker, any unskilled owner may also insert seamlessly in the cloud native ecosystem, since the proof of the attestation has been transformed into means that are usable by existing, deployed and broadly used software stacks of the public cloud.

As the skilled person knows, the session key (shared secret) between the party and the payload may be generated based on different key-agreement protocols such as any public key-based key-agreement protocol.

For instance, in a particular embodiment, the method further comprises the following steps for generating the session key between the software payload and the party using a non-authenticated key-agreement protocol such as one based on an Elliptic Curve Diffie-Hellman, ECDH, protocol:.

Since it uses a non-authenticated key-agreement protocol, it further requires that the public element(s) coming from the payload be signed using the just generated payload private key. In this way, the party can ensure the origin of these public elements preventing any Man-In-The-Middle (MIM) attacks.

Nonetheless, the payload may also use the payload private key to sign any other data exchanged with the party apart from the ECDH public elements. For instance, payload private key may be used to sign other data during the establishment of the secure channel itself, later on for subsequent exchanges, etc..

Since some data has to be public, in a preferred embodiment, the payload will generate the ECDSA Key Pair (payload public key, payload private key) and compute hash(payload public key) that will become this public data.

Then, this hash(payload public key) is mixed, for instance using an XOR function, with the nonce coming from the owner attestation request. Finally, XOR(hash(payload public key), nonce) is passed through the HW TEE during the attestation computation.

In addition, through the lifetime of the payload, it may be necessary for the party to set subsequent communications with it, for instance to perform secret(s) rotation. However, maintaining the secure channel through the whole lifetime of the payload would be too costly in term of network resources.

According to the prior art, the option would be to re-do the attestation procedure to re-establish a secure channel between the payload and the party but, as mentioned, in that case the party cannot be sure whether the same attested payload is being provisioned. This is due to a core limitation of the existing HW TEE technology that does not provide confidentiality for the payload before its execution, but only its integrity.

Consequently, there is no guarantee for the party that it would re-establish a secure channel with the very same payload, and there is no guarantee for the payload that it will be re-contacted by the same party. As the skilled person would appreciate, depending on the use case, a lack of strong pairing between the payload and the party may prevent confidential computing from being an option in some use cases.

Therefore, in a particular embodiment, once the secure channel has been established between the party and the software payload running into the HW TEE, the party sends a party authentication means to the payload, this party authentication means being configured to allow subsequent authentication of the owner to the payload to re-establish a secure channel.

In other words, in this embodiment, the method ensures that once the payload has been provisioned by the party with the secret(s), it is not possible for any other parties to break this "mating". Accordingly, this method prevents a rogue party from masquerading the genuine one once, for instance, the payload has been provisioned with sensitive data.

In a preferred embodiment, the party sends the party authentication means just after establishing the secure channel with the payload. That is, not after re-establishing the channel to avoid a rogue party-situation. In this way, it is ensured that subsequent communications will still occur between the exact same instance of the payload and the same party and, more importantly, that subsequent re-establishments of the secure channel will happen between the parties that established the original secure channel.

To do so, for instance, these owner authentication means will be stored in the memory of the payload under the protection of the HW TEE, ensuring that it cannot be compromised in both confidentiality and integrity. That is, in a particular embodiment, after receiving the authentication means, the software payload stores it persistently in a memory of the HW TEE architecture.

A secure channel may be closed and re-opened on demand, without need to repeat the entire attestation flow again.

In an embodiment, the party generates a party key pair: public key and private key using, for example, ECDSA, and then sends the party public key to the software payload for subsequent authentication purposes. Similarly, the payload private key may be kept in the same (or different) memory, e.g., RAM, under the protection of the HW TEE. That is, in a particular embodiment, after generating the payload private key, the software payload stores it in a memory under the protection of the HW TEE architecture.

By doing so, it will be possible to have a true mutual authentication for the subsequent communication between the payload and the original owner, by using both the public/ private keys on payload side, generated at the time of the initial attestation and the public / private keys on the owner side.

For HW TEEs having natively data sealing (term used by Intel) capabilities to store securely data in persistent storage, the payload private key and the owner authentication means can be stored therein. To do so, for instance, the HW TEE may access persistent storage (e.g., a hard disk drive HDD or solid-state drive SSD) and generates its own encryption keys so that the payload can encrypt the sensitive data it wants to store therein.

The HW TEE may also provide read-write memory for the payload such as the RAM that is typically encrypted by the HW TEE as part of the normal encryption of the payload. Unfortunately, since the payload keeps any sensitive data as part of its own RAM memory, there is an issue when the payload is stopped.

Consequently, the present invention advantageously defines a mean to provide sealing capabilities to the payload to ensure the confidentiality of its persistent storage. This means that if this payload is modified or the HW TEE is modified or tampered-with, the present invention still ensures that the payload will not be able to retrieve its persistent storage protected by the sealing capability.

To that end, in a particular embodiment, the method allows to persistently store data by the payload once the secure channel has been established, wherein the method comprises the following steps:.

Accordingly, this initiator key is not stored by the payload and will be deleted after used.

In a particular embodiment, the party encrypts this payload identifier using a first encryption key, e.g., a symmetric key, before sending it to the payload for its persistent storing in encrypted form.

In a particular embodiment, the key initiator is a symmetric key.

In a preferred embodiment, the key initiator is first passed through a key derivation function, KDF, by the payload, to generate a symmetric key that encrypts the data.

In a preferred embodiment, the key initiator is passed through a key derivation function, KDF, by the payload, to generate a Message Authentication Code (MAC) that allows the payload to subsequently check the integrity of the persistently stored data.

As mentioned, the owner trusts the broker to perform the attestation and provisioning of specific secrets for sealing and of a mean for the payload to authenticate to the owner. Then, the owner will be able to check that the attestation has been performed.

As a result, the owner can authenticate and communicate securely with the payload to, in addition, for instance, inject and manage applicative assets to permit the payload to access further service provider(s). According to the invention, a service provider is a <NUM>rd party (i.e., different from the broker) used by the owner to provide e.g., security services to its payload such as an external key management system.

Once the persistent storage capabilities of the payload are enabled, the party (broker or owner) can inject further secret(s) for different purposes.

In a first scenario, by injecting some secrets, the payload may prove to a user accessing, for instance, a web-services provided by the payload that it has been attested by the party. Throughout this document, a user is a user or customer of the service provided by the owner through its payload.

In this embodiment when the running payload provides a web-service, the method further comprising:.

Advantageously, it proves easily that the web services is running in an attested HW TEE and fits naturally in environment using HTTPS connectivity like web-browser.

In a second scenario, the payload can prove to the owner that it has been attested by the broker when the owner wants to manage its payload using, for instance, a Secure Sockets Layer, SSL connection. In other words, the invention allows the owner of the payload to directly communicate with and manage the payload.

In this embodiment, assuming that the party is the broker, the method comprises the following steps:.

In addition, the payload uses the stored SSL payload private key for configuring a Secure Shell, SSH, server. In other words, the payload uses it to configure the identity of the SSH server (ex: /etc/. ssh/*_key*).

On the other hand, the owner uses the stored SSL payload public key to automatically authenticate the payload when accessing it through an SSH session. In other words, the broker sends the SSL payload public key to the owner, so it can update its "known_hosts" configuration file to be able to automatically authenticate the payload when accessing it through a SSH session (ex: ~/. ssh/known_hosts).

Advantageously, this provides an easy manner to use SSL connectivity for remote payload management.

In a preferred embodiment, at least one (preferably both) of the SSL payload key pair and the SSL owner key pair is generated by the broker. Advantageously, since the broker is trusted by the owner, this embodiment is advantageous in terms of SLAs and performance.

Nevertheless, in an alternative embodiment, one or both of these key pairs may be generated by another party such as:.

In a third scenario, the payload can prove to a service provider that has been attested by the broker aiming at using it. That is, the present invention allows to transform the attestation proof in an actionable mean for accessing a common service provider.

More in particular, it allows the owner to have a transfer of proof of the attestation/provisioning flow into a form that is usable in commonly deployed environments.

By doing so, both users and service providers can benefit from confidential computing advantages without having to change their current practices.

In this embodiment, the method further comprises the following steps:.

Advantageously, this embodiment fits naturally in environment using Application Programming Interfaces, APIs. That is, the broker is considered as the Identity Provider, IdP, for the payload, while the owner configures the service provider to access JWT from the broker.

In a preferred embodiment, the owner sets at least one policy for delegating the management of the life cycle of at least one credential to the party.

In other words, the life cycle management of the different credentials can be delegated to the broker by the owner and managed by policies: periodic renewal of certificate(s) (first scenario), periodic renewal of SSL public key (second scenario), short-lived JWT (third scenario).

The liveness duration, the decision to (or not to) re-attest, the periodicity of the re-attestation, etc. is also part of the policies to be defined by the owner and provided as configuration policies of the life cycle services offered by the broker.

In a second inventive aspect, the invention provides a computer-implemented method to re-establish an authenticated secure channel between a party and the software payload of an owner when running into a hardware-based trusted execution environment, HW TEE, at the instance of a cloud service provider, the method comprising the following steps:.

In a third inventive aspect, the invention provides a system for establishing a secure channel between party and a software payload of an owner when running into a hardware-based trusted execution environment, HW TEE, at the instance of a cloud service provider, the system comprising:.

In a fourth inventive aspect, the invention provides for establishing a secure channel with the software payload when running into a HW TEE at the instance of a cloud service provider, the party being configured to communicate with the software payload when running into the HW TEE, wherein
the party is further configured to.

In a fifth inventive aspect, the invention provides a software payload for establishing a secure channel with a party when running into a HW TEE at the instance of a cloud service provider, the software payload being configured to run into the HW TEE operated by the cloud service provider;
wherein the software payload is further configured to:.

In a sixth inventive aspect, the invention provides a hardware-based trusted execution environment, HW TEE, at the instance of a cloud service provider for establishing a secure channel between a party and a software payload when running into the HW TEE, wherein the HW TEE is operated by the cloud service provider;
wherein the HW TEE is configured to:.

All the features described in this specification (including the claims, description and drawings) and/or all the steps of the described method can be combined in any combination, with the exception of combinations of such mutually exclusive features and/or steps.

As it will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a method or a system for establishing a secure channel, a method to re-establish the secure channel, a party, a software payload or a HW TEE.

Herein below, it is considered a case in which the method according to the invention for establishing a secure channel is implemented by, locally at a server side, an HW TEE at instances or premises of a cloud service provider.

According to another embodiment, the party (either the payload's owner or another <NUM>rd party of trust such as a broker) is implemented by a PC <NUM> or a server <NUM>, and may also be a SE host device that cooperates with a TEE that is adapted to carry out the functions that are carried out by the party.

The invention does not impose any constraint as to a kind of the party's device (so-called "party") or cloud server provider's HW TEE. Examples of party's devices can be a PC, a mobile phone, a server, an loT device, etc..

As mentioned, even if the party may be the payload's owner or a <NUM>rd party of trust such as broker, for illustrative purposes, in the following, the party will be a broker.

Once the payload starts, depending on the owner choice (e.g., set by policies), the payload <NUM> may directly contact the broker <NUM>, <NUM> or, alternatively, the owner <NUM> may instruct the broker <NUM>, <NUM> to contact the payload.

<FIG> depicts schematically a system of a party (e.g., the owner <NUM> or the broker(s) <NUM>, <NUM>) and a software payload <NUM> running into a HW TEE <NUM> at the instance or premises of a cloud service provider <NUM>.

The party, when acting as a broker, may be embodied as a PC <NUM> and/or as a single <NUM> or a collection of interconnected servers. The invention also envisages the presence of a service provider's server <NUM>.

The owner (i.e., "owner's device") is depicted in <FIG> also as a PC <NUM> operated by a user <NUM>. The PC <NUM> may be configured to receive, from the user <NUM> at least his/her login credentials for at least one of his/her end-user account(s), verify them and let said user to run applications and/or initiate different processes such as sending a code as a whole or part (i.e., "trusted portion") of an application, i.e., the payload <NUM>, to be executed in the HW TEE.

In the following, the description about the PC <NUM> applies to the owner <NUM> and any or both of the servers <NUM>, <NUM>.

The PCs <NUM> or <NUM> (or even the server(s) <NUM>, <NUM>) includes one or several (micro)processors (and/or a (micro)controller(s)) <NUM>, as data processing means, comprising and/or being connected to one or several memories <NUM>, as data storing means, comprising or being connected to means for interfacing with the user, such as a Man Machine Interface (or MMI), and comprising or being connected to an Input/Output (or I/O) interface(s) <NUM> that are internally all connected, through an internal bidirectional data bus.

The I/O interface(s) <NUM> may include a wired and/or a wireless interface, to exchange, over a contact and/or Contactless (or CTL) link(s), with e.g., the user <NUM> or any other user in charge of the PC <NUM> or server(s) <NUM>, <NUM>. Within the present description, the adjective "CTL" denotes notably that the communication means communicates via one or several Short Range (or SR) type Radio Frequency (or RF) links.

The PCs <NUM>, <NUM> may be connected, wired (not represented) or wirelessly, to another device operated either at the owner's instances or at the broker's instances, respectively. That is, the owner <NUM> may be also embodied as a server device configured to execute data / code, optionally split it into trusted and untrusted portions, and send the trusted portions to a CSP's HW TEE for its execution or, alternatively, the broker <NUM>, <NUM> can do it on its behalf. Examples of payloads as highly sensitive data that must be protected and securely processed is personally identifiable information (PII), healthcare, financial, or intellectual property data.

The PC MMI may include a display screen(s), a keyboard(s), a loudspeaker(s) and/or a camera(s) (not represented). The PC MMI allows a user to interact with the PC <NUM>. The PC MMI may be used for getting data entered and/or provided by the user.

The PC memory(ies) <NUM> may include one or several volatile memories and/or one or several non-volatile memories. The PC memory(ies) <NUM> may store data, such as an ID(s) relating to the PC, that allows identifying uniquely and addressing the PC. The PC ID(s) may include a unique ID, such as a UUID, a Uniform Resource Locator (or URL), a Uniform Resource ID (or URI), and/or other data that allows identifying uniquely and addressing the PC.

The PC memory(ies) <NUM> stores the Operating System (OS) and an application which is adapted to send the payload (also known as "workload") to the CSP to be processed within one of the HW TEE. The owner's application that allows sending this payload may be a web-based portal (e.g., Amazon Web Service, AWS, management console), or even an open source application (e.g., AWS command line interface).

The PC <NUM> and/or <NUM> themselves, or e.g., in combination with server <NUM>, are further configured to send information over a communication network <NUM> (e.g., Transport Layer Security, TLS) to the CSP end <NUM>. In particular, the broker <NUM> and the cloud service provider infrastructure <NUM> may communicate via one or more Application Program Interfaces, APIs, using HTTPS over TLS.

In addition, the owner <NUM> can also establish SSL connectivity directly with the payload running on the HW TEE of the CSP <NUM>. Furthermore, the running payload <NUM> can access services of the service provider <NUM>. Also, if the payload <NUM> provides a web-service, different users <NUM> thereof can also establish HTTPS connectivity with the running payload <NUM>. Details about how to accomplish these wireless, secure connections will be described infra.

At the CSP end <NUM>, or CSP facilities, one or more computing devices <NUM>, <NUM>', <NUM>", <NUM>"' with one or more HW TEEs <NUM>, <NUM>' are provided as secure enclave(s) for confidential computing services.

As shown in <FIG>, the computing device <NUM> includes a processor <NUM>, a memory <NUM>, and an I/O subsystem <NUM>, and a data storage device <NUM>. Examples of computing devices <NUM> suitable for confidential computing are those described in <CIT> in relation with secure enclave supports such as Intel® Software Guard Extensions (SGX) technology.

Thus, the processor <NUM> may be embodied as a single or multi-core processor(s), digital signal processor, microcontroller, or other processor or processing/controlling circuit including the secure enclave support <NUM>. <NUM>, which allows the processor <NUM> to establish a trusted execution environment <NUM> known as a secure enclave, in which executing code (i.e., payload) may be measured, verified, and/or otherwise determined to be authentic.

Additionally, code and data included in the secure enclave may be encrypted or otherwise protected from being accessed by code executing outside of the secure enclave. For example, code and data included in the secure enclave may be protected by hardware protection mechanisms of the processor <NUM> while being executed or while being stored in certain protected cache memory of the processor <NUM>. The secure enclave support <NUM>. <NUM> may be embodied as a set of processor instruction extensions that allows the processor <NUM> to establish one or more secure enclaves in the memory <NUM>.

The memory <NUM> may be embodied as any type of volatile or non-volatile memory or data storage capable of performing the functions described herein. In operation, the memory <NUM> may store various data and software used during operation of the computing device <NUM> such as operating systems, applications, programs, libraries, and drivers. As shown, the memory <NUM> may be communicatively coupled to the processor <NUM> via the I/O subsystem <NUM>, which may be embodied as circuitry and/or components to facilitate input/output operations with the processor <NUM>, the memory <NUM>, and other components (not shown) of the computing device <NUM>.

The data storage device <NUM>. <NUM> may be embodied as any type of device or devices configured for short-term or long-term storage (i.e., persistent storage) of data such as, for example, memory devices and circuits, memory cards, hard disk drives, solid-state drives, non-volatile flash memory, or other data storage devices. The secure enclave platform <NUM>. <NUM> may have native mechanisms for sealing or persistently storing pre-encrypted data and native standard key exchange to setup an encrypted tunnel for data transport between components of the computing device <NUM> (for instance, for local attestation purposes).

In this illustrative embodiment, the components of the computing device <NUM>, or the secure enclave platform <NUM>. <NUM> itself, additionally comprise hardware attestation features to prove their authenticity. The root of trust in the computing device <NUM> manages the security credentials (keys, certificates) used with this purpose. As mentioned, the attestation process measures code and data of the running payload, for instance when it is starting up and attests it when the owner requests attestation.

<FIG> depicts a schematic flowchart of a method <NUM> to establish a secure channel between the party <NUM> and the software payload <NUM>. For this, it will be assumed that the owner has already sent the payload <NUM> to the CSP <NUM> and it is running into a HW TEE <NUM> described in <FIG>.

Method <NUM> comprises the following steps: first, the party <NUM> generates and sends <NUM> at least a nonce (NonceBroker) to the software payload <NUM>. Then, the payload <NUM> generates <NUM> a payload key pair: public key (KpubPayload) and private key (KprivPayload). The payload mixes <NUM> the KpubPayload with NonceBroker as a "modified" nonce (AttestationNonce) to be provided to the HW TEE. That is, payload <NUM> will provide the HW TEE <NUM> with the AttestationNonce for computing the attestation instead of the original NonceBroker generated by the party (e.g., the broker).

After, HW TEE <NUM> computes <NUM> an attestation (Attestation Payload Report) using at least this AttestationNonce. AttestationPayloadReport will be retrieved by the payload <NUM> and forwarded <NUM> to the party with the KpubPayload.

Once received by the party <NUM>, it reproduces the same mixing done by the payload but using the nonce it originally sent (i.e., NonceBroker) instead. Therefore, if the mixing output is the same, it is certain that no attack occurred. Therefore, the party <NUM> can verify <NUM> that it is the same data it originally sent. Finally, the payload <NUM> and the party <NUM> generates <NUM> a session key and thus establish <NUM> a secure channel between them.

<FIG> depicts schematic diagram of an embodiment of the method <NUM> to establish a secure channel between the party <NUM> and the software payload <NUM>.

Alike traditional schemes, first, the payload <NUM> will be started by the owner and measured by the HW TEE. The payload sends a message to the HW TEE in order to generate an encryption key for the subsequent payload execution and, in addition, HE TEE measures the firmware running on the payload <NUM> during boot. Just after, the payload <NUM> will normally send a liveness notification to the owner <NUM>.

If the party is a broker, once the payload starts, depending on the owner choice (e.g., set by policies), the payload <NUM> may directly contact the broker or, alternatively, the owner may instruct the broker to contact the payload.

Preferably, from that point, the establishment of the secure channel according to this invention starts. In particular, in the following, it will be described a non-authenticated key-agreement protocol of the type of Elliptic Curve Diffie-Hellman, ECDH, protocol used for generating the session key by the software payload <NUM> and the party <NUM>.

As it can be seen from <FIG>, the party <NUM> generates <NUM> party public data (ECDHBrokerPubElt) and NonceBroker, and sends <NUM> them to the payload <NUM>. The party also stores this NonceBroker for verifying afterwards the attestation.

Then, the payload <NUM> generates <NUM> ECDS key pair: KpubPayload / KprivPayload. The payload will also generate <NUM> payload public data (ECDHPayloadPubElt) and sign <NUM> this ECDHPayloadPubElt using KprivPayload resulting in ECDHPayloadPubEltSigned.

Next, the payload will compute <NUM> a hash of the KpubPayload further scrambling this hash output with the NonceBroker. In other words, computing: <MAT>.

This AttestationNonce will be sent <NUM> by the payload to the HW TEE for computing <NUM> the attestation. In a traditional workflow, the payload would send to the HW TEE the original NonceBroker sent by the user but, according to the invention, the AttestationNonce will be used instead. The skilled person would understand that the payload will also send specific parameters required by the specific HW TEE on a normal attestation workflow. Then, once received, the HW TEE <NUM> computes the attestation using at least this AttestationNonce thus giving rise to AttestationPayloadReport which is further sent back <NUM> to the payload <NUM>.

Then, the payload receives it (or intercepts it), and forward it <NUM> to the party together with KpubPayload, ECDHPayloadPubElt, ECDHPayloadPubEltSigned.

The party will receive it and reproduce <NUM> the mixing done by the payload but using the original NonceBroker it sent to the payload. Therefore, the party computes: <MAT> and verifies <NUM> AttestationPayloadReport using AttestationNonce'. If the verification succeeds, the workflow continues. Otherwise, the attestation verification fails and the secure channel cannot be established. In addition, the party (either broker or owner itself) can be alerted somehow and, optionally, preventive measures may be taken such as aborting the connection with the payload.

In case the attestation can be verified, the party <NUM> verifies <NUM> ECDHPayloadPubEltSigned using KpubPayload. If the verification of the signature succeeds, the workflow continues. Otherwise, the signature verification fails and the secure channel cannot be established.

Therefore, both the software payload <NUM> and the party <NUM> separately generate <NUM> a shared secret using party public data and payload public data, respectively. Hence, a direct secure channel is established <NUM> between them.

KPrivPayload is not limited to sign the ECDH Public Elements, it may be also used to sign any other data exchanged with the party (either the broker, the owner ot both). In other embodiments, a Key Derivation Function may be used from the shared secret to have a specific signature key.

Advantageously, once the secure channel has been established, the party is able to provision the very same attested payload with some secret(s).

Still, through the lifetime of the Payload, it may be necessary for the party to have subsequent communications with it, for instance to perform secret(s) rotation.

Therefore, <FIG> depicts a schematic diagram of an embodiment of the method <NUM> for providing authentication means for the party. Thanks to this, both parties are authenticated and therefore the secure channel may be re-opened on demand with the very same attested payload.

That is, once the secure channel has been established between the party <NUM> and the software payload <NUM> running into the HW TEE <NUM> for instance, using the method <NUM>, <NUM> according to <FIG> or <FIG>, the party <NUM> generates <NUM> a party ECDSA key pair: public key (KpubBroker) and private key (KprivBroker), and then sends the KpubBroker to the payload.

The software payload receives KpubBroker and stores it <NUM> in a memory under the protection of the HW TEE. This persistent storage may be used either using the native sealing capabilities of the HW TEE or, alternatively, using any of the methods according to any of <FIG>.

Then, both the party <NUM> and the payload <NUM> can exchange <NUM> any information relevant to the application in a secure manner.

After this provisioning, since maintaining the secure channel through the whole lifetime of the payload would be too costly in term of network resources, any of the ends may require closing the secure channel <NUM> and the secure communication will stop.

Therefore, an authenticated secure channel backed up by attestation may be opened and closed as needed.

<FIG> depicts a schematic diagram of an embodiment of the method <NUM> to re-establish a secure and authenticated channel between the party <NUM> and the software payload <NUM>.

It will be assumed that a secure channel according to the method <NUM>, <NUM> of the <FIG> or <FIG> was already established and, afterwards, stopped.

First, the party <NUM> and the payload <NUM> perform a non-authenticated key-agreement protocol of the type of ECDH protocol for generating a session key. This session key may be different or similar to the session key already used for the establishment of the last secure channel.

Thus, the party generates <NUM> party public data (ECDHBrokerPubElt) and signs it <NUM> using KprivBroker thus resulting in ECDHBrokerPubEltSigned. Then, the party sends <NUM> these ECDHBrokerPubElt and ECDHBrokerPubEltSigned to the payload <NUM>.

Tthe software payload retrieves the previously stored (e.g., in a HW TEE memory such as RAM) KpubBroker and verifies <NUM> ECDHBrokerPubEltSigned using KpubBroker.

If the party signature is verified at payload's end, the workflow will continue. Otherwise, this verification will fail and the secure channel cannot be established.

If verified, the payload also generates <NUM> payload public data (ECDHPayloadPubElt) and retrieves KprivPayload for signing <NUM> this ECDHPayloadPubElt giving rise to ECDHPayloadPubEltSigned.

Then, the payload sends <NUM> ECDHPayloadPubElt and ECDHPayloadPubEltSigned to the party which verifies <NUM>, at its end, the ECDHPayloadPubEltSigned using the KpubPayload.

If verified, both the payload <NUM> and the party <NUM> will generate or compute <NUM> a (new) shared secret using ECDHBrokerPubElt and ECDHPayloadPubElt, respectively.

Finally, a secure channel is re-established <NUM> between the party and the software payload running into the HW TEE allowing the party <NUM> and the payload <NUM> exchanging any sensitive information in a secure manner.

<FIG> depicts a schematic flowchart of a method to persistently store sensitive data by the payload <NUM>.

It is assumed that a secure channel has been established <NUM> between the party <NUM> and the payload <NUM> itself when running into a HW TEE at the instance of a cloud service provider. Preferably, this secure channel is backed by the computation, by the HW TEE, of an attestation.

First, the party generates <NUM> a payload identifier (PayloadID) using information shared from the payload during the establishment of the secure channel. For instance, payloadID can be derived from the attestation information such as information relative to the HW TEE, the version of the payload, and/or the instantiation of the payload.

Then, the party also generates <NUM> a key initiator (KEY_INIT) and persistently stores <NUM> (i.e., at the party side) the key initiator associated to the payloadID. In a basic configuration, this KEY_INIT may be simply a symmetric key.

Then, the party sends <NUM> these payloadID and key initiator to the payload. And the payload uses <NUM> the key initiator to encrypt data.

By doing so, the payload will be able to persistently store <NUM> in the HW TEE memory (e.g., RAM) the encrypted data and the payloadID without relying on the privacy mechanisms of the HW TEE.

The persistently stored sensitive data may be, for instance, KpubBroker and KprivPayload. As it will be seen, the payload will also store PayloadIDCiphered (<FIG>), X. <NUM> certificate (<FIG>), SSLPrivPayloadKey, SSLPubPayloadKey, SSLPubOwnerKey (<FIG>), and JWT (<FIG>).

Therefore, when the payload need to retrieve this persistently stored data the following steps are taken:.

After that, the payload will delete this key initiator.

<FIG> depicts a preferred embodiment of a method <NUM> to persistently store sensitive data by the payload <NUM> without relying on the sealing capabilities of the HW TEE.

As mentioned, a secure channel has been established <NUM> between the party <NUM> and the payload <NUM>, for instance, backed by the computation, by the HW TEE, of an attestation.

The party generates <NUM> PayloadID using information from the attestation. Then, the party encrypts the payloadID using a first encryption key (PayloadIDEncKey) resulting in PayloadIDCiphered.

Then, the party also generates <NUM> KEY_INIT and persistently stores <NUM> (i.e., at the party side) the KEY_INIT associated to the payloadID.

Then, the party sends <NUM> these payloadIDCiphered and KEY_INIT to the payload.

The payload passes <NUM> the KEY_INIT through a key derivation function, KDF, to generate a symmetric key (DataEncKey) for encrypting data, and (in addition) to generate a DatalntKey and Message Authentication Code (MAC) that allows the payload to subsequently check the integrity of the persistently stored data.

Finally, first the payload stores <NUM> the PayloadlDCiphered and further encrypts and MAC <NUM> the sensitive data.

<FIG> depicts a preferred embodiment of a method <NUM> to retrieve persistently stored sensitive data by the payload <NUM> as, for instance, any of the methods <NUM>, <NUM> according to <FIG>.

Either at the instance of the payload or as part of a workflow, the party <NUM> sends <NUM> PayloadlDEncKey to the payload <NUM>. Then, firstly, the payload retrieves <NUM> the PayloadlDCiphered and further decrypts it using PayloadlDEncKey (= PayloadID). The payload will then send back to the party the PayloadID in clear.

As an alternative implementation (not shown), the payload <NUM> may retrieve PayloadlDCiphered and send it to the party which will decrypt it using PayloadlDEncKey thus also resulting on PayloadID in clear.

Referring back to <FIG>, once the party has the PayloadID in clear, it looks for any known PayloadID and, if found, retrieves <NUM> the associated KEY_INIT. Otherwise, if no PayloadID can be found, an error message may appear and the communications may end.

If KEY_INIT retrieval succeeds, the party sends <NUM> KEY_INIT to the payload which will pass it through KDF to generate <NUM> DataEncKey for decrypting the sealed data, and to generate <NUM> DatalntKey to check the integrity of the persistently stored data.

Therefore, the payload retrieves <NUM> the sealed data and, accordingly, use <NUM> DataEncKey and DatalntKey to decrypt and check the integrity of this sealed data.

In the following usage examples, the party will be embodied as a <NUM>rd party of trust for the owner <NUM>, i.e., a broker <NUM>.

These three examples rely on the authentication and sealing properties as described in connection with previous <FIG>. In particular, three scenarios (or workflows) are described hereinafter for managing traditional credentials which are injected in the payload <NUM> by the broker <NUM> so the payload is enabled to use traditional native cloud environment.

The skilled person shall understand that these scenarios, even described separately for illustrative purposes, may coexist for providing the payload with more than one functionality.

The first scenario in connection with <FIG> describes a situation when the owner needs to provide a certificate for a service (e.g., web-service) provided by the running payload. The inventions allows linking this certificate (usable by the web-service) to the attestation.

Namely, <FIG> depicts a schematic diagram of an embodiment of the method <NUM> to establish HTTPS connectivity for a user <NUM> of a web-service provided by the attested payload <NUM>.

In the following, it is assumed that the payload <NUM> and the broker <NUM> have already <NUM> established an authenticated secure channel backed by the attestation and the payload can store persistently the secret(s) injected by either the broker or the owner.

Then, the broker <NUM> signs <NUM> (e.g., using the generated KprivBroker) a certificate (e.g., a X. <NUM> certificate) private key, and sends the signed certificate to the payload <NUM>. Finally, the payload will store persistently <NUM> the signed certificate.

The certificate is configured to establish connectivity, such as HTTPS connectivity, to the web-service provided by the running payload.

Next, the stop and re-start of the payload is optional and the workflow may equally continue after step <NUM>. Assuming that the secure channel has been re-established, the payload <NUM> will obtain and send <NUM> its PayloadID (see, for instance, <FIG>) to the broker <NUM>, which will, in return, send back to the payload <NUM> the KEY_INIT. The payload <NUM> uses KEY_INIT this KEY_INIT to generate DataEncKey and DatalntKey for decrypting and check the integrity of the sealed data, respectively.

The payload <NUM> then configures <NUM> the web-service with the X. <NUM> certificate.

Thus, when the user tries to connect <NUM>, the payload signs a message <NUM> using its certificate which can be checked <NUM> by the user.

If the user verifies the X. <NUM> certificate used by the payload <NUM>, HTTPS connection is enabled for the web service running in the payload <NUM>. For instance, if the owner <NUM> provides services (e.g., API, REST API or web service) for different companies or applicants (i.e., users <NUM>) then these users need to be in the certificate chain of the broker.

In a second scenario, <FIG> depicts a schematic diagram of an embodiment of the method to setup a SSL connectivity between the owner and its attested payload. That is, this method <NUM> allows the owner <NUM> to directly manage its payload <NUM> using Secure Sockets Layer, SSL, connection.

As mentioned, the owner cannot inject certificates in the traditional manner (e.g., when starting the instance) since there no confidentiality and, thus, someone may stole them and masquerade your payload. Therefore, the idea underlying this embodiment is to leverage the secure channel backed by attestation so that the payload <NUM> and owner <NUM> uses the broker <NUM> to securely send the relevant certificates for configuring a Secure Shell, SSH, client-server system.

Again, it is assumed that the payload and broker have established a secure channel and performed the necessary actions for the payload to seal data <NUM>.

First, SSL key pairs are to be generated for the payload <NUM> and for the owner <NUM>. Throughout <FIG>, these key pairs will be generated by the broker <NUM> but, in other embodiments (not shown), some or all of these key pairs may be generated by the payload or owner and transferred through the broker to the other party.

In addition, in an embodiment (not shown), the generation of these SSL key pairs by the broker (or the owner for the owner key pair) can be done offline and, at least, the corresponding certificate sent to (or stored by) the owner.

Referring back to <FIG>, the broker <NUM> generates <NUM> SSL payload key pair: public key (SSLPubPayloadKey) and private key (SSLPrivPayloadKey) and sends <NUM> SSLPubPayloadKey to the owner <NUM> which uses it to configure <NUM> ~/. ssh/known_hosts. That is, the owner uses SSLPubPayloadKey to update its "known_hosts" configuration file and be able to automatically authenticate the payload when accessing it through an SSH session.

With the payload initiated, the broker <NUM> sends <NUM> SSLPubPayloadKey and SSLPrivPayloadKey to the payload which will store <NUM> them using data sealing.

Concerning the SSL owner key pair, the broker generates <NUM> it: public key (SSLPubOwnerKey) and private key (SSLPrivOwnerKey). Then, the broker sends <NUM> SSLPubOwnerKey and SSLPrivOwnerKey to the owner which uses them to configure <NUM> ~/. Finally, the owner also stores SSLPrivOwnerKey.

Then, the broker sends <NUM> SSLPubOwnerKey to the initiated payload which stores <NUM> it using sealing capabilities.

<FIG> depicts a schematic diagram of an embodiment of the method to establish SSL connectivity for the owner of the attested payload for its remote management.

It is assumed that, for instance, the payload has stopped and re-started so that the secure channel had to be re-established <NUM>. In addition, the data exchange protocol of <FIG> is also performed <NUM>, <NUM> and the payload is now able to retrieve its persistently stored data. The skilled person recognizes that the following steps may take place just after <FIG> without the need to close and re-established the secure channel.

The payload configures <NUM> ~/. ssh/*_key using SSLPrivPayloadKey, and configures <NUM> ~/. ssh/authorized_keys using SSLPubOwnerKey.

Therefore, when the owner tries to connect <NUM> using SSLPrivOwnerKey, the payload checks <NUM> whether SSLPubOwnerKey is in ~/. ssh/authorized_keys and, if so, authenticates it.

The payload sends back <NUM> to the owner a signed message using SSLPrivPayloadKey and the owner checks whether SSLPubPayloadKey is in ~/. ssh/known_hosts and, if so, authenticates the payload.

As a result, the configuration of this SSH client-server system entails a transparent SSL connection, e.g., HTTPS connection, for the owner to administrate its payload(s). In other words, once this configuration has been performed, there is nothing specific to the attestation or confidential computing. It allows a simple management where, for instance, every time the system re-starts, the payload restarts.

Finally, <FIG> depicts a schematic diagram of an embodiment of the method <NUM> to prove to a service provider that the payload has been attested for its further use. In particular, this method <NUM> allows the payload accessing services to address e.g., APIs.

Again, a secure channel has been established between payload <NUM> and broker <NUM> and, in addition, the payload has been provided with data sealing capabilities <NUM> according to <FIG>.

First, the owner defines <NUM> JSON Web Token, JWT-like token, policies to the broker, and configures <NUM> the service provider to accept the JWT from the broker. This may occur offline, i.e., without initiating the payload. Thus, the owner configures its service access to the service provide to establish also trust with the broker-generated JWT.

The broker then generates and signs <NUM> (e.g., using KprivBroker) a token according to policies setup by the owner. Then, once the payload is initiated, the broker sends <NUM> the signed token to the payload which, in turn, stores <NUM> it.

Again, it is described that, optionally, the payload has being stopped and re-started so that the secure channel had to be re-established <NUM> again.

Next, the payload configures <NUM> the application with JWT.

In use, the payload tries to connect <NUM> the service provider using JWT. Then, the service provider checks <NUM> the JWT (this process is out of the scope of this invention and hence it is not explained here) and, if verified, the service provider provides <NUM> the service to the payload.

The service provider is able to verify the signature of the payload because the broker has already signed the JWT with a standard format (e.g., the certificate of the broker can be retrieved for verifying the signature to accept or not the JWT).

Claim 1:
Computer-implemented method (<NUM>) to establish a secure channel between a party (<NUM>), for instance a broker, and a software payload (<NUM>) of an owner when running into a hardware-based trusted execution environment, HW TEE, at the instance of a cloud service provider, the method (<NUM>) comprising the following steps:
• sending (<NUM>), by the party (<NUM>), at least a nonce to the software payload (<NUM>);
• generating (<NUM>), by the software payload (<NUM>), a payload key pair: public key and private key;
• mixing (<NUM>), by the software payload (<NUM>), the payload public key with the nonce;
• computing (<NUM>), by the HW TEE, an attestation using at least this nonce mixed with the payload public key;
• sending (<NUM>), by the software payload (<NUM>), at least the attestation, and the payload public key to the party (<NUM>);
• verifying (<NUM>), by the party (<NUM>), the attestation using the sent nonce mixed with the received payload public key;
• generating (<NUM>), by the software payload (<NUM>) and the party (<NUM>), a session key between them; and
• establishing the secure channel between the party and the software payload (<NUM>) running into the HW TEE.