1. 前言
前面文章介紹了兩種BLE的安全機制：白名單[4]和LL privacy[3]。說實話，在這危機四伏的年代，這兩種“捂着臉講話（其它人不知道是誰在講話，因而不能插話、不能假傳聖旨，但講話的內容卻聽得一清二楚）”的方法，實在是小兒科。對於物聯網的應用場景來說，要做到安全，就必須對傳輸的數據進行加密，這就是LE Encryption要完成的事情（當然，只針對面向連接的數據），具體請參考本文的介紹。
2. 基本概念
從字面理解，Encryption是一個名詞，意思是“加密術”，因此LE Encryption就是“BLE所使用的加密技術”的意思。了解加密概念的同學應該都知道，通信過程中的加密無非就是如下簡單的流程：
| 數據發送方在需要發送數據的時候，按照一定的加密算法，將數據加密； 數據接收方在接收到數據的時候，按照等同的解密算法，將數據解密。 |
因此，對LE Encryption來說，需要考慮的事情無非就兩條：
| 1）加密/解密的事情，需要在協議的哪個層次去做？ 2）使用什么樣的加密/解密算法？ |
對問題1來說，很好回答：無論是從安全的角度，還是從通信效率的角度，都應該由鏈路層（LL，Link Layer[1]）在發送/接收數據的時候，完成加密/解密動作（具體可參考）。而問題2呢，到底要使用什么的算法，這是藍牙標准化組織的事情，我們在本文只需要了解最終的結論即可（具體可參考）。
3. packet的加密/解密過程
LE加密/解密的過程如下面圖片1所示：
圖片1 LE加密/解密過程
| Master/Slave的LE Host會保存一個LTK（Long Term Key，至少128bits），對BLE用戶（或者應用）來說，這個Key是所有加密/解密動作源頭； 每當為某個LE連接啟動加密傳輸的時候，Master和Slave的LL會協商生成一個128bits的隨機數SKD（Session Key Diversifier，128bits），並以它為輸入，以LTK為key，通過Encryption Engine加密生成SessionKey； 每當有明文數據包需要發送的時候，需要對明文進行加密。加密的過程，是以明文數據包為輸入，以SessionKey為Key，同樣通過Encryption Engine加密生成密文數據包； 同樣，每當收到密文數據包的時候，需要對密文解密。解密的過程，是以密文數據包為輸入，以SessionKey為Key，同樣通過Encryption Engine解密生成明文數據包。 |
理解了加密/解密的過程之后，問題隨之而來：
1）LTK是怎么來的？
2）SKD是個什么東西？怎么來的？
3）Encryption Engine又什么東西呢？
對於問題1，需要由SMP解答（也就是我們常說的配對過程），具體可參考后續的文章。問題3比較單純，就是一個由Bluetooth specifiction所規定的加密算法，后面會單獨寫一篇文章介紹。而問題2，則涉及到LE Encryption的操作流程，具體可參考后面第4章的介紹。
4. Encryption Procedure
LE Encryption的過程主要由Link Layer控制（具體可參考“BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B] 5.1.3 Encryption Procedure”）：當連接建立之后，Link Layer可以應Host的請求，使能對數據包的Encryption操作，過程如下（具體可參考“BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part D] 6.6 START ENCRYPTION”）：
圖片2 Start Encryption
1）Host A發送LE Start Encryption HCI命令，請求Link Layer啟動加密。該命令的格式如下：
| Command | OCF | Command parameters | Return Parameters |
| HCI_LE_Start_Encryption | 0x0019 | Connection_Handle Random_Number Encrypted_Diversifier Long_Term_Key |
| Connection_Handle，連接句柄； Random_Number和Encrypted_Diversifier分別簡稱為Rand和EDIV（Rand是一個64bits的隨機數，EDIV是一個16bits的Diversifier），它們在LE Legacy Pairing的過程中，用於在多個LTK標識某一個具體的LTK。而在新的LE Secure Connections Pairing過程中，則不再使用（賦值為0即可）。關於LE的配對過程，可參考后面SMP的分析文章，這里不再詳細描述； |
2）LL A收到Host的加密請求之后，會向LL B發送LL_ENC_REQ PDU以請求加密，該PDU的格式為：
| Rand(8 octets) | EDIV(2 octets) | SKDm(8 octets) | IVm(4 octets) |
| Rand和EDIV就是上面的Random_Number和Encrypted_Diversifier； SKDm（session key diversifier ），是一個64bits的隨機數，用於和SKDs一起，生成本次加密的SessionKey； IVm（initialization vector ），一個32bits的隨機數，和IVs一起組成64bits的IV，后面Encryption Engine會使用。 |
3）LL B收到LL_ENC_REQ PDU之后，會向Host B發送LE Long Term Key Request HCI Event，該Event的格式為：
| Event | Event code | Event Parameters |
| LE Long Term Key Request | 0x3E | Subevent_Code Connection_Handle Random_Number Encryption_Diversifier |
| Subevent_Code為0x05； Connection_Handle，連接句柄； Random_Number和Encrypted_Diversifier就是LL_ENC_REQ PDU中的Rand和EDIV，最初是由Host A通過LE Start Encryption命令發送過來的。 |
4）如果Host B能提供LTK，則通過LE Long Term Key Request Reply HCI命令，將LTK提供給LL B，該命令的格式為：
| Command | OCF | Command parameters | Return Parameters |
| HCI_LE_Long_Term_Key_Request_Reply | 0x001A | Connection_Handle Long_Term_Key | status Connection_Handle |
5）LL B收到LTK之后，會向LL A回應一個LL_ENC_ RSP PDU，該PDU的格式為：
| SKDs(8 octets) | IVs(4 octets) |
| SKDs和LL A的SDKm共同組成128bits的SKD； IVs和LL A的IVm共同組成64bits的IV。 |
6）LL A收到LL_ENC_ RSP PDU之后，可以向LL B發送LL_START_ENC_REQ PDU，開啟Encryption，LL B則回應LL_START_ENC_RSP PDU，這兩個PDU均不攜帶任何的參數。
加密start之后，雙方就可以安全的通信了。當然，LE encryption還提供了其它諸如暫停加密（LL_PAUSE_ENC_REQ/LL_PAUSE_ENC_RSP）、重啟加密等過程，比較簡單，這里就不詳細介紹了，具體可參考BLE Spec[2]中的相關描述。
5. 參考文檔
[1] 藍牙協議分析(3)_藍牙低功耗(BLE)協議棧介紹
[2] Core_v4.2.pdf
[3] 藍牙協議分析(9)_BLE安全機制之LL Privacy
[4] 藍牙協議分析(8)_BLE安全機制之白名單
原創文章，轉發請注明出處。蝸窩科技，www.wowotech.net。