Electronic Mail Security

Pretty Good Privacy (PGP)

S/Mime Security Architecture

Email Security
email is one of the most widely used and

regarded network services

currently message contents are not
secure

may be inspected either in transit

or by suitably privileged users on destination
system

Email Security Enhancements

confidentiality

protection from disclosure

authentication

of sender of message

message integrity

protection from modification

non-repudiation of origin

protection from denial by sender

Schemes of Email Security

PGP (Pretty Good Privacy)

S/MIME (Secure/Multipurpose Internet

mail Extension)

Pretty Good Privacy (PGP)

widely used for secure email
developed by Phil Zimmermann
selected best available crypto algorithm as

building block
Integrated these algorithms into a generalpurpose application
on Unix, PC, Macintosh and other systems
provides a confidentiality and authentication
service that can be used for electronic mail
and file storage applications

PGP is an open-source freely available software package for

e-mail security.
It provides authentication through the use of digital
signature; confidentiality through the use of symmetric block
encryption; compression using the ZIP algorithm; e-mail
compatibility using the radix-64 encoding scheme; and
segmentation and reassembly to accommodate long emails.
PGP incorporates tools for developing a public-key trust
model and public-key certificate management.

PGP has grown explosively and is now widely

used. A number of reasons can be cited for this
growth:
Available free worldwide in versions that run on
a variety of platforms, including Windows,
UNIX, Macintosh, and many more
It is based on algorithms that have survived
extensive public review and are considered
extremely secure.

 It has a wide range of applicability

It was not developed by, nor is it controlled

by, any governmental or standards

organization.
PGP is now on an Internet standards track
(RFC 3156).

PGP Operations
Authentication
Confidentiality
Confidentiality & Authentication
Compression
Compatibility

Authentication
digital signature service provided by PGP

sender creates message

use SHA-1 to generate 160-bit hash of message

signed hash with RSA using sender's private key, and

is attached to message

receiver uses RSA with sender's public key to decrypt

and recover hash code

receiver verifies received message using hash of it and

compares with decrypted hash code

combination of SHA-1 and RSA provides an effective

digital signature scheme

Confidentiality
1.
2.
3.
4.
5.

sender generates message and 128-bit

random number as session key for it
encrypt message using CAST-128 / IDEA /
3DES in CBC mode with session key
session key encrypted using RSA with
recipient's public key, & attached to msg
receiver uses RSA with private key to
decrypt and recover session key
session key is used to decrypt message

Confidentiality & Authentication

can use both services on same message

create signature & attach to message

encrypt both message & signature
attach RSA/ElGamal encrypted session key

when both services are used, the sender first

signs the message with its own private key,
then encrypts the message with a session key,
and then encrypts the session key with the
recipient's public key.

Compression
by default PGP compresses message

after signing but before encrypting

benefit of saving space both for e-mail

transmission and for file storage
& because compression is non deterministic

uses ZIP compression algorithm

Compatibility

when using PGP will have binary data to send

(encrypted message etc)
however email was designed only for text
hence PGP must encode raw binary data into
printable ASCII characters
uses radix-64 algorithm

maps 3 bytes to 4 printable chars

also appends a CRC

PGP also segments messages if too big

Transmission and Reception of

PGP Messages

Cryptographic Keys and key ring

of PGP
PGP makes use of four types of keys:
one-time session symmetric keys
public keys
private keys
passphrase-based symmetric keys

Three separate requirements can be identified with

respect to these keys: A means of generating
unpredictable session keys is needed.
We would like to allow a user to have multiple
public-key/private-key pairs. One reason is that
the user may wish to change his or her key pair
from time to time.
Each PGP entity must maintain a file of its own
public/private key pairs as well as a file of public
keys of correspondents.

PGP Session Keys

need a session key for each message

of varying sizes: 56-bit DES, 128-bit CAST or

IDEA, 168-bit Triple-DES

generated using ANSI X12.17 mode

uses random

inputs taken from previous

uses and from keystroke timing of user

PGP Public & Private Keys

since many public/private keys may be in use,

need to identify which is actually used to encrypt
session key in a message

rather use a key identifier based on key

could send full public-key with every message

but this is inefficient
is least significant 64-bits of the key
will very likely be unique

also use key ID in signatures

PGP Message Format

PGP Key Rings

each PGP user has a pair of keyrings:

public-key ring contains all the public-keys of

other PGP users known to this user, indexed
by key ID
private-key ring contains the public/private
key pair(s) for this user, indexed by key ID &
encrypted keyed from a hashed passphrase

security of private keys thus depends on

the pass-phrase security

PGP Message Generation

1. Signing the message

PGP retrieves the sender's private key from the private-key
ring using your_userid as an index. If your_userid was not
provided in the command, the first private key on the ring is
retrieved.
PGP prompts the user for the passphrase to recover the
unencrypted private key.
The signature component of the message is constructed.
2. Encrypting the message
PGP generates a session key and encrypts the message.
PGP retrieves the recipient's public key from the public-key
ring using her_userid as an index.
The session key component of the message is constructed.

PGP Message Reception

1. Decrypting the message

a) PGP retrieves the receiver's private key from the private-key ring,
using the Key ID field in the session key component of the message
as an index.
b) PGP prompts the user for the passphrase to recover the
unencrypted private key.
c) PGP then recovers the session key and decrypts the message.
2. Authenticating the message
a) PGP retrieves the sender's public key from the public-key ring,
using the Key ID field in the signature key component of the
message as an index.
b) PGP recovers the transmitted message digest.
c) PGP computes the message digest for the received message and
compares it to the transmitted message digest to authenticate.

PGP Key Management

rather than relying on certificate authorities

in PGP every user is own CA

forms a web of trust

can sign keys for users they know directly

trust keys have signed
can trust keys others have signed if have a chain of
signatures to them

key ring includes trust indicators

users can also revoke their keys

S/MIME (Secure/Multipurpose
Internet Mail Extensions)
security enhancement to MIME email

original Internet RFC822 email was text only

MIME provided support for varying content
types and multi-part messages
with encoding of binary data to textual form
S/MIME added security enhancements

have S/MIME support in many mail agents

eg MS Outlook, Mozilla, Mac Mail etc

MIME specification
includes the following elements:
Five new message header fields are defined. These
fields provide information about the body of the
message.

MIME-Version
Content-Type
Content-Transfer-Encoding
Content-ID
Content-Description

A number of content formats are defined, thus

standardizing representations that support multimedia
electronic mail.
Transfer encodings are defined that enable the
conversion of any content format into a form that is
protected from alteration by the mail system

S/MIME Functionality
S/MIME provides the following functions
enveloped data

signed data

encoded message + signed digest

clear-signed data

encrypted content and associated keys

cleartext message + encoded signed digest

signed & enveloped data

nesting of signed & encrypted entities

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 algs to use

S/MIME Messages
S/MIME secures

a MIME entity with a

signature, encryption, or both
forming a MIME wrapped PKCS object
have a range of content-types:

enveloped data
signed data
clear-signed data
registration request
certificate only message

S/MIME Certificate Processing

S/MIME uses X.509 v3 certificates

the responsibility is local for maintaining the
certificates needed to verify incoming signatures
and to encrypt outgoing messages
managed using a hybrid of a strict X.509 CA
hierarchy & PGPs web of trust
each client has a list of trusted CAs certs
and own public/private key pairs & certs
certificates must be signed by trusted CAs

 User Agent Rol

An S/MIME user has several key-management

functions to perform:

Key generation
Registration
Certificate storage and retrieval

VeriSign Certificates
VeriSign provides three levels, or classes, of security for
public-key certificates
For Class 1 Digital IDs, VeriSign confirms the user's e-mail
address by sending a PIN and Digital ID pick-up
information to the e-mail address provided in the
application.

For Class 2 Digital IDs, VeriSign verifies the information in

the application through an automated comparison with a
consumer database in addition to performing all of the
checking associated with a Class 1 Digital ID.
For Class 3 Digital IDs, VeriSign requires a higher level of
identity assurance

Certificate Authorities
have several well-known CAs
Verisign one of most widely used
Verisign issues several types of Digital IDs
increasing levels of checks & hence trust
Class
1
2
3

Identity Checks
name/email check
+ enroll/addr check
+ ID documents

Usage
web browsing/email
email, subs, s/w validate
e-banking/service access

Summary
have considered:

secure email
PGP
S/MIME