- DH、ECDH 和 ECDHE 的關係
- Flow chart
- Reference
背景：
對稱加解密演算法都需要一把秘鑰，但是很多情況下，網際網路環境不適合傳輸這把對稱密碼，有被中間人攔截的風險。
為了解決這個問題，我們看看ECDH秘鑰交換演算法是怎麼做的？
DH、ECDH 和 ECDHE 的關係
DH、ECDHE不是本文的重點， 知道即可。
Diffie-Hellman金鑰交換演算法，簡稱DH，只是一些流程不同，不深究。
ECDH可以拆分為：EC和DH，
EC的含義：
- elliptic curves——橢圓曲線，從名字就能看出，底層原理類似ECC，
DH的含義
- Diffie–Hellman——是兩位數學牛人的名稱，他們發明了這個演算法，好像也能代指金鑰交換。
ECDH的定義：
- ECDH全稱是橢圓曲線迪菲-赫爾曼秘鑰交換（Elliptic Curve Diffie–Hellman key Exchange），主要是用來在一個不安全的通道中協商出一把共享秘鑰，這個共享秘鑰一般作為“對稱加密”的金鑰而被雙方在後續資料傳輸中使用。
我們先來說說 ECDH, 客戶端和服務端不傳輸私鑰(需要傳輸公鑰), 就可以計算出一樣的結果(共有加密資料), 即使協商過程被第三方(中間人)知曉和監聽, 也不會洩露金鑰。
而 ECDHE(ECDH Ephemeral) 與 ECDH 無本質差別, 他們協商的流程一模一樣, 只是ECDHE代表協商出的共有加密資料是臨時的, 就算當前的加密資料洩露, 也不會影響其之前的歷史資料被解密, 這是使用方式決定的, 大白話意思就是, 我們透過 ECDH 生成的共有加密資料有實效性, 會透過邏輯在一段時間或特定事件後重新協商, 而不是隻協商一次, 如果只協商一次, 如果共有加密資料被洩露, 則之前的所有資料都可以解開。 這種共有加密資料資料洩露也不會對歷史資料有影響的特性在密碼學中被稱為 前向安全性。
這種共有加密資料資料洩露也不會對歷史資料有影響的特性在密碼學中被稱為 前向安全性——"forward secrecy"。
這個多出來的E的意思是指每次公鑰都隨機生成。因為像HTTPS裡那種是可以從證書檔案裡取靜態公鑰的。可以理解ECDHE是ECDH的升級版。
Flow chart
我們可以仿造 TLS1.2 協議來打造一個前後端通訊加密的流程, 但是需要注意以下幾點:
- ECDH 本身的協商過程是"明文的", 協商出共享加密資料後使用該資料對 body 進行加密傳輸才是"安全的"；
- ECDH 變成 ECDHE 是加了時效性, 因此共享加密資料的淘汰策略很重要；
- ECC 生成的公私鑰實際上是 XY 座標, 考慮前端 JS 出問題生成 XY 重複的可能；
修改後的金鑰協商流程如下:
之後的請求, 均使用 aesKey1 進行 AES256-CBC 加解密通訊，
Reference
淺嘗 ECDHE 協議流程
https://www.cnblogs.com/chnmig/p/16833780.html
https://cloud.tencent.com/developer/article/1173441