METHOD FOR CONTROLLING SECURITY FUNCTION EXECUTION WITH A FLEXIBLE, ENTENDABLE, AND NON-FORGABLE BLOCK

• US 20080077794A1
• Filed: 09/22/2006
• Published: 03/27/2008
• Est. Priority Date: 09/22/2006
• Status: Active Grant

• Current Assignee: International Business Machines Corporation
• Original Assignee: International Business Machines Corporation
• Inventors: Wiese, Jesper, Frehr, Carsten D., Jacobsen, Kurt S., Kelly, Michael J., Marik, Mark D., Dames, Elizabeth A., Arnold, Todd W.
• Granted Patent: US 7,779,258 B2
• Time in Patent Office: Days
• US Class Current: 713/169
• CPC Class Codes: H04L 2209/04 Masking or blinding
• CPC Class Codes: H04L 2209/34 Encoding or coding, e.g. Huffman coding or error correction
• CPC Class Codes: H04L 9/0822 using key encryption key
• CPC Class Codes: H04L 9/088 Usage controlling of secret information, e.g. techniques for restricting cryptographic keys to pre-authorized uses, different access levels, validity of crypto-period, different key- or password length, or different strong and weak cryptographic algorithms network architectures or network communication protocols for using time-dependent keys in a packet data network H04L63/068
• CPC Class Codes: H04L 9/3242 involving keyed hash functions, e.g. message authentication codes [MACs], CBC-MAC or HMAC
• CPC Class Codes: H04L 9/3247 involving digital signatures

Abstract

A method, article, and system for providing an effective implementation of data structures, and application programming interface (API) functions that allow secure execution of functions behind a secure boundary. The controlling mechanism is a flexible, extendable, and non-forgeable block that details how values and parameters behind the secure boundary can be changed. The invention allows for one entity to execute a security function that will normally require extensive authorizations or dual or multiple control. The method and system comprise instructions that are cryptographically protected against alteration or misuse, wherein the instructions further comprise a trusted block that defines security policies that are permitted when an application program employs the trusted block in APIs. The trusted block has a number of fields containing rules that provide an ability to limit how the trusted block is used, thereby reducing the risk of the trusted block being employed in unintended ways. This trusted block controls the critical values or parameters behind the secure boundary. Cryptographically secured data structures are provided that allow for breaking up the instructions in the trusted blocks in a number of steps without reducing the level of security. Systems that make use of the trusted block must provide two API functions; one that encapsulates the block under at least dual control, and one that process the instructions or rules in the trusted block. In particular the invention provides a method, article, and system for the effective implementation for securely transferring symmetric encryption keys to remote devices, such as Automated Teller Machines (ATMs), PIN entry devices, and point of sale terminals. It may also be used to exchange symmetric keys with another cryptographic system of any type, such as a Host Security Module (HSM) in a computer server.

Claims

1. A data structure comprising instructions that are cryptographically protected against alteration or misuse, wherein said instructions further comprise a trusted block that defines specific key management policies that are permitted when applications employ said trusted block to generate, import, or export symmetric cryptographic keys, and wherein said applications comprise:

application programming interfaces (API);

embedded firmware;

operating system code;

and hardware configured operations; and

wherein said applications further comprise;

a Trusted_Block_Create (TBC) function;

a Remote_Key_Export (RKX) function; and

wherein said TBC function creates said trusted block; and

wherein said RKX function uses said Trusted Block to generate, import or export symmetric keys according to a set of parameters in said Trusted Block; and

wherein said RKX function creates a RKX token; and

wherein said RKX token encases said keys; and

wherein said trusted block has zero or more fields containing rules that provide an ability to limit how said trusted block is used, thereby reducing the risk of said trusted block being employed in unintended ways or with unintended keys; and

wherein said rules are created and approved by a cryptographic module under the control of at least two separate individuals;

wherein said trusted block is created with integrity protection by a message authentication code (MAC); and

wherein said MAC is calculated over the contents of said trusted block; and

wherein said trusted block comprises a randomly generated MAC key that is used to achieve said trusted blocks integrity protection; and

wherein said MAC key and a prepended confounder is encrypted under a variant of said cryptographic modules master key.

2. The data structure according to claim 1, wherein said rules are protected and bound to said trusted block;

and

wherein said rule comprises at least one of the following;

an indictor of whether said rule is to be used to generate, import, or export said symmetric cryptographic keys; and

an indicator of whether said generated, said imported, or said exported symmetric cryptographic keys should be in the form of a key that is immediately usable, or in the form of said RKX token that can only be used as a subsequent input to another RKX function call;

or

an indicator of whether the said generated or said exported symmetric cryptographic key should be encrypted under a public key contained in a vendor-supplied certificate.

3. The data structure according to claim 1, wherein said rules may comprise a rule ID, which is a value that identifies said rule and where said rule should be used;

and

wherein said rules can reference other rules by referring to said rule ID.

4. The data structure according to claim 1, wherein said rule may comprise at least one of the following:

a transport key rule reference to identify what rule must have been used previously to produce a key used as a transport key input to said RKX function;

or

a source key rule reference to identify what rule must have been used previously to produce a key used as a source key input to said RKX function;

or

an importer key rule reference to identify what rule must have been used previously to produce a key used an importer key input to said RKX function.

5. The data structure according to claim 1, wherein said rule may comprise at least one of the following:

information that controls the length of the keys that can be generated with said rule;

or

information controlling the length of keys that can be exported with said rule;

or

information controlling the length of keys that can be imported with said rule.

6. The data structure according to claim 1, wherein said rule comprises a plurality of variants;

and

wherein a first variant can be exclusive-or'"'"'ed (XORed) with the cleartext value of an output key exported by said trusted block prior to said output key being enciphered by a transport key; and

wherein a second variant can be XORed with a transport key prior to said transport key being employed to encrypt said output key that is exported or generated by said trusted block; and

wherein a third variant out can be exclusive-or'"'"'ed (XORed) with the cleartext value of an input source key imported by said trusted block prior to said output key being enciphered by said cryptographic modules master key.

7. The data structure according to claim 1, wherein said rule comprises a plurality key label templates;

and

wherein said templates specify acceptable key label values for either keys that are to be exported by said trusted block, or importer keys that are to be used for decrypting keys that are to be imported by said trusted block; and

wherein host-applied labels are compared to said template; and

wherein said key will not be exported if said host-applied label does not correspond to said key label values specified by said template.

8. The data structure according to claim 1, wherein said keys have structure;

and wherein said key structure further comprises a token, and

wherein said token is a data structure used to encase said key; and

wherein said token further comprises control vectors; and

wherein said rules comprise information to control which of said keys can be exported, based on said control vectors associated with said keys; and

wherein said control vectors have values; and

wherein said rule information allows the acceptable control vectors to be specified so that sets of related control vector values are acceptable, while values outside said set are rejected.

9. The data structure according to claim 1, further comprising activation and expiration date information;

and

wherein said RKX function enforces said activation and expiration date information before carrying out said instructions in said trusted block.

10. The data structure according to claim 1, wherein said rule comprises a plurality of masks of control vector bits;

and

wherein said rule comprises the required values of said control vector bits; and

wherein said masks of control vector bits and said required values are enforced by said RKX function when exporting a key or using an importer key; and

wherein said rule may comprise a control vector that is applied to a cryptographic module'"'"'s master key, before said master key is being employed to encrypt an output key that is imported by said trusted block.

11. The data structure according to claim 1, wherein said trusted block has a cryptographic public key;

and

wherein said TBC function creates and approves said cryptographic public key with said cryptographic module under the control of at least two separate individuals.

12. The data structure according to claim 1, wherein said RKX token further comprises a confounder used to initialize an encryption-block chaining value during the encryption of said encased key;

and wherein said confounder and said encased key within said RKX token are encrypted using the same MAC key that was used to protect said trusted block.

13. The data structure according to claim 1, wherein said RKX token further comprises a rule identification field that specifies a particular rule section that was used to create said RKX token.

14. The data structure according to claim 13, wherein said RKX token further comprises a MAC value;

and

wherein said MAC value is computed over said RKX token; and

wherein said RKX token further comprises;

an encrypted confounder;

a key value; and

wherein said rule identification field has a value; and

wherein said rule identification field value can be compared with instructions within said rule sections of said trusted block, to determine whether said key within said RKX token may be used as either an importer key—

key encrypting key, a source key, or exporter key-encrypting key.

15. A method for securely transferring symmetric cryptographic keys to other devices, wherein said method utilizes a data structure comprising instructions that are cryptographically protected against alteration or misuse, wherein said instructions further comprise a trusted block that defines specific key management policies that are permitted when applications employ said trusted block to generate, import, or export said symmetric cryptographic keys, and wherein said applications comprise:

application programming interfaces (API);

embedded firmware;

operating system code;

and hardware configured operations; and

wherein said applications further comprise;

a Trusted_Block_Create (TBC) function;

a Remote_Key_Export (RKX) function;

wherein said TBC function creates said trusted block; and

wherein said RKX function uses said Trusted Block to generate, import, or export symmetric keys according to a set of parameters in said Trusted Block; and

wherein said trusted block has a number of fields containing rules that provide an ability to limit how said trusted block is used, thereby reducing the risk of said trusted block being employed in unintended ways or with unintended keys; and

wherein said method comprises;

at least two separate individuals cooperating to create said trusted block under multiple control.

16. The method according to claim 15, wherein said trusted block has a data structure comprising:

zero or one trusted public key section, zero or more rule sections, zero or one trusted block label section, one trusted block information section, and zero or one application defined data section.

17. The method according to claim 15, wherein said trusted block is protected by a MAC that is computed over the contents of said data structure;

and

wherein said trusted block contains a public key and optional rules to control export of other keys associated with said other device(s) that use that public key; and

wherein for remote key distribution, said public key will be the root certification key for the other device, and said public key will be used to verify the signature on public key certificates for individual devices; and

wherein it is also possible for the Trusted Block to be used simply as a trusted public key container, in which case said public key in said trusted block will be used in functions such as Digital Signature Verify.

18. The method according to claim 15, wherein said rules in said trusted block further comprise a function to generate, import, or export said symmetric cryptographic keys;

and

wherein said function to generate, import, or export said symmetric cryptographic keys is said RKX function; and

wherein said RKX function creates a RKX token; and

wherein said RKX token holds said encrypted symmetric keys so as to bind them to said trusted block, and allows sequences of RKX calls to be bound together as if they are an atomic operation.

19. The method according to claim 15, wherein said RKX function provides for secure transport of said symmetric keys from a security module to another device.

20. A storage medium encoded with machine-readable computer code for a processor to implement an instruction set of instructions designed to securely transfer symmetric cryptographic keys to other devices;

and

wherein said instructions are cryptographically protected against alteration or misuse; and

wherein said instructions further comprise a trusted block that defines specific key management policies that are permitted when applications employ said trusted block to generate, import, or export said symmetric cryptographic keys, and wherein said applications comprise;

application programming interfaces (API);

embedded firmware;

operating system code;

and hardware configured operations; and

wherein said applications further comprise;

a Trusted_Block_Create (TBC) function;

a Remote_Key_Export (RKX) function;

wherein said TBC function creates said trusted block; and

wherein said RKX function uses said Trusted Block to generate, import, or export symmetric keys according to a set of parameters in said Trusted Block; and

wherein said trusted block has a number of fields containing rules that provide an ability to limit how said trusted block is used, thereby reducing the risk of said trusted block being employed in unintended ways or with unintended keys.