Cryptography &

Network Security

UNIT-V
Course Objectives
The aim of this course is to introduce about information Security concepts to the students. This course
develops a basic understanding of goals, threats, attacks and mechanisms of security, the algorithms and their
design choices. The course also familiarizes students with a few mathematical concepts used in cryptology.
The course emphasizes to give a basic understanding of attacks in cryptosystems as well, how to shield
information from attacks. It also deals with message authentication, Digital signatures and Network security.

Course Objectives
 Understand security concepts, goals, threats and Security services, mechanisms to counter them. (L2)
 Comprehend and apply Classical Encryption Techniques. (L3)
 Understand various symmetric cryptographic techniques. (L2)
 Learn number theory related to Modern Cryptography. (L2)
 Learn different kinds of Message Authentication Techniques. (L2)
Course Outcomes
After completion of this course, the student will be able to:

 distinguish between Symmetric and Asymmetric cryptosystems (L4)

 analyze and implement Symmetric Classical Ciphers (L4)
 explain Hash functions and its algorithms (L2)
 apply Digital signature and its algorithms (L3)
 discuss public key distribution, Kerberos (L6)
 understand security at application and transportation layers. (L2)
Module-5 Syllabus
Internet Security:
• SSL and TLS
• S/MIME
Firewalls
IDPS
 After Completion of this unit the
student will be able to
Module – 5
Learning • explain transport-level security techniques (L2)

Outcomes
• discuss application-level security techniques
(L2)
• list network-level security techniques (L2)
Threats on Web
 Location of Security facilities in
the TCP/IP Protocol stack SMTP – Simple Mail Transfer Protocol
HTTP - Hyper Text Transfer Protocol
FTP - File Transfer Protocol
IP - Internet Protocol
TCP - Transmission Control Protocol
S/MIME- Secure/Multipurpose Internet Mail
Extension

The advantage of using IPsec General-purpose solution is to implement security just above Application-specific security
is that it is transparent to end TCP (Fig. b). The first example of this approach is the SSL services are embedded within
users and applications and and the follow-on Internet standard known as TLS. the particular application. Fig.
provides a general-purpose At this level, there are two implementation choices: (c) shows examples of this
solution. 1. For full generality, SSL or TLS could be provided as architecture.
IPsec includes a filtering part of the underlying protocol suite and therefore be The advantage of this approach
capability so that only selected transparent to applications. is that the service can be tailored
traffic need to bear the 2. TLS can be embedded in specific packages. For to the specific needs of a given
overhead of IPsec processing. example, virtually all browsers come equipped with application.
TLS, and most Web servers have implemented the
protocol
Secure Socket Layer (SSL)/Transport
Layer Security (TLS)
• One of the most widely used security services is Transport Layer Security (TSL)

• The current version is Version 1.2, defined in RFC 5246.

• TLS is an Internet standard that evolved from a commercial protocol known as Secure Sockets Layer (SSL).

• Although SSL implementations has been deprecated by IETF and is disabled by most corporations offering
TLS software.

• TLS is a general purpose service implemented as a set of protocols that rely on TCP.
TLS Concepts
• Connection: A connection is a transport (in the OSI model) that provides a suitable type of service. For
TLS, such connections are peer-to-peer relationships. The connections are temporary. Every connection
is associated with one session.

A connection state is defined by the following parameters:

• Server and client random: Byte sequences that are chosen by the server and client for each connection.

• Server write MAC secret: The secret key used in MAC operations on data sent by the server.

• Client write MAC secret: The symmetric key used in MAC operations on data sent by the client.

• Server write key: The symmetric encryption key for data encrypted by the server and decrypted by the client.
Connection
• Client write key: The symmetric encryption key for data encrypted by the client and decrypted by the server.

• Initialization vectors: When a block cipher in CBC mode is used, an initialization vector (IV) is maintained
for each key. This field is first initialized by the TLS Handshake Protocol. Thereafter, the final ciphertext
block from each record is preserved for use as the IV with the following record.

• Sequence numbers: Each party maintains separate sequence numbers for transmitted and received messages
for each connection. When a party sends or receives a “change cipher spec message,” the appropriate
sequence number is set to zero. Sequence numbers may not exceed 2 64 - 1
Session
A TLS session is an association between a client and a server. Sessions are created by the Handshake Protocol.
Sessions define a set of cryptographic security parameters, which can be shared among multiple connections.
Sessions are used to avoid the expensive negotiation of new security parameters for each connection.

There are a number of states associated with each session.

• Once a session is established, there is a current operating state for both read and write (i.e., receive and

send).

• In addition, during the Handshake Protocol, pending read and write states are created.

• Upon successful conclusion of the Handshake Protocol, the pending states become the current states.
Session
A session state is defined by the following parameters:

• Session identifier: An arbitrary byte sequence chosen by the server to identify an active or resumable

session state.

• Peer certificate: An X509.v3 certificate of the peer. This element of the state may be null

• Compression method: The algorithm used to compress data prior to encryption.

• Cipher spec: Specifies the bulk data encryption algorithm (such as null, AES, etc.) and a hash algorithm

(such as MD5 or SHA-1) used for MAC calculation. It also defines cryptographic attributes such as the

hash_size.

• Master secret: 48-byte secret shared between the client and server.

• Is resumable: A flag indicating whether the session can be used to initiate new connections .
TLS Architecture
• TLS is designed to make use of TCP to provide a
reliable end-to-end secure service. TLS is not a
single protocol but rather two layers of protocols.

• The Record Protocol provides basic security

services to various higher-layer protocols.

• The Hypertext Transfer Protocol (HTTP), provides

the transfer service for Web client/server interaction,
that can operate on top of TLS.
TLS Protocols

• Record Protocol
• Change cipher spec protocol
• Alert protocol
• Hand shake protocol
Record Protocol

The SSL Record Protocol provides two services for SSL connections:

• Confidentiality: The Handshake Protocol defines a shared secret key that is used
for symmetric encryption of SSL payloads.

• Message integrity: The Handshake Protocol also defines a shared secret key that
is used to form a message authentication code (MAC)
 TLS Record Protocol Operations

Figure indicates the overall operation of the SSL

Record Protocol.
1. Fragmentation. Each upper-layer message is
fragmented into blocks of 214 bytes (16,384
bytes) or less.
2. Compression is optionally applied.
3. Compute a message authentication code(MAC)
over the compressed data.
4. Encrypt the compressed message and MAC
using symmetric encryption.
5. Prepend a header, which includes version and
length fields.
Change Cipher Spec Protocol

• The Change Cipher Spec Protocol is one of the four TLS-specific protocols
that use the TLS Record Protocol, and it is the simplest.

• This protocol consists of a single message, which consists of a single byte

with the value 1.

• The only purpose of this message is to cause the pending state to be copied
into the current state, which updates the cipher suite to be used on this
connection.
Alert Protocol
• The Alert Protocol is used to convey TLS-related alerts to the peer entity. As with other
applications that use TLS, alert messages are compressed and encrypted, as specified by the
current state.

• Each message in this protocol consists of two bytes. The first byte takes the value warning(1) or
fatal(2) to convey the severity of the message. If the level is fatal, TLS immediately terminates the
connection. Other connections on the same session may continue, but no new connections on this
session may be established.
• The second byte contains a code that indicates the specific alert. An example of a fatal alert is an
incorrect MAC. An example of a nonfatal alert is a close_notify message, which notifies the recipient
that the sender will not send any more messages on this connection
Handshake Protocol
• The most complex part of TLS is the Handshake Protocol.

• This protocol allows the server and client to authenticate each other and to negotiate an
encryption and MAC algorithm and cryptographic keys to be used to protect data sent in an TLS
record.

• The Handshake Protocol is used before any application data is transmitted.

• The Protocol consists of a series of messages exchanged by client and server.

• Figure in the next slide shows the initial exchange needed to establish a logical connection
between client and server.

• The exchange can be viewed as having four phases.

Handsha
ke
protocol
Phases in Handshake Protocol

• Phase 1 is used to initiate a logical connection and to establish the security

capabilities that will be associated with it. The exchange is initiated by the client,
which sends a client_hello message with the following parameters:

• Version: The highest TLS version understood by the client.

• Random: A client-generated random structure, consisting of a 32-bit timestamp

and 28 bytes generated by a secure random number generator. These values are
used during key exchange to prevent replay attacks.
Phase 1
• Session ID: A variable-length session identifier. A nonzero value indicates that the client wishes to
update the parameters of an existing connection or create a new connection on this session. A zero
value indicates that the client wishes to establish a new connection on a new session.

• CipherSuite: This is a list that contains the combinations of cryptographic algorithms supported
by the client, in decreasing order of preference. Each element of the list (each cipher suite) defines
both a key exchange algorithm and a CipherSpec.

• Compression method: This is a list of the compression methods the client supports.
Phase 2

• Phase 2 depends on the underlying public-key encryption scheme that is used.

• In some cases, the server passes a certificate to the client, possibly additional
key information, and a request for a certificate from the client.

• The final message in phase 2, and one that is always required, is the
server_done message, which is sent by the server to indicate the end of the
server hello and associated messages. After sending this message, the server
will wait for a client response.
Phase 3

• In phase 3, upon receipt of the server_done message, the client should

verify that the server provided a valid certificate if required and check
that the server_ hello parameters are acceptable.

• If all is satisfactory, the client sends one or more messages back to the
server, depending on the underlying public-key scheme.
Phase 4
• Phase 4 completes the setting up of a secure connection.
• The client sends a change_cipher_spec message and copies the pending CipherSpec into the
current CipherSpec. (this message is not considered part of the Handshake Protocol but is sent
using the Change Cipher Spec Protocol.)
• The client then immediately sends the finished message under the new algorithms, keys, and
secrets.
• The finished message verifies that the key exchange and authentication processes were successful.
• In response to these two messages, the server sends its own change_cipher_spec message,
transfers the pending to the current CipherSpec, and sends its finished message.
• At this point, the handshake is complete and the client and server may begin to exchange application
layer data.
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.

• MIME is an extension to the old RFC 822 specification of an Internet mail format. RFC 822 defines a
simple header with To, From, Subject, and other fields that can be used to route an e-mail message through
the Internet and that provides basic information about the e-mail content.

• RFC 822 assumes a simple ASCII text format for the content.

• MIME provides a number of new header fields that define information about the body of the message,
including the format of the body and any encoding that is done to facilitate transfer.

• MIME defines a number of content formats, which standardize representations for the support of
multimedia e-mail. Examples include text, image, audio, and video.
S/MIME Services
• ad
Function Typical Algorithm Typical Action

Digital Signature RSA/SHA-256 A hash code of a message is created using SHA-256. This
message digest is encrypted using SHA-256 with the
sender’s private key and included with the message.

Message encryption AES-128 with CBC A message is encrypted using AES-128 with CBC with a
one-time session key generated by the sender. The session
key is encrypted using RSA with the recipient’s public key
and included with the message.

Compression Unspecified A message may be compressed for storage or transmission.

Email compatibility Radix-64 conversion To provide transparency for email applications, an

encrypted message may be converted to an ASCII string
using Radix-64 conversion.
Digital Signature
Authentication is provided with Digital Signature. Most commonly RSA with SHA-256 is used. The sequence is
as follows:

1. The sender creates a message.

2. SHA-256 is used to generate a 256-bit message digest of the message.

3. The message digest is encrypted with RSA using the sender’s private key, and the result is appended to the
message. The sender’s identity is also appended. This enables the receiver to retrieve the sender’s public key.

4. The receiver uses RSA with the sender’s public key to decrypt and recover the message digest.

5. The receiver generates a new message digest for the message and compares it with the decrypted hash code. If
the two match, the message is accepted as authentic.
Message Encryption
• Confidentiality is obtained through message encryption. Most commonly AES with a 128-bit key is used, with the cipher

block chaining (CBC) mode. The key itself is also encrypted with RSA which addresses the problem of key distribution.

• In S/MIME, each symmetric key, referred to as a content-encryption key, is used only once.

• A key is generated as a random number for each message. The content-encryption key is bound to the message and

transmitted with it.

• To protect the key, it is encrypted with the receiver’s public key. The sequence can be described as follows:

1. The sender generates a message and a random 128-bit number to be used as a content-encryption key for this message only.

2. The message is encrypted using the content-encryption key.

3. The content-encryption key is encrypted with RSA using the recipient’s public key and is attached to the message.

4. The receiver uses RSA with its private key to decrypt and recover the content-encryption key.

5. The content-encryption key is used to decrypt the message.

Email Compatibility
• When S/MIME is used, at least part of the block to be transmitted is encrypted.
• If only the signature service is used, then the message digest is encrypted (with the
sender’s private key).
• If the confidentiality service is used, the message plus signature (if present) are
encrypted (with a one-time symmetric key).
• Thus, part or all of the resulting block consists of a stream of arbitrary 8-bit octets.
• Many electronic mail systems only permit the use of blocks consisting of ASCII text.
• To accommodate this restriction, S/MIME provides the service of converting the raw
8-bit binary stream to a stream of printable ASCII characters, a process referred to as
7-bit encoding.
Email Compatibility
• The scheme typically used for this purpose is Base64 conversion.
• Each group of three octets of binary data is mapped into four ASCII characters.
• The Base64 algorithm, blindly converts the input stream to Base64 format regardless of content, even
if the input happens to be ASCII text.
• Thus, if a message is signed but not encrypted and the conversion is applied to the entire block, the
output will be unreadable to the casual observer, which provides a certain level of confidentiality.
• MIME handles any entity in any environment without changing it.
• For example, a trusted gateway might remove the encryption, but not the signature, of a message, and
then forward the signed message on to the end recipient so that they can verify the signatures directly.
• If the transport that is internal to the site is not 8-bit clean, like on a WAN with a single mail gateway,
verifying the signature will not be possible unless the original MIME entity was only 7-bit data
Compression
• S/MIME also offers the ability to compress a message.
• This has the benefit of saving space both for email transmission and for file storage.
• Compression can be applied in any order with respect to the signing and message
encryption operations.
• RFC 5751 provides the following guidelines:
• Compression of binary encoded encrypted data is discouraged, since it will not yield
significant compression.
• Base64 encrypted data could very well benefit.
• If a lossy compression algorithm is used with signing, you will need to compress first,
then sign
Cryptographic algorithms used in S/MIME
• Table summarizes the cryptographic algorithms used in
S/MIME. 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.
Cont..
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.

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.

5. 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
S/MIME message content types
• S/MIME is defined as a set of additional MIME content types (Table in next slide) and provides the
ability to sign and/or encrypt e-mail messages. These content-types support four new functions:
• Enveloped data: This function consists of encrypted content of any type and encrypted-content’s 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.
S/MIME Content Types
Typical S/MIME Process for Creating
and S/MIME Message
Signed and Clear-Signed Data
• The default algorithms used for signing S/MIME messages are
1. Digital Signature Standard (DSS)
2. Secure Hash Algorithm, revision 1 (SHA-1).

• The process works as follows:

• Take the message that you want to send and map it into a fixed-length code of 160 bits, using SHA-1.
• The 160-bit message digest is unique for this message.
• It would be impossible to alter or substitute the original message with another, and still come up with the same
message digest.
• S/ MIME encrypts the digest using DSS and the sender’s private DSS key. This results in attaching digital
signature, to the message.
• The receiver who gets this message can re-compute the message digest and then decrypt the signature using DSS
and the sender’s public DSS key.
• If the message digest in the signature matches the message digest that was calculated, then the signature is valid.
• Since this operation only involves encrypting and decrypting a 160-bit block, it takes up little time.
Cont…
• As an alternative, the RSA public-key encryption algorithm can be used with either the SHA-1 or
the MD5 message digest algorithm for forming signatures.

• The signature is a binary string, and sending it in that form through the Internet e-mail system
could result in unintended alteration of the contents, because some e-mail software will attempt to
interpret the message content looking for control characters such as line feeds.

• To protect the data, either the signature alone or the signature plus the message are mapped into
printable ASCII characters using a radix-64 or base64 mapping.
Enveloped Data
• The default algorithms used for encrypting S/MIME messages are the triple DES (3DES) and a public-key scheme known as ElGamal,

which is based on the Diffie-Hellman public-key exchange algorithm.

• S/MIME generates a pseudorandom secret key; this is used to encrypt the message using 3DES or some other conventional encryption

scheme.

• In any conventional encryption application, the problem of key distribution must be addressed. In S/ MIME, each conventional key is

used only once.

• That is, a new pseudorandom key is generated for each new message encryption. This session key is bound to the message and

transmitted with it.

• The secret key is used as input to the public-key encryption algorithm, ElGamal, which encrypts the key with the recipient’s public

ElGamal key.

• On the receiving end, S/MIME uses the receiver’s private ElGamal key to recover the secret key and then uses the secret key and 3DES

to recover the plaintext message. If encryption is used alone, radix-64 is used to convert the ciphertext to ASCII format.
Enhanced Security Services
Four enhanced security services for S/MIME are:

• Signed receipts: A signed receipt may be requested in a SignedData object. Returning a signed receipt provides proof of delivery to the

message originator 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.

• Security labels: A security label may be included in the authenticated attributes of a SignedData 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 or role based, describing which kind of people can

see the information (e.g., patient.

• 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.

• Signing certificates: This service is used to securely bind a sender’s certificate to their signature through a signing certificate attribute.