Android藍牙低功耗配對

Question

我對BLE有點困惑。 我讀到BLE配對過程有三個選項，我感興趣的是Passkey Entry。

我的目標是在現場安裝傳感器，Android應用程序將掃描並找到此傳感器，然后它將請求與傳感器配對，然后才能交換數據。 用戶應用程序可以在手機或平板電腦上運行。

BLE配對與藍牙經典相同嗎？ 我的意思是用於BLE和Classic的Android API BluetoothDevice.setPin，驅動程序將在引擎蓋下完成其余的工作嗎？

我很困惑，因為我讀到的地方，對於BLE我可以設置PIN或密碼，但BT Classic只接受4位數PIN。

Answer 1

BLE中的配對只是設置加密鏈接的一種方式。 設備需要就加密密鑰達成一致，他們通過工作 （將密鑰設置為全零）， 密鑰輸入 （最多六位數）或帶外 （通過NFC或其他通道分配的密鑰）來實現此目的。

如果使用密鑰，則表示“窺探器”無法與傳感器配對，除非他能看到設備上的密碼。 （打印或在顯示器上）

您還可以將配對與綁定結合起來，在加密鏈接后設備可以分配密鑰，從而可以在不必租用密鑰的情況下重新連接同一設備。

然后，您需要在傳感器上設置數據庫，以便只允許通過加密鏈接讀取傳感器數據。 （您不希望您的窺探器簡單地連接到設備並自己讀取數據）。

這種方法的一個問題是密鑰條目僅使用6位數。 這還不足以真正保護你免受竊聽。 密鑰輸入后生成的密鑰可以在幾毫秒內強制執行，所有商用藍牙嗅探器都將其作為正常操作的一部分。 然而，他們必須嗅探配對程序才能做到這一點，所以如果沒有人在設備被綁定時進行竊聽，那么你通常會很好。

使用帶外數據也是安全的，因為您不能輕易地強制隨機使用128位AES密鑰。

Answer 2

據我所知，在BTLE中沒有使用PIN類型的密鑰。 傳統藍牙設備使用固定的PIN密碼，該密碼硬編碼到設備中或由應用程序輸入。 在下一輪藍牙中，這種配對方法被SSP（安全簡單配對）取代。 BTLE稍后出現並僅使用SSP。 SSP中的密鑰（當啟用中間人保護時）由藍牙軟件隨機生成，通常處於相當低的水平。 一個SSP選項是“正常工作”，整個密鑰生成是內部的。 對用戶來說很棒，但是對於中間人（MITM）攻擊是可能的。 因此，最終，對於您的藍牙LE應用程序，您永遠不會使用4位數的PIN。

因此，與Android上的BTLE設備配對可以與一對標准藍牙設備完全相同。 如果BTLE設備使用的是“正常工作”之外的SSP選項，您將獲得一個彈出菜單，要求您使用

1. 驗證設備上顯示的數字和/或提供您必須在設備上驗證的號碼（是 - 否和僅顯示組合）

2. 要求您輸入在設備上顯示的數字和/或顯示您必須在設備上輸入的數字（鍵盤）

內置的配對功能適用於BTLE和BT設備，盡管事實上它們的機制非常不同。 BTLE設備發送客戶端設備掃描的廣告（BTLE'發現'），而BT設備在尋找設備時掃描來自客戶端的傳輸（BT發現）。

或者，可以使用BluetoothAdapter.startLeScan（LeScanCallback回調）方法掃描僅BTLE設備。 此方法將為您提供BTLE設備列表，然后可以選擇並嘗試連接。 在這種情況下，您的應用程序需要在需要時處理配對。 通常，在嘗試啟用通知或指示之前，BTLE設備上不需要配對。 服務發現，讀取設備信息服務和其他花絮通常不需要配對，如果內存為我服務，則永遠不需要配對進行服務發現。

因此，為了使我的應用程序的生活更輕松，我鏈接到標准的Android提供的工具，用於發現/配對需要配對的任何設備以及那些不需要配對的BTLE設備（並且有許多這樣的設備）我使用startLeScan（）API並對其中一個“已發現”設備執行BluetoothDevice.connectGatt（）。 如果我使用這種方法並且設備實際上需要配對，我將收到安全錯誤。 從理論上講，我應該可以使用Android提供的配對API然后與設備配對。 不幸的是，我無能的編程技巧導致我還沒有成功地正確實現它。