S8_CS_Security in Computing _ Module 4 NETWORK & APPLICATION SECURITY

ELECTRONIC MAIL SECURITY

• The protection of electronic mail from unauthorized access and inspection is known as
electronic privacy.
• Because e-mail connects through many routers and mail servers on its way to the
recipient, it is inherently vulnerable to both physical and virtual eavesdropping. Any
cracker who gains access to an inadequately protected router can read the e-mail.
• 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 e-mail's contents into incomprehensible text that can be decrypted only by
the recipient.
• With the explosively growing reliance on e-mail for every conceivable purpose, there
grows a demand for authentication and confidentiality services. Two schemes for email
security that widespread in use are Pretty Good Privacy and S/MIME
PRETTY GOOD PRIVACY (PGP)
• Pretty Good Privacy provides a confidentiality and authentication service that can be
used for electronic mail and file storage applications.
• Phil Zimmermann created the first version of PGP encryption in 1991.
Benefits of PGP
ü It is available free worldwide in version that run on a variety of platforms including
Windows, UNIX, Macintosh and many more.
ü Extremely secure since the package includes RSA, DSS and Diffie-Hellman etc.
ü It has a wide range of applicability from corporations to individuals.
ü It was not developed by any governmental or standards organization.
ü PGP is now on an Internet standards track.
Operational Description
It consists of five services: authentication, confidentiality, compression, e-mail compatibility
and segmentation.
1) Authentication
Steps involved in authentication procedure are:
i) The sender creates a message
ii) SHA-1 is used to generate a 160-bit hash code of the message.
iii) The hash code is encrypted with RSA with the sender’s private key, and the result
is prepended to the message.
iv) The receiver uses RSA with the sender’s public key to decrypt and recover the
hash code.

18 CEC, Perunad
S8_CS_Security in Computing _ Module 4 NETWORK & APPLICATION SECURITY

v) 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.
Source A Destination B
E [PRa, H (M)] PUa
PRa

DP
M H || Z Z-1
EP M Compare

H
Fig. 4.10 Authentication
2) Confidentiality
Confidentiality is provided by encrypting message to be transmitted. For this the
symmetric key algorithm CAST-128 may be used. This includes the following steps:
i) The sender generates a message and a random 128-bit number to be used as a
session key for this message only.
ii) The message is encrypted, using CAST-128 or IDEA with the session key.
iii) The session key is encrypted with RSA, using the recipient’s public key, and is
prepended to the message.
iv) The receiver uses RSA with its private key to decrypt and recover the session key.
v) The session key is used to decrypt the message.
Source A PUb
Destination B
E [PUb, Ks] PRb

EP
Ks

M DP

Z EC ||
M
DC Z-1
Fig. 4.11 Confidentiality
3) Compression
As a default, PGP compress 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. (*In figure, compression is denoted by Z and decompression is denoted by –Z.)
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
ü The PGP compression algorithm is not deterministic; various implementations of
the algorithm achieve different tradeoffs in running speed versus compression ratio and,
as a result produce different compressed forms.

19 CEC, Perunad
S8_CS_Security in Computing _ Module 4 NETWORK & APPLICATION SECURITY

Message encryption is applied after compression to strengthen cryptographic

security. Because the compressed message has less redundancy than the original plain
text, cryptanalysis is more difficult. The compression algorithm used is ZIP.
4) E-mail compatibility
The part or the entire message after encryption consists of a stream of arbitrary
8-bit octets. But 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
CRC to detect transmission errors. The use of radix-64 expands a message by 33%.
5) Segmentation and reassembly
E-mail facilities often are restricted to a maximum message length. Any message
longer than the maximum length must be broken up into smaller segments, each of
which is mailed separately.

File (X) Convert from radix 64

Yes Generate Yes Decrypt

Signature Confidentiality
required? Signature required? key, X

No No

Compress (Z(X)) Decompress (Z-1(X))

Yes Encrypt Yes Strip

Confidentiality Signature
required? key, X required? Signature

No
No

Convert to radix 64

Fig. 4.12 Transmission and Reception of PGP Messages

20 CEC, Perunad
 S8_CS_Security in Computing _ Module 4 NETWORK & APPLICATION SECURITY

To accommodate this restriction, PGP automatically subdivides a message that is

too large into segments that are small enough to send via e-mail. The segmentation is
done after all of the other processing, including the radix-64 conversion. Thus, session
key component and signature component appear only once, at the beginning of the first
segment. At the receiving end, PGP must strip off all e-mail headers and reassemble the
entire original block.

How PGP encryption works

PGP message encryption uses both asymmetric key encryption and symmetric key
encryption algorithms. Commonly, when encrypting a message, the sender uses the public key
half of the recipient's linked key pair to encrypt a symmetric cipher session key. That session
key is used, in turn, to encrypt the plaintext of the message. Other operational modes are less
commonly used.
The recipient of a PGP-encrypted message decrypts the session key using his private
key (the session key was previously encrypted using his public key by the sender). Next, he
decrypts the ciphertext of the message using the session key.
Use of two ciphers in this way is useful, despite higher complication, because of the
very considerable difference in operating speed between asymmetric key and symmetric key
ciphers (the difference is often a factor of 1000 or more). This approach also makes it easily
possible to send the same encrypted message to two or more recipients.
The entire encryption and decryption operations are completely automated in current
PGP desktop versions. Many PGP users' public keys are available to all from the many PGP
key servers around the world, which act as mirror sites for each other.

S/MIME
S/MIME (Secure/Multipurpose Internet Mail Extension) is a security enhancement to
the MIME Internet e-mail format standard, based on technology from RSA data security.
RFC 822 – It defines a format for text message that are sent using electronic mail. In this
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.

Multipurpose Internet Mail Extensions

MIME is an extension to RFC 822 framework that is intended to address some of the
problems and limitations of the use of SMTP or some other mail transfer protocol and RFC
822 for electronic mail.
Limitations of SMTP/822 Scheme:
SMTP cannot transmit executable files or other binary objects.
SMTP cannot transmit text data that includes national language characters.
SMTP servers may reject mail messages over a certain size.

21 CEC, Perunad
 S8_CS_Security in Computing _ Module 4 NETWORK & APPLICATION SECURITY

Overview of MIME
The MIME specification includes the following elements:
1. Five new message header fields are defined. These fields provide information about the
body of the message.
2. A number of content formats are defined, thus standardizing representations that
support multimedia electronic mail.
3. Transfers encoding are defined that enable the conversion of any content format into a
form that is protected from alteration by the mail system.

Table 4.2 Header Fields defined in MIME

Field name Description

MIME- Version Indicates that the message conforms to

MIME and must have the value 1.0
Describe the data contained in the body with
Content- Type
sufficient details.

Content-Transfer Indicates the type of transformation that has

encoding been used to represent the body of the
message.
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

Table 4.3 MIME content types:

Type Subtype Description

Plain Unformatted text

Text
Enriched Provides greater format flexibility

Mixed Different parts are independent but are to be transmitted

together

Parallel Differs from Mixed only in that no order is defined for

Multipart
delivering the parts to the receiver

Alternative Different parts are alternative versions of the same

information.

22 CEC, Perunad
 S8_CS_Security in Computing _ Module 4 NETWORK & APPLICATION SECURITY

Digest Similar to Mixed, but the default type/subtype of each

part is message/rfc 822.

rfc 822 The body itself an encapsulated message that conforms

to RFC 822
Message
Partial Used to allow fragmentation of large mail items.

External-body Contains a pointer to an object that exists elsewhere.

Jpeg The image is JPEG format.

Image
gif The image is GIF format.

Video Mpeg MPEG format

Basic Single-channel 8-bit ISDN mu-law encoding at a

Audio
sample rate of 8 kHz

Post-Script Adob Postscript

Application
Octet-stream General binary data consisting of 8-bit bytes.

Table 4.4 MIME Transfer Encoding:

7 bit The data are all represented by short lines of ASCII characters.

8 bit The lines are short, but there may be non-ASCII characters

Binary Not only may non- ASCII characters be present but the lines are not
necessarily short enough for SMTP transport

quoted- Encodes the data in such a way that if the data being encoded are
printable mostly ASCII text, the encoded form of the data remains largely
recognizable by humans

base64 Encodes data by mapping 6-bits blocks of input to 8-bit blocks of

output, all of which are printable ASCII characters.

x-token A named nonstandard encoding

23 CEC, Perunad
 S8_CS_Security in Computing _ Module 4 NETWORK & APPLICATION SECURITY

S/MIME Functionality
S/MIME provides the following functions
1) Enveloped data: This consists of encrypted content of any type and encrypted content
encryption keys for one or more recipients.
The steps for preparing an enveloped data are follows
i) Generate a pseudorandom session key for a particular symmetric encryption
algorithm.
ii) For each recipient, encrypt the session key with the recipient’s public key
iii) For each recipient, prepare a block known as RecipientInfo that contains an
identifier of the recipient’ public key certificate, an identifier of the algorithm used
to encrypt the session key and the encrypted session key.
iv) Encrypt the message content with the session key.
2) 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. A signed data
message can only be viewed by a recipient with S/MIME capability.
The steps for preparing a signed data are follows
i) Select a hash algorithm
ii) Compute the hash of the content to be signed.
iii) Encrypt the hash with the signer’s private key.
iv) Prepare a block known as SignerInfo that contains the signer’s public key
certificate, an identifier of the hash algorithm, an identifier of the encryption
algorithm and the encrypted hash.
3) Clear signed data: As with signed data a digital signature of the content is formed.
However, in this case, 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.
4) 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.

24 CEC, Perunad