7.1 Pretty Good Privacy Phil Zimmerman (MIT):

1

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)

Chapter 7 – Electronic Mail Security

2

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)

3

Using PGP to Authenticate the Sender

Recall figure 3.2(b) for digital signatures:

Alice Bob

4

Figure 7.1(a)

Alice Bob

Alice Bob

compression

Decompression

There will be an extra step – radix-64 encoding

5

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

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

Using PGP for confidentiality – next slide

6

Recall Figure 3.9(a) for confidentiality:

BobAlice

Alice Bob

Figure 7.1(b)We discussed the basic idea in section 4.3 (page 116)

Compress before encryption

Session key not entire message

7

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.

Figure 7.1(c)

Second option

8

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

Compression:

9

10

E-mail compatibility - Radix-64 conversion:

11

Table 7.9 Radix-64 Encoding

12

Summary:

13

Table 7.1 Summary of PGP Services

14

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

15

Session key generation

User types randomly into buffer (lab session #1)

16

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.

17

Format of transmitted message (assuming both authentication and confidentiality):

Sender Alice, receiver Bob

18

Format of transmitted message

(continued):

Sequence of operations during sending.

Sequence during receiving

19

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

20

Private key ring (“my” key-pairs)

information:

Private key stored encrypted with

passphrase

<barnard@cis.uab.edu>

<barnard@uab.edu>

“Private Key Ring” also contains “my” public keys

21

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.

22

Public key ring:

Defer discussionDefer

The owner’s public key(s) appear on both key rings

23

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

24

Bob receives the PGP message from Alice:

25

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?

“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.

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

26

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.

27

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.

28

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.

29

Possible values of the various trust fields.

Table 7.2 Contents of Trust Flag Byte

30

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.

31

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.

32

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.

7.2 S/MIME - preliminary material on RFC822/MIME

S/MIME includes a secure development of RFC 822/MIME

33

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.

34

Headers

■ contain readable text (ASCII)

■ are divided into lines

■ each line of form <keyword> : <value>

Keywords To and From are required, others optional

35

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.

RFC 822 states that the message can consist only of ASCII text.

36

If you receive this ASCII message how do you know what it is?

MIME header to the rescue!

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.

From point of view of receiver:

Example: Content-Transfer-Encoding says “radix-64 conversion”

37

38S/MIME will add new subtypes to Application and Multipart

39

40

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.

41

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

42

S/MIME Functionality - continued

► Enveloped data: encrypted content plus encryption keys

PGP equivalent: Figure 7.1(b) plus radix-64 conversion

Radix-64 conversion

43

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”

44

S/MIME Functionality - continued

► Signed and enveloped data

PGP equivalent: figure 7.1(c)

45

(El Gamal)

Sending

Table 7.6 Cryptographic Algorithms Used in S/MIME

46

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.

MIME S/MIME

**

*

*

Table 7.7 S/MIME Content Types

To participate fully in S/MIME, sender and receiver must understand the new S/MIME subtypes

47

EnvelopedData - preliminary

Recall PGP figure 7.1(b) – sending side:

48

envelopedData

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.

In preparing this, the sender:

49

RecipientInfo/ Identifier of recipient’s public-key certificate:

Identifier

This will be taken from an X.509 certificate.

50

51

52

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.

Again recall PGP figure 7.1(b) - receiving side:

S/MIME receiver does same things (top page 253)

53

signedData – preliminary:

Recall PGP figure 7.1(a) – sending side:

54

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

55

signedData - continued

56

signedData - continued

For receiver, first task is to reverse the base64 encoding

57

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

58

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.

59The second part is a detached signature

60

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)

61

VeriSign Public-Key Certificate Classes

Table 7.8 Verisign Public-Key Certificate Classes

62

End of Chapter 7

Omit Section 7.3 Domainkeys Identified Mail