蓝牙低能耗安全如何在Android应用和BLE设备之间起作用?

时间:2017-06-10 10:54:55

标签: android security encryption bluetooth bluetooth-lowenergy

我正在研究蓝牙低功耗(BLE)协议(v4.2),特别是其安全功能。 我试图理解移动应用程序和BLE设备之间传输的数据加密是如何工作的。

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

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

第二个疑问: 为什么有些BLE设备在GATT协议之上实现自己的加密,而不是使用SIG提供的安全功能?

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

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

1 个答案:

答案 0 :(得分:9)

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

蓝牙标准只有一个“用例”。该用例是提供一种用于保护两个设备之间的链路的方法,使得在绑定之后,没有人应该能够模仿设备或能够操纵或解密流量。正如您现在所说的那样,“LE Legacy Pairing”是蓝牙v4.1中唯一指定的配对方法,如果攻击者在配对过程中嗅探流量(“Just works”和“MITM”),它有几个缺陷会使其不安全/ passkey条目“,但不是OOB)。然而,蓝牙v4.2定义的新“LE安全连接”使用Diffie Hellman使其更安全。

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

  1. 如果您已与设备配对。
  2. 如果您使用的是正版设备或中文副本。
  3. 安全级别,即配对使用Just Works,MITM传统配对或LE安全连接。
  4. 如果当前链接已加密。
  5. Android更好一点。应用程序至少可以知道设备是否已绑定(但不是其他三个)。还有一个API“createBond”来启动绑定过程。 Windows API在这方面要好得多,因为您可以在执行GATT操作时强制执行加密链接。

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

    无论如何,如果您使用自己的硬件开发自己的外围设备并希望使用蓝牙标准的配对/绑定/加密,那么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找到。