VTU Network and Cyber Security Module-2 (15ec835, 17ec835) .

NETWORK AND CYBER SECURITY
(15EC835, 17EC835)
8th SEM E&C
JAYANTHDWIJESH H P M.tech (DECS)

Assistant Professor – Dept of E&CE
B.G.S INSTITUTE OF TECHNOLOGY (B.G.S.I.T)

B.G Nagara, Nagamangala Tq, Mandya District- 571448
NETWORK AND CYBER SECURITY 15EC835, 17EC835
NETWORK AND CYBER SECURITY
MODULE-2
MODULE-2
E-mail Security: Pretty Good Privacy, S/MIME, and Domain keys identified
mail.
TEXT BOOK:
1. William Stallings, “Cryptography and Network Security Principles and

Practice”, Pearson Education Inc., 6th Edition, 2014, ISBN: 978-93-325- 1877-
3.
2. Thomas J. Mowbray, “Cyber Security – Managing Systems, Conducting
Testing, and Investigating Intrusions”, Wiley.
REFERENCE BOOKS:
1. Cryptography and Network Security, Behrouz A. Forouzan, TMH, 2007.

2. Cryptography and Network Security, Atul Kahate, TMH, 2003.
Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 1

1. PRETTY GOOD PRIVACY IMP QS (question)-06M
PGP is a remarkable phenomenon. Largely the effort of a single person, Phil

Zimmermann, PGP provides a confidentiality and authentication service that can be
used for electronic mail and file storage applications.
In essence, 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 (Via crypt, now Network Associates) to
provide a fully compatible, low-cost commercial version of PGP.
PGP has grown explosively and is now widely used. A number of reasons can be
cited for this growth
1. It is available free worldwide in versions that run on a variety of platforms, including
Windows, UNIX, Macintosh, and many more. In addition, the commercial version
satisfies users who want a product that comes with vendor support.
2. It is based on algorithms that have survived extensive public review and are
considered extremely secure. Specifically, the package includes RSA, DSS, and Diffie-
Hellman for public-key encryption; CAST-128, IDEA, and 3DES for symmetric
encryption; and SHA-1 for hash coding.
3. It has a wide range of applicability, from corporations that wish to select and enforce
a standardized scheme for encrypting files and messages to individuals who wish to
communicate securely with others worldwide over the Internet and other networks.
4. It was not developed by, nor is it controlled by, any governmental or standards
organization. For those with an instinctive distrust of “the establishment,” this
makes PGP attractive.
5. PGP is now on an Internet standards track (RFC 3156; MIME Security with Open
PGP). Nevertheless, PGP still has an aura of an antiestablishment endeavour.

1.1 NOTATION
Most of the notation used in this chapter has been used before, but a few terms
are new. It is perhaps best to summarize those at the beginning. The following symbols
are used.
Ks = session key used in symmetric encryption scheme

PRa = private key of user A, used in public-key encryption scheme
PUa = public key of user A, used in public-key encryption scheme
EP = public-key encryption
DP = public-key decryption
EC = symmetric encryption
DC = symmetric decryption
H = hash function
‖= concatenation
Z = compression using ZIP algorithm
R64 = conversion to radix 64 ASCII format
1.1 OPERATIONAL DESCRIPTION
The actual operation of PGP, as opposed to the management of keys, consists of four
services: authentication, confidentiality, compression, and e-mail compatibility (Table
1).
Table 1: Summary of PGP Services

1.1.1 PGP Operation- Authentication IMP QS (question)-06M
Figure 1 Authentication only

Above Figure 1:-
Sender:
1. The sender creates a message.
2. SHA-1 is used to generate a 160-bit hash code of the message.
3. The hash code is encrypted with RSA using the sender’s private key, and the
result is prepended to the message.
Receiver:
4. The receiver uses RSA with the sender’s public key to decrypt and recover the
hash code.
5. 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.
1.1.2 PGP Operation- Confidentiality IMP QS (question)-06M
Figure 2 Confidentiality only

Above Figure 2:-
Sender:
1. The sender generates a message and a random 128-bit number to be used as a
session key for this message only.

2. The message is encrypted using CAST-128 (or IDEA or 3DES) with the session
key.
3. The session key is encrypted with RSA using the recipient’s public key and is
prepended to the message.
Receiver:
4. The receiver uses RSA with its private key to decrypt and recover the session
key.
5. The session key is used to decrypt the message.
1.1.3 PGP Operation- Confidentiality and Authentication

IMP QS (question)-06M
Figure 3 Confidentiality and authentication

Above Figure 3:-
1. Both services may be used for the same message. First, a signature is generated
for the plaintext message and prepended to the message.
2. Then the plaintext message plus signature is encrypted using CAST-128 (or IDEA
or 3DES), and the session key is encrypted using RSA .This sequence is
preferable to the opposite: encrypting the message and then generating a
signature for the encrypted message.
3. It is generally more convenient to store a signature with a plaintext version of a
message. Furthermore, for purposes of third-party verification, if the signature is
performed first, a third party need not be concerned with the symmetric key
when verifying the signature.
In summary, when both services are used, the sender first signs the message with its
own private key, then encrypts the message with a session key, and finally encrypts the
session key with the recipient’s public key.

NOTE:- Figure 1 Authentication only, Figure 2 Confidentiality only, Figure 3 Confidentiality

and authentication = PGP Cryptographic Functions
1.1.4 Compression
As a default, PGP compresses 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. The placement of the compression algorithm, indicated by Z for compression
and 𝑍−1 for decompression in figure (1, 2 &3) critical. The compression algorithm used is
ZIP.
1. The signature is generated before compression for two reasons:

a. so that one can store only the uncompressed message together with signature
for later verification
b. Applying the hash function and signature after compression would constrain all
PGP implementations to the same version of the compression algorithm as the
PGP compression algorithm is not deterministic
2. Message encryption is applied after compression to strengthen cryptographic
security. Because the compressed message has less redundancy than the original
plaintext, cryptanalysis is more difficult.
1.1.5 PGP Operation – Email Compatibility IMP QS (question)-08M
 When PGP is used, at least part of the block to be transmitted is encrypted, and
thus consists of a stream of arbitrary 8-bit octets.
 However many electronic mail systems only permit the use 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.
 It uses radix-64 conversion, in which each group of three octets of binary data is
mapped into four ASCII characters. This format also appends a CRC to detect
transmission errors. The use of radix 64 expands a message by 33%, but still an
overall compression of about one- third can be achieved.

Figure 4 Transmissions and Reception of PGP Messages
Transmissions
1. On transmission (if it is required), a signature is generated using a hash code of

the uncompressed plaintext.
2. Then the plaintext (plus signature if present) is compressed. Next, if
confidentiality is required, the block (compressed plaintext or compressed
signature plus plaintext) is encrypted and prepended with the public key-
encrypted symmetric encryption key.
3. Finally, the entire block is converted to radix-64 format.
Reception
4. On reception, the incoming block is first converted back from radix-64 format to
binary.
5. If the message is encrypted, the recipient recovers the session key and decrypts
the message. The resulting block is then decompressed.
6. If the message is signed, the recipient recovers the transmitted hash code and
compares it to its own calculation of the hash code.

1.2 PGP OPERATION - SEGMENTATION/REASSEMBLY

 E-mail facilities often are restricted to a maximum message length.
 For example, many of the facilities accessible through the Internet impose a
maximum length of 50,000 octets. Any message longer than that must be broken
up into smaller segments, each of which is mailed separately.
 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.
 The session key component and signature component appear only once, at the
beginning of the first segment.
 Reassembly at the receiving end is required before verifying signature or
decryption.
1.3 KEY IDENTIFIERS OR PGP MESSAGE FORMAT

The concept of key ID has been introduced; we can take a more detailed look at the
format of a transmitted message, which is shown in Figure 5
 A message consists of three components: the message component, a signature
(Optional), and a session key component (optional).
 The message component includes the actual data to be stored or transmitted, as
well as a filename and a timestamp that specifies the time of creation.
 The signature component includes the following:
 Timestamp: The time at which the signature was made.
 Message digest: The 160-bit SHA-1 digest, encrypted with the sender's
private signature key.
 Leading two octets of message digest: To enable the recipient to determine
if the correct public key was used to decrypt the message digest for
authentication, by comparing this plaintext copy of the first two octets with
the first two octets of the decrypted digest. These octets also serve as a 16-bit
frame check sequence for the message.
 Key ID of sender's public key: Identifies the public key that should be used
to decrypt the message digest and, hence, identifies the private key that was
used to encrypt the message digest.
Figure 5 General Format PGP Message (from A to B)

 The session key component includes the session key and the identifier of the
recipient's public key that was used by the sender to encrypt the session key.
 The entire block is usually encoded with radix-64 encoding.
1.4 PGP MESSAGE GENERATIONS OR PGP MESSAGE

TRANSMISSION AND RECEPTION OR KEY RINGS IMP QS (question)-10M
1.4.1 Message transmission
The following figure 6 shows the steps during message transmission assuming
that the Message is to be both signed and encrypted.
The sending PGP entity performs the following steps

Figure 6 PGP Message Generation (from User A to User B: no compression or radix-64

Conversion)
Signing the message
a. PGP retrieves the sender's private key from the private-key ring using your _
user id as an index. If your_ user id was not provided in the command, the first
private key on the ring is retrieved.
b. PGP prompts the user for the passphrase to recover the unencrypted private key.
c. The signature component of the message is constructed.
Encrypting the message

a. PGP generates a session key and encrypts the message.
b. PGP retrieves the recipient's public key from the public-key ring using her _ user
id as an index.
c. The session key component of the message is constructed.
1.4.2 Message Reception

The receiving PGP entity performs the following steps (Figure 7)
a. PGP retrieves the receiver’s private key from the private-key ring using the
Key ID field in the session key component of the message as an index
b. PGP prompts the user for the passphrase to recover the unencrypted private
key.

c. PGP then recovers the session key and decrypts the message.
Figure 7 PGP Message Reception (from User A to User B; no compression or radix-64

conversion)
Authenticating the message
a. PGP retrieves the sender's public key from the public-key ring, using the Key ID
field in the signature key component of the message as an index.
b. PGP recovers the transmitted message digest.
c. PGP computes the message digest for the received message and compares it to
the transmitted message digest to authenticate.
1.5 RADIX-64 CONVERSION IMP QS (question)-06M
Both PGP and S/MIME make use of an encoding technique referred to as radix-64
Conversion. This technique maps arbitrary binary input into printable character output.
The form of encoding has the following relevant characteristics:
1. The range of the function is a character set that is universally represent able At
all sites, not a specific binary encoding of that character set. Thus, the characters
themselves can be encoded into whatever form is needed by a specific system.

For example, the character “E” is represented in an ASCII based system as

hexadecimal 45 and in an EBCDIC-based system as hexadecimal C5.
2. 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 bits of input.
3. No control characters are included in the set. Thus, a message encoded in radix
64 can traverse mail-handling systems that scan the data stream for control
characters.
4. The hyphen character “-” is not used. This character has significance in the RFC
5322 format and should therefore be avoided.
Table 2 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.
Table 2 Radix-64 Encoding

Figure 8 illustrates the simple mapping scheme. 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.

Figure 8 Printable Encoding of Binary Data into Radix-64 Format
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
The extracted 6-bit decimal values are 8, 53, 50, and 17. Looking these up in Table 2
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
In hexadecimal, this is 49317952. To summarize:
2. S/MIME IMP QS (question)-06M
 Secure/Multipurpose Internet Mail Extension (S/MIME) is a security

enhancement to the MIME Internet e-mail format standard based on technology
from RSA Data Security.
 Both PGP and S/MIME are on an IETF standards track, it appears likely that
S/MIME will emerge as the industry standard for commercial and organizational

use, while PGP will remain the choice for personal e-mail security for many
users.
 S/MIME is defined in a number of documents—most importantly RFCs 3370,
3850, 3851, and 3852.
2.1 RFC 5322 IMP QS (question)-06M
 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.
 The content standard includes a set of header fields that may be used by the mail
system to create the envelope, and the standard is intended to facilitate the
acquisition of such information by programs.
 The overall structure of a message that conforms to RFC 5322 is very simple.
 A message consists of some number of header lines (the header) followed by
unrestricted text (the body).
 The header is separated from the body by a blank line. Put differently, a message
is ASCII text, and all lines up to the first blank line are assumed to be header lines
used by the user agent part of the mail system.
2.2 MULTIPURPOSE INTERNET MAIL EXTENSIONS
Multipurpose Internet Mail Extension (MIME) is an extension to the RFC 5322

framework that is intended to address some of the problems and limitations of the use of
Simple Mail Transfer Protocol (SMTP), defined in RFC 821, or some other mail transfer
protocol and RFC 5322 for electronic mail.

Lists the following limitations of the SMTP/5322 scheme.
1. SMTP cannot transmit executable files or other binary objects. A number of

schemes are in use for converting binary files into a text form that can be used by
SMTP mail systems, including the popular UNIX Uuencode/ Uudecode scheme.
However, none of these is a standard or even a de facto standard.
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 and the character code EBCDIC do
not use a consistent set of mappings, resulting in translation problems.
5. SMTP gateways to X.400 electronic mail networks cannot handle non textual
data included in X.400 messages.
6. Some SMTP implementations do not adhere completely to the SMTP standards
defined in RFC 821. Common problems include:
 Deletion, addition, or reordering of carriage return and linefeed
 Truncating or wrapping lines longer than 76 characters
 Removal of trailing white space (tab and space characters)
 Padding of lines in a message to the same length
 Conversion of tab characters into multiple space characters
The MIME specification includes the following elements.

1. 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.
2. A number of content formats are defined, thus standardizing representations
that support multimedia electronic mail.
3. Transfer encodings are defined that enable the conversion of any content format
into a form that is protected from alteration by the mail system.
The five header fields defined in MIME are
1. MIME-Version: Must have the parameter value 1.0. This field indicates that the
message conforms to RFCs 2045 and 2046.
2. 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.
3. 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.
4. Content-ID: Used to identify MIME entities uniquely in multiple contexts.
5. Content-Description: A text description of the object with the body; this is
useful when the object is not readable (e.g., audio data).
2.3 MIME CONTENT TYPES IMP QS (question)-10M
 The bulk of the MIME specification is concerned with the definition of a variety of
content types.
 Table 3 lists the content types specified in RFC 2046. There are seven different
major types of content and a total of 15 subtypes.
 In general, a content type declares the general type of data, and the subtype
specifies a particular format for that type of data.
 For the text type
 The text type of body, the primary subtype is plain text, which is simply a
string of ASCII characters or ISO 8859 characters. The enriched subtype
allows greater formatting flexibility.
 For multipart type
 Multipart type indicates that the body contains multiple, independent parts.
 The Content-Type header field includes a parameter (called a boundary) that
defines the delimiter between body parts.
 This boundary should not appear in any parts of the message.
 Each boundary starts on a new line and consists of two hyphens followed by
the boundary value.
 The final boundary, which indicates the end of the last part, also has a suffix
of two hyphens. Within each part, there may be an optional ordinary MIME
header.
 There are four subtypes of the multipart type, all of which have the same
overall syntax.

1. The multipart/mixed subtype, is used when there are multiple independent

body parts that need to be bundled in a particular order.
2. 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.
3. The multipart/alternative subtype, the various parts are different
representations of the same information.
Table 3: MIME Content Types

4. The multipart/digest subtype, is used when each of the body parts is
interpreted as an RFC 5322 message with headers. This subtype enables the
construction of a message whose parts are individual messages.
 The message type provides a number of important capabilities in MIME.
1. The message/rfc822 subtype indicates that the body is an entire message,
including header and body.
2. The message/partial subtype Used to allow fragmentation of large mail
items, in a way that is transparent to the recipient.

3. The 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. As with the other
message types, the message/external-body subtype has an outer header and
an encapsulated message with its own header.
 The application type refers to other kinds of data, typically either uninterpreted
binary data or information to be processed by a mail-based application.
2.4 MIME TRANSFER ENCODINGS IMP QS (question)-06M
The other major component of the MIME specification, in addition to content

type specification, is a definition of transfer encodings for message bodies. The objective
is to provide reliable delivery across the largest range of environments.
 The MIME standard defines two methods of encoding data. The Content-
Transfer-Encoding field can actually take on six values, as listed in Table 4.
 However, three of these values (7bit, 8bit, and binary) indicate that no encoding
has been done but provide some information about the nature of the data.
Table 4: MIME Transfer Encodings

 For SMTP transfer, it is safe to use the 7bit form.
 The 8bit and binary forms may be usable in other mail transport contexts.
 Another Content-Transfer-Encoding value is x-token, which indicates that
some other encoding scheme is used for which a name is to be supplied.
 The quoted-printable transfer encoding is useful when the data consists largely
of octets that correspond to printable ASCII characters. In essence, it represents
non safe characters by the hexadecimal representation of their code and
introduces reversible (soft) line breaks to limit message lines to 76 characters.

 The base64 transfer encoding, also known as radix-64 encoding, is a common

one for encoding arbitrary binary data in such a way as to be invulnerable to the
processing by mail-transport programs.
2.5 NATIVE AND CANONICAL FORM IMP QS (question)-04M
An important concept in MIME and S/MIME is that of canonical form. Canonical

form is a format, appropriate to the content type that is standardized for use between
systems. This is in contrast to native form, which is a format that may be peculiar to a
particular system. Shown in below table 5
Table 5: Native and Canonical Form
2.6 S/MIME FUNCTIONALITY IMP QS (question)-04M
In terms of general functionality, S/MIME is very similar to PGP. Both offer the
ability to sign and/or encrypt messages.
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.
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.
The content plus signature are then encoded using base64 encoding. A signed
data message can only be viewed by a recipient with S/MIME capability.

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.
2.7 CRYPTOGRAPHIC ALGORITHMS OR CRYPTOGRAPHIC

ALGORITHMS USED IN S/MIME IMP QS (question)-06M
Table 6 summarizes the cryptographic algorithms used in S/MIME. S/MIME uses

the following terminology taken from RFC 2119 (Key Words for use in RFCs to Indicate
Requirement Levels) to specify the requirement level:
MUST: The definition is an absolute requirement of the specification. An
implementation must include this feature or function to be in conformance with 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.
The S/MIME specification includes a discussion of the procedure for deciding
which content encryption algorithm to use. In essence, a sending agent has two
decisions to make. First, the sending agent must determine if the receiving agent is
capable of decrypting using a given encryption algorithm. Second, if the receiving agent
is only capable of accepting weakly encrypted content, the sending agent must decide if
it is acceptable to send using weak encryption. To support this decision process, a
sending agent may announce its decrypting capabilities in order of preference for any
message that it sends out. A receiving agent may store that information for future use.
The following rules, in the following order, should be followed by a sending agent.
1. If the sending agent has a list of preferred decrypting capabilities from an
intended recipient, it SHOULD choose the first (highest preference) capability on
the list that it is capable of using.
2. If the sending agent has no such list of capabilities from an intended recipient but
has received one or more messages from the recipient, then the outgoing

message SHOULD use the same encryption algorithm as was used on the last
signed and encrypted message received from that intended recipient.
3. If the sending agent has no knowledge about the decryption capabilities of the
intended recipient and is willing to risk that the recipient may not be able to
decrypt the message, then the sending agent SHOULD use triple DES.
Table 6: Cryptographic Algorithms Used in S/MIME
4. If the sending agent has no knowledge about the decryption capabilities of the
intended recipient and is not willing to risk that the recipient may not be able to
decrypt the message, then the sending agent MUST use RC2/40.
If a message is to be sent to multiple recipients and a common encryption algorithm
cannot be selected for all, then the sending agent will need to send two messages. However,
in that case, it is important to note that the security of the message is made vulnerable by the
transmission of one copy with lower security.
2.8 S/MIME MESSAGES IMP QS (question)-04M
S/MIME makes use of a number of new MIME content types, which are shown in
Table 7. All of the new application types use the designation PKCS. This refers to a set of
public-key cryptography specifications issued by RSA Laboratories and made available
for the S/MIME effort.

Table 7: S/MIME Content Types
2.9 ENVELOPED DATA OR MIME ENVELOPED DATA
The steps for preparing an enveloped Data MIME entity are

1. Generate a pseudorandom session key for a particular symmetric encryption
Algorithm (RC2/40 or triple DES).
2. For each recipient, encrypt the session key with the recipient’s public RSA key.
3. For each recipient, prepare a block known as Recipient Info that contains an
identifier of the recipient’s public-key certificate,2 an identifier of the algorithm
used to encrypt the session key, and the encrypted session key.
4. Encrypt the message content with the session key.
2.10 SIGNED DATA
The signed Data smime-type can be used with one or more signers. For clarity,
we confine our description to the case of a single digital signature. The steps for
preparing a signed Data MIME entity are as follows
1. Select a message digest algorithm (SHA or MD5).
2. Compute the message digest (hash function) of the content to be signed.
3. Encrypt the message digest with the signer’s private key.
4. Prepare a block known as Signer Info that contains the signer’s public-key
certificate, an identifier of the message digest algorithm, an identifier of the
algorithm used to encrypt the message digest, and the encrypted message digest.
The signed Data entity consists of a series of blocks, including a message digest
algorithm identifier, the message being signed, and Signer Info.

The signed Data entity consists of a series of blocks, including a message digest
algorithm identifier, the message being signed, and Signer Info.
2.11CLEAR SIGNING
 Clear signing is achieved using the multipart content type with a signed subtype.
 As was mentioned, this signing process does not involve transforming the
message to be signed, so that the message is sent “in the clear.”
 Thus, recipients with MIME capability but not S/MIME capability are able to
read the incoming message.
 A multipart/signed message has two parts.
 The first part can be any MIME type but must be prepared so that it will not
be altered during transfer from source to destination.
 The Second part has a MIME content type of application and a subtype of
pkcs7-signature.
2.12 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.
 The certification request includes certification Request Info block, followed by
an identifier of the public-key encryption algorithm, followed by the signature of
the certification Request Info block made using the sender’s private key. The
certification Request Info block includes a name of the certificate subject (the
entity whose public key is to be certified) and a bit-string representation of the
user’s public key.
2.13 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 a smime-type parameter of degenerate. The steps involved are
the same as those for creating a signed Data message, except that there is no message
content and the signer Info field is empty.

2.14 S/MIME CERTIFICATE PROCESSING IMP QS (question)-10M
S/MIME uses public-key certificates that conform to version 3 of X.509.
User Agent Role

An S/MIME user has several key-management functions to perform.
1. Key generation: The user of some related administrative utility (e.g., one
associated with LAN management) MUST be capable of generating separate
Diffie-Hellman and DSS key pairs and SHOULD be capable of generating RSA key
pairs. Each key pair MUST be generated from a good source of nondeterministic
random input and be protected in a secure fashion. A user agent SHOULD
generate RSA key pairs with a length in the range of 768 to 1024 bits and MUST
NOT generates a length of less than 512 bits.
2. Registration: A user’s public key must be registered with a certification
authority in order to receive an X.509 public-key certificate.
3. Certificate storage and retrieval: A user requires access to a local list of
certificates in order to verify incoming signatures and to encrypt outgoing
messages. Such a list could be maintained by the user or by some local
administrative entity on behalf of a number of users.
VeriSign Certificates
 There are several companies that provide certification authority (CA) services.
 VeriSign provides a CA service that is intended to be compatible with S/MIME
and a variety of other applications.
 VeriSign issues X.509 certificates with the product name VeriSign Digital ID.
 The information contained in a Digital ID depends on the type of Digital ID and
its use. At a minimum, each Digital ID contains
1. Owner’s public key
2. Owner’s name or alias
3. Expiration date of the Digital ID
4. Serial number of the Digital ID
5. Name of the certification authority that issued the Digital ID
6. Digital signature of the certification authority that issued the Digital ID
 Digital IDs can also contain other user-supplied information, including
1. Address
2. E-mail address

3. Basic registration information (country, zip code, age, and gender)
Table 8: VeriSign Public-Key Certificate Classes

 VeriSign provides three levels, or classes, of security for public-key certificates,
as summarized in Table 8. A user requests a certificate online at VeriSign’s Web
site or other participating Web sites. Class 1 and Class 2 requests are processed
on line, and in most cases take only a few seconds to approve. Briefly, the
following procedures are used.
1. For Class 1 Digital IDs, VeriSign confirms the user’s e-mail address by sending a
PIN and Digital ID pick-up information to the e-mail address provided in the
application.
2. For Class 2 Digital IDs, VeriSign verifies the information in the application
through an automated comparison with a consumer database in addition to
performing all of the checking associated with a Class 1 Digital ID. Finally,
confirmation is sent to the specified postal address alerting the user that a Digital
ID has been issued in his or her name.

3. For Class 3 Digital IDs, VeriSign requires a higher level of identity assurance. An
individual must prove his or her identity by providing notarized credentials or
applying in person.
2.15 ENHANCED SECURITY SERVICES
As of this writing, three enhanced security services have been proposed in an

Internet draft. The details of these may change, and additional services may be added.
The three services are
1. Signed receipts: A signed receipt may be requested in a Signed Data object.

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. In essence, the recipient signs the entire original Message plus the
original (sender’s) signature and appends the new signature to form a new S/MIME
message.
2. Security labels: A security label may be included in the authenticated attributes of a
Signed Data object. A security label is a set of security information regarding the
sensitivity of the content that is protected by S/MIME encapsulation. The labels may
be used for access control, by indicating which users are permitted access to an
object. Other uses include priority (secret, confidential, restricted, and so on) or role
based, describing which kind of people can see the information (e.g., patient’s
health-care team, medical billing agents, etc.).
3. Secure mailing lists: When a user sends a message to multiple recipients, a certain
amount of per-recipient processing is required, including the use of each recipient’s
public key. The user can be relieved of this work by employing the services of an
S/MIME Mail List Agent (MLA). An MLA can take a single incoming message,
perform the recipient-specific encryption for each recipient, and forward the
message. The originator of a message need only send the message to the MLA with
encryption performed using the MLA’s public key.
3 DOMAIN KEYS IDENTIFIED MAIL IMP QS (question)-06M
 Domain Keys Identified Mail (DKIM) is a specification for cryptographically

signing e-mail messages, permitting a signing domain to claim responsibility for
a message in the mail stream.

 Message recipients (or agents acting in their behalf) can verify the signature by
querying the signer’s domain directly to retrieve the appropriate public key and
thereby can confirm that the message was attested to by a party in possession of
the private key for the signing domain.
 DKIM is a proposed Internet Standard (RFC 4871: Domain Keys Identified Mail
(DKIM) Signatures). DKIM has been widely adopted by a range of e-mail
providers, including corporations, government agencies, Gmail, yahoo, and many
Internet Service Providers (ISPs).
3.1 INTERNET MAIL ARCHITECTURE IMP QS (question)-10M
To understand the operation of DKIM, it is useful to have a basic grasp of the

Internet mail architecture, which is currently defined in RFC 5598.
At its most fundamental level, the Internet mail architecture consists of a user
world in the form of Message User Agents (MUA), and the transfer world, in the form of
the Message Handling Service (MHS), which is composed of Message Transfer Agents
(MTA).
Figure 9 illustrates the key components of the Internet mail architecture, which
include the following.
1. Message User Agent (MUA): Operates on behalf of user actors and user
applications. It is their representative within the e-mail service. Typically, this
function is housed in the user’s computer and is referred to as a client e-mail
program or a local network e-mail server. The author MUA formats a message
and performs initial submission into the MHS via a MSA. The recipient MUA
processes received mail for storage and/or display to the recipient user.
2. 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. This function may be located together with the MUA or as a separate
functional model. In the latter case, the Simple Mail Transfer Protocol (SMTP) is
used between the MUA and the MSA.
3. Message Transfer Agent (MTA): Relays mail for one application-level hop. It is
like a packet switch or IP router in that its job is to make routing assessments
and to move the message closer to the recipients. Relaying is performed by a
sequence of MTAs until the message reaches a destination MDA. An MTA also

adds trace information to the message header. SMTP is used between MTAs and
between an MTA and an MSA or MDA.
Figure 9: Function Modules and Standardized Protocols Used Between Them or Internet
mail architecture
4. Mail Delivery Agent (MDA): Responsible for transferring the message from the
MHS to the MS.
5. 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. Typically, an MUA
retrieves messages from a remote server using POP (Post Office Protocol) or
IMAP (Internet Message Access Protocol).
Two other concepts need to be defined
1. An administrative management domain (ADMD) is an Internet e-mail
provider.
2. 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.

3.2 E-MAIL THREATS IMP QS (question)-10M
RFC 4686 (Analysis of Threats Motivating Domain Keys Identified Mail)

describes the threats being addressed by DKIM in terms of the characteristics,
capabilities, and location of potential attackers.
3.2.1 Characteristics
RFC 4686 characterizes the range of attackers on a spectrum of three levels of threat.
1. At the low end are attackers who simply want to send e-mail that a recipient
does not want to receive. The attacker can use one of a number of commercially
available tools that allow the sender to falsify the origin address of messages.
This makes it difficult for the receiver to filter spam on the basis of originating
address or domain.
2. At the next level are professional senders of bulk spam mail. These attackers
often operate as commercial enterprises and send messages on behalf of third
parties. They employ more comprehensive tools for attack, including Mail
Transfer Agents (MTAs) and registered domains and networks of compromised
computers (zombies) to send messages and (in some cases) to harvest addresses
to which to send.
3. The most sophisticated and financially motivated senders of messages are those
who stand to receive substantial financial benefit, such as from an e- mail-based
fraud scheme. These attackers can be expected to employ all of the above
mechanisms and additionally may attack the Internet infrastructure itself,
including DNS cache-poisoning attacks and IP routing attacks.
3.2.2 Capabilities
RFC 4686 lists the following as capabilities that an attacker might have.
1. Submit messages to MTAs and Message Submission Agents (MSAs) at multiple

locations in the Internet.
2. Construct arbitrary Message Header fields, including those claiming to be mailing
lists, resenders, and other mail agents.
3. Sign messages on behalf of domains under their control.
4. Generate substantial numbers of either unsigned or apparently signed messages
that might be used to attempt a denial-of-service attack.

5. Resend messages that may have been previously signed by the domain.
6. Transmit messages using any envelope information desired.
7. Act as an authorized submitter for messages from a compromised computer.
8. Manipulation of IP routing. This could be used to submit messages from specific
IP addresses or difficult-to-trace addresses, or to cause diversion of messages to
a specific domain.
9. Limited influence over portions of DNS using mechanisms such as cache
poisoning. This might be used to influence message routing or to falsify
advertisements of DNS-based keys or signing practices.
10. Access to significant computing resources, for example, through the conscription
of worm-infected “zombie” computers. This could allow the “bad actor” to
perform various types of brute-force attacks.
11. Ability to eavesdrop on existing traffic, perhaps from a wireless network.
3.2.3 Location
 DKIM focuses primarily on attackers located outside of the administrative units

of the claimed originator and the recipient.
 These administrative units frequently correspond to the protected portions of
the network adjacent to the originator and recipient.
 It is in this area that the trust relationships required for authenticated message
submission do not exist and do not scale adequately to be practical.
 Conversely, within these administrative units, there are other mechanisms (such
as authenticated message submission) that are easier to deploy and more likely
to be used than DKIM.
 External “bad actors” are usually attempting to exploit the “any-to-any” nature of
e-mail that motivates most recipient MTAs to accept messages from anywhere
for delivery to their local domain. They may generate messages without
signatures, with incorrect signatures, or with correct signatures from domains
with little traceability. They may also pose as mailing lists, greeting cards, or
other agents that legitimately send or resend messages on behalf of others.

3.3 DKIM STRATEGY IMP QS (question)-10M
DKIM is designed to provide an e-mail authentication technique that is

transparent to the end user.
 In essence, a user’s e-mail message is signed by a private key of the

administrative domain from which the e-mail originates. The signature covers all
of the content of the message and some of the RFC 5322 message headers.
 At the receiving end, the MDA can access the corresponding public key via a DNS
and verify the signature, thus authenticating that the message comes from the
claimed administrative domain.
 Thus, mail that originates from somewhere else but claims to come from a given
domain will not pass the authentication test and can be rejected. This approach
differs from that of S/MIME and PGP, which use the originator’s private key to
sign the content of the message.
 The motivation for DKIM is based on the following reasoning.
1. S/MIME depends on both the sending and receiving users employing S/MIME.
For almost all users, the bulk of incoming mail does not use S/MIME, and the
bulk of the mail the user wants to send is to recipients not using S/MIME.
2. S/MIME signs only the message content. Thus, RFC 5322 header information
concerning origin can be compromised.
3. DKIM is not implemented in client programs (MUAs) and is therefore
transparent to the user; the user need take no action.
4. DKIM applies to all mail from cooperating domains.
5. DKIM allows good senders to prove that they did send a particular message and
to prevent forgers from masquerading as good senders.
The operation of DKIM or Simple Example of DKIM Deployment
Figure 10 is a simple example of the operation of DKIM.

 We begin with a Message generated by a user and transmitted into the MHS to an
MSA that is within the user’s administrative domain.
 An e-mail message is generated by an e-mail client program. The content of the
message, plus selected RFC 5322 headers, is signed by the e-mail provider using
the provider’s private key.

 The signer is associated with a domain, which could be a corporate local

network, an ISP, or a public e-mail facility such as Gmail.
 The signed message then passes through the Internet via a sequence of MTAs. At
the destination, the MDA retrieves the public key for the incoming signature and
verifies the signature before passing the message on to the destination e-mail
client.
Figure 10 Simple Example of DKIM Deployment

 The default signing algorithm is RSA with SHA-256. RSA with SHA-1 also may be
used.
3.4 DKIM FUNCTIONAL FLOW IMP QS (question)-06M
 Figure 11 provides a more detailed look at the elements of DKIM operation.

Basic message processing is divided between a signing Administrative
Management Domain (ADMD) and a verifying ADMD.
 At its simplest, this is between the originating ADMD and the delivering ADMD,
but it can involve other ADMDs in the handling path.

 Signing is performed by an authorized module within the signing ADMD and uses
private information from a Key Store. Within the originating ADMD, this might be
performed by the MUA, MSA, or an MTA.
Figure 11 DKIM Functional Flow

 Verifying is performed by an authorized module within the verifying ADMD.
Within a delivering ADMD, verifying might be performed by an MTA, MDA, or
MUA.
 The module verifies the signature or determines whether a particular signature
was required.
 Verifying the signature uses public information from the Key Store.
 If the signature passes, reputation information is used to assess the signer and
that information is passed to the message filtering system.

 If the signature fails or there is no signature using the author’s domain,

information about signing practices related to the author can be retrieved
remotely and/or locally, and that information is passed to the message filtering
system.( For example, if the sender (e.g., Gmail) uses DKIM but no DKIM
signature is present, then the message may be considered fraudulent)
 The signature includes a number of fields. Each field begins with a tag consisting
of a tag code followed by an equals sign and ends with a semicolon. The fields
include the following:
 v = DKIM version.
 a = Algorithm used to generate the signature; must be either rsa-sha1 or rsa-
sha256.
 c = Canonicalization method used on the header and the body.
 d = A domain name used as an identifier to refer to the identity of a responsible
person or organization. In DKIM, this identifier is called the Signing Domain
Identifier (SDID). In our example, this field indicates that the sender is using a
Gmail address.
 s = In order that different keys may be used in different circumstances for the
same signing domain (allowing expiration of old keys, separate departmental
signing, or the like), DKIM defines a selector (a name associated with a key),
which is used by the verifier to retrieve the proper key during signature
verification.
 h = Signed Header fields. A colon-separated list of header field names that
identify the header fields presented to the signing algorithm. Note that in our
example above, the signature covers the domain key-signature field. This refers
to an older algorithm (since replaced by DKIM) that is still in use.
 bh = The hash of the canonicalized body part of the message. This provides
additional information for diagnosing signature verification failures.
 b = the signature data in base64 format; this is the encrypted hash code.

QUESTION BANK – NETWORK AND CYBER SECURITY

MODULE-2
1. Explain PGP. 06M

2. With a neat diagrams, Explain PGP Cryptographic Functions or PGP Functions
(Authentication, Confidentiality, Confidentiality and Authentication). 14M
3. With a neat diagram, Explain E-mail Compatibility or Transmission and Reception of
PGP Messages. 08M
4. With a neat diagram, explain key identifiers or PGP message format. 08M
5. With a neat diagram, Explain PGP message generations or PGP message
transmission and reception or key rings. 12M
6. With a neat diagram, explain RADIX-64 conversion. 06M OR 08M
7. Explain S/MIME. 06M
8. Explain RFC 5322. 06M
9. Discuss multipurpose internet mail extensions (MIME). 10M
10. Discuss MIME content types. 08M or 10M
11. Short note on 1) MIME transfer encodings 2) native and canonical form 3) S/MIME
functionality 4) S/MIME messages. 12M or 14M
12. Discuss cryptographic algorithms or cryptographic algorithms used in S/MIME .06M
13. Discuss S/MIME certificate processing. 8M or 10M
14. Explain domain keys identified mail. 06M
15. With a neat diagram, explain internet mail architecture. 10M
16. Discuss E-MAIL threats. 10M
17. With a neat diagram, explain DKIM strategy OR DKIM Deployment. 10M
18. With a neat diagram, explain DKIM functional flow. 10M

VTU Network and Cyber Security Module-2 (15ec835, 17ec835) .

Uploaded by

Copyright:

Available Formats

VTU Network and Cyber Security Module-2 (15ec835, 17ec835) .

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VTU Network and Cyber Security Module-2 (15ec835, 17ec835) .

Uploaded by

Copyright:

Available Formats

NETWORK AND CYBER SECURITY

8th SEM E&C

JAYANTHDWIJESH H P M.tech (DECS)

B.G.S INSTITUTE OF TECHNOLOGY (B.G.S.I.T)

NETWORK AND CYBER SECURITY

1. William Stallings, “Cryptography and Network Security Principles and

1. Cryptography and Network Security, Behrouz A. Forouzan, TMH, 2007.

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 1

1. PRETTY GOOD PRIVACY IMP QS (question)-06M

PGP is a remarkable phenomenon. Largely the effort of a single person, Phil

In essence, Zimmermann has done the following:

1. Selected the best available cryptographic algorithms as building blocks.

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 2

Ks = session key used in symmetric encryption scheme

1.1 OPERATIONAL DESCRIPTION

Table 1: Summary of PGP Services

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 3

1.1.1 PGP Operation- Authentication IMP QS (question)-06M

Figure 1 Authentication only

1.1.2 PGP Operation- Confidentiality IMP QS (question)-06M

Figure 2 Confidentiality only

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 4

1.1.3 PGP Operation- Confidentiality and Authentication

Figure 3 Confidentiality and authentication

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 5

NOTE:- Figure 1 Authentication only, Figure 2 Confidentiality only, Figure 3 Confidentiality

1. The signature is generated before compression for two reasons:

1.1.5 PGP Operation – Email Compatibility IMP QS (question)-08M

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 6

Figure 4 Transmissions and Reception of PGP Messages

1. On transmission (if it is required), a signature is generated using a hash code of

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 7

1.2 PGP OPERATION - SEGMENTATION/REASSEMBLY

1.3 KEY IDENTIFIERS OR PGP MESSAGE FORMAT

Figure 5 General Format PGP Message (from A to B)

1.4 PGP MESSAGE GENERATIONS OR PGP MESSAGE

1.4.1 Message transmission

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 9

Figure 6 PGP Message Generation (from User A to User B: no compression or radix-64

Encrypting the message

1.4.2 Message Reception

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 10

Figure 7 PGP Message Reception (from User A to User B; no compression or radix-64

1.5 RADIX-64 CONVERSION IMP QS (question)-06M

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 11

For example, the character “E” is represented in an ASCII based system as

Table 2 Radix-64 Encoding

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 12

Figure 8 Printable Encoding of Binary Data into Radix-64 Format

2. S/MIME IMP QS (question)-06M

 Secure/Multipurpose Internet Mail Extension (S/MIME) is a security

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 13

2.1 RFC 5322 IMP QS (question)-06M

2.2 MULTIPURPOSE INTERNET MAIL EXTENSIONS

Multipurpose Internet Mail Extension (MIME) is an extension to the RFC 5322

Dept. of ECE, BGSIT, BG Nagara, Mandya. Page 14

Lists the following limitations of the SMTP/5322 scheme.

1. SMTP cannot transmit executable files or other binary objects. A number of

The MIME specification includes the following elements.

The five header fields defined in MIME are