PGP and S/MIME are two standards for securing email. PGP provides encryption and authentication independently of operating systems using symmetric and asymmetric cryptography. S/MIME uses X.509 certificates and defines how to cryptographically sign, encrypt, and combine MIME entities for authentication and confidentiality using algorithms like RSA, DSS, and 3DES. DKIM allows a sending domain to cryptographically sign emails to assert the message's origin and prevent spoofing, while the email architecture standards like RFC 5322 and MIME define message formatting and how attachments are represented.

1. NETWORK SECURITY
Name of the Staff : M.FLORENCE DAYANA M.C.A.,M.Phil.,(Ph.D).,
Head, Dept. of CA
Bon Secours College For Women
Thanjavur.
Class : II MSc., CS
Semester : III
Unit : III
Topic : Electronic Mail Security
2/15/20191

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

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

4. Table 19.1
Summary of PGP Services

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

6. 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
• As an alternative to the use of RSA for key encryption, PGP uses
ElGamal, a variant of Diffie-Hellman that provides
encryption/decryption
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

7. 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
signs the message
with its own private
key
Then encrypts the
message with a
session key
And finally encrypts
the session key
with the recipient’s
public key

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

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

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

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

14. Multipurpose Internet
Mail Extensions (MIME)
• An extension to the RFC 5322
framework that is intended
to address some of the
problems and limitations of
the use of Simple Mail
Transfer Protocol (SMTP)
• Is intended to resolve
these problems in a
manner that is compatible
with existing RFC 5322
implementations
• The specification is
provided in RFCs 2045
through 2049
MIME specification includes the following elements:
Five new message
header fields are
defined, which may
be included in an
RFC 5322 header;
these fields provide
information about
the body of the
message
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

15. The Five Header Fields
Defined in MIME
•Must have the parameter value 1.0
•This field indicates that the message conforms to RFCs 2045 and 2046
MIME-Version
•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-Type
•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-Transfer-Encoding
•Used to identify MIME entities uniquely in multiple contexts
Content-ID
•A text description of the object with the body; this is useful when the object is not
readable
Content-Description

16. Table 19.2
MIME
Content
Types

17. Table 19.3
MIME Transfer Encodings

19. Table 19.4
Native and Canonical Form

20. S/MIME Functionality
Enveloped data
•Consists of encrypted content of any type and
encrypted content encryption keys for one or
more recipients
Signed data
•A digital signature is formed by taking the
message digest of the content to be signed and
then 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
Clear-signed data
•Only the digital signature is encoded using
base64
•As a result recipients without S/MIME capability
can view the message content, although they
cannot verify the signature
Signed and enveloped data
•Signed-only and encrypted-only entities may be
nested, so that encrypted data may be signed and
signed data or clear-signed data may be
encrypted
S/MIME

21. Table
19.5
Cryptographic
Algorithms
Used in
S/MIME

22. Table 19.6
S/MIME Content Types

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

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

25. SignedData
• The steps for preparing a
signedData MIME are:
Select a message
digest algorithm
(SHA or MD5)
Compute the
message digest
(hash function) of
the content to be
signed
Encrypt the
message digest
with the signer’s
private key
Prepare a block
known as
SignerInfo
that contains the
signer’s public-key
certificate, an
identifier of the
message digest
algorithm, an
identifier of the
algorithm used to
encrypt the
message digest,
and the encrypted
message digest

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

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

28. User Agent Role
• An S/MIME user has several key-management functions to
perform:
Key generation
The user of some related
administrative utility must be
capable of generating separate
Diffie-Hellman and DSS key pairs
and should be capable of
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
Registration
A user’s public key must be
registered with a certification
authority in order to receive an
X.509 public-key certificate
Certificate storage and
retrieval
A user requires access to a
local list of certificates in
order to verify incoming
signatures and to encrypt
outgoing messages

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

30. IA Issuing Authority
CA Certification Authority
PCA VeriSign public primary certification authority
PIN Personal Identification Number
LRAA Local Registration Authority Administrator
Table 19.7
VeriSign Public-Key Certificate Classes

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

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

34. E-mail Threats
• RFC 4684 (Analysis of
Threats Motivating
DomainKeys Identified
Mail)
• Describes the threats
being addressed by
DKIM in terms of the
characteristics,
capabilities, and
location of potential
attackers
• Characterized on three levels
of threat:
At the low end are attackers who
simply want to send e-mail that a
recipient does not want to receive
The next level are professional senders
of bulk spam mail and often operate as
commercial enterprises and send
messages on behalf of third parties
The most sophisticated and financially
motivated senders of messages are
those who stand to receive substantial
financial benefit, such as from an e-mail
based fraud scheme

37. Summary
• Pretty good privacy
• Notation
• Operational
description
• DomainKeys Identified
Mail
• Internet mail
architecture
• E-mail threats
• DKIM strategy
• DKIM functional flow
• S/MIME
• RFC 5322
• Multipurpose Internet
mail extensions
• S/MIME functionality
• S/MIME messages
• S/MIME certification
processing
• Enhanced security
services