是否應該與藍牙 LE 設備建立綁定

Question

對於使用 Xamarin（Android API 21 及更高版本）的藍牙項目，我想知道創建與藍牙設備的綁定是否很常見。 目前的要求是：

• 藍牙設備使用頻繁，但不是持續使用。
• 重新連接應該盡快發生
• 設備掉電時藍牙地址隨機變化
• 設備名稱未知、為空或隨機
• 連接已加密
• 該連接使用需要藍牙設備作為連接參數的上層 API。

是否應該與此設備建立綁定以“更好地”識別（作為某種緩存）或“從頭開始”重新連接到設備。 在這種情況下，什么是常見的？ 因此，這不是“我可以綁定”的問題，而是是否有必要綁定，或者甚至更好：什么是coorect 和工作可靠的場景。

目前我使用這樣的代碼（result.Device.Name 用於開發目的）：

  public override void OnScanResult([GeneratedEnum] ScanCallbackType callbackType, ScanResult result)
    {

        if (result.Device.Name == "��" &&

            !_discovered &&
          result.ScanRecord != null &&
          result.ScanRecord.ServiceUuids != null &&
          result.ScanRecord.ServiceUuids.Any(x => x.Uuid.ToString().ToUpper() == uuid))
        {
            lock (_locker)
            {
                _discovered = true;
                _deviceList.Add(result.Device);
                BluetoothDiscoverySucces?.Invoke(result.Device);
            }
        }
    }

Answer 1

簡短回答：正確、常見且可靠的方案是綁定。 綁定意味着連接是安全的，鏈接是可信的。 這意味着您的本地設備通常會找到遠程設備，即使其地址發生變化。 出於安全和隱私原因，配對/綁定是藍牙中的推薦做法。

---

長答案：自推出以來，藍牙規范的增量版本增加了一些功能，以提高藍牙設備的安全性和隱私性。 許多設備不允許您交換數據或正確跟蹤它們，除非您已配對/綁定（綁定和配對之間的區別在於綁定，交換的密鑰存儲在數據庫中。）

在低功耗藍牙中，配對/綁定過程包括三個階段：-

階段 1 - 配對功能交換

兩個連接的設備交換它們的 IO 功能（例如設備是否有鍵盤）、身份驗證要求（例如綁定或不綁定）和支持的密鑰大小。

第 2 階段 - 身份驗證和加密

使用加密算法生成密鑰並用於加密鏈接（這對於傳統和 LESC 配對是不同的，但這超出了本問題的范圍）。

階段 3 - 密鑰分發

多個密鑰在設備之間交換，包括 CSRK（連接簽名解析密鑰）、IRK（身份解析密鑰）和靜態地址。

對您的問題特別重要的是 IRK 和地址。 自藍牙 v4.0 以來，一項稱為LE Privacy的功能允許設備不斷更改其地址以降低其跟蹤能力。 惡意設備將無法跟蹤實現此功能的設備，因為它實際上看起來像是一系列不同的設備。 為了解析地址，設備需要事先配對/綁定。 如果遠程設備包含 IRK，則它可以使用該 IRK 和隨機可解析地址來導出藍牙設備的原始地址。

---

所以，回顧你的標准：-

• 藍牙設備使用頻繁，但不是持續使用。

如果您要頻繁斷開/重新連接，您可以與設備配對一次並存儲密鑰（即綁定）。 之后不再需要配對，因為在斷開/重新連接時將使用相同的密鑰來加密連接。

• 重新連接應該盡快發生

連接和綁定是兩件不同的事情。 無論是否實施綁定，重新連接都將花費相同的時間。 但是，一旦設備重新連接，重新加密連接需要一些時間。

• 設備掉電時藍牙地址隨機變化

這意味着該設備正在使用 LE 隱私功能。 因此，您的設備應該與其綁定以解析私有可解析地址。

• 設備名稱未知、為空或隨機

這通常是 BLE 的情況。 這些設備通常可以通過它們的地址來識別。 因此，如果您的設備之前已綁定，您將能夠解析更改地址並識別遠程設備。

• 連接已加密

如果不先配對，您將無法實現加密連接（按照上述 3 個階段）。 通過綁定，您將密鑰存儲在數據庫中，從而確保您將來可以使用它們來重新加密連接，而無需經過配對階段。

• 該連接使用需要藍牙設備作為連接參數的上層 API。

我不確定這意味着什么，但與綁定要求無關。

---

有關該主題的進一步閱讀，我建議訪問藍牙規范版本 5.0，第 3 卷，第 H 部分，第 2 部分安全管理器（第 2295 頁）