Applied Cryptography, Second Edition: Protocols, Algorthms, and Source Code in C (cloth)
(Publisher: John Wiley & Sons, Inc.)
Author(s): Bruce Schneier
ISBN: 0471128457
Publication Date: 01/01/96

24.3 ISDN

Bell-Northern Research developed a prototype secure Integrated Services Digital Network (ISDN) telephone terminal [499, 1192, 493, 500]. As a telephone, it was never developed beyond prototype. The resulting product was the Packet Data Security Overlay. The terminal uses Diffie-Hellman key exchange, RSA digital signatures, and DES data encryption; it can transmit and receive voice and data at 64 kilobits per second.

Keys

A long-term public-key/private-key key pair is embedded in the phone. The private key is stored in a tamper-resistant area of the phone. The public key serves as the identification of the phone. These keys are part of the phone itself and cannot be altered in any way.

Additionally, two other public keys are stored in the phone. One of these keys is the owner’s public key. This key is used to authenticate commands from the owner and can be changed via a command signed by the owner. In this way an owner can transfer ownership of the phone to someone else.

The public key of the network is also stored in the phone. This key is used to authenticate commands from the network’s key management facility and to authenticate calls from other users on the network. This key can also be changed via a signed command from the owner. This permits the owner to move his phone from one network to another.

These keys are considered long-term keys: rarely, if ever, changed. A short-term public-key/private-key key pair is also stored on the phone. These are encapsulated in a certificate signed by the key management facility. When two phones set up a call, they exchange certificates. The public key of the network authenticates these certificates.

This exchange and verification of certificates only sets up a secure call from phone to phone. To set up a secure call from person to person, the protocol has an additional piece. The owner’s private key is stored on a hardware ignition key, which is inserted into the telephone by the owner. This ignition key contains the owner’s private key, encrypted under a secret password known only by the owner (not by the phone, not by the network’s key management facility, not by anybody). It also contains a certificate signed by the network’s key management facility that contains the owner’s public key and some identifying information (name, company, job title, security clearance, favorite pizza toppings, sexual preference, or whatever). This is also encrypted. To decrypt this information and enter it into the phone, the owner types his secret password on the phone’s keypad. After the phone uses this information to set up calls, it is erased after the owner removes his ignition key.

The phone also stores a set of certificates from the network’s key management facility. These certificates authorize particular users to use particular phones.

Calling

A call from Alice to Bob works as follows.

(1)  Alice inserts her ignition key into the phone and enters her password.

(2)  The phone interrogates the ignition key to determine Alice’s identity and gives Alice a dial tone.

(3)  The phone checks its set of certificates to ensure that Alice is authorized to use the particular phone.

(4)  Alice dials the number; the phone places the call.

(5)  The two telephones use a public-key cryptography key-exchange protocol to generate a unique and random session key. All subsequent protocol steps are encrypted using this key.

(6)  Alice’s phone transmits its certificate and user authentication.

(7)  Bob’s phone authenticates the signatures on both the certificate and the user authentication using the network’s public key.

(8)  Bob’s phone initiates a challenge-and-reply sequence. It demands real-time signed responses to time-dependent challenges. (This prevents an adversary from using certificates copied from a previous exchange.) One response must be signed by Alice’s phone’s private key; another must be signed by Alice’s private key.

(9)  Bob’s phone rings, unless he is already on the phone.

(10)  If Bob is home, he inserts his ignition key into the phone. His phone interrogates the ignition key and checks Bob’s certificate as in steps (2) and (3).

(11)  Bob transmits his certificate and user authentication.

(12)  Alice’s phone authenticates Bob’s signatures as in step (7), and initiates a challenge-and-reply sequence as in step (8).

(13)  Both phones display the identity of the other user and phone on their displays.

(14)  The secure conversation begins.

(15)  When one party hangs up, the session key is deleted, as are the certificates Bob’s phone received from Alice’s phone and the certificates Alice’s phone received from Bob’s phone.

Each DES key is unique to each call. It exists only inside the two phones for the duration of the call and is destroyed immediately afterward. If an adversary captures one or both of the phones involved in the call, he will not be able to decrypt any previous call between the two phones.

24.4 STU-III

STU stands for “Secure Telephone Unit, ” an NSA-designed secure phone. The unit is about the size and shape of a conventional telephone, and can be used as such. The phones are also tamper-resistant, enough so that they are unclassified if unkeyed. They also have a data port and can be used to secure modem traffic as well as voice [1133].

Whitfield Diffie described the STU-III in [494]:

To make a call with a STU-III, the caller first places an ordinary call to another STU-III, then inserts a key-shaped device containing a cryptographic variable and pushes a “go secure” button. After an approximately 15-second wait for cryptographic setup, each phone shows information about the identity and clearance of the other party on its display and the call can proceed.

In an unprecedented move, Walter Deeley, NSA’s deputy director for communications security, announced the STU-III or Future Secure Voice System in an exclusive interview given to The New York Times [282]. The objective of the new system was primarily to provide secure voice and low-speed data communications for the U.S. Defense Department and its contractors. The interview didn’t say much about how it was going to work, but gradually the word began to leak out. The new system was using public key.

The new approach to key management was reported early on [68] and one article spoke of phones being “reprogrammed once a year by secure telephone link, ” a turn of phrase strongly suggestive of a certificate passing protocol, similar to that described [in Section 24.3], that minimizes the need for phones to talk to the key management center. Recent reports have been more forthcoming, speaking of a key management system called FIREFLY that [1341] “evolved from public key technology and is used to establish pair-wise traffic encryption keys.” Both this description and testimony submitted to the U.S. Congress by Lee Neuwirth of Cylink [1164] suggest a combination of key exchange and certificates similar to that used in the ISDN secure phone and it is plausible that FIREFLY too is based on exponentiation.

STU-IIIs are manufactured by AT&T and GE. Somewhere between 300, 000 and 400, 000 have been fielded through 1994. A new version, the Secure Terminal Equipment (STE), will work on ISDN lines.

24.5 Kerberos

Kerberos is a trusted third-party authentication protocol designed for TCP/IP networks. A Kerberos service, sitting on the network, acts as a trusted arbitrator. Kerberos provides secure network authentication, allowing a person to access different machines on the network. Kerberos is based on symmetric cryptography (DES as implemented, but other algorithms could be used instead). Kerberos shares a different secret key with every entity on the network and knowledge of that secret key equals proof of identity.

Kerberos was originally developed at MIT for Project Athena. The Kerberos model is based on Needham-Schroeder’s trusted third-party protocol (see Section 3.3) [1159]. The original version of Kerberos, Version 4, is specified in [1094, 1499]. (Versions 1 through 3 were internal development versions.) Version 5, modified from Version 4, is specified in [876, 877, 878]. The best overview of Kerberos is [1163]. Other survey articles are [1384, 1493], and two good articles on using Kerberos in the real world are [781, 782].