UNIT-IV
(Email privacy: Pretty Good Privacy (PGP) and S/MIME)
LEARNINIG OBJECTIVES
At the End of this UNIT student should be able to:








Define electronic mail security
List and explain PGP notations
Explain PGP operational descriptions
Describe public key management
Explain RFC 822
Define MIME
Explain about MIME functionality and certificate processing
List the enhanced security services
1
Introduction:
The Internet is an expansive network of computers, much of which is unprotected against
malicious attacks. From the time it is composed to the time it is read, e-mail travels along this
unprotected Internet, perpetually exposed to electronic dangers. Many users believe that e-mail
privacy is inherent and guaranteed, psychologically equating it with postal mail. While e-mail is
indeed conventionally secured by a password system, the one layer of protection is not secure,
and generally insufficient to guarantee appreciable security. Businesses are increasingly relying
on electronic mail to correspond with clients and colleagues. As more sensitive information is
transferred online, the need for e-mail privacy becomes more pressing.
E-mail is vulnerable to both passive and active attacks.
Passive threats include Release of message contents, and Traffic analysis while active threats
include Modification of message contents, Masquerade, Replay, and Denial of Service (DoS).
Actually, all the mentioned threats are applicable to the traditional e-mail protocols:

Disclosure of Information: Most of e-mails are currently transmitted in the clear (not
encrypted). By means of some available tools, persons other than the designated recipients can
read the e-mail contents.

Traffic analysis: It is believed that some countries are routinely monitoring e-mail messages
as part of their Echelon project. This is not just for counter-terrorism reasons but also to facilitate
combat against industrial espionage and to carry out political eavesdropping. However, it is not
devoted to the national agencies since there is a thriving business in providing commercial and
criminal elements with the information within e-mails.

Modification of messages: E-mail contents can be modified during transport or storage. Here,
the man-in-the-middle attack does not necessarily require the control of gateway since an
attacker that resides on the same Local Area Network (LAN), can use an Address Resolution
Protocol (ARP) spoofing tool such as "ettercap" to intercept or modify all the e-mail packets
going to and from the mail server or gateway.

Masquerade: It is possible to send a message in the name of another person or organization.

Replay of previous messages: Previous messages may be resent to other recipients. This may
lead to loss, confusion, or damage to the reputation of an individual or organization. It can cause
some damage if e-mail is used for certain applications such as funds transferring, registration,
and reservation.
2

Spoofing: False messages may be inserted into mail system of another user. It can be
accomplished from within a LAN, or from an external environment using Trojan horses.

Denial of Service: It can put a mail system out of order by overloading it with mail shots. It
can be carried out using Trojan horses or viruses sent to users within the contents of e-mails. It is
also possible to block the user accounts by repeatedly entering wrong passwords in the login.
To provide a reasonable level of privacy, all routers in the e-mail pathway, and all connections
between them, must be secured. This is done through data encryption, which translates the email's contents into incomprehensible text that, if designed correctly, can be decrypted only by
the recipient. An industry-wide push toward regular encryption of e-mail correspondence is slow
in the making. However, there are certain standards that are already in place which some services
have begun to employ.
There are two basic techniques for providing such secure connections. The electronic
envelope technique involves encrypting the message directly using a secure encryption standard
such as Open PGP (Public key infrastructure) or S/MIME. These encryption methods are often a
user-level responsibility, even though Enterprise versions of Open PGP exist. The usage of Open
PGP requires the exchange of encryption keys. Even if the encrypted emails are intercepted and
accessed, its contents are meaningless without the encryption key. This method is also
sometimes tied with authentication. Authentication just means that each user must prove who
they are by using either a password, biometric (such as a fingerprint), or other standard
authentication means. The second approach is to send an open message to the recipient which
contains no sensitive content but which announces a message waiting for the recipient on the
sender's secure mail facility. The recipient then follows a link to the sender's secure website
where the recipient must log in with a username and password before being allowed to view the
message.
At the ISP level, a further level of protection can be implemented by encrypting the
communication between servers themselves, usually employing an encryption standard
called Transport Layer Security (TLS). It is coupled with Simple Authentication and Security
Layer (SASL), which confirms the target router's identity. This ensures that unintended servers
don't end up with a copy of the e-mail, which happens frequently in the course of normal
correspondence. Although many ISPs have implemented secure sending methods, users have
been slow to adopt the habit, citing the esoteric nature of the encryption process. Without user
participation, e-mail is only protected intermittently from intrusion.
3
Pretty Good Privacy (PGP) is a data encryption and decryption computer program that
provides cryptographic privacy and authentication for data communication. PGP is often used for
signing, encrypting and decrypting e-mails to increase the security of e-mail communications. It
was created by Philip Zimmermann in 1991. PGP encryption uses a serial combination
of hashing, data
compression, symmetric-key
cryptography,
and,
finally, public-key
cryptography; each step uses one of several supported algorithms.
Why PGP is popular:

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
Operational description: Consist of five services:

Authentication

Confidentiality

Compression

E-mail compatibility

Segmentation
The following diagram shows how we are achieving authentication and confidentiality
4
This is a digital signature scheme with hashing.
1. Alice has (private/public) key pair (Ad/Ae) and she wants to send a digitally signed
message m to Bob.
2. Alice hashes the message using SHA-1 to obtain
SHA(m).
3. Alice encrypts the hash using her private key Ad to obtain ciphertext c given by
c=pk.encryptAd(SHA(m))
4. Alice sends Bob the pair (m,c)
5. Bob receives (m,c) and decrypts c using Alice's public key Ae to obtain signature s
s=pk.decryptAe(c)
6. He computes the hash of m using SHA-1 and if this hash value is equal to s then the
message is authenticated.
Bob is sure that the message is correct and that is does come from Alice. Furthermore Alice
cannot later deny sending the message since only Alice has access to her private key Ad which
works in conjunction with the public key Ae.
PGP Confidentiality:
1. Alice wishes to send Bob a confidential message m.
2. Alice generates a random session key k for a symmetric cryptosystem.
3. Alice encrypts k using Bob’s public key Be to get
k’ = pk.encryptBe(k)
4. Alice encrypts the message m with the session key k to get ciphertext c
c=sk.encryptk(m)
5. Alice sends Bob the values (k’,c)
6. Bob receives the values (k’,c) and decrypts k’ using his private key Bd to obtain k
k=pk.decryptBd(k’)
7. Bob uses the session key k to decrypt the ciphertext c and recover the message m
m=sk.decryptk(c)
5
Public and symmetric key cryptosystems are combined in this way to provide security for
key exchange and then efficiency for encryption. The session key k is used only to encrypt
message m and is not stored for any length of time.
PGP Authenticaton and Confidentiality (at the same time):
The schemes for authentication and confidentiality can be combined so that Alice can sign a
confidential message which is encrypted before transmission. The steps required are as follows:
1. Alice generates a signature c for her message m as in the Authentication scheme
c=pk.encryptAd(SHA(m))
2. Alice generates a random session key k and encrypts the message m and the signature c
using a symmetric cryptosystem to obtain ciphertext C
C=sk.encryptk(m,c)
4. She encrypts the session key k using Bob’s public key
k’ = pk.encryptBe(k)
5. Alice sends Bob the values (k’,C)
6. Bob recieves k’ and C and decrypts k’ using his private key Bd to obtain the session key k
k=pk.decryptBd(k’)
7. Bob decrypts the ciphertext C using the session key k to obtain m and c
(m,c) = sk.decryptk(C)
8. Bob now has the message m. In order to authenticate it he uses Alice’s public key Ae to
decrypt the signature c and hashes the message m using SHA-1.
If
SHA(m) = pk.decryptAe(c)
Then the message is authenticated.
Compression:



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 (described in appendix 5A)
PGP can also compress the message if desired. The compression algorithm is ZIP and the
decompression algorithm is UNZIP.
1. The original message m is signed as before to obtain
c=pk.encryptAd(SHA(m))
6
2. Now the original message m is compressed to obtain
M=ZIP(m)
3. Alice generates a session key k and encrypts the compressed message and the signature
using the session key
C=sk.encryptk(M,c)
4. The session key is encrypted using Bob’s public key as before.
5. Alice sends Bob the encrypted session key and ciphertext C.
6. Bob decrypts the session key using his private key and then uses the session key to
decrypt the ciphertext C to obtain M and c
(M,c) = sk.decryptk(C)
7. Bob decompresses the message M to obtain the original message m
m=UNZIP(M)
8. Now Bob has the original message m and signature c. He verifies the signature using
SHA-1 and Alice’s public key as before.
Note that the compression is applied after signing (due to implementation of ZIP) but before
encryption (this strengthens the security of the scheme since the message has less redundancy
after compression)
Radix 64 Conversion:
Suppose the text to be encrypted has been converted into binary using ASCII coding and
encrypted to give a cipher text stream of binary. Radix-64 conversion maps arbitrary binary into
printable characters as follows:
1. The binary input is split into blocks of 24 bits (3 bytes).
2. Each 24 block is then split into four sets each of 6-bits.
3. Each 6-bit set will then have a value between 0 and 26-1 (=63).
4. This value is encoded into a printable character.
PGP Segmentation:
Another constraint of e-mail is that there is usually a maximum message length. PGP
automatically blocks an encrypted message into segments of an appropriate length. On receipt,
the segments must be re-assembled before the decryption process
Key Issues:
1. Key Generation
Recall that a new session key is required each time a message is encrypted. How are
these keys generated?
PGP uses the timing of key strokes and key patterns to generate random numbers.
2. Key Identifiers
PGP allows users to have more than one public/private key pair
 To increase security
 To ease the key changeover period
So how does Bob know which set of keys he should be using?
7
•
•
In the case of encryption, (Alice uses Bob’s public key) Alice can send Bob the public
key with the message since this is not secret (in fact Alice only sends the 64 least
significant bits so that Bob can identify the key).
In the case of digital signatures Alice uses her private key and Bob uses Alice’s
corresponding public key. Alice cannot send Bob her private key, but she can look up the
corresponding public key and send the 64 least significant bits of that.
PGP consists of:
• Message component – the actual data to be transmitted + a filename + a timestamp;
• Signature component – timestamp + hash of message and timestamp + first part of
message (so user can check that they are decrypting correctly) + Key ID of sender’s
public key
• Session Key component – session key + key ID of recipient’s public key
E-mail Compatibility
 The scheme used is radix-64 conversion (see appendix 5B).
 The use of radix-64 expands the message by 33%.
Segmentation and Reassembly:

Often restricted to a maximum message length of 50,000 octets.
Format of PGP Message:
8
PGP Message Format:
S/MIME:

After the development of PEM industry working group led by RSA Security, Inc. started
to develop another specification for conveying digitally signed and/or encrypted and
digitally enveloped data in accordance to the MIME message formats.

S/MIME (Secure/Multipurpose Internet Mail Extension) is a security enhancement to
the MIME Internet e-mail format standard.

S/MIME is not restricted to mail; it can be used with any transport mechanism that
transports MIME data, such as HTTP.

S/MIME is likely to emerge as the industry standard for commercial and organizational
use, while PGP will remain the choice for personal e-mail security for many.

S/MIME provides the following cryptography security services:

Authentication.
9

Message Integrity

Non-repudiation of origin.

Privacy and data security.
There are three versions of S/MIME:

S/MIME version 1 (1995)- was specified and officially published in 1995 by RSA
Security, Inc.

S/MIME version 2 (1998)- was specified in a pair of informational RFC documents RFC 2311 and RFC 2312 - in March1998.

The work was continued in the IETF S/MIME Mail Security (SMIME) WG and resulted
in S/MIME version 3 (1999) specified in RFCs 2630 to 2634 in June 1999.

RFC 822 defines a format for text messages that are sent using electronic mail.
SMTP/RFC822 scheme limitations:
1. SMTP cannot transmit executable files or other binary files.
2. SMTP cannot transmit text data that includes national language characters because these
are represented by 8-bit codes with values of 128 decimal or higher, and SMTP is limited
to 7-bit ASCII.
3. SMTP servers may reject mail message over a certain size.
4. SMTP gateways that translate between ASCII to EBCDIC suffer translation problems.
5. Some SMTP implementations do not adhere completely to the SMTP standard defined in
RFC 822.
MIME specification includes the following elements:
1. Five new message header fields. These fields provide information about the body of the
message.
2. A number of content formats are defined, thus standardizing representations that supports
multimedia e-mail.
3. Transfer encodings are defined that enable that protect any content format to be altered
by the mail system.
4. MIME provides a standardized way of dealing with a wide variety of information
representations in a multimedia environment.
10
5. Conclusions:
1. MIME is a necessity in today’s Internet and e-mail traffic requirements.
2. The “Object Oriented” structure of the MIME message enhances its capability to
serve as multipurpose standard.
3. The MIME is capable of transferring data between two distinct systems which
uses different formats
S/MIME is based on the Cryptographic Message Syntax
(CMS) specified in RFC 2630.
Enveloped data: This consists of encrypted content of any type and encrypted content encryption
keys for one or more users. This functions provides privacy and data security.
Signed data: A digital signature is formed by signing the message digest and then encrypting
that with the signer private key. The content and the signature are then encoded using base64
encoding. This function provides authenticity, message integrity and non-repudiation of origin.
SignerInfo: allows the inclusion of unsigned and signed attributes to be included along with a
signature.

signingTime

sMIMECapabilities

sMIMEEncryptionKeyPreference
Clear signed data: In this case a digital signature of the content is formed, However only the
signature is encoded with base64.
Signed and enveloped data: Because of S/MIME encapsulating capability (multipart type),
signed only and encrypted only entities may be nested, so that encrypted data may be signed and
signed data may be encrypted.
Definitions:
MUST: The definition is an absolute requirement of the specification.
SHOULD: There may exist valid reasons in particular circumstances to ignore this feature or
function, but it is recommended that an implementation include the feature or function.
11
Algorithm use decision procedure:
Preferred decrypting capabilities: SHOULD choose the first (highest preference) capability on
the list.
No list of capabilities but has received message/s: SHOULD use the same encryption
algorithm as was used on the last signed and encrypted message.
No knowledge & Willing to risk: Willing to risk that the recipient may not be able to decrypt
the message, then the sending agent SHOULD use 3DES.
No knowledge & Not willing to risk: Sending agent MUST use RC2/40.
A possible problem: A multiple recipient’s message:

Performance

Security
The Solution: This problem is solved using an Enhanced Security service called S/MIME Mail
List Agent (MLA). An MLA perform the recipient-specific encryption for each recipient, and
forward the message.
S/MIME Message:
12
S/MIME –Certificates:

S/MIME uses public-key certificates that conform to version 3 of X.509.

A hybrid between a strict X.509 certification hierarchy and PGP's web of trust.

A receiving agent MUST provide some certificate retrieval mechanism.

Receiving and sending agents SHOULD also provide a mechanism to allow a user to "store
and protect" certificates

Public key certificates are required to protect the authenticity and
keys, thus protecting against man-in-the-middle attack.
integrity of public
 A certificate chain must be verified until
 a root CA is reached
 a certificate can only be trusted if:
o every certificate in the chain is successfully verified.
o every CA in the certificate chain is trusted.
13

In practice, certificate chains are short and seldom verified for trustworthiness.

Also, the concept of cross-certification is of low practical value and seldom used between
certification service providers.

Key generation:
o MUST be capable of generating separate Diffie-Hellman and DSS key pairs.


SHOULD be capable of generating RSA key pairs.

good source of non-deterministic random.

protected in a secure fashion.
Registration:
o 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:
o access to a local list of certificates in order to verify incoming signatures and
encrypt outgoing messages.
o maintained by the user local administrative entity on behalf of number of users.

Certificate Management in S/MIME:

CA-centered.

CA certificates come with the client software.

An ordinary user is not aware of the CAs that he/she trusts.

Certificates are sent along with the signed messages.
Before S/MIME can be used in any of the above applications, one must obtain and install an
individual key/certificate either from one's in-house certificate authority (CA) or from a public
CA.
The accepted best practice is to use separate private keys (and associated certificates) for
signature and for encryption, as this permits escrow of the encryption key without compromise to
the non-repudiation property of the signature key.
Encryption requires having the destination party's certificate on store (which is typically
automatic upon receiving a message from the party with a valid signing certificate). While it is
technically possible to send a message encrypted (using the destination party certificate) without
14
having one's own certificate to digitally sign, in practice, the S/MIME clients will require you
install your own certificate before they allow encrypting to others.
A typical basic ("class 1") personal certificate verifies the owner's "identity" only insofar as it
declares that sender is the owner of the "From:" email address in the sense that the sender can
receive email sent to that address, and so merely proves that an email received really did come
from the "From:" address given.
It does not verify the person's name or business name. If a sender wishes to enable email
recipients to verify the sender's identity in the sense that a received certificate name carries the
sender's name or an organization's name, the sender needs to obtain a certificate ("class 2") from
a CA who carries out a more in-depth identity verification process, and this involves making
enquiries about the would-be certificate holder.
Depending on the policy of the CA, your certificate and all its contents may be posted publicly
for reference and verification. This makes your name and email address available for all to see
and possibly search for. Other CAs only post serial numbers and revocation status, which does
not include any of the personal information. The latter, at a minimum, is mandatory to uphold the
integrity of the public key infrastructure.
Obstacles to deploying S/MIME in practice

Not all e-mail software handles S/MIME signatures, resulting in an attachment
called smime.p7s that may confuse some people.

S/MIME is sometimes considered not properly suited for use via webmail clients. Though
support can be hacked into a browser, some security practices require the private key to be
kept accessible to the user but inaccessible from the webmail server, complicating the key
webmail advantage of providing ubiquitous accessibility. This issue is not fully specific to
S/MIME - other secure methods of signing webmail may also require a browser to execute
code to produce the signature, exceptions are PGP Desktop and versions of GnuPG, who will
grab the data out of the webmail, sign it by means of a clipboard, and put the signed data
back into the webmail page. Seen from the view of security this is even the more secure
solution.

Some organizations consider it acceptable for webmail servers to be "in on the secrets";
others don't. Some of the considerations are mentioned below regarding malware. Another
argument is that servers often contain data that is confidential to the organization anyway, so
what difference does it make if additional data, such a private keys used for decryption, are
also stored and used on such servers?
15
Many make a distinction between private keys used for decryption and those used for digital
signatures. They are far more likely to accept sharing of the former than the latter. This is
especially true if the non-repudiation aspect of digital signatures is a concern (it may not be).
There is fairly universal consensus that non-repudiation requires that a private key be
under sole control of its owner during its entire lifecycle. Therefore, decryption done with
webmail servers is more likely to be acceptable than digital signatures.

S/MIME is tailored for end to end security. Encryption will not only encrypt your messages,
but also malware. Thus if your mail is scanned for malware anywhere but at the end points,
such as your company's gateway, encryption will defeat the detector and successfully deliver
the malware. Solutions:

Perform malware scanning on end user stations after decryption.

Store private keys on the gateway server so decryption can occur prior to the gateway
malware scan. (Though this in some ways defeats the purpose of encryption, as it allows
anyone with access to the gateway server to read another user's mail.)

Use message content scanners specifically designed to check the content of encrypted
messages in transit whilst preserving end-to-end signatures and encryption. Such solutions
must contain built-in protection for both the private key used to decrypt the message, and for
the temporarily decrypted contents.

Due to the requirement of a certificate for implementation, not all users can take advantage of
S/MIME, as some may wish to encrypt a message, with a public/private key pair for
example, without the involvement or administrative overhead of certificates.
Questions from previous papers:
1. Explain the various MIME content types?
2. Discuss the functions provided by S/MIME?
3. Explain the pretty good privacy (PGP).
4. Explain how bob sends out what cryptographic algorithms Alice has used when
he receives an S/MIME message from her?
5. In PGP, explain how bob and Alice exchange the secret key for encrypting messages?
6. Explain about the services being provided by PGP.
*******************All The Best********************
16