WO2023217383A1

WO2023217383A1 - Apparatus and method for efficient secure channel re-attestation without server-side state

Info

Publication number: WO2023217383A1
Application number: PCT/EP2022/063001
Authority: WO
Inventors: Arto NIEMI; Sandeep TAMRAKAR; Jan-Erik Ekberg; Pekka Laitinen; Vasile Adrian Bogdan POP
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2022-05-13
Filing date: 2022-05-13
Publication date: 2023-11-16

Abstract

Apparatuses and methods for improved handling of attested secure channels. An improved session ticket is exchanged between a trusted client and a server, the improved session ticket includes attestation evidence signed with a public key of the trusted client, an integrity protection signature over the attestation evidence generated with a server secret key, and secure channel session parameters encrypted with a server secret key. During session establishment, the trusted client sends attestation evidence to a server, the server validates the attestation evidence then generates and transmits the enhanced session ticket to the client. When resuming the secure channel, the client re-measures and re-validates the attestation evidence, then sends the enhanced session ticket back to the server. The server integrity checks the attestation evidence and trusting that the client has re-measured and re-validated the attention evidence, resumes the secure channel when the integrity check succeeds.

Description

APPARATUS AND METHOD FOR EFFICIENT SECURE CHANNEL REATTESTATION WITHOUT SERVER-SIDE STATE

TECHNICAL FIELD

The aspects of the disclosed embodiments relate generally to computer security and more particularly to secure communication channels between computing devices.

BACKGROUND

Secure channels, such as Transport Layer Security (TLS), are widely used in computer systems to provide communications security over computer networks. Attested secure channels add an additional layer of security by requiring a client program to send attestation evidence to the server during channel initiation. This allows a server to establish trust and ensure the client program has not been compromised.

Establishing a secure communication channel is computationally expensive. Thus, modern protocols include provisions for resuming a secure channel based on previously negotiated session parameters, thereby reducing the work required when resuming the channel. Secure channel protocols often require session parameters or other channel state to be stored on the server where it is later used when resuming a secure channel. When the number of client programs becomes large, storing state on the server consumes valuable computing resources.

Resuming an attested secure channel requires re-attestation, a process in which the client regenerates attestation evidence and sends it to the server for validation. While re-attestation ensures the client program has not become compromised after initial creation of the attested secure channel, the processing load on the server in increased.

Thus, there is a need for improved apparatus and methods capable of providing efficient reattestation and resumption of secure channels without the overhead associated with re-signing and re-validating the attestation evidence and storing channel state on the server. Accordingly, it would be desirable to provide methods and apparatus that addresses at least some of the problems described above. SUMMARY

The aspects of the disclosed embodiments are directed to improved apparatus and methods for providing efficient re-attestation and resumption of attested secure channels. The aspects of the disclosed embodiments provide appropriate re-attestation and resumption of attested secure channels while reducing processing costs and server-side state storage typically associated with re-attestation and resumption of attested secure channels.

According to a first aspect, the above and further implementations and advantages are obtained by a client apparatus. In one embodiment, the client apparatus includes a processor and a memory configured to provide a first execution environment and a trusted component. The processor is configured to execute a client program within the first execution environment, and the trusted component is configured to establish an attested secure channel with a server and resume the attested secure channel with the server. Establishing the attested secure channel with the server includes securely measuring the client program to produce one or more client program measurements, generating an attestation evidence based at least in part on the one or more client program measurements, transmitting the attestation evidence to the server and receiving a session ticket from the server. The attestation evidence includes one or more claims and a digital signature over the one or more claims generated with a private key of the trusted component. The session ticket comprises the attestation evidence, a digital signature over the attestation evidence generated with a first server secret key and session parameters encrypted with a second server secret key. Resuming the attested secure channel comprises re-measuring the client program to produce one or more re-measurements, validating the attestation evidence based at least in part on the one or more re-measurements; and transmitting the session ticket to the server. The trusted component is configured to be more secure than the first execution environment.

In a possible implementation form, the attestation evidence includes an assurance that the trusted component will re-measure the client program and validate the one or more claims when resuming the attested secure channel. Providing this assurance allows a server to avoid revalidating all the claims and rely on an integrity check of the attestation evidence.

In a possible implementation form, the trusted component is configured to independently derive a resumption pre-shared key, and the attestation evidence includes an assurance that the trusted component will restrict access to the resumption pre-shared key. Restricting access to or protecting the resumption pre-shared key is important to avoid a malicious actor from taking control of the secure session. Including an assurance in the attestation evidence allows a server to trust that the resumption pre-shared key has not been compromised.

In a possible implementation form, the session ticket includes the attestation evidence encrypted with a third server secret key. The trusted component is configured to store the attestation evidence and the corresponding session ticket. Encrypting the entire session ticket allows the improved attestation techniques disclosed herein to be easily configured to improve existing secure channel protocols.

In a possible implementation form, an endpoint of the attested secure channel is provided by one of the trusted components and the client program. The trusted component acts as the endpoint of the underlying secure session and additional flexibility is added by allowing the transfer control protocol (TCP) endpoint to be provided by either the trusted component or the client program.

In a possible implementation form, the processor is configured to receive one or more requested claims from the server and generate the one or more claims based on the one or more requested claims. Allowing the server to specify information to be included in the claims provides greater control by and improves trust by a server.

According to a second aspect, the above and further implementations and advantages are obtained by a server apparatus. In one embodiment the server apparatus includes a processor and a memory. The processor is configured to establish an attested secure channel with a client and resume the attested secure channel. Establishing the attested secure channel with the client includes receiving attestation evidence from the client, validating an integrity of the attestation evidence based on a public key of the client, validating one or more claims, generating a session ticket and transmitting the session ticket to the client. The attestation evidence includes one or more claims and a digital signature over the one or more claims generated with a private key of the client. The session ticket includes the attestation evidence, a digital signature over the attestation evidence generated with a first server secret key and session parameters encrypted with a second server secret key. Resuming the attested secure channel includes receiving the session ticket from the client, validating an integrity of the attestation evidence based on the signature over the attestation evidence and the first server secret key and resuming the attested secure channel based on the session parameters.

In a possible implementation form, the session ticket comprises a resumption pre-shared key, and the attestation evidence provides an assurance the client will independently derive and restrict access to the resumption pre-shared key. The trust provided by this assurance allows a server to trust that the resumption pre-shared key has not been compromised.

In a possible implementation form, the attestation evidence provides an assurance that the client will re-measure and re-validate the one or more claims prior to resuming the attested secure channel. This assurance allows the server to use a simple integrity check to validate the attestation evidence instead of a more in-depth check of all the claim values.

In a possible implementation form of the server apparatus, the session ticket includes a key name, an initial value vector, attestation evidence and an encrypted session state. The encrypted session state is generated based on the server secret key and a tag. The tag is configured to protect an integrity of the attestation evidence. A ticket having this format allows the improved attestation embodiments disclosed herein to be easily configured to improve existing secure channel protocols.

In a possible implementation form, the first server secret key is different than the second server secret key. The first server secret key is diversified based on the second server secret key and a random salt. The session parameters comprise the random salt. Deriving the first server secret key in this fashion reduces the number of keys maintained by the server while still limiting exposure of the server secret key.

According to a third aspect, the above and further implementations and advantages are obtained by a method. In one embodiment the method includes establishing an attested secure channel between a client program and a server and resuming the attested secure channel. Establishing the attested secure channel includes securely measuring the client program to produce one or more client program measurements, generating attestation evidence based at least in part on the one or more client program measurements, transmitting the attestation evidence to the server and receiving a session ticket from the server. The attestation evidence includes one or more claims and a digital signature over the one or more claims generated with a private key of a trusted component. The session ticket includes the attestation evidence, a digital signature over the attestation evidence generated with a first server secret key and session parameters encrypted with a second server secret key. Resuming the attested secure channel includes remeasuring the client program to generate one or more re-measurements, re-validating the attestation evidence based at least in part on the one or more re-measurements, transmitting the session ticket to the server and resuming the secure channel based on the session ticket.

According to a fourth aspect, the above and further implementations and advantages are obtained by a method. In one embodiment the method includes establishing an attested secure channel with a client and resuming the attested secure channel. Establishing the attested secure channel with the client includes receiving attestation evidence from the client, validating an integrity of the attestation evidence based on a public key of the client, validating the one or more claims, generating a session ticket and transmitting the session ticket to the client. Resuming the attested secure channel includes receiving the session ticket, validating an integrity of the attestation evidence based on a first server secret key and resuming the attested secure channel based on the session parameters. The attestation evidence includes one or more claims and a digital signature over the one or more claims generated with a private key associated with the client. The session ticket includes the attestation evidence, a digital signature over the attestation evidence generated with the first server secret key and session parameters encrypted with a second server secret key.

In a possible implementation form the attestation evidence provides an assurance the client will re-measure and re-validate the one or more claims prior to resuming the attested secure channel. This assurance allows the server to us a simple integrity check to validate the attestation evidence instead of a more in-depth check of all the claim values.

According to a fifth aspect, the above and further implementations and advantages are obtained by a computer program product. In one embodiment, the computer program product includes a non-transitory computer readable media having program instructions stored thereon. Execution of the instructions by a processor causes the processor to perform the method according to the implementation forms described herein.

These and other aspects, implementation forms, and advantages of the exemplary embodiments will become apparent from the embodiments described herein considered in conjunction with the accompanying drawings. It is to be understood, however, that the description and drawings are designed solely for purposes of illustration and not as a definition of the limits of the disclosed invention, for which reference should be made to the appended claims. Additional aspects and advantages of the invention will be set forth in the description that follows, and in part will be obvious from the description, or may be learned by practice of the invention. Moreover, the aspects and advantages of the invention may be realized and obtained by means of the instrumentalities and combinations particularly pointed out in the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following detailed portion of the present disclosure, the invention will be explained in more detail with reference to the example embodiments shown in the drawings, in which like references indicate like elements and:

Figure 1 illustrates a block diagram of an exemplary client apparatus incorporating aspects of the disclosed embodiments;

Figure 2 illustrates a block diagram of an exemplary server apparatus incorporating aspects of the disclosed embodiments;

Figure 3 illustrates a pictorial diagram of an exemplary computer network incorporating aspects of the disclosed embodiments;

Figure 4 illustrates a message sequence chart depicting an improved secure channel protocol incorporating aspects of the disclosed embodiments;

Figure 5 illustrates a flow diagram of an exemplary method for establishing and resuming the client side of an attested secure channel incorporating aspects of the disclosed embodiments;

Figure 6 illustrates a flow diagram of an exemplary method for establishing and resuming the server side of an attested secure channel incorporating aspects of the disclosed embodiments.

DETAILED DESCRIPTION OF THE DISCLOSED EMBODIMENTS

Referring to Figure 1, there can be seen a block diagram of an exemplary apparatus 100 incorporating aspects of the disclosed embodiments. For the purposes of the description herein, the apparatus 100 can also be referred to as a client apparatus. The exemplary apparatus 100 of the disclosed embodiments is directed to a computing apparatus having improved methods and apparatus for resuming attested secure channels, such as transport layer security (TLS) compliant attested secure channels and other appropriate types of attested secure channels. The aspects of the disclosed embodiments reduce processing requirements and eliminate the need to store session state on the server-side when supporting resumption of an attested secure channel. These improvements and advantages are obtained in part through the generation and exchange of an improved session ticket.

As illustrated in Figure 1, in one embodiment, the client apparatus 100 includes a processor 102 and a memory 104. The processor 102 is communicably coupled to the memory 104. The processor 102 and memory 104 of the client apparatus 100 are configured to provide a first execution environment 108 and a trusted component 106. The processor is 102 configured to execute a client program 110 within the first execution environment 106. The trusted component 106 is configured to establish an attested secure channel with a server and resume 140 the attested secure channel with the server.

In one embodiment, establishing the attested secure channel with the server includes securely measuring the client program 110 to produce one or more client program measurements and generating attestation evidence based at least in part on the one or more client program measurements. The attestation evidence includes one or more claims 162 and a digital signature 164 over the one or more claims 162 generated with a private key 112 of the trusted component 106.

The client program 110 is configured to transmit 128 the attestation evidence 160 to the server and receive 130 a session ticket 170 from the server. In one embodiment, the session ticket 170 includes the attestation evidence 160, a digital signature 166 over the attestation evidence 160 generated with a first server secret key and session parameters 170 encrypted with a second server secret key.

In one embodiment, resuming 140 the attested secure channel includes re-measuring 142 the client program to produce one or more re-measurements, validating 144 the attestation evidence 160 based at least in part on the one or more re-measurements and transmitting 146 the session ticket 170 to the server. The trusted component 106 is configured to be more secure than the first execution environment 108.

As used herein the term transport layer security (TLS) refers to any of the various industry standard transport layer security protocols such as TLS version 1.2, or TLS version 1.3 as published by the IETF®. It should be understood that TLS is referenced herein only as an aid understanding and should not be construed as limiting in any way. It will be appreciated that the disclosed embodiments may be advantageously employed to provide improved attestation within any appropriate secure channel protocol without straying from the spirit and scope of the present disclosure.

In one embodiment, the processor 102 can be any suitable processor or processing device that may be advantageously employed in the client apparatus 100. For example, the processor 102 can include one or more of a high-performance multi-core computer processing device such as those used in large cloud computing data centers, a multi-core or single core microprocessor such as those used in workstations and laptop computers, a processing device embedded in a system such as a system on a chip (SoC), or any suitable or specialized processing device such as those used in mobile communications devices, telecommunications equipment, and smart devices adapted for the internet of things (loT).

The memory 104 can comprise any desired type of computer accessible memory. In one embodiment, the memory 104 can include random-access memory (RAM), read-only memory (ROM), or other suitable types of volatile and non-volatile memory. When desired the memory 104 may include various types of physically secure memory, such as one-time programmable memory, eFuse memory, and hardware security modules (HSM).

Although not specifically depicted in the apparatus 100 illustrated in Figure 1, it should be understood that the apparatus 100 supports computer networking capabilities including both wired networks such as Ethernet, as well as wireless networks such as Wi-Fi, WiMAX, or cellular networks. The apparatus 100 is configured to send and receive data or messages over one or more of these computer networks. As used herein the terms “transmit” or “send” generally refer to transmitting data or messages over a computer network to a remote entity. The term “receive” refers to receiving data or messages over a computer network from a remote entity. A remote entity may refer to a separate physical computing device or it may refer to a separate processing environment running on the same or different physical device.

As illustrated in Figure 1, one portion 152 of the memory is associated with the first execution environment 108 and may be configured to execute less trusted applications such as the client program 110. In one embodiment the first execution environment 108 may be a rich execution environment (REE) providing a fully featured operating system, such as Linux, and is configured to support highly functional and user-friendly applications. Alternatively, the first execution environment may be a more secure environment such as a secure execution environment (SEE) that is more secure than a REE but less trusted than services, such as the attestation service 154 and secure channel service 156, running within the trusted component 106.

In one embodiment, the memory 104 can include a memory portion 150. The memory portion is protected and only accessible by services executing within the trusted component 106. The attestation service 154 and secure channel service 156, which are used to provide support for attested secure channels, are examples of services protected by the trusted component 106 environment. This memory portion 150 of the memory 104, also generally referred to as memory, is configured to support a highly secure operating environment, which may run smaller and less vulnerable code modules, and is configured to protect sensitive applications and data including confidential key material. Importantly, the memory portionl50, embedded within the more secure trusted component 106 environment, is isolated and cannot be directly accessed or modified by applications executing in the less trusted first execution environment 108 or any process executing outside the trusted component 106. In certain embodiments the trusted component 106 may include hardware-based security features to protect confidential data and programs stored within the trusted component 106.

The client apparatus 100 is configured to execute the client program 110 within a first execution environment which is a less trusted environment than the execution environment in which the attestation service 154 and the secure channel service 156 are executing. The first execution environment 108 may be configured as a REE or a SEE and may be less trusted from the perspective of a verifier than services 154,156 executing within the trusted component 106.

A verifier, such as a server with which an attested secure channel is being established, should trust information signed by or attested to by the services 154, 156 running in the trusted component 106 more than it trusts data originating from the client program 110. This higher level of trust attributed to the trusted component 106 by the verifier as opposed to the lower level of trust attributed to the client program 110 by the verifier is generally described as the trusted component 106 is configured to be more secure than the first execution environment 108. To more clearly understand the additional trust and more secure environment it is helpful to consider some concrete examples. It should be understood that the following exemplary embodiment are presented as an aid to understanding and should not be construed as limiting the disclosed embodiments in any way.

It will be appreciated that the above-described embodiments of a client apparatus 100 may be advantageously employed within an apparatus based on standards developed by the GLOBALPLATFORM® organization (GP). In one embodiment, the trusted component 106 may be implemented with a GP-TEE running a secure operating system, such as iTrustee, a secure operating system developed by HUAWEI® in a secure world of a TrustZone enabled device. The client program 110 may execute as a GP trusted application (TA) which is also running in a secure world, but running with less privileges than the services 154, 156 of the trusted component 106. In this embodiment the secure channel service 156 may be invoked through an application programming interface (API) such as the GP Socket API Annex C.

Alternatively, embodiments of the above-described client apparatus 100 may be implemented by configuring the trusted component 106 as a secure enclave runtime system or secure enclave manager, and the client program 110 may be implemented as a secure enclave program running in a secure enclave. Examples of suitable enclave managers include the Software Guard Extension (SGX) developed by INTEL® Corporation, the secure encrypted virtualization (SEV) architecture developed by Advanced Micro Devices Inc., and the Realm Management Monitor (RMM) in the confidential compute architecture (CCA) developed by Arm Limited.

Certain embodiments of the client apparatus 100 may be based on a trusted component 106 configured as a trusted hypervisor executing at a higher privilege level, such as EL2 on an Advanced Risk Machine architecture device. The client program 110 may be a program running at a lower privilege level, such as ELL When desired, the client program 110 may be executed within a REE and the trusted component 106 may be implemented as a secure enclave.

Returning now to our description of the client apparatus 100, when the client program 110 needs to exchange sensitive information with an external entity, such with as a server running a banking application, services provided by the trusted component 106 may be employed to establish 120 an attested secure channel, When a prior session needs to be resumed, the trusted component 106 may resume 140 the attested secure channel.

Attestation is particularly important to sensitive services, such as banking applications, and may be required when establishing a secure channel with a client program 110. Attestation provides a way for the client program 110 to prove its identity and prove it is operating in conjunction with a known trusted component 106.

The trusted component 106 offers a secure channel service 156, such as a TLS service exposed through a socket API, for use by the client program 110. When the client program 110 needs to establish a secure channel with a server, the client program 110 sends a request to the trusted component 106. The request may include a name or other indication of the server to which the secure channel is required.

The trusted component 106 measures 124 the client program 110 and generates 126 one or more program measurements. In one embodiment, the trusted component 106 measures 124 the client program 110 through an attestation service 154 configured to securely measure 122 the client program 110. These program measurements may include any desired information or properties derived from the client program 110. For example, one useful program measurement may be formed by computing a hash or cryptographic hash of a memory image of the client program 110. A measurement based on a cryptographic hash of a program’s memory image is sometimes referred to as the identity of the program.

The trusted component 106 generates 126 attestation evidence 160 based at least in part on the one or more program measurements. The attestation evidence 160 is a verifiable statement in which the trusted component 106 vouches for or attests to, one or more properties of the client program 110, observable by the trusted component 106 at the time the attestation evidence 160 is being generated. Such properties, referred to herein as claims 162, may include any information useful for a relying party when evaluating the trustworthiness of the client program 110. Suitable claims may include one or more of a cryptographic hash of the client program’s 110 program code or of its memory contents; the type, version, and state of the operating system or other client apparatus state under which the client program 110 is running; as well as any other information useful for establishing trust of the client program 110.

A digital signature 164 over the one or more claims 162 is generated by the trusted component 106 based on a trusted component private key 112. the trusted component private key 112 is securely stored within and known only to the trusted component 106. The resulting digital signature 164, referred to herein as a digital signature over the claims, is appended to the claims 162 to form the attestation evidence 160. A corresponding public key 114 is publicly distributed, for example, in an identity certificate. Integrity and authenticity of the attestation evidence 160 can be verified by anyone with access to the identity certificate of the trusted component 106 which has the public key 114 embedded therein.

As used herein, a digital signature over a data block generated with a key refers to the process of signing the data block using a particular key. When signing or creating a digital signature, a digest is created by computing a cryptographic hash function of the data block. The digest is then encrypted with the key and the resulting cyphertext becomes the digital signature.

The attestation evidence 160 is transmitted 128 by the apparatus 100 to a server with which a secure channel is being negotiated. As will be discussed in more detail below, the server validates the attestation evidence 160 and, once the attestation evidence is validated, proceeds to negotiate session parameters and generate a session ticket 170.

As used herein the term "server" refers to an entity that offers a secure channel endpoint and listens for secure channel request messages coming from a client. As used herein the term "client" refers to an entity that initiates establishment of a secure channel by sending a secure channel request message to a server. A client initiates a secure channel handshake by sending a request to the server. The server listens for a request from a client and responds with the next message in the handshake. In the embodiment illustrated in Figure 1, the client apparatus 100 operates as a client and initiates a secure channel connection with a server. The server apparatus 200 illustrated in Figure 2 operates as a server by listening for and responding to requests from a client. It will be appreciated that either or both apparatus 100 or apparatus 200 may operate as both a client for one secure channel while simultaneously operating as a server for another secure channel and may support any desired number of client and server connections in parallel.

The trusted component 106 receives 130 a session ticket 170 from the server where the session ticket 170 includes two parts 172, 174. Part one 172 includes the attestation evidence 160, which is the same attestation evidence 160 transmitted to the server earlier in the handshake, along with a digital signature 166 over the attestation evidence 160 generated with a first server secret key. The digital signature 166 over the attestation evidence 160 allows the server to verify, at any later time, the integrity of the attestation evidence 160.

Part two 174 of the session ticket 170 includes secure session parameters 176 encrypted with a second server secret key. The session parameters 176 include parameters necessary for a server to resume the secure channel with the trusted component 106 such as session resumption keying material and other parameters related to a TLS session. These session parameters 176 are encrypted with a second server secret key thereby preventing any entity other than the server from reading or using them.

When desired the first server secret key may be the same as the second server secret key. Using the same key for both the first and second server secret keys reduces the number keys maintained by a server. Alternatively, the first server secret key may be different than the second server secret key. Using different keys can reduce the exposure of the keys and improve security.

The session ticket 170 is stored within the apparatus 100 where it will be conditionally available for use when resuming the attested secure channel. The session ticket 170 need not be stored securely within the apparatus 100, however access control should be implemented to ensure the client program is allowed to use the session ticket 170 only when the client program measurements still match with the attestation evidence.

In large network environments it is common to have a large number of client programs continually connecting and re-connecting to a service. Because establishing a secure channel can be computationally expensive, many conventional protocols provide an abbreviated handshake to resume or re-establish a previously established channel. It can often be advantageous to include attestation during both the establishment and resumption of a secure channel.

When resuming 140 an attested secure channel the trusted component 106 re-measures 142 the client program 110 to generate one or more re-measurements. These one or more remeasurements are configured to allow re-generation of the claims 162 included in the original attestation evidence 160.

The trusted component 106 re-validates 144 the attestation evidence 160 based on the one or more re-measurements. Re-validation of the attestation evidence 160 may be accomplished in any appropriate manner such as by re-generating the attestation evidence 160 based on the one or more re-measurements and comparing the re-generated attestation evidence with the original attestation evidence 160 to ensure no changes have occurred. As will be discussed further below, ensuring the re-generated attestation evidence matches the original attestation evidence 160 allows the server to re-verify the original attestation evidence 160 simply by validating the digital signature 166 over the attestation evidence 160 included in the session ticket 170, thereby avoiding the extra work necessary to re-validate each and every claim. It will be appreciated that re-validation of the server’s digital signature 166 over the attestation evidence 160 included in the session ticket 170 is sufficient, and there is no need to re-validate the digital signature 164 over the claims 162 added to the original attestation evidence 160 by the trusted component 106.

In the event that the re-generated attestation evidence does not match the original attestation evidence 160, the trusted component 106 terminates the resumption process 140 and does not allow the session parameters 176 to be used by the client program 110 to resume the secure session.

When the trusted component 106 determines that the original attestation evidence 160 has not changed, i.e., the original attestation evidence 160 is still valid, the handshake continues and the session ticket 170 is transmitted 146 to the server.

Once a server establishes trust in the trusted component 106, the server can rely on the trusted component 106 to re-measure and re-validate the original attestation evidence 160, thus there is no need for the server to also perform a re-validation. Based on this trust, the server may do a simple integrity check based on the digital signature 166 over the attestation evidence 160 and accept the attestation evidence 160 as valid. To facilitate this simplification, the attestation evidence 160 includes an indication that the trusted component 106 has successfully remeasured and re-validated the attestation evidence. The assurance can be implicit based on validation of the digital signature 164 with the public key 114 of the trusted component 106, or when desired may be explicit by including a value in the claims 162.

In certain embodiments the session ticket 170 includes a resumption pre-shared key (PSK). The trusted component 106 is configured to independently derive and, when desired, securely store the resumption PSK. Importantly, the trusted component 106 is configured to protect confidentiality of the resumption PSK and not share it with the client program 110 or any entity external to the trusted component 106.

The trusted component 106 may associate the resumption PSK with the session ticket 170 and provide the client program 110 with a handle to use when referencing the session ticket 170 during session resumption. Similar to the assurance described above, the assurance that the trusted component 106 will protect the resumption PSK may be implicitly included in the attestation evidence 160 by virtue of the identity of the trusted component 106, or the assurance may be explicitly included as an additional claim 162. It will be appreciated that in certain embodiments the resumption PSK may be advantageously replaced with any suitable session resumption keying material as desired.

In one embodiment, an encrypted session ticket is generated by encrypting the session ticket 170, including the attestation evidence 160, the digital signature 166 over the attestation evidence 160, and the session parameters 172, using a third server secret key. This prevents any part of the encrypted session ticket from being read or used by any entity other than the server. The trusted component 106 is configured to store a copy of the attestation evidence 160 along with the session ticket 170 and the trusted component 106 does not associate a resumption PSK with the session ticket 170. The session ticket 170 is securely stored by the trusted component 106, with for example the same access control policy as would be used in embodiments that securely store the resumption PSK.

In this embodiment the server requires only a single secret key, namely the third server secret key, for encryption and signing. Successful decryption of the session ticket 170 allows the server to regard the attestation evidence 160 as valid and the session may be resumed after decryption has succeeded. Encryption of the entire session ticket 170 allows the improved attestation mechanisms disclosed herein to be easily configured to improve existing secure channel protocols.

During session resumption 140 the trusted component 106 validates the client program 110 based on the stored copy of the attestation evidence 160. The encrypted session ticket is sent to the server.

In embodiments where the entire session ticket 170 is encrypted, the use of authenticated encryption, such as Advanced Encryption Standard Galois Counter Mode (AES-GCM) based encryption, may be required to provide a desirable level of security. The server can then regard the attestation evidence 160 as valid when decryption is successful. Encryption of the full session ticket 170 may be advantageous when employing the disclosed embodiments to improve older transport layer security (TLS) type secure channel protocols such as TLS 1.2, however it is also possible to improve newer protocols, such as TLS 1.3, using this approach.

In one embodiment, the processor 102 is configured to receive one or more claim requests from the server and to generate the one or more claims 162 based at least in part on the one or more claim requests. Allowing the server to specify desired claim values can often provide additional flexibility and security. For example, a banking service might discover vulnerabilities in certain client applications when running on certain operating system versions. Specifying the information to be included in claims provides a server with a higher level of trust in a client program 110.

Referring now to Figure 2, there can be seen a block diagram of an exemplary server apparatus 200 incorporating aspects of the disclosed embodiments. The server apparatus 200 of the disclosed embodiments is configured to efficiently resume an attested secure channel without storing session state on the server and without the need to fully re- validate attestation evidence when resuming the attested secure channel.

The server apparatus 200 generally includes a processor 202 communicatively coupled to a memory 204, where the processor 202 and memory 204 are configured to provide secure channel endpoints configured to support the establishment of attested secure channels. Any suitable processor or processing device 202 may be advantageously employed in the server apparatus 200. The processor 202 may include, for example, a high-performance multi-core computer processing device, such as those used in large cloud computing data centers, a multicore or single core microprocessors such as those used in workstations and laptop computers, or a processing device embedded in a system such as a system on a chip (SoC), or any suitable or specialized processing device such as those used in mobile communications devices, telecommunications equipment, and smart devices.

Any desired type of computer memory may be beneficially employed for the memory 204. Such as random access memory (RAM), read only memory (ROM), and other types of volatile and non-volatile memory including non-transitory storage media, may be advantageously incorporated into the memory 204. When desired the memory 204 may include various types of physically secure memory, such as one-time programmable memory, eFuse type memory, and hardware security modules (HSM).

Although not specifically depicted in the diagram illustrated in Figure 2, it should be understood that the server apparatus 200 is configured to send and receive data and messages over computer networks including any suitable wired networks such as Ethernet, and when desired any suitable wireless networks such as Wi-Fi, WiMAX, and cellular networks.

In operation the processor 202 is configured to manage attested secure channels with a client. The server apparatus 200 is configured to act as a server listening for attested secure channel requests from a client. The server apparatus 200 will establish 220 and resume 240 an attested secure channel in response to requests received from a client.

When establishing an attested secure channel 220, the processor 202 is configured to receive 222 attestation evidence 160 from a client. The received attestation evidence 160 comprises one or more claims 162 and a digital signature 164 over the one or more claims generated with a private key 112 of a client. The attestation evidence 160 illustrated in Figure 2 is similar to the attestation evidence 160 described above and with respect to Figure 1.

The processor 202 validates 224 an integrity of the attestation evidence 160 based on a public key of the client. The public key of the client may for example be a public key associated with a trusted component executing within a client apparatus, such as the public key 114 associated with the trusted component 106 described above. In this example, the public key 114 corresponds to a private key 112 confidentially stored in the trusted component 106 and used to generate the digital signature 164.

The processor 202 validates 226 the one or more claims 162. Validation 226 allows the server apparatus 200 to determine whether it is safe to establish a secure channel with the client. When validation fails, the processor 202 terminates the handshake and a secure channel is not created. When validation is successful, the processor 202 continues the handshake to set up a secure channel with the client.

The processor generates 228 a session ticket 170, where the session ticket 170 includes the attestation evidence 160, a digital signature 166 over the attestation evidence 160 generated with a first server secret key 206, and session parameters 176 encrypted with a second server secret key 208. The first server secret key 206 and the second server secret key 208 are securely stored within the server apparatus 200 and kept confidential by the server apparatus 200.

In certain embodiments it may be advantageous to generate the digital signature 160 over the attestation evidence 160 using a symmetric-key cryptography, such as HMAC or authenticated encryption. Use of symmetric-key cryptography makes verification of the signature very efficient.

As described above the first server secret key 206 and the second server secret key 208 may be the same or different as desired. Encrypting the session parameters 176 with the second server secret key 208 ensures the session parameters 176 can be read only by the server apparatus 200 and cannot be accessed by any other party.

The processor 202 transmits 230 the session ticket 170 to the client. During transmission the entire session ticket 170 is encrypted using the secure channel handshake keys. Since secure channel handshake keys are shared by both the server apparatus 200 and the client, allowing both parties to read the claims 162 portion of the session ticket 170 but only the server is able to read the encrypted session parameters 176.

At a future time, the client may wish to resume communication over the attested secure channel. Beneficially, resuming a previously established attested secure channel is achieved using a shortened handshake based on re-use of previously negotiated session parameters. When resuming 240 an attested secure channel the processor 202 is configured to receive 242 the session ticket 170 from the client. The received session ticket 170 includes all information necessary for attestation along with all session parameters 172 necessary to resume the secure channel, thereby avoiding the need to store and retrieve session state on the server.

The processor 202 validates 244 an integrity of the attestation evidence 160 included in the session ticket 170. The attestation evidence 160 may be validated by verifying the integrity of the attestation evidence 160 based on the included digital signature 166 over the attestation evidence 160. There is no need for any further validation because the server 200, by virtue of the digital signature 164 over the claims 162 is able to trust that a known trusted component of the client has re-measured and re-validated the claims 162 prior to transmitting the session ticket 170.

When the integrity check fails, the server terminates secure channel resumption 240, and when the integrity check succeeds the processor 202 decrypts the session parameters 176 based on the second server secret key 208 and resumes 246 the secure channel based on the decryption of the session parameters 176.

As discussed above, the attestation evidence 160 includes an assurance that a trusted component has re-measured and re-validated the attestation evidence 160 prior to sending the session ticket 170 to the server. This assurance is included either implicitly or explicitly in the attestation evidence 160. In one embodiment the session ticket 170 may be encoded based on a data structure. An example of a suitable data structure may be defined using standard TLS notation as follows: struct { opaque key_name [ 16 ] ; opaque iv [ 16 ] ; opaque attestation_evidence_aad<0 . . 2 ^A 16- 1>; / / Part 1 (AAD) opaque encrypted_state<0 . . 2 ^A 16- 1>; / / Part 2 (Encrypted) opaque tag [ 16 ] ; } ticket ; where struct indicates a data structure, ticket is the data structure name, and opaque is a known TLS data format. Key_name[16] provides a 16 byte name or identifier for the encryption key being used, iv[16] provides a 16 byte initial value, attestion evidence aad<0..2^A16> provides up to 2¹⁶-1 bytes of attestation evidence such as attestation evidence 160 described above, and encrypted_state provides up to 2¹⁶-1 bytes of session state 170 encrypted with a server secret key.

In one embodiment the resumption PSK associated with the secure channel may be diversified based on the claims 162. In this embodiment the resumption PSK is not used directly. Instead, the PSK value used for resumption of the attested secure channel, referred to as the actual PSK, is computed by applying a key derivation function (KDF) to a combination of the resumption PSK value and the claims 162. The server stores the actual PSK in the session encrypted parameters 172 portion of the session ticket 170 where it is accessible only by the server. The trusted component 106 stores only the resumption PSK within the client.

When resuming 140 the secure channel, the trusted component 106 computes the actual PSK based on the claims 162 and the resumption PSK. The benefit of this embodiment is that there is no need to inspect the original attestation evidence 160 or to store them within the client apparatus, such as the client apparatus 100 described above and with reference to Figure 1. If the re-generated claims are different, the actual PSK generated by the client will fail. Generating an actual PSK based on the resumption PSK and the claims can improve channel resumption and reduce storage requirements in the trusted component 106.

In one embodiment the server apparatus 200 is configured to use a separate integrity-protection key when generating the digital signature 166 over the attestation evidence 160. The integrity- protection key is generated based on the server secret key 206 and a random salt. The integrityprotection key is then stored in the session parameters 176 which are encrypted based on the server secret key. The benefit of this embodiment is that it requires the server to store only a single long-term key even when a non-AEAD (Authenticated Encryption with Associated Data) cipher is used for ticket protection. This embodiment also reduces vulnerabilities to certain attacks.

Figure 3 illustrates a pictorial diagram of an exemplary computer network 300 incorporating aspects of the disclosed embodiments. As an aid to understanding, it is instructive to consider a network 300 of computing apparatuses in which the disclosed embodiments can be advantageously employed. The illustrated computer network 300 includes a plurality of client apparatuses 302, 318. . .320 and a server apparatus 322 communicatively coupled via a plurality of attested secure channels 326, 328. . . 330. Although only three client apparatus are shown in Figure 3, the aspects of the disclosed embodiments are not so limited. In alternate embodiments, any suitable number of client apparatus can be included, other than including three.

The illustrated computer network 300 employs a server apparatus 322 configured to provide a secure channel endpoint 324 adapted to support a plurality of attested secure channels 326,

328. . . 330. These attested secure channels 326, 328..330, may be based on any desired type of secure channel such as TLS version 1.2, TLS version 1.3, or other appropriate secure channel protocols that may be configured to exchange signed attestation evidence and an encrypted session ticket. The apparatus 200 described above and with reference to Figure 2 is appropriate for use as the server apparatus 322 in the exemplary network 300.

In the exemplary computer network 300, multiple client programs, such as client program 312, make multiple secure connections 326, 328...330 with the server endpoint 324. In the illustrated embodiment the exemplary client apparatus 302 is similar to the client apparatus 100 described above, where the client apparatus 302 includes a first execution environment 306 configured to execute one or more client programs 312, 314. . .316, and a trusted component 304 configured to provide attestation services 308 and secure channel services 310 to the client programs 312,

314. ..316. The client apparatuses 318 and 320 depicted in Figure 3 are similar to the exemplary client apparatus 302 and illustrate an exemplary computer network 300 including multiple client apparatuses executing multiple client programs. To provide services to users, the client programs 312, 314. ..316 may frequently need to connect to the server 322. Security considerations may require these connections take place over a trusted channel. For example, a banking client program may need to contact a server 322 to perform a bank transfer, and security considerations require that the transfer request be protected against eavesdropping, modification, replay, etc., that the transfer request must originate from a valid and authentic client program and that the client program has not been compromised by an attacker. The first requirement may be satisfied using a secure channel protocol such as TLS. Because the number of client programs is often large and connections need to be established frequently, a protocol that supports session resumption, such as TLS, may be employed to optimize use of computing and network resources. The second requirement may be satisfied through the use of remote attestation.

Figure 4 illustrates a message sequence chart 400 depicting an improved secure channel protocol incorporating aspects of the disclosed embodiments. The message sequence chart 400 depicts benefits achieved when the improved attestation handshakes disclosed herein are applied to a TLS type secure channel protocol. The illustrated attested secure channel handshake results in improved session resumption and reduced server-side resource usage. Those skilled in the art will readily recognize that the disclosed embodiments are not limited to TLS type protocols and may be advantageously employed to improve any suitable secure channel or attested secure channel protocol without straying from the spirit and scope of the disclosed embodiments.

In the illustrated message sequence chart 400, the trusted component 402 offers a TLS service to the client program 404, through for example, an API. The client program 404 is requests the trusted component 402 to negotiate a TLS session and send or receive data over the session. The trusted component 402 does all the security critical processing mandated by the TLS protocol, including record encryption and decryption, key exchange, key derivation, etc. The client program 404 gets no access to the TLS session keys or other secret keying material associated with the TLS handshake or session. The trusted component 402 acts as the endpoint of the TLS connection, but the transfer control protocol (TCP) endpoint may be provided by either the trusted component 402 or the client program.

With the illustrated message sequence 400, an initial session establishment handshake 408 establishes trust, exchanges keys, and negotiates session parameters. Once a session has been established it can be resumed using a resumption handshake 422 configured to re-establish trust by exchanging attestation evidence. The secure channel is then resumed based on the session parameters negotiated during the session establishment handshake 408.

The session establishment handshake 408 begins when the client program 404 contacts 410 the trusted component 402 and includes a server identity to establish a connection with. The trusted component 402 then sends 412 a client hello message to the server 406. The trusted component 402 measures 416 the client program 404 and generates attestation evidence, such as the attestation evidence 160 described above, containing claims corresponding to the program measurements signed with a private key associated with the trusted component 402.

The claims to be included in the attestation evidence may be selected in several ways. The client program 406 may indicate the claims to be included, or the server may provide a list of requested claims in the server hello message 414. In one embodiment, the server 406 may have a policy that allows connections only from client programs 404 running on specific, certified hardware and operating system. To facilitate this, the server may require hardware and software version numbers to be included as attestation claims. Alternatively, the trusted component 402 may select attestation claims independently.

The completed attestation evidence 430 is sent 418 to the server 406 in the TLS certificate handshake message where the server 406 verifies 434 the attestation evidence and attestation evidence signature. The attestation evidence signature may be validated using a trusted public key or a trusted root certificate. Claim validation may be done by checking that the claim values match an attestation policy of the server or that they match pre-determined trusted reference values.

The server 406 proceeds by generating 436 a session ticket. Generation 436 may include derivation of a resumption PSK value based on previously transmitted handshake messages and derived secret values. The session ticket 432 incorporates two parts. Part 1 stores the validated attestation evidence along with a digital signature over the attestation evidence generated with a server secret key. Part 2 of the session ticket 432 stores the secure session parameters, such as TLS session parameters, including the resumption PSK value, and cryptographic parameters such as cipher suite, signature and key exchange algorithms, the server’s name indication, etc. Part 2 of the session ticket 432 is encrypted using a server secret key thereby protecting the session parameters from access by any party other than the server. The digital signature over the attestation evidence included in part 1 of the session ticket 432 provides integrity protection to ensure that the attestation evidence transmitted by the trusted component 402 during session resumption 422 is the same attestation evidence provided during session establishment handshake 408. Encrypting part 2 of the session ticket 432 with the server secret key ensures that part 2, which includes the parameters necessary to resume the secure session, cannot be read by any party other than the server 406.

The session ticket 432 is transmitted 420 to the trusted component 402. In one embodiment the session ticket 432 may be transmitted inside a new session ticket handshake message such as the NewSessionTicket message used by certain TLS protocols. The trusted component 402 is able to read part 1 of the session ticket 432, but is not able to read part 2 of the session ticket 432.

After receiving the new session ticket message 420 the trusted component independently derives the resumption PSK value and stores 422 the resumption PSK along with the associated session ticket 432. The resumption PSK is securely stored by the trusted component 402 and the client program 404 is not allowed access to the resumption PSK. Associating the resumption PSK with the session ticket 432 may for example be achieved using a cryptographic hash function.

In one embodiment the session ticket 432 is stored by the trusted component 402, and the client program 404 is be provided with a handle configured to identify the desired session ticket 432. Alternatively, the session ticket 432 may be stored by the client program 404.

When a client program 404 needs to resume a secure connection, the client program 404 invokes 424 the trusted component 402 to begin a handshake 422 to resume the secure session based on the session ticket 432. The client program can indicate the desired target server using the session ticket 432, a handle associated with the session ticket 432, a server’s identity, or a handle associated with the resumption PSK value.

The trusted component 402 re-measures 426 the client program to generate one or more remeasurements. The trusted component 402 then re-validates the attestation evidence 430 based on the one or more re-measurements. When the re-validated attestation evidence ??matches the original attestation evidence 430, the client program is allowed to use the session ticket 432 to resume the secure channel. When the attestation evidence does not match, the client program is not allowed to use the session ticket 432 and the resumption handshake 422 is terminated by the trusted component 402.

Once the attestation evidence 430 is validated, the trusted component 402 proceeds with the resumption handshake 422 by sending 428 the session ticket 432 to the server 406. For example, a TLS type ClientHello message may be employed using the session ticket 432 as the PSK identity in the PSK extension and bootstrapping the TLS key schedule using the resumption PSK value associated with this session.

Referring to Figure 5 there can be seen a flow diagram of an exemplary method 500 for establishing 502 and resuming 504 the client side of an attested secure channel incorporating aspects of the disclosed embodiments. The exemplary method 500 is appropriate for use in a client apparatus, such as the client apparatus 100 described above and with respect to Figure 1. As will be discussed in more detail below, the exemplary method 500 is configured to establish 502 an attested secure channel and resume 504 an attested secure channel. Exchange of an enhanced session ticket supports efficient resumption of the attested secure channel making the method 500 beneficial in large networked computing environments where large numbers of attested secured channels need to be established and resumed.

Establishing 502 an attested secure channel begins when a client program sends 506 a request to begin establishment of an attested secure channel to a trusted component. The trusted component then sends 508 a hello message to a server, and the server responds with its own hello message which is received 510 by the client.

The trusted component measures 512 the client program to produce one or more client program measurements. The client program measurements may include any desired properties associated with the client program such as a cryptographic hash of the memory image of the client program.

Attestation evidence is generated 514 based at least in part on the one or more client program measurements. The client program measurements are incorporated along with other desired properties to form one or more claims. A digital signature over the claims is generated with a private key associated with the trusted component. The claims are combined with the signature to form the attestation evidence. The attestation evidence is then transmitted 516 to the server, where it is validated and incorporated into an enhanced session ticket, such as the session ticket 170 described above. The session ticket is then transmitted by the server back to the trusted component.

The client apparatus receives 518 the session ticket and may store it for later use. The session ticket includes the attestation evidence, a digital signature over the attestation evidence generated with a first server secret key and session parameters encrypted with a second server secret key. As noted above the first server secret key may be the same or different than the second server secret key.

The client independently derives 520 session resumption keying material, such as a resumption PSK or a resumption master key, associates it with the received session ticket and securely stores 522 the session resumption keying material within the trusted component where it will be protected from access by any system component running outside the trusted component. The client may then continue on with establishment 524 of the secure channel in any appropriate manner.

Resumption 504 of the client side of an attested secure channel begins when a client program, such as the client program 110 described above, requests 526 resumption of a previously established secure channel. Attestation evidence, such as the attestation evidence 160 described above, is retrieved 528 from a session ticket associated with the secure channel being resumed.

A trusted component executing within a client apparatus re-measures 530 the client program to generate one or more client program re-measurements. One or more claims may be re-generated based on the one or more re-measurements. In certain embodiments, the re-measurements include the same one or more client program measurements generated during establishment of the secure channel and included in the attestation evidence.

The attestation evidence is then validated 532 based on the one or more re-measurements. Validation of the attestation evidence ensures that the attestation evidence accurately reflects the current state of the client program and that the client program properties have not changed. When validation fails, the client program is not allowed to use the session ticket and session resumption is terminated.

When validation 532 of the attestation evidence is successful the client program is allowed to use the session ticket to resume the attested secure channel and the client transmits 534 the session ticket to the server. The client then resumes 536 the secure channel based on the session ticket.

Referring to Figure 6 there can be seen a flow diagram of an exemplary method 600 for establishing 602 and resuming 604 the server side of an attested secure channel incorporating aspects of the disclosed embodiments. The exemplary method 800 is appropriate for use in a server apparatus, such as the server apparatus 200 described above and with respect to Figure 2. As will be discussed in more detail below, the exemplary method 800 provides a method for establishing 802 the server side of an attested secure channel and resuming 804 the attested secure channel. The exemplary method 800 provides efficient and less resource intensive resumption of an attested secure channel by eliminating the need to re-sign the attestation evidence, reducing the effort required to re-validate the attestation evidence, and eliminating the need to store session state on the server.

Establishment 602 of an attested secure channel begins when a server receives 606 a client hello message requesting establishment of an attested secure channel. The server responds by sending 608 a server hello message back to the client.

In response to the server hello message, the server receives 610 attestation evidence from the client. The received attestation evidence may be similar to the attestation evidence 160 described above, and includes one or more claims and a digital signature over the claims generated with a private key associated with the client.

The server then validates 612 an integrity of the attestation evidence. Validation 612 includes an integrity check of the claims based on a public key of the client. The public key of the client corresponds to the private key of the client used to generate the digital signature over the claims included in the attestation evidence. Once validation 612 of the integrity succeeds, the server proceeds to validate 614 the one or more claims included in the attestation evidence. Validation of the claims may be based on any appropriate conditions or policies required by the server. If either the integrity validation 612 or the claim validation 614 fails, the method 900 terminates and no secure channel is established.

When both the integrity validation 612 and the claim validation 614 succeeds, the server proceeds to generate 616 a session ticket. The session ticket includes the attestation evidence, a digital signature over the attestation evidence generated with a first server secret, and session parameters encrypted with a second server secret key. The session ticket 170 described above is appropriate for use as the session ticket generated 616 in the method 900. As described above, the first server secret key may be the same as or a different than the second server secret key.

The session ticket is transmitted 618 to the client, and the server proceeds to establish 620 a secure channel based on any appropriate handshake as desired.

Resuming 604 an attested secure channel begins when a server, such as the server apparatus 200 described above, receives 622 a hello message requesting that a previously established secure be resumed. A session ticket, such as the session ticket 170 described above, is included in the hello message. The server validates 624 an integrity of attestation evidence included in the session ticket based on the first server secret key. Once integrity of the attestation evidence is validated, the server can trust that the client has re-measured and re- validated the attestation evidence prior to sending the session ticket to the server.

When the integrity validation 624 fails, the server refuses to resume the secure channel and terminates the resumption process 1000. When the integrity validation is successful the server continues the handshake and resumes 626 the secure channel based on session parameters included in the session ticket.

The presently disclosed embodiments may be advantageously employed to add improved reattestation mechanisms to existing TLS protocols. In one embodiment the method 800 may be implemented using callback interfaces available in readily available software libraries. For example, the session ticket 170 may be implemented using a session ticket call-back interface, attestation evidence generation may be implemented using a handshake call-back interface, and attestation evidence 160 verification may be implemented with a certificate validation call-back interface. During session resumption of the attested secure channel, decryption of the session ticket may be implemented with a session ticket call-back interface. These call-back mechanisms allow the presently disclosed embodiments to be readily employed to improve existing secure channel libraries such as the widely used open-source OpenSSL library.

Thus, while there have been shown, described and pointed out, fundamental novel features of the invention as applied to the exemplary embodiments thereof, it will be understood that various omissions, substitutions and changes in the form and details of devices and methods illustrated, and in their operation, may be made by those skilled in the art without departing from the spirit and scope of the presently disclosed invention. Further, it is expressly intended that all combinations of those elements, which perform substantially the same function in substantially the same way to achieve the same results, are within the scope of the invention. Moreover, it should be recognized that structures and/or elements shown and/or described in connection with any disclosed form or embodiment of the invention may be incorporated in any other disclosed or described or suggested form or embodiment as a general matter of design choice. It is the intention, therefore, to be limited only as indicated by the scope of the claims appended hereto.

Claims

CLAIMS What is claimed is:

1. A client apparatus (100) comprising a processor (102) and a memory (104), the client apparatus (100) configured to provide a first execution environment (108) and a trusted component (106), wherein the processor is (102) configured to execute a client program (110) within the first execution environment (106), and the trusted component (106) is configured to: establish an attested secure channel with a server; and resume the attested secure channel with the server, wherein establishing the attested secure channel with the server comprises: securely measuring the client program (110) to produce one or more client program measurements; generating an attestation evidence (160) based at least in part on the one or more client program measurements, wherein the attestation evidence (160) comprises one or more claims (162) and a digital signature (164) over the one or more claims (162) generated with a private key (112) of the trusted component (106); transmitting the attestation evidence to the server; and receiving a session ticket (170) from the server, wherein the session ticket comprises the attestation evidence (160), a digital signature (166) over the attestation evidence (160) generated with a first server secret key and session parameters (170) encrypted with a second server secret key; and wherein resuming the attested secure channel comprises: re-measuring the client program to produce one or more re-measurements; validating the attestation evidence (160) based at least in part on the one or more re-measurements; and transmitting the session ticket to the server, wherein the trusted component (106) is configured to be more secure than the first execution environment (108).

2. The client apparatus (100) according to claim 1 wherein the attestation evidence (160) comprises an assurance that the trusted component will re-measure the client program (110) and validate the one or more claims when resuming (140) the attested secure channel.

3. The client apparatus (100) according to any one of claims 1 or 2 wherein the trusted component (106) is configured to independently derive a resumption pre-shared key; and the attestation evidence (160) comprises an assurance that the trusted component (106) will restrict access to the resumption pre-shared key.

4. The client apparatus of any one of the preceding claims wherein the session ticket (170) comprises the attestation evidence (160) encrypted with a third server secret key; and the trusted component (106) is configured to store the attestation evidence (160) and the corresponding session ticket (170).

5. The client apparatus (100) of any one of the preceding claims wherein an endpoint of the attested secure channel is provided by one of the trusted component (106) and the client program (110).

6. The client apparatus (100) of any one of the preceding claims wherein the processor (102) is configured to: receive one or more requested claims from the server; and generate the one or more claims (162) based on the one or more requested claims.

7. A server apparatus (200) comprising a processor (202) and a memory (204), wherein the processor (202) is configured to: establish an attested secure channel with a client; and resume the attested secure channel, wherein establishing the attested secure channel with the client comprises: receiving attestation evidence (160) from the client, wherein the attestation evidence (160) comprises one or more claims (162) and a digital signature (164) over the one or more claims (162) generated with a private key of the client; validating an integrity of the attestation evidence (160) based on a public key of the client; validating the one or more claims (162); generating a session ticket (170), wherein the session ticket (170) comprises the attestation evidence (160), a digital signature (166) over the attestation evidence (160) generated with a first server secret key (206) and session parameters (176) encrypted with a second server secret key (208); and transmitting the session ticket (170) to the client; and wherein resuming the attested secure channel comprises: receiving the session ticket (170) from the client; validating an integrity of the attestation evidence (160) based on the digital signature (166) over the attestation evidence (160) and the first server secret key, and; resuming the attested secure channel based on the session parameters.

8. The server apparatus (200) of claim 7 wherein the session ticket (170) comprises a resumption pre-shared key and the attestation evidence provides an assurance the client will independently derive and restrict access to the resumption pre-shared key.

9. The server apparatus (200) of any one of claims 7 or 8 wherein the attestation evidence (160) provides an assurance that the client has re-measured and re-validated the one or more claims (162) prior to resuming the attested secure channel.

10. The server apparatus (200) of any one of claims 7 through 9 wherein the session ticket (170) comprises: a key name; an initial value vector; attestation evidence; an encrypted session state, wherein the encrypted session state is generated based on the server secret key; and a tag, wherein the tag is configured to protect an integrity of the attestation evidence.

11. The server apparatus of any one of claims 7 through 10 wherein the first server secret key is different than the second server secret key, and wherein the first server secret key is diversified based on the second server secret key and a random salt, and the session parameters (170) comprise the random salt.

12. A method (500) compri sing : establishing (502) an attested secure channel between a client program and a server; and resuming (504) the attested secure channel, wherein establishing (502) the attested secure channel comprises: securely measuring (512) the client program to produce one or more client program measurements; generating (514) an attestation evidence based at least in part on the one or more client program measurements, wherein the attestation evidence comprises one or more claims and a digital signature over the one or more claims generated with a private key of a trusted component; transmitting (516) the attestation evidence to the server; and receiving (518) a session ticket from the server, wherein the session ticket comprises: the attestation evidence; a digital signature over the attestation evidence generated with a first server secret key; and session parameters encrypted with a second server secret key; and wherein resuming (504) the attested secure channel comprises: re-measuring (530) the client program to generate one or more re-measurements; re-validating (532) the attestation evidence based at least in part on the one or more re-measurements; transmitting (534) the session ticket to the server; and resuming (536) a secure channel based on the session ticket.

13. A method (800) comprising: establishing (802) an attested secure channel with a client; and resuming (804) the attested secure channel, wherein establishing (802) the attested secure channel with the client comprises: receiving (610) attestation evidence from the client, wherein the attestation evidence comprises one or more claims and a digital signature over the one or more claims generated with a private key associated with the client; validating (612) an integrity of the attestation evidence based on a public key of the client; validating (614) the one or more claims; generating (616) a session ticket, wherein the session ticket comprises the attestation evidence, a digital signature over the attestation evidence generated with a first server secret key, and session parameters encrypted with a second server secret key; and transmitting (618) the session ticket; and wherein resuming (804) the attested secure channel comprises: receiving (622) the session ticket; validating (624) an integrity of the attestation evidence based on the public key of the client and the first server secret key, and; resuming (626) the attested secure channel based on the session parameters.

14. The method of claim 13, wherein the attestation evidence provides an assurance that the client has re-measured and re-validated the one or more claims prior to resuming the attested secure channel.

15. A computer program product comprising a non-transitory computer readable media having stored thereon program instructions that when executed by a processor cause the processor to perform the method according to any one of claims 12 through 15.