背景：
對稱加密算法都需要一把共享密鑰，但是很多情況下，互聯(lián)網(wǎng)環(huán)境不適合傳輸這把對稱密鑰，有被中間人攔截的風(fēng)險。
為了解決這個問題，我們看看ECDH秘鑰交換算法是怎么做的？

DH、ECDH 和 ECDHE 的關(guān)系

DH、ECDHE不是本文的重點， 知道即可。

Diffie-Hellman密鑰交換算法，簡稱DH，只是一些流程不同，不深究。

ECDH可以拆分為：EC和DH，
EC的含義：

• elliptic curves——橢圓曲線，從名字就能看出，底層原理類似ECC，

DH的含義

• Diffie–Hellman——是兩位數(shù)學(xué)牛人的名稱，他們發(fā)明了這個算法，好像也能代指密鑰交換。

ECDH的定義：

• ECDH全稱是橢圓曲線迪菲-赫爾曼秘鑰交換（Elliptic Curve Diffie–Hellman key Exchange），主要是用來在一個不安全的通道中協(xié)商出一把共享秘鑰，這個共享秘鑰一般作為“對稱加密”的密鑰而被雙方在后續(xù)數(shù)據(jù)傳輸中使用。

我們先來說說 ECDH, 客戶端和服務(wù)端不傳輸私鑰(需要傳輸公鑰), 就可以計算出一樣的結(jié)果(共有加密資料), 即使協(xié)商過程被第三方(中間人)知曉和監(jiān)聽, 也不會泄露密鑰。

而 ECDHE(ECDH Ephemeral) 與 ECDH 無本質(zhì)差別, 他們協(xié)商的流程一模一樣, 只是ECDHE代表協(xié)商出的共有加密資料是臨時的, 就算當(dāng)前的加密資料泄露, 也不會影響其之前的歷史數(shù)據(jù)被解密, 這是使用方式?jīng)Q定的, 大白話意思就是, 我們通過 ECDH 生成的共有加密數(shù)據(jù)有實效性, 會通過邏輯在一段時間或特定事件后重新協(xié)商, 而不是只協(xié)商一次, 如果只協(xié)商一次, 如果共有加密資料被泄露, 則之前的所有數(shù)據(jù)都可以解開。 這種共有加密數(shù)據(jù)資料泄露也不會對歷史數(shù)據(jù)有影響的特性在密碼學(xué)中被稱為 前向安全性。

這種共有加密數(shù)據(jù)資料泄露也不會對歷史數(shù)據(jù)有影響的特性在密碼學(xué)中被稱為 前向安全性——"forward secrecy"。

這個多出來的E的意思是指每次公鑰都隨機(jī)生成。因為像HTTPS里那種是可以從證書文件里取靜態(tài)公鑰的。可以理解ECDHE是ECDH的升級版。

Flow chart

我們可以仿造 TLS1.2 協(xié)議來打造一個前后端通信加密的流程, 但是需要注意以下幾點:

• ECDH 本身的協(xié)商過程是"明文的", 協(xié)商出共享加密數(shù)據(jù)后使用該數(shù)據(jù)對 body 進(jìn)行加密傳輸才是"安全的"；
• ECDH 變成 ECDHE 是加了時效性, 因此共享加密數(shù)據(jù)的淘汰策略很重要；
• ECC 生成的公私鑰實際上是 XY 坐標(biāo), 考慮前端 JS 出問題生成 XY 重復(fù)的可能；

修改后的密鑰協(xié)商流程如下:

之后的請求, 均使用 aesKey1 進(jìn)行 AES256-CBC 加解密通信，

Reference

淺嘗 ECDHE 協(xié)議流程
http://www.rzrgm.cn/chnmig/p/16833780.html

https://cloud.tencent.com/developer/article/1173441