1. 前言

注1：此SM是Security Manager的縮寫，非彼SM，大家不要理解歪了！

書接上文，我們在中介紹了BLE安全機制中的終極武器----資料加密。不過使用這把武器有個前提，那就是雙方要共同擁有一個加密key（LTK，Long Term Key）。這個key至關重要，怎麼生成、怎麼由通訊的雙方共享，關係到加密的成敗。因此藍芽協議定義了一系列的複雜機制，用於處理和加密key有關的操作，這就是SM（Security Manager）。

另外，在加密鏈路建立之後，通訊的雙方可以在該鏈路上共享其它的key（例如在中提到的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

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

階段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