PRETTY GOOD PRIVACY
PGP is a remarkable phenomenon. Largely the
effort of a single person, Phil Zimmermann, PGP provides a confidentiality and
authentication service that can be used for electronic mail and file storage
applications. In essence, Zimmermann has done the following:
1.
Selected the
best available cryptographic algorithms as building blocks.
2.
Integrated these
algorithms into a general-purpose application that is inde- pendent of operating system
and processor and that is based on a small
set of easy-to-use commands.
3.
Made the package and
its documentation, including the source code, freely available via the
Internet, bulletin boards, and commercial networks such as AOL (America On Line).
4.
Entered
into an agreement
with a company (Viacrypt, now Network Associates) to provide a fully compatible, low-cost commercial version
of PGP.
PGP has grown explosively and is now widely
used. A number of reasons can be cited for this growth.
1.
It is available free
worldwide in versions that run on a variety of platforms, including
Windows, UNIX, Macintosh, and
many more. In addition,
the commer- cial version
satisfies users who want a product that comes with vendor support.
2.
It is based on algorithms that have survived extensive public review and are con- sidered
extremely secure. Specifically, the package includes RSA, DSS, and Diffie-Hellman for public-key encryption; CAST-128, IDEA, and 3DES for sym-
metric encryption; and SHA-1 for hash coding.
3.
It has a wide range
of applicability, from corporations
that wish to select and enforce a standardized scheme for encrypting files and messages
to individuals who wish to communicate securely with others worldwide over the Internet
and other networks.
4.
It was not developed by, nor is it controlled by, any governmental
or standards organization. For those with an instinctive distrust
of “the establishment,” this makes
PGP attractive.
5.
PGP is now on an
Internet standards track (RFC 3156; MIME
Security with OpenPGP). Nevertheless,
PGP still has an aura
of an antiestablishment endeavor.
We begin with an overall look at
the operation of PGP. Next,
we examine how cryptographic
keys are created and stored. Then,
we address the vital issue of public-key management.
Notation
Most of the notation used in this chapter
has been used before,
but a few terms
are new. It is perhaps best to summarize
those at the beginning. The following symbols are used.
The PGP documentation often uses the term secret key to refer
to a key paired with a public key in a public-key encryption scheme. As was mentioned earlier,
this practice risks confusion with a secret
key used for symmetric encryption. Hence, we use the term private key instead.
Operational Description
The actual operation of PGP, as opposed
to the management of keys, consists of four services: authentication, confidentiality, compression, and e-mail compatibility
(Table 18.1). We examine each of these
in turn.
AUTHENTICATION Figure
18.1a illustrates the digital signature service provided by PGP. This is the
digital signature scheme discussed in Chapter 13 and illustrated in Figure
13.2. The sequence is as follows.
1.
The sender creates a message.
2.
SHA-1 is used to generate a 160-bit hash code of the message.
3.
The hash code is encrypted
with RSA using the sender’s private key, and the
result is prepended to the message.
4.
The receiver uses RSA with the
sender’s public key
to decrypt and recover the
hash code.
5.
The
receiver
generates a new hash code for the message
and compares it with the decrypted hash code. If the two match, the message is accepted as authentic.
Table
18.1 Summary
of PGP Services
The combination of SHA-1 and RSA provides an effective digital
signature scheme. Because of the strength
of RSA, the recipient is assured that only the pos-
sessor of the matching private key can generate
the signature. Because of the strength of SHA-1, the recipient is assured that no one else
could generate a new message that matches the hash
code and, hence, the signature of the original message.
As an alternative, signatures can be
generated using DSS/SHA-1.
Although signatures normally are found
attached to the message or file that they sign, this is not always the case: Detached
signatures are supported. A detached signature may be stored
and transmitted separately from the message
it signs. This
is useful in several
contexts. A user may wish to maintain
a separate signature log of all messages
sent or received. A detached signature of an executable program can detect subsequent virus infection. Finally, detached
signatures can be used when more than one party must sign a document, such as a legal contract.
Each person’s signature is independent and therefore is applied only to the document. Otherwise, signatures would have to be
nested, with the second signer signing both the docu- ment and the first
signature, and so on.
CONFIDENTIALITY Another basic service
provided by PGP is confidentiality, which is provided by encrypting messages
to be transmitted or to be stored
locally as files. In both cases, the symmetric encryption algorithm CAST-128 may be used.
Alternatively, IDEA or 3DES may be used. The 64-bit cipher feedback (CFB) mode
is used.
As always, one must address the problem of
key distribution. In PGP, each
symmetric key is used only once. That is, a new key is generated as a random 128-bit
number for each message. Thus, although
this is referred
to in the documentation as a session key, it is in reality a one-time key. Because it is to be used only once, the session key is bound to the message
and transmitted with it. To protect
the key, it is encrypted with the receiver’s public key. Figure 18.1b
illustrates the sequence, which can be described as follows.
1.
The sender generates a message and a random 128-bit number to be used as a session key for this message only.
2.
The message is encrypted using CAST-128 (or IDEA or 3DES) with the ses- sion
key.
3.
The session key is encrypted
with RSA using the recipient’s public key and is
prepended to the message.
4.
The receiver uses RSA with its private
key to decrypt and recover
the session key.
5.
The session key is used to
decrypt the message.
As an alternative
to the use of RSA for key encryption, PGP
provides an option referred to as Diffie-Hellman. As was explained in Chapter 10, Diffie- Hellman is a key exchange algorithm. In fact, PGP uses a variant of Diffie-Hellman
that does provide encryption/decryption, known
as ElGamal (Chapter
10).
Several observations may be made. First, to reduce encryption time, the combi-
nation of symmetric and public-key encryption is used in preference to simply using RSA or ElGamal to encrypt the message directly:
CAST-128 and the other symmet-
ric algorithms are substantially faster
than RSA or ElGamal. Second,
the use of the
public-key algorithm solves
the session-key distribution problem, because only the
recipient is able to recover the session key that is bound to the message. Note
that we do not need a session-key exchange protocol of the type discussed in Chapter 14, because
we are not beginning an ongoing session.
Rather, each message
is a one-time inde- pendent event
with its own key. Furthermore, given
the store-and-forward nature
of electronic mail, the use of handshaking to assure that both sides have the same
session key is not practical. Finally, the use of one-time symmetric
keys strengthens what is
already a strong symmetric encryption approach. Only a small amount of
plaintext is encrypted with each key, and
there is no relationship among the keys. Thus,
to the extent that the public-key algorithm is secure, the entire scheme is secure. To this end, PGP provides
the user with a range
of key size options from 768
to 3072 bits (the DSS
key for signatures is limited to 1024 bits).
CONFIDENTIALITY AND AUTHENTICATION
As Figure 18.1c
illustrates, both services may be used
for the same message. First, a signature is generated for the plaintext message
and prepended to the message. Then the plaintext message plus signature is
encrypted using CAST-128 (or IDEA or
3DES), and the session key is encrypted using RSA (or ElGamal). This sequence
is preferable to the opposite: encrypting
the message and then generating a signature for the encrypted message.
It is generally more convenient
to store a signature with a plaintext version of a message. Furthermore, for
purposes of third-party verification, if the signature is performed first, a
third party need not be concerned with the symmetric key when verifying the
signature.
In summary,
when both services are used, the sender first signs the message with its
own private key, then encrypts the
message with a session key, and
finally encrypts the session key with the recipient’s public key.
COMPRESSION As a default, PGP compresses
the message after applying the signature but before encryption. This has the benefit of saving space
both for e-mail transmission and for file storage.
The placement of the compression algorithm, indicated by Z for compression
and Z–1 for decompression in Figure 18.1,
is critical.
1.
The signature is generated
before compression for two reasons:
a.
It is preferable to sign an uncompressed message
so that one can store only
the uncompressed message together with the signature for future verifica- tion. If one signed
a compressed document, then it would
be necessary either
to store a compressed version of the message for later verification or
to recompress the message
when verification is required.
Even if one were willing
to generate dynamically a recompressed message for verification, PGP’s
compression algorithm presents a difficulty. The algo- rithm is not deterministic; various implementations of the algorithm achieve different tradeoffs in running speed
versus compression ratio
and, as a result,
produce different compressed forms. However, these
different compression
algorithms are interoperable because any version of the algorithm can correctly decompress the output of any
other version. Applying the hash function and signature after
compression would constrain all PGP imple- mentations to the same version of
the compression algorithm.
2.
Message encryption is applied after compression to strengthen cryptographic security. Because the
compressed message has less
redundancy than the original plaintext, cryptanalysis is more
difficult.
The compression algorithm used is ZIP, which
is described in Appendix O.
E-MAIL COMPATIBILITY When PGP
is used, at least part
of the block
to be transmitted is encrypted. If
only the signature service is used, then the
message digest is encrypted (with the sender’s private
key). If the confidentiality service
is used, the message plus signature (if present) are encrypted (with
a one-time symmetric key). Thus, part or
all of the resulting block consists of a stream of arbitrary 8-bit octets.
However, many electronic mail systems only permit the use of blocks consisting of ASCII text. To accommodate this restriction, PGP
provides the service
of converting the raw 8-bit binary
stream to a stream of printable ASCII
characters.
The scheme used for this purpose is radix-64 conversion. Each
group of three octets of binary data is mapped into four ASCII characters. This format also appends
a CRC to detect transmission errors. See Appendix 18A for a description.
The use of radix 64 expands a message by 33%. Fortunately, the session key and signature
portions of the message are relatively compact,
and the plaintext mes- sage has been compressed. In fact, the compression should
be more than enough to compensate for the radix-64
expansion. For example, [HELD96]
reports an average compression ratio of about 2.0 using ZIP. If we ignore the relatively small signature
and key components, the typical overall effect of compression and expansion of
a file of length X would be 1.33 * 0.5 * X = 0.665 * X. Thus, there is
still an overall compression of about one-third.
One noteworthy aspect
of the radix-64 algorithm is that it blindly converts
the input stream to radix-64 format regardless of content, even if the
input happens to be ASCII text.
Thus, if a message
is signed but not encrypted and the conversion is applied to the entire block, the output will be unreadable
to the casual observer, which provides a certain level of confidentiality. As an option,
PGP can be config- ured to
convert to radix-64 format only the signature portion of signed plaintext
messages. This enables
the human recipient to read the message without
using PGP. PGP would still have to be used to verify the signature.
Figure 18.2 shows the relationship among the
four services so far discussed. On transmission (if it is required), a signature is generated using
a hash code of the uncompressed
plaintext. Then the plaintext (plus signature if present) is com- pressed. Next, if confidentiality is required, the block (compressed plaintext or com- pressed signature plus plaintext) is
encrypted and prepended with the public-key- encrypted
symmetric encryption key. Finally, the
entire block is converted to
radix-64 format.
On reception, the incoming block is first converted back from radix-64
format to binary. Then, if
the message is encrypted, the recipient recovers the session key and decrypts
the message. The resulting
block is then decompressed. If the message is signed, the recipient recovers
the transmitted hash code and compares it to its own calculation of the hash code.
Cryptographic Keys and Key
Rings
PGP makes use of four types of keys: one-time session symmetric keys, public
keys, private keys, and
passphrase-based symmetric keys
(explained subsequently). Three separate requirements can be identified with respect to these keys.
1.
A means
of generating unpredictable session keys is needed.
2.
We would like to allow a user to have multiple
public-key/private-key pairs. One
reason is that the user may wish to change his or her key pair from time to time. When
this happens, any messages in the pipeline will be constructed with an obsolete key. Furthermore, recipients will know only the old public key until an update reaches them. In addition to the need to change keys over time, a user
may wish to have multiple key pairs at a given time to interact with different groups of correspondents or simply
to enhance security
by limiting the amount of
material encrypted
with any one key. The upshot of all this is that there is not a
one-to-one correspondence between users and their public keys. Thus, some means is needed for
identifying particular keys.
3.
Each PGP entity must
maintain a file of its own public/private key pairs as well as a file of public
keys of correspondents.
We examine each of these requirements in
turn.
SESSION KEY
GENERATION Each session
key is associated with a single
message and is used only for the purpose
of encrypting and decrypting that message. Recall
that message encryption/decryption is
done with a symmetric encryption algorithm.
CAST-128 and IDEA use 128-bit keys; 3DES uses a 168-bit
key. For the following
discussion, we assume CAST-128.
Random 128-bit numbers are generated using CAST-128 itself. The input to the random number generator consists of a 128-bit
key and two 64-bit blocks that are treated as plaintext to be encrypted. Using cipher feedback
mode, the CAST-128
encrypter produces two 64-bit cipher text blocks, which are concatenated
to form the 128-bit session key. The algorithm that is used is based on the
one specified in ANSI X12.17.
The “plaintext”
input to the random number generator, consisting of two 64-bit
blocks, is itself derived from a stream of 128-bit
randomized numbers. These numbers are based on keystroke input from the user. Both the keystroke
timing and the actual
keys struck are used to generate the randomized stream.
Thus, if the user hits
arbitrary keys at his or her normal
pace, a reasonably “random” input will be generated. This random input is also combined with previous session
key output from CAST-128 to form the key input to the
generator. The result, given the effective scrambling of CAST-128,
is to produce a sequence
of session keys that is effectively unpredictable.
Appendix P discusses PGP random number
generation techniques in more detail.
KEY IDENTIFIERS As we have discussed, an encrypted message is accompanied
by an encrypted form of the session key that was used for message encryption.
The session key itself is encrypted with the recipient’s public key. Hence,
only the recipient will be able to recover
the session key and therefore
recover the message. If each user employed a single
public/private key pair, then the recipient would automatically know which key to use to decrypt the session key: the
recipient’s unique private
key. However, we have stated a requirement that any given user may have
multiple public/private key pairs.
How, then,
does the recipient know which of its public
keys was used to encrypt
the session key? One simple solution would be to transmit the public key with the message. The recipient
could then verify that this is indeed one of its public keys, and proceed. This
scheme would work,
but it is unnecessarily wasteful
of space. An RSA public key may be hundreds of decimal digits
in length. Another
solution would be to associate an identifier with each public
key that is unique at least within one user. That is, the combination of user ID and key ID would be sufficient to iden- tify a key uniquely. Then only the much shorter
key ID would need to be transmit- ted. This solution, however,
raises a management and overhead problem: Key
IDs must be assigned and stored so that both sender and recipient could
map from key ID to public
key. This seems unnecessarily burdensome.
The solution adopted by PGP is to assign a key ID to each
public key that is, with very high
probability, unique within a user ID.2 The key ID associated with each public key consists of its least
significant 64 bits. That
is, the key ID of public key PUa is (PUa mod 264). This is a sufficient length that the probability of duplicate
key IDs is very small.
A key ID is also required for the PGP
digital signature. Because a sender may use one of a number of private keys to
encrypt the message digest, the recipient
must know which public key is intended for use. Accordingly, the digital
signature component of a message includes the 64-bit key ID of the required
public key. When the message is received,
the recipient verifies that the key ID is for a public key that it knows for that sender and then proceeds to verify the signature.
Now that the
concept of key ID has been introduced, we can take a more
detailed look at the format
of a transmitted message, which
is shown in Figure 18.3. A message
consists of three components: the message
component, a signature (optional), and a session
key component (optional).
The message component includes the actual
data to be stored or transmitted,
as well as a filename
and a timestamp that specifies
the time of creation.
The signature component includes the following.
•
Timestamp: The time at which the
signature was made.
•
Message digest: The 160-bit SHA-1 digest
encrypted with the sender’s private signature key. The digest is
calculated over the signature timestamp concate- nated with the data portion of
the message component. The inclusion
of the signature timestamp in the digest insures against replay types of
attacks. The exclusion of the filename and timestamp portions of the
message component ensures that
detached signatures are exactly the same as attached signatures
prefixed to the message. Detached signatures are
calculated on a separate file that has none of the message component header
fields.
•
Leading two octets of message digest: Enables
the recipient to determine if the
correct public key was used to decrypt the message digest for authentica- tion by comparing this plaintext copy of the first two octets with the first
two octets of the decrypted digest.
These octets also serve as a 16-bit
frame check sequence for the message.
•
Key ID of sender’s public key: Identifies the public
key that should
be used to decrypt the message digest
and, hence, identifies the private key that was used
to encrypt the message digest.
The message component and optional signature component may
be com- pressed using ZIP and may be encrypted using a session key.
The session key component
includes the session key and the identifier of the
recipient’s public key that was used by the sender
to encrypt the session key.
The entire block is usually encoded with
radix-64 encoding.
KEY RINGS
We have seen how key IDs are critical to the operation of PGP and that
two key IDs are included in any PGP message that provides both confidentiality
and authentication. These
keys need to be stored and organized
in a systematic way for efficient
and effective use by all parties. The scheme used in PGP is to provide
a pair of data structures at each node, one to store the public/private key pairs owned by that node and one to store the
public keys of other users known at this node. These data structures are
referred to, respectively, as the
private-key ring and the public-key ring.
Figure 18.4 shows
the general structure of a private-key ring. We can view
the ring as a table in which
each row represents one of the public/private key pairs owned by this user. Each
row contains the entries:
•
Timestamp: The date/time when this key pair was generated.
•
Key ID: The least significant 64
bits of the public key for this entry.
•
Public key: The public-key portion of the pair.
•
Private key: The private-key portion of the pair;
this field is encrypted.
•
User ID: Typically, this will be the user’s e-mail address
(e.g., stallings@acm.org). However, the user may choose to associate a
different name with each pair (e.g., Stallings,
WStallings, WilliamStallings, etc.) or to reuse the same User ID more
than once.
The private-key ring can be indexed by either User ID or Key ID; later we will
see the need for both means of indexing.
Although it is intended that the private-key
ring be stored only on the machine of the user that created and
owns the key pairs and that it be accessible only to that user, it makes sense
to make the value of the private key as secure as possible. Accordingly, the private key itself is not stored in the key ring.
Rather, this key is encrypted using
CAST-128 (or IDEA or 3DES). The procedure is as follows:
1.
The user selects a passphrase to be used for encrypting private keys.
2.
When the system generates a new public/private key pair using RSA, it asks the user for the passphrase. Using SHA-1, a 160-bit hash code is generated
from the passphrase, and the passphrase is discarded.
3.
The system encrypts the private
key using CAST-128 with the 128 bits
of the hash code as the key. The hash code is then discarded, and the encrypted private key is stored in the private-key ring.
Subsequently, when a user accesses the
private-key ring to retrieve a pri- vate key, he or she must supply the
passphrase. PGP will retrieve the encrypted private key, generate the hash code
of the passphrase, and decrypt the encrypted private key using CAST-128 with
the hash code.
This is a very compact
and effective scheme.
As in any system based on pass- words, the security of this system
depends on the security of the password. To avoid the temptation to write it down,
the user should use a passphrase that is not easily guessed but that is easily remembered.
Figure 18.4 also shows the general structure of a public-key ring. This
data structure is used to store public keys of other users that are known to
this user. For the moment, let us ignore
some fields shown
in the figure and describe
the following fields.
•
Timestamp: The date/time when this entry
was generated.
•
Key ID: The least significant 64
bits of the public key for this entry.
•
Public Key: The public key for this entry.
•
User ID: Identifies the owner of this key. Multiple user IDs may be associated with a single public
key.
The public-key ring can be indexed by either User ID or Key
ID; we will see the need for both means of indexing later.
We are now in a position to show how these key rings are used
in message transmission and reception. For simplicity, we ignore compression and radix-64 con- version in the following discussion. First consider message
transmission (Figure 18.5) and assume that the message is to
be both signed and encrypted. The sending PGP entity performs the following steps.
Figure 18.5 PGP Message Generation (from User A to User B: no
compression or radix-64 conversion)
1.
Signing the message:
a.
PGP retrieves the sender’s private key from the private-key
ring using your_userid as an index. If your_userid
was not provided in the command, the first private
key on the
ring is retrieved.
b.
PGP prompts
the user for the passphrase to recover the unencrypted private key.
c.
The signature component of the message
is constructed.
2.
Encrypting the message:
a.
PGP generates a session key
and encrypts the
message.
b.
PGP retrieves the recipient’s public key from the public-key
ring using
her_userid as an index.
c.
The session key component of the message
is constructed.
The receiving PGP entity performs the
following steps (Figure 18.6).
1.
Decrypting the
message:
a.
PGP retrieves the receiver’s private key from the private-key ring using the
Key ID field in the session key component of the message
as an index.
b.
PGP prompts the user
for the passphrase to recover the unencrypted private key.
c.
PGP then recovers the session key and decrypts
the message.
2.
Authenticating the message:
a.
PGP retrieves the sender’s
public key from the public-key ring using the Key ID
field in the
signature key component of the message
as an index.
b.
PGP recovers
the transmitted message
digest.
c.
PGP computes
the message digest
for the received
message and compares
it to the transmitted message digest to authenticate.
Public-Key Management
As can be seen from the discussion so far, PGP contains a clever, efficient, interlock- ing set of functions and formats to provide an effective confidentiality and authenti- cation
service. To complete the system, one
final area needs to be addressed, that of public-key management. The PGP
documentation captures the importance of this
area:
This whole business of protecting public
keys from tampering is the single most difficult problem
in practical public
key applications. It is
the “Achilles heel” of public key cryptography, and a lot of soft- ware complexity is tied up in solving this one problem.
PGP provides a structure for solving
this problem with several suggested options
that may be used. Because PGP is intended for use in a variety of formal and informal
environments, no rigid
public-key management scheme
is set up, such as
we will see in our discussion of S/MIME later in this chapter.
APPROACHES TO PUBLIC-KEY MANAGEMENT The essence of the problem is this: User A must
build up a public-key ring containing
the public keys of other users to interoperate with them using PGP. Suppose that A’s key ring contains a public
key attributed to B, but in fact the key is owned by C. This could happen,
for example, if A got the key from a bulletin board
system (BBS) that was used by B to post the public key but that has been
compromised by C. The result is that
two threats now exist. First,
C can send messages to A and forge B’s signature so that A will accept the message as coming from B. Second, any encrypted message
from A to B can be
read by C.
A number of
approaches are possible for minimizing the
risk that a user’s public-key ring contains false
public keys.
Suppose that A wishes to obtain a reliable
public key for B. The following are some approaches that could be used.
1.
Physically get the
key from B. B could store her public
key (PUb) on a floppy disk and hand
it to A. A could then load the
key into his system from the floppy
disk. This is a very secure method but has obvious practical limitations.
2.
Verify a key by telephone. If A can recognize
B on the phone, A could call B and ask
her to dictate the key, in radix-64 format, over the phone.
As a more practical
alternative, B could transmit her key in an e-mail message to A. A could have PGP generate
a 160-bit SHA-1 digest of the
key and display it in hexadecimal format; this is referred
to as the “fingerprint” of the key. A could then call B and ask
her to dictate the fingerprint over the phone. If the two fingerprints match, the key is verified.
3.
Obtain B’s public key from a mutual trusted individual D. For this purpose,
the introducer, D, creates
a signed certificate. The certificate includes B’s public key, the time of creation
of the key, and a validity
period for the key. D generates an
SHA-1 digest of this certificate, encrypts it with her private key, and attaches
the signature to the certificate. Because only D could have created
the signature, no one else
can create a false public key and pretend that it is signed by D. The
signed certificate could be sent directly to A by B or D, or it could be posted on a
bulletin board.
4.
Obtain B’s public key from a trusted certifying authority. Again, a public-key
certificate is created and
signed by the authority. A could then access the authority, providing a user name and receiving
a signed certificate.
For cases 3 and 4, A already would have to have a copy of the
introducer’s public key and trust that this key is valid.
Ultimately, it is up to A to assign a level of trust
to anyone who is to act as an introducer.
THE USE OF TRUST Although PGP does not include
any specification for establishing
certifying authorities or for establishing trust, it does provide a convenient means of
using trust, associating trust with public keys, and exploiting trust
information.
The basic structure is as follows. Each entry in the
public-key ring is a public- key certificate, as described in the preceding
subsection. Associated with each such entry is a key legitimacy field that indicates the extent to which PGP will trust that
this is a valid public key for this user; the higher the level of trust, the
stronger is the binding of this user ID to this key. This field is computed by PGP.
Also associated with the entry are zero or more signatures that the key
ring owner has collected that sign this certificate. In turn, each signature
has associated with it a signature trust field that indicates the degree to which this PGP user trusts
the signer to certify pub- lic keys. The key legitimacy field is derived from
the collection of signature trust fields in the entry. Finally, each entry defines a public key associated with a
particu- lar owner, and an owner trust field is included that indicates the degree to which this public key
is trusted to sign other public-key certificates; this level of
trust is assigned by the user. We can think of the signature trust
fields as cached copies of the owner
trust field from another entry.
The three fields mentioned in the previous paragraph are each
contained in a structure referred to as a trust flag byte. The content of this trust flag for each of
these three uses is shown in Table 18.2.
Suppose that we are dealing
with the public- key ring of user A. We can describe the operation of the trust
processing as follows.
1.
When A inserts a new
public key on the public-key ring, PGP must assign a value to the trust flag that is associated with the owner of this public key. If
the owner is A, and therefore this public key also appears in the private-key
ring, then a value of ultimate
trust is automatically assigned to the trust field.
Table
18.2 Contents
of Trust Flag Byte
Otherwise, PGP asks A for his assessment of
the trust to be assigned to the owner of this key, and A must enter the desired
level. The user can specify that this owner is unknown, untrusted, marginally
trusted, or completely trusted.
2.
When the new public key is entered,
one or more signatures may be attached to it.
More signatures may be added later. When a signature is inserted into the entry, PGP searches the public-key ring
to see if the author of this signature is among the known public-key owners. If so, the OWNERTRUST value for this owner is assigned
to the SIGTRUST field for this signature.
If not, an unknown user value is assigned.
3.
The value of the key legitimacy field is calculated on the basis of the signature
trust fields present in this entry. If
at least one signature has a signature trust value of ultimate, then the key legitimacy value is set to complete.
Otherwise, PGP computes a weighted sum of the trust values.
A weight of 1/X is given
to signatures that are always
trusted and 1/Y to signatures
that are usually trusted, where X and Y are user-configurable
parameters. When the total of weights of the introducers of a Key/UserID
combination reaches 1, the bind- ing is considered to be trustworthy, and the key legitimacy value is set to com- plete.
Thus, in the absence of ultimate trust, at least X signatures
that are always trusted, Y signatures that are usually trusted,
or some combination is needed.
Periodically, PGP processes the public-key ring to
achieve consistency. In essence,
this is a top-down process.
For each OWNERTRUST field, PGP scans the
ring for all signatures authored by that owner and updates the SIGTRUST field
to equal the OWNERTRUST field.
This process starts with keys for which there is ulti-
mate trust. Then all KEYLEGIT fields are computed on the basis of the attached
signatures.
Figure 18.7 provides an example of the way
in which signature trust and key
legitimacy are related.3 The figure shows the structure
of a public-key ring. The user has acquired a number of public
keys—some directly from their owners and some
from a third party such as a key server.
The node labeled
“You” refers to the entry in the public-key ring correspond- ing
to this user. This key is legitimate, and the OWNERTRUST value is ultimate
trust. Each other node in the key ring has an OWNERTRUST
value of undefined unless some other value is assigned by the user.
In this example, this user has speci- fied that it always trusts the following users to sign other keys: D, E, F, L. This user partially trusts users A and B to sign other keys.
So the shading, or lack thereof, of the
nodes in Figure 18.7 indicates the level
of trust assigned by this user. The tree structure indicates which keys
have been signed by which other users. If a key is signed by a user whose key
is also in this key ring, the arrow joins the signed key to the signatory. If
the key is signed by a user whose key is not present in this key ring, the
arrow joins the signed key to a question mark, indicating that the signatory is
unknown to this user.
Several points are illustrated in Figure
18.7.
1.
Note that all keys whose owners
are fully or partially trusted
by this user have
been signed by this user,
with the exception of node L. Such a user signature is not always necessary, as the presence
of node L indicates, but in practice,
most users are likely to sign the keys for most owners that they trust. So, for exam- ple, even though E’s key is already
signed by trusted introducer F, the
user chose to sign E’s key directly.
2.
We
assume
that two partially
trusted signatures are sufficient to certify a key. Hence, the key for user H is deemed
legitimate by PGP because it is signed by A
and B, both of whom are partially
trusted.
3.
A key may be
determined to be legitimate because it is signed by one fully trusted
or two partially trusted signatories, but its user may not be trusted
to sign other keys. For example,
N’s key is legitimate because it is signed by E, whom this user
trusts, but N is not trusted to sign other keys because this user has not assigned
N that trust value. Therefore, although R’s key is signed by N, PGP does not consider R’s key legitimate. This situation makes perfect sense. If you wish to
send a private message to some individual, it is not necessary
that you trust that individual in any respect. It is only necessary that you are sure that you have the correct public key
for that individual.
4.
Figure 18.7 also
shows an example of a detached “orphan” node S,
with two unknown signatures. Such a key may have been acquired from a
key server.
PGP cannot assume that this key is legitimate
simply because it came from a reputable server. The user must declare the key
legitimate by signing it or by telling PGP that it is willing to trust fully
one of the key’s signatories.
A final point: Earlier it was mentioned that
multiple user IDs may be associ- ated with a single public
key on the public-key ring.
This could be because
a person has changed
names or has been introduced via signature under
multiple names,
indi- cating different e-mail
addresses for the same person,
for example. So we can think of a public key as the root of a tree. A public key has a number of user IDs associating
with it, with a number
of signatures below
each user ID. The binding
of a particular user ID to a key depends on the signatures associated with that user ID and that key, whereas the level of trust in this key (for use in signing
other keys) is a function
of all the dependent signatures.
REVOKING PUBLIC KEYS A user may wish to revoke his or her current public key
either because compromise is suspected or simply to avoid the use of the same key for an
extended period. Note that a compromise would require that an opponent somehow had obtained a copy of your unencrypted private key or that the opponent
had obtained both the private
key from your private-key ring and your passphrase.
The convention for revoking a public key is for the owner to issue a key revo-
cation certificate, signed
by the owner. This certificate has the same form as a nor- mal
signature certificate but includes an indicator that the purpose
of this certificate is to revoke the use of this public key. Note that the corresponding private
key must be used to sign
a certificate that revokes a public key. The owner should then attempt to disseminate this certificate as widely and as quickly
as possible to enable
potential correspondents to update their
public-key rings.
Note that an opponent who has compromised the private key of an owner can also
issue such a certificate. However,
this would deny the opponent
as well as the
legitimate owner the use of the public key, and therefore, it seems a much less likely
threat than the malicious use of a stolen private
key.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2024 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.