配對是藍牙設備間身份認證的一個過程，只有成功配對的兩個設備才能連接并進行數據交互，所以配對是藍牙操作中必不可少的流程。
在《藍牙配對協議分析一 》和《藍牙配對協議分析二 》中已經簡單介紹了配對的相關協議知識，還不清楚的同學可以先查看下這兩篇文章，回來再閱讀本篇分享可以更加地得心應手。
藍牙標準配對流程：
- PIN碼配對：藍牙2.0及以前版本使用的流程
- SSP簡單安全配對：藍牙2.1及之后版本新增的流程
因為SSP相較于PIN碼配對具有更高的安全性、更方便的操作性等優點，所以PIN碼配對方式已經退出歷史舞臺，當前市面上的藍牙設備基本上都是采用SSP配對方式。
SSP安全簡單配對在主要應用場景中也有如下三種模型：
- Numeric Comparison：數字比較模型，連接的兩個設備都具有輸入、輸出能力。比如手機、車機、平板、個人電腦等設備間配對連接。
- Passkey Entry：密碼輸入模型，連接是兩個設備中有一個設備只具有輸入能力，另一個設備具有輸出能力。比如手機和鍵盤配對連接，只有鍵盤正確輸入手機上顯示的數字才能配對成功。
- Just Works：直接工作模型，類似 Numeric Comparison，這里一起放到數字比較模型中講解。
結合以上三種SSP配對模型，Passkey Entry 密碼輸入模型無法做到自動配對，可以有效防止MITM攻擊。Numeric Comparison 數字比較模型卻可以實現藍牙自動配對目標，以下內容都是以 Numeric Comparison 配對模型進行分享。
參照《藍牙配對協議分析二 》中Step 7: Authentication——Numeric Comparison 可知當兩個設備都具有輸入、輸出功能時，或者其中一個設備沒有輸入或輸出功能，則將執行數字比較步驟。如果一個或兩個設備沒有輸出功能，則使用相同的協議，但是協議棧Host將跳過要求用戶確認的環節，這就是Just Works模型。數字比較模型的交互流程圖如下：
所以自動配對的實現可以在用戶確認數字這塊，程序默認直接接受配對，達到讓用戶無感實現自動配對的目標。
實現方案：有多種方案，只要在協議棧bluedroid接收到User Confirmation Request的HCI請求命令處理上報流程中都可以添加自動接受配對的邏輯，為了最大程度上符合一般的流程設計，建議放到應用層中模擬用戶確認接受配對的動作進行處理。即應用監聽到系統廣播BluetoothDevice.ACTION_PAIRING_REQUEST后，直接調用接口 BluetoothDevice .setPairingConfirmation(true) 。
藍牙自動配對雖然實現了，但是配對漏洞攻擊也隨之而來。因為不需要用戶的參與，本端實現的自動配對的主機都會默認接收遠端藍牙設備發起的配對請求，這就給攻擊者可乘之機。
藍牙配對中會對設備進行IO能力的獲取，藍牙設備的IO能力總體上大概分為以下這五種：
- DisplayOnly，只有輸出能力
- DisplayYesNo，有輸出、輸入能力，手機、車機、個人電腦
- KeyboardOnly，只有鍵盤
- NoInputNoOutput，即沒輸入、也沒輸出能力，耳機、音箱
- KeyboardDisplay，鍵盤輸出能力，帶顯示器的鍵盤
IO能力為KeyboardOnly或Keyboard display的設備明顯會使用 Passkey Entry 模型進行配對，因此另一端設備必須將passkey展示出來才能在鍵盤上輸入，不適合實現自動配對功能。
其他三種IO能力的設備都會采用 Numeric Comparison 模型配對，在這三種設備間攻擊者就可以利用自動配對的漏洞實行進一步的攻擊。因此自動配對和防止漏洞攻擊不可兼得，望大伙警惕。
那有沒有辦法能讓自動配對和防止漏洞攻擊兼得呢？
方法肯定是有的，實現自動配對功能的本機首次配對連接時只允許本機發起的配對連接請求，拒絕其他設備主動來配對連接本機，后續的重連兩端設備都可以發起，此方案大大增加本機的私密性。
感興趣的小伙伴歡迎私信留言一起討論，共同學習，一起進步！
