安全管理的簡介在藍牙的SMP安全管理簡介這篇文章中有介紹。這裡將介紹BLE安全管理（SM）的詳細的配對的方法。
本文引用地址：http://www.eepw.com.cn/article/201710/366193.htm在配對過程開始時，第一階段就是雙方交換支持的配對特徵，如果有一方不支持配對，那就不會進行配對，如果都支持配對，那麼就會選擇合適的方法進行配對了。
配對特徵
首先看下這個配對特徵的內容都有哪些（前三個將決定配對第二階段的key生成方法）：
- IO capability；
- OOB；
- authenTIcaTIon requirements；
- key size；
- key distribute。
配對中產生的Key
LE legacy pairing
Temporary Key（TK）：短暫存在的Key，128-bit，用來產生STK的；
Short Term Key（STK）：128-bit，會被用來加密配對後的鏈路。
LE Secure ConnecTIons
Long Term Key（LTK）：128-bit，會被用來加密配對後的鏈路。
authenTIcation
authentication requirements是GAP設定的，主要是對Bond類型和MITM（man-in-the-middle）的要求。
key distribute
對於key distribute，Initiator首先會將自己的需求發給Responder，表明自己想發哪些Key，而且想要對方發哪些Key。而Responder收到後，會回復確定最終雙方能夠分發的Key。這層協商就兩步，比較簡單。
安全屬性-Security Properties
分為如下幾類安全屬性：
- LE Secure Connections pairing（BT4.2才支持）；
- Authenticated MITM protection（有人參與幹涉的安全，可以是人輸入密碼，或者通過OOB獲取密碼，對於Secure Connections還支持數字比較的方式）；
- Unauthenticated no MITM protection；
- No security requirements；
IO capabilities
表明輸入，輸出的能力。輸入是按鍵、鍵盤，輸出是顯示數字用的界面。
輸入能力
輸入輸出的組合
OOB Authentication Data
OOB Auth Data是一個設備持有對端的Data，用來對對端設備進行authenticate。
- LE legacy pairing：要兩端都持有對方OOB Auth Data才用OOB方法；
- LE Secure Connections pairing：至少一端持有OOB Auth Data即可用OOB方法。
加密Key Size
加密Key Size都在都在7到16 bytes之間；
兩端設備要選擇相互的max key len中較小那個；
兩端設備要檢測max key len是否小於自己的min key len，小於的話pair失敗；
產生的key到最終key有可能要裁剪。key一生成就是16 byte的key值，但是max key len小於16時，那就要縮減成len較小的resulting key再來分發了。
配對算法
在第一階段交換配對特徵後，這些特徵內容將會用來選擇確認用哪種Key生成方法。
比如Temperary Key的生成：如Just Works，Passkey Entry， OOB都可以用來生成TK，只是要先看設備是否具備這種能力。
選擇Key生成的方法
如果auth Req中MITM沒有，則說明不需要人參與中間，所以IO capabilities會被忽略，只用Just Works就OK了。
如果有OOB data，auth Req將可直接忽略，會直接選擇OOB的方式了。
Legacy pairing生成STK
Use IO capabilities對應的具體算法
上面兩個圖中都有Use IO capabilities一項，其實這一項又有細分：
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的傳輸是不可見的了，因此會顯得要安全些。
LE Legacy Pairing第二階段
即是STK的生成，這一部分可簡述為以下步驟的實現：
1. 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值進行比較，若不同說明配對失敗了，若相同，繼續；
Initiator計算STK，並通知其Controller允許鏈路加密：
STK = s1（TK， Srand， Mrand）
縱觀以上各過程，其實就是兩者互送一個128-bit隨機數用來生成STK。竊聽者或攻擊者只要知道TK，這步驟是很容易破解的。
LE Secure Connections的第二階段
即LTK的生成，比Legacy pairing還是複雜很多的，這也是BT 4.2安全性要高很多的原因了。這部分這裡只簡單說明下內容，詳細的過程需對照Spec的流程圖了。
Public Key交換
Authentication階段1-Just Works或Numeric Comparison
Authentication階段1-Passkey Entry方式
Authentication階段1-Out of Band方式
Authentication階段2和LTK計算
BR/EDR， LE交叉Key引用
這部分是指藍牙雙模設備，且支持Secure Connections，配對Key其實可以相互共享使用的，這樣可以省略掉一些重複配對，不過Key也有個換算的算法的，即密碼工具箱中的h6。