Two users of a program like RIPEM or PGP can communicate by exchanging public keys, but they are vulnerable to the "man-in-the-middle" attack under some circumstances. In a military environment, the opportunity to distribute secret keys to the users of a cryptosystem exists, but keys can be lost or stolen.
Since security is the overriding concern in a military environment, it is possible that a secure communications system for such users would attempt to combine the benefits of different approaches to key distribution.
There are, basically, three ways to provide a member of a communications network with the means to participate in secured communications.
That person may be provided with the public keys of other participants in the network, and asked to generate a public and private key for his own node.
If public keys are distributed directly to other network members in the same manner that secret keys are distributed, the problem of authentication is avoided. However, there is the limitation that a mathematical breakthrough might make it possible someday to derive secret keys from public keys, because of the restricted number of public-key algorithms.
That person may be provided with one or more secret keys for conventional encryption.
In that case, these keys are open to compromise by the participants in the network.
That person may be provided with a tamper-resistant hardware module containing key material which performs encryption functions internally.
Here, no person is provided with key material that can be betrayed; the module can use symmetric-key algorithms of arbitrary complexity and yet function as a physical "public key" since it can refuse to perform some possible functions with the key material it guards within it. However, tamper-resistance is not perfect, and physical objects can always end up being left behind on a field of battle.
For a military system, it is possible to use all three of these methods of key distribution, in such a way that the system will remain secure unless all three methods are compromised.
For each communications session, the session key could be formed from three components, combined so that no two of them would provide a useful clue to the actual key.
One component would be transmitted enciphered under the recipient's public key. Since only the recipient has a copy of his own secret key, unless the recipient's own terminal is captured, messages to it cannot be read.
Another component would be enciphered under a key manually entered on the device by the users at both ends. (This key could be enciphered under a user ID, so that while both users would in effect be entering the same key, they would not know what any other user would have to enter.) The manually entered key would be retained only in volatile storage, and would have to be re-entered each time the device was used again after being unplugged. Unless the keys are compromised in distribution, a person would have to reveal a key, since it would not be transmitted, nor would it be still present in the hardware if it were taken for inspection. Another way to provide a manual component to security would simply be for other data, internally stored in non-volatile memory, to be encrypted by a user password.
And the third component would be enciphered under key material hidden within tamper-proof hardware. This would not be transmitted, nor would it be known to any individuals.
Each of the three components of the system would be adequate to allow session keys to be communicated securely, unless they were compromised. Since these three components are vulnerable to compromise through different attacks: either overcoming the mathematical basis of the public-key system used, or compromising individuals using the system, or capturing hardware and defeating its tamper-resistance, a setup that requires all three to be compromised before it will fail has a greater likelihood of defeating the best efforts of a determined adversary.
In practice, it appears that the U.S. military is able to obtain the benefits of the second leg of this triad while avoiding its weaknesses, by physically loading encryption devices with key material from a modified handheld computer (the DTD, or AN/CYZ-10), probably similar to those gadgets with barcode readers you may see in advertisements in the back pages of computer magazines. This also allows keeping an audit trail of the distribution of key material.
Apparently, the job of generating a public/private key pair is not done by some cryptographic devices that use public-key cryptography, but is instead handled on, of all things, a desktop PC. At least they're running SCO Unix on the machines used for this function, rather than DOS. This information comes from a publicly accessible web site, operated by the U.S. Navy (at least access to their FTP server requires authorization), a link to which I found on a site with a somewhat out-of-date link on it to my page as well; the site also noted that at least as recently as 1992, eight years after the arrests of Walker and Whitworth, the Navy was still using some systems with paper keylists. This may not be as bad as it sounds, since it is not unreasonable for units to require an ability to communicate securely even when the power fails. (Said U.S. Navy site has a link to the "INFOSEC Tip of the Day" which uses a <BLINK> tag. However, it isn't a header or in large type.)
While I originally thought that external generation of public keys was an unfortunate concession to technical or cost limitations, I have since realized that my neat and tidy model of a triad of security features does have one flaw. While there is no mathematical flaw known in public-key encryption methods that would permit a passive attack, if a terminal simply thought up its own key pairs for use with a public-key system, then if the other components of the cryptographic system in use were compromised, a man-in-the-middle attack could be performed. Thus, a key for a simple public-key system is not able to make a real contribution to system security unless it is certified. And it is precisely a connection to an external hierarchy that allows this.
However, the Key Exchange Algorithm illustrates how uncertified key pairs, generated for each message, can still contribute to security when used in concert with key pairs for the public component of which a certificate exists.
The ideal, though, would be for a secure communications device to generate its own private and public key pairs, and submit only the public key to an external authority for certification through a trusted channel.
As I have noted elsewhere, while a cryptographic program like PGP creates a new session key for each message, and exchanges it using public-key techniques, one could obtain greater efficiency by only using public-key techniques infrequently, to exchange a conventional key used to encipher each message's session key. Such a key, as noted in the section on the IBM key management system, is called a key-exchange key, or KEK.
If we consider an encryption device which does not use public-key technology, the following hierarchy of keys is possible:
Building a key into the hardware of a cipher machine, and not allowing it to be changed, is a weakness. So why is the KEKEK treated this way?
Because one could omit the KEKEK entirely, and simply load the KEK into the device directly. But this creates the problem that the KEK is carried around in unencrypted form. If the KEKEK could be changed, with no key "above" it, then it would be the key carried around unencrypted.
Thus, placing a permanent key on the top does provide some real benefit: the topmost key loaded into the device is encrypted, even if the key used for that purpose might be compromised. Continuing the hierarchy upwards, on the other hand, simply begs the question of how keys are to be protected from compromise.
If public-key techniques are used, however, it becomes possible to usefully extend the hierarchy upwards by one step:
Since the public key of the device is only used to encrypt a key that is loaded into the device by physical contact, the problem of key certification is simplified. (It may not be entirely eliminated, if a key encrypted at one point is carried over a long distance, along which it is vulnerable to compromise, causing a key to be enciphered using a public key one has generated may be a useful attack.)
While extending the hierarchy upwards appears to be a useless exercise in infinite regress, extending the hierarchy downwards may be useful in systems which involve the exchange of large amounts of data at high speeds. In such a case, having a KEK or even a KEKEK which is transmitted over the insecure data link at occasional intervals in encrypted form is a useful way to limit the amount of data encrypted with a single key. In that case, the key at the next level up in the hierarchy would be the lowest-level one loaded by physical contact, and the rest of the hierarchy would move up accordingly.
Table of Contents