UNIT IV

APPLICATION LAYER SECURITY

Electronic Mail Security: Pretty Good Privacy, S/MIME, DomainKeys
Identified Mail. Wireless Network Security: Mobile Device Security

4.1 PRETTY GOOD PRIVACY:

 PGP provides the confidentiality and authentication service that can be
used for electronic mail and file storage applications.
 The steps involved in PGP are
1. Select the best available cryptographic algorithms as building blocks.
2. Integrate 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-touse commands.
3. Make the package and its documentation, including the source code,
freely available via the internet, bulletin boards and commercial networks.
4. Enter into an agreement with a company 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.
 It is available free worldwide in versions that run on a variety of platform.
 It is based on algorithms that have survived extensive public review and
are considered extremely secure.
 e.g., RSA, DSS and Diffie Hellman for public key encryption It has a wide
range of applicability.
 It was not developed by, nor it is controlled by, any governmental or
standards organization.

Operational description
The actual operation of PGP consists of five services:
 1. Authentication

2. Confidentiality

3. Compression

4. E-mail compatibility

5. Segmentation.

1. Authentication

 The sequence for authentication is as follows: The sender creates the

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 pretended 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.
2. Confidentiality

 Confidentiality is provided by encrypting messages to be

transmitted or to be stored locally as files.
 In both cases, the conventional encryption algorithm CAST-128
may be used. The 64-bit cipher feedback (CFB) mode is used.
 In PGP, each conventional key is used only once. That is, a new
key is generated as a random 128-bit number for each message.
Thus although this is referred to as a session key, it is in reality a
onetime key.
 To protect the key, it is encrypted with the receiver‟s public key.
3. Compression

As a default, PGP compresses the message after applying the signature

 but before encryption. This has the benefit of saving space for both e-
mail transmission and for file storage. 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. If one signed a compressed document, then it would be
necessary either to store a compressed version of the message for later
verification or to recompress the message when verification is required.
Even if one were willing to generate dynamically a recompressed
message from verification, PGP‟s compression algorithm presents a
difficulty. The algorithm is not deterministic; various implementations
of the algorithm achieve different tradeoffs in running speed versus
compression ratio and as a result, produce different compression forms.
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. The compression algorithm
used is ZIP.
4. E-mail compatibility
Many electronic mail systems only permit the use of blocks consisting
of ASCII texts. 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.

5. Segmentation and reassembly

E-mail facilities often are restricted to a maximum length. E.g., 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 the other
processing, including the radix-64 conversion. At the receiving end, PGP must
strip off all e-mail headers and reassemble the entire original block before
performing the other steps.

Cryptographic keys and key rings

Three separate requirements can be identified with respect to these keys:

A means of generating unpredictable session keys is needed.
It must allow a user to have multiple public key/private key pairs.
Each PGP entity must maintain a file of its own public/private key pairs
as well as a file of public keys of correspondents.
a. Session key generation
Each session key is associated with a single message and is used only
for the purpose of encryption and decryption of that message. Random
128-bit numbers are generated using CAST-128 itself.
The input to the random number generator consists of a 128-bit key and
two 64-bit blocks that are treated as plaintext to be encrypted. Using
cipher feedback mode, the CAST-128 produces two 64-bit cipher text
blocks, which are concatenated to form the 128-bit session key. The
plaintext input to CAST-128 is itself derived from a stream of 128-bit
randomized numbers.These numbers are based on the keystroke input
from the user.
b. Key identifiers

If multiple public/private key pair are used, then how does the recipient
know which of the public keys was used to encrypt the session key? One
simple solution would be to transmit the public key with the message
but, it is unnecessary wasteful of space. Another solution would be to
associate an identifier with each public key that is unique at least within
each user. The solution adopted by PGP is to assign a key ID to each
public key that is, with very high probability, unique within a user ID.
The key ID associated with each public key consists of its least
significant 64 bits. i.e., the key ID of public key KUa is (KUa mod
264).
A message consists of three components.
 Message component – includes actual data to be transmitted, as well
as the filename and a timestamp that specifies the time of creation
 Session key component – includes session key and the identifier of the
recipient public key.
Signature component – includes the following Timestamp – time at
which the signature was made. Message digest – hash code.

Two octets of message digest – to enable the recipient to determine if

the correct public key was used to decrypt the message.

Key ID of sender’s public

key – identifies the public key
Notation:

EkUb= encryption with user B‟s Public key EKRa= encryption with user
A‟s private key EKs = encryption with session key
ZIP = Zip compression function
R64 = Radix- 64 conversion function
Transmission and Reception of PGP message

PGP provides a pair of data structures at each node, one to store the
public/private key pair owned by that node and one to store the public
keys of the other users known at that node. These data structures are
referred to as private key ring and public key ring. The general
structures of the private and public key rings are shown below:
Timestamp - the date/time when this entry was made.
Key ID - the least significant bits of the public key.

Public key - public key portion of the pair.

 Private Key - private key portion of the pair. User ID - the owner of
the key

Key legitimacy field – indicates the extent to which PGP will trust that
this is a valid public key for this user.

Signature trust field – indicates the degree to which this PGP user trusts the
signer to certify public key.

Owner trust field - indicates the degree to which this public key is trusted to
sign other public key certificates
1.Signing the message
 PGP retrieves the sender‟s private key from the private key ring
using user ID as an index. If user ID was not provided, the first private
 key from
the ring is
retrieved.

2. Encrypting the message

 PGP generates a session key and encrypts the message.
PGP retrieves the recipient‟s public key from the public key ring using user ID
as index.
 The receiving PGP entity performs the following steps:

1. Decrypting the message

 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.
 PGP prompts the user for the passphrase (password) to recover the
unencrypted private key.
 PGP then recovers the session key and decrypts the message.
2. Authenticating the message
 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.
 PGP recovers the transmitted message digest. PGP computes the
message digest for the received message and compares it to the transmitted
message digest to authenticate.
 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.

Multipurpose Internet Mail Extensions

MIME is an extension to the RFC 822 framework that is intended to

address some of the problems and limitations of the use of SMTP
(Simple Mail Transfer Protocol) or some other mail transfer protocol and
RFC 822 for electronic mail.

Following are the limitations of SMTP/822 scheme:

1. SMTP cannot transmit executable files or other binary objects.

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
MIME is intended to resolve these problems in a manner that is compatible
with existing RFC 822 implementations. The specification is provided in
RFCs 2045 through 2049.

OVERVIEW

The MIME specification includes the following elements:

1. Five new message header fields are defined, which may be included
in an RFC 822 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.
In this subsection, we introduce the five message header fields. The next
two subsections deal with content formats and transfer encodings.

The five header fields defined in MIME are as follows:

 MIME-Version: Must have the parameter value 1.0. This

field indicates that the message conforms to RFCs 2045 and
2046.
 Content-Type: Describes the data contained in the body with sufficient
detail.
 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.
 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 readable (e.g.,
audio data).

MIME Content Types

There are seven different major types of content and a total of 15 subtypes
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. [PARZ06] 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
nontextual 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
MIME is intended to resolve these problems in a manner that is compatible
with existing RFC 5322 implementations. The specification is provided in
RFCs 2045 through 2049.

Functions

• Enveloped data: This consists of encrypted content of any type and

encryptedcontent encryption keys for one or more recipients.
• 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.

• 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.
• 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.
DOMAIN KEYS IDENTIFIED MAIL:
 DomainKeys 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.

INTERNET MAIL ARCHITECTURE:

 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).
 The MHS accepts a message from one user and delivers it to one or
more other users, creating a virtual MUA-to-MUA exchange
environment.
 This architecture involves three types of interoperability. One is directly
between users: messages must be formatted by the MUA on behalf of
the message author so that the message can be displayed to the message
recipient by the destination MUA.
 There are also interoperability requirements between the MUA and the
MHS—first when a message is posted from an MUA to the MHS and
later when it is delivered from the MHS to the destination MUA.
 Interoperability is required among the MTA components along the
transfer path through the MHS.
 The key components of the Internet mail architecture, which include the
following.
 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.
 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.
 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.
 Mail Delivery Agent (MDA): Responsible for transferring the
message from the MHS to the MS.
 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).
  An Administrative Management Domain (ADMD): An Internet e-
mail provider. Examples include a department that operates a local
mail relay (MTA), an IT department that operates an enterprise mail
relay, and an ISP that operates a public shared e-mail service. Each
ADMD can have different operating policies and trust-based
decision making.
 The Domain Name System (DNS): A directory lookup service that
provides a mapping between the name of a host on the Internet and
its numerical address.

E-MAIL THREATS:
Analysis of Threats Motivating DomainKeys Identified Mail describes
the threats being addressed by DKIM in terms of the characteristics,
capabilities, and location of potential attackers.

1. Characteristics:
 Characterizes the range of attackers on a spectrum of three levels of
threat.
 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.
 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.
 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.

2. Capabilities:
The following as capabilities that an attacker might have,
 Submit messages to MTAs and Message Submission Agents (MSAs)
at multiple locations in the Internet.
 Construct arbitrary Message Header fields, including those claiming
to be mailing lists, resenders, and other mail agents.
 Sign messages on behalf of domains under their control.
 Generate substantial numbers of either unsigned or apparently signed
messages that might be used to attempt a denial-of-service attack.
  Resend messages that may have been previously signed by the
domain.
 Transmit messages using any envelope information desired.
 Act as an authorized submitter for messages from a compromised
computer.
 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.
 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.
 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.
 Ability to eavesdrop on existing traffic, perhaps from a wireless
network.

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.
DKIM STRATEGY:
 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.
 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.
 S/MIME signs only the message content. Thus, RFC 5322
header information concerning origin can be compromised.
 DKIM is not implemented in client programs (MUAs) and is
therefore transparent to the user; the user need take no action.
 DKIM applies to all mail from cooperating domains.
 DKIM allows good senders to prove that they did send a
particular message and to prevent forgers from masquerading as
good senders.
  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 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.
 The default signing algorithm is RSA with SHA-256. RSA with SHA-1
also may be used.
Wireless network security:
  Wireless network security is the process of designing, implementing and
ensuring security on a wireless computer network.
 It is a subset of network security that adds protection for a wireless
computer network.
 Wireless network security primarily protects a wireless network from
unauthorized and malicious access attempts.
 Typically, wireless network security is delivered through wireless devices
(usually a wireless router/switch) that encrypts and secures all wireless
communication by default.
 Even if the wireless network security is compromised, the hacker is not
able to view the content of the traffic/packet in transit.
 Moreover, wireless intrusion detection and prevention systems also
enable protection of a wireless network by alerting the wireless network
administrator in case of a security breach.
 Some of the common algorithms and standards to ensure wireless
network security are Wired Equivalent Policy (WEP) and Wireless
Protected Access (WPA).
MOBILE DEVICE SECURITY:
Mobile security is the strategy, infrastructure, and software used to protect any
device that travels with users, including smartphones, tablets, and laptops.
Cybersecurity for mobile devices includes protecting data on the local device
and the device-connected endpoints and networking equipment. As mobile
devices continue to be a user preference over desktops, they will be bigger
targets for attackers.
 some key aspects of mobile device security:

1. Device Locking:
 Set up a strong PIN, password, or biometric authentication (fingerprint,
facial recognition) to lock your device.
 Enable auto-lock to ensure the device locks automatically after a period
of inactivity.
2. Operating System Updates:
 Regularly update your device's operating system to patch vulnerabilities
and ensure you have the latest security features.
3. App Security:
 Download apps only from official app stores (Google Play for Android,
App Store for iOS).
 Keep apps updated to benefit from security patches and bug fixes.
 Be cautious about granting unnecessary permissions to apps.
4. Mobile Security Apps:
 Install reputable mobile security apps that offer features like antivirus,
anti-malware, and remote tracking/locking/wiping in case of theft or loss.
5. Network Security:
 Avoid connecting to unsecured Wi-Fi networks, especially for sensitive
transactions.
 Use a Virtual Private Network (VPN) when connecting to public Wi-Fi to
encrypt data traffic.
6. Data Encryption:
 Enable device encryption to protect your data in case the device falls into
the wrong hands.
 Use secure protocols (HTTPS) when accessing websites to encrypt data
during transmission.
7. Backup and Recovery:
 Regularly back up your data to the cloud or a secure external device.
 Understand how to remotely wipe or track your device in case it is lost or
stolen.
8. Bluetooth and NFC Security:
 Turn off Bluetooth and NFC when not in use to prevent unauthorized
access or data interception.
9. Secure Browsing Practices:
 Be cautious when clicking on links, especially in emails or messages, to
avoid phishing attacks.
 Use a secure and updated web browser.
10. Remote Management:
 Enable remote tracking and management features offered by your
device's operating system.
 Understand how to remotely wipe your device if it is lost or stolen.
11. User Education:
 Educate yourself and other users about common security threats and best
practices.
 Be wary of downloading attachments or clicking on links from unknown
sources.
12. Physical Security:
 Keep your device physically secure, and do not leave it unattended in
public places.
 Consider using physical security measures such as biometric locks or
secure cases.