Module V : Application Layer Security

Dimple Bohra
Contents
● E-mail Architecture, Email Security
● PGP, Key Rings, PGP Algorithms
● PGP Certificate
ELECTRONIC MAIL (E-Mail)
One of the most popular Internet services is
electronic mail (e-mail). The designers of the
Internet probably never imagined the popularity of
this application program. Its architecture consists
of several components.
Three main components are : User Agent (UA),
Message Transfer Agent (MTA) and Message
Access Agent (MAA).
Electronic mail (Contd..)
To explain the architecture of e-mail, consider
four scenarios:
1. When sender and receiver on the same system.
2. When sender and receiver on different system.
3. When sender is connected to mail server via LAN
or WAN.
4. When sender and receiver both are connected to
their mail server via LAN or WAN.
First scenario in electronic mail
Note
When the sender and the receiver of an
e-mail are on the same system,
we need only two user agents.
Second scenario in electronic mail
Note
When the sender and the receiver of an
e-mail are on different systems, we
need two UAs and a pair of
MTAs (client and server).
Third scenario in electronic mail
Note
When the sender is connected to the
mail server via a LAN or a WAN,
we need two UAs and two pairs
of MTAs (client and server).
Fourth scenario in electronic mail
E-mail Architecture
■ The administrator of the
e-mail server at Alice’s site
has created a queuing
system that sends e-mail to
the Internet one by one.
■ The administrator of e-mail
server at Bob’s site has
created a mailbox for every
user connected to the server.
User Agent (UA)
■ The first component of an electronic mail system is the
user agent (UA) program used to prepare message.
■ User agents are of two types: command driven and GUI
based.
■ Services Provided by a User Agent:
A user agent composes, reads, replies to, and forwards
messages.
It also handles mailboxes.
Services of user agent
Message Transfer Agent (MTA)
■ The actual mail transfer is done through message
transfer agents. MTA is used to send message to mail
server.
■ To send mail, a system must have the client MTA, and
to receive mail, a system must have a server MTA.
■ The formal protocol that defines the MTA client and
server in the Internet is called the Simple Mail Transfer
Protocol (SMTP).
SMTP range
Message Access Agent (MAA)
■ The reading of the received message is done
through MAA. It is designed to pull messages
from the server.
■ MAA is also client server program.
■ The formal protocols that defines MAA client
and server are : Post Office Protocol, version 3
(POP3) and Internet Mail Access Protocol,
version 4 (IMAP4).
Format of an e-mail
E-mail Architecture
■ When Alice needs to send a message to Bob, Alice invokes a user agent (UA)
program to prepare the message.
■ Alice then uses another program, a message transfer agent (MTA), to send the
message to the mail server at her site. Note that the MTA is a client/server
program with the client installed at Alice's computer and the server installed at
the mail server.
■ The message received at the mail server at Alice's site is queued with all other
messages; each goes to its corresponding destination.
■ In Alice's case, her message goes to the mail server at Bob's site.
■ A client/server MTA is responsible for the e-mail transfer between the two
servers.
■ When the message arrives at the destination mail server, it is stored in Bob's
mailbox, a special file that holds the message until it is retrieved by Bob.
■ When Bob needs to retrieve his messages, he invokes another program, which
we call a message access agent (MAA)
E-mail Architecture
■ The sending of an e-mail from Alice to Bob is a store-retrieve
activity.
■ The main communication between Alice and Bob is through
two application programs: the MTA client at Alice's computer
and the MAA client at Bob's computer.
■ The MTA client program is a push program. The MAA client
program is a pull program.
■ Alice and Bob cannot directly communicate using an MTA
client at the sender site and an MTA server at the receiver
site.
Protocols used in E-mail
Protocols used in E-mail
■ SMTP uses commands and responses to transfer messages between an
MTA client and an MTA server.
■ POP3 Post Office Protocol, version 3 (POP3) is simple but limited in
functionality. The client POP3 software is installed on the recipient
computer; the server POP3 software is installed on the mail server.
■ POP3 has two modes: the delete mode and the keep mode. In the delete
mode, the mail is deleted from the mailbox after each retrieval. In the keep
mode, the mail remains in the mailbox after retrieval
■ IMAP4 protocol is Internet Mail Access Protocol, version 4 (IMAP4). IMAP4
is similar to POP3, but it has more features; IMAP4 is more powerful and
more complex.
 E-mail Security
● Sending an e-mail is a one-time activity.
● Normally message contents are not secured. Messages Can be
read/modified either in transit or at destination by the attacker. It is like
postcard service, just pick it and read it.
● We need to discuss the security of a unidirectional message because what
Alice sends to Bob is totally independent from what Bob sends to Alice.
● If e-mail is a one-time activity, how can the sender and receiver agree on
a cryptographic algorithm to use for e-mail security? If there is no session
and no handshaking to negotiate the algorithms for encryption/decryption
and hashing, how can the receiver know which algorithm the sender has
chosen for each purpose?
E-mail Security : Cryptographic Algorithms
● One solution is for the underlying protocol to select one algorithm for
each cryptographic operation and to force Alice to use only those
algorithms. This solution is very restrictive and limits the capabilities of
the two parties.
● A better solution is for the underlying protocol to define a set of
algorithms for each operation that the user used in his/her system.
Alice includes the name (or identifiers) of the algorithms she has used
in the e-mail.

**In e-mail security, the sender of the message needs to include

the name or identifiers of the algorithms used in the message.
 E-mail Security : Cryptographic Secrets
● The same problem applies to the cryptographic secrets (keys).
● If there is no negotiation, how can the two parties establish secrets
between themselves?
● Alice and Bob could use asymmetric-key algorithms for
authentication and encryption, which do not require the
establishment of a symmetric key.
● Most e-mail security protocols today require that
encryption/decryption be done using a symmetric-key algorithm and
a one-time secret key sent with the message.
 E-mail Security : Cryptographic Secrets
● Alice can create a secret key and send it with the message she
sends to Bob.
● To protect the secret key from interception by Eve, the secret
key is encrypted with Bob’s public key. i.e. Secret key itself is
encrypted.
● In e-mail security, the encryption/decryption is done using a
symmetric-key algorithm, but the secret key to decrypt the
message is encrypted with the public key of the receiver and is
sent with the message.
 E-mail Security : Certificates
● It is obvious that some public-key algorithms must be used for
e-mail security.
● To encrypt the secret key, Alice needs Bob's public key; to verify
a signed message, Bob needs Alice's public key.
● So, for sending a small authenticated and confidential message,
two public keys are needed.
● How can Alice be assured of Bob's public key, and how can Bob
be assured of Alice's public key?
● Each e-mail security protocol has a different method of certifying
keys.
PRETTY GOOD PRIVACY (PGP)

● PGP was invented by Phil Zimmermann to provide e-mail with

privacy, integrity, and authentication.
● PGP can be used to create a secure e-mail message or to store a
file securely for future retrieval
PRETTY GOOD PRIVACY (PGP)
Plaintext

● The simplest scenario is to send the e-mail message (or store the file)
in plaintext

● There is no message integrity or confidentiality in this scenario.

● Alice, the sender, composes a message and sends it to Bob, the
receiver.
● The message is stored in Bob's mailbox until it is retrieved by him.
PRETTY GOOD PRIVACY (PGP)
Message Integrity
● Probably the next improvement is to let Alice sign the message.
● Alice creates a digest of the message and signs it with her private key.
● When Bob receives the message, he verifies the message by using Alice's public
key.
● Two keys are needed for this scenario.
● Alice needs to know her private key; Bob needs to know Alice's public key.

●
PRETTY GOOD PRIVACY (PGP)
Compression
● A further improvement is to compress the message and digest to make
the packet more compact.
● This improvement has no security benefit, but it eases the traffic.
PRETTY GOOD PRIVACY (PGP)
Confidentiality with One-Time Session key
● As we discussed before, confidentiality in an e-mail system can be achieved
using conventional encryption with a one-time session key.
● Alice can create a session key, use the session key to encrypt the message and
the digest, and send the key itself with the message.
● However, to protect the session key, Alice encrypts it with Bob's public key.
PRETTY GOOD PRIVACY (PGP)
Confidentiality with One-Time Session key
● When Bob receives the packet, he first decrypts the key, using his private key
to remove the key.
● He then uses the session key to decrypt the rest of the message. After
decompressing the rest of the message, Bob creates a digest of the message
and checks to see if it is equal to the digest sent by Alice. If it is, then the
message is authentic.
PRETTY GOOD PRIVACY (PGP)
Code Conversion

● Another service provided by PGP is code conversion. Most e-mail systems

allow the message to consist of only ASCII characters. To translate other
characters not in the ASCII set, PGP uses Radix-64 conversion. Each
character to be sent (after encryption) is converted to Radix-64 code.

Segmentation

● PGP allows segmentation of the message after it has been converted to

Radix-64 to make each transmitted unit the uniform size as allowed by the
underlying e-mail protocol.
A scenario in which an e-mail message is authenticated and encrypted
Key Rings
● When Alice need to send messages to many people, Alice needs a
ring of public keys, with a key belonging to each person with whom
Alice needs to correspond (send or receive messages).
● In addition, the PGP designers specified a ring of private/public keys.
● One reason is that Alice may wish to change her pair of keys from
time to time.
● Another reason is that Alice may need to correspond with different
groups of people (friends, colleagues, and so on). Alice may wish to
use a different key pair for each group.
● Therefore, each user needs to have two sets of rings: a ring of
private/public keys and a ring of public keys of other people.
Key Rings in PGPings
Key Rings
Note that everyone can have more than one public key. Two cases may arise.

1. Alice needs to send a message to another person in the community.

● She uses her private key to sign the digest.
● She uses the receiver's public key to encrypt a newly created session key.
● She encrypts the message and signed digest with the session key created.
2. Alice receives a message from another person in the community.
● She uses her private key to decrypt the session key.
● She uses the session key to decrypt the message and digest.
● She uses her public key to verify the digest.
PGP Algorithms
1. Public key
algorithms:
used for signing
the digests or
encrypting the
messages
PGP Algorithms
2. Symmetric-key Algorithms: Used for conventional encrypting
PGP Algorithms
3. Hash Algorithms: Used for creating hashes
PGP Algorithms
4. Compression Algorithms: Used for compressing text
PGP Certificates
● PGP, like other protocols (IPSec, SSL/TLS) uses certificates to authenticate public
keys. However, the process here is totally different.
X.509 Certificates
● Protocols that use X.509 certificates depend on the hierarchical structure of the
trust.
● There is a predefined chain of trust from the root to any certificate. Every user
fully trusts the authority of the CA at the root level (prerequisite). The root
issues certificates for the CAs at the second level, a second level CA issues a
certificate for the third level, and so on. Every party that needs to be trusted
presents a certificate from some CA in the tree.
● If Alice does not trust the certificate issuer for Bob, she can appeal to a
higher-level authority up to the root (which must be trusted for the system to
work). So basically there is one single path from a fully trusted CA to a
certificate.
PGP Certificates
● In PGP, there is no need for CAs; anyone in the ring can sign a certificate for
anyone else in the ring. Bob can sign a certificate for Ted, John, Anne, and so
on.
● There is no hierarchy of trust in PGP; there is no tree. The lack of hierarchical
structure may result in the fact that Ted may have one certificate from Bob
and another certificate from Liz.
● If Alice wants to follow the line of certificates for Ted, there are two paths:
one starts from Bob and one starts from Liz. An interesting point is that Alice
may fully trust Bob, but only partially trust Liz. There can be multiple paths in
the line of trust from a fully or partially trusted authority to a certificate. In
PGP, the issuer of a certificate is usually called an introducer.
** In PGP, there can be multiple paths from fully or partially trusted authorities
to any subject
PGP Certificates : Trusts and Legitimacy
● The entire operation of PGP is based on introducer trust, the certificate trust, and the legitimacy of
the public keys.

Introducer Trust Levels

● With the lack of a central authority, it is obvious that the ring cannot be very large if every user in the
PGP ring of users has to fully trust everyone else.
● To solve this problem, PGP allows different levels of trust. The number of levels is mostly
implementation dependent, but for simplicity, let us assign three levels of trust to any introducer:
none, partial, and full.
● The introducer trust level specifies the trust levels issued by the introducer for other people in the
ring.
● For example, Alice may fully trust Bob, partially trust Anne, and not trust John at all. There is no
mechanism in PGP to determine how to make a decision about the trustworthiness of the
introducer; it is up to the user to make this decision.
PGP Certificates : Trusts
and Legitimacy
Certificate Trust Levels
● When Alice receives a certificate from an introducer, she stores the certificate under the name of the
subject (certified entity). She assigns a level of trust to this certificate.
● The certificate trust level is normally the same as the introducer trust level that issued the
certificate.
● Assume that Alice fully trusts Bob, partially trusts Anne and Janette, and has no trust in John. The
following scenarios can happen:
1. Bob issues two certificates, one for Linda (with public key K1) and one for Lesley (with public key K2).
Alice stores the public key and certificate for Linda under Linda's name and assigns a full level of
trust to this certificate. Alice also stores the certificate and public key for Lesley under Lesley's name
and assigns a full level of trust to this certificate.
PGP Certificates :
Trusts and Legitimacy

Certificate Trust Levels

2. Anne issues a certificate for John (with public key K3). Alice stores this certificate and public key
under John's name, but assigns a partial level for this certificate.

3. Janette issues two certificates, one for John (with public key K3) and one for Lee (with public key
K4). Alice stores John's certificate under his name and Lee's certificate under his name, each with a
partial level of trust. Note that John now has two certificates, one from Anne and one from Janette,
each with a partial level of trust.

4. John issues a certificate for Liz. Alice can discard or keep this certificate with a signature trust of
none.
PGP Certificates : Trusts and Legitimacy
Key Legitimacy
● The purpose of using introducer and certificate trusts is to
determine the legitimacy of a public key.
● Alice needs to know how legitimate the public keys of Bob,
John, Liz, Anne, and so on are.
● PGP defines a very clear procedure for determining key
legitimacy.
PGP Certificates : Trusts and Legitimacy
Key Legitimacy
● The level of the key legitimacy for a user is the weighted trust levels of that user. For
example, suppose we assign the following weights to certificate trust levels:
1. A weight of 0 to a non trusted certificate
2. A weight of 1/2 to a certificate with partial trust
3. A weight of 1 to a certificate with full trust
● Then to fully trust an entity, Alice needs one fully trusted certificate or two partially
trusted certificates for that entity.
● For example, Alice can use John's public key in the previous scenario because both Anne
and Janette have issued a certificate for John, each with a certificate trust level of 1/2.
● Note that the legitimacy of a public key belonging to an entity does not have anything to
do with the trust level of that person.
● Although Bob can use John's public key to send a message to him, Alice cannot accept
any certificate issued by John because, for Alice, John has a trust level of none.
PGP Certificates : Starting the Ring
In PGP, the key legitimacy of a trusted or partially trusted entity can be also determined by other methods.

● Alice can physically obtain Bob's public key. For example, Alice and Bob can meet personally and exchange
a public key written on a piece of paper or to a disk.
● If Bob's voice is recognizable to Alice, Alice can call him and obtain his public key on the phone.
● A better solution proposed by PGP is for Bob to send his public key to Alice by e-mail. Both Alice and Bob
make a 16-byte MD5 (or 20-byte SHA-1) digest from the key. The digest is normally displayed as eight
groups of 4 digits (or ten groups of 4 digits) in hexadecimal and is called a fingerprint. Alice can then call
Bob and verify the fingerprint on the phone. If the key is altered or changed during the e-mail
transmission, the two fingerprints do not match. To make it even more convenient, PGP has created a list
of words, each representing a-4-digit combination. When Alice calls Bob, Bob can pronounce the eight
words (or ten words) for Alice. The words are carefully chosen by PGP to avoid those similar in
pronunciation; for example, if sword is in the list, word is not.
● In PGP, nothing prevents Alice from getting Bob's public key from a CA in a separate procedure. She can
then insert the public key in the public key ring.
PGP Certificates : Key Ring Tables
● Each user, such as Alice, keeps track of two key rings: one private-key ring and
one public key ring.
● PGP defines a structure for each of these key rings in the form of a table.

Private Key Ring Table

PGP Certificates : Key Ring Tables
Private Key Ring Table

User ID: The user ID is usually the e-mail address of the user. However, the user may designate a unique
e-mail address or alias for each key pair. The table lists the user ID associated with each pair.
Key ID: This column uniquely defines a public key among the user's public keys.
In PGP, the key ID for each pair is the first (least significant) 64 bits of the public key. In other words, the
key ID is calculated as (key mod 264). The key ID is needed for the operation of PGP because Bob may
have several public keys belonging to Alice in his public key ring. When he receives a message from
Alice, Bob must know which key ID to use to verify the message. The key ID, which is sent with the
message, enables Bob to use a specific public key for Alice from his public ring. The entire public key is
not sent because in public-key cryptography, the size of the public key may be very long. Sending just 8
bytes reduces the size of the message.
PGP Certificates : Key Ring Tables
Private Key Ring Table

Public Key: This column just lists the public key belonging to a particular private key/public key
pair.
Encrypted Private Key: This column shows the encrypted value of the private key in the private
key/public key pair. Although Alice is the only person accessing her private ring, PGP saves only
the encrypted version of the private key. We will see later how the private key is encrypted and
decrypted.
Timestamp : This column holds the date and time of the key pair creation. It helps the user
decide when to purge old pairs and when to create new ones.
PGP Certificates : Key Ring Tables
Public Key Ring Table

User ID: As in the private key ring table, the user ID is usually the e-mail address of the user.
Key ID: As in the private key ring table, the key ID for each pair is the first (least significant) 64 bits of the
public key

Public Key: This is public key of the entity

Producer Trust: This column defines the producer level of trust. In most implementations, it can
only be of one of three values: none, partial, or full.
Certificate(s): This column holds the certificate or certificates signed by other entities for this
entity. A user ID may have more than one certificate.
PGP Certificates : Key Ring Tables
Public Key Ring Table

Certificate Trust(s): This column represents the certificate trust or trusts. If Anne sends a certificate for
John, PGP searches the row entry for Anne, finds the value of the producer trust for Anne, copies that
value, and inserts it in the certificate trust field in the entry for John.
Key Legitimacy: This value is calculated by PGP based on the value of the certificate trust and the
predefined weight for each certificate trust.
Timestamp: This column holds the date and time of the column creation.
Key Ring Table Illustration with Example
Thank You!!!!