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] 藍牙協議分析(10)_BLE安全機制之LE Encryption
[2] 藍牙協議分析(9)_BLE安全機制之LL Privacy
[3] Core_v4.2.pdf
原創文章，轉發請注明出處。蝸窩科技，www.wowotech.net。
------------恢復內容開始------------
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] 藍牙協議分析(10)_BLE安全機制之LE Encryption
[2] 藍牙協議分析(9)_BLE安全機制之LL Privacy
[3] Core_v4.2.pdf
原創文章，轉發請注明出處。蝸窩科技，www.wowotech.net。
------------恢復內容結束------------