ńňđ. 1(âńĺăî 2)ŃÎÄĹĐĆŔÍČĹ >>
Page 152
Next Page
Prev. Page

CHAPTER Key Length
7

lel will spend 1O597 years finding the key. By that time the universe will have long
collapsed or expanded into nothingness.
Before you rush to invent a cryptosystem with an 8-kilobyte key, remember the
other side to the strength question: The algorithm must be so secure that there is no
better way to break it than with a brute-force attack. This is not as easy as it might
seem. Cryptography is a subtle art. Cryptosystems that look perfect are often
extremely weak. Strong cryptosystems, with a couple of minor changes, can become
weak. The warning to the amateur cryptographer is to have a healthy, almost para-
noid, suspicion of any new algorithm. It is best to trust algorithms that professional
cryptographers have scrutinized for years without cracking them and to be suspi-
cious of algorithm designersâ€™ grandiose claims of security.
Recall an important point from Section 1.1: The security of a cryptosystem
should rest in the key, not in the details of the algorithm. Assume that any crypt-
much ciphertext as he wants and can mount an intensive ciphertext-only attack.
Assume that he can mount a plaintext attack with as much data as he needs. Even
assume that he can mount a chosen-plaintext attack. If your cryptosystem can
remain secure, even in the face of all that knowledge, then youâ€™ve got something.
That warning aside, there is still plenty of room in cryptography to maneuver. In
reality, this kind of security isnâ€™t really necessary in many situations. Most adver-
saries donâ€™t have the knowledge and computing resources of a major government,
and even the ones who do probably arenâ€™t that interested in breaking your cryp-
tosystem. If youâ€™re plotting to overthrow a major government, stick with the tried
and true algorithms in the back of the book. The rest of you, have fun.
Time and Cost Estimates for Brute-Force Attack
Remember that a brute-force attack is typically a known-plaintext attack; it
requires a small amount of ciphertext and corresponding plaintext. If you assume
that a brute-force attack is the most efficient attack possible against an algorithm-
a big assumption-then the key must be long enough to make the attack infeasible.
How long is that?
Two parameters determine the speed of a brute-force attack: the number of keys
to be tested and the speed of each test. Most symmetric algorithms accept any fixed-
length bit pattern as the key. DES has a 56-bit key; it has 256possible keys. Some
algorithms discussed in this book have a 64-bit key; these have 264possible keys.
Others have a 128-bit key.
The speed at which each possible key can be tested is also a factor, but a less
important one. For the purposes of this analysis, I will assume that each different
algorithm can be tested in the same amount of time. The reality may be that one
algorithm may be tested two, three, or even ten times faster than another. But since
we are looking for key lengths that are millions of times more difficult to crack than
would be feasible, small differences due to test speed are irrelevant.
Most of the debate in the cryptologic community about the efficiency of brute-
force attacks has centered on the DES algorithm. In 1977, Whitfield Diffie and Mar-
tin Hellman [497] postulated the existence of a special-purpose DES-cracking
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter

CHAPTER 24 ................................................ 560
Example Implementations ........................ 560
IBM SECRET-KEY MANAGEMENT ......... 560
A Variation ..................................................... 561
MITRENET ............................................... 561
ISDN ......................................................... 562
Keys .............................................................. 562
Calling ........................................................... 563
STU-III ...................................................... 564
KERBEROS .............................................. 565
The Kerberos Model ....................................... 565
Figure 24.1 Kerberos authentication steps. ... 566
How Kerberos Works .................................... 566
Table 24.1 Kerberos Table of Abbreviation ... 566
Credentials .................................................... 567
Kerberos Version 5 Messages ...................... 567
Getting an Ticket ........................................... 568
Getting Server Tickets ................................... 568
Requesting a Service .................................... 569
Kerberos Version 4 ....................................... 569
Security Kerberos .......................................... 570
KRWTOKNIGHT ....................................... 570
SESAME .................................................. 571
IBM COMMON CRYPTOGRAPHIC .......... 572
IS0 AUTHENTICATION FRAMEWORK .... 573
Certificates .................................................... 574
Alice Figure 24.3 Sample certification ............ 574
Authentication Protocols ............................... 575
PRIVACY-ENHANCED MAIL (PEM)......... 576
PEM Documents ........................................... 577
Certificates .................................................... 578
PEM Messages ............................................. 578
Figure 24.4 Example of an encapsulated ....... 578
Figure 24.5 Example of an encapsulate ......... 579
Figure 24.6 Example of an encapsulated ....... 581
Security PEM ................................................. 581
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter

TIS/PEM ........................................................ 582
RIPEM ........................................................... 583
MESSAGE SECURITY PROTOCOL ........ 583
PRETTY GOOD PFUVACY (PGP) .......... 583
Figure 24.7 PGP trust model. ......................... 585
SMART CARDS ........................................ 586
PUBLIC-KEY CRYPTOGRAPHY .............. 587
UNIVERSALELECTRONICPAYMENT ..... 588
CAPSTONE .................................................. 592
Table 24.2 EES Participating Agencies .. 592
AT&T MODEL 3600 TELEPHONE ............... 593
Page 560
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter

24
CHAPTER

Example
Implementations
Itâ€™s one thing to design protocols and algorithms, but another thing to field them in
operational systems. In theory, theory and practice are the same; in practice they are
different. Often ideas that look good on paper donâ€™t work in real life. Maybe the
bandwidth requirements are too large; maybe the protocol is too slow. Chapter 10
discusses some of the issues related to using cryptography; this chapter gives exam-
ples of how it has been done in practice.

24.1 IBM SECRET-KEY MANAGEMENT PROTOCOL
In the late 1970s IBM developed a complete key management system for communi-
cations and file security on a computer network, using only symmetric cryptogra-
phy [515,1027]. This protocol is less important in the actual mechanisms and more
in its overall philosophy: By automating the generation, distribution, installation,
storage, changing, and destruction of keys, the protocol went a long way to ensure
the security of the underlying cryptographic algorithms.
This protocol provides three things: secure communications between a server and
several terminals, secure file storage at the server, and secure communication
among servers. The protocol doesnâ€™t really provide for direct terminal-to-terminal
communication, although it can be modified to do that.
Each server on the network is attached to a cryptographic facility, which does all
of the encrypting and decrypting. Each server has a Master Key, KM,, and two vari-
ants, KM1 and KM,, both of which are simple variants of KM,. These keys are used
to encrypt other keys and to generate new keys. Each terminal has a Master Termi-
nal Key, KMT, which is used to exchange keys with other terminals.
The servers store KMT, encrypted with KM1. All other keys, such as those used to
encrypt files of keys (called KNF), are stored in encrypted form under KM,. The mas-
ter key, KM,, is stored in some nonvolatile security module. Today that could be
Page 561
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24 Example Implementations
CHAPTER

either a ROM key or a magnetic card, or it could be typed in by the user (probably as
a text string and then key crunched). KM1 and KM2 are not stored anywhere in the
system, but are computed from KM, whenever they are needed. Session keys, for
communication among servers, are generated with a pseudo-random process in the
server. Keys to encrypt files for storage (KAY) are generated in the same manner.
The heart of the protocol is a tamper-resistant module, called a cryptographic
facility. At both the server and the terminal, all encryption and decryption takes
place within this facility. The most important keys, those used to generate the
actual encryption keys, are stored in this module. These keys can never be read once
they are stored. And they are tagged by use: A key dedicated for one purpose cannot
accidentally be used for another. This concept of key control vectors is probably the
most significant contribution of this system. Donald Davies and William Price dis-
cuss this key management protocol in detail [435].

A Variation
A variation on this scheme of master and session keys can be found in [ 14781.Itâ€™s
built around network nodes with key notarization facilities that serve local termi-
nals. It is designed to:

- Secure two-way communication between any two terminal users.
- Secure communications using encrypted mail.
- Provide personal file protection.
- Provide a digital signature capability.

For communication and file transfer among users, the scheme uses keys generated
in the key notarization facility and sent to the users encrypted under a master key.
The identities of the users are incorporated with the key, to provide evidence that
the session key has been used between a particular pair of users. This key notariza-
tion feature is central to the system. Although the system does not use public-key
cryptography, it has a digital-signature-like capability: A key could have only come
from a particular source and could only be read at a particular destination.

24.2 MITRENET
One of the earliest implementations of public-key cryptography was the experi-
mental system MEMO (MITRE Encrypted Mail Office). MITRE is a DOD contractor,
a government think tank, and an all-around bunch of smart guys. MEMO was a
secure electronic mail system for users in the MITRENET network, using public-
key cryptography for key exchange and DES for file encryption.
In the MEMO system, all public keys are stored in a Public Key Distribution Cen-
ter, which is a separate node on the network. They are stored in an EPROM to prevent
anyone from changing them. Private keys are generated by users or by the system.
Page 562
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
ISDN
24.3

For a user to send secure messages, the system first establishes a secure commu-
nications path with the Public Key Distribution Center. The user requests a file of
all public keys from the Center. If the user passes an identification test using his
private key, the Center sends this list to the userâ€™s workstation. The list is
encrypted using DES to ensure file integrity.
The implementation uses DES to encrypt messages. The system generates a ran-
dom DES key for file encryption; the user encrypts the file with the DES key and
encrypts the DES key with the recipientâ€™s public key. Both the DES-encrypted file
and the public-key-encrypted key are sent to the recipient.
MEMO makes no provision for lost keys. There is some provision for integrity
checking of the messages, using checksums. No authentication is built into the
system.
The particular public-key implementation used for this system-Diffie-Hellman
key exchange over GF(21z7)-was proven insecure before the system was imple-
mented (see Section 11.6), although it is easy to modify the system to use larger
numbers. MEMO was intended mainly for experimental purposes and was never
made operational on the real MITRENET system.

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 Secu-
rity Overlay. The terminal uses Diffie-Hellman key exchange, RSA digital signa-
tures, 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 pri-
vate 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 authen-
ticate 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 net-
work 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
Page 563
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24 Example Implementations
CHAPTER

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.

Alice inserts her ignition key into the phone and enters her password.
(1)
(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 th e 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 adver-
sary 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 inter-
rogates the ignition key and checks Bobâ€™s certificate as in steps (2) and (3).
Page 564
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24.4 STU-III

Bob transmits his certificate and user authentication.
(11)
Aliceâ€™s phone authenticates Bobâ€™s signatures as in step (7), and initiates a
(12)
challenge-and-reply sequence as in step (8).
(13) Both phones display the identity of the other user and phone on their
displays.
The secure conversation begins.
(14)
When one party hangs up, the session key is deleted, as are the certificates
(15)
Bobâ€™s phone received from Aliceâ€™s phone and the certificates Aliceâ€™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 pre-
vious 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 [ 11331.
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 l&second wait for crypto-
graphic 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 commu-
nications security, announced the STU-III or Future Secure Voice System in an
exclusive interview given to The New York Times (2821. The objective of the new
system was primarily to provide secure voice and low-speed data communica-
tions 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 1681and one arti-
cle 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.31, 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
Page 565
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24 Example Implementations
CHAPTER

and is used to establish pair-wise traffic encryption keys.â€ť Both this
technology
description and testimony submitted to the U.S. Congress by Lee Neuwirth of
Cylink [11641suggest 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-111s 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 Equip-
ment (STE), will work on ISDN lines.

24.5 KERBEROS
Kerberos is a trusted third-party authentication protocol designed for TCP/IP net-
works. A Kerberos service, sitting on the network, acts as a trusted arbitrator. Ker-
beros 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 differ-
ent 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)
[ 11591. The original version of Kerberos, Version 4, is specified in [ 1094,1499]. (Ver-
sions 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].

Model
The Kerberos
The basic Kerberos protocol was outlined in Section 3.3. In the Kerberos model,
there are entities-clients and servers-sitting on the network. Clients can be users,
but can also be independent software programs that need to do things: download
files, send messages, access databases, access printers, obtain administrative privi-
leges, whatever.
Kerberos keeps a database of clients and their secret keys. For a human user, the
secret key is an encrypted password. Network services requiring authentication, as
well as clients who wish to use these services, register their secret key with Kerberos.
Because Kerberos knows everyoneâ€™s secret key, it can create messages that con-
vince one entity of another entityâ€™s identity. Kerberos also creates session keys
which are given to a client and a server (or to two clients) and no one else. A session
key is used to encrypt messages between the two parties, after which it is destroyed.
Kerberos uses DES for encryption. Kerberos Version 4 provided a nonstandard
mode for authentication. This mode is weak: It fails to detect certain changes to the
ciphertext (see Section 9.10). Kerberos Version 5 uses CBC mode.
Page 566
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter

Kerberos
24.5

1. Request for Ticket-Granting Ticket
2. Ticket-Granting Ticket
3. Request for ServerTicket
4. ServerTicket
5. Request for Service

Figure 24.1 Kerberos authentication steps.

How Kerberos Works
This section discusses Kerberos Version 5. I will outline the differences between
Version 4 and Version 5 further on. The Kerberos protocol is straightforward (see
Figure 24.1). A client requests a ticket for a Ticket-Granting Service (TGS) from Ker-
beros. This ticket is sent to the client, encrypted in the clientâ€™s secret key. To use a
particular server, the client requests a ticket for that server from the TGS. Assum-
ing everything is in order, the TGS sends the ticket back to the client. The client
then presents this ticket to the server along with an authenticator. Again, if thereâ€™s
nothing wrong with the clientâ€™s credentials, the server lets the client have access to
the service.

Table 24.1
Kerberos Table of Abbreviations
client
=
C

= server
S
a
= beginning and ending validity time for a ticket
V

= timestamp
t

K, = xâ€™s secret key
K â€˜wY = session key for x and y
(m]Kx = m encrypted in xâ€™s secret key
TXâ€™Y = xâ€™s ticket to use y
A Xâ€™Y = authenticator from x to y
Page 567
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24 Example Implementations
CHAPTER

Credentials
Kerberos uses two types of credentials: tickets and authenticators. (The rest of
this section uses the notation used in Kerberos documents-see Table 24.1.) A
ticket is used to pass securely to the server the identity of the client for whom the
ticket was issued. It also contains information that the server can use to ensure that
the client using the ticket is the same client to whom the ticket was issued. An
authenticator is an additional credential, presented with the ticket.
A Kerberos ticket takes this form:
T,, s = s, IG a, v, Kc, ,lK
A ticket is good for a single server and a single client. It contains the clientâ€™s name
and network address, the serverâ€™s name, a timestamp, and a session key. This infor-
mation is encrypted with the serverâ€™s secret key. Once the client gets this ticket, she
can use it multiple times to access the server-until the ticket expires. The client
cannot decrypt the ticket (she does not know the serverâ€™s secret key), but she can
present it to the server in its encrypted form. No one listening on the network can
read or modify the ticket as it passes through the network.
A Kerberos authenticator takes this form:

The client generates it every time she wishes to use a service on the server. The
authenticator contains the clientâ€™s name, a timestamp, and an optional additional
session key, all encrypted with the session key shared between the client and the
server. Unlike a ticket, it can only be used once. However, since the client can
generate authenticators as needed (it knows the shared secret key), this is not a
problem.
The authenticator serves two purposes. First, it contains some plaintext encrypted
in the session key. This proves that it also knows the key. Just as important, the
sealed plaintext includes the timestamp. An eavesdropper who records both the
ticket and the authenticator canâ€™t replay them two days later.

Kerberos Version 5 Messages
Kerberos Version 5 has five messages (see Figure 24.1):

Client to Kerberos: G QY
1.
2. Kerberos to client: (Kc,t,K, D-c,tgsKgs
3. Client to TGS: L%, ,I& tgs. t&&s
Fâ€™c,
4. TGS to client: K, JK, tgs, JK
(Tc,
5. Client to server: (A, sK, s.P-c,#-G

These will now be discussed in detail.
Page 568
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
Kerberos
24.5

an Initial
Getting Ticket
The client has one piece of information that proves her identity: her password.
Obviously we donâ€™t want her to send this password over the network. The Kerberos
protocol minimizes the chance that this password will be compromised, while at
the same time not allowing a user to properly authenticate herself unless she knows
The client sends a message containing her name and the name of her TGS server
to the Kerberos authentication server. (There can be many TGS servers.) In reality,
the user probably just enters her name into the system and the login program sends
the request.
The Kerberos authentication server looks up the client in his database. If the
client is in the database, Kerberos generates a session key to be used between her
and the TGS. This is called a Ticket Granting Ticket (TGT). Kerberos encrypts that
session key with the clientâ€™s secret key. Then it creates a TGT for the client to
authenticate herself to the TGS, and encrypts that in the TGSâ€™s secret key. The
authentication server sends both of these encrypted messages back to the client.
The client now decrypts the first message and retrieves the session key. The
secret key is a one-way hash of her password, so a legitimate user will have no trou-
ble doing this. If the user were an imposter, he would not know the correct password
and therefore could not decrypt the response from the Kerberos authentication
server. Access would be denied and he wouldnâ€™t be able to get the ticket or the ses-
sion key.
The client saves the TGT and session key and erases the password and the one-
way hash. This information is erased to reduce the chance of compromise. If an
adversary manages to copy the clientâ€™s memory, he will only get the TGT and the
session key. These are valuable pieces of information, but only during the lifetime
of the TGT. After the TGT expires, they will be worthless.
The client can now prove her identity to the TGS for the lifetime of the TGT.

Getting Server Tickets
A client has to obtain a separate ticket for each service she wants to use. The TGS
grants tickets for individual servers.
When a client needs a ticket that she does not already have, she sends a request to
the TGS. (In reality, the program would do this automatically, and it would be invis-
ible to the user.)
The TGS, upon receiving the request, decrypts the TGT with his secret key. Then
he uses the session key included in the TGT to decrypt the authenticator. Finally,
he compares the information in the authenticator with the information in the
ticket, the clientâ€™s network address with the address the request was sent from, and
the timestamp with the current time. If everything matches, he allows the request
to proceed.
Checking timestamps assumes that all machines have synchronized clocks, at
least to within several minutes. If the time in the request is too far in the future or
Page 569
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24 Example Implementations
CHAPTER

the past, the TGS treats the request as an attempt to replay a previous request. The
TGS should also keep track of all live authenticators, because past requests can have
timestamps that are still valid. Another request with the same ticket and time-
The TGS responds to a valid request by returning a valid ticket for the client to
present to the server. The TGS also creates a new session key for the client and the
server, encrypted with the session key shared by the client and the TGS. Both of
these messages are then sent back to the client. The client decrypts the message and
extracts the session key.
Requesting a Service
Now the client is ready to authenticate herself to the server. She creates a mes-
sage very similar to the one sent to the TGS (which makes sense, since the TGS is a
service).
The client creates an authenticator, consisting of her name and network address,
and a timestamp, encrypted with the session key for her and the server that the TGS
encrypted with the serverâ€™s secret key) and the encrypted authenticator.
The server decrypts and checks the ticket and the authenticator, as discussed pre-
viously, and also checks the clientâ€™s address and the timestamp. If everything
checks out, the server knows that, according to Kerberos, the client is who she says
she is.
For applications that require mutual authentication, the server sends the client
back a message consisting of the timestamp, encrypted with the session key. This
proves that the server knew his secret key and could decrypt the ticket and there-
fore the authenticator.
The client and the server can encrypt future messages with the shared key, if
desired. Since only they share this key, they both can assume that a recent message
encrypted in that key originated with the other party.

Kerberos Version 4
The previous sections discussed Kerberos Version 5. In the messages and the con-
struction of the tickets and authenticators, Version 4 is slightly different.
In Kerberos Version 4, the five messages looked like:

1. Client to Kerberos: G tgs
2. Kerberos to client: (Kc,tgs,(T,, fgs]Ktgs]Kc
3. Client to TGS: (A, ,K, tgs,IT,, tgsKgs> s
4. TGS to client: K, s>(Tc,KIK, tgs
5. Client to server: (A, JK, st IT,, &

T,,s= (s,c, a, v, 1,K, ,lK
A, s= (c, a, WC,s
Page 570
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter

Messages 1, 3, and 5 are identical. The double encryption of the ticket in steps 2
and 4 has been removed in Version 5. The Version 5 ticket adds the possibility of
multiple addresses, and it replaces a â€ślifetimeâ€ť field, 1, with a beginning and ending
time. The Version 5 authenticator adds the option of including an additional key.

of Kerberos
Security
Steve Bellovin and Michael Merritt discussed several potential security vulnera-
bilities of Kerberos [ 1081. Although this paper was written about the Version 4 pro-
tocols, many of their comments also apply to Version 5.
It may be possible to cache and replay old authenticators. Although timestamps
are supposed to prevent this, replays can be done during the lifetime of the ticket.
Servers are supposed to store all valid tickets to prevent replays, but this is not
always possible. And ticket lifetimes can be long; eight hours is typical.
Authenticators rely on the fact that all the clocks in the network are more or less
synchronized. If a host can be fooled about the correct time, then an old authentica-
tor can be replayed without any problem. Most network time protocols are insecure,
so this can be a serious problem.
Kerberos is also vulnerable to password-guessing attacks. An intruder can collect
tickets and then try to decrypt them. Remember that the average user doesnâ€™t usu-
ally choose good passwords. If Mallory collects enough tickets, his chances of recov-
Perhaps the most serious attack involves malicious software. The Kerberos proto-
cols rely on the fact that the Kerberos software is trustworthy. Thereâ€™s nothing to
stop Mallory from surreptitiously replacing all client Kerberos software with a ver-
sion that, in addition to completing the Kerberos protocols, records passwords. This
is a problem with any cryptographic software package on an insecure computer, but
the widespread use of Kerberos in these environments makes it a particularly tempt-
ing target.
Enhancements to Kerberos are in the works, including an implementation of
public-key cryptography and a smart-card interface for key management.

Kerberos is not in the public domain, but MITâ€™s code is freely available. Actually
implementing it into a working UNIX environment is another story. Several compa-
nies sell versions of Kerberos, but you can get a good version free from Cygnus Sup-
port, 814 University Ave., Palo Alto, CA, 94301; (415) 322-3811; fax: (415) 322-3270.

24.6 KRWTOKNIGHT
KryptoKnight (Kryptonite-get it?) is an authentication and key distribution system
designed by IBM. It is a secret-key protocol and uses either DES in CBC mode (see
Section 9.3) or a modified version of MD5 (see Section 18.5).
KryptoKnight supports four security services:
Page 571
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24 Example Implementations
CHAPTER

- User authentication (called single sign-on)
- Two-party authentication
- Key distribution
- Authentication of data origin and content

From a userâ€™s perspective, KryptoKnight is similar to Kerberos. Some differences are:

- KryptoKnight uses a hash function for authentication and encrypting
tickets.
- KryptoKnight does not rely on synchronized clocks; it uses nonces for
challenges (see Section 3.3).
- If Alice wishes to communicate with Bob, KryptoKnight has the
option of allowing Alice to send a message to Bob and then for Bob to
initiate the key exchange protocol.

KryptoKnight has tickets and authenticators, just like Kerberos. It has TGSs, but
KryptoKnight calls them authentication servers. KryptoKnightâ€™s designers spent con-
siderable effort minimizing the number of messages, lengths of messages, and amount
of encryption. For further information on KryptoKnight, read [ 1110,173,174,175].

24.7 SESAME
SESAME stands for Secure European System for Applications in a Multivendor
Environment. Itâ€™s a European Community security project, 50 percent funded by
RACE (see Section 25.7) whose primary objective is producing technology for user
authentication with distributed access control. Think of it as kind of a European
version of Kerberos. Itâ€™s a two-part project: Stage one is a basic prototype of the
architecture, and stage two is a set of commercial projects. The three companies
with the greatest hand in development are ICL in the United Kingdom, Siemens in
Germany, and Bull in France.
SESAME is an authentication and key-exchange system [361,1248,797,1043]. It
uses the Needham-Schroeder protocol, with public-key cryptography to communi-
cate between different security domains. The system is seriously flawed in several
respects. Instead of using a real encryption algorithm, they use XOR with a 64-bit
key size. Even worse, they use XOR in CBC mode, which leaves half the plaintext
unencrypted. In their defense, they planned on using DES until the French govern-
ment complained; they validated the code with DES but then removed it, and expect
people to add it back. I am unimpressed nonetheless.
Authentication in SESAME is a function on the first block of a message, not on
the entire message. This has the effect of authenticating â€śDear Sirâ€ť and not the body
of a letter. Key generation consists of two calls to the UNIX rand function, which
isnâ€™t very random. SESAME uses crc32 and MD5 as one-way hash functions. And of
course, SESAME is vulnerable to Kerberos-like password-guessing.
Page 572
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24.9 IS0 Authentication Framework

24.8 IBM COMMON CRYPTOGRAPHIC ARCHITECTURE
The Common Cryptographic Architecture (CCA) was designed and developed by
IBM to provide cryptographic primitives for confidentiality, integrity, key manage-
ment, and personal identification number (PIN) processing [75 1,784,1025,1026,
940,752]. Keys are managed by control vectors (CVs) (see Section 8.5). Every key has
a CV XORed with it and is never separated from the vector unless inside secure
hardware. The CV is a data structure providing an intuitive understanding of the
privileges associated with a particular key.
The individual bits of the CV are defined to have specific meanings for using and
handling each key managed by CCA. The CV is carried with the encrypted key in
data structures called key tokens. Internal key tokens are used locally and contain
keys encrypted under the local master key (MK). External key tokens are used to
export and import encrypted keys between systems. Keys in external key tokens are
encrypted under key-encrypting keys (KEK). The KEKs are managed in internal key
tokens. Keys are separated according to their permitted uses.
Key length is also specified and enforced using bits in the CV. Single length
keys are 56 bits and are used for such functions as privacy and message authenti-
cation. Double length keys are 112 bits and are used for key management, PIN
functions, and other special uses. Keys can be required to be DOUBLE-ONLY in
which both the left and right halves of the key must be different, DOUBLE in
which the halves are permitted to be equal by chance, SINGLE-REPLICATED in
which the left and right halves are equal, or SINGLE which contains only 56 bits.
The CCA functions specify hardware enforcement of certain key types to be used
for some operations.
The CV is checked in a secure hardware processor: It must conform to the ger-
mitted CCA rules for each CCA function. If the CV successfully passes the test
requirements, a variant of the KEK or MK is obtained by the XOR of the KEK or MK
with the CV, and the plaintext target key is recovered for use internally with the
CCA function. When new keys are generated, the CV specifies the uses of the gen-
erated key. Those combinations of key types that could be used in attacking the sys-
tem are not generated or imported into a CCA-compliant system.
CCA uses a combination of public-key cryptography and secret-key cryptography
for key distribution. The KDC shares a secret master key with each user and
encrypts session keys using that master key. Master keys are distributed using
public-key cryptography.
The systemâ€™s designers chose this hybrid approach for two reasons. The first is
performance. Public-key cryptography is computationally intensive; if session keys
are distributed using public-key cryptography, the system might bog down. The sec-
ond is backwards compatibility; this system can be overlaid on existing secret-key
schemes with minimal disruption.
CCA systems are designed to be interoperable. For systems that are non-CCA
compliant, a Control Vector Translate (CVXLT) function permits keys to be passed
between the two implementations. Initialization of the CVXLT function requires
dual control. Two individuals must set up the required translation tables indepen-
Page 573
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter

24 Example Implementations
CHAPTER

dently. Such dual control provides a high degree of assurance concerning the
integrity and pedigree of any keys introduced into the system.
A key of type DATA is provided for compatibility with other systems. A DATA
key is stored with a CV that identifies the key as a DATA key. DATA keys can have
broad uses and as such must be regarded with suspicion and used with care. DATA
keys may not be used for any key management functions.
The Commercial Data Masking Facility (CDMF) provides an exportable version of
CCA. It has a special feature that reduces DES keys to an effective 40 bits for export
(see Section 15.5) [785].

24.9 IS0 AUTHENTICATION FRAMEWORK
Public-key cryptography has been recommended for use with the IS0 authentica-
tion framework, also known as the X.509 protocols [304]. This framework provides
for authentication across networks. Although no particular algorithms are specified
for either security or authentication, the specification recommends RSA. There are

Version

Serial Number

Algorithm Identifier:
-Algorithm
- Parameters

Issuer

Period of Validity:
- Not Before Date
- Not After Date

Subject

Subjectâ€™s Public Key:
- Algorithm
- Parameters
- Public Key

Signature Figure 24.2 An X.509 certificate.
Page 574
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24.9 IS0 Authentication Framework

provisions, however, for multiple algorithms and hash functions. X.509 was ini-
tially issued in 1988. After public review and comment, it was revised in 1993 to
correct some security problems [ 1100,750].

Certificates
The most important part of X.509 is its structure for public-key certificates. Each
user has a distinct name. A trusted Certification Authority (CA) assigns a unique
name to each user and issues a signed certificate containing the name and the userâ€™s
public key. Figure 24.2 shows an X.509 certificate [304].
The version field identifies the certificate format. The serial number is unique
within the CA. The next field identifies the algorithm used to sign the certificate,
together with any necessary parameters. Issuer is the name of the CA. The period of
validity is a pair of dates; the certificate is valid during the time period between the
two. Subject is the name of the user. The subjectâ€™s public key information includes
the algorithm name, any necessary parameters, and the public key. The last field is
the CAâ€™s signature.
If Alice wants to communicate with Bob, she first gets his certificate from a data-
base. Then she verifies its authenticity. If both share the same CA, this is easy. Alice
simply verifies the CAâ€™s signature on Bobâ€™s certificate.
If they use different CAs, itâ€™s more complicated. Think of a tree structure, with
different CAs certifying other CAs and users. On the top is one master CA. Each CA
has a certificate signed by the CA above it, and by the CAs below it. Alice uses these
certificates to verify Bobâ€™s certificate.
Figure 24.3 illustrates this. Aliceâ€™s certificate is certified by CAAi Bobâ€™s is certified
by CA,. Alice knows CA,â€˜s public key. CAo has a certificate signed by CA*, so Alice

Figure 24.3 Sample certification hierarchy.
Alice
Page 575
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24 Example Implementations
CHAPTER

can verify that. CAD has a certificate signed by CAc. CAB has a certificate signed by
CAD. And Bobâ€™s certificate is signed by CAB. By moving up the certification tree to
a common point, in this case CAD, and then down to Bob, Alice can verify Bobâ€™s cer-
tificate.
Certificates can be stored on databases around the network. Users can send them
to each other. When a certificate expires, it should be removed from any public
directories. The issuing CA, however, should maintain a copy of the certificate.
Should a dispute arise later, it will be required.
Certificates can also be revoked, either because the userâ€™s key has been compro-
mised, the CAâ€™s key has been compromised, or because the CA no longer wants to
certify the user. Each CA must maintain a list of all revoked but not expired certifi-
cates. When Alice receives a new certificate, she should check to see if it has been
revoked. She can check a database of revoked keys on the network, but more likely
she will check a locally cached list of revoked certificates. There are certainly pos-
sible abuses to this system; key revocation is probably its weakest part.
Authentication Protocols
Alice wants to communicate with Bob. First she goes to a database and obtains
what is called a certification path from Alice to Bob, and Bobâ€™s public key. At this
point Alice can initiate either a one-way, two-way, or three-way authentication
protocol.
The one-way protocol is a single communication from Alice to Bob. It establishes
the identities of both Alice and Bob and the integrity of any information communi-
cated by Alice to Bob. It also prevents any replay attacks on the communication.
The two-way protocol adds a reply from Bob. It establishes that Bob, and not an
imposter, sent the reply. It also establishes the secrecy of both communications and
prevents replay attacks.
Both the one-way and two-way protocols use timestamps. A three-way protocol
adds another message from Alice to Bob and obviates the need for timestamps (and
therefore authenticated time).
The one-way protocol is:

Alice generates a random number, RA.
(1)
(2) Alice constructs a message, M = (TA, RA, IB, d), where TA is Aliceâ€™s time-
stamp, IB is Bobâ€™s identity, and d is an arbitrary piece of data. The data may
be encrypted with Bobâ€™s public key, EB,for security.
(3) Alice sends (C,, DA(M)) to Bob. (C, is Aliceâ€™s certificate; DA is Aliceâ€™s pri-
vate key.)
(4) Bob verifies CA and obtains EA. He makes sure these keys have not expired.
(EAis Aliceâ€™s public key.)
(5) Bob uses EA to decrypt DA(M). This verifies both Aliceâ€™s signature and the
integrity of the signed information.
(6) Bob checks the IB in M for accuracy.
(7) Bob checks the TA in M and confirms that the message is current.
Page 576
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter

(8) As an option, Bob can check RA in M against a database of old random num-
bers to ensure the message is not an old one being replayed.

The two-way protocol consists of the one-way protocol and then a similar one-
way protocol from Bob to Alice. After executing steps (1) through (8) of the one-way
protocol, the two-way protocol continues with:

(9) Bob generates another random number, RB.
( 10) Bob constructs a message Mâ€™ = (T,, RB, IA, RA, d), where TB is Bobâ€™s time-
stamp, IA is the identity of Alice and d is arbitrary data. The data may be
encrypted with Aliceâ€™s public key, EA, for security. RA is the random num-
ber Alice generated in step (1).
(11) Bob sends D&Hâ€™) to Alice.
(12) Alice uses EB to decrypt D&Uâ€™). This verifies both Bobâ€™s signature and the
integrity of the signed information.
( 13) Alice checks the ZAin Mâ€™ for accuracy.
(14) Alice checks the TB in ZVIâ€™and confirms that the message is current.
(15) As an option, Alice can check the RB in Mâ€™ to ensure the message is not an
old one being replayed.

The three-way protocol accomplishes the same thing as the two-way protocol, but
without timestamps. Steps (1) through (15) are identical to the two-way protocol,
with TA = TB = 0.

(16) Alice checks the received version of RA against the RA she sent to Bob in
step (3).
(17) Alice sends II, to Bob.
(18) Bob uses EA to decrypt DA(RB).This verifies both Aliceâ€™s signature and the
integrity of the signed information.
(19) Bob checks the received version of RB against the RB he sent to Alice in
step (10).

24.10 MAIL (PEM)
PRIVACY-ENHANCED
PEM is the Internet Privacy-Enhanced Mail standard, adopted by the Internet Archi-
tecture Board (IAB) to provide secure electronic mail over the Internet. It was ini-
tially designed by the Internet Research Task Force (IRTF) Privacy and Security
Research Group (PSRG), and then handed over to the Internet Engineering Task
Force (IETF) PEM Working Group. The PEM protocols provide for encryption,
authentication, message integrity, and key management.
Page 577
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
CHAPTER 24 Example Implementations

The complete PEM protocols were initially detailed in a series of RFCs
(Requests for Comment) in [977] and then revised in [978]. The third iteration of
the protocols [979,827,980] is summarized in [ 177,178]. The protocols were modi-
fied and improved, and the final protocols are detailed in another series of RFCs
[981,825,76,802]. Another paper by Matthew Bishop [179] details the changes.
Reports of attempts to implement PEM include [602,1505,1522,74,351,1366,
PEM is an inclusive standard. The PEM procedures and protocols are intended to
be compatible with a wide range of key-management approaches, including both
symmetric and public-key schemes to encrypt data-encrypting keys. Symmetric
cryptography is used for message-text encryption. Cryptographic hash algorithms
are used for message integrity. Other documents support key-management mecha-
nisms using public-key certificates; algorithms, modes, and associated identifiers;
and paper and electronic format details and procedures for the key-management
infrastructure to support these services.
PEM supports only certain algorithms, but allows for different suites of algorithms
to be specified later. Messages are encrypted with DES in CBC mode. Authentica-
tion, provided by something called a Message Integrity Check (MIC), uses either
MD2 or MD5. Symmetric key management can use either DES in ECB mode or
triple-DES using two keys (called EDE mode). PEM also supports public-key certifi-
cates for key management, using the RSA algorithm (key length up to 1024 bits) and
the X.509 standard for certificate structure.
PEM provides three privacy-enhancement services: confidentiality, authentica-
tion, and message integrity. No special processing requirements are imposed on the
electronic mail system. PEM can be incorporated selectively, by site or by user,
without affecting the rest of the network.
PEM Documents
The specifications for PEM come from four documents:
- RFC 1421: Part I, Message Encryption and Authentication Proce-
dures. This document defines message encryption and authentication
procedures in order to provide privacy-enhanced mail services for
electronic mail transfer on the Internet.
- RFC 1422: Part II, Certificate-Based Key Management. This docu-
ment defines a supporting key management architecture and infra-
structure, based on public-key certificate techniques to provide
keying information to message originators and recipients.
- RFC 1423: Part III, Algorithms, Modes, and Identifiers. This docu-
ment provides definitions, formats, references, and citations for
cryptographic algorithms, usage modes, and associated identifiers
and parameters.
- RFC 1424: Part IV, Key Certification and Related Services. This docu-
ment describes three types of service in support of PEM: key certifi-
cation, certificate revocation list (CRL) storage, and CRL retrieval.
Page 578
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24.10 Privacy-Enhanced Mail (PEM)

Certificates
PEM is compatible with the authentication framework described in [304]j see also
[826]. PEM is a superset of X.509; it establishes procedures and conventions for a
key-management infrastructure for use with PEM and with other protocols (from
both the TCP/IP and OS1 suites) in the future.
The key-management infrastructure establishes a single root for all Internet cer-
tification. The Internet Policy Registration Authority (IPRA) establishes global poli-
cies that apply to all certification under this hierarchy. Beneath the IPRA root are
Policy Certification Authorities (PCAs), each of which establishes and publishes its
policies for registering users or organizations. Each PCA is certified by the IPRA.
Below PCAs, CAs certify users and subordinate organizational entities (such as
departments, offices, subsidiaries). Initially, the majority of users are expected to be
registered with some organization.
Some PCAs are expected to provide certification for users who wish to register
independent of any organization. For users who wish anonymity while taking
advantage of PEM privacy facilities, one or more PCAs are expected to be estab-
lished with policies that allow for registration of users who do not wish to disclose
their identities.
PEM Messages
PEMâ€™s heart is its message format. Figure 24.4 shows an encrypted message using
symmetric key management, Figure 24.5 shows an authenticated and encrypted
message using public-key key management, and Figure 24.6 shows an authenticated
(but unencrypted) message using public-key key management.
The first field is â€śProc-Type,â€ť and identifies the type of processing performed on
the message. There are three possible types of messages. The â€śENCRYPTEDâ€ť spec-

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DES-CBC,F8143EDE5960C597
Originator-ID-Symmetric: schneier@counterpane.com,,
Recipient-ID-Symmetric: schneier@chinet.com,ptf-kmc,3
Key-Info:
˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜
Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4
Key-Info:
˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜˜
LLrHBOeJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoHlnvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXROUrUzYbkNpkOagV2IzUpk
J6UiRRGcDSvzrsoK+oNvquGz7Xs5Xfz5rDqUcMlKlZ672OdcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----END PRIVACY-ENHANCED MESSAGE-----

Figure 24.4 Example of an encapsulated message (symmetric case).
Page 579
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24 Example Implementations
CHAPTER

1
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DESCBC,BFF968AA74691ACl
Originator-Certificate:
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGAlUEBhMCVVMxIDAeBgNV
BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFwO5MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSUOEgRGFOYSBTZWNlcmlOeSwgSW5jLjEU
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/xOfM+YrsyFlu3F
LZPVtzlndhYFJQIDAQABMAOGCSqGSIb3DQEBAgUAAlkACKrOPqphJYwlj+YPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMpZX3U/
5XUXGx7qusDgHQGs7Jk9W8CWlfuSWUgN4w==
Key-Info: RSA,
13rRIGXUGWAF8js5wCzRTkdh034PTHdRZY9TuvmO3M+NM7fx6qc5udixps2LngO+
wGrtiUm/ovtKdinz6ZQ/aQ==
Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGAlUEBhMCVVMxIDAeBgNV
BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQOEwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDclOTU5WjBRMQsw
CQYDVQQGEwJVUzEgMB4GAlUEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMAOGA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnpGlQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
cqAz/7R7XhjYCmOPcqbdzoACZtIlETrKrcJiDYoP+DkZ8klgCk7hQHpbIwIDAQAB
MAOGCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
dD2jMZ/3HsyWKWgSFOeH/AJB3qr9zosG47pyMnTf3aSyZnBO7CMxpUWRBcXUpE+x
EREZd9++32ofGBIXaialnOgVUnOOzSYgugiQO77nJLDUjOhQehCizEs5wUJ35a5h
MIC-Info: RSA-MD5,RSA,
UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv
AjRFbHoNPzBuxwmOAFeAOHJszL4yBvhG
Recipient-ID-Asymmetric:
MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSUOEgRGFOYSBTZWNlcmlOeSwgSW5j
LjEPMAOGAlUECxMGQmVOYSAxMQ8wDQYDVQQLEwZOTlRBUlk=,
66
Key-Info: RSA,
06BSlww9CTyHPtS3bMLD+LOhejdvX6QvlHK2ds2sQPEaXhX8EhvVphHYTjwekdWv
7xOZ3Jx2vTAhOYHMcqqCjA==
qeWljlYJ2Uf5ng9yznPbtDOmYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d
jIqCJAxvld2xgqQimUzoSla4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA==
-----END PRIVACY-ENHANCED MESSAGE-----
i
Figure 24.5 Example of an encapsulated ENCRYPTED message (asym-
metric case).
Page 580
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24.10 Privacy-Enhanced Mail (PEM)

ifier says that the message is encrypted and signed. The â€śMIC-ONLYâ€ť and â€śMIC-
CLEARâ€ť specifiers would indicate that the message is signed, but not encrypted.
MIC-CLEAR messages are not encoded and can be read using non-PEM software.
MIC-ONLY messages need PEM software to transform them to a human-readable
form. A PEM message is always signed; it is optionally encrypted.
The next field, â€śContent-Domain,â€ť specifies the type of mail message. It has
nothing to do with security. The â€śDEK-Infoâ€ť field gives information on the Data
Exchange Key (DEK), the encryption algorithm used to encrypt the text, and any
parameters associated with the encryption algorithm. Only DES in CBC mode is
currently specified, or â€śDES-CBC.â€ť The second subfield specifies the IV. Other algo-
rithms may be specified by PEM in the future; their use will be noted in DEK-Info
and in other fields that identify algorithms.
For messages with symmetric key management (see Figure 24.4), the next field is
â€śOriginator-ID-Symmetricâ€ť with three subfields. The first subfield identifies the
sender by a unique electronic mail address. The second subfield is optional and iden-
tifies the authority that issued the interchange key. The third is an optional Ver-
sion/Expiration subfield.
Continuing with the symmetric key-management case, each recipient has two
fields: â€śRecipient-ID-Symmetricâ€ť and â€śKey-Info.â€ť The â€śRecipient-ID-Symmetricâ€ť
field has three subfields; these identify the receiver in the same way that â€śOriginator-
ID-Symmetricâ€ť identified the sender.
The â€śKey-Infoâ€ť field specifies the key-management parameters. This field has four
subfields. The first subfield gives the algorithm used to encrypt the DEK. Since the
key management in this message is symmetric, the sender and receiver have to share
a common key. This is called the Interchange Key (IK), which is used to encrypt the
DEK. The DEK can be either encrypted using DES in ECB (denoted by â€śDES-ECBâ€ť)
or triple-DES (which would be denoted â€śDES-EDEâ€ť). The second subfield specifies
the MIC algorithm. It can be either MD2 (denoted by â€śRSA-MD2â€ť) or MD5 (which
would be denoted â€śRSA-MDEiâ€ť). The third subfield, the DEK, and the fourth field,
the MIC, are both encrypted with the IK.
Figures 24.5 and 24.6 show messages with public-key key management (called
â€śasymmetricâ€ť in PEM nomenclature). The headers are different. In ENCRYPTED
messages, after the â€śDEK-Infoâ€ť field comes the â€śOriginator-Certificateâ€ť field. The
certificate follows the X.509 standard (see Section 24.9). The next field is â€śKey-Infoâ€ť
with two subfields. The first subfield specifies the public-key algorithm used to
encrypt the DEK; currently only RSA is supported. The next subfield is the DEK,
encrypted in the originatorâ€™s public key. This is an optional field, intended to permit
the originator to decrypt his own message in the event that it is returned by the mail
system. The next field â€śIssuer-Certificate,â€ť is the certificate of whomever signed
the Originator-Certificate.
Continuing with the asymmetric key-management case, the next field is â€śMIC-
Info.â€ť The first subfield gives the algorithm under which the MIC was computed.
The second subfield shows the algorithm under which the MIC was signed. The
third subfield consists of the MIC, signed by the senderâ€™s private key.
Page 581
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
CHAPTER 24 Example Implementations

-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MICONLY
Content-Domain: RFC822
Originator-Certificate:
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGAlUEBhMCVVMxIDAeBgNV
BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFwO5MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSUOEgRGFOYSBTZWNlcmlOeSwgSW5jLjEU
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/xOfM+YrsyFlu3F
LZPVtzlndhYFJQIDAQABMAOGCSqGSIb3DQEBAgUAAlkACKrOPqphJYwlj+YPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
5XUXGx7qusDgHQGs7Jk9W8CWlfuSWUgN4w==
Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGAlUEBhMCVVMxIDAeBgNV
BAoTFlJTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQOEwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDclOTU5WjBRMQsw
CQYDVQQGEwJVUzEgMB4GAlUEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMAO˜AlUECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnp61QCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
cqAz/7R7XhjYCmOPcqbdzoACZtIlETrKrcJiDYoP+DkZ8klgCk7hQHpbIwIDAQAB
MAOGCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
dD2jMZ/3HsyWKWgSFOeH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
EREZd9++32ofGBIXaialnOgVUnOOzSYgugiQ077nJLDUjOhQehCizEs5wUJ35a5h
MIC-Info: RSA-MD5,RSA,
EtE7K2QDeVMCyXsdJlA8fA==
LSBBIGllc3NhZ2UgZm9yIHVzZSBpbiBOZXNOaW5nLgOKLSBGb2xsb3dpbmcgaXMg
YSBibGFuayBsaW510g0KDQpUaGlzIGlzIHRoZSB1bmQuDQo=
-----END PRIVACY-ENHANCED MESSAGE-----

Figure 24.6 Example of an encapsulated MIC-ONLY message (asymmet-
ric case).

Still continuing with asymmetric key management, the next fields deal with the
recipients. There are two fields for each recipient: â€śRecipient-ID-Asymmetricâ€ť and
â€śKey-Info.â€ť The â€śRecipient-ID-Asymmetricâ€ť field has two subfields. The first iden-
tifies the authority that issued the receiverâ€™s public key; the second is an optional
Version/Expiration subfield. The â€śKey-Infoâ€ť field specifies the key management
parameters: The first subfield identifies the algorithm used to encrypt the message
and the second subfield is the DEK encrypted with the receiverâ€™s public key.
of PEM
Security
RSA keys in PEM can range from 508 bits to 1024 bits. This should be long
enough for anyoneâ€™s security needs. A more likely attack would be against the key-
management protocols. Mallory could steal your private key-donâ€™t write it down
Page 582
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24.10 Privacy-Enhanced Mail (PEM)

anywhere-or attempt to fool you into accepting a bogus public key. The key certi-
fication provisions of PEM make this unlikely if everyone follows proper proce-
dures, but people have been known to be sloppy.
A more insidious attack would be for Mallory to modify the PEM implementation
running on your system. This modified implementation could surreptitiously send
Mallory all of your mail, encrypted with his public key. It could even send him a
copy of your private key. If the modified implementation works well, you will never
know what is happening.
Thereâ€™s no real way to prevent this kind of attack. You could use a one-way hash
function and fingerprint the PEM code. Then, each time you run it, you could check
the fingerprint for modification. But Mallory could modify the fingerprint code at
the same time he modifies the PEM code. You could fingerprint the fingerprint code,
can subvert the security of PEM.
The moral is that you can never really trust a piece of software if you cannot trust
the hardware it is running on. For most people, this kind of paranoia is unwarranted.
For some, it is very real.
TZS/PEM
Trusted Information Systems, partially supported by the U.S. government
Advanced Research Projects Agency, has designed and implemented a reference
implementation of PEM (TIS/PEM). Developed for UNIX-based platforms, it has
also been ported to VMS, DOS, and Windows.
Although the PEM specifications indicate a single certification hierarchy for use
by the Internet, TIS/PEM supports the existence of multiple certification hierar-
chies. Sites may specify a set of certificates that are to be considered valid, includ-
ing all certificates issued by them. A site need not join the Internet hierarchy in
order to use TIS/PEM.
TIS/PEM is currently available to all U.S. and Canadian organizations and citizens
upon request. It will be distributed in source code form. Interested parties should
contact: Privacy-Enhanced Mail, Trusted Information Systems, Inc., 3060 Washing-
ton Road (Rte. 97) Glenwood, MD 21738; (301) 854-6889; fax: (301) 854-5363; Inter-
net: pem-info@tis.com.

RZPEM
RIPEM is a program, written by Mark Riordan, that implements the PEM proto-
cols. Although technically not public domain, the program is publicly available and
can be used royalty-free for personal, noncommercial applications. A license for its
use is included with the documentation.
The code cannot be exported. Of course, U.S. government laws donâ€™t apply out-
side the United States, and some people have ignored the export rules. RIPEM code
is available on bulletin boards worldwide. Something called RIPEM/SIG, which
only does digital signatures, is exportable.
Page 583
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter
24 Example Implementations
CHAPTER

At this writing, RIPEM is not a complete implementation of the PEM protocols;
it does not implement certificates for authenticating keys.
Before writing RIPEM, Riordan wrote a similar program called RPEM. This was
intended to be a public-domain electronic-mail encryption program. To try to avoid
patent issues, Riordan used Rabinâ€™s algorithm (see Section 19.5). Public Key Partners
claimed that their patents were broad enough to cover all of public-key cryptogra-
phy and threatened to sue; Riordan stopped distributing the program.
RPEM isnâ€™t really used anymore. It is not compatible with RIPEM. Since RIPEM
can be used with the full blessing of Public Key Partners, there is no reason to use

24.11 (MSP)
MESSAGE SECURITY PROTOCOL
The Message Security Protocol (MSP) is the military equivalent of PEM. It was
developed by the NSA in the late 1980s under the Secure Data Network System
(SDNS) program. It is an X.400-compatible application-level protocol for securing
electronic mail. MSP will be used for signing and encrypting messages in the
Department of Defenseâ€™s planned Defense Message System (DMS) network.
The Preliminary Message Security Protocol (PMSP), to be used for â€śunclassified
but sensitiveâ€ť messages, is a version of MSP adapted for use with both X.400 and
TCP/IP. This protocol is also called Mosaic.
Like PEM, MSP and PMSP software applications are flexible and designed to
accommodate a variety of algorithms for security functions including signing, hash-
ing, and encryption. PSMP will work with the Capstone chip (see Section 24.17).

24.12 PRETTY PFUVACY (PGP)
GOOD
Pretty Good Privacy (PGP) is a freeware electronic-mail security program, originally
designed by Philip Zimmermann [1652]. It uses IDEA for data encryption, RSA
(with keys up to 2047 bits) for key management and digital signatures, and MD5 as
a one-way hash function.
PGPâ€™s random public keys use a probabilistic primality tester, and get their initial
seeds from measuring the userâ€™s keyboard latency while typing. PGP generates ran-
dom IDEA keys using the method delineated in ANSI X9.17, Appendix C (see Sec-
tion 8.1) [55], with IDEA as the symmetric algorithm instead of DES. PGP also
encrypts the userâ€™s private key using a hashed pass phrase instead of a password.
PGP-encrypted messages have layered security. The only thing a cryptanalyst can
learn about an encrypted message is who the recipient is, assuming he knows the
recipientâ€™s key ID. Only after the recipient decrypts the message does he learn who
signed the message, if it is signed. Contrast this approach with PEM, which leaves
quite a bit of information about the sender, recipient, and message in the unen-
Page 584
Prev. Chapter Home Previous Page
Next Page
Prev. page
Next Page Next Chapter

The most interesting aspect of PGP is its distributed approach to key manage-
ment (see Section 8.12). There are no key certification authorities; PGP instead
supports a â€śweb of trust.â€ť Every user generates and distributes his own public key.
Users sign each otherâ€™s public keys, creating an interconnected community of
PGP users.
For example, Alice might physically give her public key to Bob. Bob knows Alice,
so he signs her public key. He then gives the signed key back to her and keeps a copy
for himself. When Alice wants to communicate with Carol, Alice sends Carol a
copy of the key Bob signed. Carol, who already has Bobâ€™s public key (she got it at
some other time) and trusts Bob to certify other peopleâ€™s keys, verifies his signature
on Aliceâ€™s key and accepts it as valid. Bob has introduced Alice to Carol.
PGP does not specify a policy for establishing trust; users are free to decide who
they trust and who they do not. PGP provides mechanisms for associating trust
with public keys and for using trust. Each user keeps a collection of signed public
keys in a file called a public-key ring. Each key in the ring has a key legitimacy field
that indicates the degree to which the particular user trusts the validity of the key.
The higher the trust level, the more the user believes the key is legitimate. A sig-
nature trust field measures how far the user trusts the signer to certify the public
keys of other users. And finally, an owner trust field indicates the degree to which
the particular user trusts the keyâ€™s owner to sign other public keys; this field is set
manually by the user. PGP continuously updates these fields as users supply new
information.
 ńňđ. 1(âńĺăî 2)ŃÎÄĹĐĆŔÍČĹ >>