cns

1. Cryptography & Network
Security
Cryptographic Hash Functions, MAC and Digital Signatures
UNIT-IV
Dr. G Lakshmeeswari
Associate Professor, CSE

2. Course
Particulars
• Course Code : CSEN2071
• Category : Core
• Credits : 03
• Faculty Name : Dr. G Lakshmeeswari
• Offered to : ¾ B. Tech (CSE)
• Semester : 6
• Duration :
• Academic year : 2024-25
• Offering Dept. : CSE, GIT, Visakhapatnam

3. 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)

4. 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)

5. 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)

6. Module – 4
Learning
Outcomes
After Completion of this unit the
student will be able to
 explain and implement simple hash
functions (L2)
 discuss message authentication
techniques (L2)
 explain Digital Signature Standard
(DSS) (L2)

7. Introduction
• A hash function H accepts a variable-length block of data
M as input and produces a fixed-size hash value.
h = H(M)
• 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)

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

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

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

11. 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)

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

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

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

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

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

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

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

19. Comparison of SHA parameters

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

21. 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).

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

23. 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 ith
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

24. 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:

25. 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) are
generated by substitution. Elementary SHA-512 Operation (single round)

26. SHA-512
• Creation of 80-word Input Sequence for SHA-512 Processing of Single
Block

27. 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:

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

29. Message Authentication
Codes

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

31. Message
Authentication
Requirements
• In the context of communications across a network,
following attacks can be identified:
• Disclosure
• Traffic analysis
• Masquerade
• Content modification
• Sequence modification
• Timing modification
• Source repudiation
• Destination repudiation

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

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

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

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

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

37. Basic Uses of Message Authentication code
(MAC)

38. MAC
Properties
• a MAC is a cryptographic checksum
MAC = CK(M)

condenses a variable-length message M using a
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

39. Requirements
for MACs
• taking into account the types of attacks
• need the MAC to satisfy the following:
1. knowing a message and MAC, is infeasible to
find another message with same MAC
2. MACs should be uniformly distributed
3. MAC should depend equally on all bits of the
message

40. Security of
MACs
• attacks on MACs are grouped into two categories:
• brute-force attacks
• cryptanalysis
• Brute-force attacks exploiting
•
strong collision resistance hash have cost 2
m/2
• 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

41. Keyed
Hash
Functions
as MACs
• a MAC based on a hash function

because hash functions are generally faster

crypto hash function code is widely available
• hash includes a key along with message
• original proposal:
KeyedHash = Hash(Key|Message)

some weaknesses were found with this
• eventually led to development of HMAC

42. HMAC

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

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

45. HMAC Overview
•HMAC can be expressed as:
•HMAC(K, M) = H[(K+
⊕
opad) || H[(K+ ipad) ||
⊕
M]]

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

48. MAC’s BASED ON BLOCK
CIPHERS: DAA and CMAC

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

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

51. 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 K1.
• For AES, the key size is 128, 192, or 256 bits; for triple DES, the key size is 112 or 168 bits.

52. Cipher-Based Message Authentication Code
(CMAC)

53. Digital Signatures

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

55. Generic
Model of
Digital
Signature
Process

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

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

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

59. Simplified
Depiction of
Essential
Elements of
Digital Signature
Process

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

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

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

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

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

65. Digital Signature Standard (DSS)
US Govt approved
signature scheme
designed by NIST &
NSA in early 90’s
published as FIPS-
186 in 1991
revised in 1993,
1996 & then 2000
uses the SHA hash
algorithm
DSS is the standard,
DSA is the algorithm
FIPS 186-2 (2000)
includes alternative
RSA & elliptic curve
signature variants
DSA is digital
signature only unlike
RSA which is a
public-key technique

66. Two
Approaches
to Digital
Signatures

67. The Digital
Signature
Algorithm
• creates a 320 bit signature
• with 512-1024 bit security
• smaller and faster than RSA
• a digital signature scheme only
• security depends on difficulty of computing
discrete logarithms
• variant of ElGamal & Schnorr schemes

68. Digital Signature Creation and Verification

69. DSS
Signing
and
Verifying

70. DSS Signing and Verifying

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

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

73. 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)

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

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

76. Decentralized
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.

77. Symmetric Key distribution using Asymmetric
Encryption
One of the most important uses of a public-
key cryptosystem is to encrypt secret keys for
distribution

78. Simple use
of Public
key
encryption
to establish
a session
key
If A wishes to communicate with B, the following procedure is employed:
• A generates a public/private key pair {PUa, PRa} and transmits a message to B
consisting of PUa and an identifier of A, IDA.
• 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
the message, only A and B will know the identity of Ks.
• A discards PUa and PRa and B discards PUa.
A and B can now securely communicate using conventional encryption and the session key
Ks.

79. Man in the middle attack

80. Secret Key distribution with confidentiality
and Authentication

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

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

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

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

85. 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 PUa 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.

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

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

88. 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, PUauth, to decrypt the certificate.

89. Obtaining public key certificates from CA

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

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

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

93. X.509 Certificates

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

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

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

97. X.509 Certificates
• notation CA<<A>> = CA {V, SN, AI, CA, UCA, A, UA, Ap, TA
} denotes certificate for A
signed by CA
• Where :
Y <<X>> = the certificate of user X issued by certification authority Y
Y {I} = the signing of I by Y. It consists of I with an encrypted hash code appended
V = version of the certificate (1, 2, or 3)
SN = serial number of the certificate (unique within CA)
AI = identifier of the algorithm used to sign the certificate
CA = name of certificate authority
UCA = optional unique identifier of the CA
A = name of user A
UA = optional unique identifier of the user A
Ap = public key of user A
TA
= period of validity of the certificate (from – to dates)

98. Obtaining a Certificate
 any user with access to CA public key can get an certificate from it.
 only the CA can modify a certificate
 As the certificates cannot be forged, certificates can be placed in a public
directory without the need for the directory to make special efforts to protect
them.
 If there is a large community of users, it may not be practical for all users to
subscribe to the same CA.

99. END of Module - 4