一種物聯網M2M通訊密鑰協商方案

一種物聯網M2M通訊密鑰協商方案

引言

在一個物聯網網絡裏，當兩個互不受信的節點之間，想要臨時地安全通訊時，須要安全地創建起一個「弱鏈接」，以用於受限通訊，這種受限訪問，體如今「資源訪問」的受限，和「通訊有效期」的受限。

 

問題的核心在於：互不信任的雙方，如何達成可信。

 

應用到物聯網領域，互不受信的兩個節點之間，如何在一個不安全的鏈路上協商出一個臨時會話密鑰Kses，從而二者能夠創建安全通訊鏈路。在密鑰超出生存期T後，安全鏈路可以中斷。

 

該方案可以應用到如下場景：

1.     網關和節點之間，無需互相保存對方的根密鑰，創建安全的通訊鏈路。

2.     手機和網關之間，無需互相保存對方的根密鑰，創建安全的通訊鏈路。

3.     手機和節點之間，無需互相保存對方的根密鑰，創建安全的通訊鏈路。

4.     任意兩節點之間，無需互相保存對方的根密鑰，創建安全的通訊鏈路。

方案概念

要想讓互不信任的雙方達成可信，一共有三種方案，分別舉幾個生動形象的例子來講明。

l   方案一：提早預置密鑰

A、B、C、D四個地下黨員互不認識，但每一個人都有可能和其餘三我的接頭。一種簡單的思路就是，每一個人跟其餘三我的都由組織提早約定好一個獨立的暗號，見面後對得上暗號，就表明是能信任的人。

 

 

 

這種方案有兩個弊端：

a)       每一個人都要存儲n-1個暗號，整個組織要存儲的暗號量是N*(N-1)，隨着組織的擴大，存儲的暗號量會指數級增加。這就是密碼學中著名的N2密鑰分配問題。

b)      當有第n+1個地下黨加入組織時，該地下黨要與組織裏全部人創建新的暗號。

 

 

 

 

這種方案只適用於節點規模比較小，而且不會頻繁增長節點的場景。不適合大規模物聯網的方案。

 

l   方案二：中間人擔保

仍是上面地下黨的例子，A、B、C、D四個地下黨員互相不認識，可是它們都認識地下黨組織的領導老K，並且對老K絕對信任。當A、B、C、D中某兩個黨員想接頭時，約定先去老K家碰個頭。老K證實雙方都是同一戰壕的兄弟，並告訴兩我的一個臨時的暗號，後續一段時間內兩人就能夠放心的直接通訊了。

 

 

這種方案完美的解決了方案一的兩個問題，可是要依賴一箇中心節點。

 

l   方案三：去中心化的P2P網絡，區塊鏈方案

仍是上面地下黨的例子，A、B、C、D四個地下黨員互相不認識，而且也不存在一個你們都相信的領導老K，整個組織很龐大，並且有可能有內鬼。當A要與B通訊時，A要經過組織內部專門的通訊手段詢問你們，B是不是組織內部的人，當組織內部的大多數人（50%以上）都確認B是組織內部的人，此時A就認爲B能夠值得信任了。反過來講，若是B是內鬼，就必須整個組織的內鬼數量大於真實黨員數量，才能欺騙A。此問題屬於經典的拜占庭將軍問題。

 

 

 

這種方案，是一個徹底去中心化的解決方案，可是必須網絡規模足夠大，使得欺騙成本很高，才能保證安全性。

 

       這三種方案各有優劣，且應用領域不一樣。方案一適合於節點規模小，且節點數量不會頻繁變更的物聯網場景。方案二對任意的物聯網規模都適用，可以作到方案的通用性，並且能達到很是高的安全級別，可是依賴於一個雲端中心節點，對中心節點的可靠性、性能、擴展性都有很高的要求。方案三是一個徹底去中心化的解決方案，可是適用那種大規模網絡的物聯網應用場景。

 

本文的方案，是基於方案二來設計的。

方案設計

首先聲明，該方案借鑑lorawan協議安全機制，以及Kerberos協議的思想，並充分考慮應用到物聯網領域的工程可行性後進行從新設計的。

 

假設咱們有這樣一個物聯網拓撲：物聯網中兩個節點A和B都在生產環節燒寫好獨立的AppKey：KA和KB，以及對應的設備ID：ID_A和ID_B，同時雲端的密鑰管理中心保存了節點A和節點B的AppKey以及對應的ID。

 

 

        節點A但願與節點B安全的通訊，首先A向密鑰管理中心發送密鑰申請消息：，該消息告訴密鑰管理中心，節點A要和節點B創建臨時的受信關係，同時該消息生成了一個隨機nonce rA，用於對密鑰管理中心的應答消息進行驗證。密鑰管理中心經過權限管理中心判斷雙方容許點對點通訊後，首先生成隨機的會話密鑰Kses，並指明該會話密鑰的生存期T（通常是指定具體到某個時間後失效，如2017/10/30 17:00:00）。接下來密鑰管理中心把用A的應用密鑰KA加密生成yA，把用B的應用密鑰KB加密生成yB，並把yA和yB發回給節點A，密鑰管理中心的使命就結束了。

       節點A收到應答消息後，首先對yA用KA解密，獲得，而後判斷若是知足, 則說明該應答必定是密鑰管理中心發回的。經過判斷, 可確認該會話密鑰確實是A和B之間的會話密鑰。接下來A保存了密鑰生存期T。最後，A把ID_A用新申請的會話密鑰Kses加密後生成yAB，並把發送給節點B。

       節點B首先用本身的應用密鑰KB解密yB，獲得 ; 並用新獲得的會話密鑰Kses解密yAB，獲得 。接下來的判斷很重要：若是 ，則能確認yAB和yB的合法性，所以能確認兩件事情：1. yB是密鑰管理中心發送的，裏面包含的A、B之間會話密鑰Kses是合法的；2. 本身確實是跟節點A通訊。最後B保存生存期T。

 

       至此，A、B雙方都安全的獲得了會話密鑰Kses，而且雙方確認了密鑰的有效期T，在Kses到期前，A、B雙方能夠點對點的安全通訊，而不須要中心節點的參與，極大的節省了雲端性能的開銷。

 

重放攻擊 

       想象一下以下場景，若是一個黑客C抓取A和B之間的歷史加密數據，並經過某種途徑，獲得了一個歷史會話密鑰 ，他就能夠假裝成A給B發送歷史yAB和yB，因爲節點資源有限，從工程角度B不可能把歷史上全部的會話密鑰記錄下來，所以B根本沒法知道這是歷史會話密鑰。若是沒有生存期T的存在，B就會認可該密鑰的有效性，從而與C創建了安全鏈接（想象一下若是B是某銀行金庫的大門開關），而有了生存期T，B若是發現密鑰已經失效，則這次重放攻擊不生效（極端狀況下，密鑰可能通訊一次就失效）。

       另外一種重放攻擊場景，是C假裝成密鑰管理中心給A節點應答和，因爲每次A節點會隨機生成nonce rA，所以歷史數據重放攻擊在A節點對nonce的確認環節沒法經過。

   

總結

這個方案的巧妙之處在於：

• 兩個節點之間，只要有一個節點能鏈接雲端便可，不要求雙方都必須鏈接雲端。
• 只有會話創建初期，須要雲端參與協商密鑰，後續通訊不須要雲端參與，大大節省了雲端的性能開銷。
• 由雲端決定密鑰生存期T，而且雙方沒法抵賴。而不是由其中某個節點決定。想象一下，若是生存期由某個節點決定，那麼若是該節點是一個惡意節點，就可能把生存期設置成無限長，使該臨時會話密鑰沒法失效。
• 同時生存期T的存在，也能夠有效的防止重放攻擊。

    該方案能夠做爲一個基礎協議，嵌入到不一樣的產品形態：節點、手機、網關、雲端密鑰管理中心等。不一樣的產品形態，在工程實現時可能有一些不一樣。例如，手機做爲節點A，可能沒有應用密鑰，而是經過用戶帳戶+TLS隧道的機制，跟雲端創建安全隧道，所以密鑰管理中心下發yA時，能夠不用加密，手機端能夠去掉解密環節。

 

    其次，該方案獨立於各類傳輸協議，好比手機和網關之間多是藍牙、Wi-Fi傳輸；手機和雲端多是4G移動網絡；網關和節點之間是lora協議傳輸，都可採用此方案。

 

    另外，根據不一樣應用領域的安全級別不一樣，作方案時，能夠徹底實現、部分實現、不實現該協議。好比防止重放攻擊必須依賴系統時鐘，在安全級別要求較低，系統資源要求較苛刻的解決方案，能夠不實現防止重放攻擊部分（會話密鑰泄漏是一個小几率事件）。

 

做者：趙晗

郵箱：1054236085@qq.com

 

原創方案，禁止轉載