1 / 62

7.1 Pretty Good Privacy Phil Zimmerman (MIT):

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

alexandra-morton
Download Presentation

7.1 Pretty Good Privacy Phil Zimmerman (MIT):

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  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. Alice Bob Alice Bob compression Figure 7.1(a) Decompression There will be an extra step – radix-64 encoding

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

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

  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. Second option Figure 7.1(c)

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

  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/privatekey-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. Sender Alice, receiver Bob Format of transmitted message (assuming both authentication and confidentiality):

  17. Sequence of operations during sending. Format of transmitted message (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 <barnard@cis.uab.edu> <barnard@uab.edu>

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

  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. S/MIME will add new subtypes to Application and Multipart

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

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

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

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

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

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

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

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

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

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

More Related