轉自 http://www.sunyouqun.com/2017/04/understand-ble-5-stack-security-manager-layer/

---

安全管理（Security Manager）定義了裝置間的配對過程。

配對過程包括了配對資訊交換、生成金鑰和交換金鑰三個步驟。具有不同的輸入輸出能力的裝置將採用不同的配對方式，兩個裝置完成配對將加密連線，產生LTK、IRK、CSRK等金鑰，這些金鑰將支援加密、隱私、簽名等安全特性。

安全管理協議定義了配對相關的資料結構。

安全管理資料都通過L2CAP的安全管理通道傳輸，安全管理協議通過GAP層暴露使用者介面，由使用者設定裝置的輸入輸出能力和配對引數。

1. 配對概述

BLE 4.2協議新增了一種配對方法，稱為“LE安全連線配對”，新的配對方法增加了安全性，為了與BLE 4.1及以前的配對方法做區別，之前的配對方法統稱為“傳統配對”。

傳統配對和LE安全連線配對過程基本一致，都分為三個步驟，僅第二步驟生成金鑰上有所不同。

三個步驟為：

1. 交換配對資訊，確定配對模式
2. 執行配對模式，生成金鑰
3. 分發金鑰，儲存金鑰

三個步驟具有明確的時序關係，並且前一個步驟將顯著影響下一個步驟，如下所示：

兩端裝置先建立連線，然後才能進行配對操作。配對無需在連線後立即執行，可以在任何需要時候進行。

2. 配對資訊

配對資訊包括：

• 認證需求
• IO 能力
• OOB
• 金鑰長度
• 是否繫結

2.1 安全特性

安全特性取決於裝置的認證需求，可選的安全特性如下：

安全特性	MITM保護	所屬配對方法
LE Secure Connections pairing	Yes	LE安全連線配對
Authenticated MITM protection	Yes	傳統配對
Unauthenticated no MITM protection	No	傳統配對
No security requirements	No	傳統配對

MITM（Man in the Middle）指中間人攻擊，假如第三方裝置攻破了BLE連線，A裝置傳送的訊息被C裝置接收，C裝置再轉發給B裝置，A與B裝置相互以為建立了連線，而實際上所有的資料通訊都經過了C裝置轉發。

前兩種安全特性可以實現MITM保護，後兩種則無法防護MITM攻擊。

四種安全等級從上至下安全性依次降低。

安全特性資訊會持久儲存在裝置的安全資料庫中。

2.2 IO能力

一個裝置具有的輸入輸出能力分為以下幾種情況：

輸入能力	描述	輸出能力	描述
No input	無輸入	No ouput	無輸出
Yes/No	僅能輸入是或否	Numeric output	能顯示數字
Keyboard	輸入數字以及確認

不同的輸入輸出能力，將組合出不同的IO能力，如下：

	No output	Numeric output
No input	NoInputNoOutput	DisplayOnly
Yes/No	NoInputNoOutput	DisplayYesNo
Keyboard	KeyboardOnly	KeyboardDisplay

2.3 OOB能力

OOB（Out of Band）指利用NFC或Wifi等非BLE通訊方式傳遞金鑰，它要求裝置具有OOB介面能力。

傳統配對方式中，要求兩端裝置都設定了OOB標誌位，在LE安全連線配對方式中，只需一個裝置設定了OOB標誌位即可。

2.4 金鑰長度

金鑰長度決定了加密強度，越長的金鑰其加密強度越高，但加解密所消耗資源和時間也越多。

金鑰長度有效值為：7-16位元組。

當兩端裝置的金鑰長度值不同，取較小值為有效值。

3. 配對模式

可選的配對模式包括：

• Just Works
• Numeric Comparison
• Passkey Entry
• Out Of Band (OOB)

3.1 選擇模式

如果兩端裝置均選擇No-MITM protection安全特性，則使用Just Works配對模式；如果兩端裝置（對於LE安全連線配對，僅需要一個裝置）均選擇OOB，則使用OOB配對模式；否則根據兩端裝置的IO能力選擇配對模式。

兩端裝置的IO能力中，如果有一端裝置是NoInputNoOutput，則只能使用Just Works配對方式，其他的IO能力組合所對應的配對方式如下：

	DisplayOnly	DisplayYesNo	KeyboardOnly	KeyboardDisplay
DisplayOnly	Just Works	Just Works	Passkey Entry	Passkey Entry
DisplayYesNo	Just Works	Just Works, Numeric Comparison	Passkey Entry	Passkey Entry, Numeric Comparison
KeyboardOnly	Passkey Entry	Passkey Entry	Passkey Entry	Passkey Entry
KeyboardDisplay	Passkey Entry	Just Works, Numeric Comparison	Passkey Entry	Passkey Entry, Numeric Comparison

如果採用了Just Works方式，一定是未認證的，Passkey Entry和Numeric Comparison方式則是認證的。

3.2 Just Works

Just Works配對模式不能夠防護竊聽和MITM威脅。如果裝置的配對過程不被竊聽，配對結束後連線被加密並且保證安全。

所以Just Works雖然不如其他配對方式安全，仍然比不配對的連線要安全。

Just Works通常用於一端裝置完全沒有輸入輸出能力的場景，所以它將臨時金鑰TK設定為固定值0，這樣兩端裝置可以根據這個TK值進行後續的加密操作。

3.3 Passkey Entry

Passkey Entry配對模式可以防護MITM威脅，有限的防護竊聽。如果裝置的配對過程不被竊聽，配對結束後連線被加密並且保證安全。

Passkey Entry方法在一端裝置上顯示一個隨機的6位十進位制數作為密碼，另一端裝置輸入該密碼。passkey作為TK的初值進行後續加密運算，進而可以通過比較加密運算的中間值來判斷輸入的密碼與顯示的密碼是否一致。比如passkey=001024(400h)，則TK=0x00000000000000000000000000000400。

3.4 OOB

OOB（Out of Band）配對模式使用非BLE協議傳輸TK。使用者通過鍵盤輸入Passkey Entry，也屬於一種OOB傳輸TK。

OOB傳輸通道的安全性決定了配對過程的安全性。

3.5 Numeric Comparison

數值比較僅能用於LE安全連線配對方法，它能夠防護MITM和竊聽威脅。

數值比較配對模式在兩端裝置分別顯示一串數字，使用者比較數字是否相等並通過輸入Yes/No來確認，從而實現認證。

這種模式僅需要兩個按鍵即可完成輸入，適合用在小型裝置上。

3.6 安全性

BLE通訊面臨的外部威脅有兩類：被動威脅和主動威脅。

被動威脅指第三方裝置監聽配對過程中的金鑰資料，有了金鑰即可解密後續的連線資料。

主動威脅指MITM，通過偽造身份參與到通訊連線中。

一旦BLE的連線經過了認證，即可抵擋MITM威脅，經過認證的裝置，就意味著對端裝置不是一個偽造偷聽裝置。

傳統的配對方法使用臨時金鑰TK作為加密運算的初值，而交換TK時可以被竊聽裝置獲取，從而破解後續的加密措施。

不同的配對方法，其安全防護能力如下：

安全性	傳統配對	LE安全連線配對
MITM防護	Passkey Entry， OOB	Numeric Comparison， Passkey Entry， OOB
竊聽防護	OOB	全部

4. 生成金鑰

4.1 傳統配對

傳統配對可以使用Just Works，Passkey Entry和OOB三種演算法，配對成功後生成短期金鑰STK（Short Term Key）。

生成STK的演算法如下：

STK = s1(TK, Srand, Mrand)

其中s1演算法是專門用於生成STK的加密演算法，TK值可以通過不同的配對模式獲得（Just Works模式下TK=0，Passkey Entry模式下TK=passkey，OOB模式下TK=oob input），Mrand和Srand分別為主機和從機生成的128位的隨機數。

在兩端裝置生成STK之前，還需要確認對端裝置的安全性，稱為“認證”。

配對發起端裝置生成一個Mrand隨機數，然後根據TK值以及裝置配對資訊和地址資訊等，生成一個確認值Mconfirm。配對響應端裝置也按照相同的步驟生成一個Srand和Sconfirm。

然後兩端裝置交換各自的隨機數和確認值。

響應端根據發起端的隨機數Mrand按照相同的演算法計算出一個新的Mconfirm_new，比較Mconfirm和Mconfirm_new，如果二者匹配，說明發起端裝置是安全的。

發起端根據發起端的隨機數Srand計算出新的Sconfirm_new，比較Sconfirm和Sconfirm_new，如果二者匹配，說明響應端裝置是安全的。

然後兩端裝置命令控制器加密連線，並根據Srand和Mrand生成STK值。

一旦產生了STK，即說明兩端裝置之間的連線已經加密和認證。

4.2 LE安全連線配對

安全連線配對可以使用全部四種配對模式，配對成功後生成長期金鑰LTK（Long Term Key）。

安全連線配對模式使用橢圓曲線加密演算法ECDH（ Elliptic Curve Diffie-Hellman）來解決TK被竊聽的威脅。

ECDH演算法具有數學不可逆的特點。對於一個ECDH運算Q=Pk，如果P和k是已知，計算出Q很容易，但是反過來如果P和Q是已知，計算出k則很難。在金鑰交換時，設定一對“公鑰-私鑰”對，私鑰是上式子中的k，公鑰是Q，加密演算法為P，交換金鑰時僅交換公鑰Q，私鑰永遠不對外暴露，攻擊者即使獲得了公鑰也無法反推出私鑰。（參考）

引入ECDH演算法是安全連線配對與傳統配對最大的區別。

生成LTK需要三個步驟：

1. 交換公鑰，生成ECDH金鑰
2. 認證裝置
3. 利用私鑰生成LTK

在配對開始前，每個裝置先準備自己的公鑰和私鑰對，公鑰可以對外傳輸，私鑰不對外傳輸。

第一步交換攻擊，並利用公鑰和私鑰生成ECDH金鑰，這個ECDH金鑰將用來生成LTK，由於私鑰和ECDH金鑰不對外傳輸，因此可以保證不被竊聽。

第二步認證對端裝置，具體過程與傳統配對基本一致，即在裝置內根據隨機數生成一個確認值，再將隨機數和確認值穿給對端裝置，對端裝置根據隨機數重新生成一個確認值，並與收到的確認值作比較，符合則認證通過，不符合則認證失敗。

如果使用Just Works配對模式，無需使用者輸入，兩端裝置自動完成隨機數和確認值的交換和校驗過程，完成認證。

如果使用Numeric Comparison配對模式，無需使用者輸入，兩端裝置自動完成隨機數和確認值的交換過程，並將最終確認值顯示出來等待使用者確認，如果確認通過則完成認證。

如果使用Passkey Entry配對模式，需要使用者輸入passkey作為初值，然後兩端裝置自動完成隨機數和確認值的交換和校驗過程，完成認證。

如果使用OOB配對模式，不強制要求雙向OOB通訊，僅單向OOB通訊即可完成認證。利用OOB通道傳輸隨機數，保證隨機數不被竊聽。

第三步生成LTK，仍然要執行一次確認值校驗操作。

5. 分發金鑰

BLE工作時可能用到以下幾種金鑰：

金鑰	描述	適用範圍
IRK (Identity Resolving Key)	身份識別金鑰，用於解析私有地址	傳統配對、LE安全連線配對
CSRK (Connection Signature Resolving Key)	連線簽名解析金鑰，用於解析簽名資料	傳統配對、LE安全連線配對
LTK (Long Term Key)	長期金鑰，用於解析加密連線。傳統配對中，LTK是由STK進一步生成；LE安全連線配對中，LTK是配對結束後生成。	傳統配對
EDIV (Encrypted Diversifier)	在傳統配對中，用於生成LTK。它是繫結資訊的一部分。	傳統配對
Rand (Random Number)	在傳統配對中，用於生成LTK。它是繫結資訊的一部分。	傳統配對

其中Rand用以生成EDIV，EDIV用以生成LTK。傳統配對的第二步驟結束時，連線被STK加密以傳輸各種金鑰，此時將STK臨時當做LTK使用，配對成功以後，需要使用Rand、EDIV和LTK作為金鑰來加密和解析連線。

加密過程在鏈路層進行，通過執行鏈路層的加密規程進行加密。檢視LL_ENC_REQ命令，其輸入引數包括Rand和EDIV。

金鑰生成以後，兩端裝置將交換各自的金鑰資訊。傳統配對裝置可以交換以上全部五種金鑰，LE安全連線配對僅交換IRK和CSRK。交換金鑰時會儲存對端設的裝置地址，使裝置地址與LTK關聯在一起。

至此，配對過程全部結束。

6. 安全管理協議

安全管理協議定義配對過程中用到的各種資料格式和協議介面。

安全管理操作資料使用L2CAP的Security Manager通道，傳統的配對方法使用預設的L2CAP MTU值23，LE安全連線配對方法將L2CAP MTU值擴大到65。

安全管理協議的操作以命令的形式進行，命令的格式如下：

欄位	Code	Data
長度	1 octets	0 – 22 or 64 octets

命令碼Code代表了不同的命令型別，全部命令碼如下：

Code	Command
0x01	Pairing Request
0x02	Pairing Response
0x03	Pairing Confirm
0x04	Pairing Random
0x05	Pairing Failed
0x06	Encryption Information
0x07	Master Identification
0x08	Identity Information
0x09	Identity Address Information
0x0A	Signing Information
0x0B	Security Request
0x0C	Pairing Public Key
0x0D	Pairing DHKey Check
0x0E	Pairing Keypress Notification

下面介紹配對請求的命令格式，配對響應與之完全相同。

發起端裝置發起配對請求，執行配對資訊交換（Pairing Feature Exchange）。

配對請求命令的結構如下：

• IO Capability表示不同的IO能力
• OOB data flag表示是否具有OOB能力
• AuthReq表示認證請求，它的結構如下：

欄位	Bonding_Flags	MITM	SC	Keypress	CT2	RFU
長度	2 bits	1 bit	1 bit	1 bit	1 bit	2 bits

其中Bonding_Flags表示是否儲存繫結資訊，MITM是否要求MITM防護能力，即是否需要認證，SC（Secure Connection）表示是否使用LE安全連線配對，Keypress為KeyboardOnly裝置提供一些必要的輸入狀態資訊，CT2與經典藍芽有關。

• Max Encryption Key Size表示最大金鑰長度，有效範圍為7-16位元組。
• Initiator Key Distribution表示發起者需要分發的金鑰。
• Responder Key Distribution表示響應者需要分發的金鑰。