前言
ECDHE 我之前是聽都沒聽過, 但是新業務需要對前後端通信進行加密, 經過大佬推薦才知道有這個東西, 經過幾天的學習和踩坑😇, 才大致明白其流程和使用方式.
過程坎坷, 好在最後還是成功運用到了業務中, 大大提高了業務的安全性. 👍
這裏記錄一下本人對 ECDHE 的理解和注意要點
ECDHE
橢圓曲線迪菲-赫爾曼金鑰交換 - 維基百科，自由的百科全書 (wikipedia.org)
我們先來說說 ECDH, ECDH(Elliptic Curve Diffie–Hellman key exchange) 是一種密鑰協商協議, 其精髓是通過橢圓曲線算法(ECC), 讓客戶端和服務端不傳輸私鑰(需要傳輸公鑰), 就可以計算出一樣的結果(共有加密資料), 即使協商過程被第三方(中間人)知曉和監聽, 也不會泄露密鑰.
而 ECDHE(ECDH Ephemeral) 與 ECDH 無本質差別, 他們協商的流程一模一樣, 只是ECDHE代表協商出的共有加密資料是臨時的, 就算當前的加密資料泄露, 也不會影響其之前的歷史數據被解密, 這是使用方式決定的, 大白話意思就是, 我們通過 ECDH 生成的共有加密數據有實效性, 會通過邏輯在一段時間或特定事件後重新協商, 而不是隻協商一次, 如果只協商一次, 如果共有加密資料被泄露, 則之前的所有數據都可以解開. 這種共有加密數據資料泄露也不會對歷史數據有影響的特性在密碼學中被稱爲 前向安全性.
橢圓曲線密碼學(ECC)
ECC 是 ECDH 的核心
橢圓曲線密碼學 - 維基百科，自由的百科全書 (wikipedia.org)
JavaScript ECDH Key Exchange Demo (stanford.edu)
橢圓曲線算法(ECC) 是一種基於橢圓曲線數學的公開密鑰加密算法, ECC 相比於 RSA 來講, 有更短的密鑰長度和相同等級的安全性(ECC被廣泛認爲是在給定密鑰長度的情況下，最強大的非對稱算法，因此在對帶寬要求十分緊的連接中會十分有用.)
而且, ECC可以定義羣之間的雙線性映射, 即通過兩個向量空間上的元素, 生成第三個向量空間上的元素的函數. 這使得他可以讓兩對數據通過交換和計算得出相同結果
ECC 算法衍生出了一些加密協議, 常見的有 ECDHE, MQV, ECDSA 等
- ECC 的公鑰其實對應了橢圓曲線數學的 XY 座標, 根據種子隨機生成
- ECC 的私鑰對應了橢圓曲線數學的 a 參數, 與公鑰對應
- ECC 計算出的 share 也是 XY 座標
- ECC 的種子有公開的幾個, 例如
secp128r1/secp256r1/secp192k1等, 兩端的種子需要保持一致.
在線 ECDH 可參照 JavaScript ECDH Key Exchange Demo (stanford.edu)
橢圓曲線數學
橢圓曲線的數學原理在這裏
橢圓曲線 - 維基百科，自由的百科全書 (wikipedia.org)
常言道, 學好數理化, 走遍天下都不怕. 可惜我是宅男, 不愛出門💀
這個原理在我的理解範疇之外了, 如果你對數學有興趣, 可以嘗試瞭解
三者關係
先誕生出的橢圓曲線數學公式, 而後有的基於橢圓曲線數學公式的密碼學算法 ECC, 而ECC 又衍生出一些加密協議和協議, ECDH就是其中一種
破解概率
直接引用 wiki 原文
如果攻擊者擁有大型量子計算機，那麼他可以使用秀爾算法解決離散對數問題，從而破解私鑰和共享祕密。目前的估算認爲：破解256位素數域上的橢圓曲線，需要2330個量子比特與1260億個託佛利門。相比之下，使用秀爾算法破解2048位的RSA則需要4098個量子比特與5.2萬億個託佛利門。因此，橢圓曲線會更先遭到量子計算機的破解。目前還不存在建造如此大型量子計算機的科學技術，因此橢圓曲線密碼學至少在未來十年（或更久）依然是安全的。但是密碼學家已經積極展開了後量子密碼學的研究。其中，超奇異橢圓曲線同源密鑰交換（SIDH）有望取代當前的常規橢圓曲線密鑰交換(ECDH)
ECDH 協商流程
前面說過, ECDHE 和 ECDH 不同是協商出的密鑰有效期, 實際上協商流程是一致的, 所以這裏嚴謹一點, 就叫 ECDH 協商流程
ECDH 本身的協商流程如下圖所示(按照數字編號走流程):
上面說過, ECDH實際上是協商共享加密數據的過程, 難點在 ECC 的本身實現, 而交換的過程很簡單, 互相發送自己生成的公鑰即可, 公鑰其實就是橢圓算法中的計算所需的 X/Y 座標.
安全性
中間人只監聽數據
兩端協商密鑰的過程中, 均未傳輸自己的私鑰.
這樣, 即使有中間人監聽了兩端之間的網絡數據, 也只能獲取到兩端的公鑰, 無法計算出真正的 shareX/shareY , 如圖所示:
中間人監聽並僞造客戶端和服務端
如果中間人能做到, 同時僞造成客戶端和服務端(對於客戶端來講是服務端, 對於服務端來講是客戶端), 那麼ECDH生成的共享加密數據, 客戶端與服務端無法對應
但是細想, 這時候, 雖然客戶端與服務端的共享加密數據不相同, 但是ECDH只是一個協商密鑰的過程, 中間人在此種情況下成功在客戶端與服務端不知情的情況下正常走完了協商流程, 之後的加密數據, 如果使用了這個協商出的加密數據, 就會導致之後的數據被中間人截獲/解析, 並且無感知, 例如:
不過, 這就逃脫了 ECDH 的範疇了, 這是真正需要開發者在業務中考慮的事情.
ECDH在 TLS1.2 中的使用流程
TLS1.2 的詳細立案可看:
RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2 (rfc-editor.org)
在 TLS1.2 協議中, 就使用了 ECDHE 來交換密鑰, 我們來分析一下 TLS1.2 怎麼使用 ECDHE 的:
TLS v1.2 handshake overview | by apoorv munshi | Medium
如文章所述, 在步驟 Server Key Exchange & Server Hello Done 時, 服務端不止返回了自己的 ECC 公鑰, 還使用了 TLS 證書生成時的私鑰對信息進行了簽名(RSA), 而後, 客戶端在接受到信息後, 嘗試使用 TLS 證書中的公鑰對信息進行驗籤, 用來保證數據一定是服務端返回的, 解決中間人篡改問題, 如圖:
業務中使用 ECDHE 進行前後端通信數據加密
我們可以仿造 TLS1.2 協議來打造一個前後端通信加密的流程, 但是需要注意以下幾點:
- ECDH 本身的協商過程是"明文的", 協商出共享加密數據後使用該數據對 body 進行加密傳輸纔是"安全的"
- ECDH 變成 ECDHE 是加了時效性, 因此共享加密數據的淘汰策略很重要
- ECC 生成的公私鑰實際上是 XY 座標, 考慮前端 JS 出問題生成 XY 重複的可能
修改後的密鑰協商流程如下:
![]()
之後的請求, 均使用aesKey1進行aes256cbc加解密通信
![]()
針對問題1, 我們使用混淆生成 key 進行 aes 加密的方式, 對請求進行加密, 提高解密難度
針對問題2, 我們將單次協商的共享密鑰與當前會話和用戶設備綁定, 並對會話進行有效期淘汰管理, 當觸發到淘汰標準時會將服務端密鑰進行刪除, 客戶端需重新協商密鑰纔可重新通信
針對問題3, 我們在前後端加入隨機數生成並於最終的 shareX 混淆, 防止ECC生成公私鑰時因實現問題導致的重複密鑰
