1. 前言
注1：此SM是Security Manager的縮寫，非彼SM，大家不要理解歪了！
書接上文，我們在“藍牙協議分析(10)_BLE安全機制之LE Encryption”中介紹了BLE安全機制中的終極武器----數據加密。不過使用這把武器有個前提，那就是雙方要共同擁有一個加密key（LTK，Long Term Key）。這個key至關重要，怎麼生成、怎麼由通信的雙方共享，關係到加密的成敗。因此藍牙協議定義了一系列的複雜機制，用於處理和加密key有關的操作，這就是SM（Security Manager）。
另外，在加密鏈路建立之後，通信的雙方可以在該鏈路上共享其它的key（例如在“藍牙協議分析(9)_BLE安全機制之LL Privacy”中提到的IRK），SM也順便定義了相應的規範。
2. Security Manager介紹
SM在藍牙協議中的位置如下圖：
圖片1 SM_in_BLE_protocol
它的主要目的是爲LE設備（LE only或者BR/EDR/LE）提供建立加密連接所需的key（STK or LTK）。爲了達到這個目的，它定義瞭如下幾類規範：
1）將生成加密key的過程稱爲Pairing（配對），並詳細定義了Pairing的概念、操作步驟、實現細節等。
2）定義一個密碼工具箱（Cryptographic Toolbox），其中包含了配對、加密等過程中所需的各種加密算法。
3）定義一個協議（Security Manager Protocol，簡稱SMP），基於L2CAP連接，實現master和slave之間的配對、密碼傳輸等操作。
3. Pairing（配對）
在SM的規範中，配對是指“Master和Slave通過協商確立用於加（解）密的key的過程”，主要由三個階段組成：
圖片2 LE Pairing Phases
階段1，稱作“Pairing Feature Exchange”，用於交換雙方有關鑑權的需求（authentication requirements），以及雙方具有怎麼的人機交互能力（IO capabilities）。
階段2，通過SMP協議進行實際的配對操作，根據階段1 “Feature Exchange”的結果，有兩種配對方法可選：LE legacy pairing和LE Secure Connections。
階段3是可選的，經過階段1和階段2之後，雙方已經產生了加密key，因而可以建立加密的連接。加密連接建立後，可以互相傳送一些私密的信息，例如Encryption Information、Identity Information、Identity Address Information等。
3.1 Pairing Feature Exchange
配對的過程總是以Pairing Request和Pairing Response的協議交互開始，通過這兩個命令，配對的發起者（Initiator，總是Master）和配對的迴應者（Responder，總是Slave）可以交換足夠的信息，以決定在階段2使用哪種配對方法、哪種鑑權方式、等等，具體包括：
3.1.1 配對方法
Master和Slave有兩種可選的配對方法：LE legacy pairing和LE Secure Connections（具體可參考後面3.2和3.3章節的介紹）。從命名上看，前者是過去的方法，後者是新方法。選擇的依據是：
當Master和Slave都支持LE Secure Connections（新方法）的時候，則使用LE Secure Connections。否則，使用LE legacy pairing。
3.1.2 鑑權方式
所謂的鑑權（Authentication），就是要保證執行某一操作的雙方（或者多方，這裏就是配對的雙方）的身份的合法性，不能出現“上錯花轎嫁對郎”的情況。那怎麼保證呢？從本質上來說就是通過一些額外的信息，告訴對方：現在正在和你配對的是“我”，是那個你正要配對的“我”！說起來挺饒舌，沒關係，看看下面的實現方法就清楚了。
對BLE來說，主要有三類鑑權的方法（其實是兩種），如下：
1）由配對的雙方，在配對過程之外，額外的交互一些信息，並以這些信息爲輸入，進行後續的配對操作。這些額外信息也稱作OOB（out of band），OOB的交互過程稱爲OOB protocol（是一個稍微繁瑣的過程，這裏不在詳細介紹了）。
2）讓“人（human）”參與進來，例如：
手機A向手機B發起配對操作的時候，手機A在界面上顯示一串6位數字的配對碼，並將該配對碼發送給手機B，手機B在界面上顯示同樣的配對碼，並要求用戶確認A和B顯示的配對碼是否相同，如果相同，在B設備上點擊配對即可配對成功（如下如所示）。
圖片3 配對碼
這種需要人蔘與的鑑權方式，在藍牙協議裏面稱作MITM（man-in-the-middle）authentication，不過由於BLE設備的形態千差萬別，硬件配置也各不相同，有些可以輸入可以顯示、有些只可輸入不可顯示、有些只可顯示不可輸入、有些即可輸入也可顯示，因此無法使用統一的方式進行MITM鑑權（例如沒有顯示的設備無法使用上面例子的方式進行鑑權）。爲此Security Manager定義了多種交互方法：
2a）Passkey Entry，通過輸入配對碼的方式鑑權，有兩種操作方法
用戶在兩個設備上輸入相同的6個數字（要求兩個設備都有數字輸入的能力），接下來的配對過程會進行相應的校驗；
一個設備（A）隨機生成並顯示6個數字（要求該設備有顯示能力），用戶記下這個數字，並在另一個設備（B）上輸入。設備B在輸入的同時，會通過SMP協議將輸入的數字同步的傳輸給設備A，設備A會校驗數字是否正確，以達到鑑權的目的。
2b）Numeric Comparison，兩個設備自行協商生成6個數字，並顯示出來（要求兩個設備具有顯示能力），用戶比較後進行確認（一致，或者不一致，要求設備有簡單的yes or no的確認能力）。
2c）Just Work，不需要用戶參與，兩個設備自行協商。
3）不需要鑑權，和2c中的Just work的性質一樣。
3.1.3 IO Capabilities
由3.1.2的介紹可知，Security Manager抽象出來了三種MITM類型的鑑權方法，這三種方法是根據兩個設備的IO能力，在“Pairing Feature Exchange”階段自動選擇的。IO的能力可以歸納爲如下的六種：
NoInputNoOutput
DisplayOnly
NoInputNoOutput1
DisplayYesNo
KeyboardOnly
KeyboardDisplay
具體可參考BT SPEC[3] “BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part H]” “2.3.2 IO Capabilities”中的介紹。
3.1.4 鑑權方法的選擇
在“Pairing Feature Exchange”階段，配對的雙方以下面的原則選擇鑑權方法：
1）如果雙方都支持OOB鑑權，則選擇該方式（優先級最高）。
2）否則，如果雙方都支持MITM鑑權，則根據雙方的IO Capabilities（並結合具體的配對方法），選擇合適的鑑權方式（具體可參考BT SPEC[3] “BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part H]”“2.3.5.1 Selecting Key Generation Method”中的介紹）。
3）否則，使用Just work的方式（不再鑑權）。
3.2 LE legacy pairing
LE legacy pairing的過程比較簡單，總結如下（可以參考下面的流程以輔助理解）：
圖片4 LE legacy pairing過程
1）LE legacy pairing最終生成的是Short Term Key（雙方共享），生成STK之後，參考[1]中的介紹，用STK充當LTK，並將EDIV和Rand設置爲0，去建立加密連接。
2）加密連接建立之後，雙方可以自行生成Long Term Key（以及相應的EDIV和Rand），並通過後續的“Transport Specific Key Distribution”將它們共享給對方，以便後面重新建立加密連接所使用：
master和slave都要生成各自的LTK/EDIV/Rand組合，並共享給對方。因爲加密鏈路的發起者需要知道對方的LTK/EDIV/Rand組合，而Master或者Slave都有可能重新發起連接。
另外我們可以思考一個問題（在[1]中就應該有這個疑問）：爲什麼LE legacy pairing的LTK需要EDIV/Rand信息呢？因爲LTK是各自生成的，不一樣，因而需要一個索引去查找某一個LTK（對比後面介紹的LE Secure Connections，LTK是直接在配對是生成的，因而就不需要這兩個東西）。
3）STK的生成也比較簡單，雙方各提供一個隨機數（MRand和SRand），並以TK爲密碼，執行S1加密算法即可。
4）TK是實在鑑權的過程中得到的，根據在階段一選擇的鑑權方法，TK可以是通過OOB得到，也可以是通過Passkey Entry得到，也可以是0（Just Work）。
LE legacy pairing只能使用OOB、Passkey Entry或者Just Work三種鑑權方法（Numeric Comparison只有在LE Secure Connections時纔會使用）。
3.3 LE Secure Connections Pairing
LE Secure Connections pairing利用了橢圓曲線加密算法（P-256 elliptic curve），簡單說明如下（具體細節可參考看藍牙SPEC[3]，就不在這裏羅列了）：
1）可以使用OOB、Passkey Entry、Just Work以及Numeric Comparison四種鑑權方法。其中Numeric Comparison的流程和Just Work基本一樣。
2）可以直接生成LTK（雙方共享），然後直接使用LTK進行後續的鏈路加密，以及重新連接時的加密。
3.4 Transport Specific Key Distribution
加密鏈路建立之後，通信的雙方就可以傳輸一些比較私密的信息，主要包括：
Encryption Information (Long Term Key)
Master Identification (EDIV, Rand)
Identity Information (Identity Resolving Key)
Identity Address Information (AddrType, BD_ADDR)
Signing Information (Signature Key)
至於這些私密信息要怎麼使用，就不在本文的討論範圍了，後續碰到的時候再介紹。
4. Security Manager Protocol介紹
SMP使用固定的L2CAP channel（CID爲0x0006）傳輸Security相關的命令。它主要從如下的方面定義SM的行爲（比較簡單，不再詳細介紹）：
1）規定L2CAP channel的特性，MTU、QoS等。
2）規定SM命令格式。
3）定義配對相關的命令，包括：
Pairing Request
Pairing Response
Pairing Confirm
Pairing Random
Pairing Failed
Pairing Public Key
Pairing DHKey Check
Keypress Notification
4）定義鑑權、配對、密碼交互等各個過程。
5. 密碼工具箱介紹
爲了執行鑑權、配對等過程，SM定義了一組密碼工具箱，提供了十八般加密算法，由於太專業，就不在這裏介紹了，感興趣的讀者直接去看spec就行了（“BLUETOOTH SPECIFICATION Version 4.2 [Vol 3, Part H] 2.2 CRYPTOGRAPHIC TOOLBOX”）。
6. Security Manager的使用
相信經過本文的介紹，大家對BLE的SM有了一定的瞭解，不過應該會有一個疑問：
這麼複雜的過程，從應用角度該怎麼使用呢？
放心，藍牙協議不會給我們提供這麼簡陋的接口的，參考上面圖片1，SM之上不是還有GAP嗎？對了，真正使用SM功能之前，需要再經過GAP進行一次封裝，具體可參考本站後續的文章。
7. 參考文檔
[1] Core_v4.2.pdf