藍牙Legacy Pairing流程概述

Legacy pairing 從名字上看能夠知道它是老式設備採用的配對方法。

配對的最終目的是爲了生成key，key能夠給鏈路加密，保證雙方設備通訊的安全性。那配對流程的講述其實就是key的生成過程。

key的生成是通過各類各樣的算法，這裏不會針對具體的算法講述，而是着重描述其流程，以及key生成過程當中的邏輯推理。

Legacy pairing 的流程能夠分爲以下的幾個階段：

1. 隨機數的生成
2. key的選擇以及生成。
3. key的驗證
   
   

下面先看一下 legacy pair 最終創建鏈路的流程圖：

上圖中對應pair的1，2，3階段標出如圖示。

首先大概描述一下 整個的流程：

1. controller端會和對端的設備進行LMP feature exchange 的交互—>
2. 交互以後肯定配對算法legacy pairing（以前未配對過狀況。若是host端有key，那麼先走authentication流程，該流程若失敗繼續走legacy pairing）—>
3. controller端向host請求pin code
4. controller 得到了pin code以後生成隨機數發送給對方。
5. 對端也進行pin code 的請求，並生成相應的隨機數發送給對方。（這裏描述的是能夠配對的狀況，不可配對場景後面會描述）
6. 雙方發送 key給對方，並生成最終的link key
7. 進行authentication的操做
8. 通知各自的host ：link key 已經生成。

 

下面詳細描述一下 Legacy pairing 的流程的各個階段所作的具體的事情。

首先看看隨機數的生成：

這裏涉及到一個問題：什麼樣的雙方是能夠配對的？

主要有以下的幾種場景：

1.responder 有一個可變的pin，這種狀況能夠配對，其隨機數交互的流程以下：

上面的 legacy pair 最終創建鏈路的流程圖就是屬於這種狀況，當initiator發送random給responder的時候，responder回覆LMP accepted

 2.responder 有一個固定的pin，這種狀況也能夠配對，其隨機數交互的流程以下：

 在這種狀況下，雙方使用的隨機是responder 發送過來的隨機數。

 

3.雙方有一個固定的pin ，那這種狀況雙方是沒法配對的。其交互流程以下:

上面講的這個隨機數是幹嗎的呢？

它是雙方設備計算Kinit 用的，這個Kinit 最後又會被用來計算link key。下面先看看這個Kinit的計算：以下圖：

使用的算法是E2  其中 L‘ = pin 的長度 ，這裏的RAND就是上面交互的隨機數，pin的話 老式機器通常都是4個0，那麼從上圖能夠推出雙方的Kinit應該是同樣。

 

接下里看第二階段：key的選擇以及生成。

關於key的選擇，這裏存在兩種key：unit key和comb key ，那麼兩種key 對應於什麼樣的應用場景呢？

1.若是其中有一方使用unit key，那麼雙方就使用unit key做爲link key。

2，若是雙方都給對方發送unit key，那麼使用master的unit key做爲link key。

3.若是雙方都發送LMP_comb_key，那麼雙方就使用他們二者的key通過計算獲得的key。

 

關於最終key的使用，其互相交互的流程以下：

 

接下來先看一下 key生成的大局流程圖：

 

 因爲前面的分析，如今看到這個圖應該也不難理解的，能夠發現以前的隨機數是用來計算Kinit，Kinit又會被用來計算link key。

那下面就來分析一下，Kinit是 如何通過計算出link key。

首先來看看 unit key 是如何計算出來的

 key的計算以下所示：

 上面生成K以後，用下圖的算法和對方交換key

關於上圖中的藍牙地址也是雙方根據pin code預先設定好的，下面的圖是key的交換的過程。

 

下面再看看 combination key 的生成

 

 

這裏須要解釋 是K，當處於未配對狀態，這個K = Kinit，其他的流程 上圖已經明顯，最後能夠知道KAB = KBA

到這裏key的生成已經完成。

 

最後是一步key的驗證：

關於key的驗證，其套路仍是不變的。主要就是經過交換隨機值以及經過隨機值和link key以及其餘共享信息計算出來的值 ，來互相驗證。

其流程以下圖：

這裏須要注意的就是，上圖只是展現單方面的驗證，驗證過程是雙向的。

另外注意的是這裏的隨機不是上面的隨機值了，能夠發現其名字不同了，這個隨機值是在authentication 的過程當中從新生成的。

相關的air log以下：

從上面的log 能夠看出 其驗證是雙向的.

到此關於key的驗證就結束了.

通常狀況還會有一個encryption的流程,其實這個流程是不屬於配對流程的,而且在ssp 流程中已經有描述,這裏再也不描述.