Transport layer secure computer device and method

Abstract

A computer device instantiates a first transport layer security (TLS) endpoint having access to a trusted execution environment (TEE) of a processor; generating an endpoint dedicated public key-private key pair bound to the first TLS endpoint in the TEE; generating attestation data that verifies that an endpoint-specific public key-private key pair is generated in the TEE and is bound to the first TLS endpoint; and signing attestation data in the TEE using a TEE private key securely embedded in the processor. The device generates a TEE signature by using an endpoint dedicated private key in the endpoint dedicated public key-private key pair; and indicating the attestation data, an endpoint-specific public key in the endpoint-specific public public key-private key pair, and the TEE signature to a second TLS endpoint within the TLS handshake message exchange between the first TLS endpoint and the second TLS endpoint.

Description

Technical Field

[0001] The present disclosure relates to computer devices, systems, and computer-implemented methods for implementing a transport layer security protocol. Background Art

[0002] Transport Layer Security (TLS) is a standard protocol for establishing cryptographically secure network connections over untrusted networks. TLS is built on public key cryptography for the secure exchange of keys. The currently approved version of TLS is version 1.3, which is specified in "RFC8446: Transport Layer Security (TLS) Protocol Version 1.3" (https: / / www.rfc-editor.org / rfc / rfc8446).

[0003] TLS includes a handshake message exchange, which is used to negotiate the security parameters of the connection between the client and server devices before exchanging application data. The handshake includes a certificate message, which allows the server to share a certificate issued by a trusted third party (the certificate authority (CA) of the certificate). The handshake also includes a certificate verification (CertificateVerify) message, which allows the client to verify that the server is the holder of the private key associated with the certificate. Summary of the invention

[0004] In summary, examples of the present invention provide a means of extending or modifying the authentication portion of the handshake of the TLS protocol, allowing not only the use of TLS certificates to verify domain ownership, but also the attestation of a trusted execution environment (TEE). This proves that the data exchanged using the protocol during authentication remains only within a specific TEE. Such authentication improves the security of environments in multi-tenant computing environments such as cloud computing systems.

[0005] The present invention content is provided to introduce some concepts that will be further described in the following detailed description in a simplified form. This overview is not intended to identify the key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. The claimed subject matter is also not limited to implementations that solve any or all of the disadvantages mentioned herein. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] To aid understanding of the present disclosure, and to show how the embodiments may be effected, reference is made by way of example to the accompanying drawings, in which:

[0007] Figure 1 is a schematic block diagram illustrating various aspects of a TLS handshake;

[0008] Figure 2 is a schematic diagram showing messages exchanged in a TLS handshake;

[0009] Figure 3is a schematic block diagram of a server included in a system according to a first example of the present disclosure;

[0010] Figure 4 is a schematic block diagram of a system according to a first example of the present disclosure;

[0011] Figure 5 It is shown Figure 4 Schematic diagram of message exchange in the system;

[0012] Figure 6 is a schematic block diagram of a system according to a second example of the present disclosure;

[0013] Figure 7 It is shown Figure 6 A schematic diagram of message exchange in a system;

[0014] Figure 8 is a schematic block diagram of a system according to a third example of the present disclosure;

[0015] Fig. 9 is a schematic flow chart of a first example method;

[0016] Fig.10 is a schematic flow chart of a second example method;

[0017] Fig.11 is a schematic block diagram of an example computing system. DETAILED DESCRIPTION

[0018] Figure 1 An environment 100 in which an example of the present disclosure may operate is shown to demonstrate relevant aspects of a TLS handshake message exchange to aid in understanding the disclosure herein. This is not intended to be an exhaustive discussion of the protocol. Environment 100 is a computing environment that includes a server device 110, a client device 120, and a certificate authority (CA) 130.

[0019] Server device 110 is part of network domain 112, an example of a fictitious name xyz.com is given herein. Domain 112 (or more precisely the owner of the domain) has been issued a certificate 150 (i.e., a TLS certificate, also referred to herein as a domain certificate) by CA 130, which includes a digital signature of CA 130. Certificate 150 issued by CA 130 indicates the fact that CA 130 has certified the holder of a private key (151PR, discussed below) corresponding to certificate 150 is the owner of domain 112.

[0020] In the illustrated example, domain 112 includes a single server device 110 , but in practice domain 112 may include any number of server devices 110 forming part of domain 112 .

[0021] Certificate 150 includes public key 151PB of public-private key pair 151. The corresponding private key 151PR is kept secret by domain 112.

[0022] In addition to the CA 130's public key 151PB digital signature, the certificate 150 may include various other data, such as the subject domain ("xyz.com"), the subject organization (i.e., the domain owner), the name of the issuing CA 130, the issue date, the expiration date, and a list of additional or alternative subject domains to which the certificate applies. The certificate 150 may employ the X.509 standard (https: / / www.itu.int / rec / T-REC-X.509).

[0023] At some point after the certificate 150 is issued to the domain 112, the client device 120 attempts to communicate with the server device 110 over an untrusted network such as the Internet using the TLS protocol. That is, the client device 120 and the server device 110 wish to share application data in an encrypted manner. In contrast to data exchanged in order to establish or manage a secure TLS communication channel between the two devices 110, 120, application data herein refers to the actual data that the client device 120 and the server device 110 wish to send to each other.

[0024] The term "client" herein is intended only to indicate that the device in question initiates a TLS connection - in some examples, client device 120 itself may be a server computer. Herein, the term "TLS endpoint" may be used to refer collectively to client device 120 and server device 110.

[0025] TLS includes a handshake protocol. The messages exchanged as part of the handshake protocol are Figure 2 and are briefly discussed below in this article.

[0026] First, the step is initiated by the client device 120 sending a ClientHello message 161, to which the server 110 responds with a ServerHello message 163. These two messages involve establishing shared key material and selecting cryptographic parameters (e.g., which cryptographic algorithms are supported / selected by both devices 110, 120). Subsequent messages are encrypted. Messages 161 and 163 can be considered the key exchange phase of the handshake protocol.

[0027] Next, the server 110 sends an encrypted extension message 165 to indicate any extensions not required to determine the cryptographic parameters. The subsequent certificate request message 167 is optional and allows the server 110 to request that the client 120 share its certificate. These messages can be considered the server parameter exchange phase of the handshake protocol.

[0028] Next, the step proceeds to the authentication phase. The server 110 sends Figure 1 1. The certificate message 170 is shown in FIG. The certificate message 170 includes the certificate 150 and the public key 151PB. The public key 151PB may be the original public key in the message 170 and forms part of the certificate 150.

[0029] The server 110 then sends a certificate verification message 172, which is also Figure 1 151PB. This is accomplished by including a message 172 with a signature 172a applied to a transcribed hash 172b. The transcribed hash is a concatenated hash of all previous messages exchanged between the server 110 and the client 120. Although the figure shows the transcribed hash 172b being included in the message 172 to help understand the purpose of the signature 172a, the hash value 172b is not actually present in the message.

[0030] Upon receiving certificate message 170 and certificate verification message 172, client 120 uses public key 151PB and its own knowledge of the transcription to verify signature 172a. For example, client 120 calculates a transcription hash from the transcription, decrypts signature 172a using public key 151PB, and compares the hash value to the decrypted signature.

[0031] The certificate 150 is verified by the client device 110, which verifies that it identifies and trusts the CA 130, and checks that the certificate 150 has not been revoked or expired. Any suitable means of verifying the certificate 150 may be employed. For example, "RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" (https: / / www.rfc-editor.org / rfc / rfc5280) may be employed.

[0032] If the certificate 150 fails to verify, or the signature 172a fails to verify, the client closes the TLS connection.

[0033] At the same time, the server 110, having sent its authentication messages 170, 172, may send a completion message 174 indicating that it has completed its portion of the handshake. The server 110 may then proceed to share application data in message 176.

[0034] In the example where the server 110 requests the client device 120's certificate, optional message 178 and optional message 180 allow the client 110 to share its certificate in the certificate and certificate verification messages. The client 110 shares a completion message 182 to indicate that it is finished with its portion of the handshake. This ends the handshake, and the client 120 and server 110 then continue to share application data, as indicated by reference numeral 184.

[0035] Reference Figure 1 and Figure 2 The TLS protocol in question allows a client to determine that a server / domain is under the ownership / control of the entity listed on the certificate 150 .

[0036] Figure 3 and Figure 4 System 200 is shown according to an example of the present disclosure. Elements identical to system 100 described above have corresponding reference numerals augmented by those of system 100.

[0037] First turn Figure 3 , a server 210 forming part of a domain 212 will be discussed. The server 210 is a computing device including a trusted execution environment (TEE) 211.

[0038] TEE 211 is a secure environment isolated from the main (i.e., conventional) processing environment of device 210. This provides an environment in which data in use - that is, during processing rather than in transmission or storage - can be kept secure. TEE 211 may include protected hardware resources, including secure storage elements such as secure areas of memory and secure areas of processors. Protected hardware resources cannot be directly accessed by the operating system of the main processing environment. Therefore, TEE 211 may also include a suitable trusted operating system that provides access to secure hardware from the main processing environment.

[0039] TEE 211 includes a private key 214PR. That is, the private key 214PR is stored in TEE 211. For example, the private key 214PR may be embedded in a secure storage element. In other words, when the server 210 is manufactured, the private key 214PR is embedded in hardware (e.g., a chip such as a processor, a memory chip, or other hardware element) included in the TEE 211, and the corresponding public key 214PB is provided by the manufacturer. The secure storage element may also include a secret from which the private key 214PR may be derived or calculated. Figure 3 It is shown that the public key 214PB is also stored in the TEE 211.

[0040] Server 210 is a server that hosts multiple virtual machines 213a..213n (also referred to herein as "instances" or VMs). A hypervisor 212 is included in server 210, which manages VM 213, for example, by instantiating VM 213, allocating their associated resources, and scheduling execution. Instantiating VM 213 (which is an example of instantiating a TLS endpoint more generally) may involve creating a VM using hypervisor 212. Hypervisor 212 may run on a suitable host operating system 212a. VM 213 is a TLS endpoint, where each VM 213 is capable of acting as a server for a corresponding TLS connection to a client. VM 213 may access TEE 211. For example, each VM 213 may be executed within TEE 211 (i.e., TEE 211 itself is capable of hosting VM 213). In other examples, VM 213 may be hosted outside TEE 211 and access TEE 211 through any suitable mechanism.

[0041] In one example, server 210 is Secure Encrypted Virtualization (SEV) Server. For example, server 210 may operate SEV-SNP (Secure Nested Paging) functionality such that each VM 213 is a SEV-SNP VM. This is merely an example of a suitable virtualization environment that includes a TEE. It should be appreciated that there are many other such environments that may be used, including Software Guard Extensions (SGX), Confidential Computing Architecture (CCA), etc.

[0042] Server 210 possesses a certificate 250 issued by a suitable CA (not shown) which can be used to authenticate server 210, as described above with respect to Figure 1 discussed.

[0043] Additionally, each VM 213 is configured to generate a TEE certificate 217 , which may be used to provide assurance that the VM 213 is being hosted in a TEE 211 .

[0044] like Figure 3 As shown, VM 213a uses TEE 211 to generate instance-specific public key 216PB and corresponding private key 216PR. That is, the isolated environment of TEE 211 is used to execute key generation software 211a. Key pair 216 is endpoint-specific, which means that key pair 216 is bound to a specific VM 213a acting as a TLS endpoint.

[0045] VM 213 is also configured to generate an attestation report 215, which can be used to confirm that key generation occurred in TEE 211. The process of generating attestation report 215 relies on private key 214PR. Attestation report 215 also includes public key 214PB. Therefore, when appropriate, public key 214PB can be used to authenticate attestation report 215.

[0046] VM 213 is then configured to generate a TEE certificate 211 that indicates (eg, includes) an attestation report 215 , an instance-specific public key 216PB, and a signature provided by an instance-specific private key 216PR.

[0047] In some examples, VM 213 signs TEE certificate 211 to TEE-specific CA 290 that recognizes TEE certificate 211. For example, TEE-specific CA 290 can be an identity service such as Microsoft Cloud Authentication (MAA) service. In other examples, VM 213 signs certificate 211 itself.

[0048] In one example, the above process of generating key 216, attestation report 215, and TEE certificate 217 is performed before initiating a TLS connection. For example, the process can be performed when VM 213 is created. In other examples, the process can be performed before each TLS session, or in response to a request from a client to generate a new attestation report 215, or periodically to refresh key 216.

[0049] Figure 4 A system 200 is shown including a server 210 and a client 220. The figure shows that a TEE certificate 217 is provided to the client 220 as part of a modified TLS handshake.

[0050] In more detail, certificate message 270 includes TEE certificate 217 and instance-specific public key 216PB. Upon receiving certificate message 270, client 220 verifies domain certificate 250 in the same manner as discussed above with respect to system 100.

[0051] TEE certificate 217 is verified by client 220 using attestation service 295. Specifically, client 220 may extract attestation report 215 from TEE certificate 217 and provide attestation report 215 to attestation service 295. Attestation service 295 verifies the claims in attestation report 215, such as using public key 214PB to verify that report 215 has been signed using private key 214PR stored in TEE 211. If the claim verification fails, client 220 closes the TLS connection.

[0052] In examples where the TEE certificate 217 has been signed by a TEE-specific CA 290, the certificate 217 may be verified by reference to the TEE CA 290 in a manner similar to reference to the domain certificate 250 of the domain CA 230. In some examples, the attestation service 295 and the TEE CA 290 may be the same - that is, the same service that provides hardware attestation and acts as a trusted third-party certification authority. For example, the attestation service 295 and / or the TEE CA 290 may be a MAA service.

[0053] Certificate verification message 270 includes domain signature 272a of transcribed hash 272b (ie, the signature is applied with domain private key 251PR and verifiable with corresponding public key 251PB). In addition, VM 213 generates second signature 273 over transcribed hash 272b using instance-specific private key 216PR.

[0054] Upon receiving certificate verification message 272, client 220 then verifies that VM 213 has key 251PR by verifying signature 272a using key 251PB included in certificate message 270. Similarly, client 220 verifies that VM 213 possesses key 216PR by verifying signature 273 using key 216PU included in certificate message 270.

[0055] By including this additional information in the certificate message and the certificate verification message, the TLS handshake protocol is extended in a manner that allows the client 220 to verify that the VM 213 acting as a TLS server is operating in the TEE 211. Furthermore, this technique enables verification without introducing any additional round trips.

[0056] Figure 5 The message exchange between client 220 and VM 213 is shown in more detail. The message flow is similar to Figure 2 A conventional TLS handshake is shown, and therefore only the differences are discussed in detail.

[0057] First, the client 220 generates and sends a client hello message 261 including an attested_tls extension. The attested_tls extension is an indication from the client 220 to the server 210 that the client 210 wishes to use the authenticated handshake procedure discussed herein.

[0058] Next, VM 213 generates and sends a Server Hello message 263 including an attested_tls extension. This serves as an indication that VM 213 understands the authenticated handshake process.

[0059] VM 213 then sends a certificate message 270, including domain certificate 250 and TEE certificate 217. This is followed by a certificate verification message 280 including signature 272a and signature 273.

[0060] If VM 213 has sent optional certificate request message 267, client 220 responds with its own certificate message 278, which includes client 220's domain certificate 250-C and client 220's TEE certificate 273-C. Client 220 generates these messages in a similar manner, and client 220 must include its own TEE in order to generate these messages. This is followed by certificate message 280, which includes transcribed signatures 272a-C and 273-C in a similar manner as described above.

[0061] Other news such as the above article about Figure 1 and 2 Operate as discussed.

[0062] In the above about Figures 3 to 5 In the discussion of , both the verification message and the certificate verification message are extended to include additional information that allows the client to confirm that VM 213 is running in TEE 211. According to the latest TLS standard (TLS 1.3), the verification message supports extensions (i.e., there is space in the standard message to include additional data). However, the certificate verification message does not support extensions. Therefore, the above example may require modifications to the TLS protocol.

[0063] Figure 6 and Figure 7 Another example system 300 is shown including a server 310 and a client 320. System 300 is substantially the same as system 200, with only the differences discussed in detail below. Elements identical to system 200 described above have corresponding reference numerals augmented from system 100.

[0064] in short, Figure 6 System 300 of differs from system 200 in that the information required to verify TEE certificate 317 (signature 373) is included in certificate message 370, rather than certificate verification message 372. This avoids modification of the certificate verification message, allowing the scheme to comply with the TLS 1.3 protocol. Although the certificate message has not yet been sent, the transcription on which the transcription hash 372b is based includes certificate message 370. This means that hash value 372b corresponds to hash value 272b, except that the message in which it is sent is different.

[0065] Figure 7 The message exchanges in system 300 are shown in greater detail. Figure 7 The content is similar to Figure 5 , so only the differences are discussed in detail.

[0066] like Figure 7As shown, TEE signature 374 is included in certificate message 370. Certificate verification message 372 contains no other content except that specified in the TLS 1.3 protocol.

[0067] Similarly, optional certificate message 378 includes client TEE signature 373 -C instead of including it in certificate verify message 380 .

[0068] also, Figure 7 It is shown that the certificate request message 367 may include an attested_tls extension, indicating that VM 313 expects the client to return a TEE certificate. This optional extension may be used in situations where both the client and the server include TEE hardware and require verification. However, in other cases, this extension may not be included, and the certificate and certificate verification messages signaled to the client only need to include the domain certificate and not the TEE certificate. This may be appropriate in the case where the client is a legacy client running a TLS library that does not support the attested_tls extension or attestation verification logic but still requires domain authentication. It should be understood that any example herein may include this optional extension to the certificate request message 367.

[0069] The above examples focus on TLS server certification. That is, the process of the server generating a TEE certificate and including it in a certificate message is discussed, and the case of mutual certification is briefly discussed. However, it should be understood that the above discussion is fully applicable to the case of mutual certification. That is, in some examples, the server can request a certificate from the client using a certificate request message as part of the handshake. In this case, the client can generate a certificate and a certificate verification message in substantially the same manner as the VM / server described above. This mutual certification is particularly useful in ensuring communication between different TEEs.

[0070] In addition, the TEE certificates discussed in the examples herein are examples of attestation data that can be provided by a TLS endpoint to provide evidence that it is running in a TEE. For example, the attestation data can take the form of an attestation report itself included in a TLS exchange, or an attestation token issued by an attestation service.

[0071] In addition, in some examples, the attestation data (e.g., TEE certificate) itself may not be included in the TLS exchange. Instead, the TLS exchange may include an indication of where the attestation data can be accessed. In this document, references to indicating attestation data include examples of sending attestation data in a TLS exchange and otherwise linking to attestation data.

[0072] Figure 8Another example system 400 is shown. System 400 is substantially the same as systems 200 and 300, with only the differences discussed in detail below. Elements identical to systems 200 and 300 described above have corresponding reference numerals, beginning with "4" instead of "2" or "3", respectively.

[0073] In the system 200 / 300, the client 220 / 320 uses the attestation service 295 / 395 to verify the attestation report 215 included in the TEE certificate 217 / 317. In other words, this involves the client 220 / 320 independently accessing the attestation service 295 / 395 and verifying the claims made in the attestation report 215.

[0074] On the contrary, Figure 8 In FIG. 4 , domain 412 itself includes a certification endpoint 495. Certification endpoint 495 may be, for example, an HTTP (Hypertext Transfer Protocol) endpoint. Endpoint 495 may be hosted by VM 413, server 410, or another server within domain 412.

[0075] Attestation endpoint 495 provides attestation services for client 420. This may be appropriate in situations where client 420 rarely communicates securely with the TEE, so it is uneconomical or impractical for client 420 to provide a separate attestation service.

[0076] Attestation endpoint 495 is configured to receive and respond to attestation verification requests from client 420 in a manner similar to the attestation service described above. That is, the attestation report (or more specifically, the signature applied thereto) is decrypted using the public key corresponding to the private key embedded within the TEE.

[0077] In other examples, client 420 (and likewise, client 220 and client 320 described above) may verify the attestation report itself, without reference to external endpoint 495 or server 295 / 395. For example, the fact that the TEE certificate was issued by a CA that the client trusts may be sufficient for the client to verify the report.

[0078] Fig. 9 An example method of the present disclosure is shown. The method may be performed by a device acting as a TLS endpoint (either as a server or as a client in a mutual authentication scenario).

[0079] The method comprises a step S91 of instantiating a first TLS endpoint having access rights to the TEE. For example, this may comprise instantiating a VM as described above.

[0080] The method includes a step S92 of generating, in the TEE, an endpoint-specific (eg, VM-specific) public-private key pair bound to the first TLS endpoint.

[0081] The method comprises a step S93 of generating attestation data verifying that an endpoint-specific public-private key pair is generated in the TEE and bound to the first TLS endpoint.

[0082] The method comprises a step S94 of signing the attestation data in the TEE using a TEE private key embedded in the TEE of the processor.

[0083] The method comprises step S95 of generating a TEE signature using an endpoint-specific private key in an endpoint-specific public key-private key pair; and

[0084] The method comprises step S96 of indicating the attestation data, the endpoint-specific public key of the endpoint-specific public-private key pair, and the TEE signature to the second TLS endpoint within a TLS handshake message exchange between the first TLS endpoint and the second TLS endpoint.

[0085] Fig.10 Another example method of the present disclosure is shown. The method may be performed by a device acting as a TLS endpoint (either as a client or as a server in a mutual authentication scenario).

[0086] The method comprises a step S1001 of receiving attestation data and an instance-specific public key within a TLS handshake message exchange. The method comprises a step S1002 of verifying the attestation data. The method comprises a step S1003 of receiving a TEE signature. The method comprises a step S1004 of verifying the TEE signature using the instance-specific public key.

[0087] Fig.11 A non-limiting example of a computing system 1200 that can perform one or more of the above methods and processes is schematically shown. The computing system 1200 is shown in simplified form. The computing system 1200 can be embodied as described above and in Figure 1-Figure 8 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 21, 22, 23, 29, 295, 310, 320, 330, 390, 395, 410, 420, or 495, or any other computer device discussed herein. Computing system 1200 may take the form of one or more of a personal computer, a server computer, a tablet computer, a home entertainment computer, a network computing device, a gaming device, a mobile computing device, a mobile communication device (e.g., a smart phone), and / or other computing devices, as well as wearable computing devices such as smart watches and head-mounted augmented reality devices.

[0088] The computing system 1200 includes a logic processor 1202, a volatile memory 1204, and a non-volatile storage device 1206. The computing system 1200 may optionally include a display subsystem 1208, an input subsystem 1210, a communication subsystem 1212, and / or Fig.11 Other components not shown.

[0089] Logical processor 1202, as an example of a processing unit, includes one or more physical devices configured to execute instructions. For example, a logical processor may be configured to execute instructions that are part of one or more applications, programs, routines, libraries, objects, component data structures, or other logical constructs. Such instructions may be implemented to perform a task, implement a data type, transform the state of one or more components, implement a technical effect, or otherwise achieve a desired result.

[0090] The logical processor may include one or more physical processors (hardware) configured to execute software instructions. Additionally or alternatively, the logical processor may include one or more hardware logic circuits or firmware devices configured to execute hardware-implemented logic or firmware instructions. The processor of the logical processor 1202 may be single-core or multi-core, and the instructions executed thereon may be configured for sequential, parallel and / or distributed processing. The various components of the logical processor may optionally be distributed in two or more separate devices that may be remotely located and / or configured for coordinated processing. Various aspects of the logical processor may be virtualized and executed by a remotely accessible networked computing device configured in a cloud computing configuration. It should be understood that in this case, these virtualized aspects run on different physical logical processors of various different machines.

[0091] The non-volatile storage device 1206 includes one or more physical devices configured to store instructions executable by a logical processor to implement the methods and processes described herein. When implementing such methods and processes, the state of the non-volatile storage device 1206 may be transformed - for example, to store different data.

[0092] The non-volatile storage device 1206 may include a removable and / or built-in physical device. The non-volatile storage device 1206 may include an optical storage device (e.g., CD, DVD, HD-DVD, Blu-ray disc, etc.), a semiconductor memory (e.g., ROM, EPROM, EEPROM, flash memory, etc.), and / or a magnetic storage device (e.g., a hard disk drive) or other mass storage device technology. The non-volatile storage device 1206 may include a non-volatile, dynamic, static, read / write, read-only, sequential access, location addressable, file addressable, and / or content addressable device. It should be understood that the non-volatile storage device 1206 is configured to retain instructions even when the power to the non-volatile storage device 1206 is cut off. The non-volatile storage device 1206 may include a secure storage element that stores a TEE private key as discussed herein.

[0093] The volatile memory 1204 may include a physical device with random access memory. The volatile memory 1204 is typically used by the logical processor 1202 to temporarily store information during the processing of software instructions. It should be understood that when power to the volatile memory 1204 is cut off, the volatile memory 1204 typically does not continue to store instructions.

[0094] Aspects of the logic processor 1202, volatile memory 1204, and non-volatile storage device 1206 may be integrated together into one or more hardware-logic components. Such hardware-logic components may include, for example, field programmable gate arrays (FPGAs), program and application specific integrated circuits (PASIC / ASIC), program and application specific standard products (PSSP / ASSP), systems on chips (SOCs), and complex programmable logic devices (CPLDs).

[0095] The terms "module", "program", and "engine" may be used to describe an aspect of a computing system 1200 that is typically implemented in software by a processor to perform a specific function using portions of volatile memory that involves a conversion process that specifically configures the processor to perform the function. Thus, a module, program, or engine may be instantiated using portions of volatile memory 1204 via a logical processor 1202 that executes instructions stored by a non-volatile storage device 1206. It should be understood that different modules, programs, and / or engines may be instantiated from the same application, service, code block, object, library, routine, API, function, etc. Likewise, the same module, program, and / or engine may be instantiated by different applications, services, code blocks, objects, routines, APIs, functions, etc. The terms "module", "program", and "engine" may include individual or collections of executable files, data files, libraries, drivers, scripts, database records, and the like.

[0096] When the display subsystem 1208 is included, the display subsystem 1208 can be used to present a visual representation of the data stored by the non-volatile storage device 1206. The visual representation can take the form of a graphical user interface (GUI). As the methods and processes described herein change the data held by the non-volatile storage device, and thus convert the state of the non-volatile storage device, the state of the display subsystem 1208 can also be converted to visually represent the changes in the underlying data. The display subsystem 1208 may include one or more display devices utilizing virtually any type of technology. Such display devices may be combined with the logical processor 1202, the volatile memory 1204, and / or the non-volatile storage device 1206 in a shared housing, or such display devices may be peripheral display devices.

[0097] When input subsystem 1210 is included, input subsystem 1210 may include or interact with one or more user input devices, such as a keyboard, mouse, touch screen, or game controller. In some embodiments, the input subsystem may include or interact with selected natural user input (NUI) component portions. Such component portions may be integrated or peripheral, and the conversion and / or processing of input actions may be processed on or off the board. Example NUI component portions may include microphones for speech and / or voice recognition; infrared, color, stereo, and / or depth cameras for machine vision and / or gesture recognition; head tracking, eye trackers, accelerometers, and / or gyroscopes for motion detection and / or intent recognition; and electric field sensing components for assessing brain activity; and / or any other suitable sensors.

[0098] When communication subsystem 1212 is included, communication subsystem 1212 can be configured to communicatively couple various computing devices described herein to each other, as well as to communicatively couple to other devices. Communication subsystem 1212 can include wired and / or wireless communication devices compatible with one or more different communication protocols. As non-limiting examples, the communication subsystem can be configured to communicate via a wireless telephone network, or a wired or wireless local area network or wide area network. In some embodiments, the communication subsystem can allow computing system 1200 to send messages to other devices and / or receive messages from other devices via a network such as the Internet.

[0099] Various modifications may be made to the examples discussed herein within the scope of the present disclosure. Although the above examples are discussed with respect to the TLS 1.3 protocol, the concepts discussed herein may be applied to any TLS protocol, either by modifying the messages used in the protocol (i.e., to provide a modified protocol outside the standard protocol), or by extending the protocol by utilizing the extension space defined in the message according to the standard. It should be understood that references to TLS (e.g., TLS handshake, TLS protocol) herein include examples where the messages do not technically conform to the protocol but define a modified protocol.

[0100] Although an example TEE environment has been discussed, it should be understood that the teachings herein are applicable to any environment including a TEE where secure communications are desired. Similarly, a variety of attestation services or mechanisms are compatible with the present disclosure.

[0101] Advantageously, the systems and methods discussed herein support attestation of services provided using TEEs without requiring application-level encryption or introducing further round trips. Instead, attestation is advantageously provided using messages of the TLS protocol. The use of the TLS protocol means that the systems and methods are compatible with existing mechanisms for providing identity and domain certificates, and do not require changes to existing public key infrastructure (PKI).

[0102] The use of a TEE-specific CA advantageously enables the issuance of certificates with relatively short expiration times.The issuance of TEE certificates avoids the need to distribute keys between different instances of the same service.

[0103] Additional example features of the invention are set out below.

[0104] According to a first aspect disclosed herein, a computer device is provided, comprising: a processing unit; a secure storage element coupled to the processing unit and containing a trusted execution environment, a TEE, a private key, and a memory coupled to the processing unit and configured to store executable instructions, which, when executed by the processing unit, are configured to cause the processing unit to: instantiate a first transport layer security TLS endpoint having access rights to a TEE of a processor; generate an endpoint-specific public key-private key pair bound to the first TLS endpoint in the TEE; generate attestation data verifying that the endpoint-specific public key-private key pair is generated in the TEE and bound to the first TLS endpoint; sign the attestation data in the TEE using the TEE private key; generate a TEE signature using the endpoint-specific private key in the endpoint-specific public key-private key pair; and indicate the attestation data, the endpoint-specific public key in the endpoint-specific public key-private key pair, and the TEE signature to the second TLS endpoint within a TLS handshake message exchange between the first TLS endpoint and the second TLS endpoint.

[0105] The memory may be configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to send the attestation data in a TLS certificate message of a TLS handshake message exchange.

[0106] The memory may be configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to send the TEE signature in a TLS certificate verification message.

[0107] The memory may be configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to send the TEE signature in a TLS certificate message.

[0108] The memory may be configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to instantiate a virtual machine VM as a first TLS endpoint.

[0109] The memory may be configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to receive a TLS Client Hello message from the second TLS endpoint. The Client Hello message may include an indication that the second TLS endpoint wants to receive a TLS Certificate message including attestation data. The memory may also store instructions for generating a TLS Server Hello message including an indication that the computer device is capable of sending TLS Certificate messages including attestation data.

[0110] The memory may be configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to receive a second TLS certificate message from a second TLS endpoint, the second TLS certificate message including second proof data generated by the second TLS endpoint and a second instance-specific public key. The memory may also store instructions for verifying the second proof data. The memory may also store instructions for receiving a second TEE signature, the second TEE signature being signed by a second instance-specific private key corresponding to the second instance-specific public key. The memory may also store instructions for verifying the second TEE signature using the second instance-specific public key.

[0111] The memory may be configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to send a certificate request message to the second TLS endpoint and receive a second TLS certificate message in response.

[0112] The memory may be configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to generate a TEE certificate indicating the attestation data and the endpoint-specific public key in the endpoint-specific public key-private key pair. The memory may also store instructions to submit the TEE certificate to the TEE certificate authority CA. The memory may also store instructions to receive an approved TEE certificate from the TEE CA. The memory may also store instructions to include an approved TEE certificate in a TLS certificate message.

[0113] The memory may be configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to generate a transcription hash from a transcription of a previous message of the TLS handshake message exchange. The memory may also store instructions for generating a TEE signature based on the transcription hash.

[0114] According to a second aspect disclosed herein, a computer device configured to act as a first transport layer security (TLS) endpoint device is provided, the computer device comprising: a processing unit; a memory coupled to the processing unit and configured to store executable instructions, which, when executed by the processing unit, are configured to cause the processing unit to: receive attestation data and an instance-specific public key within a TLS handshake message exchange with a second TLS endpoint; verify the attestation data; receive a TEE signature, the TEE signature being signed by an instance-specific private key corresponding to the instance-specific public key; and verify the TEE signature using the instance-specific public key.

[0115] The memory may be configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to generate a TLS Client Hello message including an indication that the computer device wants to receive a TLS Certificate message including attestation data.

[0116] The memory may be configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to send attestation data to an attestation endpoint in a network domain of the second TLS endpoint; and in response, receive verification of the attestation data.

[0117] The present disclosure extends to a system comprising a computer device according to the first aspect and a computer device according to the second aspect.Furthermore, features of the first and second aspects may be combined in order to provide a device acting as a TLS server and client.

[0118] According to a third aspect disclosed herein, a computer-implemented method is provided, the method comprising: instantiating a first transport layer security TLS endpoint with access rights to a trusted execution environment TEE; generating an endpoint-specific public-private key pair in the TEE bound to the first TLS endpoint; generating attestation data verifying that the endpoint-specific public-private key pair is generated in the TEE and bound to the first TLS endpoint; signing an attestation report in the TEE using a TEE private key contained in a secure storage element; generating a TEE signature using an endpoint-specific private key in the endpoint-specific public-private key pair; and indicating the attestation data, the endpoint-specific public key of the endpoint-specific public-private key pair, and the TEE signature to the second TLS endpoint within a TLS handshake message exchange between the first TLS endpoint and the second TLS endpoint.

[0119] The method may also include receiving attestation data and an instance-specific public key at a second TLS endpoint. The method may include verifying the attestation data. The method may include receiving a TEE signature. The method may include verifying the TEE signature using the instance-specific public key.

[0120] The present disclosure extends to a computer-implemented method corresponding to the second aspect.

[0121] Although at least some aspects of the embodiments described herein with reference to the accompanying drawings include computer processing performed in a processing system or processor, the invention also extends to a computer program suitable for putting the invention into practice, in particular a computer program on or in a carrier. The program may be in the form of a non-transitory source code, an object code, a code intermediate source and object code, such as in a partially compiled form, or in any other non-transitory form suitable for use in the implementation of the process according to the invention. The carrier may be any entity or device capable of carrying the program. For example, the carrier may include a storage medium, such as a solid state drive (SSD) or other semiconductor-based RAM; a ROM, such as a CD ROM or a semiconductor ROM; a magnetic recording medium, such as a floppy disk or a hard disk; an optical storage device in general; and the like.

[0122] The embodiments described herein are to be understood as illustrative embodiments of embodiments of the present invention. Other embodiments and examples are contemplated. Any feature described with respect to any one example or embodiment may be used alone or in combination with other features. In addition, any feature described with respect to any one example or embodiment may also be used in combination with one or more features of any other example or embodiment or any combination of any other example or embodiment. In addition, within the scope of the present invention as defined in the claims, equivalents and modifications not described herein may also be employed.

Claims

1. A computer device comprising: Processing unit; a secure storage element coupled to the processing unit and containing a trusted execution environment, a TEE, a private key, and a memory coupled to the processing unit and configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to: Instantiate a first transport layer security TLS endpoint with access rights to the TEE; Generating, in the TEE, an endpoint-specific public key-private key pair bound to the first TSL endpoint; generating attestation data verifying that the endpoint-specific public-private key pair is generated in the TEE and bound to the first TLS endpoint; Sign the attestation data in the TEE using the TEE private key; Generate a TEE signature using the endpoint-specific private key from the endpoint-specific public-private key pair; as well as The attestation data, the endpoint-specific public key of the endpoint-specific public key-private key pair, and the TEE signature are indicated to the second TLS endpoint within a TLS handshake message exchange between the first TLS endpoint and the second TLS endpoint.

2. The computer device of claim 1 , wherein the memory is configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to: The certification data is transmitted in a TLS certificate message of the TLS handshake message exchange.

3. A computer device according to claim 1 or claim 2, wherein the memory is configured to store executable instructions which, when executed by the processing unit, are configured to cause the processing unit to: The TEE signature is transmitted in a TLS certificate verification message.

4. The computer device of claim 1 or claim 2, wherein the memory is configured to store executable instructions which, when executed by the processing unit, are configured to cause the processing unit to: The TEE signature is transmitted in the TLS certificate message.

5. A computer device according to any preceding claim, wherein the memory is configured to store executable instructions which, when executed by the processing unit, are configured to cause the processing unit to: Instantiate a virtual machine VM as the first TLS endpoint.

6. A computer device according to any preceding claim, wherein the memory is configured to store executable instructions which, when executed by the processing unit, are configured to cause the processing unit to: Receive a TLS Client Hello message from the second TLS endpoint, the Client Hello message comprising: an indication that the second TLS endpoint wants to receive the TLS certificate message including the attestation data; as well as A TLS Server Hello message is generated, the TLS Server Hello message including an indication that the computer device is capable of sending the TLS Certificate message including the attestation data.

7. The computer device of claim 1 or claim 2, wherein the memory is configured to store executable instructions which, when executed by the processing unit, are configured to cause the processing unit to: receiving a second TLS certificate message from the second TLS endpoint, the second TLS certificate message including second attestation data and a second instance-specific public key generated by the second TLS endpoint; verifying the second certification data; Receiving a second TEE signature, the second TEE signature being signed by a second instance-specific private key corresponding to the second instance-specific public key; as well as The second TEE signature is verified using the second instance-specific public key.

8. The computer device of claim 7, wherein the memory is configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to: A certificate request message is sent to the second TLS endpoint, and the second TLS certificate message is received in response.

9. A computer device according to any preceding claim, wherein the memory is configured to store executable instructions which, when executed by the processing unit, are configured to cause the processing unit to: generating a TEE certificate indicating the attestation data and an endpoint-specific public key of the endpoint-specific public key-private key pair; Submit the TEE certificate to the TEE certificate authority CA; Receive an approved TEE certificate from the TEE CA; The approved TEE certificate is included in the TLS handshake message exchange.

10. A computer device according to any preceding claim, wherein the memory is configured to store executable instructions which, when executed by the processing unit, are configured to cause the processing unit to: generating a transcription hash from a transcription of a previous message of the TLS handshake message exchange; The TEE signature is generated based on the transcribed hash.

11. A first transport layer security (TLS) endpoint device, the first TLS endpoint device comprising: Processing unit; a memory coupled to the processing unit and configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to: receiving, within a TLS handshake message exchange with a second TLS endpoint, the attestation data and the instance-specific public key; verifying the certification data; receiving a TEE signature signed by an instance-specific private key corresponding to the instance-specific public key; and The TEE signature is verified using the instance-specific public key.

12. The first TLS endpoint device of claim 11 , wherein the memory is configured to store executable instructions that, when executed by the processing unit, are configured to cause the processing unit to: A TLS Client Hello message is generated, the Client Hello message including an indication that the first TLS endpoint device wants to receive the TLS Certificate message including the attestation data.

13. The first TLS endpoint device according to claim 11 or claim 12, wherein the memory is configured to store executable instructions which, when executed by the processing unit, are configured to cause the processing unit to: sending the attestation data to an attestation endpoint in the network domain of the second TLS endpoint; and In response, a verification of the certification data is received.

14. A computer-implemented method comprising: Instantiate a first Transport Layer Security (TLS) endpoint with access rights to the Trusted Execution Environment (TEE); generating, in the TEE, an endpoint-specific public-private key pair bound to the first TLS endpoint; generating attestation data verifying that the endpoint-specific public-private key pair is generated in the TEE and bound to the first TLS endpoint; signing the attestation report in the TEE using a TEE private key contained in a secure storage element; Generate a TEE signature using the endpoint-specific private key from the endpoint-specific public-private key pair; as well as Within a TLS handshake message exchange between the first TLS endpoint and the second TLS endpoint, the attestation data, the endpoint-specific public key of the endpoint-specific public key-private key pair, and the TEE signature are indicated to the second TLS endpoint.

15. The method according to claim 14, comprising: receiving, at a second TLS endpoint, the attestation data and the instance-specific public key; verifying the certification data; Receiving the TEE signature; as well as The TEE signature is verified using the instance-specific public key.

Images