Electronic mail security

1
 Pretty good privacy
 S/MIME

2
 Philip R. Zimmerman is the creator of PGP.
 PGP provides a confidentiality and
authentication service that can be used for
electronic mail and file storage applications.

Henric Johnson 3
 Zimmermann has done the following:

◦ 1. Selected the best available cryptographic algorithms

as building blocks.
◦ 2. 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.
◦ 3. Made the package and its documentation, including
the source code, freely available via the Internet, bulletin
boards, and commercial networks such as AOL (America
On Line).
◦ 4. Entered into an agreement with a company (Viacrypt,
now Network Associates) to provide a fully compatible,
low-cost commercial version of PGP.
 It is availiable free on a variety of platforms.
 Based on well known algorithms.
 Wide range of applicability
 Not developed or controlled by governmental
or standards organizations

Henric Johnson 5
 The actual operation of PGP, Consist of five
services:
◦ Authentication
◦ Confidentiality
◦ Compression
◦ E-mail compatibility
◦ Segmentation

7
 The sender creates a message.
 SHA-1 is used to generate a 160-bit hash code
of the message.
 The hash code is encrypted with RSA using the
sender’s private key, and the result is prepended
to the message.
 The receiver uses RSA with the sender’s public
key to decrypt and recover the hash code.
 The receiver generates a new hash code for the
message and compares it with the decrypted
hash code. If the two match, the message is
accepted as authentic.

8
 The sender generates a message and a random
128-bit number to be used as a session key for
this message only.
 The message is encrypted using CAST-128 (or
IDEA or 3DES) with the session key.
 The session key is encrypted with RSA using the
recipient’s public key and is prepended to the
message.
 The receiver uses RSA with its private key to
decrypt and recover the session key.
 The session key is used to decrypt the message.

9
10
 PGP compresses the message after applying
the signature but before encryption
 The placement of the compression algorithm
is critical.
 The compression algorithm used is ZIP

11
 The signature is generated before
compression for two reasons:
◦ It is preferable to sign an uncompressed message
so that one can store only the uncompressed
message together with the signature for future
verification.
◦ Message encryption is applied after compression to
strengthen cryptographic security. Because the
compressed message has less redundancy than the
original plaintext

12
 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 is radix-64 conversion
 The use of radix-64 expands the message by
33%.

13
 Both PGP and S/MIME make use of an
encoding technique.
 This technique maps arbitrary binary input
into printable character output.
 The form of encoding has the following
relevant characteristics:

14
 The range of the function is a character set
that is universally representable at all sites,
not a specific binary encoding of that
character set.
 The character set consists of 65 printable
characters, one of which is used for padding.
With 26=64 available characters, each
character can be used to represent 6 bits of
input.
 No control characters are included in the set.
 The hyphen character “-” is not used. This
character has significance in the RFC 5322
format and should therefore be avoided.

15
16
 Table shows the mapping of 6-bit input values to
characters.
 The character set consists of the alphanumeric
characters plus “+ ” and “/”. The “= ” character is
used as the padding character.
 Binary input is processed in blocks of 3 octets (24
bits).
 Each set of 6 bits in the 24-bit block is mapped into a
character.
 In the figure, the characters are shown encoded as 8-
bit quantities.
 In this typical case, each 24-bit input is expanded to
32 bits of output.

17
18
 For example,
◦ consider the 24-bit raw text sequence 00100011
01011100 10010001, which can be expressed in
hexadecimal as 235C91.We arrange this input in
blocks of 6 bits:
◦ 001000 110101 110010 010001 = 8 53 50 17
◦ Looking these up in Table yields the radix-64
encoding as the following characters: I1yR. If
these characters are stored in 8-bit ASCII format
with parity bit set to zero, we have
◦ 01001001 00110001 01111001 01010010

19
20
 Often restricted to a maximum message
length of 50,000 octets.
 Longer messages must be broken up into
segments.
 PGP automatically subdivides a message that
is to large.
 The receiver strip of all e-mail headers and
reassemble the block.

21
22
23
 Secure/Multipurpose Internet Mail Extension
 S/MIME will probably emerge as the industry
standard.
 PGP for personal e-mail security
 a security enhancement to MIME
 provides similar services to PGP
 based on technology from RSA Security
 industry standard for commercial and
organizational use
 RFC 2630, 2632, 2633

24
 defines a format for text messages to be sent
using e-mail
 Internet standard
 structure of RFC 822 compliant 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
25
 SMTP Limitations - Can not transmit, or has a
problem with:
◦ executable files, or other binary files (jpeg
image)
◦ “national language” characters (non-ASCII)
◦ messages over a certain size
◦ ASCII to EBCDIC translation problems
◦ lines longer than a certain length (72 to 254
characters)

26
 some servers
◦ reject messages over a certain size
◦ delete, add, or reorder CR and LF characters
◦ truncate or wrap lines longer than 76 characters
◦ remove trailing white space (tabs and spaces)
◦ pad lines in a message to the same length
◦ convert tab characters into multiple spaces

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

28
 MIME-Version: Must be “1.0” -> RFC 2045, RFC 2046
 Content-Type: More types being added by developers
(application/word)
◦ describes the data contained in the body
◦ receiving agent can pick an appropriate method to
represent the content
 Content-Transfer-Encoding: How message has been
encoded (radix-64)
 Content-ID: Unique identifying character string.
 Content Description:
◦ description of the object in the body of the message
◦ useful when content is not readable (e.g., audio data)

29
30
31
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--
32
--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--

33
 Enveloped Data: Encrypted content and
encrypted session keys for recipients.
 Signed Data: Message Digest encrypted with
private key of “signer.”
 Clear-Signed Data: Signed but not
encrypted.
 Signed and Enveloped Data: Various
orderings for encrypting and signing.

34
 Message Digesting: SHA-1 and MDS
 Digital Signatures: DSS
 Secret-Key Encryption: Triple-DES, RC2/40
(exportable)
 Public-Private Key Encryption: RSA with key
sizes of 512 and 1024 bits, and Diffie-
Hellman (for session keys).

35
 S/MIME secures a MIME entity with a signature,
encryption, or both.
 A MIME entity may be an entire message or one or more
of the subparts of the message.
 The MIME entity plus some security related data, such
as algorithm identifiers and certificates, are processed
by S/MIME to produce a PKCS, which refers to a set of
public-key cryptography specifications issued by RSA
Laboratories.
 A PKCS object is then treated as message content and
wrapped in MIME.

36
 Have a range of S/MIME content-types, as
shown.
◦ enveloped data
◦ signed data
◦ clear-signed data
◦ registration request
◦ certificate only message

37
38
 enveloped data (application/pkcs7-mime; smime-type =
enveloped-data)
◦ standard digital envelop
 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
◦ signed and encrypted entities may be nested in any order

39
 Registration Request
◦ Typically, an application or user will apply to a
certification authority for a public-key certificate.
◦ The application/pkcs10 S/MIME entity is used to
transfer a certification request.
 Certificates-only Message
◦ A message containing only certificates or a
certificate revocation list (CRL) can be sent in
response to a registration request.
◦ The message is an application/pkcs7-mime
type/subtype with an smime-type parameter of
degenerate.

40
 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.

41
 S/MIME user several key management functions to
performs:
◦ Key Generation - Diffie-Hellman, DSS, and RSA key-pairs.
◦ Registration - Public keys must be registered with X.509
CA.
◦ Certificate Storage - Local (as in browser application) for
different services.
◦ Signed and Enveloped Data - Various orderings for
encrypting and signing.

42
 Example: Verisign (www.verisign.com)
◦ Class-1: Buyer’s email address confirmed by
emailing vital info.
◦ Class-2: Postal address is confirmed as well, and
data checked against directories.
◦ Class-3: Buyer must appear in person, or send
notarized documents.

43