1. 1 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. preliminary material on RFC822/MIME Chapter 7 – Electronic Mail Security

2. 2 Message Formats RFC 822 messages consist of lines of ASCII text, ending with maximum 1000 characters There are three sections: ■ header fields ■ a blank line (a line with nothing except ■ optionally, the message body.

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

4. 4 MIME – Multipurpose Internet Mail Extensions (RFC 1341, 1992) 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) ■ Encrypted messages/digital signatures 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 821 (SMTP) states that the message can consist only of 7-bit ASCII text (high order bit must be zero)

5. 5 E-mail compatibility - Radix-64 conversion:

6. 6 Table 7.9 Radix-64 Encoding

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

8. 8

9. 9 PGP and S/MIME will add new subtypes to Application and Multipart

10. 10 End of preliminary material on RFC822/MIME

11. 11 7.1 Pretty Good Privacy (1991) 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

12. 12 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, 2001)

13. 13 Using PGP to Authenticate the Sender Recall figure 3.2(b) for digital signatures: AliceBob

14. 14 Figure 7.1(a) Alice Bob AliceBob compression Decompression If sent by e-mail there will be an extra step – radix-64 encoding

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

16. 16 Recall Figure 3.9(a) for confidentiality: Bob 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

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

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

19. 19

20. 20 Summary: File can be e-mailed

21. 21 PGP Zimmerman 1991 MIME RFC 1341 1992 MIME PGP subtypes RFC 2015 1996 OpenPGP RFC 3156 2001 PGP and E-mail

22. 22 From Elkins, RFC 2015 Mime-Version: 1.0 Content-Type: multipart/signed; boundary=bar; micalg=pgp-md5; protocol="application/pgp-signature" --bar Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable --bar Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXI X/LC//jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC 3C041WGquMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhd folT9BrnHOxEa44b+EI= =ndaj -----END PGP MESSAGE----- --bar--

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

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

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

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

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

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

29. 29 Private key ring (“my” key-pairs) information: Private key stored encrypted with passphrase “Private Key Ring” also contains “my” public keys

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

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

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

33. 33 Bob receives the PGP message from Alice:

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

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

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

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

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

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

40. 40 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. 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. 42 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. MIMES/MIME * * * * Table 7.7 S/MIME Content Types To participate fully in S/MIME, sender and receiver must understand the new S/MIME subtypes

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

44. 44 envelopedData 1. Generates a pseudorandom session key K s for the chosen symmetric encryption algorithm. 2. For each recipient, encrypts the session key with the recipient’s public RSA key PU b 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. Similarly S/MIME: In preparing envelopedData, the sender : Recall PGP:

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

46. 46

47. 47

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

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

50. 50 Similarly, the steps for preparing a signedData S/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 PR a ; 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 PGP:

51. 51 signedData - continued

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

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

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

55. 55 The second part is a detached signature

56. 56 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.3) ► certificate storage and retrieval (equivalent of PGP public key ring)

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

58. 58 End of Chapter 7 Omit Section 7.3 Domainkeys Identified Mail