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)

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
User
agent
Mail transfer
Agent (SMTP)
Retrieval
(e.g. POP3)
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 )
 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)

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
 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

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)
 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
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

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)
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

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
 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

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)
Integration Of PEM Into Existing Mail System
Originator at a multiuser host
Editor
PEM
filter
Recipient at a workstation
User
agent
User
agent
PEM
module
Mail transfer
Agent (SMTP)
Retrieval
(e.g. POP3)
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 .
 The shortcoming is that it restricts the input
to 7-bit ASCII .
 The reason is that the Internet e-mail imposes
the same restrictions.

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 permessage symmetric key .

The encryption action is performed only if the
message is of type ENCRYPTED .

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.

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.

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: RFC822
Conforms to
DEK-Info: DES-CBC, BGFA799HTS347KGKL0
Msg encryption
params
Originator-Certificate:
yhtrwhhj57jw5jw6w7u6juj6uu45yjj5645w4y4y5yqy3
(for example, IV)
Originator certificate
Issuer-Certificate:
Eth46u5kw57kwuw3jwjw465iw6uw57uw6u4q6jj6646
Issuer certificate
PEM Message Submission: Header
Construction (2)
MIC-Info: RSA-MD5, RSA,
MIC & Dig.Sig algo
Sdhdsh453hwe5yyh5ywjuhs5yahhaehjue78iok67k
Digital signature
Recipient-ID-Asymmetric:
Agw56ywjq45y2jqhj4yuq4hjq4yq3yy3yewghew5y3
Recipient’s id
Key-Info: RSA,
Public key algo
Adshw45w5j7w57j5u46yu5yq46ju46juqyuq4u5y35hj
Encrypted message key
Blank line
Dfghj56er656uw6u64uu45yw46u5wjwu5i56u57i5wuiw5u
W46uw56uueueri5u6w56uw46u5wu56uw56u56u5
------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
Certificate: = SIGNED SEQUENCE {
Uniquely identifies this
certificate
version[0]
Version DEFAULT v1988,
serialNumber
CertificateSerialNumber,
signature
AlgorithmIdentifier,
Dig.sig & hash func
algo & params
issuer
Name,
Issuer ID
validity
Validity,
subject
Name,
subjectPublicKeyInfo
SubjectPublicKeyInfo }
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
 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”

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

Example to a Typical Internet
Certification Hierarchy
IPRA
High
assurance
BBN
User
User
BBNCD
User
Residential
Mid-level
assurance
Persona
Louisiana
New York
New Orleans
User
User
LCS
User
User
User
User
User
User
User
MIT
HUJI
User
Persona
User
User
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)
Next :
Pretty Good Privacy