Diffie-Hellman密鑰交換演算法在移動安全防護實踐

大家好，我是小編

好久不見

最近微信改版

嚇得小編瑟瑟發抖

答應我

不要與我分別！

前言

如今支付方式的演變，從現金、PC端支付再到移動支付，移動互聯網帶來的變革，不斷對改變著人們的生活消費習慣，對通信、社交、娛樂等方面都產生了重大的影響。

類似支付寶、微信支付、甜橙金融翼支付等互聯網金融支付產品上，用戶在享受移動支付快速便捷的同時，也面臨著信息泄露、非法竊取、介面破解等日益嚴重的安全威脅。

引發問題的根源，繞不開的就是密鑰在移動APP運行環境下的安全保護問題。

移動安全密鑰防護方案設計與剖析

現代密碼安全體系是以密鑰安全的安全架構防護，存儲在移動終端上的密鑰，就成為了攻擊者在整個安全體系架構的攻擊破壞最主要的手段。

此問題一造成短板，將會對整個移動安全防護體系建設造成巨大的衝擊和破壞，從而導致企業遭受非法攻擊、批量註冊登錄、信息泄露乃至套利盜刷等安全事件的發生。

於是，提出了基於Cloud Secure Element和Diffie-Hellman密鑰交換演算法的有效結合，解決移動終端安全密鑰保護相關問題。

與傳統的對稱和非對稱密碼演算法相比，以Diffie-Hellman 為代表的公開密鑰密碼算系統不需要額外的分發密鑰通道，在公開加密密鑰的前提下，依舊可以無損害整個系統的安全性。在應對移動安全此領域，密鑰安全保護有其重要的意義。

Diffie-Hellman密鑰交換方案原理

設p是一個大素數，g是有限域GF(p)中的一個生成元，(g,p)=1，且1

用戶 A 選定一個隨機數 nA∈（nA可以認為是A之私鑰）；

用戶A計算YA=gnA(modp)，並將YA傳送給用戶B；

用戶B選定一個隨機數nB∈（nB可以認為是B之私鑰）；

用戶B計算YB=gnB(modp)，並將YB傳送給用戶A；此 時 A 可 以 算 出 (gnB)nA(modp)，B 也 可 以 算 出 (gnA)nB(modp)。由於(gnB)nA(modp)=(gnA)nB(modp)=gnAnB(modp)，因此，A和B就形成了一個公共的密鑰K=gnAnB(modp)。可以用此密鑰進行傳統的加密解密計算，從而達到在不安全的通道上進行保密通訊的目的。顯然，攻擊者可以截獲到 p，g，gnA(modp)，gnB(modp)。因此，如果攻擊者有快速的求解離散對數的演算法，就能從已截獲的信息中求出nA或nB，從而算出gnAnB(modp)。但橢圓曲線上的Diffie—Hellman 密鑰交換協議的安全性是基於橢圓曲線上離散對數問題的難解性，當所選的有限域GF(p)很大時，nA或nB就很難算出，目前還沒有快速的求解離散對數的算。【1】

基於CloudSE密鑰保護技術安全防護

CloudSE（Cloud Secure Element）雲安全元件，相比於傳統的硬U盾、TEE+SE身份認證方案，密鑰及關鍵數據不在單純的依靠移動終端進行存儲，通過雲服務端進行保護，從軟體層面擺脫硬體的限制。大大減低移動終端受到侵害後導致數據泄密，介面破解的風險。

鑒於此理論基礎，移動安全防護可結合Diffie-Hellman公開密鑰演算法機制和CloudSE雲端託管密鑰防護思路，將核心密鑰向後存儲和認證，部分密鑰進行定時的密鑰更換，避免了移動終端因密鑰硬編碼逆向破解的可能性，以及硬體U盾等不夠便捷的支付方式。

跨平台交互實現與示例

Android/iOS 客戶端源碼示例（C語言）

主要函數介紹（基於開源openssl庫）

int DH_generate_key(DH *dh) ：用於生成密鑰信息

int DH_compute_key(unsigned char *key,const BIGNUM *pub_key,DH *dh)：構建本地加密密鑰

伺服器端源碼示例（JAVA）

甜橙金融安全開發建議

避免中間人攻擊。

雖然Diffie—Hellman密鑰交換協議從演算法上是安全的，但在公開的通信信道上，易受中間人攻擊。如下圖所示，該協議的素數p,g, YA和YB是通過網路傳輸的，中間方攻擊者可利用此機會，當做用戶A的服務端，用戶B的客戶端進行中間轉發和消息竊取。

攻擊者C對DH協議演算法進行中間人攻擊示意圖

鑒於此，業內主流的手段有以下幾個方面。基於PKI/CA的簽名認證，互相對發起方的身份進行認證和識別；OTP（One Time Password）安全機制保護，在每次公開密鑰交互的工程中，引入不確定的因素和隨機值，進行二次的介面加固和時間戳，一次一密，避免不必要的重放攻擊嘗試。

跨平台演算法兼容性

在實踐交互過程中，在Android、iOS、Linux三個操作系統下，C和Java所使用的開源庫，官方和各大社區提供的源碼示例，並無法進行跨平台的交互使用。通過源碼定位發現java中生成的加密密鑰長度要小於C語言生成的長度。根源在於java自帶的函數區別於openssl C，會對對稱加密演算法的不同對密鑰進行截取。關鍵代碼如下（以AES為例）

具體規則為（以AES為例）：截取前N個位元組，N取值可為，具體值由P值決定

最終N的取值規則為：

參考文獻

【1】方俊.「一種基於Diffie-Hellman密鑰交換協議的OTP方案」Computer Era No11 2009

本文來自：甜橙安全團隊

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！