端午安康，今天借Jayden這篇文章和大家談一下無線傳輸?shù)男畔踩?#xff0c;該文從加密，認證，以及對應(yīng)的算法優(yōu)劣做了清晰明確的介紹，并在此基礎(chǔ)上對藍牙的配對加密過程進行了分析，是我看到把信息安全和藍牙配對講的很透徹的科普文章，該文也給各位工程師提供了一課信息安全的科普。如何保障無線傳輸中的數(shù)據(jù)安全是一項非常重要的課題，我們要在做工程角度運用各種密碼技術(shù)保障數(shù)據(jù)的安全性。另外非常推薦?結(jié)城浩的《圖解密碼技術(shù)》。

?

網(wǎng)上介紹BLE安全機制的文章大多只關(guān)注業(yè)務(wù)概念，如：配對加密是什么，綁定過程是什么；而忽略了其中涉及到的信息安全知識，如：使用了加密和認證有什么用，不用又會怎么樣。讓新人讀了有種云里霧里，知其然而不知其所以然的感覺。這里結(jié)合涉及到的信息安全知識，換一個角度來認識BLE安全機制。

前言

標題中的“放棄”有點調(diào)侃的意思，是指讀者在讀完之后，可以不依賴別人，靠自己讀藍牙核心規(guī)范加深認識，這樣收獲也會更多，也是這篇博文的目標。

為了易于理解，會對藍牙核心規(guī)范的算法進行裁剪，但是原理是不變的，標準算法應(yīng)參考藍牙核心規(guī)范。

最后，這是博主的一得之見，歡迎各位指正。

目錄

• 密碼技術(shù)初探

  • 對稱密碼

  • diffie-hellman密鑰交換算法

  • 橢圓曲線diffie-hellman密鑰交換算法

  • 消息認證碼

  • 認證加密CCM

  • 信息安全小結(jié)

• ble安全機制初探

  • ble40安全機制

  • ble42安全機制

• 總結(jié)

• 參考資料

密碼技術(shù)初探

在介紹密碼技術(shù)之前，我們先給參與信息交互的對象賦予名稱，方便舉例和記憶。

?

Caption

重要角色一覽

Alice和Bob分別是兩家銀行，Bob銀行通過網(wǎng)絡(luò)向Alice銀行發(fā)送了一條500元的匯款請求：從賬戶B-6789向賬戶A-1234匯款500元。

當(dāng)然，會有人在網(wǎng)絡(luò)中嘗試攻擊銀行間通信，妄想用非法手段牟利，其中就有這樣一個分工明確的組織，由以下成員組成：

• Eve

  • 竊聽不同銀行之間的消息，從中獲取重要信息，如獲知“從賬戶B-6789向賬戶A-1234匯款500元”。

• Mallory：

  • 篡改不同銀行之間的消息，如修改匯款請求為“從賬戶B-6789向賬戶A-1234匯款5000000元”。

  • 偽裝成Bob銀行，以Bob銀行名義發(fā)送一條新的匯款請求給Alice銀行。

從上述例子可知消息面臨的威脅有：竊聽、篡改和偽裝，對應(yīng)的安全特性為：機密性、一致性、是否已認證。

“威脅”和“安全特性”的關(guān)系可以這樣描述：

• 如果消息沒有加密，消息則不具有機密性，無法防止他人竊聽；

• 如果發(fā)送者發(fā)送的消息和接收者的消息是不同的，說明消息被篡改過，不具有一致性；

• 如果沒有對消息進行認證，無法保證消息來自正確發(fā)送者而不是偽裝者。

存在威脅，就會有對應(yīng)的解決方法，下面會針對每個威脅介紹對應(yīng)的密碼技術(shù)。

對稱密碼

算法一般指復(fù)雜步驟，加密算法指的是用明文生成密文的步驟，解密的步驟稱為解密算法，兩者統(tǒng)稱為密碼算法，密碼算法需要用到密鑰。

所謂對稱密碼（symmetric cryptography）技術(shù)，即加密和解密時用的是同一個密鑰，加密和解密的算法一般是公開的，如AES128。對稱密碼應(yīng)用圖

Caption

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?對稱密碼解決的問題

如上圖所示

Bob創(chuàng)建一條匯款請求消息；

用密鑰key對它加密；

將加密后的消息發(fā)給Alice；

Alice收到密文；

Eve竊聽到了加密后的消息，由于沒有密鑰key，無法解讀內(nèi)容；

Alice用密鑰key對消息解密；

Alice獲得一條匯款請求消息。

對稱密碼技術(shù)可以解決竊聽的威脅。

對稱密碼無法解決的問題

對稱密碼技術(shù)可以解決竊聽的威脅，但是有一個前提，就是在這之前發(fā)送者和接收者要有相同的密鑰key，所以一定要先給接收者配送密鑰，有以下幾種方式：

Bob通過網(wǎng)絡(luò)先將key發(fā)送給Alice，但容易被Eve截取到；

Bob乘坐交通工具將密鑰key親手交給Alice，或者其他網(wǎng)絡(luò)以外的方式配送密鑰，這種方式成本高維護麻煩，稱為帶外（Out-Of-Band）配送；

用diffie-hellman密鑰交換算法解決；

用橢圓曲線diffie-hellman密鑰交換算法解決。

?

Diffie-hellman密鑰交換算法

先不管DH密鑰交換算法是什么，我們現(xiàn)在關(guān)注問題是：在Eve竊聽網(wǎng)絡(luò)的情況下，如何解決Bob配送key給Alice的問題？

密碼界的前輩們從數(shù)學(xué)角度上找到了答案：利用這個數(shù)學(xué)難題，Bob和Alice可以在Eve竊聽的情況下，協(xié)商出一個密鑰，而Eve不知道密鑰是什么。

最好解決配送問題的辦法就是不配送，通過協(xié)商獲得相同的密鑰，是不是很神奇，話不多說，我們看看是怎么實現(xiàn)的。

離散對數(shù)問題

背景知識：mod符號表達的意思是求余數(shù)，如表達式5 mod 7的計算思路為：5除以7等于0，余數(shù)為5，所以5 mod 7 = 5。

現(xiàn)有離散對數(shù)問題如下，請問滿足公式的x是多少：

Caption

為了求x，我們可以運用上面提到的背景知識來做計算，像下面這樣依次嘗試一遍，就可以得到x = 9。

Caption

例子的數(shù)字較小，所以很快就找到答案了，當(dāng)數(shù)字很大時，計算x就會變得非常耗時，快速求出離散對數(shù)的算法到現(xiàn)在還沒被發(fā)現(xiàn)，所以可以得到這樣的一個簡單結(jié)論：

Caption

對于上圖公式，已知G、p、Y的時候，很難求出x。

接下來我們看看如何具體利用這個數(shù)學(xué)問題來協(xié)商出密鑰的。

diffie-hellman密鑰交換算法應(yīng)用

在DH中，我們將Y稱為公鑰（public key），將x稱為私鑰（private key），則有以下結(jié)論：已知G、p、公鑰的時候，很難求出私鑰。

Caption

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?DH應(yīng)用圖

如上圖所示

1.Bob和Alice選擇一個公開的G和p，Eve當(dāng)然也知道這個公開的G和p；

2.Bob和Alice分別隨機生成各自的私鑰sb和sa；

3.Bob和Alice根據(jù)G、p以及各自的私鑰，生成公鑰pb和pa；

4.Bob和Alice互發(fā)公鑰pb和pa，Eve竊聽到了pb和pa；

5.Bob和Alice計算出共享密鑰DHkey。

Eve能計算出DHkey嗎？

對比三個角色最后的“已知信息”可知，只要Eve知道任一私鑰（sb或sa），它就能容易算出DHkey，而這時候問題就變成了：Eve在已知G、p、公鑰情況下，是否能求出私鑰，這也就是我們上面提到的離散對數(shù)問題，這是很難做到的。

diffie-hellman密鑰交換算法解決的問題

因為DH密鑰交換算法利用了“離散對數(shù)問題”的復(fù)雜度，所以就算Eve一直竊聽，Bob和Alice也能協(xié)商出一個共享密鑰，而Eve卻因為復(fù)雜的數(shù)學(xué)問題而沒辦法算出共享密鑰，也就解決了對稱密碼中的配送問題。

?

橢圓曲線diffie-hellman密鑰交換算法

DH是利用了“離散對數(shù)問題”的復(fù)雜度來實現(xiàn)密鑰的安全交換的，如果將“離散對數(shù)問題”改為“橢圓曲線上的離散對數(shù)問題”，這樣的算法就叫橢圓曲線diffie-hellman密鑰交換（ECDH）。

兩者密鑰交換總體流程相同，只是利用的數(shù)學(xué)問題不同而已，ECDH能夠用較短的密鑰長度實現(xiàn)較高的安全性。

橢圓曲線diffie-hellman密鑰交換算法應(yīng)用

ECDH中的數(shù)學(xué)問題可以這樣簡單定義：

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Y = x * G

已知橢圓曲線上的點Y、基點G的時候，很難求出x。其中算術(shù)符號*表示的不是普通的乘法，而是一種在橢圓曲線上的特殊算法。

在ECDH中，我們稱Y為公鑰（public key），x為私鑰（private key）。

Caption

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ECDH應(yīng)用圖

如上圖所示

Bob和Alice選擇一條密碼學(xué)家推薦的橢圓曲線，選擇曲線上的一個基點G；

Bob和Alice分別隨機生成各自的私鑰sb和sa；

Bob和Alice根據(jù)G以及各自的私鑰，生成公鑰pb和pa；

Bob和Alice互發(fā)公鑰pb和pa，Eve竊聽到了pb和pa；

Bob和Alice計算出共享密鑰DHkey。

橢圓曲線diffie-hellman密鑰交換算法無法解決的問題

DH和ECDH都能解決密鑰配送問題，結(jié)合對稱密碼技術(shù)，就能保證消息的機密性，防止被竊聽了，但是對于篡改和偽裝的攻擊，卻無能為力。為了解決剩下這兩個威脅，就要靠其他技術(shù)手段了。

Caption

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 篡改示意圖

如上圖所示，Mallory不需要知道密文是什么意思，但是他可以修改密文，導(dǎo)致Alice解密出預(yù)期以外的內(nèi)容。偽裝示意圖

?

Caption

如上圖所示，Mallory夾在Bob和Alice之間并偽裝他們。對于Mallory來說，DHkey是赤裸裸的，所以Bob和Alice互發(fā)的消息是沒有機密性的，這種攻擊也稱為中間人攻擊（MITM）。

消息認證碼

消息認證碼（MAC）技術(shù)是檢查信息一致性并進行認證的技術(shù)，發(fā)送者通過MAC算法可以輸出一個MIC值，接收者通過校驗MIC值不僅可以判斷消息一致性，還能判斷消息是否來自正確的發(fā)送者。

?

Caption

MAC技術(shù)有以下幾種重要性質(zhì)：

• 正向快速：給定明文、MAC算法和密鑰key，在有限時間和有限資源內(nèi)能計算出MIC。

• 逆向困難：給定MIC、MAC算法和明文，在有限時間內(nèi)很難（基本不可能）逆推出密鑰。

• 輸入敏感：原始輸入信息修改一點信息，產(chǎn)生的MIC看起來應(yīng)該都有很大不同。

• 沖突避免：很難找到兩段內(nèi)容不同的明文，使得它們的MIC一致（發(fā)生沖突）。即對于任意兩個不同的數(shù)據(jù)塊，其MIC相同的可能性極小；對于一個給定的數(shù)據(jù)塊，找到和它MIC相同的數(shù)據(jù)塊極為困難。

MAC技術(shù)與對稱加密技術(shù)有一個顯著差異：加密解密是雙向的，可以互相推導(dǎo)，而認證只能單向；加密是為了解密，MAC設(shè)計是無法解。

消息認證碼解決的問題

消息經(jīng)過CMAC算法之后，為何Mallory無法篡改消息和偽裝呢？

Caption

?

消息一致性檢查和認證示意圖

• Mallory如果想篡改明文，那就同時也要篡改MIC，否則無法通過Alice的校驗，但是應(yīng)該將MIC改成多少呢？因為Malloyr沒有共享密鑰，所以他也不知道MIC應(yīng)該是什么。如果想篡改MIC，那就同時也要篡改明文才能通過Alice的校驗，由于MAC算法的逆向困難性質(zhì)，Mallory不知道明文應(yīng)該是什么。

• Bob用CMAC算法認證一條消息并發(fā)給Alice，并要求Alice也用CMAC算法認證并返回一條消息給Bob。若Mallory偽裝成Alice，由于沒有認證密鑰，無法返回通過Bob校驗的消息。

消息認證碼無法解決的問題

沒錯，要使用MAC技術(shù)，首先要有相同的認證密鑰，又回到了之前的密鑰配送問題，具體這里采用哪種方式解決配送密鑰問題，視實際情況而定。

消息認證碼攻擊方式

對于MAC算法來說，應(yīng)保證不能根據(jù)MIC和明文推測出通信雙方所使用的密鑰。但實際上用窮舉法是可以推測出來的，如果使用密碼學(xué)安全的、高強度的偽隨機數(shù)生成器生成密鑰，就會使得破解時間需要很長以至在現(xiàn)實中幾乎不可能破解。而如果密鑰是人為選定的，就會大大增加被推測出來的風(fēng)險。

?

認證加密CCM

其實上文一直在有意無意的強調(diào)一個事情，那就是加密和認證是獨立的兩個概念。加密能防止竊聽，認證能防止篡改和偽裝。前輩們用一種密碼技術(shù)將兩者融合起來——CCM（Counter with CBC-MAC）。

通過查閱資料，以我的戰(zhàn)五渣水平只能理解到這一程度：

• 發(fā)送方先對明文使用MAC技術(shù)，然后對稱加密成密文；

• 接收方先用對稱加密技術(shù)解密密文，然后用MAC技術(shù)校驗明文；

• 發(fā)送方和接收方需要至少一個共享隨機數(shù)和一個共享密鑰，隨機數(shù)可以公開，密鑰不可以公開。

  Caption

?

個人猜測CCM應(yīng)用示意圖

上圖只是個人猜測的示意圖，有可能是不對的，因為不是術(shù)業(yè)專攻方向，沒有深入研究，秉著求真精神，覺得應(yīng)該提醒大家，避免誤導(dǎo)。

放上圖的目的是：加密和認證可以做在一個算法中，而且BLE就是這么用的。

?

信息安全小結(jié)

?

威脅、安全特性、密碼技術(shù)關(guān)系圖

Caption

總結(jié)：

• 為了解決竊聽問題，采用對稱密碼技術(shù)；

• 為了解決對稱密碼技術(shù)的加密密鑰配送問題，采用配送密鑰技術(shù)；

• 為了解決篡改問題，采用消息認證碼技術(shù)；

• 為了解決偽裝問題，采用消息認證碼技術(shù)；

• 為了解決消息認證碼技術(shù)的認證密鑰配送問題，采用配送密鑰技術(shù)。

?

Tips：無論消息認證碼技術(shù)還是對稱密碼技術(shù)，都需要用到配送密鑰技術(shù)，而不同的配送密鑰技術(shù)本身，也會涉及到認證強度的問題。比如希望用ECDH來解決消息認證碼的認證密鑰配送問題，但是ECDH本身認證強度為零，所以它也需要消息認證碼技術(shù)來證明ECDH過程中沒有出現(xiàn)篡改或者偽裝攻擊，即又要使用消息認證碼技術(shù)，導(dǎo)致進入了死循環(huán)。所以需要選擇合適的密鑰配送技術(shù)，常見的有：郵箱驗證碼、手機短信驗證碼、NFC、目測法等。

?

ble安全機制初探

在介紹ble安全機制之前，我們先給參與信息交互的對象賦予名稱，方便舉例和記憶。

ble重要角色一覽

?

Caption

?

背景知識：簡單來說ble設(shè)備可分為兩種角色，一種是主機角色（master），另一種是從機角色（slave），有以下幾種差異：

?

ble各個狀態(tài)示意圖

Caption

建立連接前

• 主機能進入掃描狀態(tài)、發(fā)起連接狀態(tài)，不能進入廣播狀態(tài)；

• 從機能進入廣播狀態(tài)，不能進入掃描狀態(tài)和發(fā)起連接狀態(tài)；

• 一定是由主機發(fā)起連接，從機只能被連接。

建立連接后

• 一定是由主機發(fā)起配對，但是從機能夠請求主機發(fā)起配對；

• 廣播狀態(tài)：設(shè)備正在往空中發(fā)送廣播包，誰都可以收得到；

• 掃描狀態(tài)：設(shè)備正在接收空中的廣播包，看看誰在發(fā)，發(fā)什么；

• 發(fā)起連接狀態(tài)：設(shè)備指定與另外一個設(shè)備發(fā)起連接；

• 明文數(shù)傳階段：兩個已連接設(shè)備之間，用明文傳送數(shù)據(jù)包；

• 配對階段：兩個已連接設(shè)備之間，運用密碼技術(shù)生成各種安全強度的密鑰；

• 加密過程：兩個已連接設(shè)備之間，使用配對階段輸出的密鑰，或者綁定階段提供的密鑰，衍生出最終用于加密底層數(shù)據(jù)包的密鑰；

• 密文數(shù)傳階段：兩個已連接設(shè)備之間，用密文傳送數(shù)據(jù)包；

• 綁定階段：用“綁定”這個詞特定描述配對階段中的第三階段，該階段交換綁定信息，有了綁定信息下次需要密文數(shù)傳可以跳過配對階段。

除了展示兩種角色的異同，我覺得有必要通過上圖澄清幾個概念，加深大家的理解：

復(fù)雜密碼技術(shù)是運用在已連接之后的配對階段，所以不存在配對失敗，導(dǎo)致ble無法正常建立連接，至多是配對失敗，導(dǎo)致連接斷開。

連接后，不一定要啟動配對，如果明文數(shù)傳已經(jīng)滿足應(yīng)用要求，就沒必要啟動配對了。

?

ble4.0 安全機制

從用戶角度提出問題：我現(xiàn)在對密碼技術(shù)有初步了解了，也知道ble安全機制的一些背景知識，評估下來連接之后的明文數(shù)傳風(fēng)險太大，我要用到密文數(shù)傳，ble提供什么樣的解決方案呢？

ble4.0安全機制簡單示意圖

上圖是ble4.0安全機制簡單示意圖，是上一節(jié)“建立連接后”的細節(jié)展開，觀察方式從上到下為角色的時間軸，從左到右分別是不同的角色，空白地方的文本為傳遞的數(shù)據(jù)，虛線為可選項，雙斜杠為不展開討論的內(nèi)容。

對于密文數(shù)傳，ble提供解決方案分四種情況：

首次連接無綁定

• 首次連接，配對輸出臨時密鑰（STK），加密過程用STK衍生出會話密鑰（sessionKey）和隨機數(shù)（IV）用于CCM認證加密，后面都是密文數(shù)傳。

首次連接有綁定

• 首次連接，配對輸出臨時密鑰（STK），加密過程用STK衍生出會話密鑰（sessionKey）和隨機數(shù)（IV）用于CCM認證加密，后面都是密文數(shù)傳，進入綁定階段，從機將長期密鑰（LTK）發(fā)送給主機保存。

第二次連接且首次連接無綁定

• 第二次連接，配對輸出臨時密鑰（STK），加密過程用STK衍生出會話密鑰（sessionKey）和隨機數(shù)（IV）用于CCM認證加密，后面都是密文數(shù)傳。

第二次連接且首次連接有綁定

• 第二次連接，跳過配對階段，加密過程使用之前綁定的LTK衍生出會話密鑰（sessionKey）和隨機數(shù)（IV）用于CCM認證加密，后面都是密文數(shù)傳。

由下往上讀圖，回答用戶提出的問題：

ble4.0選擇CCM給明文數(shù)據(jù)認證加密，想要使用CCM，就需要一個密鑰和一個隨機數(shù)用于CCM認證加密，所以ble有一個“加密過程”負責(zé)輸出一個密鑰（sessionKey）和一個隨機數(shù)（IV），而加密過程又需要一個密鑰來產(chǎn)生sessionKey，所以ble有一個“配對階段”來輸出一個臨時密鑰（STK）給加密過程，或者在綁定階段輸出一個長期密鑰（LTK）給加密過程下一次連接時候使用。

TK配對碼的生成和配送

ble4.0的TK配對碼生成和配送方式有多種，常用的兩種TK配對碼的生成和配送方式是：JustWorks和Passkey，他們有以下差異：

JustWorks模式時，生成的TK是000000，因為這是公開的，沒有配送的意義，配送目的是為了防止通信雙方以外的第三方獲得密鑰，由于現(xiàn)在認證碼是公開的，就沒配送的意義了，而且由于認證碼泄露，這種模式不能提供篡改和偽裝保護。

Passkey模式時，TK的生成方式和配送方式如下：通信其中一方如Alice隨機生成TK為142536，通過顯示屏/短信/NFC等藍牙以外的輸出數(shù)據(jù)的方式，將配對碼告知給Bob’s User，Bob’s User通過鍵盤往Bob設(shè)備輸入142536，使得Bob和Alice擁有一個共享認證密鑰，而針對藍牙基帶攻擊的第三方Mallory不知道，從而提供篡改和偽裝保護。

下面來看一下圖，Passkey模式是怎么做到認證保護的。

?

Caption

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 認證保護示意圖

?

通過正常認證過程，可以發(fā)現(xiàn)Bob和Alice只在空中交互了兩次，所以Mallory的攻擊時機有兩個，第一個是Bob和Alice交換MIC的時刻，另一個是在Bob和Alice交換明文的時刻。

分兩種攻擊行為

篡改MIC或者明文其中一項，屬于篡改攻擊。

• 如果篡改MIC，那就是在未知明文和TK的情況下，憑空捏造一個EMIC，而且這個EMIC還要能夠通過后續(xù)校驗，這個幾乎不可能。MIC是果，明文和TK是因，因果倒置不可能吧。

• 如果篡改明文，那就是給定MIC，基于MAC算法且未知認證密鑰TK的情況下，推導(dǎo)出另一份明文，根據(jù)MAC算法性質(zhì)，這個是很難做到的。

同時篡改MIC和明文，屬于偽裝攻擊，也叫MITM攻擊。

• 因為偽造認證碼EMIC和偽造明文Erand是Mallory提供的，計算過程可能是EMIC = MAC(EK, Erand)，而真實配對碼TK和偽造配對碼EKEY只有百萬分之一的幾率是相同的，所以看作是不相同的，也即EK != TK，根據(jù)MAC的輸入敏感性質(zhì)，EMIC != MAC(TK, Erand)，最終認證失敗。

?

ble4.0真的足夠安全嗎？

我們先列出ble4.0安全機制各個密鑰的安全依賴關(guān)系：

CCM -> sessionKey -> STK(LTK) -> TK

可以看到，最終的源頭是TK認證碼，只有保證TK足夠安全，密文才能保證安全，也就是說不能讓非法分子獲得TK，否則他們就能夠?qū)⒚芪慕饷芰恕?/p>

一般我們依靠MAC算法本身的性質(zhì)，可以保證認證密鑰不被推算出來，但是但是這些性質(zhì)的前提是：認證密鑰是使用密碼學(xué)安全的、高強度的偽隨機數(shù)生成器生成的，而且這些密鑰位數(shù)很多，以至于無法窮舉。

而實際TK的取值是000000~999999，最多只有100萬種可能性，先抓取配對階段（phase2.2）中用到的明文、MIC，再通過窮舉的方式，就可以推算出TK了。

我們分析一下，如果在整個安全機制過程中，一直存在竊聽者Eve，那么我們會面臨什么威脅。

Tips：在這里也順帶分析靜態(tài)配對碼和動態(tài)配對碼的區(qū)別，靜態(tài)配對碼是指每次輸入都是固定的TK值，動態(tài)配對碼是指每次輸入都是動態(tài)產(chǎn)生的TK值，其實核心規(guī)范里面沒有提過靜態(tài)配對碼，但是很多人會希望有如下功能：在一個設(shè)備預(yù)設(shè)一個配對碼為123456，然后配對階段時另一個設(shè)備輸入配對碼123456則通過認證，否則不通過，其實對于ble來說，由于TK可以被破解，所以靜態(tài)配對碼沒有起到安全保護作用。

• 如果是靜態(tài)配對碼，Eve推算出首次連接TK，從而推算出STK，從而推算出sessionKey，從而破解CCM，從而竊取綁定過程中的LTK。

• Bob和Alice首次連接，因TK和STK被破解，所有階段被破解，可任意竊聽和篡改；

• Bob和Alice第二次連接，因LTK被竊取，所有階段被破解，可任意竊聽和篡改；

• 偽裝Bob或者Alice與對方首次連接，因為TK是靜態(tài)配對碼，通過認證，偽裝成功。

• 如果是動態(tài)配對碼，Eve推算出首次連接TK，從而推算出STK，從而推算出sessionKey，從而破解CCM，從而竊取綁定過程中的LTK。

• Bob和Alice首次連接，因TK和STK被破解，所有階段被破解，可任意竊聽和篡改；

• Bob和Alice第二次連接，因LTK被竊取，所有階段被破解，可任意竊聽和篡改；

• 偽裝Bob或者Alice與對方首次連接，因為TK是動態(tài)配對碼，之前破解的TK用不上，無法通過認證，偽裝失敗。

總結(jié)出幾個觀點：

因為“加密”都依賴于認證碼TK，而TK容易被窮舉破解，加密則形同虛設(shè)。

上面描述的威脅，首先是竊聽成功，才能篡改成功，問題是出在了竊聽上。正常情況下對于密文的處理，CCM需要先解密，后認證。如果Eve沒有竊聽成功，亂篡改Bob發(fā)出的CCM認證加密過的密文，那么Alice解密出來的數(shù)據(jù)幾乎不可能通過后續(xù)認證的。正是因為Eve竊聽成功，知道篡改哪部分內(nèi)容，所以才會造成威脅。解決竊聽問題，就能同時解決篡改問題了。

TK是不安全的，以至于如果使用靜態(tài)配對碼而不是動態(tài)配對碼，就無法解決偽裝問題，如果認證碼不像TK那樣范圍窄，靜態(tài)配對碼技術(shù)本身也沒什么問題，但是最好還是定期更新。

上面總結(jié)的也是ble4.2安全機制里面做的一部分改善，比如增加破解TK的難度，引入ECDH解決竊聽問題。

?

ble4.2 安全機制

上一節(jié)，我們分析了ble4.0的安全“漏洞”， 接下來簡單說一下ble4.2作出的應(yīng)對措施。

• 無法改變的前提：

• 配對碼是6個字節(jié)。

• 可能的攻擊方式：

• Eve竊聽整個過程，從而破解TK，下一次可以偽裝Bob和Alice主動發(fā)起連接認證。

• Eve竊聽整個過程，從而破解TK，從而得到STK，然后竊取LTK。

• Mallory發(fā)起MITM攻擊，即使攻擊失敗，包含整個TK信息的MAC和MIC會被Mallory獲得。（雖然我不知道有什么用）

• 提出對應(yīng)解決的方案：

• 動態(tài)認證碼；

• ECDH保證機密性；

• 將TK拆成20bit，每次認證一個bit，攻擊失敗只會暴露1個bit，不會暴露整個TK。

BLE4.2與BLE4.0的安全機制區(qū)別主要體現(xiàn)在“配對階段”的phase2，在這個階段引入了ECDH，下面展開passkey模式的phase2（包括phase2.1~2.3）。

?

Caption

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?BLE4.2 phase2示意圖

?

在“Authentication Stage1”過程，可以發(fā)現(xiàn)Bob和Alice只在空中交互了三次，所以Mallory的攻擊時機有三個：

交換公鑰的時刻

交換MIC的時刻

交換明文的時刻。

后兩個攻擊方式，在BLE4.0已經(jīng)分析過了，至于第一個攻擊時機，因為公鑰是也是MAC算法里面的一個參數(shù)，所以它也不能被隨意篡改，如果改了后面的Ea和Eb校驗就不通過了，即給ECDH也提供了MITM保護。

Tips：這里之所以可以提供MITM保護的實質(zhì)是人的參與，通過觀察的方法獲得配對碼，繞開了藍牙空中傳輸來獲得配對碼，從而不會受到第三者攻擊。

對比BLE4.2和BLE4.0的主要區(qū)別：

• BLE4.2沒有STK，在配對過程直接生成LTK，因為LTK在配對階段就已經(jīng)強制生成了，加密過程直接使用LTK，BLE4.2的綁定階段(phase3)不會發(fā)送LTK。

• LTK是DHkey衍生出來的，DHkey是第三方無法竊聽也無法破解出來的，所以可以保證后面用CCM加密后數(shù)據(jù)的機密性。

BLE4.2完美解決了BLE4.0的安全漏洞。

?

總結(jié)

文章提到的只是BLE常見的一些概念，其他如：簽名（Signed）、授權(quán)（Authorization）之類都沒有提及，有興趣的讀者可以去核心規(guī)范探索一番。

參考資料里面有許多優(yōu)秀的書籍和文章，比如密碼技術(shù)相關(guān)知識我是從《圖解密碼技術(shù)》獲知的，關(guān)于具體的實戰(zhàn)抓包分析，吹爆“BLE配對過程詳解”這篇文章。

最后最后，感謝您閱讀到最后，這是對我最大的鼓勵，也希望這篇博文能讓您有一點點的收獲。

?

參考資料

• 《圖解密碼技術(shù)》

• BLE配對過程詳解

• BLE核心規(guī)范

• Hash算法總結(jié)

• 窮舉法破解BLE的TK值

?

本文作者：?Jayden Huang

本文鏈接：?https://jaydenh215.github.io/2019/05/14/BLE安全機制從入門到放棄/

總結(jié)

以上是生活随笔為你收集整理的BLE安全机制从入门到放弃的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。