蓝牙模块的bluedroid

什么是Bluedroid？

总的来说，bluedroid就是在安卓上替代bluez的一个蓝牙协议栈。Android 4.2之前，Google一直使用的是Linux官方蓝牙协议栈BlueZ。BlueZ实际上是由高通公司在2001年5月基于GPL协议发布的一个开源项目，做为Linux 2.4.6内核的官方蓝牙协议栈。随着Android设备的流行，BlueZ也得到了极大的完善和扩展。例如Android 4.1中BlueZ的版本升级为4.93，它支持蓝牙核心规范4.0，并实现了绝大部分的Profiles。
从Android 4.2开始，Google便在Android源码中推出了它和博通公司一起开发的BlueDroid以替代BlueZ。BlueZ的创始者，高通公司也将在基于其芯片的Android参考设计中去除BlueZ，支持BlueDroid。
相比BlueZ，BlueDroid最值得称道的地方就是其框架结构变得更为简洁和清晰。

Android4.2中的BlueDroid框架结构图

bluedroid整体协议栈架构

bluedroid的源码在android/external/bluetooth/bluedroid目录下，从目录上来看bluedroid似乎是安卓系统中外来的东西，因为它在external中。的确是这样，bluedroid协议栈最早是broadcom公司编写的一套用于实现蓝牙协议的协议栈，后来不断完善，最终被google采纳。所以bluedroid不是安卓原生的东西。根据bluedroid目录下的Android.mk文件来看，bluedroid最终会编译生成一个动态库，也就是说它实现了很多函数可以被人调用。这个库会在蓝牙启动过程中被加载。那么这个库中的函数怎么调用呢？

bluedroid调用结构图

从上图可以看出，bluedroid协议栈是在user space的。应用层或framework层通过jni进入协议栈的btif(bluetooth interface)中，btif是应用程序通过jni进入协议栈库的入口；然后会调用到bta(bluetooth application)中，这里面是bluetooth的各种profile在协议栈中的实现；之后会进入stack(bluedroid stack)，这里是bluedroid的核心实现，实现蓝牙的各种标准机制。

近期在看关于Bluetooth bluedroid模块的一个漏洞问题：
5.1之前的Android中的btif / src / btif_dm.c不能正确执行蓝牙配对的临时性，这允许用户协助的远程攻击者在点击了精心制作的NFC标签后，通过精心制作的蓝牙数据包绕过了预期的访问限制。
谷歌官方已发布CVE-2014-7914来修复此漏洞。见：https://android.googlesource.com/platform/external/bluetooth/bluedroid/+/0360aa7c418152a3e5e335a065ac3629cbb09559%5E%21/#F0
这个漏洞目测是由于上一个临时配对的请求状态设置延迟，而下一个请求的时候绑定状态被memset为0的场景。临时配对的is_temp状态值应该为1，由于延时被memset为0。操作被误当成持久配对，而错误的存储了链接密钥。补丁将标志反转为“负”标志。重命名为“ persistent_bond”，默认为0，现在用于表示临时债券。如果延迟设置不正确，则默认为临时绑定，不会错误地保存链接密钥。

分析之前先来了解一下蓝牙的分类。

BT和BLE？

蓝牙是一种短距的无线通讯技术，可实现固定设备、移动设备之间的数据交换。一般将蓝牙3.0之前的BR/EDR蓝牙称为传统蓝牙，而将蓝牙4.0规范下的LE蓝牙称为低功耗蓝牙。

蓝牙模块

第一次接触蓝牙，分析这个问题花了很多时间找关于临时配对的概念和流程。蓝牙的配对和bluedroid协议栈有着紧密的联系。

漏洞的btif_dm.c是bluedroid模块中BTIF层的有关设备管理的文件，进行配对时，pairing_cb.is_temp标志指示是否配对是暂时的或永久的。
调查后才知道，临时配对是BLE框架中的SMP(Security Manage Protocol)部分的概念，也称SM，是蓝牙用来进行安全管理的，其定义了配对和密钥分发的过程实现。看一下SM在蓝牙模块中的位置：

低功耗蓝牙体系结构

SMP被用在LE-only设备或蓝牙双模设备中。SM是使用一种密钥分发的方式来实现识别BLE数据加密和解密的功能。连接建立之后，双方通过某些方式协商共同的密钥，然后将后续要传输的数据用这个密钥通过加密算法进行加密，实际传送到空中的数据是加密后的数据，接收到数据后，必须用对应的密钥解密后才能得到正确的数据。当然，这种方式的加密，破解方式就是得到其密钥即可。

蓝牙SMP如何配对？

配对过程开始时，第一阶段是双方交换支持的配对特征，如果有一方不支持配对，就不会进行配对，如果都支持配对，会选择合适的方法进行配对。

安全属性-Security Properties:
分为如下几类安全属性：

• LE Secure Connections pairing（BT4.2才支持）；
• Authenticated MITM protection（有人参与干涉的安全，可以是人输入密码，或者通过OOB获取密码，对于Secure Connections还支持数字比较的方式）；
• Unauthenticated no MITM protection；
• No security requirements；

配对特征:
首先看下这个配对特征的内容都有哪些（前三个将决定配对第二阶段的key生成方法）：

• IO capability(表明输入，输出的能力。输入是按键、键盘，输出是显示数字用的界面。)；
• OOB；
• authentication requirements；
• key size；
• key distribute。

配对算法:
在交换配对特征后，这些特征内容将会用来选择确认用哪种Key生成方法：
1、Just Works 直接连接
2、Numeric Comparison 数值比较（仅用于LE Secure Connections）
3、Passkey Entry 输入密钥
4、Out of Band（OOB） 带外（很少用到）

这四种方法和IO能力、鉴权要求、OOB鉴权数据等，会决定LE Legacy pairing和LE Secure Connections中生成密钥的算法。
Pairing Request PDU中的SC位决定了设备支持哪种配对方式，当Initiator和Responder都支持LE Secure Connections的时候，则使用LE Secure Connections。否则，使用LE legacy pairing。
• 如果双方都支持OOB Authentication，则选择该方式（优先级最高）。
• 如果双方都支持MITM Authentication，则根据双方的IO Capabilities（并结合具体的配对方法），选择合适的Authentication方式。
• 否则，使用Just Works的方式。
LE是“low energy”的缩写，是蓝牙4.0及以上版本的主要功能之一。在蓝牙4.2规范中，添加了LE物理传输的安全连接特性，升级了对蓝牙LE物理传输的配对，使用了FIPS-approved的算法(AES-CMAC和P-256椭圆曲线)。为了区分蓝牙4.0和4.1规范中定义的安全连接和配对，将其称为LE legacy pairing，而到蓝牙4.2版本后增加了LE Secure Connections的模式。

配对中产生的密钥(Key):
LE legacy pairing

• Temporary Key(TK)：临时密钥，短暂存在的Key，128-bit，用来产生STK的；
• Short Term Key(STK)：128-bit，会被用来加密配对后的链路。

LE Secure Connections

• Long Term Key(LTK)：128-bit，会被用来加密配对后的链路

比如Temperary Key的生成：如Just Works，Passkey Entry，OOB都可以用来生成TK，不同的Authentication获取TK的方式不同：
• OOB:get from OOB data.
• Passkey Entry: user input passkey.
• Just Works: zero.
我们配对后往往需要将一些信息（TK, LTK等）存下来，这个过程是蓝牙的绑定。绑定只是物理性的保存某些encrypted数据在芯片的Flash中。

结合Android源码，弄懂了bluedroid的蓝牙配对绑定流程，就可以构建临时配对场景来测试了。

Step 1:合入patch并将追踪的log添加到补丁所在的函数

The log of bond_state_changed() function

The log of btif_dm_ssp_cfm_req_evt() function

The log of btif_dm_auth_cmpl_evt() function

Step2：操作另一台蓝牙设备（无输入和输出功能）与主设备配对，模拟临时配对的场景来走到补丁处，触发补丁处的代码。

Step3：抓取log并分析。

log显示程序走到了漏洞修复处的代码

补丁处的代码被程序走到且打印出了添加的日志，系统正常运行。经验证，Android4.2合入该补丁并不会影响系统功能。

参考

• 蓝牙协议标准_Core_v5.0 Vol3 PartH
• https://blog.csdn.net/qq_21231413/article/details/89174917
• https://blog.csdn.net/yurhzzu/article/details/89134937
• https://www.cnblogs.com/lim11/p/11158153.html
• https://blog.csdn.net/xubin341719/article/details/40378205
• https://www.jianshu.com/p/b490bed77e23
• https://www.sohu.com/a/167206747_404276

*引用转载本文需注明出处