E-mail Security

1. E-mail Security • Introduction to E-mail • Privacy Enhanced Mail (PEM) • The Certification System • Pretty Good Privacy (PGP) • 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) • Fast • Easy to distribute • Inexpensive • Modern e-mail messages can include hyperlinks, HTML formatted text, images, sound, and even video • Accessible from any host connected to the Internet

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

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

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

6. S: 220 hamburger.edu C: HELO crepes.fr S: 250 Hello crepes.fr, pleased to meet you C: MAIL FROM: <alice@crepes.fr> S: 250 alice@crepes.fr… Sender ok C: RCPT TO: <bob@hamburger.edu> 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 Example to SMTP • a client C, which its host name is crepes.fr • a server S, which its host name is hamburger.edu

7. Header Format • Defined in RFC 822 • 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 • 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

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 • Include additional headers in the message, which are defined in RFC 2045/2046 • 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 • In particular, security mechanisms to provide data confidentiality, authenticity, integrity and non-repudiation were missing • E-mail service is asynchronous • All the regular security protocols (such as IPSEC, SSL, etc.) are synchronous • PEM, S/MIME and PGP come to help • 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 ? • 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)

12. Privacy Enhanced Mail (PEM) Introduction • 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) • Defined in RFCs 1421/1422/1423/1424 • Consists of extensions to existing message processing software plus a key management infrastructure

13. PEM Security Services • Integrity, which ensures a message recipient that the message has not been modified en route. • Authenticity, which ensures a message recipient that a message was sent by the indicated originator. • Non-repudiation, which allows a message to be forwarded to a third party, who can verify the identity of the originator. • 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 • Transparent to SMTP mail relays • 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

15. PEM Overview (contd.) • The use of X.509 certificates is the base for public key management in PEM • 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)

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

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

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

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 . • The shortcoming is that it restricts the input to 7-bit ASCII . • 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 . • 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 .

21. PEM Message Processing – Step 3 • 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. • 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 . • MIC-ONLY is a signed , but not encrypted, encoded message . • 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.

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 Standard RFC 822 Header Version & type Conforms to Msg encryption params (for example, IV) Originator certificate Issuer certificate

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

25. PEM Message Delivery Processing (1) • Recipient receives a PEM message • 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 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 certificates • 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

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

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

30. The Internet Certification System (2) • 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 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 • CAs can issue certificates to (subordinate) CAs or directly to users

31. Example to a Typical Internet Certification Hierarchy IPRA High assurance Residential Mid-level assurance Persona BBN Louisiana New York MIT HUJI Persona User BBNCD New Orleans User User LCS User User User User User User User User User User User User

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 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 • Problem : PEM does not support security services to multimedia files (MIME)

33. Next : Pretty Good Privacy