Chapter 13 Digital Signatures Authentication Protocols

Chapter 13 Digital Signatures & Authentication Protocols

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

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

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

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

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

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)

重現 (replay)的破壞行為

Using Symmetric Encryption • as discussed previously can use a twolevel 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

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 || 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)]

Key Distribution Scenario

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)

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[N 1] 5. A→B: EKs[f(N 1)] • Verify timeliness by ｜Clock-T｜<Δt 1+Δt 2, where Δt 1 is the estimated normal discrepancy between the KDC’s clock and the local clock(at A or B) and Δt 2 is the expected network delay time. • Clock synchronization • Suppress replay attacks

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

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

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

Woo & Lam Protocol - nonces • Woo 92 b 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]

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

Using Symmetric Encryption • can refine use of KDC but can’t have final exchange of nonces, 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] • does not protect against replays – could rely on timestamp in message, though email delays make this problematic

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

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

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

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

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

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 (v 2+) subject unique identifier (v 2+) extension fields (v 3) signature (of hash of all fields in certificate) • notation CA<> denotes certificate for A signed by CA