CSE3080-Cryptography and Network

Security

Module 7: E-mail and IP Security

Email Security 2

VIT/SCOPE/BTECH/CNS-BCSE309L
 Internet Mail Architecture
 Email Components
 Email Protocols
 Email Formats
 RFC 5322
 Multipurpose Internet Mail Extensions
 Email Threats and Comprehensive Email
Security
 SMIMIE
 Pretty Good Privacy
Email Security 4

VIT/SCOPE/BTECH/CNS-BCSE309L
 Electronic mail is the most heavily used network-
based application.
 With the explosively growing reliance on email,
there grows demand for authentication and
confidentiality services.
 Two approaches are widely used:
 Pretty Good Privacy (PGP)
 S/MIME.
 Internet Mail Architecture is defined in RFC 5598
Email Components 5

VIT/SCOPE/BTECH/CNS-BCSE309L
 The Internet mail architecture consists
A. User world in the form of Message User Agents (MUA)
B. Transfer world, in the form of the Message Handling
Service (MHS)
 Composed of Message Transfer Agents (MTA).
 Accepts a message from one user and delivers it to one
or more other users, creating a virtual MUA-to-MUA exchange environment.
 Three types of interoperability
1. Directly between users
2. Between the MUA and the MHS
3. Among the MTA components
 6

Function Modules and

Standardized Protocols Used
between them in the
Internet Mail Architecture

VIT/SCOPE/BTECH/CNS-BCSE309L
Email Components… 7

VIT/SCOPE/BTECH/CNS-BCSE309L
 Key components of the Internet mail architecture:
 Message User Agent (MUA): Operates on behalf of user
actors and user applications.
 Mail Submission Agent (MSA): Accepts the message
submitted by an MUA and enforces the policies of the hosting
domain and the requirements of Internet standards.
 Message Transfer Agent (MTA): Relays mail for one
application-level hop.
 Mail Delivery Agent (MDA): Responsible for transferring
the message from the MHS to the MS.
 Message Store (MS): An MUA can employ a long-term MS.
An MS can be located on a remote server or on the same
machine as the MUA.
Email Components… 8

VIT/SCOPE/BTECH/CNS-BCSE309L
 An administrative management domain (ADMD)
is an Internet email provider.
 a department that operates a local mail relay (MTA),
 an IT department that operates an enterprise mail relay,
 an ISP that operates a public shared email service.
 The Domain Name System (DNS) is a directory
lookup service that provides a mapping between the
name of a host on the Internet and its numerical
address.
Email Protocols 9

Two types of protocols are used for

transferring email:

Used to move messages Used to transfer

through the Internet from messages between mail
source to destination servers
• Simple Mail Transfer • Mail Access Protocols
Protocol (SMTP) (IMAP and POP are the most
commonly used)

VIT/SCOPE/BTECH/CNS-BCSE309L
1. Simple Mail Transfer Protocol 10

VIT/SCOPE/BTECH/CNS-BCSE309L
 SMTP encapsulates an email message in an envelope
and is used to relay the encapsulated messages from
source to destination through multiple MTAs.
 The current revision is RFC 5321
 SMTP is a text-based client-server protocol where the
client (email sender) contacts the server (next-hop
recipient) and issues a set of commands
 The transfer of a message from a source to its
destination can occur over a single SMTP client/server
conversation over a single TCP connection
2. Mail Access Protocols 12

POP3 IMAP
 Post Office Protocol  Internet Mail Access
 Allows an email client to Protocol
download an email from an email  Enables an email client to
server (MTA) access mail on an email
 POP3 user agents connect via server
TCP to the server  Also uses TCP, with server
 After authorization, the UA can TCP port 143
issue POP3 commands to retrieve  Is more complex than
and delete mail POP3
 Provides stronger
authentication and
provides other functions
not supported by POP3
VIT/SCOPE/BTECH/CNS-BCSE309L
2. Mail Access Protocols 13

VIT/SCOPE/BTECH/CNS-BCSE309L
 Post Office Protocol (POP3) allows an email client (user agent)
to download an email from an email server (MTA).
 POP3 user agents connect via TCP to the server (typically port
110).
 The user agent enters a username and password.
 After authorization, the UA can issue POP3 commands to
retrieve and delete mail.
 Internet Mail Access Protocol (IMAP) also enables an email
client to access mail on an email server.
 IMAP also uses TCP, with server TCP port 143.
 IMAP is more complex than POP3.
 IMAP provides stronger authentication than POP3 and provides
other functions not supported by POP3.
14

VIT/SCOPE/BTECH/CNS-BCSE309L
MIME
Formats
Email

RFC 5322
RFC 5322((Internet Message 15

Format)

VIT/SCOPE/BTECH/CNS-BCSE309L
 RFC 5322 defines a format for text messages that are sent
using electronic mail.
 It has been the standard for Internet-based text mail
messages and remains in common use.
 In the RFC 5322 context, 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.
 The RFC 5322 standard applies only to the contents.
RFC 5322 … 16

VIT/SCOPE/BTECH/CNS-BCSE309L
 A message consists of some number of header lines
(the header) followed by unrestricted text (the
body).
 A header line usually consists of a keyword, followed
by a colon, followed by the keyword’s arguments
 The format allows a long line to be broken up into
several lines.
 The most frequently used keywords are From, To,
Subject, and Date.
 Another common field in RFC 5322 headers is
Message-ID. This field contains a unique identifier
RFC 5322 … 17

VIT/SCOPE/BTECH/CNS-BCSE309L
 An Example Message
Limitations of the SMTP/5322 20

scheme

VIT/SCOPE/BTECH/CNS-BCSE309L
 SMTP cannot transmit executable files or other binary
objects.
 SMTP cannot transmit text data that includes national
language characters
 SMTP servers may reject mail message over a certain size
 SMTP gateways do not use consistent set of mappings
 SMTP gateways to X.400 electronic mail networks cannot
handle nontextual data included in X.400 messages.
Multipurpose Internet Mail 21

Extension (MIME)

VIT/SCOPE/BTECH/CNS-BCSE309L
 MIME is an extension to the RFC 5322 framework to
address some of the problems and limitations of the
use of SMTP or some other mail transfer protocol and
RFC 5322 for electronic mail.
 RFCs 2045 through 2049 define MIME
Overview of MIME 22

VIT/SCOPE/BTECH/CNS-BCSE309L
 The 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.
Overview of MIME… 23

VIT/SCOPE/BTECH/CNS-BCSE309L
 MIME header fields
 MIME-Version
 Content-Type
 Content-Transfer-Encoding
 Content-ID
 Content-Description
The Five Header Fields Defined in 24

MIME

VIT/SCOPE/BTECH/CNS-BCSE309L
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
 25

VIT/SCOPE/BTECH/CNS-BCSE309L
MIME Content Types
MIME Content Types… 26

VIT/SCOPE/BTECH/CNS-BCSE309L
 For the text type of body, no special software is required to get the full
meaning of the text aside from support of the indicated character set.
 The multipart type indicates that the body contains multiple,
independent parts
 There are four subtypes of the multipart type:
 Multipart/mixed subtype is used when there are multiple independent body
parts that need to be bundled in a particular order.
 For the Multipart/parallel subtype, the order of the parts is not significant. If the
recipient’s system is appropriate, the multiple parts can be presented in
parallel.
 For the multipart/alternative subtype, the various parts are different
representations of the same information.
 The multipart/digest subtype is used when each of the body parts is interpreted
as an RFC 5322 message with headers.
MIME Content Types… 27

VIT/SCOPE/BTECH/CNS-BCSE309L
 The message type provides a number of important capabilities in
MIME.
 Message/rfc822 subtype indicates that the body is an entire
message, including header and body
 Message/partial subtype enables fragmentation of a large
message into a number of parts, which must be reassembled at the
destination
 Message/external-body subtype indicates that the actual data to
be conveyed in this message are not contained in the body. Instead,
the body contains the information needed to access the data.
 The application type refers to other kinds of data, typically either
uninterpreted binary data or information to be processed by a mail-
based application.
MIME TRANSFER ENCODINGS 28

VIT/SCOPE/BTECH/CNS-BCSE309L
 Two methods of encoding data
 The quoted-printable transfer encoding is useful when the
data consists largely of octets that correspond to printable ASCII
characters
 The base64 transfer encoding, also known as radix-64
encoding, is for encoding arbitrary binary data in such a way as
to be invulnerable to the processing by mail-transport programs
 The Content Transfer-Encoding field can actually take on six
value
Formats 29

VIT/SCOPE/BTECH/CNS-BCSE309L
Native Form Canonical Form
  The entire body, including out-
The body to be transmitted is
created in the system’s native of-band information such as
format record lengths and possibly file
attribute information, is
 The native character set is used converted to a universal
and, where appropriate, local canonical form
end-of-line conventions are used
as well  The specific media type of the
body as well as its associated
 The body may be any format attributes dictates the nature of
that corresponds to the local
the canonical form that is used
model for the representation of
some form of information  Conversion to the proper
 canonical form may involve
Examples include a UNIX-style
text file, or a Sun raster image,
character set conversion,
or a VMS indexed file, and audio transformation of audio data,
data in a system-dependent compression, or various other
format stored only in memory operations specific to the
various media types
Canonical form 30

VIT/SCOPE/BTECH/CNS-BCSE309L
 Canonical form is a format, appropriate to the content
type, that is standardized for use between systems.
 Native form is a format that may be peculiar to a
particular system.
Email Threats and 31

Comprehensive Email Security

VIT/SCOPE/BTECH/CNS-BCSE309L
 Authenticity-related threats: Could result in
unauthorized access to an enterprise’s email system.
 Integrity-related threats: Could result in
unauthorized modification of email content.
 Confidentiality-related threats: Could result in
unauthorized disclosure of sensitive information.
 Availability-related threats: Could prevent end
users from being able to send or receive email
 32
Email Threats and Mitigations
Impact on Purported
Threat Impact on Receiver Mitigation
Sender

Loss of reputation, valid Deployment of domain-

Email sent by UBE and/or email
email from enterprise based authentication
unauthorized MTA in containing malicious
may be blocked as techniques. Use of
enterprise (e.g. links may be delivered
possible spam/phishing digital signatures over
malware botnet) into user inboxes
attack. email.

Loss of reputation, valid

UBE and/or email Deployment of domain-
Email message sent email from enterprise
containing malicious based authentication
using spoofed or may be blocked as
links may be delivered techniques. Use of
unregistered sending possible spam/phishing
into user inboxes digital signatures over
domain attack.
email.

Email message sent UBE and/or email

Loss of reputation, valid Deployment of domain-
using forged sending containing malicious
email from enterprise based authentication
address or email links may be delivered.
may be blocked as techniques. Use of
address (i.e. Users may inadvertently
possible spam/phishing digital signatures over
phishing, spear divulge sensitive
attack. email.
phishing) information or PII.

(Table can be found on page 587 in the textbook)

Protocols against Email Threats 33

VIT/SCOPE/BTECH/CNS-BCSE309L
 SP 800-177 recommends the use of a variety of
standardized protocols as a means for countering these
threats.
1. STARTTLS
2. S/MIME
3. DNS Security Extensions (DNSSEC)
4. DNS-based Authentication of Named Entities (DANE)
5. Sender Policy Framework (SPF)
6. DomainKeys Identified Mail (DKIM)
7. Domain-based Message Authentication, Reporting, and
Conformance (DMARC)
Secure/Multipurpose Internet 34

Mail Extension (S/MIME)

VIT/SCOPE/BTECH/CNS-BCSE309L
 A security enhancement to the MIME Internet e-mail format standard
based on technology from RSA Data Security
 The most important documents relevant to S/MIME include:
 RFC 5750, S/MIME Version 3.2 Certificate Handling
 RFC 5751, S/MIME Version 3.2 Message Specification
 RFC 4134, Examples of S/MIME Messages
 RFC 2634, Enhanced Security Services for S/MIME
 RFC 5652, Cryptographic Message Syntax (CMS)
 RFC 3370, CMS Algorithms
 RFC 5752, Multiple Signatures in CMS
 RFC 1847, Security Multiparts for MIME – Multipart/Signed and
Multipart/Encrypted
Operational Description 35

VIT/SCOPE/BTECH/CNS-BCSE309L
 S/MIME is defined as a set of additional MIME content
types and provides the ability to sign and/or encrypt e-
mail messages.
 S/MIME provides four message-related services:
 Authentication
 Confidentiality
 Compression
 Email compatibility
36

VIT/SCOPE/BTECH/CNS-BCSE309L
1. Authentication 37

VIT/SCOPE/BTECH/CNS-BCSE309L
 Provided using a digital signature
 The sender creates a message
 SHA-256 is used to generate a 256-bit message digest of the message
 The message digest is encrypted with RSA using the sender’s private key, and
the result is appended to the message. Also appended is identifying information
for the signer, which will enable the receiver to retrieve the signer’s public key
 The receiver uses RSA with the sender’s public key to decrypt and recover the
message digest
 The receiver generates a new message digest for the message and compares it
with the decrypted hash code. If the two match, the message is accepted as
authentic
 Detached signatures are supported
 A detached signature may be stored and transmitted separately from the
message it signs
2. Confidentiality 38

VIT/SCOPE/BTECH/CNS-BCSE309L
 S/MIME provides confidentiality by encrypting messages
 Most commonly AES with a 128-bit key is used, with the cipher
block chaining (CBC) mode
 The key itself is also encrypted, typically with RSA
 Each symmetric key, referred to as a content-encryption key, is used
only once
 A new key is generated as a random number for each message
 Because it is to be used only once, the content-encryption key is
bound to the message and transmitted with it
 To protect the key, it is encrypted with the receiver’s public key
 To reduce encryption time, the combination of symmetric and
public-key encryption is used
 Only the recipient is able to recover the session key that is bound
to the message
39

VIT/SCOPE/BTECH/CNS-BCSE309L
40

VIT/SCOPE/BTECH/CNS-BCSE309L
3. E-mail Compatibility 41

VIT/SCOPE/BTECH/CNS-BCSE309L
 Many electronic mail systems only permit the use of
blocks consisting of ASCII text
 To accommodate this restriction, S/MIME 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 Base-64 conversion
 Each group of three octets of binary data is mapped into four ASCII
characters
 The Base64 algorithm blindly converts the input stream to Base64
format regardless of content, even if the input happens to be ASCII text
 RFC 5751 recommends that even if outer 7-bit encoding is
not used, the original MIME content should be 7-bit
encoded
4. Compression 42

VIT/SCOPE/BTECH/CNS-BCSE309L
 S/MIME offers the ability to compress a message
 This has the benefit of saving space both for email
transmission and for file storage
 Compression can be applied in any order with respect to
the signing and message encryption operations
 RFC 5751 provides these guidelines:
 Compression of binary encoded encrypted data is
discouraged, since it will not yield significant compression;
Base64 encrypted data could very well benefit, however
 If a lossy compression algorithm is used with signing, you will
need to compress first, then sign
S/MIME Message Content Types 43

VIT/SCOPE/BTECH/CNS-BCSE309L
 Defined in RFC 5652, Cryptographic Message Syntax
 Data: Refers to the inner MIME-encoded message content,
which may then be encapsulated in a SignedData,
EnvelopedData, or CompressedData content type
 SignedData: Used to apply a digital signature to a message
 EnvelopedData: This consists of encrypted content of any
type and encrypted content encryption keys for one or more
recipients
 CompressedData : Used to apply data compression to a
message
S/MIME Message Content Types… 44

VIT/SCOPE/BTECH/CNS-BCSE309L
 TheData content type is also used for a
procedure known as clear signing.
 A digital signature is calculated for a MIME-encoded
message and the two parts, the message and
signature, form a multipart MIME message
 Can be read and their signatures verified by email
entities that do not implement S/MIME
Securing a MIME Entity 45

VIT/SCOPE/BTECH/CNS-BCSE309L
 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 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 46

VIT/SCOPE/BTECH/CNS-BCSE309L
 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 47

VIT/SCOPE/BTECH/CNS-BCSE309L
 The steps for preparing a signedData
MIME are:

Prepare a
block known
Encrypt the as SignerInfo
message that contains
digest with the signer’s
the signer’s public-key
Compute the private key certificate, an
message identifier of
digest (hash the message
function) of the digest
content to be algorithm, an
signed identifier of
Select a the algorithm
message used to
digest encrypt the
algorithm message
(SHA or digest, and
MD5) the encrypted
message
digest
Clear Signing 48

VIT/SCOPE/BTECH/CNS-BCSE309L
 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 49

VIT/SCOPE/BTECH/CNS-BCSE309L
 S/MIME uses public-key certificates that conform to
version 3 of X.509
 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 50

 An S/MIME user has several key-management functions to

VIT/SCOPE/BTECH/CNS-BCSE309L
perform:
Certificate
Key generation Registration storage and
retrieval

The user of some related A user’s public key A user requires

administrative utility must be registered with access to a local list
must be capable of a certification authority of certificates in
generating separate in order to receive an order to verify
Diffie-Hellman and DSS X.509 public-key incoming signatures
key pairs and should be certificate and to encrypt
capable of generating outgoing messages
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
Enhanced Security Services 51

VIT/SCOPE/BTECH/CNS-BCSE309L
 RFC 2634 defines four enhanced security services for
S/MIME:
 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
 Signing certificates: This service is used to securely bind a
sender’s certificate to their signature through a signing certificate
attribute
 52

VIT/SCOPE/BTECH/CNS-BCSE309L
Pretty Good Privacy(PGP)
LEARN FROM PDF
Pretty Good Privacy(PGP) 53

VIT/SCOPE/BTECH/CNS-BCSE309L
 In 1996, version 5.x of PGP was defined in IETF RFC 1991, PGP Message
Exchange Formats.
 Subsequently, OpenPGP was developed as a new standard protocol based
on PGP version 5.x.
 OpenPGP is defined in RFC 4880 (OpenPGP Message Format, November
2007) and RFC 3156 (MIME Security with OpenPGP, August 2001)
 There are two significant differences between S/MIME
and OpenPGP:
 Key Certification
 Key Distribution
 NIST 800-177 recommends the use of S/MIME rather than PGP because of
the greater confidence in the CA system of verifying public keys.
 54

VIT/SCOPE/BTECH/CNS-BCSE309L
Secure Electronic
Transaction(SET)
LEARN FROM PDF
Secure Electronic 55

Transaction(SET)

VIT/SCOPE/BTECH/CNS-BCSE309L
 SET is an open encryption and security specification
designed to protect credit card transactions on the
Internet.
 SET provides three services:
1. Provides a secure communications channel among all
parties involved in a transaction
2. Provides trust by the use of X.509v3 digital certificates
3. Ensures privacy because the information is only
available to parties in a transaction when and where
necessary
Topics to be learned 56

VIT/SCOPE/BTECH/CNS-BCSE309L
 Requirements
 Key Features of SET
 SET Participants
 Payment Processing
 Purchase Request
 Payment Authorization
 Payment Capture
Secure Electronic Commerce Components 57

VIT/SCOPE/BTECH/CNS-BCSE309L
Construction of Dual Signature 58

VIT/SCOPE/BTECH/CNS-BCSE309L
Cardholder Sends Purchase Request 59

VIT/SCOPE/BTECH/CNS-BCSE309L
Merchant Verifies Customer Purchase Request 60

VIT/SCOPE/BTECH/CNS-BCSE309L