In the late 1970s, after the Data Encryption Standard stimulated interest in commercial applications of cryptography, IBM disclosed in a series of papers by its technical personnel an architecture for a cryptographic facility that could use DES, and could be incorporated into systems such as their 3278 terminals and their System/370 mainframes.
Encryption was to be performed via special-purpose hardware, attached to terminals and hosts.
The functions provided by the terminal cryptographic facility were simple enough, and besides being easy to understand, will make apparent the general thrust of this system.
An authorized person can set up a terminal with a "terminal master key". This is called the WMK (Write Master Key) operation.
Regular users will, in normal operation, be supplied with session keys by the host system which will be encrypted with their terminal's master key. Loading such a key into the terminal cryptographic facility means that it will decrypt that key, using the terminal master key, and will then store the result as the current working key. This operation is called DECK (Decipher Key).
No operation will be provided to perform encryption or decryption using the terminal master key where the result is disclosed, or to reveal either the terminal master key or the current working key. (Previous working keys will not be retained in the device.) However, one additional operation can be allowed without compromising security: LKD (Load Key Direct) allows one to load in an unencrypted working key, so that the cryptographic system can also be used for DES encryption outside the regular framework of this secure system.
Once a working key is loaded into the facility, it can be used to encipher and decipher via the ENC (Encipher) and DEC (Decipher) operations.
One can use an LKD operation, or even a DECK operation, to load the device with an invalid key to clear the key after one is finished.
The cryptographic facility at the host is, like that at the terminal, assumed to have only limited storage for keys. However, it has to communicate with a number of terminals which is not to be strictly limited. Also, the host is assumed to be a time-shared computer system. Therefore, the cryptographic facility only retains master keys within itself, and must be supplied, each time it is used for decryption or encryption, with any session or terminal key (which may itself be encrypted) to be used for that operation. (It is noted, however, that an encrypt or decrypt operation may be extended to encrypt or decrypt multiple blocks for one decryption of the key.)
Like the terminal facility, there is an operation which can only be performed by authorized personnel, SMK (Set Master Key) which initializes the device by loading it with its master key. Later, we will see that there are some operations which need, for security, to be done with master keys differing from each other. However, the descriptions of this design note that it is possible, without destroying security, to use variants, obtained by a known method, of the secret master key for those purposes - even as trivial as the master key XOR 0101010101... in one case, and the master key XOR 110011001100... in another.
(Incidentally, we are no longer so sure that this is safe, because related-key attacks have been developed for many block ciphers.)
The normal data encrypting and decrypting operations are ECPH (Encipher Data) and DCPH (Decipher Data). These use the master key to decrypt a submitted session key in external form, and then use that key to either encrypt or decrypt, respectively, one's data.
Also available is EMK (Encipher Under Master Key), which enciphers data under the host master key. This instruction is used to prepare keys for later use with the ECPH and DCPH instructions.
With the instructions we have seen so far, it is clear how secure communications could be set up with multiple terminals. Initially, at some time when the computer is secured from other uses, the terminal master keys of all the terminals are randomly generated. These keys are then entered into the terminals, using their WMK instructions. Meanwhile, the host system applies the EMK instruction to all the terminal master keys, retaining only the encrypted versions.
Later, when communications are to be set up with a terminal, one can proceed as follows:
The host system will generate randomly a session key. Using the encrypted version of the terminal's master key in storage, the host system can, using an ECPH instruction, encipher the session key under the terminal's master key. This encrypted session key will be sent to the terminal. The terminal can then use a DECK operation to load in the encrypted session key. Meanwhile, the host computer must also apply an EMK instruction to the randomly-generated session key to produce a copy of the session key encrypted with the host master key. Now, when the terminal executes ENC and DEC instructions with the key it has loaded in, and the host executes ECPH and DCPH instructions with the encrypted session key, both will be performing DES encryption and decryption with the original session key, and thus the terminal and host can communicate.
This does, however, require that the session key be created, and temporarily be stored, on the host system in clear form. Initially, the terminal master keys were on the host system in clear form, which is even worse, but this need only be done once, when no other users are allowed on the system. Additional instructions are present in the host facility to allow this danger to be avoided.
Also, the session key is sent to the terminal enciphered under the terminal master key. This can't be changed, but in the present set-up, it's unacceptably dangerous, because the clear session keys are enciphered under that key using an ECPH instruction. Having the terminal keys on the host system, enciphered under its master key, means that someone could intercept the session key in transmission, find the encrypted terminal master key in storage, and use it to decrypt the session key.
So we wish to keep the terminal master keys on the host system in a safer form, that can only be used to encrypt session keys, not decrypt them. And we want to avoid having to have session keys existing in the clear outside the cryptographic facilities at both ends.
This is achieved by adding an operation called RFMK (Re-encipher From Master Key) to the system. Given a copy of the terminal master key - enciphered, not under the regular host master key, but under an auxilliary key, which could even be a variant of the host master key, as mentioned above - and a copy of the session key, encrypted under the regular host master key, it produces a copy of the session key encrypted under the terminal master key. The regular host master key is called KM0, and the auxilliary key used here is called KM1. The action of RFMK is: given two keys as inputs, it deciphers the first under KM1, and it deciphers the second under KM0. Then, it uses the deciphered first key to encipher the deciphered second key to produce the result.
Initially, to create the copies of the terminal master key enciphered under the auxilliary key, one can use a copy of KM1 enciphered with itself as the first input to an RFMK instruction; as the second input, a copy of the terminal master key, encrypted under KM0 as produced by the EMK instruction is used. The copy of KM1 enciphered under itself is not left available afterwards, so as to avoid giving users the ability to encrypt arbitrary values under KM1 - with this ability, they could take any quantity enciphered under the host master key, and translate it to be enciphered under any key of their choosing, essentially inverting the EMK instruction, and therefore being able to read any session keys stored for use on the host system.
The other problem, of generating session keys in the clear, is avoided simply: since we can now start from a session key enciphered under the host master key, and proceed directly from it to a session key enciphered under a terminal master key, instead of using the EMK instruction, when we generate a key as a 64-bit random number, we consider that to be the session key after encryption under the host master key. (Note that this means that, when we decipher encrypted keys for use with DES, we have to ignore the parity bits that are usually used to validate DES keys.)
If instead we were to consider it to be the session key after encryption under the terminal master key, we could instead use an instruction that deciphers under a terminal master key and subsequently enciphers under the host master key. Such an instruction might seem less dangerous, since it doesn't threaten to invert the EMK instruction.
Such an instruction will be examined shortly, for use in maintaining encrypted files. Since the RFMK instruction is already present, and having an inverse of it available would be dangerous, a second auxilliary key, KM2, is used with this new instruction. But using such an instruction for communications security would allow people to take an intercepted session key (enciphered under the terminal master key, from a transmission) and make it more useful, by converting it to a form enciphered under the host master key, with which the DCPH instruction allows them to decode the transmission.
However, when we examine this objection, we also note that the session key encrypted with the host master key is retained in the host computer's memory in the former case as well. If we assume that the operating system on the host computer is not secure, then plaintext going in to or coming out of the host cryptographic facility can always be intercepted. Some additional assumptions, regarding how some areas of computer memory are more secure than others, or that long-term security cannot be guaranteed, but short-term security is assumed, are required to provide genuine effectiveness. Possibly the RFMK instruction should be replaced by a variant of the ECPH and DCPH instructions that takes as input, besides the data to be encrypted or decrypted, the terminal key encrypted under KM1 and the session key encrypted under the terminal key, so that the session key encrypted under KM0 need never be visible.
The instruction RTMK (Re-encipher to Master Key) takes as its two inputs a key (generally, a secondary file key) enciphered under KM2, and another key (generally, a file key) enciphered under the secondary file key (in its original, unencrypted form), and produces the file key enciphered under KM0 (in which form, it is available for use with the ECPH and DCPH instructions).
This allows the enciphered file key to be stored with the file. The secondary file key unlocks the file, so it appears that this key must be kept secret. Instead, since it does need to be kept in the computer's memory for later use, the RTMK instruction is made a privileged instruction. While the SMK instruction may require a physical key to enable it, the RTMK instruction is privileged in the sense that only the operating system may use it. The RFMK instruction, since its use is in key management, is restricted in this way as well.
Other master key variants are later discussed in connection with this protocol: KM3, for handling communications between hosts; KM4 for random number generation; and KM5 for authentication. These, however, are not stored in the cryptographic facility, but are protected by the use of the RTMK and RFMK instructions.
[Next] [Up/Previous] [Index]
Table of Contents