1. E-mail Security Introduction to E-mail Introduction to E-mail Privacy Enhanced Mail (PEM) Privacy Enhanced Mail (PEM) The Certification System The Certification System Pretty Good Privacy (PGP) Pretty Good Privacy (PGP) Secure Multipurpose Internet Mail Extensions (S/MIME) Secure Multipurpose Internet Mail Extensions (S/MIME)

2. Introduction to E-mail E-mail is one of the most popular Internet applications Asynchronous (=> no session => no handshaking) Asynchronous (=> no session => no handshaking) Fast Fast Easy to distribute Easy to distribute Inexpensive Inexpensive Modern e-mail messages can include hyperlinks, HTML formatted text, images, sound, and even video Modern e-mail messages can include hyperlinks, HTML formatted text, images, sound, and even video Accessible from any host connected to the Internet Accessible from any host connected to the Internet

3. A Typical E-mail Journey 1.Starts its journey in the sender’s user agent 2.Travels to the sender’s mail server 3.Then travels to the recipient’s mail server 4.Deposited in the recipient’s mailbox 5.The recipient wants to access the messages in his mailbox 6.The mail server containing his mailbox authenticates him (with user name and password) 7.Then sends the message to the recipient’s user agent

4. Existing E-Mail System Intermediate relay pointRecipient’s mailbox host User agent Editor Mail transfer Agent (SMTP) Originator at a multiuser host User agent Recipient at a workstation Mail transfer Agent (SMTP relay) Mail transfer Agent (SMTP) SMTP (RFC 821) SMTP (RFC 821) Retrieval (e.g. POP3)

5. The Simple Mail Transfer Protocol (SMTP) Defined in RFC 821 (dates back to 1982 ) Defined in RFC 821 (dates back to 1982 ) The principal application-layer protocol for the internet electronic mail The principal application-layer protocol for the internet electronic mail Uses the reliable data transfer service of TCP at port 25 Uses the reliable data transfer service of TCP at port 25 Possess certain “archaic” characteristics (such as the 7-bit ASCII restriction) Possess certain “archaic” characteristics (such as the 7-bit ASCII restriction)

6. Example to SMTP S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: C: MAIL FROM: S: 250 alice@crepes.fr… Sender ok C: RCPT TO: C: RCPT TO: S: 250 bob@hamburger.edu… Recipient ok C: DATA S: 354 Enter mail, end with “.” on a line by itself C: Do you like ketchup? C:. S: 250 Message accepted for delivery C: QUIT S: 221 hamurger.edu closing connection a client C, which its host name is crepes.fr a client C, which its host name is crepes.fr a server S, which its host name is hamburger.edu a server S, which its host name is hamburger.edu

7. Header Format Defined in RFC 822 Defined in RFC 822 Headers containing peripheral information precedes the body of the message itself Headers containing peripheral information precedes the body of the message itself Specifies the exact format for mail header lines as well as their semantic interpretations Specifies the exact format for mail header lines as well as their semantic interpretations After the message header, a blank line follows, then the message body in ASCII follows After the message header, a blank line follows, then the message body in ASCII follows The message terminates with a line containing only a period The message terminates with a line containing only a period

8. Example to E-mail Message From: alice@cs.huji.ac.il To: bob@cs.huji.ac.il Subject: Mail header format Message body (in ASCII).

9. Multipurpose Internet Mail Extensions (MIME) RFC 822 is not sufficiently rich enough for multimedia messages RFC 822 is not sufficiently rich enough for multimedia messages Include additional headers in the message, which are defined in RFC 2045/2046 Include additional headers in the message, which are defined in RFC 2045/2046 This topic will be addressed later in the S/MIME section This topic will be addressed later in the S/MIME section

10. The Security Issue (1) Initial specification of internet e-mail did not address security issues Initial specification of internet e-mail did not address security issues In particular, security mechanisms to provide data confidentiality, authenticity, integrity and non-repudiation were missing In particular, security mechanisms to provide data confidentiality, authenticity, integrity and non-repudiation were missing E-mail service is asynchronous E-mail service is asynchronous All the regular security protocols (such as IPSEC, SSL, etc.) are synchronous All the regular security protocols (such as IPSEC, SSL, etc.) are synchronous PEM, S/MIME and PGP come to help PEM, S/MIME and PGP come to help Each message is a one-time independent event with its own one-time symmetric key Each message is a one-time independent event with its own one-time symmetric key

11. The Security Issue (2) Why not simply use the regular synchronous security protocols to protect the message while en route between intermediate stations ? Why not simply use the regular synchronous security protocols to protect the message while en route between intermediate stations ? Security services should be added between the two end users (no exposure in the middle) Security services should be added between the two end users (no exposure in the middle) The secure services were build on an existing mail system (SMTP mail servers) The secure services were build on an existing mail system (SMTP mail servers)

12. Privacy Enhanced Mail (PEM) Introduction Primary goal of PEM is to add security services for e-mail users in the internet community Primary goal of PEM is to add security services for e-mail users in the internet community Began in 1985 as an activity of the Privacy and Security Research Group (PSRG) Began in 1985 as an activity of the Privacy and Security Research Group (PSRG) Defined in RFCs 1421/1422/1423/1424 Defined in RFCs 1421/1422/1423/1424 Consists of extensions to existing message processing software plus a key management infrastructure Consists of extensions to existing message processing software plus a key management infrastructure

13. PEM Security Services 1. Integrity, which ensures a message recipient that the message has not been modified en route. 2. Authenticity, which ensures a message recipient that a message was sent by the indicated originator. 3. Non-repudiation, which allows a message to be forwarded to a third party, who can verify the identity of the originator. 4. Confidentiality (optional), which ensures a message originator that the message text will be disclosed only to the designated recipients.

14. PEM Overview Compatible with RFC 822 message processing conventions Compatible with RFC 822 message processing conventions Transparent to SMTP mail relays Transparent to SMTP mail relays Uses symmetric cryptography to provide (optional) encryption of messages Uses symmetric cryptography to provide (optional) encryption of messages The RFCs strongly recommend the use of asymmetric cryptography (for digital signatures, certificates and encryption of the symmetric key) because of its ability to support vast distributed community of users The RFCs strongly recommend the use of asymmetric cryptography (for digital signatures, certificates and encryption of the symmetric key) because of its ability to support vast distributed community of users

15. PEM Overview (contd.) The use of X.509 certificates is the base for public key management in PEM The use of X.509 certificates is the base for public key management in PEM This certification hierarchy supports universal authentication of PEM users This certification hierarchy supports universal authentication of PEM users PEM can be used in a wider range of messaging environments (other than RFC 822 and SMTP) PEM can be used in a wider range of messaging environments (other than RFC 822 and SMTP)

16. Integration Of PEM Into Existing Mail System Intermediate relay pointRecipient’s mailbox host User agent Editor Mail transfer Agent (SMTP) Originator at a multiuser host User agent Recipient at a workstation Mail transfer Agent (SMTP relay) Mail transfer Agent (SMTP) SMTP (RFC 821) SMTP (RFC 821) Retrieval (e.g. POP3) PEM filter PEM module

17. PEM Message Submission: Message Processing Begin privacy enhanced message End privacy enhanced message Encapsulated header: Contains authentication, integrity, and (optional) encryption control fields and related information Blank line Encapsulated text: (Encrypted) User message text and optional Replicated header fields User provides recipient address and other data (e.g. “Subject”) for enclosing header User provides address information needed to perform encryption Plaintext of user message requiring privacy enhancement Enclosing header RFC 822 header fields Encapsulated message All data between the privacy enhanced message boundaries is represented here, and may be interspersed with unprotected plaintext

18. PEM Message Processing Plaintext message “SMTP” canonicalization MIC calculation and (optional) encryption 6-bit encoding and line length limiting Processed message Step 1 Step 2 Step 3

19. PEM Message Processing – Step 1 Uses the canonicalization specified by SMTP to ensure a uniform presentation syntax among a heterogeneous collection of computer systems. Uses the canonicalization specified by SMTP to ensure a uniform presentation syntax among a heterogeneous collection of computer systems. The shortcoming is that it restricts the input to 7-bit ASCII. The shortcoming is that it restricts the input to 7-bit ASCII. The reason is that the Internet e-mail imposes the same restrictions. The reason is that the Internet e-mail imposes the same restrictions.

20. PEM Message Processing – Step 2 A MIC is calculated over the canonicalized message to permit uniform verification in the heterogeneous environments. A MIC is calculated over the canonicalized message to permit uniform verification in the heterogeneous environments. The canonical (padded as required) message text is then (optionally) encrypted using a per- message symmetric key. The canonical (padded as required) message text is then (optionally) encrypted using a per- message symmetric key. The encryption action is performed only if the message is of type ENCRYPTED. The encryption action is performed only if the message is of type ENCRYPTED.

21. PEM Message Processing – Step 3 Renders an ENCRYPTED or MIC-ONLY message into a printable form suitable for transmission via SMTP. Renders an ENCRYPTED or MIC-ONLY message into a printable form suitable for transmission via SMTP. This encoding step transforms the (optionally encrypted) message text into a restricted 6-bit alphabet. This encoding step transforms the (optionally encrypted) message text into a restricted 6-bit alphabet. A MIC-CLEAR messages are not subject to any portion of the third processing step. A MIC-CLEAR messages are not subject to any portion of the third processing step.

22. PEM Message Types ENCRYPTED is a signed, encrypted and encoded (in step 3) message. ENCRYPTED is a signed, encrypted and encoded (in step 3) message. MIC-ONLY is a signed, but not encrypted, encoded message. MIC-ONLY is a signed, but not encrypted, encoded message. MIC-CLEAR is a signed, but not encrypted, and message that is not encoded. MIC-CLEAR is a signed, but not encrypted, and message that is not encoded. Specially so it can be sent to a mixed set of recipients, some of whom use PEM and some do not. Specially so it can be sent to a mixed set of recipients, some of whom use PEM and some do not.

23. PEM Message Submission: Header Construction (1) From: alice@cs.huji.ac.il To: bob@cs.huji.ac.il Subject: Encrypted PEM message ------------BEGIN PRIVACY-ENHANCED MESSAGE-------- Proc-Type: 4, ENCRYPTED Content-Domain: RFC822 DEK-Info: DES-CBC, BGFA799HTS347KGKL0 Originator-Certificate: 3yhtrwhhj57jw5jw6w7u6juj6uu45yjj5645w4y4y5yqy Issuer-Certificate: Eth46u5kw57kwuw3jwjw465iw6uw57uw6u4q6jj6646 Version & type Standard RFC 822 Header Conforms to Msg encryption params (for example, IV) Originator certificate Issuer certificate

24. PEM Message Submission: Header Construction (2) MIC-Info: RSA-MD5, RSA, Sdhdsh453hwe5yyh5ywjuhs5yahhaehjue78iok67k Recipient-ID-Asymmetric: Agw56ywjq45y2jqhj4yuq4hjq4yq3yy3yewghew5y3 Key-Info: RSA, Adshw45w5j7w57j5u46yu5yq46ju46juqyuq4u5y35hj Dfghj56er656uw6u64uu45yw46u5wjwu5i56u57i5wuiw5u W46uw56uueueri5u6w56uw46u5wu56uw56u56u5 ------------END PRIVACY-ENHANCED MESSAGE------ Digital signature MIC & Dig.Sig algo Recipient’s id Public key algo Encrypted message key Encrypted message Blank line

25. PEM Message Delivery Processing (1) Recipient receives a PEM message Recipient receives a PEM message Scans the PEM header for the version and the type (ENCRYPTED, MIC-ONLY, MIC-CLEAR) Scans the PEM header for the version and the type (ENCRYPTED, MIC-ONLY, MIC-CLEAR) If ENCRYPTED or MIC-ONLY then decode the 6-bit encoding back to ciphertext or canonical plaintext form If ENCRYPTED or MIC-ONLY then decode the 6-bit encoding back to ciphertext or canonical plaintext form If ENCRYPTED then decrypt the symmetric message key using the private component of his public key pair and decrypt the message using the symmetric message keyIf ENCRYPTED then decrypt the symmetric message key using the private component of his public key pair and decrypt the message using the symmetric message key

26. PEM Message Delivery Processing (2) Validate the public key of the sender by validating a chain of certificatesValidate the public key of the sender by validating a chain of certificates Validate the digital signature using the public component of the public key of the sender Validate the digital signature using the public component of the public key of the sender The canonical form is translated into the local representation and presented to the recipient The canonical form is translated into the local representation and presented to the recipient

27. The Certification System A public key X.509 certificate is a digitally signed data structure used to securely bind a public key to a name and to specify who vouches for the binding A public key X.509 certificate is a digitally signed data structure used to securely bind a public key to a name and to specify who vouches for the binding The signature to the certificate applied by the issuer using the private component of his public key pair and appended after the certificate fields The signature to the certificate applied by the issuer using the private component of his public key pair and appended after the certificate fields One validates a certificate by computing the one- way hash function over the certificate, uses the public key of the issuer to decrypt the value in the appended signature and compare the two resulting values One validates a certificate by computing the one- way hash function over the certificate, uses the public key of the issuer to decrypt the value in the appended signature and compare the two resulting values

28. X.509 Certificate Certificate: = SIGNED SEQUENCE { version[0] Version DEFAULT v1988, serialNumber CertificateSerialNumber, signature AlgorithmIdentifier, issuer Name, validity Validity, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo } Uniquely identifies this certificate Dig.sig & hash func algo & params Issuer ID Start & end valid times Subject name Public key of the subject, algo ID & params

29. The Internet Certification System (1) The user need to possess the public key of the issuer of the certificate in order to validate the certificate The user need to possess the public key of the issuer of the certificate in order to validate the certificate The issuer will also have a certificate, and thus the process of certificate validation is recursive and implicitly defines a directed certification graph The issuer will also have a certificate, and thus the process of certificate validation is recursive and implicitly defines a directed certification graph X.509 defines defines a Certification Authority (CA) as “an authority trusted by one or more users to create and assign certificates” X.509 defines defines a Certification Authority (CA) as “an authority trusted by one or more users to create and assign certificates”

30. The Internet Certification System (2) Different CAs can issue certificates under different policies, for example, varying degrees of assurance in vouching for certificates Different CAs can issue certificates under different policies, for example, varying degrees of assurance in vouching for certificates The root of the certification graph is the Internet PCA Registration Authority (IPRA) The root of the certification graph is the Internet PCA Registration Authority (IPRA) The IPRA is a reference point from which all certificates can be validated The IPRA is a reference point from which all certificates can be validated The IPRA issues certificates to a second layer of entities called Policy Certification Authorities (PCA), which, in turn, issue certificates to CAs The IPRA issues certificates to a second layer of entities called Policy Certification Authorities (PCA), which, in turn, issue certificates to CAs CAs can issue certificates to (subordinate) CAs or directly to users CAs can issue certificates to (subordinate) CAs or directly to users

31. Example to a Typical Internet Certification Hierarchy IPRA High assurance ResidentialMid-level assurance Persona BBNLouisianaNew YorkMITHUJIPersona UserBBNCDNew OrleansUser LCSUser

32. PEM Summery PEM represents a major effort to provide security for an application that touches a vast number of users within the Internet and beyond PEM represents a major effort to provide security for an application that touches a vast number of users within the Internet and beyond PEM was designed to have backward compatibility with existing mail system PEM was designed to have backward compatibility with existing mail system PEM depends on a successful establishment of the certification hierarchy that underlies asymmetric key management PEM depends on a successful establishment of the certification hierarchy that underlies asymmetric key management Problem : PEM does not support security services to multimedia files (MIME) Problem : PEM does not support security services to multimedia files (MIME)

33. Next : Pretty Good Privacy