如何設計一個壞協議

  • 如何設計一個壞協議已关闭评论
  • 12 views
  • A+
所属分类:安全百科

如何設計一個壞協議

Wed Jun 13 19:44:31 2018

近幾日看 The 8th BIU Winter School on Cryptography 的 slide,
這期冬令營主要內容是協議設計。

冬令營第二講 Implicitly Authenticated KE Protocols 拋磚引玉,
提出了一個相當簡潔的兩消息隱式帶認證密鑰交換Implicitly Authenticated Key Exchange協議,

後文將稱之爲 BADAKEBasic A-round Diffie-hellman Authenticated Key Exchange

BADAKE

這是一個相當乾淨的協議,甚至可能大家自己就在實踐中設計過類似的協議。
但這不是一個安全的協議。

slide 中已經舉出了一些該協議的攻擊,這些攻擊並不那麼直觀。

Define

在描述這些攻擊之前,我們先澄清一些定義。

  • 隱式帶認證密鑰交換:
    與顯式認證密鑰交換不同,隱式認證協議不會在協議執行中顯式的失敗,
    但只有雙方身份正確時會生成相同的密鑰。
  • 認證協議安全要求: 一個合格的認證協議應該在協議完成之後保證
    • 基本僞裝抗性Basic Impersonation Resistance: 若 A 正確執行協議,當敵手不知道 A 的長期密鑰時,敵手不可以僞裝成 A。
  • 密鑰交換協議安全要求: 一個合格的密鑰交換協議應該保證,
    • 完美前向保密Perfect Forward Secrecy: 長期密鑰泄漏時,不會影響之前會話密鑰的安全性。
    • 弱前向保密weak Perfect Forward Secrecy: 由於兩消息的認證密鑰交換協議無可能滿足 PFS,所以對於這些協議,退而求其次,我們只要求 wPFS。
      若敵手在長期密鑰泄漏之前沒有參與協議,那長期密鑰泄漏時,不會影響之前會話密鑰的安全性。
    • 已知密鑰安全Known-Key Security: 會話密鑰泄漏時,不會影響長期密鑰及其他會話密鑰的安全性。
    • 臨時祕密揭露抗性Ephemeral Secrets Reveal Resistance: 臨時密鑰泄漏時,不會影響長期密鑰及其他會話密鑰的安全性。
    • 未知密鑰共享Unknown Key-Share抗性: 當 A 和 C 協商出會話密鑰時,A 不會認爲該密鑰是與 B 協商得到的。

Signature + DH

在分析 BADAKE 前,slide 先給出了一個簡單的簽名與密鑰交換的組合協議。
這個協議在簽名中加入了目標身份,以避免交錯攻擊。

但這個協議仍然是不安全的。

當 A 的臨時密鑰 x 泄漏時,
攻擊者可以重放消息 g^x, SIG{A}(g^x, B),與 B 進行握手。
從而達成僞裝 A 身份的目的。

一般情況下防止重放攻擊的最好方案是添加一個 challenge,
但這需要增加一輪通信。

這個例子說明了使用 Signature + DH 的簡單組合無法實現安全的兩消息帶認證密鑰交換。

Implicitly Authenticated DH

slide 給出了 BADAKE 的兩種簡單組合方式。

第一種組合方式相當簡單,
K = H(g^ab, g^xy)

slide 中描述它受到 Open to known key and interleaving attacks 的威脅。
一開始我不太明白這個攻擊如何實現。

藉助 tamarin
我們可以輕鬆找到針對這個協議的多個攻擊方案,這裏我們舉出兩個

  • 反射攻擊

reflection attack

A 向 B 發起兩個握手請求,敵手將這兩個請求作爲響應發回給 A。

A 不會知道他正在和自己通信。(呆萌

  • 會話密鑰揭露時的交錯攻擊

interleaving attack

這圖片中描述的攻擊與 slide 可能有所不同。

此攻擊需要 B 在握手結束之後泄漏會話密鑰。

B 向 A 發起兩個握手請求,敵手將一個請求作爲響應發回給 B。
兩個會話產生相同的密鑰,結束其中一個會話,B 泄漏會話密鑰 K
敵手使用該密鑰繼續與 B 通信。

最終達成僞造 A 身份的目的。

KCI Attack

第二種組合方式添加了角色因素,
可以對抗反射、並行會話等攻擊方式。
K = H(g^ab, g^xy, g^x, g^y)

這相比第一種組合方式要好一點,但仍不是一個理想的 AKE 方案。

slide 中提到了密鑰泄漏僞裝攻擊Key-Compromise Impersonation
簡單來講就是,在 A 的長期密鑰泄漏之後,敵手不但可以僞裝成 A 與 B 通信,也可以僞裝成 B 與 A 通信。

這個漏洞在使用密鑰交換作認證的協議裏很常見,例如 Tox 就有這個問題。

很多人會覺得泄漏長期密鑰之後,協議可以不保證認證安全性。但一個好的認證協議應該要避免這一點。


上文的內容在冬令營的演講中只佔不到半分鐘時間,而後面關於 MQV、HMQV 的各種變種佔了將近兩個小時。

設計一個好的密碼協議並不是一件容易的事情。

而想要設計一個壞協議?只需要拍腦袋式的想一個簡潔的協議就可以了。

CN-SEC.COM中文网|本文百科收录于:https://quininer.github.io/

相关推荐: 基于serviceWorker的缓存投毒

基于serviceWorker的缓存投毒 Sat May 2 20:52:57 2015 前几天才察觉到 Chromium 42 已经支持 Fetch API 了, 鉴于我早就想用 Fetch 代替 Ajax, 所以今天把 ice.js 的$.http部分改用…