Cryptography

Cryptography and NetworkSecurity

and Network Security

Unit V – Email Security

PGP , S/MIME

CSE - AVCCE 1
 Email Security

Pretty Good Privacy (PGP)

S/MIME

CSE - AVCCE 2
 Introduction

• Email is one of the most heavily used network-based application.

• There are two widely used schemes for providing authentication and
confidentiality for email security, PGP and S/MIME.
PGP
• PGP provides a confidentiality and authentication service that can be
used for file storage and electronic mail applications.
• PGP was developed be Phil Zimmermann in 1991.

The preliminary steps for PGP are

• Select the best cryptographic algorithm
• Integrate the algorithms into a general purpose application,independent
of operating systems and processors.
• Make the package available on the internet.

CSE - AVCCE 3
 PGP

PGP is the most widely used standard, because

• It is available as free version.

• Can be used on all platforms (windows. UNIX).
• It is based on extremely secure algorithm like RSA, DSS,
DiffieHellman,3DES, SHA1.
• It is not controlled by any organization.

CSE - AVCCE 4
 PGP – Operational description
• The actual operation of PGP consists of five services:
– authentication,
– confidentiality,
– compression,
– e-mail compatibility
– segmentation and Reassembly(Table 12.1.)

Authenticaiton
– The sender creates a message
– SHA-1 is used to generate 160-bit hash code
– Hash code is encrypted with RSA using senders private key
– Receiver uses RSA to decrypt the hash code
– Receiver generates a new hash code and compares with the
decrypted one

CSE - AVCCE 5
CSE - AVCCE 6
Confidentiality

• The steps to obtain confidentiality are as follows

– The sender generates a message and a random 128-bit number
called the session key
– The message is encrypted with CAST-128
– The session key is encrypted with recipients’ public key using
RSA
– The recipient uses RSA with its private key to decrypt the session
key
– The session key decrypts the message

CSE - AVCCE 7
Confidentiality and Authentication

• To have both confidentiality and authentication

– The sender first signs the message using it’s own
private key
– Then encrypts the message with the session key
– Then encrypts the session key with the recipient’s
public key

CSE - AVCCE 8
Compression

• As a default PGP compresses the message after the signature but

before encryption (Fig 12.1. compression and decompression are noted
as Z and Z-1)
The signature is generated before compression
– it now suffices to store only the plaintext version plus signature for
later verification.
Message encryption is after compression
• Message encryption is applied after compression to strenghten
cryptographic security.
– compressed message has less redundancy making cryptanalysis
more difficult.

CSE - AVCCE 9
 E-mail compatibility
• Encrypted parts of the message form a stream of 8-bit octets.
• PGP converts the 8 bit binary blocks into printable ASCII characters.
This is called radix-64 conversion
• Each groupof 3 octets(8x3) is divided into four 6-bit blocks(6x4)
• Each 6-bit is replaced with ASCII character.
• 8-bit 00100011 01011100 10010001
• 6-bit 001000 110101 110010 010001
• Decimal 8 53 50 17
• Char. I 1 y R

6-bit value Char.

0-25 A-Z
26-51 a-z
52-61 0 - 9

CSE - AVCCE 62 + 10
Radix-64 blindly converts the input stream into ASCII even if the input is
an ASCII character. So the message will be unreadable to a normal person
which provides some confidentiality.

Segmentation and reassembly

• Email accepts a maximum message length of 50,000 octets.
• So PGP automatically subdivides messages into segments that are
small enough to be sent via email.
• At the receiving end, PGP must strip off all email headers and
reassemble the entire original block.

CSE - AVCCE 11
CSE - AVCCE 12
CSE - AVCCE 13
 Introduction

• S/MIME (Secure / Multipurpose Internet Mail Extension) is the

industry standard for secure mail over the Internet. Secure MIME
(S/MIME) was developed by an industry consortium, and is now
appearing in a number of major products.
• a security enhancement to MIME
• provides similar services to PGP
• based on technology from RSA Security

The two earlier standards for E-mail were:

– RFC 822
– MIME

CSE - AVCCE 14
 RFC 822
• defines a format for text messages to be sent using e-mail
• The msg. consists of header and body(text). Both are separated by
blank line.
• structure of RFC 822 messages:
- header lines (e.g., from: …, to: …, cc: …)
– blank line
– body (the text to be sent)
• example

Date: Tue, 16 Jan 1998 10:37:17 (EST)

From: “Levente Buttyan” <[email protected]>
Subject: Test
To: [email protected]

Blablabla
CSE - AVCCE 15
 Problems with RFC 822 and SMTP

• can’t transmit .exe / binary files

• a standard is needed
• SMTP is limited to 7-bit ASCII. Characters which are represented by
8-bit codes cannot be sent.
• text data that includes special characters (e.g., Hungarian text)
• doesn’t support the messages in language without alphabets (chinese)
• doesn’t support the messages containing audio/video
• Translation between ASCII and EBCDIC is not consistent.
• Large mail messages can be rejected.
• Formatting used in msg. like linefeed, tabs is not reflected.
– truncate or wrap lines longer than 76 characters
– remove trailing white space (tabs and spaces)

CSE - AVCCE 16
 MIME
• MIME is an extension to the RFC 822 addressing many limitations of
the use of SMTP.
• defines new message header fields
• defines a number of content formats (standardizing representation of
multimedia contents)
• defines transfer encodings that protects the content from alteration by
the mail system
• The MIME content types are listed in table 12.3.

• MIME consists of 3 basic elements

• Header fields
• Content formats
• Transfer encodings

CSE - AVCCE 17
 MIME - Header fields
There are 5 header fields
• MIME-Version
• Content-Type
– describes the data contained in the body
– receiving agent can pick an appropriate method to represent the
content
• Content-Transfer-Encoding
– indicates the type of the transformation that has been used to
represent the body of the message (e.g) radix 64
• Content-ID
– Unique identification of MIME entities
• Content-Description
– description of the object in the body of the message
– useful when content is not readable (e.g., audio data)
CSE - AVCCE 18
18
In general, multi part has more parts. Each part has a parameter called
boundary. Each boundary starts on a new line indicated by 2 hyphens(--)
The last boundary has structure --boundary --
CSE - AVCCE 19
 MIME – Transfer encodings
Transfer encodings for msg. body is necessary to provide reliable delivery
over large environments.
• 7bit
– short lines of ASCII characters
• 8bit
– short lines of non-ASCII characters
• binary
– non-ASCII characters
– lines are not necessarily short
• quoted-printable
– non-ASCII characters are converted into hexa numbers (e.g., =EF)
• base64 (radix 64)
– 3 8-bit blocks into 4 6-bit blocks
• x-token
– non-standard encoding
CSE - AVCCE 20
20
 MIME – Example
MIME-Version: 1.0
From: Nathaniel Borenstein <[email protected]>
To: Ned Freed <[email protected]>
Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
Subject: A multipart example
Content-Type: multipart/mixed; boundary=unique-boundary-1

This is the preamble area of a multipart message. Mail readers that understand multipart format
should ignore this preamble. If you are reading this text, you might want to consider changing to a mail reader
that understands how to properly display multipart messages.

--unique-boundary-1
Content-type: text/plain; charset=US-ASCII

… Some text …

--unique-boundary-1
Content-Type: multipart/parallel; boundary=unique-boundary-2

--unique-boundary-2
Content-Type: audio/basic
Content-Transfer-Encoding: base64

... base64-encoded 8000 Hz single-channel mu-law-format audio data goes here ...

--unique-boundary-2
Content-Type: image/jpeg
Content-Transfer-Encoding: base64

... base64-encoded image data goes here ...

--unique-boundary-2--

CSE - AVCCE 21
21
 MIME – Example cont’d
--unique-boundary-1
Content-type: text/enriched

This is <bold><italic>enriched.</italic></bold><smaller>as defined in RFC 1896</smaller>

Isn’t it <bigger><bigger>cool?</bigger></bigger>

--unique-boundary-1
Content-Type: message/rfc822

From: (mailbox in US-ASCII)

To: (address in US-ASCII)
Subject: (subject in US-ASCII)
Content-Type: Text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: Quoted-printable

... Additional text in ISO-8859-1 goes here ...

--unique-boundary-1--

CSE - AVCCE 22
22
 S/MIME Functionality
• The general functionality of S/MIME is very similar to PGP both
offering the ability to sign and/or encrypt messages.
S/MIME Functions

• enveloped data (application/pkcs7-mime; smime-type = enveloped-

data)
– Both body and encryption keys are encrypted
• signed data (application/pkcs7-mime; smime-type = signed-data)
– standard digital signature (“hash and sign”)
– content + signature is encoded using base64 encoding
• clear-signed data (multipart/signed)
– standard digital signature
– only the signature is encoded using base64
– recipient without S/MIME capability can read the message but
cannot verify the signature
• signed and enveloped data
–CSEsigned
- AVCCE
and encrypted entities may be nested in any order 23
23
CSE - AVCCE 24
 S/MIME – cryptographic algorithms

• The used algorithms are summarized in table 12.6.

• There are two requirement levels:
MUST - means an absolute requirement in order to be in conformance
with the specification.
SHOULD - This is a recommended requirement.
.

CSE - AVCCE 25
CRYPTOGRAPHIC ALGORITHMS
• message digest
– must: SHA-1
– should (receiver): MD5 (backward compatibility)
• digital signature
– must: DSS
– should: RSA
• asymmetric-key encryption
– must: ElGamal
– should: RSA
• symmetric-key encryption
– sender:
• should: 3DES, RC2/40
– receiver:
• must: 3DES
• should: RC2/40
CSE - AVCCE 26
CSE - AVCCE 27
The sending agent must consider 2 issues:
• Whether receiver is capable of decrypting his algorithm
• If receiver can accept only weak algorithm, sender must decide
whether it can allowed.

For this Sender and receiver must have preference list of encryption alg.
used.
The rules to be followed by sending agent are
• If the sender has preference list of receiver, it should choose the top
alg. in the list.
• If there is no list , sender should use the same alg. which was used in
last transaction
• If sender has no knowledge about receiver , but it is willing to take
risk, Sender Should use 3DES .
• If sender has no knowledge about receiver , but it is not willing to take
risk, Sender Should use RC2/40 .
CSE - AVCCE 28
 Securing a MIME entity

• S/MIME secures a MIME entity with a signature and encryption.

• A normal MIME entity with security info like algorithm identifiers &
certificates is processed by S/MIME and produces PKCS
(Public Key Cryptography Specification) object.
• the PKCS object is treated as message and wrapped with appropriate
MIME headers. Finally the message is converted to canonical form
suitable for the given message type and subtype.

• Canonical form:
Format that is standardized for all types of system. It is
appropriate to content type

29 CSE - AVCCE 29
 S/MIME Content Types

• The various content types are

– Enveloped data
– Signed data
– Clear signed data
– Registration request for certificates
– Certificate-only message

CSE - AVCCE 30
• Enveloped data
– The steps for preparing this entity are
Sender End
1) Generate the pseudo random session key.
2) Encrypt the session key with recipients public RSA key.
3) Prepare a RecipientInfo block containing recepient’s certificate
ID, Encryption algorithm ID and the encrypted session key.
4) Encrypt the message content with the session key.
5) This information is then encoded into radix-64
Receiver End
1) First cut-off radix64 encoding
2) Receiver private key is used to recover the session key.
3) Session key is used to recover the message.

CSE - AVCCE 31
 PKCS7 “enveloped data”

Version

Originator Info Version

Recipient ID (issuer and s.no.)

Recipient Info
Key Encryption Algorithm

Encrypted Key

Encrypted Content Info Content type

Content Encryption Alg.

Encrypted Content

32 CSE - AVCCE 32
 Enveloped data – Example
Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7m

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
0GhIGfHfQbnj756YT64V

33 CSE - AVCCE 33
• Signed data

Sender End
1) Select a message digest algorithm.
2) Compute the MD of msg. Content.
3) Encrypt the message digest with senders private key
4) Prepare SignerInfo block containing
• signer’s public key certificate
• message digest algorithm ID
• Encryption algorithm ID and
• encrypted message digest.
5) This information is then encoded into radix-64
Receiver End
1) Cut-off radix64
2) Sender’s public key is used to decrypt the MD
3) Receiver calculates the MD seperately
4) Both are compared to verify the signature
CSE - AVCCE 34
 PKCS7 “signed data”

Content type

Content

Version

Signer ID (issuer and ser. no.)

Digest Algorithm

Authenticated Attributes

Digest Encryption Alg.

Encrypted digest (signature)

35 CSE - AVCCE 35
• Clear signed data

Sender End
It belongs to multipart/signed type. The msg has 2 parts
– First part contains clear message.
– Second part contains encrypted message digest. And this is
encoded using radix64
Receiver End

• Calculates MD from the first part (clear message)

• Recover the MD from the second part.
• Compares both the MD.

CSE - AVCCE 36
 Clear-signed data – Example
Content-Type: multipart/signed; protocol="application/pkcs7-signature";
micalg=sha1; boundary=boundary42

--boundary42
Content-Type: text/plain

This is a clear-signed message.

--boundary42
Content-Type: application/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=smime.p7s

ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
7GhIGfHfYT64VQbnj756

--boundary42--

37 CSE - AVCCE 37
 S/MIME Functionality

• Registration request
– A user typically applies to a CA for a public-key certificate.
Application/PKS10 entity is used to transfer a certification request
– It contains a certification RequestInfo block- name of the certificate user,
public key, encryption algorithm ID.
• Certificates-only message
– This is sent as response to registration request.
– Either a certificate (or) CRL can come as response
– Content type is application/pkcs7mime(degenerate)

CSE - AVCCE 38
 S/MIME – Certificate Processing

• S/MIME users must configure each client with a list of trusted keys
and certificate revocation lists.
– the responsibility for maintaining certificates needed to verify incoming
messages and encrypt outgoing ones is local.
– however, the cerificates are signed by certification authorities.
User’s role
• An S/MIME user has several key-management functions to perform
• Key generation: the user MUST be able to generate DSS and D-H key
pairs and SHOULD be able to generate RSA key pairs. Key size must
be >512 bits
• Registration: a user’s public key must be registered with a CA in order
to receive an X.509 certificate.
• Certificate storage and retrieval: a list of certificates can be
maintained by the user locally

CSE - AVCCE 39