NSC_Unit-III_final.ppt

Network Security and
Cryptography
Unit-III
Source: Lecture slides by Lawrie
Brown for “Cryptography and
Network Security”, 5/e, by William
Stallings

Message Authentication
 message authentication is concerned with:
 protecting the integrity of a message
 validating identity of originator
 non-repudiation of origin (dispute resolution)
 will consider the security requirements
 Then three alternative functions used:
 Message Encryption
 Hash function
 Message Authentication Code (MAC)

Message Security Requirements
 disclosure
 traffic analysis
 masquerade
 content modification
 sequence modification
 timing modification
 source repudiation
 destination repudiation

Symmetric Message Encryption
 encryption can also provide authentication
 if symmetric encryption is used then:
 receiver knows sender must have created it
 since only sender and receiver now used key
 know content cannot be altered
 if message has suitable structure, redundancy
or a checksum to detect any changes

Public-Key Message Encryption
 if public-key encryption is used:
 encryption provides no confidence of sender
• since anyone potentially knows public-key
 however if
• sender signs message using their private-key
• then encrypts with recipients public key
• have both secrecy and authentication
 again need to recognize corrupted messages
 but at cost of two public-key uses on message

Message Authentication Code
(MAC)
 generated by an algorithm that creates a
small fixed-sized block
 depending on both message and some key
 like encryption though need not be reversible
 appended to message as a signature
 receiver performs same computation on
message and checks it matches the MAC
 provides assurance that message is
unaltered and comes from sender

Message Authentication Code
 a small fixed-sized block of data
 generated from message + secret key
 MAC = C(K,M)
 appended to message when sent

Message Authentication
Codes
 as shown the MAC provides authentication
 can also use encryption for secrecy
 generally use separate keys for each
 can compute MAC either before or after encryption
 is generally regarded as better done before
 why use a MAC?
 sometimes only authentication is needed
 sometimes need authentication to persist longer than
the encryption (eg. archival use)
 note that a MAC is not a digital signature

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

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

Security of MACs
 like block ciphers have:
 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 keyspace (cf key search) or MAC
• at least 128-bit MAC is needed for security

Security of MACs
 cryptanalytic attacks exploit structure
 like block ciphers want brute-force attacks to
be the best alternative
 more variety of MACs so harder to
generalize about cryptanalysis

Cryptographic Hash
Functions
Each of the messages, like each one he had ever
read of Stern's commands, began with a number
and ended with a number or row of numbers. No
efforts on the part of Mungo or any of his experts
had been able to break Stern's code, nor was
there any clue as to what the preliminary
number and those ultimate numbers signified.
—Talking to Strange Men, Ruth Rendell

Hash Functions
 condenses arbitrary message to fixed size
h = H(M)
 usually assume hash function is public
 hash used to detect changes to message
 want a cryptographic hash function
 computationally infeasible to find data mapping to
specific hash (one-way property)
 computationally infeasible to find two data to same
hash (collision-free property)

Hash Function Uses
 Message Integrity Check (MIC)
 send hash of message (digest)
 MIC always encrypted, message optionally
 Message Authentication Code (MAC)
 send keyed hash of message
 MAC, message optionally encrypted
 Digital Signature (non-repudiation)
 Encrypt hash with private (signing) key
 Verify with public (verification) key

Hash Functions & Message
Authentication
Symmetric Key
Unkeyed Hash
a) Message
encrypted
b) Message
unencrypted

Hash Functions & Message
Authentication
Symmetric Key
Keyed Hash
a) Message
unencrypted
d) Message
encrypted

Hash Functions & Digital
Signatures - PKCS

Other Hash Function Uses
 pseudorandom function (PRF)
 Generate session keys, nonces
 Produce key from password
 Derive keys from master key cooperatively
 pseudorandom number generator
(PRNG)
 Vernam Cipher/OTP
 S/Key, proof of “what you have” via messages

More Hash Function Uses
 to create a one-way password file
 store hash of password not actual password
 e.g., Unix, Windows NT, etc.
 salt to deter precomputation attacks
 Rainbow tables
 for intrusion detection and virus detection
 keep & check hash of files on system
 e.g., Tripwire

Lamport One-time Passwords
 Password safety in distributed system
 server compromise does not compromise P
 interception of authentication exchange does
not compromise password either
 Alice picks Password PA
 Hashes password N times, HN(PA)
 Server stores (Alice, N, HN(PA))
 Attacker can’t get PA from HN(PA)

Lamport One-time Passwords
 Protocol
 Alice sends “I’m Alice”
 Server sends “N-1”
 Alice sends “X” where X=HN-1(PA)
 Server verifies H(X) = HN(PA)
 Server updates to (Alice, N-1, X)
 Attacker still can’t get PA or
authenticate as Alice

Two Simple Insecure Hash
Functions
 consider two simple insecure hash functions
 bit-by-bit exclusive-OR (XOR) of every block
 Ci = bi1 xor bi2 xor . . . xor bim
 a longitudinal redundancy check
 reasonably effective as data integrity check
 one-bit circular shift on hash value
 for each successive n-bit block
•rotate current hash value to left by1bit and XOR block
 good for data integrity but useless for security

Attacks on Hash Functions
 have brute-force attacks and cryptanalysis
 a preimage or second preimage attack
 find y s.t. H(y) equals a given hash value
 collision resistance
 find two messages x & y with same hash so
H(x) = H(y)
 hence value 2m/2 determines strength of
hash code against brute-force attacks
 128-bits inadequate, 160-bits suspect

Birthday Attacks
 might think a 64-bit hash is secure
 but by Birthday Paradox is not
 birthday attack works thus:
 given user prepared to sign a valid message x
 opponent generates 2
m/2 variations x’ of x, all with essentially the same
meaning, and saves them
 opponent generates 2
m/2 variations y’ of a desired fraudulent message y
 two sets of messages are compared to find pair with same hash
(probability > 0.5 by birthday paradox)
 have user sign the valid message, then substitute the forgery which will
have a valid signature
 conclusion is that need to use larger MAC/hash

Birthday Attacks
y y’1 y’2 … y’j … y’N
x ≠ ≠ ≠ ≠ ≠
x’1 ≠ ≠ ≠ ≠ ≠
x’2 ≠ ≠ ≠ ≠ ≠
…
x’i ≠ ≠ ≠ = ≠
…
x’N ≠ ≠ ≠ ≠ ≠
Find i and j
such that
H(y’j)=H(x’i)
Table takes O(N2
)
time
Faster …
Sorted lists take
O(NlogN) time

Birthday Attacks
 What are chances we get a match?
 N distinct values, k randomly chosen ones
 P(N,i) = prob(i randomly selected values from
1..N have at least one match)
 P(N,2) = 1/N
 P(N,i+1) = P(N,i)+(1-P(N,i))(i/N)
 For P(N,k)>0.5, need k ≈ N1/2
 Need double # bits in hash value

Hash Function Cryptanalysis
 cryptanalytic attacks exploit some property
of alg so faster than exhaustive search
 hash functions use iterative structure
 process message in blocks (incl length)
 attacks focus on collisions in function f

Block Ciphers as Hash
Functions
 can use block ciphers as hash functions
 using H0=0 and zero-pad of final block
 compute: Hi = EMi
[Hi-1]
 and use final block as the hash value
 similar to CBC but without a key
 resulting hash is too small (64-bit)
 both due to direct birthday attack
 and to “meet-in-the-middle” attack
 other variants also susceptible to attack

Block Ciphers as Hash
Functions
E
M1
H0
E
M2
E
ML
HL
Block cipher key length B
Pad Message M to multiple of B
Break padded M into L blocks
L = |M|/B
M = M1 M2 … ML
Use blocks of M as keys in block
cipher, iteratively encrypt state value
starting with constant H0 resulting in
hash value
H = HL = E(ML,….E(M2,E(M1,H0))…)

Secure Hash Algorithm
 SHA originally designed by NIST & NSA in 1993
 was revised in 1995 as SHA-1
 US standard for use with DSA signature scheme
 standard is FIPS 180-1 1995, also Internet RFC3174
 nb. the algorithm is SHA, the standard is SHS
 based on design of MD4 with key differences
 produces 160-bit hash values
 2005 results on security of SHA-1 raised
concerns on its use in future applications

Revised Secure Hash
Standard
 NIST issued revision FIPS 180-2 in 2002
 adds 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 similar to SHA-1
 hence analysis should be similar
 but security levels are rather higher

SHA-512 Compression
Function
 heart of the algorithm
 processing message in 1024-bit blocks
 consists of 80 rounds
 updating a 512-bit buffer
 using a 64-bit value Wt derived from the
current message block
 and a round constant based on cube root of
first 80 prime numbers

SHA-3
 SHA-1 not yet "broken”
 but similar to broken MD5 & SHA-0
 so considered insecure
 SHA-2 (esp. SHA-512) seems secure
 shares same structure and mathematical
operations as predecessors so have concern
 NIST announced in 2007 a competition for
the SHA-3 next gen NIST hash function
 Keccak winner Oct 2012 – std in Q2,2014

SHA-3 Requirements
 replace SHA-2 with SHA-3 in any use
 so use same hash sizes
 preserve the online nature of SHA-2
 so must process small blocks (512 / 1024 bits)
 evaluation criteria
 security close to theoretical max for hash sizes
 cost in time & memory
 characteristics: such as flexibility & simplicity

Keyed Hash Functions as MACs
 want 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

HMAC Design Objectives
 use, without modifications, hash functions
 allow for easy replaceability of embedded
hash function
 preserve original performance of hash
function without significant degradation
 use and handle keys in a simple way.
 have well understood cryptographic analysis
of authentication mechanism strength

HMAC
 specified as Internet standard RFC2104
 uses hash function on the message:
HMACK(M)= Hash[(K+ XOR opad) ||
Hash[(K+ XOR ipad) || M)] ]
 where K+ is the key padded out to size
 opad, ipad are specified padding constants
 overhead is just 3 more hash calculations than
the message needs alone
 any hash function can be used
 eg. MD5, SHA-1, RIPEMD-160, Whirlpool

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

Using Symmetric Ciphers for
MACs
 can use any block cipher chaining mode
and use final block as a MAC
 Data Authentication Algorithm (DAA) is
a widely used MAC based on DES-CBC
 using IV=0 and zero-pad of final block
 encrypt message using DES in CBC mode
 and send just the final block as the MAC
• or the leftmost M bits (16≤M≤64) of final block
 but final MAC is now too small for security

CMAC
 previously saw the DAA (CBC-MAC)
 widely used in govt & industry
 but has message size limitation
 can overcome using 2 keys & padding
 thus forming the Cipher-based Message
Authentication Code (CMAC)
 adopted by NIST SP800-38B

Authenticated Encryption
 simultaneously protect confidentiality and
authenticity of communications
 often required but usually separate
 approaches
 Hash-then-encrypt: E(K, (M || H(M))
 MAC-then-encrypt: E(K2, (M || MAC(K1, M))
 Encrypt-then-MAC: (C=E(K2, M), T=MAC(K1, C)
 Encrypt-and-MAC: (C=E(K2, M), T=MAC(K1, M)
 decryption /verification straightforward
 but security vulnerabilities with all these

Counter with Cipher Block
Chaining-Message
Authentication Code (CCM)
 NIST standard SP 800-38C for WiFi
 variation of encrypt-and-MAC approach
 algorithmic ingredients
 AES encryption algorithm
 CTR mode of operation
 CMAC authentication algorithm
 single key used for both encryption & MAC

Galois/Counter Mode (GCM)
 NIST standard SP 800-38D, parallelizable
 message is encrypted in variant of CTR
 ciphertext multiplied with key & length over
in (2128) to generate authenticator tag
 have GMAC MAC-only mode also
 uses two functions:
 GHASH - a keyed hash function
 GCTR - CTR mode with incremented counter

Pseudorandom Number
Generation (PRNG) Using
Hash Functions and MACs
 essential elements of PRNG are
 seed value
 deterministic algorithm
 seed must be known only as needed
 can base PRNG on
 encryption algorithm (Chs 7 & 10)
 hash function (ISO18031 & NIST SP 800-90)
 MAC (NIST SP 800-90)

PRNG using a Hash Function
 hash PRNG from
SP800-90 and
ISO18031
 take seed V
 repeatedly add 1
 hash V
 use n-bits of hash
as random value
 secure if good
hash used

PRNG using a MAC
 MAC PRNGs in
SP800-90,
IEEE 802.11i,
TLS
 use key
 input based on
last hash in
various ways

Digital Signatures
To guard against the baneful influence exerted by
strangers is therefore an elementary dictate of savage
prudence. Hence before strangers are allowed to enter a
district, or at least before they are permitted to mingle
freely with the inhabitants, certain ceremonies are often
performed by the natives of the country for the purpose
of disarming the strangers of their magical powers, or of
disinfecting, so to speak, the tainted atmosphere by
which they are supposed to be surrounded.
—The Golden Bough, Sir James George Frazer

Digital Signatures
 have looked at message authentication
 but does not address issues of lack of trust
 digital signatures provide the ability to:
 verify author, date & time of signature
 authenticate message contents
 be verified by third parties to resolve disputes
 hence include authentication function with
additional capabilities

Attacks and Forgeries
 attacks
 key-only attack
 known message attack
 generic chosen message attack
 directed chosen message attack
 adaptive chosen message attack
 break success levels
 total break
 selective forgery
 existential forgery

Digital Signature Requirements
 must depend on the message signed
 must use information unique to sender
 to prevent both forgery and denial
 must be relatively easy to produce
 must be relatively easy to recognize & verify
 be computationally infeasible to forge
 with new message for existing digital signature
 with fraudulent digital signature for given message
 be practical save digital signature in storage

Direct Digital Signatures
 involve only sender & receiver
 assumed receiver has sender’s public-key
 digital signature made by sender signing
entire message or hash with private-key
 can encrypt using receivers public-key
 important that sign first then encrypt
message & signature
 security depends on sender’s private-key

ElGamal Digital Signatures
 A variant of the DSA.
 signature variant of ElGamal, related to D-H
 so uses exponentiation in a finite (Galois)
 with security based difficulty of computing
discrete logarithms, as in D-H
 use private key for encryption (signing)
 uses public key for decryption (verification)
 each user (eg. A) generates their key
 chooses a secret key (number): 1 < xA < q-1
 compute their public key: yA = a
xA
mod q

ElGamal Digital Signature
 Alice signs a message M to Bob by computing
 the hash m = H(M), 0 <= m <= (q-1)
 chose random integer K with 1 <= K <= (q-1)
and gcd(K,q-1)=1
 compute temporary key: S1 = a
k
mod q
 compute K-1 the inverse of K mod (q-1)
 compute the value: S2 = K-1(m-xAS1) mod (q-1)
 signature is:(S1,S2)
 any user B can verify the signature by computing
 V1 = a
m
mod q
 V2 = yA
S1 S1
S2 mod q
 signature is valid if V1 = V2

ElGamal Signature Example
 use field GF(19) q=19 and a=10
 Alice computes her key:
 A chooses xA=16 & computes yA=10
16
mod 19 = 4
 Alice signs message with hash m=14 as (3,4):
 choosing random K=5 which has gcd(18,5)=1
 computing S1 = 10
5
mod 19 = 3
 finding K-1 mod (q-1) = 5-1 mod 18 = 11
 computing S2 = 11(14-16.3) mod 18 = 4
 any user B can verify the signature by computing
 V1 = 10
14
mod 19 = 16
 V2 = 43.34 = 5184 = 16 mod 19
 since 16 = 16 signature is valid

Schnorr Digital Signatures
 also uses exponentiation in a finite (Galois)
 security based on discrete logarithms, as in D-H
 minimizes message dependent computation
 multiplying a 2n-bit integer with an n-bit integer
 main work can be done in idle time
 have using a prime modulus p
 p–1 has a prime factor q of appropriate size
 typically p 1024-bit and q 160-bit numbers

Schnorr Key Setup
 choose suitable primes p , q
 choose a such that a
q
= 1 mod p
 (a,p,q) are global parameters for all
 each user (eg. A) generates a key
 chooses a secret key (number): 0 < sA < q
 compute their public key: vA = a
-sA
mod q

Schnorr Signature
 user signs message by
 choosing random r with 0<r<q and computing
x = ar mod p
 concatenate message with x and hash result to
computing: e = H(M || x)
 computing: y = (r + se) mod q
 signature is pair (e, y)
 any other user can verify the signature as follows:
 computing: x' = ayve mod p
 verifying that: e = H(M || x’)

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
 is a public-key technique

Digital Signature Algorithm
(DSA)
 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

DSA Key Generation
 have shared global public key values (p,q,g):
 choose 160-bit prime number q
 choose a large prime p with 2L-1 < p < 2L
• where L= 512 to 1024 bits and is a multiple of 64
• such that q is a 160 bit prime divisor of (p-1)
 choose g = h(p-1)/q
• where 1<h<p-1 and h(p-1)/q mod p > 1
 users choose private & compute public key:
 choose random private key: x<q
 compute public key: y = gx mod p

DSA Signature Creation
 to sign a message M the sender:
 generates a random signature key k, k<q
 nb. k must be random, be destroyed after
use, and never be reused
 then computes signature pair:
r = (gk mod p)mod q
s = [k-1(H(M)+ xr)] mod q
 sends signature (r,s) with message M

DSA Signature Verification
 having received M & signature (r,s)
 to verify a signature, recipient computes:
w = s-1 mod q
u1= [H(M)w ]mod q
u2= (rw)mod q
v = [(gu1 yu2)mod p ]mod q
 if v=r then signature is verified
 see Appendix A for details of proof why

Chapter 14 – Key Management
and Distribution
No Singhalese, whether man or woman,
would venture out of the house without a
bunch of keys in his hand, for without such
a talisman he would fear that some devil
might take advantage of his weak state to
slip into his body.
—The Golden Bough, Sir James George
Frazer

Key Management and
Distribution
 topics of cryptographic key management /
key distribution are complex
 cryptographic, protocol, & management issues
 symmetric schemes require both parties to
share a common secret key
 public key schemes require parties to
acquire valid public keys
 have concerns with doing both

IS_Unit-II_Sam 87
Key Distribution
Both parties must have the secret key
Key is changed frequently
Requires either manual delivery of keys, or a
third-party encrypted channel
Most effective method is a Key Distribution
Center (e.g. Kerberos)

IS_Unit-II_Sam 88
Key Distribution
1. A key could be selected by A and physically
delivered to B.
2. A third party could select the key and
physically deliver it to A and B.
3. If A and B have previously used a key, one
party could transmit the new key to the
other, encrypted using the old key.
4. If A and B each have an encrypted
connection to a third party C, C could deliver
a key on the encrypted links to A and B.

IS_Unit-II_Sam 89
Key Distribution
• Session key:
– Data encrypted with a one-time session
key.At the conclusion of the session the
key is destroyed
• Permanent key:
– Used between entities for the purpose of
distributing session keys

Key Distribution
 symmetric schemes require both parties to
share a common secret key
 issue is how to securely distribute this key
 whilst protecting it from others
 frequent key changes can be desirable
 often secure system failure due to a break
in the key distribution scheme

Key Distribution
 given parties A and B have various key
distribution alternatives:
1. A can select key and physically deliver to B
2. third party can select & deliver key to A & B
3. if A & B have communicated previously can
use previous key to encrypt a new key
4. if A & B have secure communications with a
third party C, C can relay key between A & B

Key Hierarchy
 typically have a hierarchy of keys
 session key
 temporary key
 used for encryption of data between users
 for one logical session then discarded
 master key
 used to encrypt session keys
 shared by user & key distribution center

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

Symmetric Key Distribution
Using Public Keys
 public key cryptosystems are inefficient
 so almost never use for direct data encryption
 rather use to encrypt secret keys for distribution

Simple Secret Key Distribution
 Merkle proposed this very simple scheme
 allows secure communications
 no keys before/after exist

Man-in-the-Middle Attack
 this very simple scheme is vulnerable to
an active man-in-the-middle attack

Secret Key Distribution with
Confidentiality and
Authentication

Hybrid Key Distribution
 retain use of private-key KDC
 shares secret master key with each user
 distributes session key using master key
 public-key used to distribute master keys
 especially useful with widely distributed users
 rationale
 performance
 backward compatibility

Distribution of Public Keys
 can be considered as using one of:
 public announcement
 publicly available directory
 public-key authority
 public-key certificates

Public Announcement
 users distribute public keys to recipients or
broadcast to community at large
 eg. append PGP keys to email messages or
post to news groups or email list
 major weakness is forgery
 anyone can create a key claiming to be
someone else and broadcast it
 until forgery is discovered can masquerade as
claimed user

Publicly Available Directory
 can obtain greater security by registering
keys with a public directory
 directory must be trusted with properties:
 contains {name,public-key} entries
 participants register securely with directory
 participants can replace key at any time
 directory is periodically published
 directory can be accessed electronically
 still vulnerable to tampering or forgery

Public-Key Authority
 improve security by tightening control over
distribution of keys from directory
 has properties of directory
 and requires users to know public key for
the directory
 then users interact with directory to obtain
any desired public key securely
 does require real-time access to directory
when keys are needed
 may be vulnerable to tampering

Public-Key Certificates
 certificates allow key exchange without
real-time access to public-key authority
 a certificate binds identity to public key
 usually with other info such as period of
validity, rights of use etc
 with all contents signed by a trusted
Public-Key or Certificate Authority (CA)
 can be verified by anyone who knows the
public-key authorities public-key

X.509 Authentication Service
 part of CCITT X.500 directory service standards
 distributed servers maintaining user info 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
 algorithms not standardised, but RSA recommended
 X.509 certificates are widely used
 have 3 versions

X.509 Certificates
 issued by a Certification Authority (CA), containing:
 version V (1, 2, or 3)
 serial number SN (unique within CA) identifying certificate
 signature algorithm identifier AI
 issuer X.500 name CA)
 period of validity TA (from - to dates)
 subject X.500 name A (name of owner)
 subject public-key info Ap (algorithm, parameters, key)
 issuer unique identifier (v2+)
 subject unique identifier (v2+)
 extension fields (v3)
 signature (of hash of all fields in certificate)
 notation CA<<A>> denotes certificate for A signed by CA

Obtaining a Certificate
 any user with access to CA can get any
certificate from it
 only the CA can modify a certificate
 because cannot be forged, certificates can
be placed in a public directory

CA Hierarchy
 if both users share a common CA then they are
assumed to know its public key
 otherwise CA's must form a hierarchy
 use certificates linking members of hierarchy to
validate other CA's
 each CA has certificates for clients (forward) and
parent (backward)
 each client trusts parents certificates
 enable verification of any certificate from one CA
by users of all other CAs in hierarchy

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

X.509 Version 3
 has been recognised that additional
information is needed in a certificate
 email/URL, policy details, usage constraints
 rather than explicitly naming new fields
defined a general extension method
 extensions consist of:
 extension identifier
 criticality indicator
 extension value

Certificate Extensions
 key and policy information
 convey info about subject & issuer keys, plus
indicators of certificate policy
 certificate subject and issuer attributes
 support alternative names, in alternative
formats for certificate subject and/or issuer
 certificate path constraints
 allow constraints on use of certificates by
other CA’s

PKIX Management
 functions:
 registration
 initialization
 certification
 key pair recovery
 key pair update
 revocation request
 cross certification
 protocols: CMP, CMC

NSC_Unit-III_final.ppt

More Related Content

Similar to NSC_Unit-III_final.ppt (20)

More from DrVASAVIBANDE (7)

Recently uploaded (20)

NSC_Unit-III_final.ppt