Module 2
Electronic Mail Security
Pretty Good Privacy (PGP)
• Provides a confidentiality and authentication service
that can be used for electronic mail and file storage
applications
• Developed by Phil Zimmermann
– Selected the best available cryptographic algorithms as
building blocks
– Integrated these algorithms into a general-purpose
application that is independent of operating system and
processor and that is based on a small set of easy-to-use
commands
– Made the package and its documentation, including the
source code, freely available via the Internet, bulletin
boards, and commercial networks
– Entered into an agreement with a company to provide a
fully compatible, low-cost commercial version of PGP
PGP Growth
It is available free worldwide in versions that run on a variety of platforms
The commercial version satisfies users who want a product that comes with
vendor support
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
Is now on an Internet standards track, however it still has an aura of an
antiestablishment endeavor
Summary of PGP Services
PGP Authentication
• Combination of SHA-1 and RSA provides an
effective digital signature scheme
– Because of the strength of RSA the recipient is
assured that only the possessor of the matching
private key can generate the signature
– Because of the strength of SHA-1 the recipient is
assured that no one else could generate a new
message that matches the hash code
– As an alternative, signatures can be generated using
DSS/SHA-1
– Detached signatures are supported
– Each person’s signature is independent
and therefore applied only to the document
PGP Confidentiality
• Provided by encrypting messages to be transmitted or to be
stored locally as files
– In both cases the symmetric encryption algorithm CAST-128
may be used
– Alternatively IDEA or 3DES may be used
– The 64-bit cipher feedback (CFB) mode is used
In PGP each symmetric key is used only once
• Although referred to as a session key, it is in reality a one-
time key
• Session key is bound to the message and transmitted with it
• To protect the key, it is encrypted with the receiver’s public
key
– As an alternative to the use of RSA for key encryption, PGP uses
ElGamal, a variant of Diffie-Hellman that provides
encryption/decryption
PGP Confidentiality and
Authentication
• Both services may be used for the same message
– First a signature is generated for the plaintext
message and prepended to the message
– Then the plaintext message plus signature is
encrypted using CAST-128 (or IDEA or 3DES) and the
session key is encrypted using RSA (or ElGamal)
• When both services are used:
The sender first And finally encrypts
Then encrypts the
signs the message the session key with
message with a
with its own private the recipient’s
session key
key public key
PGP Compression
• As a default, PGP compresses the message after
applying the signature but before encryption
– This has the benefit of saving space both for e-mail
transmission and for file storage
– The placement of the compression algorithm is
critical
• Applying the hash function and signature after
compression would constrain all PGP implementations to
the same version of the compression algorithm
• Message encryption is applied after compression to
strengthen cryptographicsecurity
– The compression algorithm used is ZIP
PGP E-mail Compatibility
• Many electronic mail systems only permit the
use of blocks consisting of ASCII text
– To accommodate this restriction, PGP provides
the service of converting the raw 8-bit binary
stream to a stream of printable ASCII characters
– The scheme used for this purpose is radix-64
conversion
• Each group of three octets of binary data is mapped
into four ASCII characters
• This format also appends a CRC to detect transmission
errors
Secure/Multipurpose Internet Mail
Extension (S/MIME)
• A security enhancement to the MIME
Internet e-mail format standard based on
technology from RSA Data Security
• Defined in:
– RFCs 3370, 3850, 3851, 3852
RFC 5322
• Defines a format for text messages that are
sent using electronic mail
• Messages are viewed as having an envelope
and contents
– The envelope contains whatever information is
needed to accomplish transmission and delivery
– The contents compose the object to be delivered
to the recipient
– RFC 5322 standard applies only to the contents
• The content standard includes a set of
header fields that may be used by the mail
system to create the envelope
Multipurpose Internet Mail Extensions
(MIME)
MIME specification includes the following elements:
• An extension to the RFC 5322
framework that is intended to
address some of the problems
and limitations of the use of Transfer encodings Five new message
Simple Mail Transfer Protocol are defined that header fields are
(SMTP) enable the defined, which may
conversion of any be included in an
– Is intended to resolve RFC 5322 header;
these problems in a content format into
a form that is these fields provide
manner that is compatible protected from information about
with existing RFC 5322 alteration by the the body of the
implementations mail system message
– The specification is
provided in RFCs 2045
through 2049 A number of content
formats are defined, thus
standardizing
representations that
support multimedia
electronic mail
The Five Header Fields Defined in
MIME
MIME-Version
• Must have the parameter value 1.0
• This field indicates that the message conforms to RFCs 2045 and 2046
Content-Type
• Describes the data contained in the body with sufficient detail that the receiving user agent
can pick an appropriate agent or mechanism to represent the data to the user or otherwise
deal with the data in an appropriate manner
Content-Transfer-Encoding
• Indicates the type of transformation that has been used to represent the body of the message
in a way that is acceptable for mail transport
Content-ID
• Used to identify MIME entities uniquely in multiple contexts
Content-Description
• A text description of the object with the body; this is useful when the object is not readable
MIME
Content
Types
MIME Transfer Encodings
Native and Canonical Form
S/MIME Functionality
Enveloped data Signed data
• Consists of encrypted content of any type and • A digital signature is formed by taking the message
encrypted content encryption keys for one or more digest of the content to be signed and then
recipients encrypting that with the private key of the signer
• The content plus signature are then encoded using
base64 encoding
• A signed data message can only be viewed by a
recipient with S/MIME capability
S/MIME
Clear-signed data Signed and enveloped data
• Only the digital signature is encoded using base64 • Signed-only and encrypted-only entities may be
• As a result recipients without S/MIME capability nested, so that encrypted data may be signed and
can view the message content, although they signed data or clear-signed data may be encrypted
cannot verify the signature
Cryptographic
Algorithms
Used in
S/MIME
S/MIME Content Types
Securing a MIME Entity
• S/MIME secures a MIME entity with a
signature, encryption, or both
• The MIME entity is prepared according to the
normal rules for MIME message preparation
– The MIME entity plus some security-related data,
such as algorithm identifiers and certificates, are
processed by S/MIME to produce what is known
as a PKCS object
– A PKCS object is then treated as message content
and wrapped in MIME
• In all cases the message to be sent is
converted to canonical form
EnvelopedData
• The steps for preparing an envelopedData MIME
are:
Generate a pseudorandom session key for a particular symmetric
encryption algorithm
For each recipient, encrypt the session key with the recipient’s
public RSA key
For each recipient, prepare a block known as RecipientInfo
that contains an identifier of the recipient’s public-key certificate,
an identifier of the algorithm used to encrypt the session key,
and the encrypted session key
Encrypt the message content with the session key
SignedData
• The steps for preparing a
signedData MIME are:
Prepare a block
known as
Encrypt the SignerInfo
message digest with that contains the
the signer’s private signer’s public-key
key certificate, an
Compute the identifier of the
message digest (hash message digest
function) of the algorithm, an
content to be signed identifier of the
algorithm used to
Select a message encrypt the
digest algorithm message digest,
(SHA or MD5) and the encrypted
message digest
Clear Signing
• Achieved using the multipart content type
with a signed subtype
• This signing process does not involve
transforming the message to be signed
• Recipients with MIME capability but not
S/MIME capability are able to read the
incoming message
S/MIME Certificate Processing
• S/MIME uses public-key certificates that conform
to version 3 of X.509
• The key-management scheme used by S/MIME is
in some ways a hybrid between a strict X.509
certification hierarchy and PGP’s web of trust
• S/MIME managers and/or users must configure
each client with a list of trusted keys and with
certificate revocation lists
– The responsibility is local for maintaining the
certificates needed to verify incoming signatures and
to encrypt outgoing messages
• The certificates are signed by certification
authorities
User Agent Role
• An S/MIME user has several key-management functions to
perform:
Certificate storage and
Key generation Registration
retrieval
The user of some related A user’s public key must be A user requires access to a
administrative utility must be registered with a certification local list of certificates in
capable of generating separate authority in order to receive an order to verify incoming
Diffie-Hellman and DSS key pairs X.509 public-key certificate signatures and to encrypt
and should be capable of outgoing messages
generating RSA key pairs
A user agent should generate
RSA key pairs with a length in
the range of 768 to 1024 bits
and must not generate a length
of less than 512 bits
VeriSign Certificates
• VeriSign provides a certification authority (CA) service
that is intended to be compatible with S/MIME and a
variety of other applications
• Issues X.509 certificates with the product name
VeriSign Digital ID
• At a minimum, each Digital ID contains:
– Owner’s public key
– Owner’s name or alias
– Expiration date of the Digital ID
– Serial number of the Digital ID
– Name of the certification authority that issued the Digital
ID
– Digital signature of the certification authority that issued
the Digital ID
VeriSign Public-Key Certificate Classes
IA Issuing Authority
CA Certification Authority
PCA VeriSign public primary certification authority
PIN Personal Identification Number
LRAA Local Registration Authority Administrator
Enhanced Security Services
• Three enhanced security services have been
proposed in an Internet draft:
– Signed receipt
• Returning a signed receipt provides proof of delivery to the
originator of a message and allows the originator to
demonstrate to a third party that the recipient received the
message
– Security labels
• A set of security information regarding the sensitivity of the
content that is protected by S/MIME encapsulation
– Secure mailing lists
• An S/MIME Mail List Agent (MLA) can take a single incoming
message, perform the recipient-specific encryption for each
recipient, and forward the message
DomainKeys Identified Mail (DKIM)
• A specification for cryptographically signing e-mail
messages, permitting a signing domain to claim
responsibility for a message in the mail stream
• Message recipients can verify the signature by
querying the signer’s domain directly to retrieve
the appropriate public key and can thereby
confirm that the message was attested to by a
party in possession of the private key for the
signing domain
• Proposed Internet Standard RFC 4871
• Has been widely adopted by a range of e-mail
providers and Internet Service Providers (ISPs)
E-mail Threats
• RFC 4684 (Analysis of • Characterized on three levels
Threats Motivating of threat:
DomainKeys Identified
Mail) The most sophisticated and financially
motivated senders of messages are those
who stand to receive substantial financial
– Describes the threats benefit, such as from an e-mail based
fraud scheme
being addressed by
DKIM in terms of the
characteristics, The next level are professional senders of
bulk spam mail and often operate as
capabilities, and commercial enterprises and send
messages on behalf of third parties
location of potential
attackers
At the low end are attackers who simply
want to send e-mail that a recipient does
not want to receive
Summary
• Pretty good privacy • S/MIME
– Notation
• RFC 5322
– Operational • Multipurpose
description
Internet mail
• DomainKeys extensions
Identified Mail • S/MIME functionality
– Internet mail • S/MIME messages
architecture • S/MIME certification
– E-mail threats processing
– DKIM strategy • Enhanced security
– DKIM functional flow services