藍牙secure simple pair 概述

Secure Simple Pairing，簡稱SSP，其流程主要分爲六個部分：

1. • IO capabilities exchange
2. • Public key exchange
3. • Authentication stage 1
4. • Authentication stage 2
5. LINK KEY CALCULATION
6. LMP AUTHENTICATION AND ENCRYPTION

 

 

接下來將逐個介紹這個六個部分的內容。

 IO capabilities exchange

在ssp的過程當中，有兩個角色：「Initiator 」和「Responder 」，他們是如何確認的呢？主動發起 IO capabilities exchange流程的那一方就是Initiator，而另外一方就是Responder 。

 IO capabilities exchange 是幹嗎的呢？

在日常的配對中，有以下的場景：

1. 手機和鍵盤配對，咱們會被要求在鍵盤上面輸入字符。
2. 手機和音箱配對的時候，咱們每每不須要額外的操做。
3. 手機和手機的配對的時候，咱們每每要在兩隻手機的屏幕上面都要點擊一下配對。
   
   
   

上面的場景就是配對的設備之間通過IO capabilities exchange以後來肯定了雙方進行配對所選取的最合適的配對算法。配對算法有以下的幾種：

1. Numeric comparison
2. Passkey entry
3. Out of band 

手機和鍵盤進行配對的場景就屬於Passkey entry，而手機和音箱的配對屬於Numeric comparison，Out of band 是屬於帶外數據的通訊，這裏基本用不到，不做細節介紹。

那麼接下來的一個問題是：IO capabilities exchange 和配對算法的選取的具體的映射關係是什麼樣的呢？

請看下圖：

上面這個圖是根據設備的input和ouput的能力來歸結出來的一個綜合的IO能力，下面這張圖是根據這個IO能力來選擇不一樣的流程：

上面兩張圖都是比較容易理解的，這裏舉兩個例子來講明一下（每每是以下的狀況，並不絕對，嚴格來講仍是要看IOcap）：

initiator	responder	配對算法選取
TV	音箱	Numeric Comparison with automatic confirmation on both devices
TV	手機	Numeric Comparison: Both Display, Both Confirm
TV	鍵盤	Passkey Entry: Initiator Display,Responder Input.

最後看看這一流程的空中交互：

OIcap的整個流程圖以下：

ssp的第二個階段是Public key exchange

首先看一下這個部分流程圖：

這裏交換的public key其實設備本身生成的，還有一個screct key，這二者組成一對key。從上圖能夠看出，當獲得了對方了public key以後就進行了DHKey的計算，DHKey最終會參與到link key的計算當中。

由於public key比較大，它是分多比包來傳輸的。從上圖能夠看出它是先傳輸的header部分，而後在傳輸palyload部分。

air log中該過程的交互以下：(下圖只展現了responder-->initiator部分)

 

Authentication Stage 1

這一部分主要介紹兩種配對協議：

Numeric Comparison Passkey Entry Authentication

首先來看看

Numeric Comparison

這個配對協議的使用場景，上面已經分析過，這裏再次重複一下。

1. 當雙方的設備都有output的能力的時候，好比兩個手機進行配對，這個時候兩隻手機的界面須要用戶去確認的。
2. 當一方設備有output的能力，可是另外一方設備是no input or output的時候，好比手機和音箱進行配對的時候，這種狀況和上一種的狀況的區別是不要用戶去確認，這種狀況其實也能夠稱爲just work

下面從btsnoop中看一下二者的區別：下面是（TV和TV配對）

若是用戶不去確認屏幕上面顯示的value，那麼最終就會出現LMP response timeout的錯誤：

而若是用戶在屏幕上面點擊取消配對的話，那麼相應的log以下:

這邊抓了一下air log發現，如是在確認界面直接點擊取消配對的話，那麼controller端是直接發送LMP Detach的報文，那麼在對方的host就只會收到一個disconnection event。

在spec中規定是要下一次initiator進行DHKey check的時候，responder才通告驗證失敗：

 

以上是關於該協議的流程部分，下面看一下該協議的算法部分：

上面的圖片都有註釋，比較容易看懂，這裏就再也不過多解釋。在配對章節的基本思想都是以下：

一方經過隨機值rand與某個配對算法（以前協商好的）計算出一個confirm值，而後把rand值和confirm值發送給對方，讓對方去check。

 

接下來看 這一階段的另外一個配對協議Passkey Entry Authentication

這個配對協議的典型應用場景就是鍵盤和TV的配對。

下面看一下其流程：

從上面的流程圖能夠看出來，其校驗的套路仍是同樣，首先按照某種算法計算出confirm 值，併發送給對方，而後雙方再交換各自參與計算confirm值的random值，而後依次使用對方發送過來的值進行計算看是否和對方發送過來的confirm值相等。

下面看一下 校驗過程的詳細流程圖：

上面的流程圖也很容易理解，參照上面的註釋應該能看懂，這裏不作過多註釋。下面看一下該流程在air log中的表現：

下面是對應的btsnoop：

上面兩張圖是對應於按鍵的輸入流程輸入流程。輸入完成以後開始計算：注意上面流程圖顯示了計算要計算20次，下圖簡單展現幾回交互過程：

 

接下來看看Authentication Stage 2

這一階段主要的工做就是DHKey的驗證，這個流程很是的簡單，以下：

DHKey校驗完成以後，那麼以後的流程就是要生成link key了。這裏須要說明一下的是 DHKey是在前面進行public key交換以後就生成了。

 

下面來看看link 能夠的生成過程：LINK KEY CALCULATION

其link key的計算算法以下：

咱們能夠看出，其中輸入參數都是雙方已經校驗過的，而且參數是一致的，若是雙方計算不出錯的話，輸出的link key也是一致的。

從上面的這個圖能夠看出來，雙方計算了link key以後還會再進行一輪校驗，以保證生成的link key確實是同樣的。相應的air 中的狀況以下：

 

到此link key就生成了，這個key標誌着配對完成。以後只要二者沒有刪除link key，仍是能夠回連的。回連的流程就不會再走一系列的生成key的動做，而是直接驗證link key。

 

最後來看看encryption的過程：

在air 中的交互以下：

上面的流程是生成KC，下面是key做用於數據包的示意圖：

 

這個流程的意思就是經過link key以及一些其餘的信息生成一個Kc，而後Kc又參與某種算法生成Kcipher，最終由這個key 對接下來發送的數據進行加密。這裏要注意的是加密是針對於baseband層的payload，加密並不會對header進行加密。

到此ssp流程分析完畢。