Email Security Introduction to Email n Privacy Enhanced

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

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

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

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

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

S: 220 hamburger. edu C: HELO crepes. fr Example to SMTP 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 • a client C, which its host name is crepes. fr • a server S, which its host name is hamburger. edu

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

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

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

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

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

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

PEM Security Services 1. 2. 3. 4. 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.

PEM Overview Compatible with RFC 822 message processing conventions n Transparent to SMTP mail relays n Uses symmetric cryptography to provide (optional) encryption of messages n 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 n

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

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

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 Plaintext of user message requiring privacy enhancement Begin 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 End privacy enhanced message 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

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

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

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

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

PEM Message Types ENCRYPTED is a signed, encrypted and encoded (in step 3) message. n MIC-ONLY is a signed , but not encrypted, encoded message. n 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. n

PEM Message Submission: Header Construction (1) From: alice@cs. huji. ac. il To: bob@cs. huji. ac. il Subject: Encrypted PEM message Standard RFC 822 Header ----------BEGIN PRIVACY-ENHANCED MESSAGE Proc-Type: 4, ENCRYPTED Version & type Content-Domain: RFC 822 Conforms to DEK-Info: DES-CBC, BGFA 799 HTS 347 KGKL 0 Msg encryption params Originator-Certificate: (for example, IV) 3 yhtrwhhj 57 jw 5 jw 6 w 7 u 6 juj 6 uu 45 yjj 5645 w 4 y 4 y 5 yqy Originator certificate Issuer-Certificate: Eth 46 u 5 kw 57 kwuw 3 jwjw 465 iw 6 uw 57 uw 6 u 4 q 6 jj 6646 Issuer certificate

PEM Message Submission: Header Construction (2) MIC-Info: RSA-MD 5, RSA, MIC & Dig. Sig algo Sdhdsh 453 hwe 5 yyh 5 ywjuhs 5 yahhaehjue 78 iok 67 k Digital signature Recipient-ID-Asymmetric: Agw 56 ywjq 45 y 2 jqhj 4 yuq 4 hjq 4 yq 3 yy 3 yewghew 5 y 3 Recipient’s id Key-Info: RSA, Public key algo Adshw 45 w 5 j 7 w 57 j 5 u 46 yu 5 yq 46 juqyuq 4 u 5 y 35 hj Encrypted message key Blank line Dfghj 56 er 656 uw 6 u 64 uu 45 yw 46 u 5 wjwu 5 i 56 u 57 i 5 wuiw 5 u W 46 uw 56 uueueri 5 u 6 w 56 uw 46 u 5 wu 56 uw 56 u 5 ---------END PRIVACY-ENHANCED MESSAGE Encrypted message

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

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

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

X. 509 Certificate: = SIGNED SEQUENCE { Uniquely identifies this certificate version[0] Version DEFAULT v 1988, serial. Number Certificate. Serial. Number, signature Algorithm. Identifier, Dig. sig & hash func algo & params issuer Name, Issuer ID validity Validity, subject Name, subject. Public. Key. Info Subject. Public. Key. Info } Start & end valid times Subject name Public key of the subject, algo ID & params

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 n The issuer will also have a certificate, and thus the process of certificate validation is recursive and implicitly defines a directed certification graph n X. 509 defines a Certification Authority (CA) as “an authority trusted by one or more users to create and assign certificates” n

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

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

PEM Summery n n 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)

Next : Pretty Good Privacy