Secure Simple Pairing，簡稱SSP，其流程主要分為六個部分：
- • IO capabilities exchange
- • Public key exchange
- • Authentication stage 1
- • Authentication stage 2
- LINK KEY CALCULATION
- LMP AUTHENTICATION AND ENCRYPTION
接下來將逐個介紹這個六個部分的內容。
IO capabilities exchange
在ssp的過程中，有兩個角色：“Initiator ”和“Responder ”，他們是如何確認的呢？主動發起 IO capabilities exchange流程的那一方就是Initiator，而另一方就是Responder 。
IO capabilities exchange 是干嘛的呢？
在平常的配對中，有如下的場景：
- 手機和鍵盤配對，我們會被要求在鍵盤上面輸入字符。
- 手機和音箱配對的時候，我們往往不需要額外的操作。
- 手機和手機的配對的時候，我們往往要在兩只手機的屏幕上面都要點擊一下配對。
上面的場景就是配對的設備之間經過IO capabilities exchange之后來確定了雙方進行配對所選取的最合適的配對算法。配對算法有如下的幾種：
- Numeric comparison
- Passkey entry
- Out of band
手機和鍵盤進行配對的場景就屬於Passkey entry，而手機和音箱的配對屬於Numeric comparison，Out of band 是屬於帶外數據的通信，這里基本用不到，不作細節介紹。
那么接下來的一個問題是：IO capabilities exchange 和配對算法的選取的具體的映射關系是什么樣的呢？
請看下圖：
上面這個圖是根據設備的input和ouput的能力來歸結出來的一個綜合的IO能力，下面這張圖是根據這個IO能力來選擇不同的流程：
上面兩張圖都是比較容易理解的，這里舉兩個例子來說明一下（往往是如下的情況，並不絕對，嚴格來說還是要看IOcap）：
|
initiator
|
responder
|
配對算法選取
|
|---|---|---|
| TV | 音箱 | Numeric Comparison |
| TV | 手機 | Numeric Comparison: |
| TV | 鍵盤 | Passkey Entry: Initiator |
最后看看這一流程的空中交互：
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
這個配對協議的使用場景，上面已經分析過，這里再次重復一下。
- 當雙方的設備都有output的能力的時候，比如兩個手機進行配對，這個時候兩只手機的界面需要用戶去確認的。
- 當一方設備有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流程分析完畢。