System and method for distributed security

• US 8,713,309 B2
• Filed: 10/16/2007
• Issued: 04/29/2014
• Est. Priority Date: 06/03/2003
• Status: Active Grant

• Current Assignee: Avago Technologies International Sales Pte Limited (Broadcom, Inc.)
• Original Assignee: Broadcom Corporation (Broadcom, Inc.)
• Inventors: Buer, Mark
• Primary Examiner(s): Rahman, Mahfuzur
• Application Number:
  US11/873,220
• Publication Number:
  US 20080037793A1
• Time in Patent Office: 2,387 Days
• Field of Search: 713/157
• US Class Current: 713/157
• CPC Class Codes: G06Q 20/3674 involving authentication
• CPC Class Codes: H04L 63/04 for providing a confidential data exchange among entities communicating through data packet networks
• CPC Class Codes: H04L 63/061 for key exchange, e.g. in peer-to-peer networks cryptographic mechanisms or cryptographic arrangements for key agreement H04L9/0838
• CPC Class Codes: H04L 63/062 for key distribution, e.g. centrally by trusted party cryptographic mechanisms or cryptographic arrangements for key distribution involving a central third party H04L9/0819
• CPC Class Codes: H04L 63/08 for authentication of entities cryptographic mechanisms or cryptographic arrangements for entity authentication H04L9/32
• CPC Class Codes: H04L 63/123 received data contents, e.g. message integrity
• CPC Class Codes: H04L 9/0825 using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
• CPC Class Codes: H04L 9/3265 using certificate chains, trees or paths; Hierarchical trust model

Abstract

A security architecture in which a security module is integrated in a client machine, wherein the client machine includes a local host that is untrusted. The security module performs encryption and decryption algorithms, authentication, and public key processing. The security module also includes separate key caches for key encryption keys and application keys. A security module can also interface a cryptographic accelerator through an application key cache. The security module can authorize a public key and an associated key server. That public key can subsequently be used to authorize additional key servers. Any of the authorized key servers can use their public keys to authorize the public keys of additional key servers. Secure authenticated communications can then transpire between the client and any of these key servers. Such a connection is created by a secure handshake process that takes place between the client and the key server. A time value can be sent from the key server to the client, allowing for secure revocation of keys. In addition, secure configuration messages can be sent to the security module.

Claims

1. A method, at a client, for creating a hierarchy of key servers, wherein a key server is configured to distribute cryptographic keys to one or more network entities, the method comprising:

determining that a first key server is authorized by comparing information stored in a security module of the client with a hash value of a first public key associated with the first key server, wherein the first public key is configured to expire after a predetermined period of time;

accessing information in the security module to determine whether the first key server is permitted to authorize additional key servers; and

in response to determining that the first key server is permitted to authorize additional key servers, signing a second public key of a second key server with the first public key to authorize the second key server, wherein either the first public key of the first key server or the second public key of the second key server can be used to authorize an additional key server.

2. The method of claim 1, wherein the hash value is a Secure Hash Algorithm 1 (SHA1) value.

3. The method of claim 1, further comprising:

receiving, at the security module, a configuration message from a local host of the client;

determining whether the configuration message is accompanied by a signature created by an authorized public key; and

in response to determining that the configuration message is accompanied by the signature, loading content of the configuration message.

4. The method of claim 3, wherein the configuration message, when loaded, alters a functionality available to the security module.

5. The method of claim 4, wherein the configuration message, when loaded, enables a cryptographic accelerator.

6. The method of claim 4, wherein the configuration message, when loaded, places a constraint on key length.

7. The method of claim 4, wherein the configuration message, when loaded, removes a constraint on key length.

8. The method of claim 4, wherein the configuration message, when loaded, constrains how a given key is to be used, in accordance with a system security policy.

9. The method of claim 4, wherein the configuration message, when loaded, constrains the time interval over which a given key is usable, in accordance with a system security policy.

10. The method of claim 1, wherein the first public key is configured to expire after a countdown timer reaches zero.

11. A method of establishing an authenticated connection between a client and a key server through a handshake process, the method comprising:

generating a client random number;

saving a copy of the client random number in a security module of the client;

sending the client random number to the key server;

receiving a server random number, a signed session key, and a certificate from the key server;

sending the signed session key to the security module;

verifying the signed session key by determining whether the signed session key has been signed with a verified public key; and

verifying the handshake process by comparing a hash of a first public key corresponding to the key server with information stored in the security module, wherein the first public key is configured to expire after a predetermined period of time.

12. The method of claim 11, wherein the verifying the handshake process comprises:

sending a client certificate to the key server;

engaging in a key exchange with the key server;

incorporating a client session key into a finished hash;

sending a client finished message to the key server; and

receiving and verifying a server finished message from the key server.

13. The method of claim 11, further comprising:

receiving a key from the key server along with a time value;

loading the key at a key cache;

setting a countdown timer to the time value;

decrementing the countdown timer; and

if the countdown timer reaches zero or a next key is received from the key server with a next time value, rendering the key unusable.

14. The method of claim 13, wherein the countdown timer is implemented in a hardware register, and wherein decrementing the countdown timer comprises decrementing the hardware register.

15. The method of claim 13, wherein the received key and time value are received in a sequentially numbered message.

16. The method of claim 11, wherein the authenticated connection between the client and the key server is implemented using a protocol that complies with the Transport Layer Security (TLS) protocol.

17. The method of claim 11, wherein the first public key is configured to expire after a countdown timer reaches zero.

18. A client device in communication with a plurality of key servers, the client device comprising:

a local host configured to;

send a first public key, wherein the first public key corresponds to a first key server in the plurality of key servers, and wherein the first public key is configured to expire after a predetermined period of time, and

send a secure configuration message; and

a security module programmed with secure server authorization data corresponding to the key server, wherein the secure server authorization data comprises a hash value of the first public key, wherein the security module is configured to;

determine that the first key server is authorized by comparing information stored in the security module with the hash value of the first public key,

determine, based on accessing information in the security module, whether the first key server is permitted to authorize additional key servers,

in response to determining that the first key server is permitted to authorize additional key servers, sign a second public key of a second key server with the first public key to authorize the second key server, wherein either the first public key or the second public key can be used to authorize an additional key server,

determine whether the secure configuration message is accompanied by an authorized signature of an authenticated public key, and

in response to determining that the secure configuration message is accompanied by the authorized signature, reconfigure the security module based on the secure configuration message.

19. The client device of claim 18, wherein the local host is further configured to attach a time value to the first public key prior to sending it to the security module, wherein the security module is further configured to set a countdown timer based on the time value, and wherein the first public key expires after the countdown timer reaches zero.

20. The client device of claim 18, wherein the first public key is configured to expire after a countdown timer reaches zero.