android - 低功耗蓝牙安全性如何在 Android 应用程序和 BLE 设备之间发挥作用？

Question

我正在研究低功耗蓝牙 (BLE) 协议(protocol) (v4.2)，尤其是它的安全功能。我正在尝试了解移动应用程序和 BLE 设备之间传输的数据加密的工作原理。

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

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

第二个疑点:为什么一些 BLE 设备在 GATT 协议(protocol)之上实现自己的加密，而不是使用 SIG 提供的安全功能？

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

如您所见，我有一些疑问，也许有些问题可能很愚蠢，所以如果有人可以阐明如何在 App 和 BLE 设备之间实现安全机制(如加密)，以及在哪些级别(操作系统或应用程序级别)实现这些功能，我将非常感激。

Answer 1

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

蓝牙标准只有一个“用例”。此用例旨在提供一种方法来保护两个设备之间的链接，以便在绑定(bind)后，任何人都不能冒充设备或能够操纵或解密流量。您可能知道，“LE Legacy Pairing”是蓝牙 v4.1 之前指定的唯一配对方法，它有几个缺陷，如果攻击者在配对期间嗅探流量(“Just works”和“MITM/密码条目”，但不是 OOB)。然而，由蓝牙 v4.2 定义的新“LE 安全连接”使用 Diffie Hellman 使其更加安全。

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

1. 如果您已与设备配对。
2. 如果您与正版设备或中文副本通话。
3. 安全级别，即配对是否使用 Just Works、MITM 遗留配对或 LE 安全连接。
4. 如果当前链接是加密的。

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

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

不管怎样，如果你用自己的硬件开发自己的外设，想要使用蓝牙标准的配对/绑定(bind)/加密，BLE芯片厂商的SDK通常已经实现了。但是，您仍然需要正确设置它才能正常工作。通常你只需要配置一些参数(比如如果你有显示器或者用户可以输入密码)然后剩下的由他们的 SDK 在内部自动处理。

更新:

Android 的源代码可以在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 .