蓝牙低能量安全是如何在Android应用程序和BLE设备之间工作的？

Question

我正在研究蓝牙低能量(BLE)协议(v4.2)，特别是它的安全特性。我试图了解移动应用程序和BLE设备之间的数据加密是如何工作的。

正式文档(v4.2)指定了加密数据、验证设备、生成加密和配对阶段使用的密钥等方法。

第一个疑问(我想肯定已经理解了一些概念)：所有这些功能都是在主机级别上实现的，所以如果我想加密应用程序(Android)和BLE设备(比如健身跟踪器)之间传输的数据，我需要在BLE设备上实现(或启用)这些方法吗？这样，开发人员应该只关心BLE设备上这些特性的实现，因为Android蓝牙堆栈只支持这些特性。我说的对吗？如果我错了，实现这些功能的正确方法是什么(无论是在移动应用程序上还是在BLE设备上)？

第二个疑问:为什么有些BLE设备在GATT协议之上实现自己的加密，而使用SIG提供的安全特性？

第三个也是最后一个疑问: SIG指定的安全特性是强制性的还是可选的？

正如您所看到的，我有一些疑问，也许有些问题是愚蠢的，所以如果有人能够澄清如何在App和BLE设备之间实现安全机制(比如加密)，以及这些特性是在什么级别实现的(OS或应用程序级别)，我将非常感激。

Answer 1

如果您使用标准的BLE加密，实际上是控制器上的链路层执行加密/解密/验证auth标记。但是是主机层(SMP)定义了两个设备如何配对、键和交换密钥。也是该层告诉链接层使用交换的密钥开始加密。在Android和iOS上，管理配对和连接并实现SMP的是操作系统。是否使用蓝牙配对/连接/加密完全取决于设备，并且是可选的。如果不支持，则仍然必须支持发送错误代码“配对不支持”。

蓝牙标准只有一个“用例”。这个用例是提供一种方法来保护两个设备之间的连接，这样在连接之后，任何人都不应该能够模拟一个设备，或者能够操纵或解密通信量。正如您可能知道的那样，"LE Legacy配对“是蓝牙v4.1指定的唯一配对方法，它有几个缺陷，使得攻击者在配对过程中嗅探通信量(同时用于"Just works”和"MITM/passkey entry"，而不是OOB)时不安全。然而，蓝牙v4.2定义的新的“”使用Diffie使其更安全。

尽管蓝牙配对本身提供了安全性，但在Android和iOS API中都存在一些缺陷，如果需要良好的安全性，对应用程序开发人员来说可能还不够。值得注意的是，iOS没有提供任何API来检测给定设备是否实际被绑定，或者某个链接是否被加密。然而，当配对开始时，它确实会向用户显示弹出窗口，但是应用程序对这种配对一无所知。因此，从iOS应用程序的角度来看，不知道：

1. 如果你已经和设备配对了。
2. 如果你与一个真正的设备或中文副本交谈。
3. 安全级别，即如果所使用的配对只起作用，则MITM遗留的配对或LE安全连接。
4. 如果当前链接是加密的。

Android稍微好一点。在那里，应用程序至少可以知道设备是否被连接(但其他三个)。还有一个API "createBond“来启动键合过程。这里的Windows要好得多，因为您可以在执行GATT操作时强制执行加密链接。

任何这些理由都可能足以使开发人员在GATT的基础上实现从头开始的安全性。特别是，一个常见的用例是，开发人员希望用例使用PIN或密码“登录到外围设备”。蓝牙标准不以任何方式支持该用例(不，使用"MITM保护配对与静态密码匙“不起作用，因为该协议通过设计在一次或几次尝试后显示密码)。

无论如何，如果您使用自己的硬件开发自己的外围设备，并且希望使用蓝牙标准的配对/绑定/加密，BLE芯片制造商的SDK通常已经实现了。但是，您仍然需要正确地设置它才能正常工作。通常，您只需配置一些参数(例如，如果您有一个显示，或者用户可以输入一个密码)，其余的就会由其SDK在内部自动处理。

更新：

安卓的源代码可以在https://android.googlesource.com/platform/system/bt/、https://android.googlesource.com/platform/packages/apps/Bluetooth/和https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/bluetooth上找到。