1. 首頁 > 生活百科 > >

淺嘗 ECDHE 協議流程( 二 )

生活百科


淺嘗 ECDHE 協議流程

文章插圖
但是細想, 這時候, 雖然客戶端與服務端的共享加密數據不相同, 但是ECDH只是一個協商密鑰的過程, 中間人在此種情況下成功在客戶端與服務端不知情的情況下正常走完了協商流程, 之后的加密數據, 如果使用了這個協商出的加密數據, 就會導致之后的數據被中間人截獲/解析, 并且無感知, 例如:
淺嘗 ECDHE 協議流程

文章插圖
不過, 這就逃脫了 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 協議流程

文章插圖
業務中使用 ECDHE 進行前后端通信數據加密我們可以仿造 TLS1.2 協議來打造一個前后端通信加密的流程, 但是需要注意以下幾點:
  • ECDH 本身的協商過程是"明文的", 協商出共享加密數據后使用該數據對 body 進行加密傳輸才是"安全的"
  • ECDH 變成 ECDHE 是加了時效性, 因此共享加密數據的淘汰策略很重要
  • ECC 生成的公私鑰實際上是 XY 坐標, 考慮前端 JS 出問題生成 XY 重復的可能修改后的密鑰協商流程如下:
    淺嘗 ECDHE 協議流程

    文章插圖
針對問題1, 我們使用混淆生成 key 進行 aes 加密的方式, 對請求進行加密, 提高解密難度針對問題2, 我們將單次協商的共享密鑰與當前會話綁定, 并對會話進行有效期淘汰管理針對問題3, 我們在前后端加入隨機數生成并于最終的 shareX 混淆, 防止ECC生成公私鑰時因實現問題導致的重復密鑰

推薦閱讀