You are on page 1of 60

Layered Organization

• The application layer software running at the source

node creates the data (in the form of data units
called as frames or packets) to be transmitted to the
application layer software running at a destination
node (remember virtual path?).
• It hands it over to the transport layer at the source
node. Each of the remaining TCP/IP layers from this
point onwards adds its own header to the frame as it
moves from this layer (transport layer) to the
bottommost layer (the physical layer) at the source
• At the lowest physical layer, the data is transmitted
as voltage pulses across the communication medium
such as coaxial cable.
That means that, the application layer (layer 5)
hands over the entire data to the transport
Let us call this as L5 data. After the transport
layer receives and processes this data, it adds its
own header to the original data and sends it to
the next layer in the hierarchy (i.e. the Internet
Therefore, from the fourth (transport) layer to
the third (Internet) layer, the data is sent as L5
data + H4, where H4 is the header added by the
fourth (transport) layer.
Now, for the third (Internet) layer, L5 data + H4
is the input data. Let us call this together as L4
When the third (Internet) layer sends this data
to the next, i.e. the second (data link) layer, it
sends the original data (which is L4 data) plus
its own header H3 together, i.e. L4 data + H3,
and so on.
In the end, the original data (L5) and all the
headers are sent across the physical medium.
Secure Socket Layer (SSL)
• The Secure Socket Layer protocol is an Internet
protocol for secure exchange of information between
a Web browser and a Web server.
• It provides two basic security services:
authentication and confidentiality.
• Logically, it provides a secure pipe between the web
browser and the Web server.
• Netscape Corporation developed SSL in 1994. Since
then, SSL has become the world's most popular Web
security mechanism.
• All the major web browsers support SSL.
• Currently, SSL comes in three versions: 2,3 and 3.1.
• The most popular of them is Version 3, which was
released in 1995.
The Position of SSL in TCP/IP
Protocol Suite
• SSL can be conceptually considered as an
additional layer in the TCP/IP protocol suite.
• The SSL layer is located between the
application layer and the transport layer, as
shown in Fig. 6.9.
• As such, the communication between the
various TCP/IP protocol layers is now as shown
in Fig. 6.10.
• As we can see, the application layer of the sending
computer (X) prepares the data to be sent to the
receiving computer (Y), as usual.
• However, unlike what happens in the normal case,
the application layer data is not passed directly to
the transport layer now.
• Instead, the application layer data is passed to the
SSL layer. Here, the SSL layer performs encryption
on the data received from the application layer
(which is indicated by a different color) and also
adds its own encryption information header called
as, SSL Header (SH)to the encrypted data.
• After this, the SSL layer data (LS) becomes the
input for the transport layer. It adds its own
header (H4), and passes it on to the Internet
layer and so on.
• This process happens exactly the way it
happens in the case of a normal TCP/IP data
• Finally, when the data reaches the physical
layer, it is sent in the form of voltage pulses
across the transmission medium.
• At the receiver's end, the process happens
pretty similar to how it happens in the case of a
normal TCP/IP connection, until it reaches the
new SSL layer.
• The SSL layer at the receiver's end removes the
SSL Header (SH), decrypts the encrypted data
and gives the plain text data back to the
application layer of the receiving computer.
• Thus, only the application layer data is encrypted by SSL.
The lower layer headers are not encrypted.
• This is quite obvious: if SSL has to encrypt all the headers, it
must be positioned below the data link layer. That would
serve no purpose at all.
• In fact, it would lead to problems. If SSL encrypted all the
lower layer headers, even the IP and physical addresses of
the computers (sender, receiver, and intermediate nodes)
would be encrypted and become unreadable.
• Thus, the address to deliver the packets would be
unknown. To understand the problem, imagine what would
happen if we put the address of the sender and the
receiver of a letter inside the envelope! Clearly, the postal
service would not know where to send the letter!
• This is also the reason for not encrypting the lower layer
headers. Therefore, SSL is required between the application
and the transport layers.
How SSL Works?
• SSL has three sub-protocols, namely the
Handshake Protocol, the Record Protocol and
the Alert Protocol.
• These three sub-protocols constitute the overall
working of SSL.
• We shall take a look at all the three protocols
Handshake Protocol
• The handshake protocol of SSL is the first sub-
protocol used by the client and the server to
communicate using an SSL-enabled connection.
• This is similar to how Alice and Bob would first
shake hands with each other with a hello before
they start conversing.
• As the figure shows, the handshake protocol
consists of a series of messages‘ between the
client and the server. Each of these messages has
the format shown in Fig. 6.11.
• As shown in the figure, each handshake
message has three fields, as follows:
• Type (1 byte): This field indicates one of the
ten possible message types. These ten
message types are listed in Fig. 6.12.
• Length (3 bytes): This field indicates the length
of the message in bytes.
• Content (1 or more bytes): This field contains the
parameters associated with this message,
depending on the message type, as listed in Fig.
• Let us now take a look at the possible messages
exchanged by the client and the server in the
handshake protocol, along with their
corresponding parameters, as shown in Fig. 6.12.
• The handshake protocol is actually made up of
four phases, as shown in Fig. 6.13. These
phases are:
• 1. Establish security capabilities -
• 2. Server authentication and key exchange
• 3. Client authentication and key exchange
• 4. Finish
Phase 1
Phase 2
Phase 3
Phase 4
Pretty Good Privacy
Security for Electronic Email

There are two main schemes which are especially
designed to provide confidentiality and
authentication for electronic mail systems. These

(Pretty Good Privacy)

(Secure/Multipurpose Internet Mail Extension)

S/MIME uses public key certificates
conforming to standard X.509 and signed by a
certification agency. In other respects,
S/MIME is quite similar to PGP.
S/MIME is not studied in any detail on this
course and is not examinable.
Details of the scheme are available in Chapter
5 of Stalling if you are interested.

• Developed by Phil Zimmerman in 1995.
• Documentation and source code is freely
• The package is independent of operating
system and processor.
• PGP does not rely on the “establishment” and
it’s popularity and use have grown extensively
since 1995.

• PGP combines the best available
cryptographic algorithms to achieve
secure e-mail communication.
• It is assumed that all users are using
public key cryptography and have
generated a private/public key pair.
• Either RSA (with RSA digital signatures) or
El Gamel (with DSA) can be used.
• All users also use a symmetric key system
such as triple DES or Rijndael.

What does PGP do?
PGP offers 5 services:
1. Authentication
2. Confidentiality
3. Compression
4. E-mail compatibility
5. Segmentation

PGP Authentication
This is a digital signature scheme with
1. Alice has (private/public) key pair (Ad/Ae)
and she wants to send a digitally signed
message m to Bob.
2. Alice hashes the message using SHA-1 to
obtain SHA(m).

3. Alice encrypts the hash using her private
key Ad to obtain ciphertext c given by

4. Alice sends Bob the pair (m,c)

5. Bob receives (m,c) and decrypts c using

Alice's public key Ae to obtain signature s

6. He computes the hash of m using SHA-1
and if this hash value is equal to s then the
message is authenticated.

Bob is sure that the message is correct and

that is does come from Alice. Furthermore
Alice cannot later deny sending the
message since only Alice has access to her
private key Ad which works in conjunction
with the public key Ae.

PGP Confidentiality
1. Alice wishes to send Bob a confidential
message m.
2. Alice generates a random session key k for a
symmetric cryptosystem.
3. Alice encrypts k using Bob’s public key Be to
k’ = pk.encryptBe(k)

4. Alice encrypts the message m with the
session key k to get ciphertext c

5. Alice sends Bob the values (k’,c)

6. Bob receives the values (k’,c) and decrypts
k’ using his private key Bd to obtain k

7. Bob uses the session key k to decrypt the
ciphertext c and recover the message m

Public and symmetric key cryptosystems

are combined in this way to provide
security for key exchange and then
efficiency for encryption. The session key
k is used only to encrypt message m and
is not stored for any length of time.

PGP Authenticaton and Confidentiality (at the
same time)

The schemes for authentication and

confidentiality can be combined so that
Alice can sign a confidential message
which is encrypted before transmission.
The steps required are as follows:
1. Alice generates a signature c for her
message m as in the Authentication

2. Alice generates a random session key k
and encrypts the message m and the
signature c using a symmetric
cryptosystem to obtain ciphertext C
4. She encrypts the session key k using Bob’s
public key
k’ = pk.encryptBe(k)

5. Alice sends Bob the values (k’,C)

6. Bob recieves k’ and C and decrypts k’
using his private key Bd to obtain the
session key k

7. Bob decrypts the ciphertext C using the

session key k to obtain m and c
(m,c) = sk.decryptk(C)

8. Bob now has the message m. In order to
authenticate it he uses Alice’s public key
Ae to decrypt the signature c and hashes
the message m using SHA-1.
If SHA(m) = pk.decryptAe(c)
Then the message is authenticated.

PGP Compression
PGP can also compress the message if
desired. The compression algorithm is ZIP
and the decompression algorithm is UNZIP.

1. The original message m is signed as before

to obtain

2. Now the original message m is
compressed to obtain

3. Alice generates a session key k and

encrypts the compressed message and
the signature using the session key
4. The session key is encrypted using Bob’s
public key as before.
5. Alice sends Bob the encrypted session key
and ciphertext C.
6. Bob decrypts the session key using his
private key and then uses the session key
to decrypt the ciphertext C to obtain M
and c
(M,c) = sk.decryptk(C)
7. Bob decompresses the message M to
obtain the original message m

8. Now Bob has the original message m and
signature c. He verifies the signature
using SHA-1 and Alice’s public key as

Note that the compression is applied

after signing (due to implementation of
ZIP) but before encryption (this
strengthens the security of the scheme
since the message has less redundancy
after compression)

PGP E-Mail Compatibility
Many electronic mail systems can only
transmit blocks of ASCII text. This can cause a
problem when sending encrypted data since
ciphertext blocks might not correspond to
ASCII characters which can be transmitted.
PGP overcomes this problem by using radix-64

Radix-64 conversion
Suppose the text to be encrypted has been
converted into binary using ASCII coding and
encrypted to give a ciphertext stream of
Radix-64 conversion maps arbitrary binary
into printable characters as follows:

Radix-64 conversion
1. The binary input is split into blocks of 24 bits
(3 bytes).
2. Each 24 block is then split into four sets each
of 6-bits.
3. Each 6-bit set will then have a value between
0 and 26-1 (=63).
4. This value is encoded into a printable

6 bit Character 6 bit Character 6 bit Character 6 bit Character
value encoding value encoding value encoding value encoding
0 A 16 Q 32 g 48 w
1 B 17 R 33 h 49 x
2 C 18 S 34 i 50 y
3 D 19 T 35 j 51 z
4 E 20 U 36 k 52 0
5 F 21 V 37 l 53 1
6 G 22 W 38 m 54 2
7 H 23 X 39 n 55 3
8 I 24 Y 40 o 56 4
9 J 25 Z 41 p 57 5
10 K 26 a 42 q 58 6
11 L 27 b 43 r 59 7
12 M 28 c 44 s 60 8
13 N 29 d 45 t 61 9
14 O 30 e 46 u 62 +
15 P 31 f 47 v 63 /
(pad) =

PGP Segmentation
Another constraint of e-mail is that there is
usually a maximum message length.
PGP automatically blocks an encrypted
message into segments of an appropriate
On receipt, the segments must be re-
assembled before the decryption process.

Key Issues
1. Key Generation
Recall that a new session key is required
each time a message is encrypted. How are
these keys generated?

PGP uses the timing of key strokes and key

patterns to generate random numbers.

2. Key Identifiers

PGP allows users to have more than

one public/private key pair
 To increase security
 To ease the key changeover period
So how does Bob know which set of
keys he should be using?

• In the case of encryption, (Alice uses Bob’s
public key) Alice can send Bob the public
key with the message since this is not
secret (in fact Alice only sends the 64 least
significant bits so that Bob can identify the
• In the case of digital signatures Alice uses
her private key and Bob uses Alice’s
corresponding public key. Alice cannot
send Bob her private key, but she can look
up the corresponding public key and send
the 64 least significant bits of that.
So a PGP message might consist of:

• Message component – the actual data to be

transmitted + a filename + a timestamp;
• Signature component – timestamp + hash of
message and timestamp + first part of
message (so user can check that they are
decrypting correctly) + Key ID of sender’s
public key
• Session Key component – session key + key ID
of recipient’s public key