Electronic Mail

Security
 Overview

1. Pretty Good Privacy (PGP)

2. S/MIME
3. DomainKeys Identified Mail
(DKIM)

19-2
 Motivation for E-mail Security
• Electronic mail (E-mail) is one of the widely used and
regarded network –based application in virtually all
distributed environments.
• Currently, message contents are not secure.
– May be inspected either in transit or by suitably privileged users on
destination systems
• Requirements for E-mail Security
– Confidentiality: protection from disclosure
– Authentication of sender of message
– Message integrity: protection from modification
– Non-repudiation of origin: protection from denial by
• PGPsender
(Pretty Good Privacy) and S/MIME (Secure Multi-purpose
Internet Mail Extensions) are the two commonly used E-mail
Security Standards. DKIM is a third e-mail security standard.
 E-mail Security Standards
• Pretty Good Privacy (PGP), Secure Multi-purpose Internet Mail
Extensions
(S/MIME) and Domain Keys Identified Mail (DKIM)
• Both PGP and S/MIME provide confidentiality and authentication services that can
be used for E-mail and file storage applications.
• PGP was originally designed for plaintext messages; S/MIME handles all sorts of
data files (for e.g., spreadsheets, graphics, presentations, movies, and sound) and is
integrated into many commercial e-mail packages – hence S/MIME is likely to
dominate the secure e-mail market.
• With PGP, each user is free to decide on the level of trust for a public key of a
remote user (usually done based on a “web of trust” among the users) and not
done through a centralized Certificate Authority (CA) to issue certificates for the
• public keys.
• S/MIME uses the standard public-key certificates issued by a CA. S/MIME also
provides several options for the algorithms to be used for confidentiality and
authentication services; whereas PGP is fixed with respect to the
• algorithms that can be used.
Support for S/MIME is built-in to most of the standard browsers; while PGP
typically requires a user to download and install one or more plug-ins.
 PGP Operation – Authentication
1. Sender creates message
2. Make SHA-1 160-bit hash of message
3. Attached RSA signed hash to message
4. Receiver decrypts & recovers hash code
5. Receiver verifies received message hash

19-5
 PGP for Authentication
ZIP [M || EPri-Sender(H(M)) ]

| | Z Z-1 H
M M
PRS PUS

Compare
H EP DP
H(M) H(M)

Source Side Destination Side

E(PRS, H(M))

Hashing Algorithm, H - SHA-1160 bit hash

Encryption for digital signature (public-key encryption), EP – RSA
Compression, Z – ZIP algorithm

Source (adapted from): Figure 18.1 (a), from William Stallings – Cryptography and Network Security, 5th
Edition
 PGP Operation – Confidentiality
1. Sender forms 128-bit random session key
2. Encrypts message with session key
3. Attaches session key encrypted with RSA
4. Receiver decrypts & recovers session key
5. Session key is used to decrypt message

19-6
 PGP for Confidentiality
PUR
Source Side Destination
Side
KS EP DC Z-1
M
M Z EC || KS

KS DP
Note that with PGP, the secret key
is generated for each message E(PUR,KS)
PRR

ESecret-key[ZIP (M)] || EPub-Receiver(Secret-key)

Encryption for confidentiality, EC – IDEA (International Data Encryption Algorithm)

Source (adapted from): Figure 18.1 (b), from William Stallings – Cryptography and Network Security, 5th
Edition
 Confidentiality & Authentication

 Can use both services on same message

 Create signature & attach to message

 Encrypt both message & signature

 Attach RSA/ElGamal encrypted session key

19-7
 PGP for Authentication and Confidentiality
PUR

Source Side KS EP Destination Side

EC DC Z-1
| |
M

Z KS PUS

H(M) H(M)
KS DP DP
| |

M Compare H
PR S PR R

H EP

ESecret-key[ZIP (M || EPri-Sender(H(M)) )] || EPub-Receiver(Secret-key)

Source (adapted from): Figure 18.1 (c), from William Stallings – Cryptography and Network Security, 5th
Edition
 PGP Operation – Compression
 By default PGP compresses message after signing but before
encrypting
 Uncompressed message & signature can be stored for later
verification
 Compression is non deterministic
 Uses ZIP compression algorithm

19-8
 PGP Keys
• PGP Session Key
• The session key is associated with a single message and is used only for the
purpose of encrypting and decrypting that message.
• IDEA uses a 128-bit symmetric key.
• Session keys are generated using the ANSI X12.17 generator, based on
keystroke input from the user, where both the keystroke timing and the
actual keys struck are used to generate a randomized stream of numbers
constituting the key.
• PGP Public and Private Keys
• Since many public/private keys may be in use with PGP, there is a need to
identify which key is actually used to encrypt the session key for any specific
message.
• Since, it would be inefficient to send the full public-key with every message,
PGP uses a key identifier based on the least significant 64-bits of the key,
which will very likely be unique. Then only the much shorter key ID would
need to be transmitted with any message.
• A key ID is also required for the PGP digital signature.
 PGP Operation – Email Compatibility
 PGP segments messages if too big
 PGP produces binary (encrypted) data & appends a CRC
 Email was designed only for text
 Need to encode binary into printable ASCII characters
 Uses radix-64 or base-64 algorithm
 Maps 3 bytes to 4 printable chars: 26 upper case
lowercase
alphabets, 26 alphabets, 10 numbers, +, \

Ref: http://en.wikipedia.org/wiki/Base64
19-9
 PGP Operation – Summary

Washington University in St. Louis CSE571S ©2014 Raj Jain

19-10
 PGP Session Keys
Need a session key of varying sizes for each
message:
 56-bit DES,

 168-bit Triple-DES

 128-bit CAST (Carlisle Adams and

Stafford Tavares)
 IDEA (International Data Encryption
Algorithm)
 Generated with CAST-128 using random inputs taken from
previous uses and from keystroke timing of user

19-11
 PGP Public & Private Keys
 Users are allowed to have multiple public/private
keys
⇒ Need to identify which key has been used
 Use a key identifier = Least significant 64-bits of the key

 Signature keys are different from encryption keys

(Encryption keys may need to be disclosed for legal reasons)

19-12
 PGP Message Format

Confirms correct key was used

Includes Signature, timestamp

of signature, data
Does not include filename,
timestamp of file

19-13
 PGP Key Rings
 Private keys encrypted by a passphrase
 Public keys of all correspondents

19-14
PGP Message Generation

19-15
PGP Message Reception

19-16
 Web of Trust
 There is no need to buy certificates from
companies
 A user can sign other user’s certificates
 If you trust someone, you can trust users
that they sign for.
 You can assign a level of trust to each user and hence to the
certificate they sign for
 For example,
 A certificate that is signed by a fully trusted user is fully
trusted
 A certificate signed by two half trusted users is fully
trusted
 A certificate signed by one half trusted user is half trusted
19-17
PGP Trust Model Example
DEFL are trusted
AB re half trusted
S is untrusted

19-18
 Certificate Revocation
 Owners can revoke public key by issuing a
“revocation” certificate signed with the revoked
private key
 New Web-of-trust certificates have expiry dates

19-19
 S/MIME
 Secure/Multipurpose Internet Mail
Extensions
 Original Internet RFC822 email was
text only
 MIME for varying content types and
multi-part messages
 With encoding of binary data to
textual form
 S/MIME added security
enhancements
 Enveloped data: Encrypted
content and associated keys
 Signed data: Encoded message +
signed digest
 Clear-signed data: Clear text
19-20message + encoded signed
 S/MIME
Create a Random
Plaintext
Session Key, KSession Hashing
Algorithm
Symmetric
Encrypt with the
Key Encryption Hash (Plaintext)
Recipient’s Public Key
EPub-Rcvr
Encrypted with Encrypt with the
KSession Sender’s Private Key
Encrypted with
Plaintext EPri-Send
EPub-Rcvr
KSession
Encrypted with
EPri-Send

Message Transmitted Hash (Plaintext)

Encrypted with Encrypted with Encrypted with Encrypted with EPub-Rcvr

KSession EPub-Rcvr EPri-Send
Sender’s Public-Key
Plaintext KSession Hash (Plaintext)
Certificate
 MIME Functions
 Types: Text/Plain, Text/Enriched, Multipart/Mixed,
Image/jpeg, Image/gif, Video/mpeg, audio/basic, …
 Encodings: 7bit, 8bit, binary, quoted-printable,
base64

 Quoted-Printable: non-alphanumerics by =2 hex-digits, e.g.,

Ref: http://en.wikipedia.org/wiki/MIME, http://en.wikipedia.org/wiki/Quoted-printab
le “=09” for tab, “=20” for space, “=3D” for =
http://en.wikipedia.org/wiki/Base64
19-21
 S/MIME Cryptographic Algorithms

 Digital signatures: DSS & RSA

 Hash functions: SHA-1 & MD5
 Session key encryption: ElGamal & RSA
 Message encryption: AES, Triple-DES, RC2/40 and
others
 MAC: HMAC with SHA-1
 Have process to decide which algorithms to use

19-22
 S/MIME Messages
 S/MIME secures a MIME entity with a signature, encryption,
or both
 Forming a MIME wrapped PKCS object
(Public Key Cryptography Standard originally by RSA Inc
Now by IETF)
Type Subtype Smime parameter Meaning
Multipart Signed clear msg w
signature Application Pkcs7-mime signedData Signed
entity Application Pkcs7-mime envelopedData Encrypted
entity Application Pkcs7-mime Degenerate signedData Certificate only
Application Pkcs7-mime CompressedData Compressed entity
Application Pkcs7-signature signedData Signature
Content-Type: application/pklcs7-mime; smime-type=signedData; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

Ref: http://en.wikipedia.org/wiki/PKCS

19-23
 S/MIME Certificate Processing
 S/MIME uses X.509 v3 certificates
 Managed using a hybrid of a strict X.509 CA hierarchy and
enterprise’s CAs
 Each client has a list of trusted CA’s certificates and his own
public/private key pairs & certificates
 Several types of certificates with different levels of checks:
 Class 1: Email and web browsing
 Class 2: Inter-company email
 Class 3: Banking, …

19-24
 S/MIME Enhanced Security Services

 RFC2634 (1999) describes enhanced security services:

 Signed receipts: Request a signed receipt

 Security labels: Priority, which users (role) can access

 Secure mailing lists: Request a list processor to

encrypt

19-25
 Domain Keys Identified Mail
 Emails signed by the
enterprise, e.g. WUSTL
rather than the sender
 Company’s mail system
signs the message
 So spammers cannot fake
that companies email
addresses

Ref: http://en.wikipedia.org/wiki/DKIM

19-26
 Domain Keys Identified Mail (DKIM)
• With DKIM, an e-mail message is signed using the private key of
the administrative domain from which the e-mail originates
(not signed with the private key of the individual user, as in
PGP and S/MIME).
• DKIM is transparent to the end-users as the e-mail is signed
by the Mail Submission Agent (MSA) of the sender’s domain
and validated by the Mail Delivery Agent (MDA) of the
recipient’s domain.
• At the receiving end, the MDA can access the public key of the
sender’s administrative domain (through DNS query) and
verify the authenticity of the message.
• E-mails that claim to originate from a particular domain – but,
not signed with the private key of the administrative domain
– are rejected.
• The default signing algorithm is RSA with SHA-256.
DKIM Functional Flow

19-27
 DKIM

(to send and propagate e-mail messages)

SMTP – Simple Mail Transfer Protocol
(to retrieve e-mail message from the MDA
to the MUA)
POP – Post Office Protocol
IMAP – Internet Message Access Protocol
http://www.youtube.com/watch?v=GcvdhjLVYfY
Source: Figure 18.10 from William Stallings – Cryptography and Network Security, 5th Edition
 Summary

1. Email can be signed, encrypted or

both
2. PGP is a commonly used system that provides integrity,
authentication, privacy, compression, segmentation, and
MIME compatibility
3. PGP allows Web of trust in addition to CA certificates
4. S/MIME extends MIME for secure email and provides
authentication and privacy
5. DKIM allows originating companies to sign all emails from
their users 19-28
 Acronyms
 AES Advanced Encryption Standard
 ASCII American Standard Code for
Information Exchange
 CA Certificate Authority
 CAST Carlisle Adams and Stafford
Tavares
 CRC Cyclic Redundancy Check
 DCIM Domain Key Indentified Mail
 DES Digital Encyrption Standard
 DSS Digital Signature Scheme
 ECC Elliptic Curve Cryptography
 ECDSA Elliptic Curve Cryptography
Digital Signature Algorithm
 HMAC Hybrid Message Authentication
Code
 IDEA International Data Encryption
Algorithm
 IETF Internet Engineering Task Force
19-30
 Acronyms (Cont)
 MIT Massachusetts Institute of Technology
 MS Microsoft
 OCR Optical Character Recognition
 PC Personal Computer
 PGP Pretty Good Privacy
 PKCS Public Key Cryptography Standard
 RC2 Ron's Code 2
 RFC Request for Comments
 RSA Rivest, Shamir, Adleman
 S/MIME Secure Multipurpose Internet Mail
Extension
 SHA Secure Hash Algorithm
 Triple-DES Triple Digital Encryption Standard
 WUSTL Washington University in Saint Louis

Washington University in St. Louis 19-31

CSE571S