一連接

連接過程參考：
https://blog.csdn.net/iini01/article/details/80147232

二配對

區別於傳統藍牙的配對過程，BLE的配對過程發生在連接過程之後

配對是一個三階段的過程。前兩個階段是必須的，第三階段是可選的。

第一階段：配對特徵交換
第二階段：短期祕鑰（STK）生成
第三階段: 傳輸特定祕鑰分配

STK生成規則

Just work：沒有加密 TK=0x00
passkey entry：密碼輸入如果 passkey 是 ‘019655’ TK的值就是0x00000000000000000000000000004CC7。
將輸入的值作爲一個6位數的十進制，轉換成16字節的十六進制。
OOB：帶外的TK值是一個16字節的隨機數，通過非BLE的方式傳遞給對端。

2.1 第一階段

設備首先在配對特徵交換階段交換IO能力來決定在第二階段使用下面哪種方法：

JustWorks:只工作
PasskeyEntry：輸入密碼
OutOfBand（OOB）:帶外

LE Legacy Pairing - Just Works
Just Works方式不能抵抗竊聽者和中間人攻擊，只有在配對過程時沒有遭受攻擊，後面加密的鏈路的數據傳輸纔是可信的。安全級別很低。

LE Legacy Pairing - Passkey Entry
這種方式通過輸入6位數字的方式來進行配對，生成STK。6位數是隨機產生的在000000到999999之間的數值，這個數值相當於一個TK，比如遠端顯示這個數字，需要在本地端輸入這個數字給本地設備與遠端配對。如輸入019655，那此時的臨時Key–TK是：0x00000000000000000000000000004CC7。

Out of Band 帶外
這種方式是通過BLE之外的，設備上的其他方式來獲取這個OOB data，比如通過IR紅外，或其餘的方式，因此對於藍牙竊聽者/攻擊者而言這個data的傳輸是不可見的了，因此會顯得要安全些。

2.1.1 配對請求的數據格式

1. IO capabilities表明輸入，輸出的能力

輸入是按鍵、鍵盤，輸出是顯示數字用的界面。

0x00 DisplayOnly 只能是顯示000000 ~ 999999的數字
0x01 DisplayYesNo 顯示Yes/No 的按鈕
0x02 KeyboardOnly 只能是輸入000000 ~ 999999的數字
0x03 NoinputNoOutput 沒有輸入也沒有顯示，只能用Just work工作方式
0x04 KeyboardDisplay 能輸入000000 ~ 999999的數字和輸出

2. OOB data flag

0x00 OOB 數據沒有發送
0x01 OOB 數據通過遠端設備發送（如IR）
0x02-0xFF 保留

3. 身份驗證請求

Bonding_Flags b1b0 Bonding Type
- 00 No Bonding
- 01 Bonding
- 10 Reserved
- 11 Reserved
MITM

MITM域設置爲1爲請求MITM（中間人介入）保護，否則設置爲0. 設備將標誌設置爲1爲STK請求認證的安全屬性。
選擇Key生成的方法
如果auth Req中MITM沒有，則說明不需要人蔘與中間，所以IO capabilities會被忽略，只用Just Works就OK了。
如果有OOB data，auth Req將可直接忽略，會直接選擇OOB的方式了。

SC字段是一個1位標誌，設置爲1以請求LE安全連接配對，否則應根據發起方和響應方支持的功能將其設置爲0，可能的結果配對機制爲：如果兩個設備均支持 LE安全連接，使用LE安全連接；否則，請使用LE舊式配對。

Keypress

keypress字段是一個1位標誌，僅在Passkey Entry協議中使用，而在其他協議中將被忽略。當雙方將該字段設置爲1時，應使用SMP配對按鍵通知PDU生成併發送按鍵通知。

4. MaximumEncryptionKeySize

最大祕鑰長度，7到16字節之間

5. InitiatorKeyDistribution

發起者的祕鑰分配，該域表明祕鑰初始化設備請求分配使用。

配對請求命令中的“生成”字段由主機使用，以請求發起者向響應者分發或生成哪些密鑰。

6. ResponderKeyDistribution

響應者的祕鑰分配，該字段表明祕鑰初始化設備請求響應設備來分配祕鑰分配使用。

2.1.2 配對請求實例

1. Code (1 octet)

0x01 Pairing Request

2. IO Capability (1 octet)

0x03 NoInputNoOutput: 用just work 認證方式

3. OOB data

0x00 OOB（out of band）
沒有帶外認證，帶外這種方式是通過BLE之外的，設備上的其他方式來獲取這個OOB data，比如通過IR紅外，或其餘的方式，因此對於藍牙竊聽者/攻擊者而言這個data的傳輸是不可見的了，因此會顯得要安全些。

4. AuthReq (1 octet)

AuthReq字段是一個位字段，指示STK和LTK以及GAP綁定信息的請求安全屬性
0x01 :表示綁定

5. MaxEncKeySize

0x10 表示最大認證key大小是0x10個字節

6. InitiatorKeyDistribution

該域表明祕鑰初始化設備請求分配祕鑰分配使用。

7. ResponderKeyDistribution

001 該字段表明祕鑰初始化設備請求響應設備來分配祕鑰分配使用。

2.1.3 從設備向主設備向發送配對回覆報文

具體字段含義參考配對請求報文。

2.2 第二階段

2.2.1 配對確認

第一階段的配對特徵交換成功之後，用來啓動STK生成。該命令被兩個對等設備使用，來向對等設備發送確認值。初始化設備通過向響應設備發送配對確認命令啓動STK生成。

報文格式

啓動STK的生成，這一部分可簡述爲以下步驟的實現

Initiator生成128-bit隨機數Mrand，並使用這個Mrand結合一些其他的輸入，使用密碼工具箱中c1計算出一個128-bit的Mconfirm值：

Mconfirm = c1(TK, Mrand,
Pairing Request command, Pairing Response command,
initiating device address type, initiating device address,
responding device address type, responding device address)

Responder也生成一個128-bit隨機數Srand，並使用這個Srand結合一些其他的輸入，使用密碼工具箱中c1計算出一個128-bit的Sconfirm值：

Sconfirm = c1(TK, Srand,
Pairing Request command, Pairing Response command,
initiating device address type, initiating device address,
responding device address type, responding device address)

Initiator將其計算的Mconfirm值通過Pairing Confirm包發送給Responder，而Responder也將其計算的Sconfirm值通過Pairing Confirm包發送給Initiator；
Initiator收到Sconfirm後，再將Mrand值通過Pairing Random包發送給Responder；
Responder收到Mrand值後計算它的Mconfirm值，再跟前面那個Initiator送過來的Mconfirm值進行比較，若不同說明配對失敗了。若相同，則Responder也會將它的Srand值通過Pairing Random包發送給Initiator；
而Initiator也會計算收到的Srand值的Sconfirm值，並跟前面那個Responder送過來的Sconfirm值進行比較，若不同說明配對失敗了，若相同，繼續。

報文實例

主設備向從設備發送配對確認報文，從設備也向主設備發送配對確認報文。

2.2.2 隨機配對

該命令用來由初始化和響應設備發送，用來計算在配對確認命令中的確認值的隨機數。

報文數據格式

報文實例

主設備向從設備發送配對隨機值報文，從設備也向主設備發送配對隨機值報文。

2.3 第三階段

2.3.1 傳輸特定的密鑰分發

所有的鍵和值都由主從設備分發。

要分發的密鑰由配對請求和配對響應的密鑰分發參數決定，
配對請求和配對響應來自第一階段配對特徵交換

BLE的SMP的一些Key相關定義

Long Term Key (LTK)：加密鏈路用，128-bit；
Encrypted Diversifier (EDIV)：在LE legacy pairing過程中，用於識別LTK分發，16-bit；
Random Number (Rand)：在LE legacy pairing過程中，用於識別LTK分發，64-bit。
Identity Resolving Key (IRK)：用於生成和解析random address用的，128-bit；
AddrType (1 octet)
如果BD_ADDR是公共設備地址，則AddrType應設置爲0x00。
如果BD_ADDR是靜態隨機設備地址，則AddrType應設置爲0x01。
BD_ADDR（6個八位字節）此字段設置爲分發設備的公共設備地址或靜態隨機地址。
Connection Signature Resolving Key (CSRK)：用於對數據進行簽名已經驗證簽名數據，128-bit；

2.3.2 特定key分發原因

密鑰分發階段的從設備將密鑰發送給主設備，這樣就可以對重新連接進行加密，並解析其隨機地址。或者，主設備可以驗證來自從設備的簽名數據，主設備也可以向從設備提供密鑰，這樣，如果角色互換，可以對重連接進行加密，可以解析主設備的隨機地址，或者從設備可以驗證來自主設備的簽名數據。

三綁定

就是將配對階段產生的一系列key 保持到flash中，以便後續使用。

以上這個過程的報文交互如下圖，

BLE藍牙的連接和配對過程

一連接

二配對