Secure management of keys using control vectors4941176
Abstract
The invention is an apparatus and method for validating that key management functions requested for a cryptographic key by the program have been authorized by the originator of the key. The invention includes a cryptographic facility characterized by a secure boundary through which passes an input path for receiving the cryptographic service requests, cryptographic keys and their associated control vectors, and an output path for providing responses thereto. There can be included within the boundary a cryptographic instruction storage coupled to the input path, a control vector checking unit and a cryptographic processing unit coupled to the instruction storage, and a master key storage coupled to the processing means, for providing a secure location for executing key management functions in response to the received service requests. The cryptographic instruction storage receives over the input path a cryptographic service request for performing a key management function on a cryptographic key. The control vector checking unit has an input coupled to the input path for receiving a control vector associated with the cryptographic key and an input connected to the cryptographic instruction storage, for receiving control signals to initiate checking that the control vector authorizes the key management function which is requested by the cryptographic service request. The control vector checking unit has an authorization output connected to an input of the cryptographic processing means, for signalling that the key management function is authorized, the receipt of which by the cryptographic processing unit initiates the performance of the requested key management function with the cryptographic key. The invention enables the flexible control of many cryptographic key management functions in the generation, distribution and use of cryptographic keys, while maintaining a high security standard.
Claims
What is claimed is:
1. In a data processing system which processes cryptographic service requests for the management of cryptographic keys which are associated with control vectors defining the functions which each key is allowed by its originator to perform, an apparatus for validating that key management functions requested for a crytographic key have been authorized by the originator of the key, comprising:
a crytographic facility characterized by a secure boundary through which passes an input path for receiving said cryptographic service requests, cryptographic keys and their associated control vectors, and an output path for providing responses thereto, there being included within said boundary a cryptographic control means coupled to said input path, a control vector checking means and a cryptographic processing means coupled to said control means, and a master key storage coupled to said processing means, for providing a secure location for executing key management functions in response to said received service requests;
said cryptographic control means receiving over said input path a cryptographic service request for performing a key management function with a cryptographic key;
said control vector checking means having an input coupled to said input path for receiving a control vector associated with said cryptographic key and an input coupled to said cryptographic, control means for receiving control signals to initiate checking that said control vector authorizes the key management function which is requested by said cryptographic service request;
said control vector checking means having an authorization output coupled to an input of said cryptographic processing means, for signalling that said key management function is authorized, the receipt of which by said cryptographic processing means initiates the performance of the requested key management function with said cryptographic key.
2. The apparatus of claim 1, which further comprises:
a cryptographic key storage means coupled to said cryptographic facility over said input and output paths, for storing said cryptographic key in an encrypted form in which said cryptographic key is encrypted under a storage key which is a logical product of said associated control vector and a master key stored in said master key storage.
3. The apparatus of claim 2, which further comprises:
said cryptographic control means receiving over said input path a cryptographic service request for recovering said cryptographic key from said cryptographic key storage means and said control vector checking means outputting in response thereto, an authorization signal to said cryptographic processing means that the function of recovering said cryptographic key is authorized;
said cryptographic processing means operating in response to said authorization signal, to receive said encrypted form of said cryptographic key from said cryptographic key storage means and to decrypt said encrypted form under said storage key which is a logical product of said associated control vector and said master key stored in said master key storage.
4. The apparatus of claim 2, wherein said storage key is the exclusive-OR product of said associated control vector and said master key stored in said master key storage.
5. The apparatus of claim 2, wherein said associated control vector is stored with said encrypted form of said cryptographic key in said cryptographic key storage means.
6. The apparatus of claim 1, wherein said associated control vector includes fields defining authorized tyes of cryptographic functions including key management functions, data encryption/decryption functions and PIN processing functions, and the key management functions type is designated;
said associated control vector further including fields defining export control and usage.
7. The apparatus of claim 1, for performing a generate key set function, which further comprises:
a random number source having an input connected to said cryptographic processing means, for supplying a random number thereto;
said cryptographic control means receiving over said input path a cryptographic service request for the generation of a key pair from said random number with associated first and second control vectors C3 and C4 and said control vector checking means outputting in response thereto, an authorization signal to said cryptographic processing means that the function of generating a key pair from said random number is authorized;
said cryptographic processing means operating in response to said authorization signal, to output said random number as a first generated key in an encrypted form in which said random number is encrypted under a key which is a logical product of said first associated control vector C3 and a first key K1;
said cryptographic processing means operating in response to said authorization signal, to output said random number as a second generated key in an encrypted form in which said random number is encrypted under a key which is a logical product of said second associated control vector C4 and a second key K2.
8. The apparatus of claim 7, for producing two keys which are operational in said data processing system, which further comprises:
said first and second keys K1 and K2 are said master key, local enabling operational usage within said data processing system.
9. The apparatus of claim 7, for producing a first generated key which is only operational in said data processing system which is a local data processing system, and a second generated key which can be exported to a remote data processing system connected to said local system, which further comprises:
said first key K1 is the master key, enabling operational usage within said local data processing system;
said second key K2 is a key encrypting key KEK2 with an associated control vector C2 and said control vector C2 authorizes exportation to said remote data processing system.
10. The apparatus of claim 7, for producing a first generated key which can be exported to a first remote data processing system connected to said data processing system which is a local data processing system and a second generated key which can be exported to a second remote data processing system connected to said local system, which further comprises:
said first key K1 is a key encrypting key KEK1 with an associated control vector C1 and said control vector C1 authorizes exportation to said first remote data processing system;
said second key K2 is a key encrypting key KEK2 with an associated control vector C2 and said control vector C2 authorizes exportation to said second remote data processing system.
11. The apparatus of claim 7, for producing a first generated key which is only operational in said data processing system which is a local data processing system, and a second generated key which can be imported from a utilization device connected to said local system, which further comprises:
said first key K1 is the master key, which only authorizes operational usage within said local data processing system;
said second key K2 is a key encrypting key KEK2 with an associated control vector C2 and said control vector C2 authorizes importation from said utilization device to said local system.
12. The apparatus of claim 7, for producing a first generated key which can be imported from a utilization device connected to said data processing system which is a local data processing system and a second generated key which can be exported to a remote data processing system connected to said local system, which further comprises:
said first key K1 is a key encrypting key KEK1 with an associated control vector C1 and said control vector C1 authorizes importation from said utilization device;
said second key K2 is a key encrypting key KEK2 with an associated control vector C2 and said control vector C2 authorizes exportation to said second remote data processing system.
13. The apparatus of claim 2, for performing a reencipherment from master key function, which further comprises:
said data processing system being a local data processing system connected to a first remote data processing system with which a secret key encrypting key KEK is shared;
said cryptographic key storage means storing said key encrypting key KEK in an encrypted form in which said KEK is encrypted under a storage key which is a logical product of an associated control vector C1 and said master key;
said cryptographic key storage means storing said cryptographic key as key K in an encrypted form in which said key K is encrypted under a storage key which is a logical product of an associated control vector C2 and said master key;
said cryptographic control means receiving over said input path a cryptographic service request for the reenciphering said cryptographic key K from said master key to encipherment under said key encrypting key KEK for export with an associated control vector C3 to said first remote processor and said control vector checking means outputting in response thereto, an authorization signal to said cryptographic processing means that the function of reenciphering said cryptographic key K from said master key to encipherment under said key encrypting key KEK for export is authorized;
said cryptographic processing means operating in response to said authorization signal, to receive said encrypted form of said cryptographic key K from said cryptographic key storage means and to decrypt said encrypted form thereof under a storage key which is a logical product of said associated control vector C2 and said master key;
said cryptographic processing means operating in response to said authorization signal, to receive said encrypted form of said key encrypting key KEK from said cryptographic key storage means and to decrypt said encrypted form thereof under a storage key which is a logical product of said associated control vector C1 and said master key;
said cryptographic processing means operating in response to said authorization signal, to reencipher said cryptographic key K under a logical product of said associated control vector C3 and said key encrypting key KEK and outputting said reenciphered cryptographic key K and said associated control vector C3 for transmission to said first remote data processing system.
14. The apparatus of claim 2, for performing a reencipherment to master key function, which further comprises:
said data processing system being a local data processing system connected to a first remote data processing system with which a secret key encrypting key KEK is shared;
said cryptographic key storage means storing said key encrypting key KEK in an encrypted form in which said KEK is encrypted under a storage key which is a logical product of an associated control vector C1 and said master key;
said first remote data processing system transmitting to said local data processing system a cryptographic key K enciphered under said key encrypting key KEK with an associated control vector C3;
said cryptographic control means receiving over said input path a cryptographic service request for the reenciphering said cryptographic key K from said encrypting key KEK to encipherment under said master key with an associated control vector C2 for storage in said cryptographic key storage means and said control vector checking means outputting in response thereto, an authorization signal to said cryptographic processing means that the function of reenciphering said cryptographic key K from said KEK to encipherment under said master key for storage is authorized;
said cryptographic processing means operating in response to said authorization signal, to reencipher said key K from said key encrypting key KEK to encipherment under said master key with said control vector C2 and outputting said reenciphered key K to said cryptographic key storage means.
15. The apparatus of claim 1, for performing a generate key function, which further comprises:
a random number source having an output connected to said cryptographic processing means, for supplying a random number thereto;
said cryptographic control means receiving over said input path a cryptographic service request for the generation of a key from said random number with an associated control vector C1 and said control vector checking means outputting in response thereto, an authorization signal to said cryptographic processing means that the function of generating a key from said random number is authorized;
said cryptographic processing means operating in response to said authorization signal, to output said random number as a generated key in an encrypted form in which said random number is encrypted under a key which is a logical product of said associated control vector C1 and said master key.
16. The apparatus of claim 2, for performing a translate key function, which further comprises:
said data processing system being a local data processing system connected to a first remote data processing system with which a secret import key encrypting key KEK1 is shared;
said data processing system being connected to a second remote data processing system with which a secret export key encrypting key KEK2 is shared;
said cryptographic key storage means storing said import key encrypting key KEK1 in an encrypted form in which said KEK1 is encrypted under a storage key which is a logical product of an associated control vector C1 and said master key;
said cryptographic key storage means storing said export key encrypting key KEK2 in an encrypted form in which said KEK2 is encrypted under a storage key which is a logical product of an associated control vector C2 and said master key;
said first remote data processing system transmitting to said local data processing system a cryptographic key K enciphered under said key encrypting key KEK1 with an associated control vector C3;
said cryptographic control means receiving over said input path a cryptographic service request for translating said cryptographic key K from encipherment under said import key encrypting key KEK1 to encipherment under said export key encrypting key KEK2 with an associated control vector C3 for transmission to said second data processing system and said control vector checking means outputting in response thereto, an authorization signal to said cryptographic processing means that the function of translating said cryptographic key K from encipherment under said import key encrypting key KEK1 to encipherment under said export key encrypting key KEK2 is authorized;
said cryptographic processing means operating in response to said authorization signal, to translate said cryptographic key K from encipherment under said import key encrypting key KEK1 to encipherment under said export key encrypting key KEK2 with said associated control vector C3 for transmission to said second data processing system.
17. The apparatus of claim 2, for performing a reencipherment from current master key to new master key function, which further comprises:
a current master key storage storing a current master key and a new master key storage storing a new master key coupled to said cryptographic processing means in said cryptographic facility;
said cryptographic key storage means storing said cryptographic key as key K in an encrypted form in which said key K is encrypted under a storage key which is a logical product of an associated control vector C1 and said current master key;
said cryptographic control means receiving over said input path a cryptographic service request for the reenciphering said cryptographic key K from said master key to encipherment under said new master key with said associated control vector C1 and said control vector checking means outputting in response thereto, an authorization signal to said cryptographic processing means that the function of reenciphering said cryptographic key K from said current master key to encipherment under said new master key is authorized;
said cryptographic processing means operating in response to said authorization signal, to receive said encrypted form of said cryptographic key K from said cryptographic key storage means and to decrypt said encrypted form thereof under a storage key which is a logical product of said associated control vector C1 and said current master key;
said cryptographic processing means operating in response to said authorization signal, to reencipher said cryptographic key K under a logical product of said associated control vector C1 and said new master key and outputting said reenciphered cryptographic key K and said associated control vector C1 to said cryptographic key storage means.
18. The apparatus of claim 2, for performing a lower control vector authority function, which further comprises:
said cryptographic key storage means storing said cryptographic key as key K in an encrypted form in which said key K is encrypted under a storage key which is a logical product of an associated control vector C1 and said master key;
said associated control vector C1 including a field defining export control;
said cryptographic control means receiving over said input path a cryptographic service request for lowering control vector authorit for said associated control vector C1 and said control vector checking means outputting in response thereto, an authorization signal to said cryptographic processing means that the function of lowering control vector authority for said associated control vector C1 is authorized;
said cryptographic processing means operating in response to said authorization signal, to receive said encrypted form of said cryptographic key K from said cryptographic key storage means and to decrypt said encrypted form thereof under a storage key which is a logical product of said associated control vector C1 and said master key;
said cryptographic processing means operating in response to said authorization signal, to substitute a second control vector C2 for said associated control vector C1, with said second control vector C2 having an export control field designating a lower authority;
said cryptographic processing means operating in response to said authorization signal, to encipher said key K under said master key with said second control vector C2 and outputting said enciphered key K to said cryptographic key storage means with said second control vector C2.
19. The apparatus of claim 2, for performing a reencipherment from master key function with a reduction in the export authority for the recipient, which further comprises:
said data processing system being a local data processing system connected to a first remote data processing system with which a secret key encrypting key KEK is shared;
said cryptographic key storage means storing said key encrypting key KEK in an encrypted form in which said KEK is encrypted under a storage key which is a logical product of an associated control vector C1 and said master key;
said cryptographic key storage means storing said cryptographic key as key K in an encrypted form in which said key K is encrypted under a storage key which is a logical product of an associated control vector C2 and said master key, said associated control vector C2 having an export field designating a first export authority;
said cryptographic control means receiving over said input path a cryptographic service request for reenciphering said cryptographic key K from said master key to encipherment under said key encrypting key KEK for export with an associated control vector C3 to said first remote processor, said associated control vector C3 having an export field designating a second export authority which is less than said first export authority of C2;
said control vector checking means outputting in response thereto, an authorization signal to said cryptographic processing means that the function of reenciphering said cryptographic key K from said master key to encipherment under said key encrypting key KEK for export is authorized;
said cryptographic processing means operating in response to said authorization signal, to receive said encrypted form of said cryptographic key K from said cryptographic key storage means and to decrypt said encrypted form thereof under a storage key which is a logical product of said associated control vector C2 and said master key;
said cryptographic processing means operating in response to said authorization signal, to receive said encrypted form of said key encrypting key KEK from said cryptographic key storage means and to decrypt said encrypted form thereof under a storage key which is a logical product of said associated control vector C1 and said master key;
said cryptographic processing means operating in response to said authorization signal, to reencipher said cryptographic key K under a logical product of said associated control vector C3 and said key encrypting key KEK and outputting said reenciphered cryptographic key K and said associated control vector C3 for transmission to said first remote data processing system.
said first remote data processing system having a lower authority to reexport said cryptographic key K because of said lower authority designated in said export field of said associated control vector C3.
20. The apparatus of claim 1, wherein said associated control vector further comprises:
said associated control vector includes a field defining link control which specifies whether a control vector associated with a cryptographic key can be omitted from transmission from said data processing system to a remote data processing system connected thereto due to the characteristics of said remote data processing system.
21. The apparatus of claim 1, wherein said associated control vector further comprises:
said associated control vector includes a field specifying whether the key assoicated therewith can be processed by an ANSI-type data processing system.
22. The apparatus of claim 1, wherein said associated. control vector includes fields enforcing the separation of key encryption keys based on two mutually exclusive intended uses.
23. The apparatus of claim 22, wherein said mutually exclusive intended uses are for notarized and non-notarized keys.
24. The apparatus of claim 22, wherein said mutually exclusive intended uses are for first type key encrypting keys using control vectors and second type key encrypting keys not using control vectors.
25. The apparatus of claim 22, wherein said mutually exclusive intended uses are for first type key encrypting keys used only by senders and second type key encrypting keys used only by receivers.
26. The apparatus of claim 22, wherein said mutually exclusive intended uses are for first type key encrypting keys used for translation of keys for shipment without allowing export of existing data keys stored under a master key and second type key encrypting keys used for translation of keys for shipment with allowance for export of existing data keys stored under a master key.
27. The apparatus of claim 22, wherein said mutually exclusive intended uses are for first type key encrypting keys which can be generated for export only and second type key encrypting keys which can be generated for local operational use and for export.
28. The apparatus of claim 22, wherein said mutually exclusive intended uses are for first type key encrypting keys which can be used in translation without allowing local operational use and second type key encrypting keys which can be used in translation and which are allowed for local operational use.
29. The apparatus of claim 22, wherein said mutually exclusive intended uses are for first type key encrypting keys which can be used in reencipher from master key operations and second type key encrypting keys which cannot be used in reencipher from master key operations.
30. The apparatus of claim 1, wherein said associated control vector includes a field to designate whether said cryptographic key is a single length key or a double length key.
31. In a data processing system which processes cryptographic service requests for the management of cryptographic keys which are associated with control vectors defining the functions which each key is allowed by its originator to perform, a method for validating that key management functions requested for a cryptographic key have been authorized by the originator of the key, comprising the steps of:
receiving a cryptographic service request for performing a key management function on a cryptographic key in a cryptographic facility characterized by a secure boundary through which passes an input path and an output path;
receiving a control vector associated with said cryptographic key and checking that said control vector authorizes the key management function which is requested by said cryptographic service request;
signalling that said key management function is authorized and initiating the performance of the requested key management function with said cryptographic key.
32. The method of claim 31, which further comprises the steps of:
storing in a storage means said cryptographic key in an encrypted form in which said cryptographic key is encrypted under a storage key which is a logical product of said associated control vector and a master key.
33. The method of claim 32, which further comprises:
said cryptographic service request being for the recovery of said cryptographic key from said storage means;
receiving said encrypted form of said cryptographic key from said storage means and decrypting said encrypted form under said storage key which is a logical product of said associated control vector and said master key.
34. The method of claim 32, wherein said storage key is the exclusive-OR product of said associated control vector and said master key.
35. The method of claim 32, wherein said associated control vector is stored with said encrypted form of said cryptographic key in said storage means.
36. The method of claim 31, wherein said associated control vector includes fields defining authorized types of cryptographic functions including key management functions, data encryption/decryption functions and PIN processing functions, and the key management functions type is designated;
and wherein said associated control vector further includes fields defining export control and usage.
37. The method of claim 31, wherein said associated control vector further comprises:
said associated control vector includes a field defining link control which specifies whether a control vector associated with a cryptographic key can be omitted from transmission from said data processing system to a remote data processing system connected thereto due to the characteristics of said remote data processing system.
38. The method of claim 31, wherein said associated control vector further comprises:
said associated control vector includes a field specifying whether the key associated therewith can be processed by an ANSI-type data processing system.
39. The method of claim 31, wherein said associated control vector includes fields enforcing the separation of key encryption keys based on two mutually exclusive intended uses.
40. The method of claim 39, wherein said mutually exclusive intended uses are for notarized and non-notarized keys.
41. The method of claim 39, wherein said mutually exclusive intended uses are for first type key encrypting keys using control vectors and second type key encrypting keys not using control vectors.
42. The method of claim 39, wherein said mutually exclusive intended uses are for first type key encrypting keys used only by senders and second type key encrypting keys used only by receivers.
43. The method of claim 39, wherein said mutually exclusive intended uses are for first type key encrypting keys used for translation of keys for shipment without allowing export of existing data keys stored under a master key and second type key encrypting keys used for translation of keys for shipment with allowance for export of existing data keys stored under a master key.
44. The method of claim 39, wherein said mutually exclusive intended uses are for first type key encrypting keys which can be generated for export only and second type key encrypting keys which can be generated for local operational use and for export.
45. The method of claim 39, wherein said mutually exclusive intended uses are for first type key encrypting keys which can be used in translation without allowing local operational use and second type key encrypting keys which can be used in translation and which are allowed for local operational use.
46. The method of claim 39, wherein said mutually exclusive intended uses are for first type key encrypting keys which can be used in reencipher from master key operations and second type key encrypting keys which cannot be used in reencipher from master key operations.
47. The method of claim 21, wherein said associated control vector includes a field to designate whether said cryptographic key is a single length key or a double length key.
48. The apparatus of claim 13, for performing a reencipherment from master key function, which further comprises:
said control vector checking means checking said control vector C1 associated with said key encrypting key KEK to ensure that the reencipher from master key function is authorized and said control vector checking means checking that said control vector C2 associated with said key K authorizes that said key K may be allowed to be exported using the reencipher from master key function.
49. The apparatus of claim 48 for performing a reencipherment from master key function, wherein said associated control vector C3 selectively enables said remote processor to reexport said cryptographic key K.
50. The apparatus of claim 14 for performing a reencipherment to master key function, wherein said control vector C1 associated with said key encrypting key KEK is checked to ensure that the reencipher to master key function is authorized.
51. The apparatus of claim 50 for performing a reencipherment to master key function, wherein said control vector C3 received from said remote data processing system, selectively permits further reexportation of said key K from said local data processing system.
52. The apparatus of claim 51 for performing a reencipherment to master key function, wherein said control vector C2 is selectively set by said local data processing system to permit further reexportation of said cryptographic key K from said local data processing system.
53. The apparatus of claim 16 for performing a translate key function, which further comprises:
said control vector checking means checking said control vector C1 associated with said import key encrypting key KEK1, to ensure that KEK1 is authorized as an import key encrypting key in the translate key function and,
said control vector checking means checking that said control vector C2 associated with said export key encrypting key KEK2 so as to ensure that KEK2 is authorized as an export key encrypting key in said translate key function.
54. The apparatus of claim 19 for performing a reencipherment from master key function with a reduction in the export authority for the recipient, said control vector checking means checking said control vector C1 associated with said key encrypting key KEK to ensure that the reencipher from master key function is authorized and said control vector checking means checking that said control vector C2 associated with said key K authorizes that said key K may be allowed to be exported using the reencipher from master key function.
55. In a data processing system which processes cryptographic service requests for the management of cryptographic keys which are associated with control vectors defining the functions which each key is allowed by its originator to perform, an apparatus for validating that key management functions requested for a cryptographic key have been authorized by the originator of the key, comprising:
an information path for receiving said cryptographic service requests, cryptographic keys and their associated control vectors, and for providing responses thereto;
a control means coupled to said information path, for receiving a cryptographic service request for performing a key management function with a cryptographic key;
a control vector checking means coupled to said information path, for receiving a control vector associated with said cryptographic key and having an input coupled to said control means, for receiving control signals to initiate checking that said control vector authorizes the key management function which is requested by said cryptographic service requests;
a cryptographic processing means coupled to said control means, for performing key management functions;
said control vector checking means having an authorization output coupled to an input of said cryptographic processing means, for signaling that said key management function is authorized, the receipt of which by said cryptographic processing means initiates the performance of the requested key management function with said cryptographic key.
56. The apparatus of claim 55, which further comprises:
a master key storage coupled to said cryptographic processing means, for storing a master key;
a cryptographic key storage means coupled to said information path, for storing said cryptographic key.
57. The apparatus of claim 56, wherein said cryptographic key is stored in said key storage means in an encrypted form in which said cryptographic key is encrypted under a storage key which is a logical product of said associated control vector and said master key stored in said master key storage.
58. The apparatus of claim 57, wherein said storage key is the exclusive-OR product of said associated control vector and said master key stored in said master key storage.
59. The apparatus of claim 55, wherein said control vector checking means and said cryptographic processing means are located inside a cryptographic facility characterized by a secure boundary, for providing a secure location for executing said key management functions.
60. The apparatus of claim 55, wherein said key management function is a generation of a key set.
61. The apparatus of claim 55, wherein said key management function is a reencipherment from master key function.
62. The apparatus of claim 55, wherein said key management function is a reencipherment to master key function.
63. The apparatus of claim 55, wherein said key management function is a generate key function.
64. The apparatus of claim 55, wherein said key management function is a translate key function.
65. The apparatus of claim 55, wherein said key management function is a reencipherment from current master key to new master key function.
66. The apparatus of claim 55, wherein said key management function is a lower control vector authority function.
67. The apparatus of claim 55, wherein said key management function is a reencipherment from master key function with a reduction in the export authority for the recipient.
Description
BACKGROUND OF THE INVENTION
1. Technical Field
2. Related Applications
3. Background Art
The following copending patent application is related to this invention and is incorporated herein by reference: B. Brachtl, et al., "Controlled Use of Cryptographic Keys via Generating Stations Established Control Values", Ser. No. 55,502, filed March 1987, and assigned to IBM Corporation.
The cryptographic transformation of data is ordinarily defined by a selected algorithm, or procedure, under the control of a key. Since the algorithm is normally public knowledge, protection of the transformed, or enciphered, data depends on secrecy of the key. Thus the key must be kept secret to prevent an opponent from simply using the known algorithm and key to recover the enciphered data. The protection of the data therefore hinges on the protection of secret keys.
Key Management encompasses the facilities, functions and procedures in a cryptographic system to handle cryptographic keys and key-related information in such a way as to protect the secrecy and integrity of the keys.
In order to support the primary cryptographic requirements of a user or host system, the system Key Management facility usually supports several capabilities including, Key Installation, Key Storage, Key Generation, and Key Distribution for both importing and exporting keys.
In all cases the general objective is to prevent unauthorized disclosure or modification of cryptographic keys.
Since enciphered data may be exchanged by systems employing the same cryptographic algorithm, the ability to exchange a secret key or keys may be necessary. In order to protect the privacy of a secret key during its shipment from the key originator to the intended recipient, the key itself must be enciphered under another secret key (already shared by the two parties). Key distribution protocols must be defined to support compatible, secure exchange of keys among cryptographic systems.
The storage of keys on insecure media (i.e., storage not within a secure area) requires that keys themselves be enciphered. The Master Key concept is one in which all keys used by a cryptographic system are stored in enciphered form under a single key called the Master Key. The Master Key itself must be protected from disclosure or modification. Non-cryptographic means are usually provided to protect the Master Key (such as physical access control).
The prior art has failed to provide a practical and flexible Key Management system which maintains high data security standards.
OBJECTS OF THE INVENTION
It is therefore an object of the invention to provide integrity for the cryptographic algorithm and certain higher-level cryptographic functions.
It is another object of the invention to provide for protection of the integrity of stored or distributed keys.
It is another object of the invention to provide for prevention of the misuse of stored or distributed keys (e.g., using a privacy key as an authentication key).
It is another object of the invention to provide for restricting the usage of stored or distributed keys (e.g., authentication verification only).
It is another object of the invention to provide for secure installation of the Master Key and other manually-installed key-encrypting keys.
It is another object of the invention to provide for secure generation of new key-encrypting keys and data encrypting keys.
SUMMARY OF THE INVENTION
These and other objects, features and advantages are accomplished by the invention disclosed herein. The invention referred to herein as the Cryptographic Architecture (CA), is implemented in a data processing system. The system executes a program which outputs cryptographic service requests for the management of cryptographic keys which are associated with control vectors defining the functions which each key is allowed by its originator to perform. The invention is an apparatus and method for validating that key management functions requested for a cryptographic key by the program have been authorized by the originator of the key.
The invention includes a cryptographic facility characterized by a secure boundary through which passes an input path for receiving the cryptographic service requests, cryptographic keys and their associated control vectors, and an output path for providing responses thereto. There can be included within the boundary a cryptographic instruction storage coupled to the input path, a control vector checking means and a cryptographic processing means coupled to the instruction storage, and a master key storage coupled to the processing means, for providing a secure location for executing key management functions in response to the received service requests.
The cryptographic instruction storage receives over the input path a cryptographic service request for performing a key management function on a cryptographic key. The control vector checking means has an input coupled to the input path for receiving a control vector associated with the cryptographic key and an input connected to the cryptographic instruction storage, for receiving control signals to initiate checking that the control vector authorizes the key management function which is requested by the cryptographic service request.
The control vector checking means has an authorization output connected to an input of the cryptographic processing means, for signalling that the key management function is authorized, the receipt of which by the cryptographic processing means initiates the performance of the requested key management function with the cryptographic key.
The invention further includes a cryptographic key storage means coupled to the cryptographic facility over the input and output paths, for storing the cryptographic key in an encrypted form in which the cryptographic key is encrypted under the storage key which is a logical product of the associated control vector and a master key stored in the master key storage.
For example, the cryptographic instruction storage can receive over the input path a cryptographic service request for recovering the cryptographic key from the cryptographic key storage means and the control vector checking means outputs in response thereto, an authorization signal to the cryptographic processing means that the function of recovering the cryptographic key is authorized. The cryptographic processing means then operates in response to the authorization signal, to receive the encrypted form of the cryptographic key from the cryptographic key storage means and to decrypt the encrypted form under the storage key which is a logical product of the associated control vector and the master key stored in the master key storage.
The control vector includes fields defining authorized types of cryptographic functions including key management functions, data encryption/decryption functions and PIN processing functions. The associated control vector also includes fields defining export control and usage of the keys. These various fields enforce the separation of several types of keys which have intended uses which should be made mutually exclusive in order to maintain the security of the system.
The invention enables the flexible control of many cryptographic key management functions in the generation, distribution and use of cryptographic keys, while maintaining a high security standard.
BRIEF DESCRIPTION OF THE DRAWINGS
These and other objects, features and advantages of the invention will be more fully appreciated with reference to the accompanying figures:
FIG. 1 is a System Diagram showing the major components of the Cryptographic Facility (CF).
FIG. 2 is a System Diagram showing the components of the CF, software driver CFAP and cryptographic application programs.
FIG. 3 shows where Control Vectors are applied in various inter-system communications scenarios.
FIG. 4 illustrates the fundamental cryptographic key separation.
FIG. 5 illustrates data key separation.
FIG. 6 illustrates PIN key separation.
FIG. 7 illustrates Key Encrypting Key separation.
FIG. 8 summarizes the relative priority of implementing the various types of key separation.
FIG. 9 summarizes the separation provided for each of the defined key types.
FIG. 10 shows the general format for Control Vectors (CV).
FIG. 11 shows the CV format for Privacy keys.
FIG. 12 illustrates the method of encrypting a key K under the Master Key with an Extended Control Vector.
FIG. 13 shows the CV format for MAC keys.
FIG. 14 shows the CV format for Data Compatibility keys.
FIG. 15 shows the CV format for Data Translate (XLATE) keys.
FIG. 16 shows the CV format for ANSI Data keys.
FIG. 17 shows the CV format for PIN-encrypting keys.
FIG. 18 shows the CV format for PIN-generating keys.
FIG. 19 shows the CV format for Key Encrypting Key (KEK) Sender.
FIG. 20 shows the CV format for KEK Receiver.
FIG. 21 shows the CV format for ANSI KEKs.
FIG. 22 shows the CV format for Key Parts.
FIG. 23 shows the CV format for Intermediate ICVs.
FIG. 24 shows the CV format for Tokens.
FIG. 25 is a Block Diagram of the Encode instruction.
FIG. 26 is a Block Diagram of the Decode instruction.
FIG. 27 is a Block Diagram of the Encipher instruction.
FIG. 28 is a Block Diagram of the Decipher instruction.
FIG. 29 is a Block Diagram of the Generate Message Authentication Code (Genmac) instruction.
FIG. 30 is a Block Diagram of the Verify Message Authentication Code (Vermac) instruction.
FIG. 31 is a Block Diagram of the Translate Cipher Text instruction.
FIG. 32 lists the types and subtypes of keys which may be generated for each mode of the Generate Key Set (GKS) instruction.
FIG. 33 is a Block Diagram of the Generate Key Set instruction.
FIG. 34 shows the valid combinations of CV Types for the pair of keys generated by GKS OP-OP mode.
FIG. 35 shows the valid combinations of Left versus Right CV attributes of Importing or Exporting KEKs used in the various modes of GKS. "Key Form and Link Control attributes are specified.
FIG. 36 shows the valid combinations of CV Key Forms and Link Control for pairs of Imported or Exported keys generated by various modes of GKS.
FIG. 37 shows the valid combinations of CV Types for the pair of keys generated by GKS OP-IM mode.
FIG. 38 is a Block Diagram of the Reencipher From Master Key instruction.
FIG. 39 is a Block Diagram of the Reencipher to Master Key instruction.
FIG. 40 is a Block Diagram of the Keygen instruction.
FIG. 41 is a Block Diagram of the Encipher Under Master Key instruction.
FIG. 42 is a Block Diagram of the Translate Key instruction.
FIG. 43 shows the valid combinations of Left versus Right CV Key Form attributes for the Importing and Exporting KEKs used in the Translate Key instruction.
FIG. 44 shows the Block Diagram for Mode 0 (Key Mode) of the Reencipher to New Master Key instruction.
FIG. 45 shows the Block Diagram for Mode 1 (Token Mode) of the Reencipher to New Master Key instruction.
FIG. 46 shows the Block Diagram for Mode 0 (Key Mode) of the Reencipher to Current Master Key instruction.
FIG. 47 shows the Block Diagram for Mode 1 (Token Mode) of the Reencipher to Current Master Key instruction.
FIG. 48 and FIG. 49 show the Block Diagram of the ANSI Create Partial Notarizing Key instruction.
FIG. 50 shows the Block Diagram for the ANSI Reencipher From Master Key (ARFMK) instruction.
FIG. 51 shows the valid CV Usage attributes for a data key to be exported by ARFMK.
FIG. 52 shows the valid combinations of CV Type and Key Form for the Left and Right halves of the exporting KEK versus the corresponding attributes of the key to be exported in the ARFMK instruction.
FIG. 53 shows the valid CV Usage attributes which may be specified for the CSM MAC key produced as a by-product of ARFMK.
FIG. 54 shows the block diagram for the ANSI Reencipher to Master Key (ARTMK) instruction.
FIG. 55 shows the valid CV Usage attributes for a data key to be imported by ARTMK.
FIG. 56 shows the valid combinations of CV Type and Key Form for the Left and Right halves of the importing KEK versus the corresponding attributes of the key to be imported in the ARTMK instruction.
FIG. 57 shows the valid CV Usage attributes which may be specified for the CSM MAC key produced as a by-product of ARTMK.
FIG. 58 and FIG. 59 show the Block Diagram for the ANSI Translate Key (AXLTKEY) instruction.
FIG. 60 shows the valid CV Usage attributes which may be specified for the CSM MAC key produced as a by-product of AXLTKEY.
FIG. 61 shows the Block Diagram for the ANSI Combine KDs (ACOMBKD) instruction.
FIG. 62 shows the valid CV Usage attributes for the first of two "partial" CSM MAC keys input to the ACOMBKD instruction.
FIG. 63 shows the valid CV Usage attributes for the second of two "partial" CSM MAC keys input to the ACOMBKD instruction.
FIG. 64 shows the valid CV Usage attributes which may be specified for the CSM MAC key produced by ACOMBKD.
FIGS. 65, 66, 67 and 68 show a mapping from common key management requirements or activities to instructions from which these requirements may be satisfied.
FIG. 69 shows the key state (OP, IM EX) transformations performed by certain instructions. Export and Import Channels represent unidirectional avenues of conveyance for keys imported and exported from the Cryptographic Facility.
FIG. 70 shows the valid CV types which may be imported or exported on each Channel Type (CV, CV=), and ANSI).
FIG. 71 shows the valid combinations of Distribution Modes and CV Link Control attributes.
FIG. 72 depicts the Key Translation process performed at a node C on behalf of nodes A and B.
FIG. 73 shows a portion of the Key Encrypting Key Data Set (KDDS) where KEKs are stored.
FIG. 74 is an ANSI X9.l7 System Node Diagram.
FIG. 75 shows the functional interfaces among components within an ANSI X9.l7 node.
FIG. 76 is an ANSI Point-to-Point Environment System Diagram.
FIG. 77 is an ANSI Key Distribution Center (KDC) Environment System Diagram.
FIG. 78 is an ANSI Key Translation Center (KTC) Environment System Diagram.
FIG. 79 shows the distribution of KEKs ((*KK) in a CCA ANSI X 9.17 implementation in tabular form.
FIG. 80 and FIG. 81 show the distribution of Data Keys (KD) in a CCA ANSI X 9.17 implementation in tabular form.
FIG. 82 shows the Electronic Code Book (ECB) mode of DES encryption.
FIG. 83 shows the Cipher Block Chaining (CBC) mode of DES encipherment.
FIG. 84 shows the CBC mode of DES decipherment.
FIG. 85 shows the Message Authentication (MAC) algorithm.
FIGS. 86, 87 and 88 summarize the equations for each of the instructions.
DESCRIPTION OF THE BEST MODE FOR CARRYING OUT THE INVENTION
A flexible key usage control method and apparatus are described, which is referred to herein as the Cryptographic Architecture (CA). The method enforces strict key separation within the local cryptographic facility and between systems (I.e. "on-the-link"). The method uses Control Vectors which force the recipient or user of a key to use the key in a manner consistent with the intentions of the originator of the key.
All keys stored on insecure media outside the cryptographic facility are encrypted under a key formed from a function of the Master Key and a specific Control Vector value dictated by the originator of the stored key. The Master Key and possibly a few other keys are stored in the clear within the physically secure cryptographic facility. At no time does any key unintentionally appear in the clear outside the secure cryptographic facility.
Keys transmitted from one system to another are encrypted under a key formed from a function of a key-encrypting key and a specific Control Vector value dictated by the originator (and possibly the sender) of the key. Where such key usage control interferes with support for specific key distribution protocols, on-the-link control is not be enforced.
A set of primitive cryptographic functions, or instructions, are defined. These instructions form the basis of the functional security baseline. Each instruction is specified in terms of its input and output parameters, function description, and Control Vector processing. For integrity, the instructions are intended to be implemented completely within the secure cryptographic facility.
A very strong and positive feature of the cryptographic design is the strict adherence to the principle of limited function. This principle calls for the cryptographic interfaces to be implemented such that only the desired, and anticipated, cryptographic functions are permitted, and nothing else. It is the "nothing else" that is important. It has been found that attacks are frequently developed by using the architected interfaces of prior systems in some way not specifically required, or called for under the architecture, but which have not been prohibited by the implementation.
FIG. 1 gives a Block Diagram representation of the data processing system with the cryptographic facility therein. In FIG. 1, the data processing system 2 executes a program such as the crypto facility access programs and the application programs illustrated in FIG. 2. These programs output cryptographic service requests for the management of the cryptographic keys which are associated with control vectors. The general format for a control vector is shown in FIG. 10. Control vectors define the function which the associated key is allowed by its originator to perform. The cryptographic architecture invention herein is an apparatus and a method for validating that key management functions requested for a cryptographic key by the program, have been authorized by the originator of the key.
As is shown in FIG. 1, contained within or associated with the data processing system 2 is a cryptographic facility 4 which is characterized by a secure boundary 6. An input/output path 8 passes through the secure boundary 6 for receiving the cryptographic service request, cryptographic keys and their associated control vectors from the program. The input/out path 8 outputs responses to those cryptographic requests from the cryptographic facility. Included within the secure boundary 6 is a cryptographic instruction storage 10 which is coupled by units of the bus 12 to the input/output path 8. A control vector checking units 14 is coupled to the instruction in storage 10 and a cryptographic processing units 16 is also coupled to the instruction storage 10. A master key storage 18 is coupled to the cryptographic processing unit 16. The cryptographic facility 4 provides a secure location for executing key management functions in response to the received service request.
The cryptographic instruction storage 10 receives over the input/output path 8 a cryptographic service request for performing a key management function with a cryptographic key. The control vector checking unit 14 has an input coupled to the input/output path 8, for receiving a control vector associated with the cryptographic key. The control vector checking unit 14 also has an input connected to the cryptographic instruction storage 10, for receiving control signals to initiate checking that the control vector authorizes the key management function which is requested by the cryptographic service request.
The control vector checking unit 14 has an authorization output 20 which is connected to an input of the cryptographic processing unit 16, for signalling that key management function is authorized, the receipt of the authorization signal by the cryptographic processing unit 16 initiates the performance of the requested key management function with the cryptographic key. A cryptographic key storage unit 22 is coupled to the cryptographic facility 14 over the input/output path 8. The cryptographic key storage unit 22 stores the cryptographic key in an encrypted form in which the cryptographic key is encrypted under a storage key which is a logical product of the associated control vector and the master key stored in the master key storage 18.
An example of recovering an encrypted key from the cryptographic key storage 22 occurs when the cryptographic instruction storeage 10 receives over the input/output path 8 a cryptographic service request for recovering the cryptographic key from the cryptographic key storage units 22. The control vector checking unit 14 will then output in response thereto, an authorization signal on line 20 to the cryptographic processing unit 16 that the function of recovering the cryptographic key is authorized. The cryptographic processing unit 16 will then operate in response to the authorization signal on line 20, to receive the encrypted form of the cryptographic key from the cryptographic key storage 22 and to decrypt the encrypted form under the storage key which is a logical product of the associated control vector and the master key stored in the master key storage 18.
The storage key is the exclusive-OR product of the associated control vector and the master key stored in the master key storage 18. Although the logical product is an exclusive OR operation in the preferred embodiment, it can also be other types of logical operations.
The associated control vector, whose general format is shown in FIG. 10, is stored with the encrypted form of its associated cryptographic key in the cryptographic key storage 22. Since all keys stored on a cryptographic storage encrypted under the master key, a uniform method for encryption and decryption of encrypted keys thereon can be performed.
The associated control vector, whose general format is shown in FIG. 10, includes fields defining the authorized types of cryptographic functions, including key management functions, data encryption/decryption functions and personal identification numbers (PIN) processing functions. In the key management applications, the key management functions type is designated for the type field. The associated control vector also includes additional fields which can define export control for the keys and associated encrypted information and the usage of the keys and associated encrypted information.
The invention shown in FIG. 1 can perform the generation of a key set, which is a pair of keys having several classes of uses. A random number source 26 or a stored random number in the working storage 24 of the cryptographic facility 4, has an input connected to the cryptographic processing units over the bus 12, for supplying a random number thereto.
The cryptographic instruction storage 10 will then receive over the input/output path 8 a cryptographic service request for the generation of a key pair from the random number output from the random number source 26, with associated first and second control vectors C3 and C4. The control vector checking unit 14 will then output in response thereto, an anthorization signal on line 20 to the cryptographic processing unit 16 that the function of generating a key pair from the random number is authorized. The cryptographic processing unit 16 then operates in response to the authorization signal on line 20, to output the random number as a first generated key in an encrypted form in which the random number is encrypted in a key which is a logical product of the first associated control vector C3 and a first key K1. The cryptographic processing unit 16 then further operates in response to the authorization signal on line 20, to output the random number as a second generated key in an encrypted form in which the random number is encrypted under a key which is a logical product of the second associated control vector C4 and a second key K2. There are a variety of combinations of usages which can be authorized by the control vectors C3 and C4 in accordance with the invention. One combination is for the production of two keys which are operational in the local data processing system 2 and, in this case, the first and second keys K1 and K2 are the random number and the first and second control vectors C3 and C4 only authorize operational usage within the local data processing system 2. A second combination can be for the production of a first generated key which is only operational in the local data processor 2 and a second generated key which can be exported to a remote data processing system 30 just connected to the local system 2, and in this case the first key K1 is the random number and the first control vector C3 only authorizes operational usage within the local data processing system 2 whereas, the second key K2 is a key encrypting key KEK2 and the second control vector C4 authorizes exportation to the remote data processing system 30. A third case is for the production of a first generated key which can be exportated to a first remote data processing system 30 connected to the local data processing system 2 and a second generated key which can be exportated to a second remote data processing system 30' connected to the local data processing system 2, and in this case, the first key K1 is a key encrypting key KEK1 and the first control vector C3 authorizes exportation to the first remote data processing system 30, whereas the second key K2 is a key encrypting key KEK2 and the second control vector C4 authorizes exportation to the second remote data processing system 30'. A fourth combination is for the production of a first generated key which is only operational in the local data processing system 2 and a second generated key which can be imported from a remote data processing system 30 connected to the local system 2, and in this case, the first key K1 is the random number and the first control vector C3 only authorizes operational usage within the local data processing system 2, whereas the second key K2 is a key encrypting key KEK2 and the second control vector C4 authorizes importation from the remote data processing system 30 to the local data processing system 2. A fifth case is for the production of a first generated key which can be imported from a first remote data processing system 30 connected to the local data processing system 2 and a second generated key which can be exported to a second remote data processing system 30' connected to the local system 2, and in this case the first key K1 is a key encrypting key KEK1 and a first control vector C3 authorizes importation from the first remote data processing system 30, whereas a second key K2 is a key encrypting key KEK2 and a second control vector C4 authorizes exportation to the second remote data processing system 30'.
The invention shown in FIG. 1 can perform the operation of reencipherment from master key function as follows. The data processing system 2 is connected over the communications link 28 to a remote data processing 30, with which a secret key encrypting key KEK is shared. The cryptographic key storage unit 22 stores the key encrypting key KEK in an encrypted form in which KEK is encrypted under a storage key which is a logical product of an associated control vector C1 and the master key. The cryptographic key storage units 22 also stores the cryptographic key as key K in an encrypted form in which key K is encrypted under a storage key which is a logical product of an associated control vector C2 and the master key.
The cryptographic instruction storage 10 will receive over the input/out path 8 a cryptographic service request for reencyphering the cryptographic key K from the master key to encipherment under the key encrypting key KEK for the purpose of export with an associated control vector C3 to the remote data processing system 30. The control vector checking unit 14 will output in response thereto, an authorization signal on line 20 to the cryptographic processing unit 16 that the function of reenciphering the cryptographic key K from the master key to encipherment under the key encrypting key KEK for export is authorized.
The cryptographic processing unit 16 will operate in response to the authorization signal on line 20, to receive the encrypted form of the cryptographic key K from the cryptographic key storage units 22 and to decrypt the encrypted form thereof under a storage key which is a logical product of the associated control vector C2 and the master key. The cryptographic processing unit 16 will further operate in response to the authorization signal on line 20, to receive the encrypted form of the key encrypting key KEK from the cryptographic key storage unit 22 and to decrypt the encrypted form thereof under a storage key which is a logical product of the associated control vector C1 and the master key.
The cryptographic processing unit 16 will then operate in response to the authorization signal on line 20, to reencipher the cryptographic key K under a logical product of the associated control vector C3 and the key encrypting key KEK and will output the reencipher cryptographic key K and the associated control vector C3 for transmission over the communications link 28 to the first remote data processing system 30.
The invention of FIG. 1 can perform the operation of a reencipherment to the master key function as follows. The data processing system 2 is connected over the communication link to the remote data processing system 30 with which it shares a secret key encrypting key KEK. The cryptographic key storage units 22 stores the key encrypting key KEK in an encrypted form in which KEK is encrypted under a storage key which is a logical product of an associated control vector C1 and the master key.
The remote data processing system 30 transmits over the communications link 28 to the local data processing system 2 a cryptographic key K enciphered under the key encrypting key KEK with an associated control vector C3. The cryptographic instruction storage 10 receives over the input/output path 8 a cryptographic service request for reenciphering the cryptographic key K from the key encrypting key KEK to encipherment under the master key with an associated control vector C2 for storage in the cryptographic key storage 22. The control vector checking unit 14 then outputs in response thereto, an authorization signal on line 20 to the cryptographic processing units 16 that the function of reenciphering the cryptographic key K from the key encrypting key KEK to encipherment under the master key for storage, is authorized. The cryptographic processing unit 16 then operates in response to the authorization signal on line 20 to reencipher the key K from the key encrypting key KEK to encipherment under the master key with the control vector C2 and outputs the reenciphered key K to the cryptographic key storage 22.
The invention of FIG. 1 can be further applied to generate a single key as follows. The random number source 26 has an output connected to the cryptographic processing unit 16 over the bus 12, for supplying a random number thereto. The cryptographic instruction storage 10 receives over the input/output path 8 a cryptographic service request for the generation of a key from the random number with an associated control vector C1. The control vector checking unit 14 outputs in response thereto, an authorization signal on line 20 to the cryptographic processing unit 16 that the function of generating a key from random numbers is authorized. The cryptographic processing unit 16 operates in response to the authorization signal on line 20, through output the random number as a generated key in an encrypted form in which the random number is encrypted under a key which is a logical product of the associated control vector C1 and the master key.
The invention of FIG. 1 can further operate to perform a translate key function, as follows. The data processing system 2 of FIG. 1 is a local system which is connected over a communications link 28 to a first remote data processing system 30 with which it shares a secret import key encrypting key KEK1. The local data processing system 2 is also connected over a communications link 28' to a second remote data processing system 30' with which it shares a secret export key encyrpting key KEK2. The cryptographic key storage 22 stores the import key encrypting key KEK1 in an encrypted form in which KEK1 is encrypted under a storage key which is a logical product of an associated control vector C1 and the master key. The cryptographic storage key 22 stores the export key encrypting key KEK2 in an encrypted form in which KEK2 is encrypted under a storage key which is a logical product of an associated control vector C2 and the master key.
The first remote data processing system 30 transmits over the communications link 28 to the local data processing system 2 a cryptographic key K enciphered under the import key encrypting key KEK1 with an associated control vector C3. The cryptographic instruction storage 10 receives over the input/output path 8 a cryptographic request for translating the cryptographic key K from encipherment under the import key encrypting key KEK1 to encipherment under the export key encrypting key KEK2 with an associated control vector C3 for transmission over the communications link 28' to the second data processing system 30'. The control vector checking unit 14 outputs in response thereto, an authorization signal on line 20 to the cryptographic processing unit 16 that the function of translating the cryptographic key K from encipherment under the import key encrypting key KEK1 to encipherment under the export key encrypting key KEK2 is authorized.
The cryptographic processing unit 16 operates in response to the authorization signal on line 20, to translate the cryptographic key K from encipherment under the import key encrypting key KEK1 to encipherment under the export key encrypting key KEK2 with the associated control vector C3 for transmission over the communications link 28' to the second data processing system 30'.
Various restrictions can be applied using the control vectors C1, C2 and C3 so as to prevent the local data processing system 2 from reading or from operating with the key K so that it can be transferred from the originating data processing unit 30 to the destination data processing unit 30' in a secure manner.
The invention of FIG. 1 can operate to perform a reencipherment from current master key to new master key function, as follows. A current master key storage such as the working storage 24, will store a current master key and a new master key can be stored in the master key storage 18, and both the current master key storage 24 and the master key storage 18 are coupled to the cryptographic processing unit 16 and the cryptographic facility 4. The cryptographic key storage 22 stores a cryptographic key such as key K in an encrypted form in which key K is encrypted under a storage key which is a logical product of an associated control vector C1 and the current master key. The cryptographic instruction storage will receive over the input/output path 8 a cryptographic service request for reenciphering the cryptographic key K from the current master key to encipherment under the new master key with the associated control vector C1 and the control vector checking units will output in response thereto an authorization signal on line 20 to the cryptographic processing unit 16 that the function of reenciphering the cryptographic key K from the current master key to encipherment under the new master key, is authorized.
Cryptographic processing unit 16 will operate in response to the authorization signal on line 20, to receive the encrypted form of the cryptographic key K from the cryptographic storage 22 and to decrypt the decrypted form thereof under a storage key which is a logical product of the associated control vector C1 and the current master key. Cryptographic processing unit 16 will then operate in response to the authorization signal on line 20, to reencipher the cryptographic key K under a logical product of an associated control vector C1 and the new master key and output the reenciphered cryptographic key K and the associated control vector C1 to the cryptographic key storage 22.
The invention of FIG. 1 will operate to perform a lowering of the authority specified by a control vector for the usage of a key, and this is accomplished as follows. The cryptographic key storage 22 stores the cryptographic key as key K in an encrypted form in which the key K is encrypted under a storage key which is a logical product of an associated control vector C1 and the master key. The associated control vector C1 includes a field which defines export control, for example. The cryptographic instruction storage 10 receives over the input/output path 8 a cryptographic service request for lowering the control vector authority for the associated control vector C1 and the control vector checking unit 14 outputs in response thereto, an authorization signal on line 20 to the cryptographic processing unit 16 that the function of lowering the control vector authority for the associated control vector C1, is authorized.
Cryptographic processing unit 16 then operates in response to the authorization signal on line 20, to receive encrypted form of the cryptographic key K from the cryptographic key storage 22 and to decrypt the encrypted form thereof under a storage key which is a logical product of the associated control vector C1 and the master key. The cryptographic processing unit 16 then operated in response to the authorization signal on line 20, to substitute a second control vector C2 for the associated control vector C1, with the second control vector C2 having an export control field which designates a lower authority than that which was designated for the previous control vector C1. The cryptographic processing unit 16 then operates in response to the authorization signal on line 20, to encipher the key K under the master key with the second control vector C2 and to output the enciphered key K to the cryptographic storage 22 with the second control vector C2.
The invention of FIG. 1 will operate to perform a reencipherment from master key function with a reduction in the export authority for the recipient, in the following manner. The data processing system is a local data processing system 2 which is connected to a first remote data processing system 30 with which a secret key encrypting is shared. The cryptographic storage 22 stores the key encrypting key KEK in an encrypted form in which the KEK is encrypted under a storage key which is a logical product on an associated control vector C1 and the master key. The cryptographic key storage 22 stores the cryptographic key as key K in an encrypted form in which a key K is encrypted under a storage key which is a logical product of an associated control vector C2 and the master key, the associated control vector C2 having an export field designating a first export authority. The cryptographic instruction storage 10 receives over the input/output path 8 a cryptographic service request for reenciphering the cryptographic key K from the master key to encipherment under the key encrypting key KEK for export with an associated control vector C3 to the first remote data processing 30, the associated control vector C3 having an export field designating a second export authority which is less than the first export authority of C2.
The control vector checking unit 14 outputs in response thereto, an authorization signal on the line 20 to the cryptographic processing unit 16 that the function of reenciphering the cryptographic key K from the master key to encipherment under the key encrypting key KEK for export is authorized. The cryptographic processing unit 16 operates in response to the authorization signal on line 20, to receive the encrypted form of the encrypted key K from the cryptographic key storage 22 and to decrypt the encrypted form thereof under a storage key which is a logical product of the associated control vector C2 and the master key. The cryptographic processing unit 16 operates in response to the authorization signal on line 20, to receive the encrypted form of the key encrypting key KEK from the cryptographic key storage 22 and to decrypt the encrypted form thereof under a storage key which is a logical product of the associated control vector C1 and the master key.
The cryptographic processing unit 16 then operates in response to the authorization signal on line 20, to reencipher the cryptographic key K under a logical product of the associated control vector C3 and the key encrypting key KEK and outputs the reenciphered cryptographic key K and the associated control vector C3 for transmission to the first remote data processing system 30. The first remote data processing system now has a lower authority for reexportation of the cryptographic key K because of the lower authority designated in the export field of the associated control vector C3.
The invention of FIG. 1 can further provide for link control operations in the following manner. The associated control vector includes a field which defines link control which specifies whether the control vector associated with the cryptographic key should be omitted from transmission from the local data processing system to a remote data processing system 30 connected thereto, due to the characteristics of the remote data processing system 3. For example, the remote data processing system may not be capable of assimilating and processing control vectors. The control vectors which provide for allowing their separation from the associated cryptographickey upon transmission, confer a lower security trustworthiness to the resulting operations performed by the associated cryptographic key. In this manner, those systems such as the local data processing system 2 which are able to make use of the control vectors, have a higher security trustworthiness conferred upon them than can be conferred upon remote systems that do not have the capacity to use control vectors. The associated control vector can also include a field which specifies whether the key associated therewith can be processed by an ANSI-type data processing system as the remote processing 30.
The invention of FIG. 1 has the associated control vector, generally shown in FIG. 10, which includes fields for enforcing the separation of key encrypting keys based on two mutually exclusive intended uses. FIG. 7 illustrates the organization of separating the various key encrypting keys by their intended usage. For example, mutually exclusive intended uses can be for notarized and non-notarized keys. Another form of mutually exclusive intended uses would be for first-type key encrypting key which uses control vectors and a second-type key encrypting key which does not use control vectors. Another example of mutually exclusive intended uses is for a first-type of key encrypting keys to be used only by senders and a second-type of key encrypting keys to be used only by receivers. Another example of mutually exclusive intended uses for which control vectors enforce key separation is for a first-type of key encrypting keys which can be used for the generation of key sets and for the translation of keys for shipment without allowing the export of existing data keys stored under a master key and a second-type of key encrypting keys which can be used for the generation of key sets and the translation of keys for shipment which do allow for the export of existing data keys stored under a master key. Another example of mutually exclusive intended uses for which the control vector enforces key separation is for a first-type of key encrypting keys which can be generated for export only and a second-type of key encrypting keys which can be generated for operational use and for export. Another example of mutually exclusive intended uses for which control vectors enforce key separation is for a first-type of key encrypting keys which can be used in translation without allowing local operational use and a second-type of key encrypting keys which can be used in translation and also will allow local operational use. Another example of mutually exclusive intended uses for which control vectors enforce key separation is for a first-type of key encrypting keys which can be used in the reencipher from master key operation and a second-type of key encrypting keys which cannot be used in a reencipher from master key operation.
The control vector, as generally shown in FIG. 10, can also include a field to designate whether the cryptographic key associated therewith is a single length key or a double length key.
The following provides a more detailed description of the components and operations of the invention.
FIG. 2 shows the major components of a crypto subsystem. The cryptographic subsystem consists of a Crypto Facility (CF), Crypto Facility Access Program (CFAP), and Application Program (AP). Normally, the CF is implemented in hardware, inside a physically secure box. Depending upon the implementation, the CF, CFAP, and AP could all be in a physically secure box.
The Cryptographic Facility 4 consists of:
Key Registers
The registers and their usages are described below:
Master Key Register 18
The master key register is 128 bits wide, containing the master key.
New Master Key (NMK) register:
The new master key register is 128 bits wide, containing the new master key that is going to become the current master key. The New Master Key will become the current master key only after a special instruction, the SMK instruction is issued to load the value of new master key into the master key register.
Old Master Key Register
The old master key register is 128 bits wide, containing the master key that was replaced by the current master key. The master key update mechanism is such that the current master key becomes the old master key prior to the new master key becoming the current master key.
Part Register
The key part register is 128 bits wide, containing the value of a key part (component), or a complete key that is being installed via a key loading device such as a key pad or key board attached to the CF via an optional secured physical interface.
Working Key Register(s)
For performance reasons, the system has working register(s), 128 bit wide each, to contain immediate working key(s) for fast accesses. For example, a key that is used to encrypt data is brought into the CF in encrypted form on the first use. It then is decrypted and the clear value can be stored in one of the working key registers. In subsequent uses to encrypt or decrypt the data, this clear key can be quickly accessed from a specific working key register, thus eliminating the repeated steps of decrypting the key prior to using it.
Program MDC Register (PMDC Reg)
The program MDC register is 64 bits wide, containing the MDC of the program to be loaded in the program memory inside the CF.
Dataset MDC register (DMDC Reg)
The dataset MDC register is 64 bits wide, containing the MDC of the datasets whose integrity is validated by CFAP. This normally is, at least, the key storage datasets.
Cryptographic instructions and control vector checking algorithms.
The instruction set and control vector checking algorithms are implemented in the secured cryptographic facility and are stored in the cryptographic instruction storage 10 which is a random access memory. They are executed in a microprocessor such as an Intel 80286 which can serve as the cryptographic processing unit 16. The control vector checking unit 14 can also be implemented in the cryptographic processing unit 16 or it can be implemented by a second microprocessor such as an Intel 80286 serving as the control vector checking unit 14.
Program Memory and Processing Engine.
The system can also employ a memory inside the CF to store user's programs and a processing engine to execute the programs. An example of this is a program or macro for performing new algorithms for PIN verifications on new PIN formats.
Random Number Generator 26
The random number generator is an algorithmic procedure for producing 64 bit pseudorandom numbers. The algorithm itself is nonsecret, but makes use of two 128 bit secret keys and a 64 bit nonsecret incrementing counter. Although nonsecret, the integrity and proper management of the counter are essential to security.
The Crypto Facility (CF) is a secure implementation containing the Data Encryption Algorithm and storage for a small number of key and data parameters in the cryptographic instruction storage 10. It can be accessed only through involute interfaces (secure against intrusion, circumvention, and deception) which allow processing requests, key, and data parameters to be presented, and transformed output(s) to be received.
The ANSI Data Encryption Algorithm (DEA) is a standard cryptographic algorithm for commercial data security products. The DEA is a symmetric block cipher algorithm that uses a 56-bit secret key to encipher 64 bits of plaintext to form 64 bits of cipher text. DEA keys are normally stored with 1 parity bit per byte, forming a 64-bit key. DEA forms the basis for the National Bureau of Standards approved Federal Data Encryption Standard, so it is also called DES.
The cryptographic facility must resist probing by an insider adversary who has limited access to the cryptographic hardware. "Limited" is measured in minutes or hours as opposed to days and weeks, and the adversary is constrained to a probing attack at the location where the system is installed, using limited electronic devices as opposed to a laboratory attack launched at a site under the control of the adversary using sophisticated electronic and mechanical equipment.
The cryptographic facility must detect attempts at physical probing or intrusion. This may be accomplished using a variety of electro-mechanical sensing devices.
The cryptographic facility must provide for the automatic zeroization of all internally stored clear keys. Such zeroization must be performed automatically whenever an attempted probing or intrusion has been detected. The cryptographic facility must also provide a manual capability to zeroize key storage via the front panel interface.
The crypto facility contains one master key KM. All other keys can reside on mass storage encrypted under a key formed by Exclusive ORing the master key with a valid control vector. Refer to U.S. Pat. No. 4,386,234 entitled "Cryptographic Communications and File Security Using Germinals" by Ehrsam, et al., assigned to IBM Corporation, and incorporated herein by reference, for a description of an example Cryptographic Facility.
The CFAP is the programming interface between the CF and the application program. Since users do not have direct access to the cryptographic facility, the CFAP is the programming interface through which the users can request the CF to perform specific operations.
Associated with the CFAP is the Key Storage outside the CF where encrypted keys are stored. No clear keys are stored outside the CF. The Key Storage 22 is also referred to herein as the "Cryptographic Key Data Set" (CKDS).
The CFAP typically consists of the following:
Key Storage Manager to manage keys stored in the key storage mentioned above.
CFAP Macros through which users access to the CF to perform cryptographic functions.
Application programs include user's application programs, some utilities such as a key installation utility, and communication programs such as IBM VTAM.
User's application programs consist of statements that will invoke certain CFAP macros to perform a specific task. As mentioned, the CFAP is the only interface through which application programs can request CF to execute a cryptographic operation. For example, a user might want to encipher a file prior to shipping it to another node on the network. His application program might have one statement that calls a CFAP nacro to generate a key, and another statement that invokes another CFAP macro to encipher the data of the file with the given key.
Another example of a user's application program is one that allows the manual installation of keys on the system, similar to the installation program mentioned above.
FIG. 3 shows the use of control vectors for the key distribution between various applications in a multi-system communications environment. Note that for compatibility purposes some keys must be distributed without control vectors.
______________________________________
Notation The following notation is used herein:
______________________________________
ECB Electronic code book
CBC Cipher block chaining
KM 128 bit Master key
KEK 128 bit Key encrypting key
K 64 bit key
*K 128 bit key
(*)K 64 or 128 bit key
KD 64 bit data encrypting key
KK 64 bit Key encrypting key
*KK 128 bit Key encrypting key
KKo offset 64 bit Key encrypting key
*KKo offset 128 bit Key encrypting key
(*)KKo offset 64 or 128 bit Key encrypting key
*KKNI 128 bit partial notarizing Key encrypting
key
*KN 128 bit notarizing key, equivalent to
*KKNIo
cx 64 bit control vector
CxL 64 bit left control vector
CxR 64 bit right control vector
XOR or xor exclusive or operation
or logical or operation
X `0` Hex notation
11 concantentation operation
[x] optional parameter x
not = not equal
E or e single encryption
D or d single decryption
EDE or ede triple encryption
DED or ded triple decryption
Equations The function of each instruction is
mathematically denoted in the form:
I1, I2, I3, I4, . . . - 01, 02, 03, . . .
where I1, I2, I3, . . . are the inputs to the
function and 01, 02, 03, . . . are the outputs
from the function.
KM.Cx (KML XOR Cx) 11 (KMR XOR Cx) =
KMY 11 KMX
where, KML = Left 64 bits of the master
key KM,
KMR =
right 64 bits of the master key KM,
KMY =
KML XOR Cx
KMX = KMR XOR Cx
e*KM.Cx(key) e*KM.Cx(key) =
eKMY(dKMX(eKMY(key)))
where, KMY = KML XOR Cx
KMX= KMR XOR Cx
key = 64 bit key
e*KEKn.CX(key)
e*KEKn.Cx(key) =
eKEKY(dKEKX(eKEKY(key)))
where, KEKY = KEKnL XOR CxL
KEKX = KEKnR XOR CxR
key = 64 bit key
e*KM.CxL(KEKnL)
e*KM.CxL(KEKL) =
eKMY)dKMX(eKMY(KEKnL)))
where, KEKL = left 64 bits of KEK
KMY = KML XOR CxL
KMX = KMR XOR CxL
e*KM.CxR(KEKnR)
e*KM.CxR(KEKR) =
eKMY(dKMX(eKMY(KEKnR)))
where, KEKR = right 64 bits of KEK
KMY = KML XOR CxR
KMX = KMR XOR CxR
e*KEKo(key) e*KEKo(key) =
eKEKLo(dKEKRo(eKEKLo(key)
where, KEKLo = KEKL XOR cntr
KEKRo = KEKR XOR cntr
cntr = implicit 64-bit key-message
counter for KEK
key = 64 bit key
______________________________________
Cryptographic Separation of Keys
Keys are separated cryptographically by the invention according to key type and key usage attributes.
1. The architecture guarantees that cryptographic keys can be used only in the way or ways prescribed and intended.
2. Internal Versus On-The-Link Separation. Internally (i.e., within the cryptographic facility), keys are separated via control vectors or other appropriate/equivalent mechanism. On the link, keys are separated using control vectors.
3. Hardware Versus Software Enforcement. Certain cryptographic separation is implemented in hardware; other cryptographic separation can be implemented via software.
4. Control vector key types and compatibility-mode key types. In order that the compatibility-mode key types will not diminish the security, certain rules governing generation, distribution, and usage of these two classes of key types is imposed.
5. A list of required key separations provided by the invention is listed below:
(a) Data Privacy. ENCIPHER from DECIPHER, allows public key protocols such as mailbox, ballot and pass on.
(b) Data MAC. MACGEN from MACVER, allows for nonrepudiation (equivalent of electronic signature).
(c) Data XLATE. Allows a secure translate channel to be established, where intermediate devices cannot decrypt encrypted data.
(d) Data COMPAT. Allows compatibility mode without weakening security of other data keys.
(e) Data ANSI. Allows ANSI X9.l7 key management to be coexist with non-ANSI X9.l7 key management without loss of security to either approach.
(f) Key Encrypting Keys. KEK Sender from KEK Receiver.
(g) PIN Keys. PIN Generating Key from PIN Encrypting Key. The following notation is used for FIGS. 4 through 9:
Notation:
Near each line leaving a box is a separation letter and a priority number.
The separation letter will correspond with descriptions below:
The range of priority numbers (1 through 4) should be interpreted as follows:
1. Absolute necessity
2. Strongly recommended
3. Recommended
4. Desirable
Fundamental Key Separation
FIG. 4 illustrates the fundamental cryptographic key separation. An explanation of the separation is given below:
1. A. Data Keys : KEKs and PIN keys If KDs (Data Keys) are not separated from KEKs and PIN keys, then Decipher data function used with data keys could be misused to decipher KEKs and PINs.
2. B. Key Encrypting Keys : PIN keys If KEKs (Key Encrypting Keys) are not separated from PIN Keys it would be possible for an outsider to wiretap an encrypted PIN block and replay it in place of an encrypted KD. Ahead of time, an insider accomplice could replace the encrypted stored KEK with the encrypted stored PIN Key in the receiving node's cryptographic key data set. The PIN block would be then recovered and used as a data key at the receiving node. Subsequently, data that would be encrypted under this PIN block used as a data key would be much easier to subject to a key exhaustion attack as the variability of PINs (normally four to six decimal digits) is much less than that of a random 56 bit data key.
Data Keys Separation
FIG. 5 shows the flow chart of the Data keys separation. The justifications for the separation are given below.
1. A--Authentication : Privacy
An insider who can collect plain and corresponding ciphertext encrypted with a MAC key can perpetrate an attack against the MAC procedure. For example, it would be possible to construct fraudulent messages and MACs that would be authenticated and accepted by the MAC algorithm. Thus, the data keys used for encryption/decryption should not be used for authentication of data.
On the link, if an intercepted data key can be substituted for a MAC key, the transmitted ciphertext (under that data key) could be used to construct a fraudulent message and MAC.
B--Xlate Ciphertext: Privacy
By definition, Xlate Ciphertext implies the use of a pair of data keys KD1 and KD2, where ciphertext encrypted under KD1 is decrypted under KD1 and then reencrypted under KD2 without exposing the data to the calling application program. Otherwise, Xlate Ciphertext could be performed using the existing Decipher and Encipher functions.
C--ANSI: all others
ANSI keys have their own protocol for key distribution and an additional possible usage referred to as ANSI COMBINE KEYS. These differences mandate a separate pool for all ANSI keys.
D--Data COMPATIBILITY"All others
Data Compatibility keys exist due to requirements to be compatible with previous systems such as IBM CUSP/3848, IBM PCF, and IBM 4700. As the enforced internal separation in these systems does not extend to the level of separating MAC from Privacy keys, these keys need to be distinguished from the CV keys which support such an improved level of separation.
2. B--MACGEN:MACVER
Provides an audit trail to "prove" who originated a message and MAC (called nonrepudiation). This method is no more secure than the CF, and assumes a mutual trust in the integrity and secrecy of keys stored in the CF.
3. C--Encipher: Decipher
Provides true separation of the encipher and decipher functions, thus permitting data to be enciphered under a data key without exposing the right to decipher under that same data key. For example, an encipher only data key could be used in a `vote and pass on` balloting scheme. A decipher only data key could be used in an environment where a user is authorized to read but not write some data.
Pin Keys Separation
FIG. 6 shows the flow chart of the Pin keys separation. The justifications for the separation are given below:
1. A--PIN Generating Keys: PIN Encrypting Keys
An insider who could cause a PIN block to be forced equal to a valid ID value and then encrypted under a PIN generating key instead of a PIN encrypting key, could expose PINs.
2. B--Generate PIN function : Encipher PIN function During PIN generation, the Encipher PIN attribute allows separation of PIN Generating keys that allow clear PINs to be generated from those that always must output encrypted PINs.
3. C--Create PIN Block & Generate PIN : Reformat PIN, Verify PIN & Xlate PIN
Permits the PIN encrypting key to be used with routine PIN processing functions like Reformat PIN, Verify PIN and Xlate PIN without allowing PIN keys to be used or create or otherwise "introduce" PINs into the network at electronic speeds. This would prevent dictionaries of plain and encrypted PINs to be collected at electronic speeds, which would be useful in attacking and recovering PINs without directly deciphering them. Tight control needs to be enforced over where and when and under what conditions PINs may be introduced into the system.
4. D--Create PIN Block : Generate PIN
Greater control can be exercised over the introduction of PINs into the network. A node with a requirement to create PIN blocks need not necessarily have a right or need to generate PINs.
5. E--Reformat PIN and Verify PIN : Xlate PIN
Greater control can be exercised over the PIN processing functions in the network. A node with a need and right to translate PINs does not necessarily have a right or need to reformat a PIN or verify a PIN. The later two functions might be used in combination to exhaust PINs via an internal attack, whereas the Xlate PIN function could be used by some nodes without giving away full processing capabilities.
Key Encrypting Keys Separation
FIG. 7 shows the flow chart of the Key encrypting keys separation. The justifications for the separation are given below:
1. A--Notarization: non-Notarization
An insider might be able to cause a key intended for use with offset to be used without offset/notarization, such that the variant on the key is equal to an old offset counter value. Conversely, an insider might be able to cause a key intended for use only for non-offset/authorization to be used with an offset process, such that the offset on the key is equal to a variant not intended to be created or generated via a privileged mode in the crypto facility or by an entry in the authorized variant table.
2. B--CV KEKs: non-CV KEKs
Cryptographic operations in support of other non-CV network nodes, executed by a CV cryptographic facility, must not allow CV network node security to be weakened or diminished. For example, a CV system must support the import of both privacy and authentication (MAC) keys from a non-CV IBM 4700 or IBM 3848 system. In all cases, these data keys are received under variant 0 of the shared cross domain key. If the shared cross domain keys of these non-CV systems are not separated cryptographically from the CV system cross domain keys, then it would be possible to import a CV cyctem data key intended for one purpose (specified by variant 0 of the cross domain key) and translate it for another purpose (specified by some other variants).
3. C--KEK Sender: KEK Receiver
Maintain the same unidirectionality feature on cross domain keys as is present in the current IBM 3848/CUSP and IBM PCF. Also provides better control in preventing the unauthorized creation of bidirectional KEK's.
4. D--GENKEYSET/XLATE: RFMK/GENKEYSET/XLATE
Permit KEK's in support of the GENKEYSET and LXATE for shipment of data keys without necessarily allowing the export of existing data keys stored under the master key (or variant of master key). Thus, data keys used by the CV system are not exposed for export unless this feature is needed or desired.
5. E--GENKEYSET (Export only)/XLATE: GENKEYSET (general use)
Permits a node to act as a Key Distribution Center (KDC) or a Key Translation Center (KTC) without the ability to use the generated data keys within the generating node.
6. F--RTMK: RFMK on IBM 3848/CUSP (and compatible system)
Supports unidirectionality on IBM 3848/CUSP and other systems that are compatible with CV systems.
FIG. 8 shows a summary of the key separations and assigns a relative priority to them. Highest priority is `1` and lowest is `4`.
FIG. 9 summarizes the separation flows. The `leaves` on the tree indicate the cryptographic instructions that make use of the separate key types.
Control Vectors
Control Vectors Concept
The control vector is a 64 bit nonsecret cryptographic variable for controlling the usage of keys. Each key K defined to the cryptographic system has an associated control vector C, i.e., the key and control vector define a tuple (K, C).
Each control vector specifies a CV TYPE, which broadly defines how the key may be used and the rules governing how that key may be communicated on the link. A key may be a data key, sender key encrypting key, receiver key encrypting key, PIN encrypting key, PIN generating key, Intermediate ICV, Key part or Token. Additional bits in the control vector specify exactly in which cryptographic instructions and parameter inputs the key may operate. Still other bits control the export of the key, i.e., whether the key can be exported or not.
The control vector is coupled cryptographically to the key via a special encryption function. For example, when the K is stored in a Key Storage, K is encrypted under a key formed by Exclusive-ORing the control vector with the master key, i.e., K is stored as the tuple (eKM.C(K), C), where KM.C denotes KM xor C. When K is transmitted on the link (from one device to another), a similar encrypted form is used. In this case, the master key KM is replaced by a key encrypting key KEK, where KEK is a key shared between the sender and receiver. Thus, K is transmitted as the tuple ( eKEK.C(K), C). The architecture does not require that the control vector be stored or transmitted with the key in situations where its value is defined implicitly from the context or can be reconstructed from available key-related information.
Since the control vector (C) is tightly coupled to the key (K), via the encrypted form eKM.C(K) or eKEK.C(K), it is apparent that K cannot be recovered from its encrypted form unless C is correctly specified. Thus, if the tuple (EKM.C(K), C) is provided as an input to a requested cryptographic instruction, the cryptographic facility will first check the supplied value of C to determine that the requested usage of the key is permitted. Only then will C be used to decrypt eKM.C(K) to recover the clear value of K internal to the cryptographic facility. If a false value C* is specified, the cryptographic facility may be fooled temporarily into accepting C*, but K will not be recovered properly. Thus, there is no opportunity for a user to recover the correct value of K unless the correct value of C is also specified. The cryptographic principle is thus the basis upon which the entire architecture is built; and additional security is provided as necessary and where appropriate.
The control vector is a compact data structure for defining the usage attributes of a cryptographic key. The control vector is cryptographically coupled to the key via an encryption process. This process is such that the key can be decrypted properly only if the control vector is correctly specified. (Even a single bit change in the control vector will cause an entirely different key to be recovered.)
CV Checking
The control vector is designed to minimize CV checking. Control vector usage bits are defined and structured so that each usage attribute, by itself, grants or denies a specific usage. Thus, the capability to encipher data via the Encipher Data instruction is controlled via a single "Encipher" bit within the control vector whose type/subtype is "data/privacy".
Thus, each usage attribute is defined independently from all other usage attributes. This guarantees a CV checking process such that each instruction checks only the usage attributes called for by the requested function. A design wherein usage attributes are enabled only when certain other attributes are enabled or disabled is specifically avoided, since this increases CV checking. Some cross checking of attributes among two or more control vectors is required, but is kept to a minimum.
To facilitate and simplify CV checking, each cryptographic instruction, where necessary, is passed a "mode" parameter declaring a specified use of the key or keys passed as parameters to the instruction. Thus, the CV checking process tests each control vector according to the specified "mode". This eliminates costly cross checking among control vector attributes to ensure consistency.
The design also follows a principle that no cryptographic instruction generates a control vector. All control vectors are supplied to the cryptographic instructions as parameter inputs.
Where possible, like usage attributes and field definitions are located at the same bit positions in the control vector, regardless of CV type. This facilitates CV checking. For example, the translate ciphertext instruction interrogates the same bit positions in the data/privacy and the data/xlate control vectors, even though the usage bits are "E" and "D" for the data/privacy CV and "XOUT" and "XIN" for the data/xlate CV, respectively.
CV Structure
In general, the control vector structure (including formats, field and bit assignments) has been defined to minimize and to facilitate CV checking, while at the same time providing cryptographic security. The CV structure, so to speak, is the variable with the greatest degree of freedom in the design process.
The following design options have been employed in the control vector:
1. Vertical Separation. The control vector has a "CV Type" field that provides vertical separation within the control vector structure, much like the separation provided by variants. Control vector types are defined along intuitive lines, following existing key terminology and key management. However, vertical separation is implemented only where necessary under the CA, thus ensuring architectural simplicity and ease of comprehension of the CV checking rules.
By first defining broad classes of CV Main Types (e.g. Data Keys, Key Encrypting Keys, PIN Keys) and then further defining CV Subtypes and usage attributes within CV Type, the CV checking rules can be optimized much in the same way that a "divided and conquer" search can be employed more effectively than a brute force approach.
2. Horizontal Separation. The control vector is ideally suited as a data structure for recording the usage attributes to be associated with a key (or other cryptographic variable). Within the CA, this is accomplished by specifying a bit in the control vector for every cryptographic instruction (or key parameter within the instruction, if more than one key parameter may participate) where the key may be used as an input. A bit value of "1" signifies that a usage of the key is "enabled" by the CF whereas a bit value of "0" signifies that a usage of the key is "disabled" by the CF. This form of control vector structuring is called horizontal separation.
3. Encoded Fields. A field of two or more bits is sometimes encoded for reasons of security. An encoded field has the property that individual bits have no significance by themselves, but the bits together define a set of possible values. Encoded fields have the advantage that they define mutually exclusive events since the field can take on only one value at a time. Encoded fields have the potential disadvantage that CV checking is not always optimized from a performance standpoint. However, encoded fields are sometimes necessary to ensure that usage attributes cannot be mixed in inappropriate combinations that give rise to cryptographic attack or introduce some cryptographic weakness.
4. Protection From Non-System Generated Keys. The method for coupling the control vector and key is such that CV checking is unable to detect a system generated key (via KGEN or GKS) from a non-system generated key. For this reason, a "back-door" method exists within the architecture for generating a keys and control vectors. It consists of defining a control vector "of choice" and a random number which is then represented as a key encrypted in the manner described under the architecture using the selected control vector. (However, the method has no capability to control the key actually recovered within the cryptographic facility.)
The so-called "back-door" method of key generation is primarily an annoyance, although in some cases cryptographic attacks would be possible if additional measures of defense were not taken in the architecture. It would be a simple matter to define an architecture that eliminates this "back-door" key generation (once and for all), but doing so would introduce additional unwarranted complexity and processing. A more practical approach is followed by the CA, viz., the "back-door" key generation problem is prevented only where necessary for security reasons. Thus, a good balance among security, complexity, and performance is achieved. Techniques to avoid cryptographic weaknesses introduced by the "back-door" method of key generation are these:
(a) Where necessary, conflicting usage attributes within a single control vector are split among two control vectors. The GKS instruction has checking that prevents so-called bad combinations of key pairs from being generated.
(b) Where necessary, conflicting usage attributes within a single control vector are grouped into a single encoded field.
(c) As a last resort, extra redundancy is used so that the CF can validate its own system generated keys.
5. Even Parity for Control Vectors. Even parity is enforced on the control vector. This ensures that the Exclusive-OR of an odd parity key with the control vector will result in an internal key of odd parity. This, in turn, ensures compatibility with hardware that may check such internally derived keys for odd parity (if such checking is enforced). Saying it another way, the CA cannot ensure that hardware will not enforce this odd parity on internal keys.
A control vector of 64 bits, numbered 0 through 63. The most significant bit is bit 0, by convention. Of the 64 bits, there are 8 parity bits.
6. Anti-Variant Bits. This guarantees cryptographic separation between variants and control vectors, which may unavoidably be mixed in some implementations internal to a node.
7. Avoid Onto Mappings. The control vector design and the manipulation of the control vector via the cryptographic instruction set avoids instances where CV fields with multiple values are mapped into a single value. Some specific instances of such onto mappings are allowed (e.g., LCVA, RFMK, and RTMK instructions) where security is not jeopardized.
CFAP Control
Certain bits in the control vector are reserved for CFAP. These bits can be used by CFAP for further key management control. These bits are not checked by the CF, but are entirely managed by CFAP.
General Format for Control Vectors
FIG. 10 shows the general format for control vectors. The first row of FIG. 10 shows the fields that are in common for most of the control vectors. They are briefly described as follows: (Further details can be found in subsequent subsections.)
CV Type
This field indicates the type of control vector, and is also the key type of the key to which this control vector is attached. The CV Type field consists of main-type and sub-type.
The main types of a control vector are:
Data key
Data keys are used to encrypt/decrypt data, or to authenticate data.
PIN key
PIN keys are used to encrypt PINs or to generate PINs.
Key-encrypting key
Key-encrypting keys are used to encrypt keys.
Key part
A key part is a part or a component of a key, having the same length as the key. For example, a key K may have two key parts Ka and Kb such that Ka XOR Kb=K.
Intermediate ICV
An Intermediate ICV is used during MAC processing to encrypt the intermediate Output Chaining Value of a segment of data or message. This OCV is then fed into the next segment of the data and used as an ICV. This occurs when a message or data on which a MAC to be generated or verified is long and must be divided into shorter segments.
Token
Tokens are variables used to protect the integrity of the data keys stored in the Data Key Dataset (a key storage for Data keys). They help prevent the access of data keys by unauthorized users.
The sub type differentiates the classes of keys of the same main type. For example, a key of main type data key can have the sub type of privacy (capable of doing encryption and decryption); or MAC (capable of doing data authentication); or XLATE Data (capable of translating ciphertext); etc. When no sub-type distinction is made, the keys are normally referred by the main type (e.g., Data key, PIN key, etc.)
Export Control
This field indicates how the export of the key associated to this control vector is controlled, and whether the key is allowed to be exported.
CF Enforced Usage
This field indicates for what CA functions the key can be used, and how it is used. For example, a data privacy key may have the usage attributes E=1 and D=1, which indicate that the key can be used in the Encipher and Decipher function to encrypt and decrypt the data, respectively.
AV (Anti-Variant)
This field differentiates any valid control vector from the 64 predefined variants that are used in variant-based crypto systems. Since all 8 bytes of the any variant of the 64 predefined variants are the same, setting the value of the AV field such that at least two bytes of the control vector are not the same will differentiate a valid control vector from a predefined variant.
Software Bits
This field represents control vector bits that are controlled/managed entirely by CFAP; The software field is not checked/enforced by the hardware (CF). When no control vector exists, CFAP builds a control vector from information supplied to CFAP (normally via parameter in a macro). When a control vector already exists, CFAP will check the control vector (including the software field) to determine whether the key is allowed to operate in the manner specified/requested. The hardware (CF), unlike software (CFAP), checks only those bits associated with a CA instruction, other usage bits are not checked).
Extension
This field indicates whether the control vector is a 64 bit control vector or an extended control vector of 128 bits. In the current CA, all the control vectors have 64 bits in length. This field is defined now to ease the expanding of the control vector in the future when the number of bits required to specify the control vector exceeds the 4 bit length.
Reserved Bits
This field is reserved for the system for future use.
Parity Vector
Every parity bit is the even parity of the preceding 7 bits of the byte.
For key-encrypting key control vectors, besides the common fields listed above, there are two additional fields, KEY FORM and LINK CONTROL.
Key Form
This field indicates the length of the key (single or double length) and whether the key half associated with the control vector key is the right or left half of the key. Note that for a single length key, the right half is the same as the left half and is the key itself.
Link Control
This field indicates how the key-encrypting key associated to this control vector is used to transmit other keys on the link, and what type of system (e.g., CV system or non-CV system) can keys be shipped to or received from , under this key-encrypting key.
Note that the descriptions in the second row and the third row in the general figure and other referenced figures in this section are not part of the control vector. They are put there to give information on the fields of the control vector as follows:
The second row indicates the bit length of the fields. The abbreviation `b` stands for `bit`. For example, 1b stands for 1 bit, 3b stands for 3 bits, etc.
The third row indicates whether the field is checked by hardware (CF) or software (CFAP).
Control Vector Format for Data Key
Data keys are divided into the following subtypes:
Data Compatibility Key. This is the data key that would be used to maintain compatibility with existing systems such as IBM 3848/CUSP or IBM 4700 FCS. Since these existing systems do not have the cryptographic separation between privacy and authentication, this key can be used to perform any or all of the following functions: encipher, decipher, generate MACs and verify MACs. This control vector can be removed (i.e., substituted by CV=0 on-the-link) when it is exported to other systems (via the RFMK instruction), whereas the control vectors for all other data keys except ANSI data keys cannot be removed.
Privacy Key. This is the key used for enciphering and/or deciphering only.
MAC Key. This is the key used for the purpose of data authentication only. That is, it can only be used to generate MACs and/or verify MACs.
Data Translation Key (Data XLT Key). This is the key used in the translation of ciphertext.
ANSI Key. This is the key that is used in ANSI applications. It can be used to encipher and decipher data or to generate and verify MACs. It can also be combined with another ANSI key to form an ANSI MAC key (i.e., a Data ANSI key with generate MAC/verify MAC capability). This control vector can be removed when exported to other systems (i.e., substituted by CV=0 on-the-link) via the ARFMK instruction, whereas the control vectors for all other data keys except compatibility keys cannot be removed.
Depending on the CV subtype of the control vector, the bits in the USAGE field have specific meaning to be described shortly.
Control Vector for Privacy Keys
Refer to FIG. 11. The following is a detailed description of each field and subfield of this figure.
CV Type
CV Type for privacy key (main type="DATA KEY", subtype="PRIVACY".
Export Control (controls exporting of this key):
This field occupies 1 bit:
EXPORT CONTROL=1: This key can be exported by RFMK.
Also, the RFMK, RTMK and LCVA instruction can reset this bit to 0.
EXPORT CONTROL--0: This key cannot be exported by RFMK.
Also, it cannot be changed to 1 by any instruction. As an example, suppose node X generates a key K and control vector C and sends them to node Y.
Usage
(a) E
E=1: This key can be used in the ENCIPHER instruction to encrypt the data.
E=0: This key cannot be used in the ENCIPHER instruction to encrypt the data.
(b) D
D=1: this key can be used in the DECIPHER instruction to decrypt the data.
D=0: This key cannot be used in the DECIPHER instruction to decrypt the data.
AV (Anti-Variant)
This field occupies two bits, used to differentiate the control vector from 64 predefined variants that are used in variant-based crypto systems. Since all 8 bytes of the any variant of the 64 predefined variants are the same, setting the value of the AV field such that at least two bytes of the control vector are not the same will differentiate a valid control vector from a predefined variant.
Software bits
This field occupies 12 bits.
(a) CV Version
This field is 6 bits long and is used by CFAP to distinguish the current control vector definition from future definitions.
(b) Software=Enforced Usage
See also the CFAP section.
CVDPIM (Control Vector Data Privacy Icv Mandatory)
CVDPCU (Control Vector Data Privacy CUsp)
CVDP47 (Control Vector Data Privacy 4700)
CVDPM8 (Control Vector Data Privacy Multiple of 8)
Extension
This field indicates whether the control vector is a 64 bit control vector or an extended control vector of more than 64 bits.
Reserved bits
This field is reserved for the system for future use.
Parity
This field consists of the last bit of every byte of the control vector. The parity bit of each byte is set to achieve even parity for the byte.
Control Vector for MAC keys
Refer to FIG. 13. The following is a detailed description of each field and subfield of this figure.
CV Type:
CV TYPE for MAC key (main type=:DATA KEY, sub type="MAC").
Export Control (controls exporting of this key):
Same description as that of Privacy keys.
Usage
(a) MG
MG=1: This key is permitted to be used in the GMAC instruction to generate MACs on data.
MG=0: This key is not permitted to be used in the GMAC instruction to generate MACs on data.
(b) MV
MV=1: This key is permitted to be used in the VMAC instruction to verify MACs on data.
MV=0: This key is not permitted to be used in the VMAC instruction to verify MACs on data.
AV (Anti-Variant)
Same description as that of Privacy keys.
Software bits
This field occupies 12 bits.
(a) CV Verson--Same description
(b) Software-Enforced Usage
See also the CFAP section
CVDML4 (Control Vector Data MACLEN=4)
CVDM99 (Control Vector Data MAC MODE=ANSI X 9.9)
CVDMl9 (Control Vector Data MAC MODE=ANSI X 9.19)
CVDM00 (Control Vector Data MAC MODE=IBM 4700)
CVDM30 (Control Vector Data MAC MODE=IBM 4730)
Extension
Same description as that of Privacy keys.
Reserved bits
Same description as that of Privacy keys.
Parity bits
Same description as that of Privacy Keys.
Control Vector for Data Compatibility Keys
Refer to FIG. 14. The following is a detailed description of each field and subfield of this figure.
CV Type CV TYPE=for data compatibility key (main type="DATA KEY", sub type="COMPATIBILITY"
Export Control
Same description as that of Privacy keys.
Usage
(a) E
E=1: This key can be used in the ENCIPHER instruction to encrypt the data.
E=0: This key cannot be used in the ENCIPHER instruction to encrypt the data.
(b) D
D=1: This key can be used in the DECIPHER instruction to decrypt the data.
D=0: This key cannot be used in the DECIPHER instruction to decrypt the data.
(c) MG
MG=1: This key can be used in the GMAC instruction to generate MACs on data.
MG=0: This key cannot be used in the GMAC instruction to generate MACs on data.
(d) MV
MV |
