Pseudonymous remote attestation utilizing a chain-of-trust
US-2015264021-A1 · Sep 17, 2015 · US
US10142107B2 · US · B2
| Field | Value |
|---|---|
| Publication number | US-10142107-B2 |
| Application number | US-201514986388-A |
| Country | US |
| Kind code | B2 |
| Filing date | Dec 31, 2015 |
| Priority date | Dec 31, 2015 |
| Publication date | Nov 27, 2018 |
| Grant date | Nov 27, 2018 |
A practical reading order for non-experts. Skip the full description unless you need deep technical detail.
What the patent document calls the invention.
A short plain-language summary of the technical disclosure.
Who owns or filed the patent and who is credited as inventor.
Filing, priority, publication, and grant dates set the timeline.
The legal scope of protection — read this for what is actually claimed.
Technology tags used to group this patent with similar filings.
Prior art links and similar publications in this corpus.
Official abstract text for this publication.
Binding a security token to a client token binder, such as a trusted platform module, is provided. A bound security token can only be used on the client on which it was obtained. A secret binding key (kbind) is established between the client and an STS. The client derives a key (kmac) from kbind, signs a security token request with kmac, and instructs the STS to bind the requested security token to kbind. The STS validates the request by deriving kmac using a client-provided nonce and kbind to MAC the message and compare the MAC values. If the request is validated, the STS generates a response comprising the requested security token, derives two keys from kbind: one to sign the response and one to encrypt the response, and sends the response to the client. Only a device comprising kbind is enabled to use the bound security token, providing increased security.
Opening claim text (preview).
We claim: 1. A computer-implemented method for binding a ticket granting ticket to a client computing device, comprising: establishing a binding key, wherein the binding key is a shared secret between the client and a security token service (STS), wherein the binding key is bound to the client; wherein the binding key is protected by a token binder comprising a trusted platform module (TPM) and key storage; generating a request message for obtaining a security token; deriving a first request signing key, wherein the first request signing key is a message authentication code (MAC) key for signing the request message, and is derived based on a pseudorandom function, the binding key, and a first client-generated nonce; constructing a first MAC function based on a pseudorandom function and the first request signing key; generating a MAC for authentication of the request message using the first MAC function; concatenating the request message, the MAC, and the first client-generated nonce; transmitting the concatenation to the STS for authentication of the client; and upon authentication of the client by the STS, generating an security token for client access of remote protected resources, wherein the security token, upon receipt at the client, is bound to one or more of the token binders. 2. The method of claim 1 , further comprising, in response to the request message, receiving, from the STS, a response message, wherein at least a portion of the response message is encrypted using a symmetric key cypher with a first response encryption key derived based on a pseudorandom function, the binding key, and a first STS-generated nonce, and wherein the response message includes a MAC generated by an STS-constructed MAC function based on a pseudorandom function, a first response signing key derived based on a pseudorandom function, the binding key, and a second STS-generated nonce. 3. The method of claim 2 , wherein the response message includes the requested security token, the first STS-generated nonce, and the second STS-generated nonce. 4. The method of claim 3 , further comprising: deriving the first response signing key based on a pseudorandom function, the binding key, and the second STS-generated nonce; constructing a second MAC function based on a pseudorandom function and the first response signing key; generating a MAC for authentication of the response message using the second MAC function; comparing the client-generated MAC to the STS-generated MAC included in the response message to determine whether the client-generated MAC and the STS-generated MAC match; and in response to a positive determination, authenticating the response message. 5. The method of claim 4 , further comprising: deriving the first response encryption key based on a pseudorandom function, the binding key, and the first STS-generated nonce; decrypting at least a portion of the response message using a symmetric key cipher and the first response encryption key; identifying the requested security token; and storing the requested security token. 6. The method of claim 5 , wherein generating a request message for obtaining a security token comprises generating a service token request message for obtaining a service token. 7. The method of claim 6 , wherein generating a service token request message comprises including the ticket granting ticket in the service token request message. 8. The method of claim 6 , wherein identifying and storing the requested security token comprises identifying and storing the service token. 9. The method of claim 8 , further comprising transmitting the service token to a service provider to access a particular service provided by the service provider. 10. The method of claim 1 , wherein generating a request message for obtaining a security token comprises generating an authentication request message for obtaining the ticket granting ticket. 11. A method of binding a ticket granting ticket to a client computing device, comprising: establishing a plurality of binding keys, wherein each of the plurality of binding keys is protected by a token binder associated with the client, and is a shared secret between the client and a security token service (STS); wherein each token binder comprises a trusted platform module (TPM) and key storage; generating a request message for obtaining a security token; deriving, by a first token binder, an intermediate key, wherein the intermediate key is derived based on a pseudorandom function, a binding key protected by the first token binder, and a first client-generated nonce; providing the intermediate key to a second token binder; deriving, by the second token binder, a request chaining key, wherein the request chaining key is derived based on a pseudorandom function, a binding key protected by the second token binder, and the intermediate key; constructing a first message authentication code (MAC) function based on a pseudorandom function and the request chaining key; generating a MAC for authentication of the request message using the first hash function; concatenating the request message, the MAC, and the first client-generated nonce; transmitting the concatenation to the STS for authentication of the client; and upon authentication of the client by the STS, generating a security token for client access of remote protected resources, wherein the security token, upon receipt at the client, is bound to one or more of the token binders. 12. The method of claim 11 , further comprising, in response to the request message, receiving, from the STS, a response message, wherein at least a portion of the response message is encrypted with a chained encryption key derived based on a pseudorandom function, a second binding key, and an intermediate encryption key, wherein the intermediate encryption key is derived based on a pseudorandom function, a first binding key, and a first STS-generated nonce. 13. The method of claim 12 , wherein receiving the response message comprises receiving the response message including a MAC generated by an STS-constructed MAC function based on a pseudorandom function, the second binding key, and an intermediate response signing key, wherein the intermediate response signing key is derived based on a pseudorandom function, the first binding key, and a second STS-generated nonce. 14. The method of claim 13 , wherein receiving the response message comprises receiving the response message including the requested security token, the first STS-generated nonce, and the second STS-generated nonce. 15. The method of claim 14 , further comprising: deriving the chained encryption key derived based on a pseudorandom function, the second binding key, and the intermediate encryption key, wherein the intermediate encryption key is derived based on a pseudorandom function, the first binding key, and the first STS-generated nonce; decrypting at least a portion of the response message using a symmetric key cipher and the chained encryption key; identifying the requested security token; and storing the requested security token. 16. A system for binding a ticket granting ticket to a client computing device, comprising: one or more processors for executing programmed instructions; memory, coupled to the one or more processors, for storing program instruction steps for execution by the computer processor; at least one token binder operative to secure a binding key, wherein the binding key is a shared secret between the client and a security token service (STS), wherein the binding key is protected by the token binder c
involving Diffie-Hellman or related key agreement protocols · CPC title
using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates · CPC title
wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption (cryptographic mechanisms or cryptographic arrangements for symmetric key encryption H04L9/06) · CPC title
wherein the data content is protected, e.g. by encrypting or encapsulating the payload · CPC title
involving random numbers or seeds · CPC title
Related publications grouped by family.
Answers are generated from the same data shown on this page.