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)

Growth of PGP 1. readily available free versions 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)

Using PGP to Authenticate the Sender Recall figure 3.2(b) for digital signatures: Alice Bob

There will be an extra step – radix-64 encoding Alice Bob Alice Bob compression Figure 7.1(a) Decompression There will be an extra step – radix-64 encoding

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

Session key not entire message Recall Figure 3.9(a) for confidentiality: Alice Bob Session key not entire message Alice Bob We discussed the basic idea in section 4.3 (page 116) Figure 7.1(b) Compress before encryption

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)

Similarly, we sign the uncompressed file, not the compressed file. Compression:

E-mail compatibility - Radix-64 conversion:

Table 7.9 Radix-64 Encoding

Summary:

Table 7.1 Summary of PGP Services

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”)

Session key generation User types randomly into buffer (lab session #1)

PGP message formats include the identifier of the key-pair being used. 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.

Sender Alice, receiver Bob Format of transmitted message (assuming both authentication and confidentiality):

Sequence of operations during sending. Format of transmitted message (continued): Sequence during receiving

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):

Private key stored encrypted with passphrase Private key ring (“my” key-pairs) information: Private key stored encrypted with passphrase “Private Key Ring” also contains “my” public keys <barnard@cis.uab.edu> <barnard@uab.edu>

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.

Public key ring: Defer Defer discussion The owner’s public key(s) appear on both key rings

How key rings are used by Alice in generating a message to Bob:

Bob receives the PGP message from Alice:

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.

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 mutually- trusted 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.

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.

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.

Possible values of the various trust fields. Table 7.2 Contents of Trust Flag Byte

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.

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.

S/MIME includes a secure development of RFC 822/MIME 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

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.

Headers ■ contain readable text (ASCII) ■ are divided into lines ■ each line of form <keyword> : <value> Keywords To and From are required, others optional

Sender must “disguise” non-ASCII information as ASCII 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.

MIME header to the rescue! 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.

S/MIME will add new subtypes to Application and Multipart

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.

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

S/MIME Functionality - continued ► Enveloped data: encrypted content plus encryption keys PGP equivalent: Figure 7.1(b) plus radix-64 conversion Radix-64 conversion

Radix-64 conversion after compression 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”

S/MIME Functionality - continued ► Signed and enveloped data PGP equivalent: figure 7.1(c)

Table 7.6 Cryptographic Algorithms Used in S/MIME (El Gamal) Sending

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

EnvelopedData - preliminary Recall PGP figure 7.1(b) – sending side:

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.

RecipientInfo/ Identifier of recipient’s public-key certificate: This will be taken from an X.509 certificate.

S/MIME receiver does same things (top page 253) 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)

signedData – preliminary: Recall PGP figure 7.1(a) – sending side:

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.

signedData - continued

For receiver, first task is to reverse the base64 encoding signedData - continued For receiver, first task is to reverse the base64 encoding

Again, the S/MIME recipient does the same things (page 253). 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).

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.

The second part is a detached signature

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)

VeriSign Public-Key Certificate Classes Table 7.8 Verisign Public-Key Certificate Classes

Omit Section 7.3 Domainkeys Identified Mail End of Chapter 7