Cryptography &

Network Security

Cryptographic Hash Functions, MAC and Digital Signatures, Key

Distribution
UNIT-IV
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-4 Syllabus
Cryptographic Hash Functions:
• Applications of hash Functions
• Secure Hash Algorithm (SHA) SHA-512
• SHA

MAC and Digital Signatures:

• Message Authentication Requirements
• Message Authentication Functions
• Requirements for Message Authentication Codes
• HMAC, DAA and CMAC.
• Authenticated Encryption: CCM, GCM
• Digital signatures : Digital Signature Standard (DSS)
Key distribution
 After Completion of this unit the
student will be able to
 explain and implement simple hash
Module – 4 functions (L2)
Learning  discuss message authentication
techniques (L2)
Outcomes  explain Digital Signature Standard
(DSS) (L2)
 Explain Key distribution (L2)
Introductio
• A hash function H accepts a variable-length block of data
M as input and produces a fixed-size hash value.
h = H(M)
n • A change to any bit or bits in M results, with high
probability, in a change to the hash code.
• The kind of hash function needed for security applications
is referred to as a cryptographic hash function.
• A cryptographic hash function is an algorithm for which it
is computationally infeasible to find either
• (a) a data object that maps to a pre-specified hash
result (the one-way property) or
• (b) two data objects that map to the same hash result
(the collision-free property)
 Hash Functions
• General Operation of Cryptographic Hash
Function:
• The input is padded out to an integer multiple
of some fixed length (e.g., 1024 bits)
• The padding includes the value of the length
of the original message in bits.
• The length field is a security measure to
increase the difficulty for an attacker to
produce an alternative message with the same
hash value.
Applications of Cryptographic Hash
Functions
• Used in a wide variety of security applications and Internet protocols.
• MESSAGE AUTHENTICATION:
• Message authentication is concerned with:
• protecting the integrity of a message
• validating identity of originator
• non-repudiation of origin (dispute resolution)
• Considers a set of security requirements
• Three alternative functions used:
• message encryption
• message authentication code (MAC)
• hash function
Applications of Cryptographic
Hash Functions
• Different ways in which a hash code can be used to provide
message authentication:

1. The message plus concatenated hash code is encrypted

using symmetric encryption.
Applications of Cryptographic
Hash Functions
2. Only the hash code is encrypted, using symmetric encryption.

3. Source A computes the hash value over the concatenation of M and S

and appends the resulting hash value to M. (A and B share a common
secret value S)
Applications of Cryptographic Hash Functions

4. Confidentiality can be added to the approach of method (c) by encrypting the entire message
plus the hash code.

• When confidentiality is not required, method (2) has an advantage over methods (1) and (4),
which encrypts the entire message, in that less computation is required.
Applications of Cryptographic Hash Functions
• Message Authentication is achieved using a message authentication code (MAC), also known as
a keyed hash function.
• MACs are used between two parties that share a secret key to authenticate information
exchanged between those parties.
• A MAC function takes as input a secret key and a data block and produces a hash value, referred
to as the MAC.
• If the integrity of the message needs to be checked, the MAC function can be applied to the
message and the result compared with the stored MAC value.
• An attacker who alters the message will be unable to alter the MAC value without knowledge of
the secret key.
Applications of Cryptographic
Hash Functions
DIGITAL SIGNATURES
• The operation of the digital signature is similar to the MAC.
• In digital signature, the hash value of a message is encrypted with a user’s
private key.
• Anyone who knows the user’s public key can verify the integrity of the
message that is associated with the digital signature.
• An attacker who wishes to alter the message would need to know the user’s
private key.
Applications of Cryptographic
Hash Functions
• Ways in which a hash code is used to provide a digital signature:
• The hash code is encrypted, using public-key encryption with the sender’s private
key, this provides authentication.

• If confidentiality as well as a digital signature is desired, then the message plus the
private-key-encrypted hash code can be encrypted using a symmetric secret key.
Applications of Cryptographic Hash
Functions
OTHER APPLICATIONS
• Hash functions are commonly used to create a one-way password file.
• Hash functions can be used for intrusion detection and virus detection.
• A cryptographic hash function can be used to construct a pseudorandom
function (PRF) or a pseudorandom number generator (PRNG).
• A common application for a hash-based PRF is for the generation of
symmetric keys.
Secure Hash Algorithm (SHA)
• Most widely used hash function has been the Secure Hash Algorithm (SHA).
• SHA was developed by the National Institute of Standards and Technology
(NIST) and published as a federal information processing standard (FIPS 180) in
1993.
• SHA-0 was revised in 1995 as SHA-1.
• SHA is based on design of MD4 with key differences.
• SHA-1 produces a hash value of 160 bits.
Secure Hash Algorithm (cont.…)
• Revised Secure Hash Standard
• NIST issued a revision FIPS 180-2 in 2002.
• Defines 3 additional versions of SHA – SHA-256, SHA-384, SHA-512.
• Designed for compatibility with increased security provided by the AES cipher.
• Structure & detail is like SHA-1
• hence analysis should be similar
• but security levels are rather higher
Comparison of SHA parameters
 SHA-512

• SHA-512 Logic
• Takes as input a message with a
maximum length of less than 2128
bits
• Produces as output a 512-bit message
digest.
• The input is processed in 1024-bit
blocks.

Message Digest Generation Using SHA-512

SHA-512
• The processing consists of the following steps:
• STEP 1: Append padding bits- The message is padded so that its length is congruent to 896 modulo
1024 [length ≡ 896(mod 1024)].
• The number of padding bits is in the range of 1 to 1024.

• The padding consists of a single 1 bit followed by the necessary number of 0 bits.

• STEP 2: Append length- A block of 128 bits is appended to the message.

• STEP 3: Initialize hash buffer- A 512-bit buffer is used to hold intermediate and results of the hash
function.
• The buffer can be represented as eight 64-bit registers (a, b, c, d, e, f, g, h).
 SHA-512
• STEP 4: Process message in 1024-bit (128-word)
blocks- The heart of the algorithm is a module that
consists of 80 rounds.
• Each round takes as input the 512-bit buffer value, abcdefgh,
and updates the contents of the buffer.

• The output of the eightieth round is added to the input to the

first round to produce Hi.

• STEP 5: Output- After all 1024-bit blocks have been

processed, the output from the Nth stage is the 512-bit
message digest.
SHA-512
• We can summarize the behavior of SHA-512 as follows:
• H0 = IV
• Hi = SUM64(Hi-1, abcdefghi)
• MD = HN
• Where
• IV = initial value of the abcdefgh buffer, defined in step 3
• abcdefghi = the output of the last round of processing of the i th message block
• N = the number of blocks in the message (including padding and length fields)
• SUM64 = addition modulo 264 performed separately on each word of the pair of inputs
• MD = final message digest value
SHA-512
• SHA-512 Round Function
• logic in each of the 80 steps of the processing of one 512-bit block.
• Each round is defined by the following set of equations:
SHA-512
• Two observations about the round
function:
• Six of the eight words of the output
of the round function involve simply
permutation (b, c, d, f, g, h) by
means of rotation.
• Only two of the output words (a, e)
Elementary SHA-512 Operation (single round)
are generated by substitution.
SHA-512
• Creation of 80-word Input Sequence for SHA-512 Processing of Single
Block
SHA-512
• How the 64-bit word values are derived from the 1024-bit message?
• The first 16 values of Wt are taken directly from the 16 words of the current
block. The remaining values are defined as:
SHA-512
• In the first 16 steps of processing, the value of is equal to the corresponding
word in the message block.
• For the remaining 64 steps,
• the value of Wt consists of the circular left shift by one bit of the XOR of four of the
preceding values of Wt, with two of those values subjected to shift and rotate operations.

• Weakness in SHA-512:
• The difficulty of coming up with two messages having the same message digest is on
the order of 2256 operations.
• While the difficulty of finding a message with a given digest is on the order of 2512
operations.
Message Authentication
Codes
Message Authentication Codes (MAC)
• A message authentication code (MAC) is an algorithm that requires the use of a secret key.

• A MAC takes a variable-length message and a secret key as input and produces an authentication code.

• A recipient in possession of the secret key can generate an authentication code to verify the integrity of
the message.

• One means of forming a MAC is to combine a cryptographic hash function in some fashion with a
secret key.

• Another approach to constructing a MAC is to use a symmetric block cipher in such a way that it
produces a fixed-length output for a variable length input.
 • In the context of communications across a network,
following attacks can be identified:
• Disclosure
Message • Traffic analysis
• Masquerade
Authentication • Content modification
Requirements • Sequence modification
• Timing modification
• Source repudiation
• Destination repudiation
Message Authentication Functions

• Types of functions that may be used to produce an authentication are

grouped into three classes:
• Hash function: A function that maps a message of any length into a fixed length hash value, which
serves as the authenticator

• Message encryption: The ciphertext of the entire message serves as its authenticator

• Message authentication code (MAC): A function of the message and a secret key that produces a
fixed-length value that serves as the authenticator
Message Encryption
• Message encryption by itself can provide a measure of authentication,
analysis differs for symmetric and public-key encryption schemes .
• SYMMETRIC ENCRYPTION
• receiver knows sender must have created it
• since only sender and receiver know the key used
• the content cannot have been altered if message has suitable structure, redundancy or a suitable
checksum to detect any changes
Message Encryption (cont.…)
PUBLIC-KEY ENCRYPTION

• The straightforward use of public-key

encryption provides confidentiality but not
authentication. The source A uses the public
key of the destination B to encrypt M
• To provide authentication, A uses its private
key to encrypt the message, and B uses A’s
public key to decrypt
• To provide both confidentiality and
authentication, A can encrypt first using its
private key, which provides the digital
signature, and then using B’s public key,
which provides confidentiality

Basic Uses of Message Encryption

Message Authentication Code
• Involves the use of a secret key to generate a small fixed-size block of data, known as a
cryptographic checksum or MAC, that is appended to the message
• This technique assumes that two communicating parties, say A and B, share a common secret key
• When A has a message to send to B, it calculates the MAC as a function of the message and the
key:
MAC = MAC(K, M)
where
M = input message
C = MAC function
K = shared secret key
MAC = message authentication code
Message Authentication Code (cont.…)
• MAC provides authentication
• We can also use encryption for secrecy
• generally, separate keys are used for each

• MAC can be computed either before or after encryption

• It’s generally better if computed before

• why use a MAC?

• sometimes only authentication is needed

• sometimes need authentication to persist longer than the encryption (e.g. archival use)

• note that a MAC is not a digital signature

• Does NOT provide non-repudiation
Basic Uses of Message Authentication code
(MAC)
 • a MAC is a cryptographic checksum

MAC 
MAC = CK(M)
condenses a variable-length message M using a

Properties secret key K to a fixed-sized authenticator

• is a many-to-one function

potentially many messages have same MAC
but finding these needs to be very difficult
 • taking into account the types of attacks
• need the MAC to satisfy the following:
Requirements 1. knowing a message and MAC, is infeasible to

find another message with same MAC

for MACs 2. MACs should be uniformly distributed

3. MAC should depend equally on all bits of the

message
 • attacks on MACs are grouped into two categories:
• brute-force attacks
• cryptanalysis
• Brute-force attacks exploiting

Security of •
m
strong collision resistance hash have cost 2 /2

MACs
• 128-bit hash looks vulnerable, 160-bits
better
• MACs with known message-MAC pairs

• can either attack key space or MAC

• at least 128-bit MAC is needed for security
• Cryptanalytic attacks exploit structure
• like block ciphers want brute-force attacks to

be the best alternative

Keyed • a MAC based on a hash function

because hash functions are generally faster

Hash 
crypto hash function code is widely available
• hash includes a key along with message
Functions • original proposal:
KeyedHash = Hash(Key|Message)
as MACs 
some weaknesses were found with this
• eventually led to development of HMAC
HMAC
HMAC Design Objectives

• RFC 2104 lists the following design objectives for HMAC:

• To use, without modifications, available hash functions
• To allow for easy replaceability of the embedded hash function in case faster or more secure
hash functions are found or required
• To preserve the original performance of the hash function without incurring a significant
degradation
• To use and handle keys in a simple way
• To have a well understood cryptographic analysis of the strength of the authentication
mechanism.
HMAC Algorithm
• H = embedded hash function (e.g., MD5, SHA-1, RIPEMD-160)
• IV = initial value input to hash function
• M = message input to HMAC (including the padding specified in the embedded hash function)
• Yi = ith block of M, 0 ≤ i ≤ (L – 1)
• L = number of blocks in M
• b = number of bits in a block
• n = length of hash code produced by embedded hash function
• K = secret key; recommended length is ≥ n; if key length is greater than b, the key is input to the hash function to
produce an n-bit key
• K+ = K padded with zeros on the left so that the result is b bits in length
• ipad = 00110110 (36 in hexadecimal) repeated b/8 times
• opad = 01011100 (5C in hexadecimal) repeated b/8 times
HMAC
Overview

•HMAC can be expressed as:

•HMAC(K, M) = H[(K+ ⊕
opad) || H[(K+ ⊕ ipad) ||
M]]
HMAC Security

• proved security of HMAC relates to that of the underlying hash

algorithm
• attacking HMAC requires either:
• brute force attack on key used
• birthday attack (but since keyed would need to observe a very large number of messages)

• choose hash function used based on speed verses security constraints

MAC’s BASED ON
BLOCK CIPHERS: DAA
and CMAC
Data
Authentication
Algorithm

• The Data Authentication

Algorithm (DAA), based on DES,
has been one of the most widely
used MACs

• The algorithm can be defined as

using the cipher block chaining
(CBC) mode of operation of DES
with an initialization vector of zero
Data Authentication Algorithm (cont.…)
• The data to be authenticated are grouped into contiguous 64-bit blocks
• The final block is padded on the right with zeroes to form a full 64-bit block
• Using the DES encryption algorithm E and a secret key , a data authentication code (DAC) is
calculated as follows:
O1 = E(K, D)
O2 = E(K, [D2 ⊕ O1])
O3 = E(K, [D3 ⊕ O2])
.
.
.
ON = E(K, [DN ⊕ ON-1])
The DAC consists of either the entire block or the leftmost bits of the block
Cipher-Based Message Authentication
Code (CMAC)
• Adopted by NIST
• mode of operation for use with AES and triple DES
• specified in NIST Special Publication 800-38B
• Operation of CMAC when the message is an integer multiple of the cipher block
length b:
• For AES, b=128 and for triple DES b=64.
• The message is divided into blocks
• The algorithm makes use of a k-bit encryption key K and an n-bit constant K 1.
• For AES, the key size is 128, 192, or 256 bits; for triple DES, the key size is 112 or 168 bits.
Cipher-Based Message Authentication Code
(CMAC)
Digital Signatures
Introduction
• A digital signature is an authentication mechanism that enables the
creator of a message to attach a code that acts as a signature.
• The signature is formed by taking the hash of the message and
encrypting the message with the creator’s private key. The signature
guarantees the source and integrity of the message.
• The digital signature standard (DSS) is an NIST standard that uses the
secure hash algorithm (SHA).
• In situations where there is no complete trust between sender and the
receiver an additional feature other than authentication is required.
Digital Signature provides solution to such requirement.
Generic
Model of
Digital
Signature
Process
Digital Signatures
Properties

• It must verify the author and the date and time of the signature.

• It must authenticate the contents at the time of the signature.

• It must be verifiable by third parties, to resolve disputes.

Thus, the digital signature function includes the authentication function also.
Attacks and Forgeries
Note: A denotes the user whose signature method is being attacked, and C denotes the attacker.
• Key-only attack: C only knows A’s public key.
• Known message attack: C is given access to a set of messages and their signatures.
• Generic chosen message attack: C chooses a list of messages before attempting to breaks A’s
signature scheme, independent of A’s public key. C then obtains from A valid signatures for the
chosen messages. The attack is generic, because it does not depend on A’s public key; the same
attack is used against everyone.
• Directed chosen message attack: Similar to the generic attack, except that the list of messages to
be signed is chosen after C knows A’s public key but before any signatures are seen.
• Adaptive chosen message attack: C is allowed to use A as an “oracle.” This means that C may
request from A signatures of messages that depend on previously obtained message-signature
pairs.
success at breaking a signature scheme
with a non-negligible probability
C can do any of the following :

• Total break: C determines A’s private key.

• Universal forgery: C finds an efficient signing algorithm that provides an equivalent way
of constructing signatures on arbitrary messages.

• Selective forgery: C forges a signature for a particular message chosen by C.

• Existential forgery: C forges a signature for at least one message. C has no control over
the message. Consequently, this forgery may only be a minor nuisance to A
Simplified
Depiction of
Essential
Elements of
Digital
Signature
Process
Digital Signature Requirements
• The signature must be a bit pattern that depends on the message being signed.
• The signature must use some information only known to the sender to prevent
both forgery and denial.
• It must be relatively easy to produce the digital signature.
• It must be relatively easy to recognize and verify the digital signature.
• It must be computationally infeasible to forge a digital signature, either by
constructing a new message for an existing digital signature or by constructing a
fraudulent digital signature for a given message.
• It must be practical to retain a copy of the digital signature in storage.
Digital Signature Standard
• This Standard specifies algorithms for applications requiring a digital signature, rather
than a written signature.
• A digital signature is represented in a computer as a string of bits.
• A digital signature is computed using a set of rules and a set of parameters that allow the
identity of the signatory and the integrity of the data to be verified.
• Digital signatures may be generated on both stored and transmitted data.
• Signature generation uses a private key to generate a digital signature; signature
verification uses a public key that corresponds to, but is not the same as, the private key.
Each signatory possesses a private and public key pair.
• Public keys may be known by the public; private keys are kept secret. Anyone can verify
the signature by employing the signatory’s public key.
Digital Signature Standard
• Only the user that possesses the private key can perform signature generation. A hash function is
used in the signature generation process to obtain a condensed version of the data to be signed; the
condensed version of the data is often called a message digest.
• The message digest is input to the digital signature algorithm to generate the digital signature.
• The hash functions to be used are specified in the Secure Hash Standard (SHS), FIPS 180. FIPS
approved digital signature algorithms shall be used with an appropriate hash function that is
specified in the SHS.
• The digital signature is provided to the intended verifier along with the signed data.
• The verifying entity verifies the signature by using the claimed signatory’s public key and the
same hash function that was used to generate the signature.
• Similar procedures may be used to generate and verify signatures for both stored and transmitted
data.
DSS Applications
• A digital signature algorithm is intended for use in electronic mail, electronic funds transfer,
electronic data interchange, software distribution, data storage, and other applications that require
data integrity assurance and data origin authentication.
• This Standard shall be used in designing and implementing public key-based signature systems.
The adoption and use of this Standard is available to private and commercial organizations.
• A digital signature algorithm may be implemented in software, firmware, hardware or in
combination.
• The intent of this Standard to specify general security requirements for generating digital
signatures.
Note: conformance to this Standard does not assure that a particular implementation is secure. It is
the responsibility of an implementer to ensure that any module that implements a digital signature
capability is designed and built in a secure manner
Digital Signature Standard (DSS)
• This Standard defines methods for digital signature generation that can be used for the protection of binary data
(commonly called a message), and for the verification and validation of those digital signatures.
• Three techniques are approved.
1) The Digital Signature Algorithm (DSA) is specified in this Standard. The specification includes criteria
for the generation of domain parameters, for the generation of public and private key pairs, and for the
generation and verification of digital signatures.
2) The RSA digital signature algorithm is specified in American National Standard (ANS) X9.31 and Public
Key Cryptography Standard (PKCS) #1. FIPS 186-4 approves the use of implementations of either or both
of these standards and specifies additional requirements.
3) The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified in ANS X9.62. FIPS 186-4
approves the use of ECDSA and specifies additional requirements. Recommended elliptic curves for
Federal Government use are provided herein. This Standard includes requirements for obtaining the
assurances necessary for valid digital signatures. Methods for obtaining these assurances are provided in
NIST Special Publication (SP) 800-89, Recommendation for Obtaining Assurances for Digital Signature
Applications.
Digital Signature Standard (DSS)

US Govt approved designed by NIST & published as FIPS- revised in 1993,

signature scheme NSA in early 90’s 186 in 1991 1996 & then 2000

FIPS 186-2 (2000) DSA is digital

uses the SHA hash DSS is the standard, includes alternative signature only unlike
algorithm DSA is the algorithm RSA & elliptic curve RSA which is a
signature variants public-key technique
Two
Approache
s to Digital
Signatures
 • creates a 320 bit signature
• with 512-1024 bit security
The Digital • smaller and faster than RSA

Signature • a digital signature scheme only

• security depends on difficulty of computing

Algorithm discrete logarithms

• variant of ElGamal & Schnorr schemes
Digital Signature Creation and Verification
DSS
Signing
and
Verifying
DSS Signing and Verifying
Key management and
distribution
• Strength of Cryptographic system rests with Key Distribution Mechanism.

• Key Distribution means the function that exchange a key between two Parties in encrypted form.

• Key distribution often involves the use of master keys, which are in frequently used and are long
lasting, and session keys, which are generated and distributed for temporary use between two
parties.

• Public-key encryption schemes are secure only if the authenticity of the public key is assured.
Key Distribution
• Session key: When two end systems (hosts, terminals, etc.) wish to communicate, they establish a logical
connection (e.g., virtual circuit). For the duration of that logical connection, all user data are encrypted with a
one-time session key. At the end of the session, or connection, the session key is destroyed.

• Permanent key: A permanent key is a key used between entities for the purpose of distributing session keys.
The configuration consists of the following elements:
• Key distribution center: The key distribution center (KDC) determines which systems are allowed to communicate
with each other. When permission is granted for two systems to establish a connection, the KDC provides a one-time
session key for that connection.

• Security service module (SSM): This module, which may consist of functionality at one protocol layer, performs end-
to-end encryption and obtains session keys on behalf of users.
 Key management and
distribution
• Symmetric schemes require both parties to share a common secret key.
• Symmetric key distribution using symmetric encryption
• Symmetric key distribution using Asymmetric encryption

• Public key schemes require parties to acquire valid public keys

• Distribution of public keys
• Announcement
• Directory
• Authority
• Certificates (X.509 certificates)
 Key
Distribution
Scenario
• A has a master key, Ka, known only to itself and the KDC; similarly, B shares the master
key Kb with the KDC.
• The following steps occur.
1. A issues a request to the KDC for a session key to protect a logical connection to B. The
message includes the identity of A and B and a unique identifier, N1, for this transaction,
2. The KDC responds with a message encrypted using Ka. Thus, A is the only one who can
successfully read the message, and A knows that it originated at the KDC.
The message includes two items intended for A:
• The one-time session key, Ks, to be used for the session
• The original request message, including the nonce, to enable A to match this response with
the appropriate request Thus, A can verify that its original request was not altered before
reception by the KDC and, because of the nonce, that this is not a replay of some previous
request.
• In addition, the message includes two items intended for B:
• The one-time session key, Ks, to be used for the session
• An identifier of A (e.g., its network address), IDA These last two items are encrypted with Kb
(the master key that the KDC shares with B). They are to be sent to B to establish the
connection and prove A’s identity.
• A stores the session key for use in the upcoming session and forwards to B the information
that originated at the KDC for B
Automatic
key
distribution
• The automated key distribution

approach provides the flexibility

and dynamic characteristics

needed to allow a number of

terminal users to access a

number of hosts and for the hosts

to exchange data with each other.

Decentralize
d key
distribution
• A session key may be established with the following
sequence of steps :

• A issues a request to B for a session key and includes

a nonce, N1.

• B responds with a message that is encrypted using the

shared master key. The response includes the session
key selected by B, an identifier of B, the value f(N1),
and another nonce, N2.

• Using the new session key, A returns f(N2) to B.

• Each node must maintain at most (n - 1) master keys,

as many session keys as required may be generated
and used.

• The messages transferred using the master key are

short and cryptanalysis is difficult.
Symmetric Key distribution using
Asymmetric Encryption
One of the most important uses of a public-
key cryptosystem is to encrypt secret keys for
distribution
Simple
use of
Public key
encryptio If A wishes to communicate with B, the following procedure is employed:

n to • A generates a public/private key pair {PU a, PRa} and transmits a message to B

consisting of PUa and an identifier of A, IDA.

establish
• B generates a secret key, Ks, and transmits it to A, which is encrypted with A’s public
key.
• A computes D(PRa, E(PUa, Ks)) to recover the secret key. Because only A can decrypt

a session the message, only A and B will know the identity of K s.

• A discards PUa and PRa and B discards PUa.

key A and B can now securely communicate using conventional encryption and the session key
Ks.
Man in the middle attack
Secret Key distribution with
confidentiality and Authentication
Distribution of public keys

• Several techniques have been proposed for the distribution of public

keys. Virtually all these proposals can be grouped into the following
general schemes:
• Public announcement

• Publicly available directory

• Public-key authority

• Public-key certificates
 Public Announcement
 By using public-key algorithm, such as RSA, any par-
ticipant can send his or her public key to any other participant or broadcast the
key to the community at large network.
 The major weakness in public announcement is anyone can forge such a public
announcement.
 Publicly Available Directory
• A greater degree of security can be achieved by maintaining publicly available
dynamic directory of public keys.

• Maintenance and distribution of the public directory would have to

be the responsibility of some trusted entity or organization.

• The authority maintains a directory with a {name, public key} entry for each participant.

• Each participant registers a public key with the directory authority. Registration would
have to be in person or by some form of secure authenticated communication.

• A participant may replace the existing key with a new one at any time, either because of
the desire to replace a public key that has already been used for a large
amount of data, or because the corresponding has been compromised in some way.

• Participants could also access the directory electronically. For this purpose, secure,
authenticated communication from the authority to the participant is mandatory.
 Public-Key Authority
• Stronger security for public-key distribution can be achieved by providing tighter
control over the distribution of public keys from the directory.
• The scenario assumes that a central authority maintains a dynamic directory of public
keys of all participants.
• Each participant reliably knows a public key for the authority, with only the authority
knowing the corresponding private key. The following steps occur:
• A sends a timestamped message to the public-key authority containing a request for
the current public key of B.
• The authority responds with a message that is encrypted using the authority’s private
key, PRauth. Thus, A is able to decrypt the message using the authority’s public key.
Therefore, A is assured that the message originated with the authority. The message
includes the following:
• B’s public key, PUb, which A can use to encrypt messages destined for B
• The original request used to enable A to match this response with the
corresponding earlier request and to verify that the original request was not
altered before reception by the authority
• The original timestamp given so A can determine that this is not an old message
from the authority containing a key other than B’s current public key
 Public Key Distribution Scenario
3. A stores B’s public key and also uses it to encrypt a message to B containing an identifier of A
(IDA) and a nonce (N1), which is used to identify this transaction uniquely.

4 & 5. B retrieves A’s public key from the authority in the same manner as A retrieved B’s
public key. At this point, public keys have been securely delivered to A and B, and they may
begin their protected exchange. However, two additional steps are desirable:

6. B sends a message to A encrypted with PU a and containing A’s nonce (N1) as well as a new
nonce generated by B (N2). Because only B could have decrypted message (3), the presence of
N1 in message (6) assures A that the correspondent is B.

7. A returns N2, which is encrypted using B’s public key, to assure B that its correspondent is A.

Thus, a total of seven messages are required. The initial five messages need be used
only infrequently because both A and B can save the other’s public key for future use—a
technique known as caching. Periodically, a user should request fresh copies of the public keys
of its correspondents to ensure currency.
 Key Distribution Issues
 hierarchies of KDC’s required for large networks, but must trust each
other
 session key lifetimes should be limited for greater security
 use of automatic key distribution on behalf of users, but must trust
system
 use of decentralized key distribution
 controlling key usage
Public key Certificates
• The public-key authority could be somewhat of a bottleneck in the system, for a user must appeal to the authority for a
public key for every other user that it wishes to contact.
• As before, the directory of names and public keys maintained by the authority is vulnerable to tampering.

• An alternative approach, first suggested by Kohnfelder, is to use certificates that can be used by participants to exchange
keys without contacting a public-key authority, in a way that is as reliable as if the keys were obtained directly from a
public-key authority.
• The certificate consists of :
• a public key
• an identifier of the key owner
• and the whole block signed by a trusted third party.
• The third party is a certificate authority, such as a government agency or a financial institution, that is trusted by the user community.

• A user can present his or her public key to the authority in a secure manner and obtain a certificate.

• The user can then publish the certificate after obtaining it.
Public key Certificates
• The requirements for this scheme are:
1. Any participant can read a certificate to determine the name and public key of the certificate’s owner.

2. Any participant can verify that the certificate originated from the certificate authority and is not counterfeit.

3. Only the certificate authority can create and update certificates

4. Any participant can verify the time validity of the certificate

• Each participant applies to the certificate authority, supplying a public key and requesting a certificate. Application must be in person or by
some form of secure authenticated communication. For participant A, the authority provides a certificate of the form
CA = E(PRauth, [T || IDA || PUa])

• where PRauth is the private key used by the authority and T is a timestamp. A may then pass this certificate on to any other participant, who
reads and verifies the certificate as follows:
D(PUauth, CA) = D(PUauth, E(PRauth, [T || IDA || PUa])) = (T || IDA || PUa)

• The recipient uses the authority’s public key, PU auth, to decrypt the certificate.
Obtaining public key certificates
from CA
Public-key certificate
• Because the certificate is readable only using the authority’s public key, this verifies that the certificate came from the certificate
authority.
• The elements IDA and PUa provide the recipient with the name and public key of the certificate’s holder.
• The timestamp T validates the currency of the certificate.
• The timestamp counters the following scenario.
• A’s private key is learned by an adversary.
• A generates a new private/public key pair and applies to the certificate authority for a new certificate.
• Meanwhile, the adversary replays the old certificate to B.
• If B then encrypts messages using the compromised old public key, the adversary can read those messages.
• In this context, the compromise of a private key is comparable to the loss of a credit card.
• The owner cancels the credit card number but is at risk until all possible communicants are aware that the old credit card is
obsolete.
• Thus, the timestamp serves as something like an expiration date.
• If a certificate is sufficiently old, it is assumed to be expired.
• One scheme has become universally accepted for formatting public-key certificates: the X.509 standard. X.509 certificates are
used in most network security applications, including IP security, transport layer security (TLS), and S/MIME.
 X.509 Authentication Service
• part of CCITT X.500 directory service standards
• distributed servers maintain users information database
• defines framework for authentication services
• directory may store public-key certificates
• with public key of user signed by certification authority
• also defines authentication protocols
• uses public-key crypto & digital signatures. It does not dictate the use of a specific digital
signature algorithm nor a specific hash function
• X.509 certificates are widely used and have 3 versions
• X.509 was initially issued in 1988. The standard was subsequently revised in 1993 to address
some of the security concerns documented in [IANS90] and [MITC90]. The standard is
currently at version 7, issued in 2012.
 X.509 Certificate Use
The certificate for Bob’s public key includes unique
identifying information for Bob, Bob’s public key, and
identifying information about the CA, plus other
information as explained subsequently.
This information is then signed by computing a hash value
of the information and generating a digital signature using
the hash value and the CA’s private key.
X.509 indicates that the signature is formed by encrypting
the hash value.
The current version of X.509 does not dictate a specific
digital signature algorithm.
If the NIST DSA or the ECDSA scheme is used, then the
hash value is not encrypted but serves as input to a digital
signature generation algorithm.
X.509 Certificates
Elements of the certificate
• Version: Differentiates among successive versions of the certificate format; the default is version 1.
• If the issuer unique identifier or subject unique identifier are present, the value must be version 2

• If one or more extensions are present, the version must be version 3.

• Although the X.509 specification is currently at version 7, no changes have been made to the fields that make
up the certificate since version 3.

• Serial number: An integer value unique within the issuing CA that is unambiguously associated with this
certificate.

• Signature algorithm identifier: The algorithm used to sign the certificate together with any associated
parameters. Because this information is repeated in the signature field at the end of the certificate, this
field has little utility.
Elements of the certificate
• Issuer name: X.500 name of the CA that created and signed this certificate.

• Period of validity: Consists of two dates: the first and last on which the certificate is valid.

• Subject name: The name of the user to whom this certificate refers. That is, this certificate

certifies the public key of the subject who holds the corresponding private key.

• Subject’s public-key information: The public key of the subject, plus an identifier of the

algorithm for which this key is to be used, together with any associated parameters.

• Issuer unique identifier: An optional-bit string field used to identify uniquely the issuing CA in

the event the X.500 name has been reused for different entities.
Elements of the certificate
• Subject unique identifier: An optional-bit string field used to identify uniquely the subject in the event

the X.500 name has been reused for different entities.

• Extensions: A set of one or more extension fields. Extensions were added in version 3 and are discussed

later in this section.

• Signature: Covers all of the other fields of the certificate. One component of this field is the digital

signature applied to the other fields of the certificate. This field includes the signature algorithm identifier

The unique identifier fields were added in version 2 to handle the possible reuse of subject and/or issuer

names over time. These fields are rarely used.

 Certificate Revocation
 certificates have a period of validity
 may need to revoke before expiry, eg:
1. user's private key is compromised
2. user is no longer certified by this CA
3. CA's certificate is compromised
 CA’s maintain list of revoked certificates

the Certificate Revocation List (CRL)
 users should check certificates with CA’s CRL