Transcript Chapter 5

Chapter 7 – Electronic Mail Security
7.1 Pretty Good Privacy
Phil Zimmerman (MIT):
1. Selected best available cryptographic algorithms
(Table 7.1)
2. Integrated them into a general-purpose package
3. Made package and documentation readily available
(“Freeware,” June 1991)
4. Agreed for company to provide a commercial version
(Network Associates later let the agreement expire)
1
Growth of PGP
Reasons:
1. readily available free versions
2. algorithms have survived public scrutiny
and are considered extremely secure
3. wide range of applicability
(different key lengths)
4. no government involvement
(3-year criminal investigation under Arms Export
Control Act – abandoned in 1996 without indictment)
5. Internet Standard
(“OpenPGP,” RFCs 3156 and 4880 – November, 2007)
2
Using PGP to Authenticate the Sender
Recall figure 3.2(b) for digital signatures:
Alice
Bob
3
Alice
Bob
Alice
Bob
compression
Figure 7.1(a)
Decompression
There will be an extra step – radix-64 encoding
4
Unlike a physical signature, a digital signature does not need to be
attached to the document. Because of the properties of the hash
function, a given hash could apply to only one message (to a high
degree of confidence).
Although fig 7.1(a) shows the usual situation, with the signature
attached to the message, detached signatures are supported by PGP
These can be useful:
► to check that no changes (viruses, etc.)
have been made in an executable program
► when several people, possibly at different locations,
need to sign a document
Using PGP for confidentiality – next slide
5
Recall Figure 3.9(a)
for confidentiality:
Alice
Bob
Session key
not entire
message
Bob
Alice
Figure 7.1(b)
We discussed the basic idea in section 4.3 (page 116)
Compress before encryption
6
What if we want both confidentiality and authentication?
2 possibilities:
On sending side (Alice):
► encryption before digital signature (sign the ciphertext)
► digital signature before encryption (sign the plaintext)
On receiving side (Bob):
► with first option if Bob wanted to retain evidence that Alice sent
the message, he would have to retain the plaintext,
the ciphertext and the digital signature.
► with second option Bob would have to retain only the plaintext
and the digital signature.
Second option
Figure 7.1(c)
7
Similarly, we sign the uncompressed file, not the compressed file.
Compression:
8
9
E-mail compatibility - Radix-64 conversion:
10
Table 7.9 Radix-64 Encoding
11
Summary:
12
Table 7.1 Summary of PGP Services
13
Cryptographic Keys and Key Rings
PGP uses four types of key:
* one-time "session" (conventional) key
* public keys, private keys
* passphrase-based symmetric keys
Preview of Requirements:
1. Generate unpredictable session keys
(section “session key generation”)
2. Accommodate multiple public/private key-pairs
(section “key identifiers”)
3. File of own public/private key pairs and public keys
of correspondents (section “key rings”)
14
Session key generation
User types randomly into
buffer (lab session #1)
15
Key identifiers:
Users must be able to have multiple public/private key-pairs.
Sender (Alice) must be able to tell receiver (Bob)
which key-pair she is using.
How to identify?
Use least-significant 64 bits of public key (likely to be unique for user).
PGP message formats include the identifier of the key-pair being used.
16
Format of transmitted
message (assuming both
authentication and
confidentiality):
Sender Alice, receiver Bob
17
Format of
transmitted
message
Sequence of operations
during sending.
(continued):
Sequence during
receiving
18
Key rings:
“We have seen how key IDs are critical to the operation of PGP and that
two key IDs are included in any message that includes both authentication
and confidentiality.”
Recall figure 3.9(a):
19
Private key ring (“my” key-pairs)
information:
Private key stored
encrypted with
passphrase
“Private Key Ring”
also contains “my”
public keys
<[email protected]>
<[email protected]>
20
Procedure for encrypting the private keys:
1. User selects the passphrase to be used
2. When system generates a new public/private key-pair:
► it asks user for the passphrase
► using SHA-1, passphrase is hashed
► passphrase itself is then deleted (overwritten).
3. System encrypts private key using CAST-128 with 128 bits of
the hash as key;
► hash then deleted (overwritten).
Whenever the user wishes to use the private key,
(s)he must provide the passphrase.
21
Public key ring:
Defer
Defer discussion
The owner’s public key(s) appear on both key rings
22
How key rings are used by Alice in generating a message to Bob:
23
Bob receives the PGP message from Alice:
24
Public-key management
What if Darth creates his own public/private key-pair, then convinces
Alice that his (Darth’s) public key is Bob’s?
Darth can send messages to Alice, signed with his private key,
pretending they are from Bob.
When Alice checks signature, it will appear to be OK.
Similarly, if Alice sends an encrypted message to Bob, Darth can
intercept and read it (Bob cannot read it).
“The 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 software complexity is tied up
in solving this one problem.”
PGP does not require a rigid public-key management scheme.
In contrast, we shall see that S/MIME requires X.509 public-key certificates.
25
Approaches to Public-Key Management
How can Alice get Bob’s key and be sure it really is his?
1. Alice can physically meet Bob and receive his key on a USB drive.
2. If Alice can recognize Bob’s voice over the phone, she can ask him to
dictate his public key in radix-64 form (or he can e-mail the public key, Alice
can compute the hash and call Bob to confirm the hash).
3. Alice can obtain a signed copy of Bob’s public key from a mutuallytrusted friend (the “introducer”).
4. Alice can obtain Bob’s public key from a certificate issued by a CA (in this
case the CA serves as the introducer).
For cases 3 and 4, Alice would already have a copy
of the introducer’s public key and trust that this key is
valid. Ultimately, it is up to Alice to assign a degree of
trust to anyone who is to act as an introducer.
26
Use of Trust
PGP provides a convenient means of using trust.
Recall the public key ring:
Earlier, when Alice entered a new key in her public-key ring, PGP
asked her to assign a level of trust to the owner of this key (if it’s her
own public key, value is ultimate trust). This was entered in the
Owner Trust field and will be used if Alice later receives keys signed
by this person.
27
When Alice enters another new public key, one or more signatures may
be attached (in the Signature(s) field). Alice’s PGP will search her
public-key ring to see if the author of this signature is already on her key
ring. If so PGP will copy her earlier assessment of this person’s trust
into the Signature Trust field for this person (otherwise the value of this
field will be unknown user).
PGP will compute the weighted average of the Signature Trust values
and assign this to the Key Legitimacy field. This field summarized the
confidence that Alice can have that this public key actually belongs to
the person in the UserID field.
28
Possible values of the various trust fields.
Table 7.2 Contents of Trust Flag Byte
29
PGP “Web of Trust”
The idea behind the various trust fields in the public key ring is to
establish a “Web of Trust” among a community of users.
If Alice trusts only Abe to sign certificates, then she won’t believe
certificates from Martha or Emily are genuine. If she also trusts Bob’s
judgment about signing certificates, she can trust Emily’s certificate; if
she also trusts Carl, she can trust everyone’s certificate.
30
This may be OK for informal use, but clearly corporate use requires
something more formal – this led to the development of S/MIME, which
can be viewed as a formalization of PGP, requiring use of X.509
certificates.
31
7.2 S/MIME - preliminary material on RFC822/MIME
Recall from CS x34:
Internet E-mail standards were published in two parts in 1982:
RFC 822: STANDARD FOR THE FORMAT OF
ARPA INTERNET TEXT MESSAGES
by David H. Crocker
RFC 821: SIMPLE MAIL TRANSFER PROTOCOL
by Jonathan B. Postel
(Updated as RFC 2822 and 2821 (April, 2001))
Overview of E-mail:
The message is constructed under RFC 822, then
passed to SMTP (RFC 821) for transmission.
S/MIME includes a secure development of RFC 822/MIME
32
Message Formats
RFC 822 messages consist of lines of ASCII text, ending with <CR> <LF>
maximum 1000 characters
There are three sections:
■ header fields
■ a blank line (a line with nothing except <CR><LF>
■ optionally, the message body.
33
Headers
■ contain readable text (ASCII)
■ are divided into lines
■ each line of form <keyword> : <value>
Keywords To and From are required, others optional
34
RFC 822 states that the message can consist
only of ASCII text.
MIME – Multipurpose Internet Mail Extensions (RFC 1521, 1993)
In the body of the message we would like to be able to include items such as:
■ messages in languages with accents
■ Messages in non-Latin alphabets (Arabic, Russian, Hebrew)
■ Messages in languages without alphabets (Chinese and Japanese)
■ Messages not containing any kind of text (audio and video)
Such material may contain an arbitrary bit string.
Sender must “disguise” non-ASCII information as ASCII
This will be reversed by the receiver, to give the bit string.
35
From point of view of receiver:
If you receive this ASCII message how do you know what it is?
MIME header to the rescue!
Example: Content-Transfer-Encoding says “radix-64 conversion”
Now you know that the message is a bit string that the sender has
converted to radix-64 – you can recover the bit string, but you still don’t
know what it is (image? Audio?)
MIME header: Content-Type says “image/jpeg”
which tells you how to process the received message.
36
37
S/MIME will add new subtypes to Application and Multipart
38
39
End of preliminary material on MIME.
Recall that with PGP we had ability to:
► encrypt data for confidentiality
► digitally-sign data for authentication
► do both together
S/MIME has equivalent functionality.
40
S/MIME Functionality
► Enveloped data: encrypted content and encryption keys
(can be interpreted only by recipient with S/MIME capability,
because it uses a new S/MIME content/subtype – p252)
► Signed data: message plus digital signature
(can be interpreted only by recipient with S/MIME capability,
because it uses a new S/MIME content/subtype)
► Clear-signed data: message ASCII only, signature radix-64
(recipients without S/MIME can view message, but
cannot verify the signature – it uses a new S/MIME
content/subtype)
► Signed and enveloped data: nested entities as in PGP
41
S/MIME Functionality - continued
► Enveloped data: encrypted content plus encryption keys
PGP equivalent: Figure 7.1(b) plus radix-64 conversion
Radix-64
conversion
42
S/MIME Functionality - continued
► Signed data: message plus digital signature
(can be viewed only by recipient with S/MIME capability)
PGP equivalent: figure 7.1(a), plus radix-64 conversion
Radix-64 conversion
after compression
► Clear-signed data function: only the digital signature is
converted to radix-64; the message is “in the clear”
43
S/MIME Functionality - continued
► Signed and enveloped data
PGP equivalent: figure 7.1(c)
44
Table 7.6 Cryptographic Algorithms Used in S/MIME
(El Gamal)
Sending
45
S/MIME Messages
S/MIME makes use of a number of new MIME subtypes. Most of the
new subtypes use the designation PKCS – “public key cryptographic
specifications” issued by RSA Labs and contributed to the S/MIME
effort.
Table 7.7 S/MIME Content Types
MIME
S/MIME
*
*
*
*
To participate fully in S/MIME, sender and receiver
must understand the new S/MIME subtypes
46
EnvelopedData - preliminary
Recall PGP figure 7.1(b) – sending side:
47
envelopedData
In preparing this, the sender:
1. Generates a pseudorandom session key Ks for the chosen
symmetric encryption algorithm.
2. For each recipient, encrypts the session key with the
recipient’s public RSA key PUb
3. For each recipient prepares the RecipientInfo block that contains
► an identifier of the recipient’s public-key certificate
► an identifier of the algorithm used to encrypt the session key
► the encrypted session key
4. Encrypts the message content with the session key.
48
RecipientInfo/
Identifier of
recipient’s publickey certificate:
Identifier
This will be taken
from an X.509
certificate.
49
50
51
Again recall PGP figure 7.1(b) - receiving side:
To recover the encrypted message, the PGP recipient:
1. Strips off the radix-64 conversion (not shown above);
2. Uses his/her private key to decrypt the session key;
3. Decrypts the message, using the session key.
S/MIME receiver does same things (top page 253)
52
signedData – preliminary:
Recall PGP figure 7.1(a) – sending side:
53
signedData
Similarly, the steps for preparing a signedData MIME entity are:
1. Select a message digest algorithm (SHA or MD5);
2. Compute the message digest of the content to be signed;
3. Encrypt the message digest with the signer’s private key PRa ;
4. Prepare the SignerInfo block, containing:
► the signer’s public-key certificate; (? Identifier?)
► an identifier of the message digest algorithm;
► an identifier of the algorithm used to encrypt
the message digest;
► the encrypted message digest.
54
signedData - continued
55
signedData - continued
For receiver, first task is to reverse the base64 encoding
56
SignedData – continued
Recall PGP figure 7.1(a) – receiving side:
To recover the signed message, and verify the signature,
the PGP recipient:
1. Strips off the base64 conversion (not shown above);
2. Uses the signer’s public key to decrypt the message digest;
3. Recomputes the message digest to verify the signature.
Again, the S/MIME recipient does the same things (page 253).
57
S/MIME Functionality: Clear-signed Data
The message is sent as a MIME multipart message, with the text “in the
clear” in the first part and the signature in the second part – this is a
detached signature.
Recipients without S/MIME capability can view message,
but cannot verify the signature.
58
The second part is a detached signature
59
S/MIME Certificate Processing
S/MIME uses X.509 version 3
“Hybrid between a strict X.509 hierarchy and PGP’s web of trust.”
S/MIME does not set up a global system like the Domain Name System,
to retrieve public-key certificates with minimal effort.
Rather, each user, or user group, takes responsibility for obtaining the
certificates of individuals with whom they want to correspond securely.
User Agent Role
► key-pair generation
► registration of public key with a CA,
which will issue X.509 certificate
(figure 4.4)
► certificate storage and retrieval
(equivalent of PGP public key ring)
60
VeriSign Public-Key Certificate Classes
Table 7.8 Verisign Public-Key Certificate Classes
61
Omit Section 7.3 Domainkeys Identified Mail
End of Chapter 7
62