US8700893B2 - Key certification in one round trip - Google Patents

Key certification in one round trip Download PDF

Info

Publication number
US8700893B2
US8700893B2 US12/607,937 US60793709A US8700893B2 US 8700893 B2 US8700893 B2 US 8700893B2 US 60793709 A US60793709 A US 60793709A US 8700893 B2 US8700893 B2 US 8700893B2
Authority
US
United States
Prior art keywords
key
certificate
tpm
signature
client
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active, expires
Application number
US12/607,937
Other languages
English (en)
Other versions
US20110099367A1 (en
Inventor
Stefan Thom
Scott D. Anderson
Erik L. Holt
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corp filed Critical Microsoft Corp
Priority to US12/607,937 priority Critical patent/US8700893B2/en
Assigned to MICROSOFT CORPORATION reassignment MICROSOFT CORPORATION ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: ANDERSON, SCOTT D., HOLT, ERIK L., THOM, STEFAN
Priority to JP2012536825A priority patent/JP5693595B2/ja
Priority to EP10828721.0A priority patent/EP2494733A4/en
Priority to CN201080048694.6A priority patent/CN102577229B/zh
Priority to TW099132367A priority patent/TWI507006B/zh
Priority to KR1020127010781A priority patent/KR101731132B1/ko
Priority to PCT/US2010/050285 priority patent/WO2011056321A2/en
Publication of US20110099367A1 publication Critical patent/US20110099367A1/en
Publication of US8700893B2 publication Critical patent/US8700893B2/en
Application granted granted Critical
Assigned to MICROSOFT TECHNOLOGY LICENSING, LLC reassignment MICROSOFT TECHNOLOGY LICENSING, LLC ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: MICROSOFT CORPORATION
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/14—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using a plurality of keys or algorithms
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/72—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in cryptographic circuits
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/12—Details relating to cryptographic hardware or logic circuitry
    • H04L2209/127—Trusted platform modules [TPM]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees

Definitions

  • Trust in keys is generally established through certificates.
  • an entity creates a key
  • the entity submits the key to an authority for certification.
  • the authority determines whether the key and its owner meet the authority's standards for certification. If so, the authority issues a certificate for the key, which contains the key signed by the authority.
  • authorities are entities that are known to the community that they serve, and that the community trusts to certify the keys of other entities. If a recognized authority certifies a key, then the community that trusts the authority will trust the certified key. For example, browsers periodically receive updated lists of authorities, and the browsers will trust certificates issued by authorities on the list.
  • An organization e.g., a company
  • An organization may have a certificate authority that is recognized and trusted by machines within that organization.
  • a trusted platform module is a piece of hardware that can be used to provide various forms of security for a machine.
  • One thing that a TPM can do is maintain hardware security around a key, thereby providing a high measure of assurance that the key will not be misused.
  • a certificate authority may be willing to certify only a key that is bound to a particular TPM, since this binding ensures that the key will only be used on the machine that contains that particular TPM. Therefore, in order to certify such a key, the certificate authority has to verify that the key is actually bound to the TPM on a particular machine, and cannot be migrated to other machines.
  • the process of certifying such a key involves several round-trip exchanges between the certificate authority and the client that is requesting to have the key certified.
  • a client wants to certify a new non-migratable key that is secured by the client's TPM
  • the client requests that the TPM create a key called an Attestation Identity Key (AIK) for the new key.
  • AIK Attestation Identity Key
  • the client then asks the certificate authority to certify the AIK, which the certificate authority does after verifying that the AIK was actually generated by the TPM on the client's machine.
  • the client then asks the TPM to sign the new key with the AIK, which the TPM will only do if the key is non-migratable.
  • the client then submits the new key and the AIK-generated signature to the certificate authority.
  • the certificate authority trusts the TPM, and has certified the AIK as belonging to the TPM. Therefore, the certificate authority will trust that the new key is non-migratable based on the TPM's having signed it with the AIK, so the certificate authority will issue a certificate for the new key.
  • a problem with this process is that it involved multiple round trips between the client and the certificate authority: one trip to certify AIK, and another to certify the new key that the client is trying to certify.
  • a non-migratable key may be certified in one round trip between the certificate authority and the client that is requesting the key.
  • a client asks the TPM to create a new non-migratable key (e.g., an RSA key pair).
  • the TPM then creates the key and provides the public portion of the new key to the client.
  • the client then creates a certificate request for the new key, and asks the TPM to create an Attestation Identity Key (AIK) that is bound to a digest of the certificate request.
  • AIK Attestation Identity Key
  • the TPM creates the AIK, and returns an identity binding that contains the public portion of the AIK, the digest, and a signature taken over both the public portion of AIK and the digest.
  • the client then asks the TPM to use AIK to sign the public portion of the new key, as an indication that the new key is non-migratable.
  • the TPM signs the public portion of the new key, and returns a key certification structure that contains the new key, the TPM's statement that the new key is non-migratable, and a signature created with the private portion of the AIK.
  • the client then sends to the certificate authority: the certificate request; the identity binding; the key certification structure; and the public key certificate of the TPM's endorsement key. (The endorsement key is the key that each TPM has that identifies a particular TPM.)
  • the certificate authority When the certificate authority receives these items from the client, it examines the public key certificate of the TPM's endorsement key to verify that the TPM associated with that endorsement key is a TPM that the certificate authority knows and trusts. The certificate authority then examines the certificate to recover the new key that the client is asking to certify. The certificate authority then verifies the signature on the identity binding, calculates the digest of the certificate request, and compares the calculated digest with the digest contained in the identity binding to ensure that the two digests match. If the digests match, and if the signature on the identity binding is valid, these facts prove that the AIK mentioned in the identity binding was created specifically for the certificate request that the certificate authority has received.
  • the certificate authority examines key certification structure, and verifies the signature on that structure.
  • the key certification structure represents a statement, made by the party in possession of the private portion of the AIK, that the new key contained in the structure is non-migratable.
  • the certificate authority knows that the party in possession of the private portion of the AIK has said that the key is non-migratable.
  • the certificate authority creates a certificate for the new key, and signs the certificate. But, instead of including a clear signature in the certificate, the certificate authority creates a symmetric key and encrypts the signature with the symmetric key. The certificate authority then encrypts the symmetric key with the public endorsement key that it received along with the certificate request, and sends, to the client, the certificate (with the signature encrypted by the symmetric key), along with the symmetric key encrypted by the TPM's public endorsement key. When the certificate authority received the public key certificate for the TPM's endorsement key, it determined that it trusts the particular TPM associated with that endorsement key.
  • the client will be able to decrypt the signature in the certificate by first asking the TPM to use its endorsement key to decrypt the symmetric key, and then using the symmetric key to decrypt the signature.
  • the certificate will become usable. If a different TPM is present at the client (e.g., a TPM that is not trusted by the certificate authority), then the TPM will not be able to decrypt the symmetric key because it will not have the endorsement key for which the symmetric key was encrypted. In that case, the client would not be able to decrypt the signature, and the certificate would be unusable.
  • FIG. 1 is a block diagram of various components that may be used when a client requests that a certificate authority certify a key.
  • FIGS. 2-5 are, collectively, a flow diagram of an example process in which a request to certify a key may be made and acted upon.
  • FIG. 6 is a block diagram of an example identity binding.
  • FIG. 7 is a block diagram of an example key certification structure.
  • FIG. 8 is a block diagram of an example certificate with an encrypted signature.
  • FIG. 9 is a block diagram of example components that may be used in connection with implementations of the subject matter described herein.
  • Cryptographic keys are used for various applications in computer security, such as encryption and digital signing.
  • Encryption is the process of encrypting a message with an encryption key so that only the party that possesses the decryption key (which may or may not be the same as the encryption key) can decipher the message.
  • Digital signing is a process whereby an entity (the signer) makes an assertion about a piece of data, and where the signature provides cryptographic-strength assurance that the assertion was actually made by the entity that is in possession of the key.
  • the encryption and digital signing processes both involve implicit trust relationship between the parties that participate in these processes. For example, when A encrypts data with B's key, A is implicitly trusting: (a) that the key that A believes is B's is really B's key, and (b) encrypting data with B's key and transmitting the encrypted data over an unsecure channel will not cause the encrypted data to be used in some manner that is unacceptable to A. For example, with regard to point (a), A might have received B's key from an unreliable source, so the key that A believes belongs to B might actually be an interloper's key.
  • the key might really be B's key, but B might use such lax security measures that the security of the key has become compromised, thereby allowing interlopers to decrypt messages that have been encrypted with B's key.
  • a receives a message purportedly signed by B e.g., “Fact F is true, signed B”
  • A is implicitly trusting that the message really was signed by B (i.e., that A really knows which key is B's, and that B's key has not been compromised).
  • A is also trusting that B would not sign the message “Fact F is true” unless B had verified, up to some level of certainty, that fact F really is true.
  • trust in the key is generally established by having an authority attest to the trustworthiness of the key.
  • This attestation is represented in the form of a certificate, whereby the authority signs the key as an indication that the authority has found the key to be trustworthy.
  • certificate authorities are generally well-known to the relevant community in which trust is to be established, or involve short trust chains back to well-known authorities.
  • an entity wants to use a key for signing or encryption the entity typically presents the key to an appropriate certificate authority and requests that the authority sign the key. The authority takes whatever measures it deems appropriate to determine that the key is sufficiently trustworthy.
  • the authority may determine what kinds of security measures the requesting entity uses to protect the key (e.g., whether the entity uses hardware or software protection). The authority may inquire what policies the requesting entity will use to determine what can be signed with the key. Or, the authority might only be willing to certify keys for certain types of entities (e.g., the authority could be the certificate authority for a corporation or other enterprise, and might only be willing to certify keys used by machines in that enterprise). If the authority determines that it can certify the key, it issues a certificate that contains the key and the authority's signature. An X.509 certificate is an example of such a certificate.
  • TPM Trusted Platform Module
  • the TPM is a chip that performs certain cryptographic functions for its host machine.
  • the host machine can leverage these cryptographic functions to provide a rich array of security services.
  • the TPM can seal data to a particular machine execution state, so that the data is only provided to the machine when the machine is in a known, safe state.
  • This technique is often used to protect cryptographic keys on the host. With such a technique, the host uses the TPM to seal a key, and only the sealed key is stored on the machine's disk drive.
  • the host asks the TPM to unseal the key, which the TPM will only do if the machine is in the execution state to which the key has been sealed.
  • This execution state (which is typically represented by specific values of the Platform Configuration Registers, or “PCRs”) has previously been verified to be a safe one that provides sufficient assurance against misuse of the key.
  • PCRs Platform Configuration Registers
  • Another way that a TPM can provide security for a key is to generate a key pair, and provide only the public portion of the key pair to the host, so that all private key operations involving that key pair are performed inside the TPM.
  • the TPM can provide various assurances as to such a key. For example, the TPM can assure that a key that does not leave the TPM is a non-migratable key (i.e., that the key cannot be used on any platform other than the one that employs the particular TPM that has sealed the key).
  • the host platform may present the non-migratable key to an authority and request that the authority certify the key as an indication of trustworthiness.
  • the certificate authority has to confirm that the key being presented for signature has actually been secured by the TPM. For example, the host authority might claim to have a non-migratable key.
  • the certificate authority will insist that the TPM says the key is non-migratable, not merely that the host says so.
  • TPM has a key pair called the “endorsement key” (which is referred to as “EK”, and whose public and private portions may be referred to, respectively, as “EK-public” and “EK-private”).
  • EK Endorsement key
  • a given TPM's endorsement key distinguishes that TPM from other TPMs.
  • the public EK of a TPM is known to certificate authorities that trust that specific TPM. For example, a corporation might operate a server to act as a certificate authority, and that server might know the EK for all the laptops owned by the corporation.
  • the TPM could use EK to sign the key as an indication that the TPM believes the key to be secure. Since the certificate authority knows the public EKs of those TPMs that it knows and trusts, the certificate authority could use the signature to verify that a trusted TPM has attested that the key is non-migratable, and the certificate authority could issue a certificate for the key on that basis. However, in reality, the TPM has policies that prevent it from signing arbitrary data with EK. Thus, a TPM typically uses EK to create other keys, and the TPM uses these other keys to sign data. One example of such an “other key” is an Attestation Identity Key (AIK), which the TPM uses to sign other keys.
  • AIK Attestation Identity Key
  • an AIK is used to obtain a certificate of a key in the following way.
  • Software on the host platform asks the TPM to create a new key pair, for which the software receives the public portion.
  • the software then asks the TPM to create an AIK that is bound to the public portion of the new key, and then requests that the certificate authority (“CA”) sign the public portion of the AIK (i.e., “AIK-public”).
  • CA certificate authority
  • the CA verifies that the request actually comes from a TPM that it trusts. For example, the CA might verify the security of the communication channel between itself and the TPM by using a nonce.
  • the CA signs AIK-public and returns the certificate to the host platform.
  • the host platform then generates a new key, and requests that the TPM use the private portion of AIK (“AIK-private”) to sign the new key.
  • AIK-private the private portion of AIK
  • the use of AIK to sign a new key might represent some statement that the TPM makes about the new key—e.g., signing a new key with AIK might indicate that the TPM asserts the new key is non-migratable.
  • the host presents to the CA: the new key; the signature; and the CA's certificate of AIK; and a request that the CA sign the new key.
  • the CA uses AIK-public to verify the signature on the new key, and uses the certificate of AIK-public to verify that trust in AIK has previously been established.
  • the CA then issues the new certificate and returns it to the host.
  • a problem that arises with the foregoing procedure is that it uses multiple round-trips to the CA: one to certify AIK, and then another to certify the key that the TPM has signed with AIK.
  • the subject matter described herein allows the TPM's host platform to request that a CA certify a TPM-protected key in one round trip.
  • the technique described herein avoids the use of a separate round trip to certify AIK.
  • a client on the host platform asks the TPM to create a new non-migratable key, and asks the CA to certify the new key without first establishing that the CA trusts the AIK.
  • the CA responds by certifying the key, but in a way that makes subsequent use of the certificate contingent on the host's having a TPM that the CA trusts.
  • the client asks the TPM to create a new key that the client wishes to have certified.
  • the client then creates a certificate request—i.e., a request to have the CA sign the new key.
  • the client asks the TPM to create an AIK that is bound to the certificate request.
  • the TPM responds by creating an identity binding, which contains the public portion of the AIK, a digest of the certificate request, and a signature.
  • the client then asks the TPM to sign the new key.
  • the TPM responds by creating a key certification structure, which contains the key to be certified, a statement about the key (e.g., “This key is non-migratable”), and a signature created with AIK-private.
  • the client then forwards the certificate request, the identity binding, the key certification structure, and a certificate of the TPM's EK-public, to the CA.
  • the CA then examines the certificate of EK-public to ensure that it belongs to a TPM that the CA trusts.
  • the CA then digests the certificate request, compares that digest to the digest contained in the identity binding, and verifies the signature on the identity binding. Assuming that the digests match and that the signature verifies, these facts prove that the AIK was created for the certificate request that the CA received.
  • the CA recovers the key to be certified from the certificate request, and compares it with the key identified in the key certification structure, to ensure that the key certificate structure relates to the key specified in the certificate request.
  • the CA then examines the statement made in the key certification structure to ensure that the statement about the key is consistent with the CA's certificate issuance policy (e.g., if the CA's policy calls for certifying only non-migratable keys, then the CA verifies that the statement attests to the non-migratability of the key).
  • the CA then verifies the signature on the key certification structure to ensure that the statement contained in that structure was made by the holder of AIK-private. Assuming that all of the foregoing verifications are in order, the CA, at this point, knows that the holder of AIK is asserting the new key to be non-migratable and is requesting a certificate for that key.
  • the CA issues, to the client, a conditional certificate.
  • the certificate is conditional in the sense that it can be used only if the TPM that holds EK-private (whom the CA trusts) will verify that AIK was issued by that TPM.
  • the CA creates a symmetric key and encrypts its signature of the certificate with the symmetric key. So, the CA provides to the client a certificate that contains the encrypted signature, and also provides the symmetric key encrypted by EK-public.
  • the CA delegates to a trusted TPM the job of verifying the trustworthiness of a particular AIK, thereby avoiding a separate round between the certificate authority and the client to have the AIK certified.
  • FIG. 1 shows various components that may be used when a client requests that a certificate authority certify a new key, and the example interactions between those components.
  • the key that the client is requesting to certify is referred to as the “new key.”
  • this key is the public portion of a Rivest-Shamir-Adelman (RSA) key that the client will use as part of a process to sign data.
  • RSA Rivest-Shamir-Adelman
  • the client creates a new RSA signing key and is seeking to have the key certified by the CA so that the signing key can be trusted by other entities.
  • the techniques described herein are not limited to the certification of signing keys, or RSA keys.
  • the techniques herein apply whenever a client creates a key and is seeking to have it certified by a CA.
  • the key that the client is seeking to have certified will be referred to herein as the “new key.”
  • the techniques described herein involve the use of various keys, and those keys will be distinguished in the text and drawings by appropriate labels and/or modifiers.
  • Machine 102 is a machine that provides some computing capability, such as a personal computer, a handheld computer, a set-top box, etc.
  • Machine 102 is equipped with TPM 104 .
  • TPM 104 is a component that provides various security services for machine 102 on which TPM 104 is located.
  • TPM 104 has an endorsement key (EK) 106 , which is an asymmetric key pair that has respective public and private portions 108 and 110 , respectively (referred to herein as “EK-Public” and “EK-Private”).
  • EK endorsement key
  • Each TPM 104 has its own EK that is not shared by other TPMs.
  • EK-Private is that EK-Private is not exposed outside of TPM 104 .
  • TPM 104 exposes an interface that machine 102 can use to request that TPM 104 decrypt a piece of data with EK-Private, so that TPM 104 can decrypt data for machine 102 without exposing the actual value of EK-Private.
  • TPM 104 also provides various other security functions. For example, TPM 104 maintains a set of registers (called Platform Configuration Registers, or PCRs) that record a measurement of the current execution state of the machine, and TPM 104 allows machine 102 to seal pieces of data to a specific machine state.
  • Platform Configuration Registers or PCRs
  • TPM 104 can generate key pairs and can hold the private portion of the key in its own memory so that the private portion is not exposed to the non-secure portions of machine 102 (i.e., those portions of machine 102 that are outside of TPM 104 ).
  • a key pair whose private key is held inside TPM 104 is a non-migratable key: it cannot be migrated to other machines, because it is not exposed outside of a specific machine's TPM.
  • Client 112 is a software component that wants to create a new key for some purpose (e.g., signing or encryption). Client 112 could be an application, a component of an operating system, or any other type of software component that runs on machine 102 .
  • client 112 decides to create a new key, client 112 issues a request 114 that TPM 104 create the key. TPM 104 creates the requested key and returns a key handle 116 by which the key can be identified.
  • request 114 is a request to create an asymmetric key pair, such as an RSA key pair, in which case key handle 116 contains the public portion of the new key (the private portion being kept only inside of TPM 104 ).
  • the public portion of the RSA key pair is the “new key” that the client is seeking to have certified. (Technically, it is the private key that is used to sign data, and the public key is used by other parties to verify the signature. Since data is signed with the expectation that someone will later verify the signature, for purposes herein the public key can be considered to be “part of the process” of signing data.)
  • client 112 In order to have the new key certified, client 112 creates a certificate request 118 , which is a formal data structure that requests that a certificate authority certify a key. Client 112 does not send certificate request 118 to a certificate authority at this point. Before doing so, client 112 arranges to have various pieces of data created by the TPM to send along with the certificate request. These various pieces of data are described below.
  • TPM 104 exposes a function that creates an AIK bound to an arbitrary piece of data.
  • TPM 104 might expose a function such as “CreateAIK(blob)”, which returns an AIK in a way that is cryptographically bound to “blob” (where “blob” is an arbitrary piece of data).
  • client 112 issues the request “CreateAIK(blob”)
  • TPM 104 returns a piece of data of the form:
  • client 112 next issues, to TPM 104 , a request 122 to have the new key signed with the AIK.
  • TPM 104 signs a key with AIK
  • TPM 104 returns a structure that indicates the security features that apply to the key.
  • the new key that client 112 is seeking to have certified by a CA was created by the TPM.
  • TPM 104 holds the private portion inside of TPM 104 , and does not divulge the private portion outside of TPM 104 .
  • the new key is non-migratable since its private portion cannot be used on any machine other than the specific machine (i.e., machine 102 ) that contains TPM 104 .
  • TPM 104 signs a key with AIK
  • TPM 104 when TPM 104 signs the key, it produces a key certification structure 124 , an example of which is shown in FIG. 7 .
  • the example key certification structure 124 contains statement 702 (which may be expressed either explicitly as shown, or may be expressed implicitly).
  • Key certification structure 124 also contains the new key 704 to be certified, and a signature 706 , which is created using AIK-Private and is calculated over the statement and the new key.
  • Key certification structure 124 proves that whatever entity controls AIK-Private says that new key 704 is a non-migratable key (or has whatever feature the holder of AIK-Private is attesting to).
  • Any entity in possession of AIK-Public i.e., any entity that has received the identity binding described above
  • certificate authority (CA) 126 is the entity that client 112 wants to ask to certify the new key. Client 112 is now ready to request a certificate from CA 126 .
  • client 112 sends, to CA 126 : the certificate request 118 ; the identity binding 120 ; the key certification structure 124 , and a certificate 128 of EK 106 (i.e., the public key certificate of TPM 104 's endorsement key, which contains EK-Public). These items are received by CA 126 .
  • CA 126 is a server that acts on requests to issue certificates.
  • CA 126 may be a server within a corporation (or other enterprise) that enrolls new machines in the enterprise by certifying their keys.
  • CA 126 includes an issuance component 130 , which makes decisions about which keys to certify.
  • CA 126 may contain a list 132 of trusted TPMs (e.g., a list of the EK-publics of those TPMs that CA 126 trusts).
  • CA 126 may also have a policy 134 that contains the rules under which certificate requests are to be granted or denied. For example, CA 126 might have a policy of only certifying non-migratable keys, or might have some other policy.
  • CA 126 may have a signature verifier 136 which allow it to verify cryptographic signatures on the various pieces of data that it receives. These components may be used by issuance component 130 . For example, issuance component may use signature verifier 136 to verify the signatures on identity binding and key certification structure. Issuance component 130 may also use list 132 of trusted TPMs to determine which TPMs it is willing to certify keys for. Additionally, issuance component 130 may use policy 134 to determine whether it will certify a particular key, even if the certificate request comes from a trusted TPM. (E.g., issuance component might trust TPM 104 , but might be unwilling to certify a key for TPM 104 if TPM 104 will not say that the key is non-migratable.)
  • CA 126 When CA 126 receives the above-described items from client 112 , it does the following. First, CA 126 examines certificate 128 (which contains the public portion of TPM 104 's endorsement key) to determine whether CA 126 knows and trusts the TPM on the machine that client 112 is running on. For example, if TPM 104 is unknown to CA 126 (which may be determined by comparing certificate 128 with list 132 ), then CA 126 may be unwilling to certify a key on the machine on which TPM 104 is installed. Thus, if certificate 128 indicates that the key for which certification is being sought is bound to an unknown TPM, CA 126 may deny the certificate request.
  • certificate 128 which contains the public portion of TPM 104 's endorsement key
  • CA 126 Assuming that CA 126 knows and trusts the TPM whose public endorsement key appears in certificate 128 , CA 126 then examines certificate request 118 to recover the new key that client 112 is requesting to certify (since that key is contained in the certificate request).
  • CA 126 examines identity binding 120 to find the digest of the certificate request.
  • CA 126 then calculates a digest of the certificate request (using the same digest algorithm that was used to create the digest in identity binding 120 ), and verifies that the digest contained in identity binding matches the digest that CA 126 calculated. If the digests match, then CA 126 reads AIK-Public from identity binding 120 , and uses AIK-Public to verify the signature on identity binding 120 . It will be recalled that an AIK is bound to a specific piece of data at the time of its creation. Verification of the signature proves that the piece of data for which this particular AIK was created is the digest of certificate request 118 .
  • CA 126 examines the key certification structure to determine what statement the holder of AIK-Private is making about the new key contained in the security request.
  • CA 126 uses AIK-Public to verify the signature on the key certification structure. If the signature does not verify, then CA 126 cannot conclude that the holder of AIK-Private has made any particular statement about CA 126 , so CA 126 denies the certificate request. Assuming the signature verifies, CA 126 determines whether the properties of the new key are consistent with CA 126 's policy 134 . For example, if CA 126 has a policy of certifying only non-migratable keys, then it may insist that key certification structure show that the holder of AIK-Private says the key is non-migratable.
  • AIK-Private is, in fact, held by TPM 104 , since it is TPM 104 that created the AIK. However, that fact is unknown to CA 126 .
  • CA 126 knows the public portion of TPM 104 's endorsement key, but CA 126 cannot deduce the relationship between a particular TPM and a particular AIK merely from the endorsement key.
  • CA 126 knows that some entity has created an AIK for the specific certificate request that CA 126 received, and that whoever that entity is has made a statement about the key to be certified that satisfies CA 126 's issuance policy. But CA 126 does not know who the entity is. As described above, CA 126 has examined TPM 104 's public endorsement key and has determined that TPM 104 is trustworthy, so CA 126 would be willing to grant the certificate request if the entity that controls AIK-Private is TPM 104 . But CA 126 does not know whether AIK-Private is controlled by TPM 104 , or by some other entity.
  • CA 126 can issue a conditional certificate in a form that can only be used if the entity that controls AIK-Private is actually TPM 104 .
  • the form of the certificate is such that TPM 104 would have to perform some action, before the certificate could be used.
  • the signature on the certificate can be encrypted in a way that is only decryptable as a result of a process performed by the TPM (e.g., decryption of the signature by the TPM, or decryption by the TPM of a key that is later used to decrypt the signature).
  • CA 126 In order to issue a certificate that is conditional on the presence of a particular TPM, CA 126 creates a certificate (e.g., an X.509 certificate) for the new key, as requested.
  • a certificate contains the key to be certified, and the signature of the certificate authority that certifies the key. Normally, the signature would be in the certificate in the clear (i.e., not encrypted).
  • CA 126 creates the certificate, it creates a symmetric key, and uses the symmetric key to encrypt the signature. The encrypted signature is placed in the certificate instead of a clear signature.
  • CA 126 then encrypts the symmetric key with the public endorsement key of TPM 104 (i.e., EK-Public, which CA 126 received in certificate 128 ).
  • CA 126 sends, to client 112 : (a) a certificate 138 with an encrypted signature, and (b) the encrypted symmetric key 140 (encrypted by EK-Public).
  • client 112 receives the encrypted symmetric key, it can ask TPM 104 to decrypt it with EK-public, thereby allowing client 112 to decrypt the signature with the symmetric key.
  • Client 112 can then substitute the encrypted signature in certificate 138 with the clear signature.
  • Certificate 138 is shown in FIG. 8 .
  • Certificate 138 contains new key 704 , together with encrypted signature 802 which is sig-CA-Private(new key), encrypted by the symmetric key. (“CA-Private” is the private key of CA 126 .)
  • CA 126 only wants to issue a usable certificate if TPM 104 has attested that the key that CA 126 is certifying meets the applicable standard imposed by CA 126 (e.g., non-migratability), which CA 126 knows to be true only if TPM 104 is actually the entity that generated the AIK. In theory, AIK could have been generated by some entity other than TPM 104 . In that case, CA 126 would still issue certificate 138 with an encrypted signature that TPM 104 could decrypt (since the signature is encrypted with a symmetric key that can be recovered with TPM 104 's private endorsement key).
  • CA 126 when CA 126 sends the certificate with the encrypted signature to TPM 104 , CA 126 relies on TPM 104 not to create the certificate with a clear signature unless the new key certified by certificate 138 is actually the one that TPM 104 signed with AIK. In effect, CA 126 delegates this determination to TPM 104 , which CA 126 can do because it has already established that TPM 104 is a TPM that CA 126 trusts. Thus, after TPM 104 receives certificate 138 with an encrypted signature, TPM 104 determines whether the new key certified by certificate 138 is a key that TPM 104 has signed with the AIK. If so, then TPM 104 decrypts the signature and replaces the encrypted signature with a clear signature.
  • TPM 104 does not decrypt the signature, thereby rendering the certificate unusable. No party will trust a key certificate unless the party can verify that the certificate was signed by an appropriate authority that the party trusts. If the signature in the certificate cannot be decrypted, the certificate remains effectively unusable, since it could not be used to establish trust with any party.
  • FIGS. 2-5 show, in the form of a flow chart, an example process by which a request to certify a key may be made and acted upon.
  • FIGS. 2-5 show, in the form of a flow chart, an example process by which a request to certify a key may be made and acted upon.
  • FIGS. 2-5 show, in the form of a flow chart, an example process by which a request to certify a key may be made and acted upon.
  • a client requests that the TPM generate a new key.
  • the new key may be, for example, an RSA key pair, which may be used for any cryptographic function such as encryption or signing.
  • the “new key” referred to in the flow diagram i.e., the key to be certified is the public portion of the key pair.
  • a certificate request for the new key is created.
  • a digest of the request is created (at 206 ), and the client then requests that the TPM create an AIK that is bound to the digest (at 208 ).
  • the TPM then creates the AIK (at 210 ), and returns an identity binding.
  • the identity binding contains the AIK-Public, the digest, and a signature taken over AIK-Public and the digest (with the signature being created with AIK-Private).
  • the client requests that the TPM sign the new key with AIK.
  • the TPM then returns a key certification structure (at 214 ), which contains (an explicit or implicit) statement about the new key (e.g., “This key is non-migratable”), the new key itself, and a signature taken over the statement and the new key (with the signature being created with AIK-Private).
  • the client sends to the CA: (a) the certificate request; (b) the identity binding; (c) the key certification structure; and (d) the public key certificate of the TPM's endorsement key (EK-Public).
  • EK-Public public key certificate of the TPM's endorsement key
  • the CA checks EK-Public against a list of known TPMs. If, based on EK-Public, the CA determines that the TPM associated with EK-Public either is not known to the CA or is known to be from an untrustworthy TPM (as determined at 222 ), then the CA aborts the process (at 224 ), and does not issue a certificate. If EK-Public is from a known, trusted TPM, then the process continues to 226 , where the CA reads the certificate request to get the new key that it is being asked to certify.
  • the CA then verifies the signature on the identity binding, recovers the digest from the binding, and also calculates the digest itself from the certificate request. If the identity binding does not match the certificate request (i.e., if the digest contained in the certificate request is not the same as the digest that the CA calculated from the certificate request, as determined at 228 ), then the process aborts, and the CA does not issue a certificate (at 230 ). Otherwise, the process continues to 232 .
  • the CA determines whether the key certification structure attests that the new key satisfies the applicable policy (e.g., a policy of non-migratability).
  • the CA may make this determination, for example, by verifying the signature on the key certification structure, and then examining the statement that the structure makes about the key. If the signature fails to verify, or if the statement indicates that the key does not satisfy the CA's policy to certify a key, then the process aborts, and the CA does not issue a certificate (at 234 ). Otherwise, the process continues to 236 , where the CA proceeds to issue a certificate.
  • the applicable policy e.g., a policy of non-migratability
  • the CA creates the symmetric key that will be used to encrypt the signature on the certificate.
  • the CA creates the certificate for the new key.
  • the CA creates the signature for the certificate.
  • the CA encrypts the signature with the symmetric key, and includes the encrypted signature (instead of a clear signature) in the certificate.
  • the CA encrypts the symmetric key with EK-Public (the public portion of the endorsement key of the TPM on the machine to which the certificate is to be issued).
  • EK-Public the public portion of the endorsement key of the TPM on the machine to which the certificate is to be issued.
  • the CA sends, to the client that requested the certificate, the certificate of the key (with the encrypted signature), and the symmetric key encrypted by EK-Public.
  • these items are received by the client.
  • the client asks the TPM to decrypt the symmetric key with EK-Private. Assuming that the key contained in the certificate is the same one that the TPM signed with the AIK that was used for the certificate request, the TPM decrypts the symmetric key (at 252 ) and returns it to the client. The client then uses the symmetric key to decrypt the signature, and replaces the encrypted signature in the certificate with a clear signature (at 256 ). The client now possesses a usable certificate for the new key (at 258 ).
  • FIG. 9 shows an example environment in which aspects of the subject matter described herein may be deployed.
  • Computer 900 includes one or more processors 902 and one or more data remembrance components 904 .
  • Processor(s) 902 are typically microprocessors, such as those found in a personal desktop or laptop computer, a server, a handheld computer, or another kind of computing device.
  • Data remembrance component(s) 904 are components that are capable of storing data for either the short or long term. Examples of data remembrance component(s) 904 include hard disks, removable disks (including optical and magnetic disks), volatile and non-volatile random-access memory (RAM), read-only memory (ROM), flash memory, magnetic tape, etc.
  • Data remembrance component(s) are examples of computer-readable storage media.
  • Computer 900 may comprise, or be associated with, display 912 , which may be a cathode ray tube (CRT) monitor, a liquid crystal display (LCD) monitor, or any other type of monitor.
  • CTR cathode ray tube
  • LCD liquid crystal display
  • Software may be stored in the data remembrance component(s) 904 , and may execute on the one or more processor(s) 902 .
  • An example of such software is key certification software 906 , which may implement some or all of the functionality described above in connection with FIGS. 1-8 , although any type of software could be used.
  • Software 906 may be implemented, for example, through one or more components, which may be components in a distributed system, separate files, separate functions, separate objects, separate lines of code, etc.
  • a personal computer in which a program is stored on hard disk, loaded into RAM, and executed on the computer's processor(s) typifies the scenario depicted in FIG. 9 , although the subject matter described herein is not limited to this example.
  • the subject matter described herein can be implemented as software that is stored in one or more of the data remembrance component(s) 904 and that executes on one or more of the processor(s) 902 .
  • the subject matter can be implemented as instructions that are stored on one or more computer-readable storage media. (Tangible media, such as an optical disks or magnetic disks, are examples of storage media.)
  • Such instructions when executed by a computer or other machine, may cause the computer or other machine to perform one or more acts of a method.
  • the instructions to perform the acts could be stored on one medium, or could be spread out across plural media, so that the instructions might appear collectively on the one or more computer-readable storage media, regardless of whether all of the instructions happen to be on the same medium.
  • any acts described herein may be performed by a processor (e.g., one or more of processors 902 ) as part of a method.
  • a processor e.g., one or more of processors 902
  • a method may be performed that comprises the acts of A, B, and C.
  • a method may be performed that comprises using a processor to perform the acts of A, B, and C.
  • computer 900 may be communicatively connected to one or more other devices through network 908 .
  • Computer 910 which may be similar in structure to computer 900 , is an example of a device that can be connected to computer 900 , although other types of devices may also be so connected.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Storage Device Security (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
US12/607,937 2009-10-28 2009-10-28 Key certification in one round trip Active 2032-02-08 US8700893B2 (en)

Priority Applications (7)

Application Number Priority Date Filing Date Title
US12/607,937 US8700893B2 (en) 2009-10-28 2009-10-28 Key certification in one round trip
TW099132367A TWI507006B (zh) 2009-10-28 2010-09-24 在一次往返中的金鑰認證
EP10828721.0A EP2494733A4 (en) 2009-10-28 2010-09-24 Key certification in one round trip
CN201080048694.6A CN102577229B (zh) 2009-10-28 2010-09-24 在一个往返行程中的密钥认证
JP2012536825A JP5693595B2 (ja) 2009-10-28 2010-09-24 一往復での鍵証明
KR1020127010781A KR101731132B1 (ko) 2009-10-28 2010-09-24 일회 왕복 키 인증
PCT/US2010/050285 WO2011056321A2 (en) 2009-10-28 2010-09-24 Key certification in one round trip

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US12/607,937 US8700893B2 (en) 2009-10-28 2009-10-28 Key certification in one round trip

Publications (2)

Publication Number Publication Date
US20110099367A1 US20110099367A1 (en) 2011-04-28
US8700893B2 true US8700893B2 (en) 2014-04-15

Family

ID=43899369

Family Applications (1)

Application Number Title Priority Date Filing Date
US12/607,937 Active 2032-02-08 US8700893B2 (en) 2009-10-28 2009-10-28 Key certification in one round trip

Country Status (7)

Country Link
US (1) US8700893B2 (ko)
EP (1) EP2494733A4 (ko)
JP (1) JP5693595B2 (ko)
KR (1) KR101731132B1 (ko)
CN (1) CN102577229B (ko)
TW (1) TWI507006B (ko)
WO (1) WO2011056321A2 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10326597B1 (en) 2014-06-27 2019-06-18 Amazon Technologies, Inc. Dynamic response signing capability in a distributed system
US11115220B2 (en) * 2013-07-17 2021-09-07 Amazon Technologies, Inc. Complete forward access sessions
US11475107B2 (en) * 2018-03-12 2022-10-18 Hewlett-Packard Development Company, L.P. Hardware security

Families Citing this family (50)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012023050A2 (en) 2010-08-20 2012-02-23 Overtis Group Limited Secure cloud computing system and method
WO2012122994A1 (en) * 2011-03-11 2012-09-20 Kreft Heinz Off-line transfer of electronic tokens between peer-devices
CN102355351B (zh) * 2011-07-21 2014-11-05 华为技术有限公司 一种基于可信计算的密钥生成、备份和迁移方法及系统
US8375221B1 (en) 2011-07-29 2013-02-12 Microsoft Corporation Firmware-based trusted platform module for arm processor architectures and trustzone security extensions
WO2013061792A1 (ja) 2011-10-25 2013-05-02 株式会社アイエスアイ 電子マネー送金方法およびそのシステム
US8953790B2 (en) * 2011-11-21 2015-02-10 Broadcom Corporation Secure generation of a device root key in the field
US8850187B2 (en) * 2012-05-17 2014-09-30 Cable Television Laboratories, Inc. Subscriber certificate provisioning
US9756036B2 (en) * 2012-06-15 2017-09-05 Nokia Technologies Oy Mechanisms for certificate revocation status verification on constrained devices
ES2619957T3 (es) * 2012-11-22 2017-06-27 Huawei Technologies Co., Ltd. Procedimiento y dispositivo de control de gestión para máquinas virtuales
US10270748B2 (en) 2013-03-22 2019-04-23 Nok Nok Labs, Inc. Advanced authentication techniques and applications
US9940446B2 (en) * 2013-07-25 2018-04-10 Siemens Healthcare Diagnostics Inc. Anti-piracy protection for software
US9652631B2 (en) 2014-05-05 2017-05-16 Microsoft Technology Licensing, Llc Secure transport of encrypted virtual machines with continuous owner access
US9391777B2 (en) * 2014-08-15 2016-07-12 Palo Alto Research Center Incorporated System and method for performing key resolution over a content centric network
US9519787B2 (en) * 2014-11-14 2016-12-13 Microsoft Technology Licensing, Llc Secure creation of encrypted virtual machines from encrypted templates
US9742762B2 (en) * 2014-12-01 2017-08-22 Microsoft Technology Licensing, Llc Utilizing a trusted platform module (TPM) of a host device
US10205598B2 (en) * 2015-05-03 2019-02-12 Ronald Francis Sulpizio, JR. Temporal key generation and PKI gateway
CN105141420B (zh) * 2015-07-29 2018-09-25 飞天诚信科技股份有限公司 一种安全导入、签发证书的方法、设备及服务器
DE102015214696A1 (de) * 2015-07-31 2017-02-02 Siemens Aktiengesellschaft Vorrichtung und Verfahren zum Verwenden eines Kunden-Geräte-Zertifikats auf einem Gerät
US9768966B2 (en) * 2015-08-07 2017-09-19 Google Inc. Peer to peer attestation
US10146916B2 (en) * 2015-11-17 2018-12-04 Microsoft Technology Licensing, Llc Tamper proof device capability store
CN107086907B (zh) 2016-02-15 2020-07-07 阿里巴巴集团控股有限公司 用于量子密钥分发过程的密钥同步、封装传递方法及装置
CN107086908B (zh) 2016-02-15 2021-07-06 阿里巴巴集团控股有限公司 一种量子密钥分发方法及装置
US10277407B2 (en) * 2016-04-19 2019-04-30 Microsoft Technology Licensing, Llc Key-attestation-contingent certificate issuance
CN107347058B (zh) 2016-05-06 2021-07-23 阿里巴巴集团控股有限公司 数据加密方法、数据解密方法、装置及系统
CN107370546B (zh) 2016-05-11 2020-06-26 阿里巴巴集团控股有限公司 窃听检测方法、数据发送方法、装置及系统
CN107404461B (zh) 2016-05-19 2021-01-26 阿里巴巴集团控股有限公司 数据安全传输方法、客户端及服务端方法、装置及系统
US10396991B2 (en) * 2016-06-30 2019-08-27 Microsoft Technology Licensing, Llc Controlling verification of key-value stores
JP6965921B2 (ja) * 2016-09-08 2021-11-10 日本電気株式会社 ネットワーク機能仮想化システム及び検証方法
US10320571B2 (en) * 2016-09-23 2019-06-11 Microsoft Technology Licensing, Llc Techniques for authenticating devices using a trusted platform module device
CN107959567B (zh) 2016-10-14 2021-07-27 阿里巴巴集团控股有限公司 数据存储方法、数据获取方法、装置及系统
CN107959656B (zh) 2016-10-14 2021-08-31 阿里巴巴集团控股有限公司 数据安全保障系统及方法、装置
US10164778B2 (en) * 2016-12-15 2018-12-25 Alibaba Group Holding Limited Method and system for distributing attestation key and certificate in trusted computing
EP3566384B1 (en) * 2017-01-06 2021-02-17 Koninklijke Philips N.V. Pinocchio / trinocchio on authenticated data
US11438155B2 (en) * 2017-01-24 2022-09-06 Microsoft Technology Licensing, Llc Key vault enclave
CN108667608B (zh) 2017-03-28 2021-07-27 阿里巴巴集团控股有限公司 数据密钥的保护方法、装置和系统
CN108667773B (zh) 2017-03-30 2021-03-12 阿里巴巴集团控股有限公司 网络防护系统、方法、装置及服务器
CN108736981A (zh) 2017-04-19 2018-11-02 阿里巴巴集团控股有限公司 一种无线投屏方法、装置及系统
US10819696B2 (en) * 2017-07-13 2020-10-27 Microsoft Technology Licensing, Llc Key attestation statement generation providing device anonymity
US11868995B2 (en) 2017-11-27 2024-01-09 Nok Nok Labs, Inc. Extending a secure key storage for transaction confirmation and cryptocurrency
US11831409B2 (en) 2018-01-12 2023-11-28 Nok Nok Labs, Inc. System and method for binding verifiable claims
CN110324138B (zh) * 2018-03-29 2022-05-24 阿里巴巴集团控股有限公司 数据加密、解密方法及装置
CN109450620B (zh) 2018-10-12 2020-11-10 创新先进技术有限公司 一种移动终端中共享安全应用的方法及移动终端
CN111371726B (zh) * 2018-12-25 2022-06-14 阿里巴巴集团控股有限公司 安全代码空间的认证方法、装置、存储介质及处理器
US11792024B2 (en) 2019-03-29 2023-10-17 Nok Nok Labs, Inc. System and method for efficient challenge-response authentication
CN110046515B (zh) * 2019-04-18 2021-03-23 杭州尚尚签网络科技有限公司 一种基于短效数字证书的安全的电子签名方法
WO2020229586A1 (en) * 2019-05-14 2020-11-19 Volkswagen Aktiengesellschaft Implementation of a butterfly key expansion scheme
US11429519B2 (en) 2019-12-23 2022-08-30 Alibaba Group Holding Limited System and method for facilitating reduction of latency and mitigation of write amplification in a multi-tenancy storage drive
EP3855328A1 (en) * 2020-01-24 2021-07-28 Thales Dis France Sa A method for securely diversifying a generic application stored in a secure processor of a terminal
KR102559101B1 (ko) * 2020-02-24 2023-07-25 한국전자통신연구원 전력 계량 장치, 전력 계량 서버 및 블록 체인 기반의 전력 계량 방법
US12003655B1 (en) * 2021-12-07 2024-06-04 Amazon Technologies, Inc. Cryptographic assertions for certificate issuance

Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003073688A1 (en) 2002-02-22 2003-09-04 Emc Corporation Authenticating hardware devices incorporating digital certificates
CN1457170A (zh) 2002-05-09 2003-11-19 佳能株式会社 公钥证明书发行装置
US20050223007A1 (en) * 2004-03-30 2005-10-06 Intel Corporation Remote management and provisioning of a system across a network based connection
US20050289343A1 (en) 2004-06-23 2005-12-29 Sun Microsystems, Inc. Systems and methods for binding a hardware component and a platform
US20050289347A1 (en) 2004-06-28 2005-12-29 Shlomo Ovadia Method and apparatus to authenticate base and subscriber stations and secure sessions for broadband wireless networks
US20060117181A1 (en) 2004-11-30 2006-06-01 Brickell Ernest F Apparatus and method for establishing a secure session with a device without exposing privacy-sensitive information
US20060277414A1 (en) 2004-04-30 2006-12-07 Fujitsu Limited Data managing device equipped with various authentication functions
US20070016801A1 (en) * 2005-07-12 2007-01-18 Bade Steven A Method, apparatus, and product for establishing virtual endorsement credentials for dynamically generated endorsement keys in a trusted computing platform
WO2008031148A1 (en) 2006-09-11 2008-03-20 Commonwealth Scientific And Industrial Research Organisation A portable device for use in establishing trust
US20080126802A1 (en) 2006-07-03 2008-05-29 Lenovo (Beijing) Limited Inter-system binding method and application based on hardware security unit
WO2008115988A1 (en) 2007-03-19 2008-09-25 Telcordia Technologies, Inc. Vehicle segment certificate management using short-lived, unlinked certificate schemes
US20090097642A1 (en) 2007-10-16 2009-04-16 Microsoft Corporation Secure Content Distribution with Distributed Hardware
US20090169012A1 (en) 2007-12-29 2009-07-02 Smith Ned M Virtual tpm key migration using hardware keys
US20090271618A1 (en) * 2006-08-31 2009-10-29 International Business Machines Corporation Attestation of computing platforms

Patent Citations (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2003073688A1 (en) 2002-02-22 2003-09-04 Emc Corporation Authenticating hardware devices incorporating digital certificates
CN1457170A (zh) 2002-05-09 2003-11-19 佳能株式会社 公钥证明书发行装置
US20050223007A1 (en) * 2004-03-30 2005-10-06 Intel Corporation Remote management and provisioning of a system across a network based connection
US20060277414A1 (en) 2004-04-30 2006-12-07 Fujitsu Limited Data managing device equipped with various authentication functions
US20050289343A1 (en) 2004-06-23 2005-12-29 Sun Microsystems, Inc. Systems and methods for binding a hardware component and a platform
US20050289347A1 (en) 2004-06-28 2005-12-29 Shlomo Ovadia Method and apparatus to authenticate base and subscriber stations and secure sessions for broadband wireless networks
US20060117181A1 (en) 2004-11-30 2006-06-01 Brickell Ernest F Apparatus and method for establishing a secure session with a device without exposing privacy-sensitive information
US20070016801A1 (en) * 2005-07-12 2007-01-18 Bade Steven A Method, apparatus, and product for establishing virtual endorsement credentials for dynamically generated endorsement keys in a trusted computing platform
US20080126802A1 (en) 2006-07-03 2008-05-29 Lenovo (Beijing) Limited Inter-system binding method and application based on hardware security unit
US20090271618A1 (en) * 2006-08-31 2009-10-29 International Business Machines Corporation Attestation of computing platforms
WO2008031148A1 (en) 2006-09-11 2008-03-20 Commonwealth Scientific And Industrial Research Organisation A portable device for use in establishing trust
WO2008115988A1 (en) 2007-03-19 2008-09-25 Telcordia Technologies, Inc. Vehicle segment certificate management using short-lived, unlinked certificate schemes
US20090097642A1 (en) 2007-10-16 2009-04-16 Microsoft Corporation Secure Content Distribution with Distributed Hardware
US20090169012A1 (en) 2007-12-29 2009-07-02 Smith Ned M Virtual tpm key migration using hardware keys

Non-Patent Citations (8)

* Cited by examiner, † Cited by third party
Title
"International Search Report and Written Opinion of the International Searching Authority", Mailed Date: Jun. 20, 2011, Application No. PCT/US2010/050285, Filed Date: Sep. 24, 2010, 8 pages.
George, Patrick, "User Authentication with Smart Cards in Trusted Computing Architecture.", Retrieved at <<http://www.gemplus.com/smart/rd/publications/pdf/SAM2406.pdf>>, Proceedings of the International Conference on Security and Management (SAM'04), Jun. 21-24, 2004, 7 pages.
George, Patrick, "User Authentication with Smart Cards in Trusted Computing Architecture.", Retrieved at >, Proceedings of the International Conference on Security and Management (SAM'04), Jun. 21-24, 2004, 7 pages.
List of References cited in Chinese Office Action, Doc. No. CPPH1132283P, dated May 2, 2013, 1 page.
Morozov, et al., "Hardware Key for Information Systems Users Authentification", Retrieved at <<http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=01366012>>, TCSET'2004; Feb. 24-28, 2004, Lviv-Slavsko, Ukraine, pp. 420-421.
Morozov, et al., "Hardware Key for Information Systems Users Authentification", Retrieved at >, TCSET'2004; Feb. 24-28, 2004, Lviv-Slavsko, Ukraine, pp. 420-421.
Myers, et al., "Certificate Management Messages over CMS", Retrieved at <<http://cnscenter.future.co.kr/resource/ietf/rfc/rfc2797.pdf>>, Apr. 2000, 33 pages.
Myers, et al., "Certificate Management Messages over CMS", Retrieved at >, Apr. 2000, 33 pages.

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11115220B2 (en) * 2013-07-17 2021-09-07 Amazon Technologies, Inc. Complete forward access sessions
US10326597B1 (en) 2014-06-27 2019-06-18 Amazon Technologies, Inc. Dynamic response signing capability in a distributed system
US11546169B2 (en) 2014-06-27 2023-01-03 Amazon Technologies, Inc. Dynamic response signing capability in a distributed system
US11811950B1 (en) 2014-06-27 2023-11-07 Amazon Technologies, Inc. Dynamic response signing capability in a distributed system
US11475107B2 (en) * 2018-03-12 2022-10-18 Hewlett-Packard Development Company, L.P. Hardware security

Also Published As

Publication number Publication date
EP2494733A2 (en) 2012-09-05
JP2013509805A (ja) 2013-03-14
TW201121281A (en) 2011-06-16
EP2494733A4 (en) 2017-06-28
KR101731132B1 (ko) 2017-04-27
CN102577229B (zh) 2014-05-07
US20110099367A1 (en) 2011-04-28
WO2011056321A2 (en) 2011-05-12
TWI507006B (zh) 2015-11-01
WO2011056321A3 (en) 2011-08-18
KR20120101363A (ko) 2012-09-13
JP5693595B2 (ja) 2015-04-01
CN102577229A (zh) 2012-07-11

Similar Documents

Publication Publication Date Title
US8700893B2 (en) Key certification in one round trip
US10397005B2 (en) Using a trusted execution environment as a trusted third party providing privacy for attestation
US9542568B2 (en) Systems and methods for enforcing third party oversight of data anonymization
CN110061846B (zh) 对区块链中用户节点进行身份认证和确认的方法、装置及计算机可读存储介质
EP2080142B1 (en) Attestation of computing platforms
US9998438B2 (en) Verifying the security of a remote server
US7526649B2 (en) Session key exchange
US9064129B2 (en) Managing data
US20080301436A1 (en) Method and apparatus for performing authentication between clients using session key shared with server
US20230379152A1 (en) Binding with cryptographic key attestation
US20160335453A1 (en) Managing Data
EP2457192B1 (en) Communication channel claim dependent security precautions
CN113271207A (zh) 基于移动电子签名的托管密钥使用方法、系统、计算机设备及存储介质
US11405201B2 (en) Secure transfer of protected application storage keys with change of trusted computing base
CN112784249B (zh) 实现无标识情形下进行移动终端认证处理的方法、系统、处理器及其计算机可读存储介质
Barker et al. SP 800-21 Second edition. Guideline for Implementing Cryptography in the Federal Government
CN110955883A (zh) 一种用户密钥生成的方法、装置、设备及存储介质
AG Certification Report

Legal Events

Date Code Title Description
AS Assignment

Owner name: MICROSOFT CORPORATION, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:THOM, STEFAN;ANDERSON, SCOTT D.;HOLT, ERIK L.;REEL/FRAME:023439/0886

Effective date: 20091026

STCF Information on status: patent grant

Free format text: PATENTED CASE

AS Assignment

Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034564/0001

Effective date: 20141014

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551)

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8