System and Method for Distributed Security

• US 20080037793A1
• Filed: 10/16/2007
• Published: 02/14/2008
• 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
• Granted Patent: US 8,713,309 B2
• Time in Patent Office: Days
• US Class Current: 380/282
• 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 for authorizing, at a client, a plurality of key servers, comprising the steps of:

a. determining whether a public key of a first key server is authorized;

b. determining whether a second key server requires authorization; and

c. if so, signing the public key of the second key server to authorize the second key server and the public key of the second key server, so that the public key of the first key server or the public key of the second key server can be used to authorize an additional key server.

2. The method of claim 1, wherein step a. comprises the steps of:

i. reading server authorization data;

ii. calculating a hash value of an authorized server public key; and

iii. verifying that the server authorization data of step i is equal to the calculated hash value of step ii.

3. The method of claim 2, wherein said calculation of step ii. comprises calculating a Secure Hash Algorithm 1 (SHA1) value based on the authorized server public key.

4. The method of claim 1, further comprising the steps of:

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

e. determining if the configuration messages accompanied by a signature created by an authorized public key; and

f. only if so, loading the content of the configuration message.

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

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

7. The method of claim 5, wherein said configuration message, when loaded, places a constraint on key length.

8. The method of claim 5, wherein said configuration message, when loaded, removes a constraint on key length.

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

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

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

a. generating a client random number;

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

c. sending the client random number to the key server;

d. receiving a server random number, a signed session public key, and a certificate from key server;

e. sending the signed session public key to a security module;

f. verifying the signed session public key; and

g. verifying the handshake process.

12. The method of claim 11, wherein said step f. comprises the steps of:

i. parsing the certificate received from the key server;

ii. identifying a public key corresponding to the key server;

iii. loading the corresponding public key into the security module; and

iv. using the corresponding public key to verify the signed session public key.

13. The method of claim 11, wherein said step g. comprises the steps of:

i. sending a client certificate to the key server;

ii. engaging in a key exchange with the key server;

iii. incorporating a client session key into a finished hash;

iv. sending a client finished message to key server; and

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

14. The method of claim 11, further comprising the steps of:

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

i. loading the key at a key cache;

j. setting a countdown timer to the time value;

k. decrementing the countdown timer; and

l. 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.

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

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

17. 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.