藍(lán)牙安全管理SM的配對(duì)方法

　　安全管理的簡(jiǎn)介在藍(lán)牙的SMP安全管理簡(jiǎn)介這篇文章中有介紹。這里將介紹BLE安全管理（SM）的詳細(xì)的配對(duì)的方法。

　　在配對(duì)過(guò)程開(kāi)始時(shí)，第一階段就是雙方交換支持的配對(duì)特征，如果有一方不支持配對(duì)，那就不會(huì)進(jìn)行配對(duì)，如果都支持配對(duì)，那么就會(huì)選擇合適的方法進(jìn)行配對(duì)了。

　　配對(duì)特征

　　首先看下這個(gè)配對(duì)特征的內(nèi)容都有哪些（前三個(gè)將決定配對(duì)第二階段的key生成方法）：

　　- IO capability；

　　- OOB；

　　- authenTIcaTIon requirements；

　　- key size；

　　- key distribute。

　　配對(duì)中產(chǎn)生的Key

　　LE legacy pairing

　　Temporary Key（TK）：短暫存在的Key，128-bit，用來(lái)產(chǎn)生STK的；

　　Short Term Key（STK）：128-bit，會(huì)被用來(lái)加密配對(duì)后的鏈路。

　　LE Secure ConnecTIons

　　Long Term Key（LTK）：128-bit，會(huì)被用來(lái)加密配對(duì)后的鏈路。

　　authenTIcation

　　authentication requirements是GAP設(shè)定的，主要是對(duì)Bond類型和MITM（man-in-the-middle）的要求。

　　key distribute

　　對(duì)于key distribute，Initiator首先會(huì)將自己的需求發(fā)給Responder，表明自己想發(fā)哪些Key，而且想要對(duì)方發(fā)哪些Key。而Responder收到后，會(huì)回復(fù)確定最終雙方能夠分發(fā)的Key。這層協(xié)商就兩步，比較簡(jiǎn)單。

　　安全屬性-Security Properties

　　分為如下幾類安全屬性：

　　- LE Secure Connections pairing（BT4.2才支持）；

　　- Authenticated MITM protection（有人參與干涉的安全，可以是人輸入密碼，或者通過(guò)OOB獲取密碼，對(duì)于Secure Connections還支持?jǐn)?shù)字比較的方式）；

　　- Unauthenticated no MITM protection；

　　- No security requirements；

　　IO capabilities

　　表明輸入，輸出的能力。輸入是按鍵、鍵盤，輸出是顯示數(shù)字用的界面。

　　輸入能力

　　輸入輸出的組合

　　OOB Authentication Data

　　OOB Auth Data是一個(gè)設(shè)備持有對(duì)端的Data，用來(lái)對(duì)對(duì)端設(shè)備進(jìn)行authenticate。

　　- LE legacy pairing：要兩端都持有對(duì)方OOB Auth Data才用OOB方法；

　　- LE Secure Connections pairing：至少一端持有OOB Auth Data即可用OOB方法。

　　加密Key Size

　　加密Key Size都在都在7到16 bytes之間；

　　兩端設(shè)備要選擇相互的max key len中較小那個(gè)；

　　兩端設(shè)備要檢測(cè)max key len是否小于自己的min key len，小于的話pair失?。?/p>

　　產(chǎn)生的key到最終key有可能要裁剪。key一生成就是16 byte的key值，但是max key len小于16時(shí)，那就要縮減成len較小的resulting key再來(lái)分發(fā)了。

　　配對(duì)算法

　　在第一階段交換配對(duì)特征后，這些特征內(nèi)容將會(huì)用來(lái)選擇確認(rèn)用哪種Key生成方法。

　　比如Temperary Key的生成：如Just Works，Passkey Entry， OOB都可以用來(lái)生成TK，只是要先看設(shè)備是否具備這種能力。

　　選擇Key生成的方法

　　如果auth Req中MITM沒(méi)有，則說(shuō)明不需要人參與中間，所以IO capabilities會(huì)被忽略，只用Just Works就OK了。

　　如果有OOB data，auth Req將可直接忽略，會(huì)直接選擇OOB的方式了。

　　Legacy pairing生成STK

　　Use IO capabilities對(duì)應(yīng)的具體算法

　　上面兩個(gè)圖中都有Use IO capabilities一項(xiàng)，其實(shí)這一項(xiàng)又有細(xì)分：

　　LE Legacy Pairing - Just Works

　　Just Works方式不能抵抗竊聽(tīng)者和中間人攻擊，只有在配對(duì)過(guò)程時(shí)沒(méi)有遭受攻擊，后面加密的鏈路的數(shù)據(jù)傳輸才是可信的。安全級(jí)別很低。

　　LE Legacy Pairing - Passkey Entry

　　這種方式通過(guò)輸入6位數(shù)字的方式來(lái)進(jìn)行配對(duì)，生成STK。6位數(shù)是隨機(jī)產(chǎn)生的在000000到999999之間的數(shù)值，這個(gè)數(shù)值相當(dāng)于一個(gè)TK，比如遠(yuǎn)端顯示這個(gè)數(shù)字，需要在本地端輸入這個(gè)數(shù)字給本地設(shè)備與遠(yuǎn)端配對(duì)。如輸入019655，那此時(shí)的臨時(shí)Key–TK是：0x00000000000000000000000000004CC7。

　　Out of Band

　　這種方式是通過(guò)BLE之外的，設(shè)備上的其他方式來(lái)獲取這個(gè)OOB data，比如通過(guò)IR紅外，或其余的方式，因此對(duì)于藍(lán)牙竊聽(tīng)者/攻擊者而言這個(gè)data的傳輸是不可見(jiàn)的了，因此會(huì)顯得要安全些。

　　LE Legacy Pairing第二階段

　　即是STK的生成，這一部分可簡(jiǎn)述為以下步驟的實(shí)現(xiàn)：

　　1. Initiator生成一128-bit隨機(jī)數(shù)Mrand，并使用這個(gè)Mrand結(jié)合一些其他的輸入，使用密碼工具箱中c1計(jì)算出一個(gè)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隨機(jī)數(shù)Srand，并使用這個(gè)Srand結(jié)合一些其他的輸入，使用密碼工具箱中c1計(jì)算出一個(gè)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將其計(jì)算的Mconfirm值通過(guò)Pairing Confirm包發(fā)送給Responder，而Responder也將其計(jì)算的Sconfirm值通過(guò)Pairing Confirm包發(fā)送給Initiator；

　　Initiator收到Sconfirm后，再將Mrand值通過(guò)Pairing Random包發(fā)送給Responder；

　　Responder收到Mrand值后計(jì)算它的Mconfirm值，再跟前面那個(gè)Initiator送過(guò)來(lái)的Mconfirm值進(jìn)行比較，若不同說(shuō)明配對(duì)失敗了。若相同，則Responder也會(huì)將它的Srand值通過(guò)Pairing Random包發(fā)送給Initiator；

　　而Initiator也會(huì)計(jì)算收到的Srand值的Sconfirm值，并跟前面那個(gè)Responder送過(guò)來(lái)的Sconfirm值進(jìn)行比較，若不同說(shuō)明配對(duì)失敗了，若相同，繼續(xù)；

　　Initiator計(jì)算STK，并通知其Controller允許鏈路加密：

　　STK = s1（TK， Srand， Mrand）

　　縱觀以上各過(guò)程，其實(shí)就是兩者互送一個(gè)128-bit隨機(jī)數(shù)用來(lái)生成STK。竊聽(tīng)者或攻擊者只要知道TK，這步驟是很容易破解的。

　　LE Secure Connections的第二階段

　　即LTK的生成，比Legacy pairing還是復(fù)雜很多的，這也是BT 4.2安全性要高很多的原因了。這部分這里只簡(jiǎn)單說(shuō)明下內(nèi)容，詳細(xì)的過(guò)程需對(duì)照Spec的流程圖了。

　　Public Key交換

　　Authentication階段1-Just Works或Numeric Comparison

　　Authentication階段1-Passkey Entry方式

　　Authentication階段1-Out of Band方式

　　Authentication階段2和LTK計(jì)算

　　BR/EDR， LE交叉Key引用

　　這部分是指藍(lán)牙雙模設(shè)備，且支持Secure Connections，配對(duì)Key其實(shí)可以相互共享使用的，這樣可以省略掉一些重復(fù)配對(duì)，不過(guò)Key也有個(gè)換算的算法的，即密碼工具箱中的h6。