Скачать презентацию Computer Security — Cryptography Chapter 3 Key Management Скачать презентацию Computer Security — Cryptography Chapter 3 Key Management

9f1edd611faf9d5bb4993bc76c0f165f.ppt

  • Количество слайдов: 78

Computer Security -- Cryptography Chapter 3 Key Management Message Authentication Digital Signature COMP 4690, Computer Security -- Cryptography Chapter 3 Key Management Message Authentication Digital Signature COMP 4690, HKBU 1

Part 1 Key Management COMP 4690, HKBU 2 Part 1 Key Management COMP 4690, HKBU 2

Key Distribution in Symmetric System l l l symmetric schemes require both parties to Key Distribution in Symmetric System l l l symmetric schemes require both parties to share a common secret key issue is how to securely distribute this key often secure system failure due to a break in the key distribution scheme COMP 4690, HKBU 3

Key Distribution l given parties A and B, we can have various key distribution Key Distribution l given parties A and B, we can have various key distribution alternatives: 1. 2. 3. 4. A can select key and physically deliver to B A third party can select & deliver key to A & B if A & B have previously used a key, can use previous key to encrypt a new key if A & B have secure communications (by encryption) with a third party C, C can relay key between A & B COMP 4690, HKBU 4

Key Distribution Center l KDC: key distribution center l l Every user share a Key Distribution Center l KDC: key distribution center l l Every user share a unique master key with KDC A and B communicate using a session key. l l The session key is used for the duration of a logical connection. Session key is generated by KDC dynamically. COMP 4690, HKBU 5

Key distribution using KDC 1. 2. 3. A issues a request to KDC including Key distribution using KDC 1. 2. 3. A issues a request to KDC including A, B’s ID, and a nonce, which differs with each request. KDC responds with a message encrypted using Ka. The message includes (1) the session key Ks, (2) the original request message, (3) Ks&IDA encrypted by Kb. A stores the session key Ks, and forwards the encrypted Ks&IDA to B. Remark: Step 1 -3 implements the key distribution. 4. 5. B sends a nonce (encrypted by Ks) to A. A responds with nonce+1 (encrypted by Ks) to B. Remark: Step 4 -5 performs authentication. COMP 4690, HKBU 6

Key Distribution Scenario COMP 4690, HKBU 7 Key Distribution Scenario COMP 4690, HKBU 7

Public-Key Management l l public-key encryption helps address key distribution problems have two aspects Public-Key Management l l public-key encryption helps address key distribution problems have two aspects of this: l l 1. distribution of public keys 2. use of public-key encryption to distribute secret keys COMP 4690, HKBU 8

1. Distribution of Public Keys l can be considered as using one of: l 1. Distribution of Public Keys l can be considered as using one of: l l Public announcement Publicly available directory Public-key authority Public-key certificates COMP 4690, HKBU 9

Public Announcement l users distribute public keys to recipients or broadcast to community at Public Announcement l users distribute public keys to recipients or broadcast to community at large l l eg. append PGP keys to email messages or post to news groups or email list major weakness is forgery l l anyone can create a key claiming to be someone else until forgery is discovered, the forger can masquerade as claimed user COMP 4690, HKBU 10

Publicly Available Directory l l can obtain greater security by registering keys with a Publicly Available Directory l l can obtain greater security by registering keys with a public directory must be trusted with properties: l l l 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 COMP 4690, HKBU 11

Public-Key Authority l l improve security by tightening control over distribution of keys from Public-Key Authority l l 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 l l does require real-time access to directory when keys are needed Problem: the Public-Key Authority could be a bottleneck in the system. COMP 4690, HKBU 12

Public-Key Authority COMP 4690, HKBU 13 Public-Key Authority COMP 4690, HKBU 13

Public-Key Certificates l l certificates allow key exchange without realtime access to public-key authority Public-Key Certificates l l certificates allow key exchange without realtime access to public-key authority created by a trusted Certificate Authority (CA) l l l bind its owner’s identity to public key also includes other info such as period of validity (like a credit card!), rights of use, etc can be verified by anyone who knows the CA’s public-key COMP 4690, HKBU 14

Public-Key Certificates KRauth is the private key used by the CA. COMP 4690, HKBU Public-Key Certificates KRauth is the private key used by the CA. COMP 4690, HKBU 15

2. Public-Key Distribution of Session Keys l l l use previous methods to obtain 2. Public-Key Distribution of Session Keys l l l use previous methods to obtain public-key can use for secrecy or authentication but public-key algorithms are slow so usually want to use symmetric encryption to protect message contents hence need a session key have several alternatives for negotiating a suitable session COMP 4690, HKBU 16

Simple Secret Key Distribution l proposed by Merkle in 1979 l l A generates Simple Secret Key Distribution l proposed by Merkle in 1979 l l A generates a new temporary public key pair A sends B the public key and his identity B generates a session key K, sends it to A encrypted using the supplied public key A decrypts the session key and both use COMP 4690, HKBU 17

Merkle’s scheme The problem is that an opponent can intercept and impersonate both halves Merkle’s scheme The problem is that an opponent can intercept and impersonate both halves of protocol, finds out the session key Ks, and then sniffers the communication between A and B. (man-in-the-middle attack) COMP 4690, HKBU 18

Public-Key Distribution of Secret Keys l l Assume A and B have securely exchanged Public-Key Distribution of Secret Keys l l Assume A and B have securely exchanged public-keys. It can provide confidentiality and authentication. COMP 4690, HKBU 19

Diffie-Hellman Key Exchange l l first public-key type scheme proposed by Diffie & Hellman Diffie-Hellman Key Exchange l l first public-key type scheme proposed by Diffie & Hellman in 1976 along with the exposition of public key concepts l l l note: now know that James Ellis (UK CESG) secretly proposed the concept in 1970 is a practical method for public exchange of a secret key used in a number of commercial products COMP 4690, HKBU 20

Diffie-Hellman Key Exchange l a public-key distribution scheme l l l cannot be used Diffie-Hellman Key Exchange l a public-key distribution scheme l l l cannot be used to exchange an arbitrary message rather it can establish a common key known only to the two participants value of key depends on the participants (and their private and public key information) based on exponentiation in a finite (Galois) field (modulo a prime or a polynomial) – easy security relies on the difficulty of computing discrete logarithms (similar to factoring) – hard COMP 4690, HKBU 21

Diffie-Hellman Setup l all users agree on global parameters: l l l each user Diffie-Hellman Setup l all users agree on global parameters: l l l each user (eg. A) generates their key l large prime integer q α a primitive root of q chooses a secret key (number): x. A < q x compute their public key: y. A = α A mod q each user makes public that key y. A COMP 4690, HKBU 22

Diffie-Hellman Key Exchange l shared session key for users A & B is KAB: Diffie-Hellman Key Exchange l shared session key for users A & B is KAB: x x KAB = α A. B mod q x = y. A B mod q (which B can compute) x = y. B A mod q (which A can compute) l l l KAB is used as session key in private-key encryption scheme between Alice and Bob if Alice and Bob subsequently communicate, they will have the same key as before, unless they choose new public-keys attacker needs an x, must solve discrete log COMP 4690, HKBU 23

COMP 4690, HKBU 24 COMP 4690, HKBU 24

Diffie-Hellman Example l l l users Alice & Bob who wish to swap keys: Diffie-Hellman Example l l l users Alice & Bob who wish to swap keys: agree on prime q=353 and α=3 select random secret keys: l l compute public keys: l l l A chooses x. A=97, B chooses x. B=233 97 y. A=3 mod 353 = 40 233 y. B=3 mod 353 = 248 (Alice) (Bob) compute shared session key as: x 97 KAB= y. B A mod 353 = 248 = 160 (Alice) x 233 KAB= y. A B mod 353 = 40 = 160 (Bob) COMP 4690, HKBU 25

Part 2 Message Authentication & Hash Functions COMP 4690, HKBU 26 Part 2 Message Authentication & Hash Functions COMP 4690, HKBU 26

Message Authentication l message authentication is concerned with: l l l protecting the integrity Message Authentication l message authentication is concerned with: l l l 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: l l l message encryption message authentication code (MAC) hash function COMP 4690, HKBU 27

Security Requirements l l l l disclosure traffic analysis masquerade content modification sequence modification Security Requirements l l l l disclosure traffic analysis masquerade content modification sequence modification timing modification source repudiation destination repudiation COMP 4690, HKBU 28

Message Encryption l l message encryption by itself also provides a measure of authentication Message Encryption l l message encryption by itself also provides a measure of authentication if symmetric encryption is used then: l l receiver knows sender must have created it since only sender and receiver know key used know content cannot of been altered if message has suitable structure, redundancy or a checksum to detect any changes COMP 4690, HKBU 29

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

COMP 4690, HKBU 31 COMP 4690, HKBU 31

COMP 4690, HKBU 32 COMP 4690, HKBU 32

Message Authentication Code (MAC) l generated by an algorithm that creates a small fixed-sized Message Authentication Code (MAC) l generated by an algorithm that creates a small fixed-sized block l l l 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 COMP 4690, HKBU 33

Message Authentication Code COMP 4690, HKBU 34 Message Authentication Code COMP 4690, HKBU 34

Message Authentication Codes l l as shown the MAC provides confidentiality can also use Message Authentication Codes l l as shown the MAC provides confidentiality can also use encryption for secrecy l l why use a MAC? l l l generally use separate keys for each can compute MAC either before or after encryption is generally regarded as better done before 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 COMP 4690, HKBU 35

MAC Properties l a MAC is a cryptographic checksum MAC = CK(M) l l MAC Properties l a MAC is a cryptographic checksum MAC = CK(M) l l condenses a variable-length message M using a secret key K to a fixed-sized authenticator is a many-to-one function l l potentially many messages have same MAC but finding these needs to be very difficult COMP 4690, HKBU 36

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

Using Symmetric Ciphers for MACs l l can use any block cipher chaining mode Using Symmetric Ciphers for MACs l l 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 l l l 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 l l or the leftmost M bits (16≤M≤ 64) of final block but final MAC is now too small for security COMP 4690, HKBU 38

Hash Functions l l condenses arbitrary message to fixed size usually assume that the Hash Functions l l condenses arbitrary message to fixed size usually assume that the hash function is public and not keyed l l cf. MAC which is keyed hash used to detect changes to message can use in various ways with message most often to create a digital signature COMP 4690, HKBU 39

Hash Functions & Digital Signatures COMP 4690, HKBU 40 Hash Functions & Digital Signatures COMP 4690, HKBU 40

Hash Function Properties l a Hash Function produces a fingerprint of some file/message/data h Hash Function Properties l a Hash Function produces a fingerprint of some file/message/data h = H(M) l l l condenses a variable-length message M to a fixed-sized fingerprint assumed to be public COMP 4690, HKBU 41

Requirements for Hash Functions can be applied to any sized message M produces fixed-length Requirements for Hash Functions can be applied to any sized message M produces fixed-length output h is easy to compute h=H(M) for any message M given h is infeasible to find x s. t. H(x)=h 1. 2. 3. 4. • one-way property given x is infeasible to find y s. t. H(y)=H(x) 5. • weak collision resistance is infeasible to find any x, y s. t. H(y)=H(x) 6. • strong collision resistance COMP 4690, HKBU 42

Birthday Attacks l l l might think a 64 -bit hash is secure but Birthday Attacks l l l might think a 64 -bit hash is secure but by Birthday Paradox is not birthday attack works thus: l l l m/ opponent generates 2 2 variations of a valid message all with essentially the same meaning m/ opponent also generates 2 2 variations of a desired fraudulent message 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 fingerprint COMP 4690, HKBU 43

Hash Algorithms l see similarities in the evolution of hash functions & block ciphers Hash Algorithms l see similarities in the evolution of hash functions & block ciphers l l l increasing power of brute-force attacks leading to evolution in algorithms from DES to AES in block ciphers from MD 4 & MD 5 to SHA-1 & RIPEMD-160 in hash algorithms likewise tend to use common iterative structure as do block ciphers COMP 4690, HKBU 44

MD 5 l l designed by Ronald Rivest (the R in RSA) latest in MD 5 l l designed by Ronald Rivest (the R in RSA) latest in a series of MD 2, MD 4 produces a 128 -bit hash value until recently was the most widely used hash algorithm l l in recent times have both brute-force & cryptanalytic concerns specified as Internet standard RFC 1321 COMP 4690, HKBU 45

MD 4 l l precursor to MD 5 also produces a 128 -bit hash MD 4 l l precursor to MD 5 also produces a 128 -bit hash of message has 3 rounds of 16 steps vs 4 in MD 5 design goals: l l collision resistant (hard to find collisions) direct security (no dependence on "hard" problems) fast, simple, compact favours little-endian systems (eg PCs) COMP 4690, HKBU 46

Secure Hash Algorithm (SHA 1) l l SHA was designed by NIST & NSA Secure Hash Algorithm (SHA 1) l l SHA was designed by NIST & NSA in 1993, revised 1995 as SHA-1 US standard for use with DSA signature scheme l l l standard is FIPS 180 -1 1995, also Internet RFC 3174 nb. the algorithm is SHA, the standard is SHS produces 160 -bit hash values now the generally preferred hash algorithm based on design of MD 4 with key differences COMP 4690, HKBU 47

Revised Secure Hash Standard l l l NIST have issued a revision FIPS 180 Revised Secure Hash Standard l l l NIST have issued a revision FIPS 180 -2 adds 3 additional hash algorithms 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 COMP 4690, HKBU 48

RIPEMD-160 l l l l RIPEMD-160 was developed in Europe as part of RIPE RIPEMD-160 l l l l RIPEMD-160 was developed in Europe as part of RIPE project in 96 by researchers involved in attacks on MD 4/5 initial proposal strengthen following analysis to become RIPEMD-160 somewhat similar to MD 5/SHA uses 2 parallel lines of 5 rounds of 16 steps creates a 160 -bit hash value slower, but probably more secure, than SHA COMP 4690, HKBU 49

Keyed Hash Functions as MACs l have desire to create a MAC using a Keyed Hash Functions as MACs l have desire to create a MAC using a hash function rather than a block cipher l l because hash functions are generally faster not limited by export controls unlike block ciphers hash includes a key along with the message original proposal: Keyed. Hash = Hash(Key|Message) l l some weaknesses were found with this eventually led to development of HMAC COMP 4690, HKBU 50

HMAC l l specified as Internet standard RFC 2104 uses hash function on the HMAC l l specified as Internet standard RFC 2104 uses hash function on the message: HMACK = Hash[(K+ XOR opad) || Hash[(K+ XOR ipad)||M)]] l l where K+ is the key padded out to size and opad, ipad are specified padding constants overhead is just 3 more hash calculations than the message needs alone any of MD 5, SHA-1, RIPEMD-160 can be used COMP 4690, HKBU 51

HMAC Overview COMP 4690, HKBU 52 HMAC Overview COMP 4690, HKBU 52

HMAC Security l l know that the security of HMAC relates to that of HMAC Security l l know that the security of HMAC relates to that of the underlying hash algorithm attacking HMAC requires either: l l l 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 COMP 4690, HKBU 53

Part 3 Digital Signatures COMP 4690, HKBU 54 Part 3 Digital Signatures COMP 4690, HKBU 54

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

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

Direct Digital Signatures l l l involve only sender & receiver assumed receiver has Direct Digital Signatures l l l 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 COMP 4690, HKBU 57

Arbitrated Digital Signatures l involves use of arbiter A l l l validates any Arbitrated Digital Signatures l involves use of arbiter A l l l validates any signed message then dated and sent to recipient requires suitable level of trust in arbiter can be implemented with either private or public-key algorithms arbiter may or may not see message COMP 4690, HKBU 58

Authentication Protocols l l l used to convince parties of each others identity and Authentication Protocols l l l used to convince parties of each others identity and to exchange session keys may be one-way or mutual key issues are l l confidentiality – to protect session keys timeliness – to prevent replay attacks COMP 4690, HKBU 59

Replay Attacks l where a valid signed message is copied and later resent l Replay Attacks l where a valid signed message is copied and later resent l l l simple replay repetition that can be logged repetition that cannot be detected backward replay without modification countermeasures include l l l use of sequence numbers (generally impractical) timestamps (needs synchronized clocks) challenge/response (using unique nonce) COMP 4690, HKBU 60

Using Symmetric Encryption l l as discussed previously can use a two-level hierarchy of Using Symmetric Encryption l l as discussed previously can use a two-level hierarchy of keys usually with a trusted Key Distribution Center (KDC) l l l each party shares own master key with KDC generates session keys used for connections between parties master keys used to distribute these to them COMP 4690, HKBU 61

Needham-Schroeder Protocol l original third-party key distribution protocol for session between A B mediated Needham-Schroeder Protocol l original third-party key distribution protocol for session between A B mediated by KDC protocol overview is: 1. A→KDC: IDA || IDB || N 1 2. KDC→A: EKa[Ks || IDB || N 1 || EKb[Ks||IDA] ] 3. A→B: EKb[Ks||IDA] 4. B→A: EKs[N 2] 5. A→B: EKs[f(N 2)] COMP 4690, HKBU 62

Needham-Schroeder Protocol l l used to securely distribute a new session key for communications Needham-Schroeder Protocol l l used to securely distribute a new session key for communications between A & B but is vulnerable to a replay attack if an old session key has been compromised l l then message 3 can be resent convincing B that is communicating with A modifications to address this require: l l timestamps (Denning 81) using an extra nonce (Neuman 93) COMP 4690, HKBU 63

Using Public-Key Encryption l l have a range of approaches based on the use Using Public-Key Encryption l l have a range of approaches based on the use of public-key encryption need to ensure have correct public keys for other parties using a central Authentication Server (AS) various protocols exist using timestamps or nonces COMP 4690, HKBU 64

Denning AS Protocol l Denning 81 presented the following: 1. A→AS: IDA || IDB Denning AS Protocol l Denning 81 presented the following: 1. A→AS: IDA || IDB 2. AS→A: EKRas[IDA||KUa||T] || EKRas[IDB||KUb||T] 3. A→B: EKRas[IDA||KUa||T] || EKRas[IDB||KUb||T] || EKUb[EKRa[Ks||T]] l l note session key is chosen by A, hence AS need not be trusted to protect it timestamps prevent replay but require synchronized clocks COMP 4690, HKBU 65

One-Way Authentication l l l required when sender & receiver are not in communications One-Way Authentication l l l required when sender & receiver are not in communications at same time (eg. email) have header in clear so can be delivered by email system may want contents of body protected & sender authenticated COMP 4690, HKBU 66

Using Symmetric Encryption l can refine use of KDC but can’t have final exchange Using Symmetric Encryption l can refine use of KDC but can’t have final exchange of nonces, vis: 1. A→KDC: IDA || IDB || N 1 2. KDC→A: EKa[Ks || IDB || N 1 || EKb[Ks||IDA] ] 3. A→B: EKb[Ks||IDA] || EKs[M] l does not protect against replays l could rely on timestamp in message, though email delays make this problematic COMP 4690, HKBU 67

Public-Key Approaches l l have seen some public-key approaches if confidentiality is major concern, Public-Key Approaches l l have seen some public-key approaches if confidentiality is major concern, can use: A→B: EKUb[Ks] || EKs[M] l has encrypted session key, encrypted message l if authentication needed use a digital signature with a digital certificate: A→B: M || EKRa[H(M)] || EKRas[T||IDA||KUa] l with message, signature, certificate COMP 4690, HKBU 68

Digital Signature Standard (DSS) l l l l US Govt approved signature scheme FIPS Digital Signature Standard (DSS) l l l l US Govt approved signature scheme FIPS 186 uses the SHA hash algorithm designed by NIST & NSA in early 90's DSS is the standard, DSA is the algorithm a variant on El. Gamal and Schnorr schemes creates a 320 bit signature, but with 512 -1024 bit security depends on difficulty of computing discrete logarithms COMP 4690, HKBU 69

Digital Signature Approaches COMP 4690, HKBU 70 Digital Signature Approaches COMP 4690, HKBU 70

The Digital Signature Algorithm COMP 4690, HKBU 71 The Digital Signature Algorithm COMP 4690, HKBU 71

DSA Key Generation l have shared global public key values (p, q, g): l DSA Key Generation l have shared global public key values (p, q, g): l a large prime p = 2 L where L= 512 to 1024 bits and is a multiple of 64 choose q, a 160 bit prime factor of p-1 choose g = h(p-1)/q (mod p) l where h 1 l l users choose private & compute public key: l l choose x

DSA Signature Creation l to sign a message M the sender: l l l DSA Signature Creation l to sign a message M the sender: l l l generates a random signature key k, k

DSA Signature Verification l having received M & signature (r, s) l to verify DSA Signature Verification l having received M & signature (r, s) l to verify a signature, recipient computes: w = u 1= u 2= v = s-1(mod q) (H(M)w)(mod q) (rw)(mod q) (gu 1. yu 2(mod p)) (mod q) l if v=r then signature is verified l see book web site for details of proof why l ftp: //shell. shore. net/members/w/s/ws/Support/Crypto/DSSProof. pdf COMP 4690, HKBU 74

Public Key Infrastructure (PKI) l l l A PKI enables users of an insecure Public Key Infrastructure (PKI) l l l A PKI enables users of an insecure public network to securely and privately exchange data through the use of public key-pairs that are obtained and shared through a trusted Certificate Authority. It can provide authentication, integrity, confidentiality, and non-repudiation services. A PKI consists of: l l A Certificate Authority: issues and verifies digital certificates A Registration Authority: the verifier for the CA before a digital certificate is issued to a requester One or more directories to held the certificates A certificate management system COMP 4690, HKBU 75

PKI Terms l l l Certificate authority l CAs provide the function of binding PKI Terms l l l Certificate authority l CAs provide the function of binding a public key-pair to a given identity, by digitally signing a public key certificate that contains some representation of the identity and a corresponding public key. Certificate repository l The repository system allows users to easily locate certificates. Certificate revocation l How to break the binding (in case of ID change, key compromise, etc. )? Key backup and recovery l How to recover the lost key? Automatic key update l All certificates should have a lifetime. How to renew the certificate? COMP 4690, HKBU 76

PKI Terms l Key history l l Cross-certificate l l There are multiple PKIs PKI Terms l Key history l l Cross-certificate l l There are multiple PKIs independently implemented and operated. There is a need for some of these PKIs to be interconnected. Non-repudiation l l A user can have multiple old certificate and one current certificate. This is known as the user’s key history. A specific user must not be able to deny having participated in a transaction at an earlier time. Time-stamping l To support non-repudiation. All users must trust the time source for the PKI. COMP 4690, HKBU 77

References l l l William Stallings, Cryptography and Network Security, 3 rd Edition, Prentice References l l l William Stallings, Cryptography and Network Security, 3 rd Edition, Prentice Hall, 2003. A. J. Menezes, et. al, Handbook of Applied Cryptography, CRC Press. Free version can be downloaded from: http: //www. cacr. math. uwaterloo. ca/hac/ S. Hansche, et. al, Official (ISC)2 Guide to the CISSP Exam, Auerbach Publications, 2003. COMP 4690, HKBU 78