Secure translation of usage-control values for cryptographic keys5177791Abstract A working key of a certain key type is to be transmitted from a first system (having a first usage-control value associated with keys of the certain type) and a second system (having a second usage-control value associated with keys of the certain type). A translation control value, associated with the certain key type, is generated, functionally relating the first and second usage-control values. The translation control value is used in a cryptographic function to send or receive the working key between systems, the cryptographic function being designed to produce valid results when the correct translation control value, and usage-control values, are employed, and unpredictable results otherwise. Effectively, the first usage-control value is translated to the second usage-control value. Claims What is claimed is: Description BACKGROUND OF THE INVENTION
______________________________________
Notation Description
______________________________________
V a usage-control value which may not be a
valid control vector supported by this
system.
CVi the ith control vector.
im the control vector for an importer.
ex the control vector for an exporter.
t1 the control vector for an unspecified
key type, T1.
t2 the control vector for an unspecified
key type, T2.
+ Exclusive OR.
K a cryptographic key.
K.CVi K + CVi.
MK Master key.
eK(x) Encipherment of x using key K.
dK(x) Decipherment of x using key K.
eKEK.CVi(K)
Encipherment of K using KEK.CVi.
dKEK.CVi(K)
Decipherment of K using KEK.CVi.
______________________________________
FIG. 1 shows, in block diagram form, an overview of the operation of the present invention. System A (101) uses shared key-encrypting-key KEKl (110A) and KEK2 (110B) for transmitting working keys to and receiving from System B (102). Usage-control value A (106A) is used to enforce key separation at System A for working keys of type T; usage-control value B (107B) is used for key type T at System B. When System A desires to transmit working key 1 (104) (a key of type T) to System B, it uses a translate out process (103) to secure working key 1 for transmission. Translate out process 103 takes as input working key 1 (104), usage-control value A (106A), usage-control value B (107A), and shared KEKl (110A). Process 103 interacts with cryptographic engine 105, creates two dummy keys P (108) and Q (109), and sends the necessary data securely to system B. When system A desires to receive a key of type T from system B, system A uses a translate in process (111) to receive working key 1 (115) in a form it can deal with. Process 111 takes as input usage-control value B (107B), usage-control A (106A), and shared key-encrypting-key KEK2 (110B). It interacts with cryptographic engine 105, creates two dummy keys X (112) and Y (113), and produces working key 1 in usable form (114). FIG. 2 illustrates control flow for the translate-out process. The process is used to export a key and also change the key type from the one specified by CV.sub.i to the one specified by V. Steps 201 to 205 create two dummy keys, and establish the operating environment. At 201, a shared KEK is installed as an exporter at the sending system. This means that the KEK is encrypted as eMK.ex(KEK). At 202, a random number is generated (the method of generation is not important for understanding of this invention, and can be any of numerous techniques known in the art) to form a dummy key, P. Next, 203, the second dummy key Q is generated as Q=P+V+CV.sub.i where "+" indicates an Exclusive OR operation. At 204, P is encrypted as a key of type T2 using the EIK function (known to the prior art). This function can only be executed in a special mode for security (see U.S. patent application, Ser. No. 07/672,265, by R. M. Smith Sr., et al., filed 3/20/91, assigned to the assignee of the present invention and incorporated herein by reference). This mode can be enabled or disabled by means of a manual key switch. (FIG. 8 illustrates the EIK function in detail.) As a result of this instruction, P is encrypted as: eMK.t2(P). At 205, Q is encrypted as an exporter using the EIK function. That is, Q is encrypted as: eMK.ex(Q). Dummy keys can only be installed in the special-security mode. High security is obtained by disabling the mode during normal operation so that no program can create dummy keys for unintended translations. Once the dummy keys are installed by means of the EIK function, they are stored in program accessible storage and protected by the operating system. Instead of using the encipher under importer key function, installation of dummy keys could also be performed by means of manual key entry, which is described in the aforementioned patent application, Ser. No. 07,672,265, entitled "Method and Apparatus for Validating Entry of Cryptographic Keys". Having created the two dummy keys, and established the operating environment, a working key in the form of eMK.eV.sub.i (K) can be exported securely by steps 206-208. At 206, RFMK is executed using as input i, eMK.ex(Q), and eMK.CV.sub.i (K). RFMK is known in the prior art, and is explained in greater detail in FIG. 7. The result of executing this operation is eQ.CV.sub.i (K). However, since Q=P+V+CV.sub.i, therefore Q.CV.sub.i =Q+CV.sub.i =P+V =P.V. Thus, the result can be written equivalently as eP.V(K). Next, 207, the result of 206 is input to an RTEK operation (with V, eMK.t2(P), and eMK.ex(KEK)). The RTEK operation is explained in greater detail in FIG. 5. The result of this RTEK is eKEK.V(K), which is the value exported to the other system 208. FIG. 3 illustrates control flow for the translate-in process. The process is used to import a key, and also change the key type from the one specified by V to the one specified by CV.sub.i. Steps 301 to 305 create two dummy keys, and establish the operating environment. At 301, the shared KEK is installed as an importer at the receiving system. This means that the KEK is encrypted as eMK.im(KEK). At 302, a random number is generated (again, means of generation not important for the invention) to form a dummy key, X. Next, 303, the second dummy key Y is generated as: Y=X+V+CV.sub.i (again, "+" means "Exclusive OR). At 304, X is encrypted as an importer key using the EIK function (in the special mode). (FIG. 8 shows detail for the EIK function.) As a result of this instruction, X is encrypted as: eMK.im(X). At 305, Y is encrypted as a key of type Tl using EIK. That is, Y is encrypted as: eMK.t1(Y). Dummy keys can only be installed in the special-security mode. High security is obtained by disabling the mode during normal operation so that no program can create dummy keys for unintended translations. Once the dummy keys are installed by means of the EIK function, they are stored in program accessible storage and protected by the operating system. Having created the two dummy keys, a working key in the form eKEK.V(K) key can be imported securely as shown in steps 306-307: at 306, RFIK is executed using as input V,eMK.im(KEK), eMK.t1(Y), and eKEK.V(K). RFIK is shown in greater detail in FIG. 4. The result of executing this operation is eY.V(K). However, since Y =X+V+CV.sub.i, therefore Y.V =Y+V=X+CV.sub.i. Thus the result can be written equivalently as eX.CV.sub.i (K). Next, 307, the result of 306 is input to an RTMK operation (along with i and eMK.im(X)). The RTMK operation (known in the prior art) is explained in greater detail in FIG. 6. The result of this RTMK operation is eMK.CV.sub.i (K), which is the working key in usable form on the receiving system. In the preferred embodiment of the present invention, key type t.sub.1 is an exporter and key type t.sub.2 is an importer. Thus, RFIK and RTEK become identical to a translate-key function. Note that the translation of the usage-control value of the working key from CVi to V (or from V to CVi) is controlled by the two coupled dummy keys Q and P (or X and Y), which are in the encrypted form. Although the dummy key P (or X) is simply a random number, the dummy key Q (or Y) must have a specific relationship with P (or X) in order to successfully perform the intended translation. If a malicious program replaces one of the coupled dummy keys with a unrelated dummy key or an arbitrary number, or replaces both coupled dummy keys with unrelated dummy keys or arbitrary numbers, in an attempt to create an undesirable translation, the process will produce an unpredictable result because of the novel mechanism of coupling the dummy keys. The space of possible results is so large that the chance of producing a meaningful result is comparable to the chance of arbitrarily guessing a DES key. This novel mechanism of controlling translation allows high security to be achieved without the complex checking on control vectors and masking vectors required in the prior art (see, e.g., the aforementioned U.S. Pat. No. 4,993,069). Also, this coupling of the dummy keys eliminates the need to store them in two different forms, as required in that prior art, so that further reduction in implementation complexity is achieved. Furthermore, the two coupled dummy keys are encrypted as exporter and importer keys; that is key type tl is an exporter and key type t2 is an importer. There is no new key type required. The prior art requires two new key types and, thus, requires additional complexity in key management. Additionally, the process of generating dummy keys in this invention is much simpler than the process of generating masking vectors in the prior art, and can be efficiently automated. This is because the usage-control value is treated as a constant, which can be referred to by a name, in this invention while, in the prior art, the usage-control value is bit-significant and each bit must be explicitly named and separately specified by the user. It should be noted that while the control flow depicted in FIG. 2 (or FIG. 3)is sequential, it is not necessary that all operations be performed in the described order or that all instances of a translate out (or translate in) operation require all the described steps. Steps 202 to 205 (or 302 to 305) may be executed only once at system initialization. Step 201 or (301) will be executed only as often as a new key-encrypting-key is installed. Steps 206 and 207 (or 306 and 307) are executed each time a key is translated. Step 208, the transmission of the key to another system, may consist of an actual transfer across communication lines, may be accomplished by means of a shared direct access device, or in some cases, the translated key may be used by the current system. Similarly, the key used as the input to translate in may have been created by another system and transmitted to this one, or the key may have originated at this system. It should also be noted that an alternative embodiment for the installation of the dummy keys is to manually install these values by means of a manual key input device. It will be obvious to one skilled in the state of the art that the RFMK and RTMK functions shown in FIG. 2 can be combined into a single function. Similarly, the RFIK and RTMK functions shown in figure 3 can be combined into a single function. Furthermore, the information supplied to such a function can be in a form other than a pair of dummy keys. For example, the information could be an encrypted form of the two usage-control values. Thus, in such an implementation, the installation of dummy keys becomes the installation of this information, sometimes called a translation control value. In most systems, translation is required for several types of keys. Each such translation requires a translation control value consisting of a pair of dummy keys. The translation control values would normally be generated by a software utility invoked during system initialization. This setup utility would generate a pair of values for each desired mapping. The information would be placed in a table which could have the following form:
______________________________________
id1 (DKa1, DKb2)
id2 (DKa2, DKb2)
. . .
idn (DKan, DKbn)
______________________________________
Where id1, id2, etc. are indexes to the table and are used to select the correct entry to be used for a specific translation. DKal and DKbl, DKa2 and DKb2, etc., are the encrypted dummy key pairs. The pair DKla, DKlb would allow translation from Usage-Control Value-1 to Usage-Control Value -2, and so forth. A Usage-Control Value can be a Control Vector, Variant, or other mask value. Note that if each entry is based on a different the others. If the same random number is used for some subset, then this forms classes of allowed translations. This table would be access controlled to ensure only the translation service would use it for its intended purpose. An alternate embodiment could be employed in a large computing system that has a very reliable software access control mechanism. In this case, the setup utility would create all possible mapping pairs in advance and store them in a table. The access control mechanism is then the gate as to whether someone is allowed to map a UCV from one value to another. This alternate embodiment allows initialization to proceed transparently to the user, as no choices need be made at initialization time. FIG. 4 shows, in block diagram form, the logic for the RFIK (Reencipher From Import Key) operation. The function reenciphers a working key, K, from encrypted under a derivative of an importer, that is, KEK.CV.sub.1, to become encrypted under the same derivative of another key-encrypting key, that is KI.CV.sub.i. (The "e" blocks represent logical encipherment functions under the conventional DES algorithms; the "d" blocks represent logical decipherment; the "+" blocks represent Exclusive-OR operations; MKL represents the left-half of the master key; MKR represents the right half of the master key; im1 represents a control vector for the left half of an importer key; imr represents the control vector for the right half of an importer key; t11 represents a control vector for the left half of a key with type t1; t1r represents a control vector for the right half of a key with type t1; KEK is a key-encrypting key, with KEKL and KEKR being the left and right halves, respectively. KI is a key-encrypting key, with KIL and KIR being the left and right halves, respectively. This notation will be used in subsequent figures also.) FIG. 4 shows that there are six basic inputs to the RFIK instruction (CV.sub.i (401); eMK.im1 (KEKL) (402); eMK.imr(KEKR) (403); eMK.t11(KIL) (404); eMK.t1r(KIR) (405); and eMKK.CV.sub.i (K) (406). And the output is eKI.CV.sub.i (K) (419). Six major functional blocks are shown (413, 414, 415, 416, 417, 418). The first five of which result in "clear" key internal, transitional values (420, 421, 422, 423, 424), each used in subsequent functional blocks, and the last one of which produces the instruction's final product (419). FIG. 5 shows, in block diagram form, the logic for the RTEK (Reencipher to Exporter Key) operation. The function reenciphers a working key, K, from encrypted under a derivative of a key-encrypting key. That is, KO.CV.sub.i, to become encrypted under the same derivative of an exporter key. That is, KEK.CV.sub.i. (t21 represents a control vector for the left half of a key with type t2; t2r represents a control vector for the right half of a key with type t2. ex1 represents a control vector for the left half of an exporter key; exr represents a control vector for the right half of an exporter key. KO is a key-encrypting key, with KOL and KOR being the left and right halves, respectively.) There are six inputs for RTEK: CV.sub.i (501); eMK.ex1 (KEKL) (502); eMK.exr (KEKR) (503); eMK.t21 (KOL) (504); eMK.t2r (KOR) (505); eKO.CV.sub.i (K) (506). There is one final result: eKEK.CV.sub.i (K) (507). There are six major functional blocks (508, 509, 510, 511, 512, 513), the first five producing clear key internal results used in subsequent blocks (514, 515, 516, 517, 518), and the last one producing the instructions ultimate result (507). FIG. 6 shows, in block diagram form, the logic for the RTMK (Reencipher to Master Key) operation--known in the prior art. The function reenciphers a working key, K, from encrypted under a derivative of an importer key. That is, KEK.CV.sub.i, to become encrypted under the same derivative of the master key, that is MK.CV.sub.i. There are four inputs for RTMK; i (601) (the index into the Control Vector Table 605 which is used to select CV.sub.i (606)); eMK.im1 (KEKL) (602); eKEK.CV.sub.i (K) (603); eMK.imr (KEKR) (604). There is one final result: eMK.CV.sub.i (K) (611) There are four major functional blocks (607, 608, 609, 610), the first three of which produce clear key internal results used in subsequent blocks (612, 613, 614), and the last of which produces the instruction's ultimate result (611). FIG. 7 show, in block diagram form, the logic for the RFMK (Reencipher from Master Key) operation--known in the prior art. The function reenciphers a working key, K, from encrypted under a derivative of the master key, that is MK.CV.sub.i, to become encrypted under the same derivative of an exporter key, that is KEK.CV.sub.i. There are four inputs for RFMK: i (701) (the index into the Control Vector Table 705 which is used to select CV.sub.i (706)); eMK.ex1 (KEKL) (702); eMK.CV.sub.i (K) (703); eMK.exr (KEKR) (704). There are four major functional blocks (707, 708, 709, 710), the first three of which produce clear key internal results used in subsequent blocks (712, 713, 714), and the last of which produces the instruction's ultimate result (711). FIG. 8 shows, in block diagram form, the logic for the EIK (Encipher under Importer Key) operation--known in the prior art. The function encrypts a working key, K, under the specified derivative of a importer key, that is KEK.CV.sub.i. There are four inputs for EIK: i (801) (the index into the Control Vector Table 805 which is used to select CV.sub.i (806)); eMK.im1 (KEKL) (802); eMK.imr (KEKR) (803); K (804). There are three major functional blocks (807, 808, 809), the first two of which product clear key internal results used in subsequent blocks (811, 812), and the last of which produces the instruction's ultimate result (810). An alternative method to transmit keys between systems using different usage-control values, without the use of this invention, is to install a special shared KEK between the two systems, where the value of the KEK installed in one of the systems is adjusted to compensate for the difference between the usage-control values used in the two systems. The invention described herein has the following advantages over that alternative method: 1. One pair of dummy KEKs can be used for any number of different shared KEKs, whereas with the alternative, each KEK used for exchange must be installed in the special way. 2. With this invention, shared KEKs can be installed in the normal fashion. With the alternative, special procedures are required for the installation of shared KEKs. 3. With the alternative, a separate shared KEK must be installed for each type of key to be exchanged. With this invention, a single shared KEK can be used for exchanging multiple key types. 4. With the alternative, the number of shared keys and their handling differs between types of systems. These differences are difficult to handle. With this invention, the translation function can be easily done as an independent step with no effect on the other portions of the operation.
|
Same subclass Same class Consider this |
||||||||||