Certificate issuance depending on key authentication

Abstract

This disclosure relates to certificate issuance that depends on key authentication. The present invention provides streamlined issuance of certificates and other tokens that depend on key authentication from a trusted platform module within a computing platform. Various methods are described for wrapping a requested token in a secret that is an AES key such as a TPM-based key encrypted into a key challenge. If the requesting platform fails the key challenge, the encrypted certificate or token cannot be decrypted. If the requesting platform passes the challenge, the encrypted certificate or token can be decrypted using the AES key recovered from the key challenge.

Description

[0001] Cross - Reference to Related Applications

[0002] This application is a divisional application of a patent application for invention, with international application number PCT / US2017 / 028367, international filing date Apr. 19, 2017, priority date Apr. 19, 2016 / Aug. 26, 2016, date of entry into the Chinese national phase Oct. 19, 2018, Chinese national application number 201780024584.8, and invention title "Certificate Issuance Dependent on Key Authentication".

[0003] This application was filed as a PCT international patent application on Apr. 19, 2017, and claims the priority of U.S. Patent Application No. 15 / 248,463, filed Aug. 26, 2016, which claims the benefit and priority of U.S. Provisional Patent Application No. 62 / 324,747, filed Apr. 19, 2016, the disclosures of which are hereby incorporated herein by reference in their entirety. Technical Field

[0004] The present disclosure generally relates to security authentication, and more particularly to certificate issuance dependent on key authentication. Background Art

[0005] Today's computing systems are increasingly exposed to security threats that can compromise the data stored on the systems and the functionality of the systems themselves. For example, a computing device may be infected with malware that enables unauthorized access to the data stored on the device and / or enables the functionality of the device to be hijacked by an unauthorized party.

[0006] A Trusted Platform Module (TPM) helps improve the security of computing systems. A TPM is a computer chip (microcontroller), which is typically part of a computer motherboard. The TPM provides hardware-based verification and attestation. Verification is the process of proving that a computing device is the device it claims to be. Attestation is the process of proving that a computing device is trustworthy and has not been compromised.

[0007] Generally, a TPM represents a secure processing environment that can be utilized to store security assets (such as security keys, certificates, and passwords) that are used to authenticate a platform (e.g., a computing device, a mobile device, a network device). In addition, a TPM can be utilized to store measurements of the effective device state (e.g., the operating system state), which can be used to determine whether the current device state has been compromised such that the device may be insecure and / or untrustworthy.

[0008] A Trusted Platform Module (TPM) can be used to create public-private key pairs for passwords in such a way that the private key is never disclosed or used outside the TPM. This type of key can be used to ensure that certain cryptographic operations occur within the TPM of a specific computer because any operation using the private key of such a key pair must occur within that specific TPM.

[0009] Encryption, Digital Signatures, and Certificates

[0010] Encryption typically works by using private-public key pairs (referred to as "public key cryptography" or "PKI"). Data encrypted using one key can only be decrypted using the other key from the key pair. The keys in a key pair are related. Typically, the keys are based on prime numbers and have sufficient length (e.g., bits) such that it is very difficult to decrypt the data without the correct key. One key is kept secret (the private key), and the other key (the public key) is distributed. Anyone with the public key can encrypt data, which can then only be decrypted by the holder of the corresponding private key.

[0011] Key pairs can also be used for digital signatures to authenticate that a message comes from the source it is supposed to come from. The owner of the key signs the data using the private key. The recipient of the data can compare the signature with the public key, and if they match, has evidence regarding the identity of the sender of the message.

[0012] For public key cryptography to be valuable, users must be assured that the other parties they communicate with are "secure" - that is, their identities and keys are valid and trustworthy. To provide this assurance, users must have registered identities. These identities are stored in a digital format called a certificate. A Certificate Authority (CA) represents the people, processes, and tools used to create these digital certificates that securely bind a user's name to their public key. When creating a certificate, the CA acts as a trusted proxy. As long as users trust the CA and its business policies for issuing and managing certificates, they can trust the certificates issued by the CA. The CA creates a certificate for a user by digitally signing a dataset that includes the following information:

[0013] · The name of the user in a distinguished name format;

[0014] · The user's public key;

[0015] · The validity period (or lifetime) of the certificate (start date and end date); and

[0016] · The specific operations for which the public key will be used (whether for encrypting data, verifying digital signatures, or both).

[0017] The signature of the CA on the certificate allows any tampering with the content of the certificate to be easily detected. As long as the signature of the CA on the certificate can be verified, the certificate has integrity. Since the integrity of the certificate can be determined by verifying the CA's signature, the certificate is inherently secure and can be distributed in a fully public manner (e.g., through a publicly accessible directory system).

[0018] A user retrieving the public key from the certificate can be assured that the public key is valid. That is, the user can trust the certificate and that its associated public key belongs to the entity designated by the distinguished name. The user also believes that the public key is still within its defined validity period. In addition, the user is assured that the public key can be used securely in the manner for which it was certified by the CA.

[0019] TPM Keys

[0020] Typically, a TPM has two types of keys: an endorsement key ("EK") and an attestation identity key ("AIK").

[0021] The endorsement key (EK) is a restricted cryptographic key (including a private / public key pair) that is typically permanently embedded in the TPM security hardware during manufacturing. The EK is the root of the identity of the TPM. The private part of the EK (EKPriv) is never visible outside the TPM. Since the EK can only be used for encryption, possession of the private EK (EKPriv) can only be indirectly proven by using it to decrypt values that have been encrypted using the public EK (EKPub). Thus, while the EK cannot be used to generate digital signatures, it can provide TPM authentication based on decryption operations. In summary, the private part of the endorsement key (EKPriv) is never released outside the TPM. The public part of the endorsement key (EKPub) helps identify the genuine TPM.

[0022] The attestation identity key ("AIK") is a restricted signature RSA key (including a private / public key pair) that is used to provide platform authentication based on the authentication capabilities of the TPM. The AIK allows the TPM to generate cryptographically signed attestation evidence (statements) about the running state of the platform. These signed statements can enhance current Trusted Network Connect (TNC) protocols, making them more resistant to local attacks by malware and attempts by endpoints to misrepresent their running state.

[0023] Key Authentication

[0024] Key authentication or TPM authentication refers to cryptographically proving that a key originates from (e.g., resides in) the TPM of a specific platform or device. User certificates for keys with TPM authentication provide a higher level of security assurance through the support of non-exportability, anti-hammering, and key isolation provided by the TPM. For example, with TPM key authentication, an administrator can define the set of devices that a user can use to access their company resources, with strong assurance that other devices cannot be used to access them. This access control paradigm is strong because it is tied to the hardware-bound user identity.

[0025] The EK certificate (which also resides in the TPM) is used to bind the identity to the TPM in terms of specific security attributes.

[0026] Real-world use of an AIK, such as health authentication or key authentication, requires AIK trust from the entity of the device health or key data being authenticated. This trust is embodied in the AIK certificate, which is issued from a public server of the AIK issuance service. This certificate is proof that the AIK is a restricted signature TPM key and cannot be used to sign incorrect TPM information (health authentication or key authentication claims). The AIK certificate is used to authenticate the presence of the AIK within the TPM. It is also used to authenticate that other keys attested by the AIK actually originate from that specific TPM.

[0027] However, current implementations of AIK certificate issuance require two or more network hops or round-trips from the client device to the public AIK issuance server. Current implementations of health certificate issuance require two or more round-trips to the AIK issuance server, plus additional hops or round-trips to the health issuance server. Additionally, some private networks do not grant access to the public AIK certificate issuance server, so AIK certificates (and thus health certificates) may not be available on devices restricted to these networks.

[0028] In view of these and other general considerations, aspects of the present technology have been made. Moreover, although relatively specific issues have been discussed, it should be understood that the aspects of the technology presented should not be limited to solving the specific problems identified in the background art. SUMMARY OF THE INVENTION

[0029] The present invention provides for a streamlined issuance of certificates and other tokens (such as decryption keys, signature keys, authentication credentials for logging into other systems or websites, and licenses for enabling customer-specific functionality) that depends on key authentication (such as, for example, key authentication of keys from a trusted platform module within a computing platform). More specifically, the present disclosure teaches systems and methods for obtaining certificates and other tokens that depend on key authentication within a single round-trip between a requesting client and an issuing server. Various methods are described for wrapping a requested certificate (or other token) in a server key (such as an AES key that the server encrypts into a public EK in a key challenge). The encrypted certificate (or other token) cannot be decrypted if both the EK and AIK keys are not present on the TPM. If both keys are present on the TPM, the AES key recovered from the key challenge can be used to decrypt the certificate (or other token).

[0030] In an embodiment, the present invention provides for server-side verification of a client's request for a health certificate without the need for an AIK certificate. The client sends a key authentication statement and a health authentication statement to a server that issues the health certificate. The server will create a key authentication challenge that the client needs to decrypt to prove the residency of the EK and AIK, and at the same time, the server will also create a health authentication blob that the client needs in order to advance the health authentication. The server sends this data back to the client. If the key authentication challenge is valid, the client will be able to decrypt the health authentication blob and will be in the same state as if the client had an AIK certificate (except that only a single round-trip to the health server is required and no communication with a public AIK issuance service is needed).

[0031] In another embodiment, the present invention provides for server-side verification of a request for an AIK certificate and the issuance of this certificate with a single hop or round-trip to an AIK issuance server. When the server receives a request for an AIK certificate, it creates a key authentication challenge that the client needs to decrypt to prove the residency of the EK and AIK, and at the same time, the server will also use a secret (such as an AES key or a server key) wrapped in the key authentication challenge to encrypt the AIK certificate. The server sends this data back to the client. If the key authentication challenge is valid, the client will be able to decrypt the AIK certificate without sending additional proof to the server.

[0032] It will be appreciated that these are only a few examples and other examples can be expected. Additionally, while this disclosure describes examples of authentication of key statements and health statements, this disclosure is applicable to any server-side verification of TPM statements involving keys that need to be authenticated. Additionally, while this disclosure describes the issuance of health certificates and AIK certificates, this disclosure relates to a server issuing any certificate or any other token to a client computer, including, for example, decryption keys, signature keys, authentication credentials for logging into other systems or websites, and licenses for enabling client-specific functionality.

[0033] Furthermore, the present invention content is provided to introduce some concepts that will be further described in the detailed implementation section below. The present invention content is not intended to identify the key features or essential features of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] The detailed description is described with reference to the accompanying drawings. In the drawings, the leftmost digit(s) of the reference numeral identify the figure in which the reference numeral first appears. The use of the same reference numeral in different instances in the specification and drawings may indicate similar or identical items.

[0035] Figure 1 is an illustration of an environment in an example implementation operable to employ the techniques discussed herein in accordance with one or more embodiments of the present invention.

[0036] Figure 2 depicts a conventional implementation of key authentication.

[0037] Figure 3 depicts a conventional implementation of health authentication.

[0038] Figure 4 depicts an example implementation of health authentication in accordance with one or more embodiments of the present invention.

[0039] Figure 5 depicts an example implementation of key authentication in accordance with one or more embodiments of the present invention.

[0040] Figure 6 is a flowchart illustrating the steps in a method for verifying a key authentication statement in accordance with one or more embodiments of the present invention.

[0041] Figure 7 is a flowchart illustrating the steps in a method for verifying a health authentication statement in accordance with one or more embodiments of the present invention.

[0042] Figure 8 is a flowchart illustrating the steps in a method for creating a key challenge in accordance with one or more embodiments of the present invention.

[0043] Figure 9 depicts an example implementation of a health certificate based on key authentication and health authentication according to one or more embodiments of the present invention.

[0044] Figure 10 is a flowchart illustrating steps in a method for a client to evaluate a key challenge (e.g., an EK challenge) received from a server according to one or more embodiments of the present invention. Detailed Description

[0045] Figure 1 is an illustration of an environment 100 in an example implementation that is operable to employ techniques based on key authentication and health authentication discussed herein.

[0046] The environment 100 includes a client device 102, which can be embodied as any suitable device, such as, by way of example and not limitation, a smart phone, a tablet computer, a portable computer (e.g., a laptop computer), a desktop computer, a wearable device, etc. An example of one of the various different examples of the client device 102 is shown and described below in Figure 9 One example of the various different examples of the client device 102 is shown and described below in

[0047] The client device 102 includes various different functions that support the execution of various activities and tasks. For example, the client device 102 includes an operating system 104 and an application 106. Generally, the operating system 104 represents a function for abstracting the various system components of the client device 102, such as hardware, kernel-level modules, and services, etc. For example, the operating system 104 can abstract the various components of the client device 102 to the application 106 to support the interaction between the components and the application 106.

[0048] The application 106 represents a function that supports the execution of various tasks and activities via the client device 102, such as word processing, web browsing, email, social media, enterprise tasks, etc. The application 106 can be locally installed on the client device 102 to be executed via a local runtime environment, and / or can represent a portal to remote functions (such as cloud-based services, web applications, etc.). Thus, the application 106 can take various forms, such as locally executed code, a portal to remotely hosted services, etc.

[0049] The client device 102 also includes a Trusted Platform Module (TPM) 108, which represents a part of the client device 102 that is protected from general access by most or all other functions of the client device 102. The TPM 108 can be implemented in various ways, such as a separate, dedicated hardware environment (e.g., a dedicated chip), a segmented part of an existing hardware environment (e.g., a sub-part of a central processing unit (CPU)), a protected firmware environment, etc. In one or more implementations, the TPM 108 is a module according to the Trusted Platform Module (TPM) specification available from the Trusted Computing Group (TCG). Those skilled in the art will appreciate that there can be other TPMs. Substantially, any protected module can act as a TPM for the purposes of this application.

[0050] According to various implementations, the interaction with the TPM 108 is brokered by a TPM access module 110. Generally, the TPM access module 110 represents a function that enables different components of the client device 102 (such as components of the operating system 104, applications 106, etc.) to interact with the TPM 108. For example, the TPM access module 110 represents a device driver for the TPM 108. The TPM access module 110 can be implemented in various ways, such as components of the operating system 104, separate system components of the client device 102 (e.g., kernel-level components), combinations thereof, etc.

[0051] The TPM 108 includes a TPM processor 112 and a TPM storage 114. According to various implementations, the TPM processor 112 represents a dedicated hardware processing unit that can be utilized by the TPM 108 to perform various processing tasks. The TPM storage 114 represents the data storage capacity for the TPM 108 and is protected from access by entities external to the TPM 108.

[0052] Stored on the TPM storage device 114 is a security asset 116, which represents different types of security-related information that can be used to verify the identities of certain entities, the authenticity and / or trust status of various types of data, etc. Examples of security assets 116 include security keys (e.g., cryptographic keys), security certificates, encryption and decryption algorithms, protected data, etc. In a particular implementation, the security asset 116 includes an endorsement key (EK) 118 (including a private key (EKPriv) 118a and a public key (EKPub) 118b), an attestation identity key (AIK) 120 (including a private key (AIKPriv) 120a and a public key (AIKPub) 120b), and an endorsement key certificate (EIC) 122. As used herein, the terms "AIK" and "AIK 120" may refer to the public key (AIKPub) and / or the private key (AIKPriv). As used herein, the terms "EK" and "EK 118" may refer to the public key (EKPub) and / or the private key (EKPriv). Details regarding ways in which the security asset 116 can be configured and utilized are discussed below.

[0053] The TPM 108 also includes platform functions 124, platform registers 126, and a boot counter 128. The platform functions 124 represent various functions for providing secure storage of information, such as verification functions, key generation functions, encryption and decryption functions, context-related functions, etc. According to various implementations, the TPM access module 10 may interact with the platform functions 124 to perform various aspects of techniques for health attestation based on the key attestation and health attestation described herein.

[0054] The platform registers 126 represent storage locations for storing the system state and context information of the client device 102. For example, the platform registers 126 may be used to store "measurements" of various system components, such as measurements of modules of the operating system 104 collected at system boot. In at least some implementations, the platform registers represent the platform configuration registers (PCRs) of the TPM 108.

[0055] Generally, "measurement" refers to a way of identifying and / or characterizing various device-related data (such as code modules of the client device 102, configuration data of the client device 102, etc.). As used herein, the term "code module" generally refers to a portion of executable code, such as portions of applications 106, services, modules of the operating system 104, processes, various binary files, and / or executable files, etc. Examples of measurements include hash values generated from device-related data, data signatures, encrypted versions of device-related data, and / or portions of device-related data, etc. For example, a measurement can be generated by applying a secure hash algorithm (SHA) (e.g., SHA-1, SHA-2, etc.) to device-related data.

[0056] The boot counter 128 represents a function for tracking when the client device 102 is booted and rebooted. For example, the boot counter 128 maintains a boot value that is modified each time the client device 102 is rebooted. Generally, the boot counter 128 can be used to distinguish different boot states of the client device 102.

[0057] The environment 100 also includes a health service server (“health service”) 130 that can be communicatively accessed by the client device 102 via the local network 132. Generally, the health server 130 represents a resource with which the client device 102 can interact to support performing various trust-related transactions (such as obtaining a health certificate for the client device 102). The health server 130 can be implemented via various types and / or combinations of computing devices, examples of which are described below in Figure 3 and Figure 4 are described.

[0058] The local network 132 represents a network through which various entities of the environment 100 can communicate. The local network 132 can adopt various different configurations, such as a local area network (LAN) for entities such as enterprise entities, government entities, educational entities, etc. In at least some implementations, as indicated by the dashed line 136, data communicated between the client device 102 and the health server 130 is prevented from being exposed outside the local network 132. For example, the communication between the client device 102 and the health server 130 can be restricted within the local network 132 and not allowed to cross to a network outside the local network 132, such as the public network 140.

[0059] The health server 130 can include verification assets 134, which represent different security-related assets that enable the health server 130 to verify the validity of certain claims made by the client device 102. Examples of verification assets 134 include cryptographic keys, certificates, identities of different certificate authorities, etc.

[0060] The client 102 can access the AIK certificate issuance service 150 via the public network 140. The AIK issuance service can include a certificate authority for issuing AIK certificates.

[0061] An example environment in which the techniques described herein may operate has been described. Now consider a discussion of an example TPM key authentication that utilizes an endorsement key (EK) of a TPM. The endorsement key (EK) of a TPM is injected into the TPM during manufacturing and is unique for each TPM. Trust in the EK is based on the secure and tamper-resistant storage of the EK in the TPM and the fact that the certificate of the EK is linked to the issuing CA of the TPM manufacturer. "Chain" means that the certificate of the EK can be cryptographically verified by using the certificate of the issuing CA of the TPM manufacturer.

[0062] Figure 2 FIG. illustrates a conventional process 200 for TPM key authentication by obtaining an attestation identity key (AIK) certificate from an AIK service 150 located on a public server. At step 202, the TPM access module 110 communicates a key authentication instruction (key instruction) to the TPM 108. Generally, the key setup 202 instructs the TPM 108 to create a key authentication statement (key statement). In response to receiving the key instruction 202, the TPM 108 performs a key authentication process 204 to generate a key statement for obtaining an AIK certificate that attests that the AIK key 118 is included within the TPM 108. The key statement includes a public AIK (AIKPub) 120b and a public EK (EKPub) 118b and is signed using a private AIK (AIKPriv) 120a. For example, the key statement is generated as a signed AKPriv (AIKPub, EKPub). After the key statement is generated at step 204, at step 206, the TPM 108 communicates the key statement to the TPM access module 110.

[0063] The TPM 110 sends the key statement to a server having an AIK certificate authority for verification, such as the AIK issuing service 150. As shown by the dashed line 136, the server 150 is outside the local network 132 (shown in Figure 1 ). At step 210, the server 150 uses the AIK public key from the key statement to verify the signature (i.e., AIKPriv). If the key statement passes verification, the server 150 creates an EK challenge at step 212. The EK challenge is a nonce encrypted by the public version of the EK (EKPub 118b) of the client 102 from the key statement. At step 214 and step 216, the server 150 sends the EK challenge to the TPM 108 via the TPM access module 110.

[0064] At step 218, the TPM 108 verifies that the AIK 120 in the EK challenge co-resides in the TPM with the EKPub used to sign the EK challenge. If so, at step 220, the TPM 108 decrypts the nonce using the EKPriv 118a residing on the TPM. If the TPM 108 is able to decrypt the nonce, the client 102 will send the decrypted nonce back to the server 150 (via the TPM access module 110) at steps 222 and 224 to prove that it has passed the authentication check (i.e., the AIK resides in the TPM). At this point, the server 150 will issue a certificate for the AIK at step 226 and send the AIK certificate back to the client 102 at step 228. The client will store the AIK certificate. As Figure 2 shown, the traditional key authentication process requires two separate round trips from the client 102 to the server 150, as shown by the curved arrows 230 and 232.

[0065] Figure 3 FIG. illustrates a traditional process 300 for health authentication. At step 302, the TPM access module 110 conveys a health authentication instruction (health instruction) to the TPM 108. The health instruction instructs the TPM 108 to create a health authentication statement (health statement). In response to step 304, the TPM 108 generates a health statement including references (e.g., PCRs) from the platform registers 126 and the boot counter 128 and signs the PCRs using the AIKPriv 120a. Then, at step 306, the TPM 108 communicates the health statement to the TPM access module 110. Also, in response to the health instruction 302, the TPM 108 sends the AIK certificate (such as the certificate received using the Figure 2 process shown in FIG.) and the TCG log (at step 310) to the TPM access module 110 at step 308. The TCG log includes measurements of various modules and / or binary files residing (e.g., stored, loaded, and / or run) on the client device 102. For example, when a health certificate is requested, measurements of various modules and processes are captured and will be stored as part of the TCG log.

[0066] Next, the TPM access module 110 generates a health certificate request including the health statement, the log, and the AIK certificate at step 312 and sends the certificate request to the health authentication server 130. The request can be routed using a uniform resource indicator (URI) identifying the health server 130. The health server 130 is in the same local network 132 as the client device.

[0067] The health server 130 receives a health certificate request and performs a verification process 314 to confirm that the AIK certificate is issued by a known and trusted certificate authority (CA), and that the AIK certificate is valid and not revoked. It then extracts AIKPub from the certificate. The server trusts AIKPub because it comes from the AIK certificate. At step 316, the server 130 determines the validity of the health claim by checking to ensure that the AIK public key (AIKPub) from the AIK certificate matches the AIKPriv used to sign the health claim. At step 316, the server 130 also checks the PCRs in the health claim against the log to ensure they match. In this particular example, the verification process 316 determines that the health claim is valid, and thus the health server 130 generates a health certificate at step 318 that certifies the health status of the client device 102. For example, the health certificate identifies the client device 102 and indicates that the client device 102 is currently in a secure state. Then, at step 320, the server 130 conveys the health certificate to the client 102.

[0068] The traditional health authentication process 300 requires three round trips to the server: two round trips from the client 102 to the public AIK server 150 and back (as shown by arrows 230 (first round trip) and 232 (second round trip) in Figure 2 , plus a third round trip from the client 102 to the health authentication server 130 and back (as shown by arrow 234 in Figure 3 ).

[0069] Figure 4 illustrates a health authentication process 400 according to an embodiment of the present invention. The health authentication process 400 has several advantages over the Figure 2 and Figure 3 traditional process shown in. For example, process 400 does not require the client 102 to provide an AIK certificate to the server 130 to receive a health certificate. Additionally, as shown by arrow 434, process 400 requires only one hop to the server. Further, process 400 does not require the client 102 to communicate with any server or service external to the local network 132 to receive a health certificate.

[0070] Process 400 begins with ascertaining that a health certificate is to be retrieved for the client device. For example, the client device 102 receives a request to authenticate the health of the client device 102 from a particular application / service. Alternatively or additionally, the client device 102 automatically initiates a health certificate retrieval process, such as in response to a reboot of the client device 102.

[0071] At step 402, the TPM 108 sends a key statement to the TPM access module 110. In an embodiment, the key statement is created in response to a key instruction sent from the TPM access module 110 to the TPM 108. The key statement may include AIKPub 120b and EKPub 118b signed with AIKPriv 120a.

[0072] At step 404, the TPM 108 sends a health statement to the TPM access module 110. In an embodiment, the health statement is created in response to a health instruction sent from the TPM access module 110 to the TPM 108. The health statement may include the PCR signed with AIKPriv 120a.

[0073] The TPM access module 110 may already have an EK certificate, but if not, the TPM 108 sends the EK certificate 122 to the TPM access module 110 at step 406. At step 408, the TPM 108 sends the TPM access module 110 and the TCG log. Although steps 402, 404, 406, and 408 are shown as being sent in a particular order, they may be sent from the TPM 108 to the TPM access module 110 in any order. Additionally, these steps may be performed separately or grouped into one or more communications to the TPM access module 110.

[0074] The TPM access module 110 receives the key statement, the health statement, the log, and the EK certificate 122. The TPM access module then creates a health certificate request, which may include the health statement, the key statement, the log, and the EK certificate 122, and at step 410, sends the request to the health service server 130. In at least some implementations, the request, the key authentication statement, the EK certificate, and the health authentication statement are sent to the health service 130 as part of a single communication from the client device 102.

[0075] At step 411, the server extracts the EK certificate from the health certificate request and verifies that the EK certificate was issued by a known and trusted CA, that the certificate is valid and not revoked. Then it extracts EKPub from the EK certificate.

[0076] At step 412, the server 130 verifies the key statement, as described in detail regarding Figure 6 If the verification step 412 passes, the process 400 proceeds to step 414 of creating an EK challenge.

[0077] At step 414, the server creates an EK challenge, which will be regarding Figure 8Detailed description. Generally, the process includes generating a secret, such as an AES key (or server key) 418, encrypting the key using EKPub 118a extracted from the EK certificate in step 411, and then packaging it together with the AIKPub key received in the key statement.

[0078] At step 416, server 130 verifies the health statement as described with respect to Figure 7 Detailed description. Generally, the server verifies that the signature on the PCR reference is correct and consistent with the TCG log value by using AIKPub from the key statement. At this point, AIKPub is not trusted (since the server has not received the AIK certificate), but the server will check whether AIKPub exists on the same TPM as the specified EKPub, and based on the EK certificate reviewed in step 411, the specified EKPub is known to be valid. At step 416, server 130 also checks the PCRs in the health statement against the log to ensure they match. If the verification process 416 determines that the health statement is valid, then health server 130 generates a health certificate at step 420.

[0079] If one or more of the EK certificate, key authentication statement, or health authentication statement are not verified or determined at steps 411, 412, or 416, then server 130 rejects the request for the health certificate and thus does not generate a health certificate for client device 102. In at least some implementations, health service 130 returns a notification to client device 102 indicating that the request was rejected. The notification may also include other information, such as which of the key authentication statement and / or health authentication statement was determined to be invalid and why the particular statement(s) were determined to be invalid.

[0080] Assuming that the verification checks 411, 412, and 416 pass, then at step 422, server 130 creates a health blob by encrypting the health certificate with the AES key and packaging it with an EK challenge including AIK 120.

[0081] In Figure 10 is shown in detail the processing of the health blob by the client as shown in steps 424 - 432 as Figure 4 Continuing to step 424, health server 130 sends the health blob to client device 102 at step 424, and TPM access module 110 parses the health blob to retrieve the encrypted AES key, AIK 120, and the encrypted health certificate. In at least some implementations, the health blob represents a single integrated communication from health service 130 to client device 102.

[0082] At this time, the TPM access module 110 cannot decrypt the health certificate because it cannot decrypt the encrypted AES key used to encrypt the health certificate. Accordingly, at step 426, the TPM access module 110 sends a decryption request to the TPM 108 that includes the encrypted AES key (i.e., the encrypted EKPub (AES key)). If the TPM 108 has a private EK (EKPriv) that matches the EKPub used to encrypt the AES key, then it will be able to perform the decryption process 428 to generate the decrypted AES key. If the TPM can decrypt the AES key, then it will send the AES key back to the access module 110 at step 430. In an embodiment, the decryption request 426 may also include the AIK 120 (from the EK challenge). As part of the decryption process 428, the TPM may also check to ensure that the AIK from the challenge co-resides in the TPM with the EK used to encrypt (e.g., EKPub) and / or decrypt (e.g., EKPriv) the AES key. If the TPM is unable to decrypt the AES key, this means that it has failed the EK challenge because the TPM does not have the EK related to the health certificate request that it told the server it had, or the AIK and the EK are not in the same TPM.

[0083] When the TPM access module 110 receives the AES key, it uses the AES key to decrypt 432 the encrypted health certificate. The client device 102 locally stores the health certificate 220 for authenticating the health of the current state of the client device 102.

[0084] In at least some implementations, the health certificate 220 is boot state sensitive. For example, if the client device 102 reboots after receiving the health certificate 220, the health certificate 220 may expire. In such a case, the scenario 400 may be re-initiated to obtain a new health certificate based on the current boot state of the client device 102.

[0085] Figure 5 A key authentication process 500 according to an embodiment of the present invention is shown. The key authentication process 500 has advantages over Figure 2 the conventional process shown in because it only requires one hop to the server, as indicated by the arrow 534. Although Figure 5Illustrated is a request for an AIK certificate (see step 508) to the AIK issuance server 150 and the issuance of the AIK certificate, but method 500 is generally not limited to AIK certificates or even certificates. It can be used to request any type of token, where it is only necessary to ensure that the client can access / use the token when key authentication is successful (e.g., the client can prove that it has the EK and AIK keys in its TPM), thus ensuring that no other system can access the token by hijacking the request and / or response. Examples of tokens that can be securely passed to the client using method 500 include, but are not limited to, decryption keys, signature keys, authentication tokens for logging into other systems or websites, and permissions to enable certain features on a particular client machine.

[0086] At step 502, the TPM access module 110 conveys a key authentication instruction (key instruction) to the TPM 108. Generally, the key instruction instructs the TPM 108 to create a key authentication statement (key statement). In response to receiving the key instruction, the TPM 108 generates a key statement. The key statement includes the public AIK (AIKPub) 120b and the public EK (EKPub) 118b, and is signed using the private AIK (AIKPriv) 120a. For example, the key statement is generated as a signed AIKPriv (AIKPub, EKPub). After the key statement is generated at step 504, the TPM 108 conveys the key statement to the TPM access module 110 at step 506. In response to the key instruction or at some earlier point in time, the TPM 108 sends the EK certificate 122 to the TPM access module 110. Step 503 and step 506 can occur in any order and can be sent together or separately.

[0087] At step 508, the TPM 110 sends an AIK certificate request to a server having an AIK certificate authority for verification (e.g., the AIK issuance service 150). The request includes the key statement and the EK certificate.

[0088] At step 510, the server extracts the EK certificate from the AIK certificate request and verifies that the EK certificate is issued by a known and trusted CA, that the certificate is valid, and that it has not been revoked. Then it extracts the EKPub from the EK certificate.

[0089] At step 511, the server 130 verifies the key statement, as described in detail regarding Figure 6 If the verification step 511 passes, the process 500 proceeds to step 512, where it issues the AIK certificate.

[0090] At step 514, the server creates an EK challenge, which regarding Figure 8DETAILED DESCRIPTION. Generally, the process includes generating an AES key 516, encrypting the key using the EKPub 118a extracted from the EK certificate in step 510, and then packaging it together with the AIK received in the key claim.

[0091] At step 514, the server 150 creates an AIK blob including the AIK certificate, which is encrypted using the AES key and wrapped in the EK challenge. At step 520, the server sends the AIK blob to the TPM access module.

[0092] At Figure 10 is shown in detail the client's processing of the health blob as shown in steps 520 - 528 of Figure 5 Generally, the TPM access module 110 parses the AIK blob to extract the EK challenge and sends a decryption request (with the encrypted AES key and AIK) to the TPM 108 at step 522.

[0093] At step 524, the TPM 108 verifies that the AIK co - resides in the TPM with the EKPub used to sign the EK challenge. The TPM 108 also attempts to decrypt the AES key using the EKPriv 118a residing on the TPM. If the AIK co - resides with the EK and the TPM 108 can decrypt the AES key using the EKPriv, then the client 102 sends the AES key back to the TPM access module 110 at step 526. Then, the TPM access module 110 will be able to decrypt the AIK certificate using the AES key at step 528. In this way, the client obtains the AIK certificate through a process that includes a single round - trip to the AIK server 150 (see arrow 534).

[0094] Figure 6 is a flowchart depicting the steps of a method according to one or more embodiments of the present invention. For example, method 600 describes an example process for verifying the validity of a key authentication claim. In at least some implementations, Figure 6 illustrates a way for performing Figure 4 step 412 of Figure 5 and step 512 of

[0095] Process 600 begins at step 602, which verifies the signature of the key authentication claim. For example, the health service 130 verifies the signature of the key authentication claim of AiKPriv(AIKPub, EKPub)'s signature is valid. It does this by checking to ensure that AIKPub matches the AIKPriv used for the signature key claim. In one embodiment, AIKPub is extracted from the key claim received from the server. In other embodiments, AIKPub can be obtained from another source. If AIKPub and AIKPriv match ("yes"), then method 600 proceeds to step 612, where it is determined that the key claim is valid. If they do not match, then method 600 cannot verify the key claim and proceeds to step 610.

[0096] Returning to step 604, the server checks to confirm that the EK certificate it received is from a known and trusted certificate authority, that it is valid, and that it has not been revoked. If all of these are true ("yes"), then method 600 proceeds to step 612, where it is determined that the key claim is valid. If any of these is not true ("no"), then method 600 cannot verify the key claim and proceeds to step 610.

[0097] Although steps 602 and 604 are shown in a particular order, for the purposes of the present invention, they can be performed in any order.

[0098] Figure 7 is a flowchart depicting steps in method 700 according to one or more embodiments of the present invention. For example, the method describes an example process for verifying the validity of a health attestation claim (e.g., a health claim). In at least some implementations, the process describes an example way of performing aspects of step 416 of the process described above with reference to Figure 4 the process described.

[0099] Step 702 parses the health attestation claim to identify the platform register (PCR) reference and the attestation log. As discussed above, the platform register reference includes measurements from known secure portions of the code from client device 102, such as from code modules, binaries, executables, etc. For example, the platform register reference represents measurements retrieved from the platform configuration registers of TPM 108. The attestation log represents measurements of the code loaded and / or run on client device 102. For example, when a request for a health certificate for client device 102 is initiated, measurements of the code loaded and / or run on client device 102 are captured and stored as part of the attestation log.

[0100] Step 704 verifies the signature of the health claim, which is signed using the private AIK 120a (i.e., AIKPriv). Thus, the health service 130 verifies that the platform register reference utilizes a valid AIKPriv signature. It does this by checking to ensure that the AIKPub matches the AIKPriv used to sign the key claim. If they match ("yes"), method 700 proceeds to step 706. If they do not match, method 600 cannot verify the health claim and proceeds to step 708.

[0101] Step 706 determines whether the authentication log matches the platform register reference. For example, the health service 130 compares the measurements of the code modules included in the authentication log with the measurements of the corresponding code in the platform register reference. For example, the health service 130 determines whether a particular measurement for a particular section of code from the authentication log matches a particular measurement for a particular section of code from the platform register 126. In at least some implementations, a mismatch between the authentication log and the platform register 126 may indicate that part of the code has been tampered with, such as by a hacker, malware, etc. This may indicate that the client device 102 is in an insecure state, which will result in the authentication claim failing, thereby preventing the issuance of a valid health certificate for the client device 102. If the authentication log does not match the platform register reference ("no"), method 700 proceeds to step 708 and determines that the health authentication claim is invalid.

[0102] If the authentication log matches the platform register reference ("yes"), method 700 determines at 710 that the health authentication claim is valid, and the process for issuing a health certificate for the client device 102 can continue.

[0103] Although steps 704 and 706 are shown in a particular order, for the purposes of the present invention, they may be performed in any order.

[0104] Figure 8 is a flowchart depicting steps in method 800 according to one or more embodiments of the present invention. More specifically, Figure 8 illustrates an example method for generating an EK challenge, as shown in step 414 of Figure 4 and step 514 of Figure 5 In an embodiment, process 800 is performed by a server, such as server 150 having an AIK issuance service or server 130 having a health certificate service.

[0105] Method 800 begins at step 802 by generating a secret. In at least some implementations, the secret represents a symmetric cryptographic key (e.g., an AES key) that can be used for encrypting and decrypting data.

[0106] At step 804, the public endorsement key (EKPub) is extracted from the endorsement key certificate. For example, in one embodiment, in Figure 4 step 410 of, the health service 130 extracts the EKPub 120b from the EK certificate 122 received from the client device 102. In another embodiment, the AIK service 150 extracts the EKPub from the EK certificate it receives from the client device in Figure 5 step 508. In an alternative embodiment, the EKPub may come from another source, such as a key statement.

[0107] At step 806, the server encrypts the AES key with the public EK to form an encrypted EKPub (AES key).

[0108] At step 808, the server packages the encrypted AES key with an AIK (such as AIKPub and / or AIKPriv) from a key statement or other source to form an EK challenge.

[0109] Figure 10 is a flowchart depicting steps of a method according to one or more embodiments of the present invention. For example, method 1000 describes an example process for receiving and responding to a key challenge (such as the EK challenge described with reference to Figure 4 and Figure 5 ). At least in some implementations, Figure 10 illustrates a way for performing Figure 4 steps 424 - step 432 of and Figure 5 steps 520 - step 528 of. In an embodiment, the process 1000 is performed by a client such as the client 102.

[0110] Method 1000 begins at step 1002, where the client 102 receives a blob such as a health blob or an AIK blob. At step 1004, the client parses the blob to retrieve the EK challenge and the encrypted certificate. At step 1006, the client extracts the encrypted AES key (or other server secret) and the encrypted certificate. At this point, the client cannot decrypt the encrypted certificate because the key it needs is encrypted in the EK challenge. The client must pass the EK challenge in order to decrypt the encrypted certificate. To pass the EK challenge, the client must prove that the AIK extracted from the challenge co-resides in the same TPM as the EK (e.g., the AES key) used to encrypt the server secret (see step 1008).

[0111] Determine whether the client can pass the EK challenge in two steps (1008a and 1008b), which can occur in any order. At step 1008a, the client determines whether the AIK extracted from the EK challenge resides in the client's TPM by comparing the AIK extracted from the EK challenge with the AIK residing in the TPM. If they match ("yes"), the method moves to step 1008b. If they do not match ("no"), the client fails the EK challenge (step 1016).

[0112] Returning to step 1008b, the client attempts to decrypt the server's secret using EKPriv from the TPM 108. If the decryption is successful ("yes"), the method passes the EK challenge at step 1010 and continues to decrypt the encrypted certificate using the decrypted server secret at step 1012. On the other hand, if the decryption is not successful (step 1008b is "no"), the method fails the EK challenge at step 1016.

[0113] Figure 9 An example system including an example computing device 902 is generally illustrated at 900. The example computing device 902 represents one or more computing systems and / or devices that can implement the various techniques described herein. For example, the client device 102 and / or the health service 130 discussed above with reference to Figure 1 can be embodied as the computing device 902. The computing device 902 can be, for example, a server of a service provider, a device associated with a client (e.g., a client device), a system-on-chip, and / or any other suitable computing device or computing system.

[0114] The example computing device 902 illustrated as including a processing system 904, one or more computer-readable media 906, and one or more input / output (I / O) interfaces 908, which are communicatively coupled to each other. Although not shown, the computing device 902 may also include a system bus or other data and command transfer system that couples the various components to each other. The system bus can include any one or combination of different bus structures (such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus utilizing any bus architecture in various bus architectures). Various other examples are also contemplated, such as control lines and data lines.

[0115] The processing system 904 represents the functionality to perform one or more operations using hardware. Accordingly, the processing system 904 is illustrated as including hardware elements 910 that can be configured as a processor, functional blocks, and the like. This can include being implemented in hardware as an application specific integrated circuit or other logic device formed using one or more semiconductors. The hardware elements 910 are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, a processor can include (multiple) semiconductors and / or transistors (e.g., an electronic integrated circuit (IC)). In such a context, the instructions executable by the processor can be electronically executable instructions.

[0116] The computer-readable medium 906 is illustrated as including a memory / storage device 912. The memory / storage device 912 represents the memory / storage capacity associated with one or more computer-readable media. The memory / storage device 912 can include volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical discs, magnetic disks, etc.). The memory / storage device 912 can include fixed media (e.g., RAM, ROM, fixed hard disk drive, etc.) as well as removable media (e.g., flash memory, removable hard disk drive, optical disc, etc.). The computer-readable medium 906 can be configured in various other ways as further described below.

[0117] (Multiple) input / output interfaces 908 represent the functionality that allows a user to enter commands and information into the computing device 902 and also allows information to be presented to the user and / or other components or devices using various input / output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone (e.g., for speech recognition and / or voice input), a scanner, a touch functionality (e.g., a capacitive sensor or other sensor configured to detect physical touch), a camera (e.g., that can use visible or non-visible wavelengths (such as infrared frequencies) to detect movement not involving touch as a gesture), etc. Examples of output devices include a display device (e.g., a monitor or a projector), a speaker, a printer, a network card, a haptic response device, etc. Thus, the computing device 902 can be configured in various ways as further described below to support user interaction.

[0118] Various technologies can be described herein in the general context of software, hardware elements, or program modules. Generally, such modules include routines, programs, objects, elements, components, data structures, etc. that perform specific tasks or implement specific abstract data types. As used herein, the terms "module", "function", "entity", and "component" generally represent software, firmware, or a combination thereof. The features of the technologies described herein are platform independent, meaning that these technologies can be implemented on various commercial computing platforms having various processors.

[0119] The implementation of the described modules and techniques can be stored on or transmitted across some form of computer-readable medium. The computer-readable medium can include various media that can be accessed by computing device 902. By way of example and not limitation, the computer-readable medium can include "computer-readable storage media" and "computer-readable signal media". "Computer-readable storage media" can refer to media and / or devices that support persistent storage of information as compared to merely signal transmission, carrier waves, or signals themselves. Computer-readable storage media do not include signals per se. Computer-readable storage media include hardware such as volatile and non-volatile, removable and non-removable media and / or storage devices implemented in a method or technology suitable for storage of information such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data. Examples of computer-readable storage media can include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disks (DVDs) or other optical storage devices, hard disks, magnetic cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or other storage devices, tangible media, or articles suitable for storing the desired information and accessible by a computer.

[0120] "Computer-readable signal media" can refer to a signal-bearing medium configured to transmit instructions to computing device 902, such as via a network. Signal media typically can embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal (such as a carrier wave, data signal), or other transmission mechanisms. Signal media also include any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency (RF), infrared, and other wireless media. As previously described, hardware elements 910 and computer-readable medium 906 represent instructions, modules, programmable device logic, and / or fixed device logic implemented in hardware form, which can be employed in some embodiments to implement at least some aspects of the techniques described herein. Hardware elements can include components of an integrated circuit or system-on-chip, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), and other implementations in silicon or other hardware devices. In this context, the hardware elements can operate as processing devices that execute program tasks defined by instructions, modules, and / or logic embodied by the hardware elements and the hardware devices used to store instructions for execution (e.g., the computer-readable storage media described above).

[0121] The various techniques and modules described herein can also be implemented using the foregoing combinations. Accordingly, software, hardware, or program modules and other program modules can be implemented as one or more instructions and / or logic embodied on a computer-readable storage medium of some form and / or by one or more hardware elements 910. The computing device 902 can be configured to implement specific instructions and / or functions corresponding to the software and / or hardware modules. Accordingly, an implementation that can be software-executable by the computing device 902 can be at least partially implemented in hardware, e.g., by using the computer-readable storage medium and / or the hardware elements 910 of the processing system. The instructions and / or functions can be executable / operable by one or more articles of manufacture (e.g., one or more computing devices 902 and / or processing system 904) to implement the techniques, modules, and examples described herein.

[0122] As Figure 9 further illustrated in, when running an application on a personal computer (PC), a television device, and / or a mobile device, the example system 900 supports a ubiquitous environment for a seamless user experience. When transitioning from one device to the next while using an application, playing a video game, watching a video, etc., for an average user experience, the services and applications run substantially similarly across all three environments.

[0123] In the example system 900, multiple devices are interconnected by a central computing device. The central computing device can be local to the multiple devices or can be located remotely from the multiple devices. In one embodiment, the central computing device can be a cloud of one or more server computers connected to the multiple devices via a network, the Internet, or other data communication links. In one embodiment, this interconnection architecture supports the delivery of functionality across multiple devices to provide a common and seamless experience to users of the multiple devices. Each of the multiple devices can have different physical requirements and capabilities, and the central computing device uses a platform to support the delivery of an experience to the devices that is customized for the devices yet common to all devices. In one embodiment, a class of target devices is created and the experience is customized for the general class of devices. The class of devices can be defined by physical characteristics, type of use, or other common characteristics of the devices. In various implementations, the computing device 902 can assume a variety of different configurations, such as for use with a computer 914, a mobile device 916, and a television 918. Each of these configurations includes devices that can have generally different constructs and capabilities and, thus, the computing device 902 can be configured according to one or more different device classes. For example, the computing device 902 can be implemented as a class of devices including a personal computer, a desktop computer, a multi-screen computer, a laptop computer, a netbook, etc., of the computer 914.

[0124] The computing device 902 may also be implemented as a class of mobile device 916, including mobile devices such as mobile phones, portable music players, portable gaming devices, tablet computers, wearable devices, multi-screen computers, etc. The computing device 902 may also be implemented as a device of the class of television 918, which includes devices having or connected to a generally larger screen in a casual viewing environment. These devices include televisions, set-top boxes, game console systems, etc. The techniques described herein may be supported by these various configurations of the computing device 902 and are not limited to the specific examples of the techniques described herein.

[0125] The cloud 920 includes and / or represents a platform 922 for resources 924. The platform 922 abstracts the underlying functionality of the hardware (e.g., servers) and software resources of the cloud 920. The resources 924 may include applications and / or data that may be utilized when computer processing is performed on a server remote from the computing device 902. The resources 924 may also include services provided over the Internet and / or over a subscriber network such as a cellular or Wi-Fi network. The platform 922 may abstract the resources and functionality used to connect the computing device 902 to other computing devices. The platform 922 may also be used to abstract the scaling of resources to provide a corresponding scale level to meet the demand for the resources 924 implemented via the platform 922. Accordingly, in an interconnected device embodiment, the implementation of the functions described herein may be distributed throughout the system 900. For example, the functions may be implemented partially on the computing device 902 and via the platform 922 that abstracts the functions of the cloud 920.

[0126] Discussed herein are various methods that may be implemented to perform the techniques discussed herein. Aspects of the methods may be implemented in hardware, firmware, software, or a combination thereof. The methods are shown as a set of steps specifying operations to be performed by one or more devices, and are not necessarily limited to the order shown for performing the operations of the individual blocks. Additionally, according to one or more implementations, the operations shown with respect to a particular method may be combined with and / or interchanged with the operations of different methods. Aspects of the methods may be implemented via the interaction between the various entities discussed above with reference to environment 100.

[0127] Although implementations have been discussed herein with reference to obtaining a health certificate, it should be appreciated that aspects of the techniques may be used for various other purposes, such as key authentication. Some example scenarios and processes for health certificates have been discussed based on key authentication and health authentication. Now consider a discussion of example systems and devices according to one or more embodiments.

Claims

1. A computer-implemented method for providing a token to a client computer based on TPM key authentication, the method comprising: Receiving a token request from the client computer, wherein the token request includes a key authentication statement and an endorsement key certificate, and the key authentication statement is signed using a first TPM key; Verifying the key authentication statement and the endorsement key certificate; Issuing the token in response to verifying the key authentication statement and the endorsement key certificate; Encrypting the token using a secret to form an encrypted token; Extracting a second TPM key from the endorsement key certificate, wherein the second TPM key is a TPM public endorsement key; Encrypting the secret using the second TPM key to form an encrypted secret; And Sending the encrypted token and the encrypted secret to the client computer.

2. The computer-implemented method according to claim 1, wherein verifying the token request further comprises determining whether the first TPM key is associated with a TPM having a third TPM key.

3. The computer-implemented method according to claim 2, further comprising extracting the third TPM key from the key authentication statement.

4. The computer-implemented method according to claim 3, wherein the first TPM key is a private authentication identity key and the third TPM key is a public authentication identity key.

5. The computer-implemented method according to claim 1, wherein the token request is received in a single message from the client computer.

6. The computer-implemented method according to claim 1, wherein the token comprises one of the following: a decryption key, a signature key, an authentication token, and a license.

7. A health service system, comprising a health service computer, wherein the health service computer includes a processor in electronic communication with a memory, the memory storing computer-readable instructions that, when executed by the processor, cause the health service computer to: Receive a health certificate request from the client computer, wherein the health certificate request includes a key authentication statement signed using a first TPM key; Verify the key authentication statement; Create a health certificate for the client computer in response to verifying the key authentication statement, Encrypt the health certificate using a server key to form an encrypted health certificate; Extract a second TPM key from the endorsement key certificate included in the health certificate request, wherein the second TPM key is a TPM public endorsement key; Encrypt the server key using the second TPM key to form an encrypted server key, and Send the encrypted health certificate and the encrypted server key to the client computer.

8. The health service system according to claim 7, wherein verifying the health certificate request further comprises determining whether the first TPM key is associated with a TPM having a third TPM key.

9. A computer-implemented method for obtaining a health certificate based on TPM key authentication for a client device, wherein the client device includes a TPM having: a public endorsement key, a private endorsement key, an endorsement key certificate, a public authentication identity key, and a private authentication identity key, the method comprising: Creating a key statement that includes the public authentication identity key and the public endorsement key from the TPM; Signing the key statement with the private authentication identity key from the TPM; Creating a health statement that includes health status information about the client device; Signing the health statement with the private authentication identity key from the TPM; Sending a request for a health certificate from the client device to a health service computer, the request having the key statement and the health statement and a log having measurement data; Receiving a health authentication binary large object from the health service computer; And Accessing the health authentication binary large object to obtain the health certificate.

10. The computer-implemented method according to claim 9, wherein the health authentication binary large object includes an encrypted server key and an encrypted health certificate.

11. The computer-implemented method according to claim 10, wherein accessing the health authentication binary large object includes: Parsing the health authentication binary large object to retrieve the encrypted server key and the encrypted health certificate; Using the private endorsement key from the TPM to decrypt the encrypted server key; And Using the decrypted server key to decrypt the health certificate.

12. The computer-implemented method according to claim 9, wherein the health service computer is communicatively accessible to the client device via a local network.

13. The computer-implemented method according to claim 9, wherein the client device automatically initiates the method for obtaining a health certificate.

Images