Chapter 13 Digital Signatures & Authentication Protocols

1. Chapter 13 Digital Signatures & Authentication Protocols

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

3. Digital Signature Properties • 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

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

5. Arbitrated Digital Signatures • involves use of arbiter A • 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

7. Authentication Protocols • used to convince parties of each others identity and to exchange session keys • may be one-way or mutual • key issues are • confidentiality – to protect session keys • timeliness – to prevent replay attacks

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

9. 重現(replay)的破壞行為

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

11. Needham-Schroeder Protocol • original third-party key distribution protocol • for session between A B mediated by KDC • protocol overview is: 1. A→KDC: IDA|| IDB|| N1 2. KDC→A: EKa[Ks|| IDB|| N1 || EKb[Ks||IDA] ] 3. A→B: EKb[Ks||IDA] 4. B→A: EKs[N2] 5. A→B: EKs[f(N2)]

12. Key Distribution Scenario

13. Needham-Schroeder Protocol • 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 • then message 3 can be resent convincing B that is communicating with A • modifications to address this require: • timestamps (Denning 81) • using an extra nonce (Neuman 93)

14. Denning Protocol • protocol overview is: 1. A→KDC: IDA|| IDB 2. KDC→A: EKa[Ks|| IDB|| T || EKb[Ks||IDA || T ] ] 3. A→B: EKb[Ks||IDA || T] 4. B→A: EKs[N1] 5. A→B: EKs[f(N1)] • Verify timeliness by ｜Clock-T｜<Δt1+Δt2, where Δt1 is the estimated normal discrepancy between the KDC’s clock and the local clock(at A or B) and Δt2 is the expected network delay time. • Clock synchronization • Suppress replay attacks

15. Neuman Protocol • protocol overview is: 1. A→B: IDA|| Na 2. B→KDC: IDB|| Nb || EKb[IDA || Na || Tb] 3. KDC→A: EKa[IDB ||Na ||Ks||Tb] || EKb[IDA||Ks||Tb] || Nb 4. A→B: EKb[IDA||Ks||Tb] || EKs[Nb] • Tb: expiration time • This timestamp does not require synchronized clocks because B checks only self-generated timestamps

16. Using Public-Key Encryption • 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

17. Denning AS Protocol - timestamps • 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]] • note session key is chosen by A, hence AS need not be trusted to protect it • timestamps prevent replay but require synchronized clocks

18. Woo & Lam Protocol - nonces • Woo 92b presented the following: 1. A→KDC: IDA|| IDB 2. KDC→A: EKRauth[IDB || KUb] 3. A→B: EKUb[Na || IDA] 4. B→KDC: IDB || IDA || EKUauth[Na] 5. KDC→B: EKRauth[IDA||KUa] || EKUb[EKRauth [Na ||Ks|| IDB]] 6. B→A: EKUa[EKRauth [Na ||Ks|| IDB] || Nb] 7. A→B: Eks[Nb]

19. One-Way Authentication • 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

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

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

22. 加解密技術及雜湊函式混合使用保證訊息的私密性，完整性及做身份確認加解密技術及雜湊函式混合使用保證訊息的私密性，完整性及做身份確認

23. 加解密技術及雜湊函式混合使用保證訊息的私密性，完整性及做身份確認加解密技術及雜湊函式混合使用保證訊息的私密性，完整性及做身份確認

24. 認證中心(Certificate Authority) • 申請電子證書(Digital Certificate)；用來證明身份的合法性及訊息發送者的不可否認性 • 電子證書的結構 • 認證中心產生電子證書和簽章 • 使用者驗證電子證書之合法性

25. 電子證書的結構: ITU-T X.509之規格 • V(版本): 此電子證書格式的版本。 • SN(序號): 認證中心簽發此份電子證書所給的唯一序號。 • AI(演算法): 認證中心在此電子證書所採用的簽章演算法。 • CA(認證中心): 簽發此電子證書的認證中心名稱。 • TA(證書有效期限): 此電子證書的使用有效期限。 • A(使用者): 擁有此電子證書上所記錄的公開鑰匙的使用者名稱。 • Ap(公鑰資料): 此電子證書上所記錄的的公開鑰匙及所使用的加解密演算法名稱。 • UCA(認證中心識別號): 簽發此電子證書的認證中心獨有的唯一識別碼。 • UA(使用者識別號): 擁有此電子證書上所記錄的公開鑰匙的使用者獨有的識別碼。 • signature(of hash of all fields in certificate)

26. X.509 Certificates • issued by a Certification Authority (CA), containing: • version (1, 2, or 3) • serial number (unique within CA) identifying certificate • signature algorithm identifier • issuer X.500 name (CA) • period of validity (from - to dates) • subject X.500 name (name of owner) • subject public-key info (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

27. 電子證書的結構: ITU-T X.509之規格

28. X.509 Certificates

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

30. 認證中心產生電子證書和簽章 • 步驟一：依據申請者提供的資料產生一未加認證中心簽章之電子證書。 • 步驟二：用雜湊函式對電子證書的內容計算出證書摘要(Certificate Digest)。 • 步驟三：認證中心用自己的私有鑰匙對證書摘要作加密，產生證書簽章(Certificate Signature)。 • 步驟四：將步驟一產生的證書和步驟三產生的證書簽章組合起來，便成為完整具有身份認證功能的電子證書。。 • 步驟五：將電子證書傳送給申請者。

31. 認證中心產生電子證書和簽章

32. 使用者驗證電子證書之合法性

33. ElGamal Public Key Cryptosystem • security relies on the difficulty of computing discrete logarithms (similar to factoring) – hard • User Alice wants to send a message m to Bob • Bob: q - prime number  - a primitive root of q X - private key  = X mod q – public key • Alice: • Downloads (, q, ) • Chooses a secret random integer k • Encryption: r  k mod q; t  km mod q • Send (r, t)=(k, km)to Alice • Bob: • Decryption: t/rX = m

34. ElGamal Digital Signature Scheme • User Bob wants to send an authenticated message m to Alice • Bob: q - prime number  - a primitive root of q X - private key  = X mod q – public key • Bob: • Chooses a secret random integer k, 0<k<q, gcd(k, q-1)=1 • Computes r  k mod q;S k-1(m-Xr) mod (q-1) • Digital signature  (r, s) • Alice: • Verifies m = rrs

35. Digital Signature Standard (DSS) • 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 ElGamal and Schnorr schemes • creates a 320 bit signature, but with 512-1024 bit security • security depends on difficulty of computing discrete logarithms

37. DSA Key Generation • have shared global public key values (p,q,g): • a large prime p = 2L • 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 • where h<p-1, h(p-1)/q (mod p) > 1 • users choose private & compute public key: • choose x<q • compute y = gx (mod p)

38. 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.SHA(M)+ x.r)(mod q) • sends signature (r,s) with message M

39. DSA Signature Verification • having received M & signature (r,s) • to verify a signature, recipient computes: w = s-1(mod q) u1= (SHA(M).w)(mod q) u2= (r.w)(mod q) v = (gu1.yu2(mod p)) (mod q) • if v=r then signature is verified • see book web site for details of proof why