蓝牙模块的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.cbluedroid模块中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合入该补丁并不会影响系统功能。

参考

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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,445评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,889评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,047评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,760评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,745评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,638评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,011评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,669评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,923评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,655评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,740评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,406评论 4 320
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,995评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,961评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,197评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,023评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,483评论 2 342