蓝牙协议分析(9)_BLE安全机制之LL Privacy

作者:wowo 发布于:2016-11-25 16:28 分类:蓝牙

1. 前言

在上一篇文章[1]中,我们介绍了BLE的白名单机制,这是一种通过地址进行简单的访问控制的安全机制。同时我们也提到了,这种安全机制只防君子,不防小人,试想这样一种场景:

A设备表示只信任B、C、D设备,因此就把它们的地址加入到了自己的白名单中,表示只愿意和它们沟通。与此同时,E设备对它们的沟通非常感兴趣,但A对自己不信任啊,肿么办?

E眼珠子一转,想出一个坏主意:把自己的地址伪装成成B、C、D中任意一个(这个还是很容易办到的,随便扫描一下就得它们的地址了)就行了,嘿嘿嘿!

那么问题来了,怎么摆脱“小人E“的偷听呢?不着急,我们还有手段:“链路层的Privacy(隐私)机制”。

2. LL Privacy机制介绍

总结来说,LL Privacy机制是白名单(white list)机制的进阶和加强,它在白名单的基础上,将设备地址转变成Private addresses[2]地址,以降低“小人E“窃得设备地址进而进行伪装的概率。

从白名单的角度看,Non-resolvable private address和Public Device Address/Static Device Address没有任何区别,因此LL Privacy机制主要指Resolvable Private Addresses。因此,LL Privacy机制的本质是:

通过Resolvable Private Addresses,将在空中传输的设备地址加密,让“小人E”无法窃得,从而增加其伪装的难度。

注1:当然,LL Privacy机制可以脱离白名单机制单独使用,不过这样的话好像没什么威力。

注2:有关Resolvable Private Addresses、Identity Address、IRK(Local/Peer IRK)等概念的详细介绍,可参考“蓝牙协议分析(6)_BLE地址类型[2]”,本文将会直接使用。

3. Resolving List

和白名单机制上的White List类似,如果设备需要使用LL Privacy机制,则需要在Controller端保存一个Resolving List,其思路为:

1)BLE设备要按照[1]中的介绍,配置并使能白名单机制,把那些受信任设备的地址(这里为Identity Address)加入到自己的白名单中,并采用合适的白名单策略。

2)如果设备需要使用LL Privacy策略,保护自己(以及对方)的地址不被窃取,则需要将自己(local)和对方(peer)的地址和加密key保存在一个称作Resolving List的列表中。

3)Resolving List的每一个条目,都保存了一对BLE设备的key/address信息,其格式为:Local IRK | Peer IRK | Peer Device Identity Address | Address Type。

Local IRK,本地的IRK,用于将本地设备的Identity Address转换为Resolvable Private Address。可以为0,表示本地地址直接使用Identity Address;

Peer IRK,对端的IRK,用于将对端设备的Resolvable Private Address解析回Identity Address。可以为零,表示对端地址是Identity Address;

Peer Device Identity Address、Address Type,对端设备的Identity Address及类型,用于和解析回的Identity Address进行比对。

4)Resolving List是Host通过HCI命令提供给Controller的,Controller的LL负责如下事项:

发送数据包[3]时:
如果有AdvA需要填充,则判断Resolving List是否有非0的Local IRK,如果有,则使用Local IRK将Identity Address加密为Resolvable Private Address,填充到AdvA中。否则,直接填充Identity Address;
同理,如果有InitA需要填充,则判断Resolving List是否有匹配的、非0的Peer IRK,如果有,则使用Peer IRK将对端的Identity Address加密为Resolvable Private Address,填充到InitA中。否则,直接填充Identity Address。

接收数据包时:
如果数据包中的AdvA或者InitA为普通的Identity Address,则直接做后续的处理;
如果它们为Resolvable Private Address,则会遍历Resolving List中所有的“IRK | Identity Address”条目,使用IRK解出Identity Address和条目中的对比,如果匹配,则地址解析成功,可以做进一步处理。如果不匹配,且使能了白名单/LL Privacy策略,则会直接丢弃。

5)需要重点说明的是,Controller和Host之间所有的事件交互(除了Resolving List操作之外),均使用Identity Address。也就是说,设备地址的加密、解密、比对等操作,都是在controller中完成的,对上层实体(HCI之上)是透明的。

4. 使用场景说明

结合上面2章的解释,罗列一下LL Privacy策略有关的使用场景(大部分翻译自蓝牙spec)。

4.1 设备处于广播状态(Advertising state)时

由[3]中的介绍可知,处于广播状态的BLE设备,根据需要可发送ADV_IND、ADV_DIRECT_IND、ADV_NONCONN_IND和ADV_SCAN_IND 4种类型的广播包,也就是说有4种不同的广播状态,它们的LL privacy策略有稍微的不同,下面分别描述。

1)ADV_IND

设备(Advertiser)发送ADV_IND时,其PDU(connectable undirected advertising event PDU)有一个AdvA字段,该字段的填充策略为(由controller的LL执行):

检查Resolving List,查看是否存在非0的Local IRK条目,如果有,则使用Local IRK将自己的Identity Address加密为Resolvable Private Addresses,并填充到AdvA中。否则,直接使用Identity Address。

Advertiser收到连接请求时,请求者的地址会包含在PDU的InitA中,该字段的解析策略为(由controller的LL执行):

如果InitA是Resolvable Private Addresses,且当前使能了地址解析功能,LL会遍历Resolving List中所有的“Peer IRK | Peer Device Identity Address | Address Type”条目,使用Peer IRK解析出Identity Address后和Peer Device Identity Address做比对,如果匹配,则解析成功,再基于具体的白名单策略,觉得是否接受连接;

如果解析不成功,则无法建立连接;

如果InitA不是Resolvable Private Addresses,则走正常的连接过程。

Advertiser收到扫描请求时,对ScanA的处理策略,和InitA类似。

2)ADV_DIRECT_IND

设备(Advertiser)发送ADV_DIRECT_IND 时,其PDU(connectable directed advertising event PDU)包含AdvA和InitA两个地址,它们填充策略为(由controller的LL执行):

检查Resolving List,查看是否存在非0的Local IRK条目,如果有,则使用Local IRK将自己的Identity Address加密为Resolvable Private Addresses,并填充到AdvA中。否则,直接使用Identity Address;

检查Resolving List,查看是否存在非0、和InitA的Identity Address匹配的Peer IRK条目,如果有,则使用Peer IRK将InitA的Identity Address加密为Resolvable Private Addresses,并填充到InitA中。否则,直接使用Identity Address。

Advertiser收到连接请求时,请求者的地址会包含在PDU的InitA中,该字段的解析策略为和上面ADV_IND类似,不再详细说明。

3)ADV_NONCONN_IND and ADV_SCAN_IND

这两个状态下,AdvA的填充策略和上面1)和2)一样,不再详细说明。

当Advertiser收到SCAN请求时,对ScanA的处理策略,和1)中InitA类似,不再详细说明。

4.2 设备处于扫描状态(Scanning state)时

处于Scanning状态的设备(Scanner)在接收到Advertiser发送的scannable的广播包时,需要按照4.1中解析InitA的方法,解析广播包中的AdvA,并根据当前的白名单策略,进行过滤。

Scanner发送scan请求时,需要指定ScanA和AdvA两个地址。其实ScanA的填充策略和4.1中的AdvA类似,不再详细说明。而AdvA,需要和接收到的广播包的AdvA完全一样,不能有改动。

4.3 设备处于连接状态(Initiating state)时

处于Initiating状态的设备(Initiator)在接收到Advertising发送的connectable的广播包时,需要按照4.1中解析InitA的方法,解析广播包中的AdvA,并根据当前的白名单策略,进行过滤。

同理,Initiator发送连接请求时,需要指定InitA和AdvA两个地址。其实InitA的填充策略和4.1中的AdvA类似,不再详细说明。而AdvA,需要和接收到的广播包的AdvA完全一样,不能有改动。

最后,Initiator在接收到Advertising发送的directed connectable广播包时,除了要解析AdvA,如果InitA是Resolvable Private Addresses,则需要使用Local IRK解析InitA。

5. 和LL Privacy有关的HCI命令

不太想写了,需要了解的直接去掰spec吧。

6. 参考文档

[1] 蓝牙协议分析(8)_BLE安全机制之白名单

[2] 蓝牙协议分析(6)_BLE地址类型

[3] 蓝牙协议分析(5)_BLE广播通信相关的技术分析

 

原创文章,转发请注明出处。蜗窝科技,www.wowotech.net

标签: 蓝牙 BLE resolvable privacy 安全

评论:

pang
2017-06-20 12:49
你好,
假设一个device A作为从设备, IOS手机作为主设备,IOS手机用的是resolvable address,在他们绑定之前,那么device A 怎么知道或者获取手机的IRK呢
zhay
2017-06-07 16:17
Hi wowo:

我对你文中“接收数据时,我们用Peer IRK解析出Identity Address后和Peer Device Identity Address做比对,如果匹配,则解析成功”这段话的理解有异议,请问如何用Peer IRK 解析出Identity Address?
因为你在《蓝牙协议分析(6)_BLE地址类型》一文中写到:Resolvable private address 是由IRK和Identity address进行hash运算得到的,而hash运算是不可逆的,见百度。即接收数据时,我们知道peer Resolvable private address, 是无法使用Peer IRK解析出Identity Address的。办法是用Resolving List中的peer IRK和prand也进行hash运算,再将hash运算结果和Resolvable private address中的hash段进行比较,如果匹配,则解析成功。你在《蓝牙协议分析(6)_BLE地址类型》中也是这么说的。
所以我认为用Peer IRK解析出Identity Address是错误的说法,无法解析。且接收数据时,我们只用Peer IDK进行hash运算即可,跟peer device identity address没什么关系。而peer device identity address的应用场景只有发送数据包时,有InitA需要填充的情况下,即发送ADV_DIRECT_IND广播时加密对端设备地址时用。
以上是我的理解,如有不对之处还请校正,THX!
wowo
2017-06-08 08:57
@zhay:Hi zhay,
多谢指正,你是对的,原谅我的不细致以及想当然吧!~~
确实,Private Device Address Resolution的过程,是不需要“Peer Device Identity Address”参与的,只需要对比hash即可。
Resolving List中之所以要保存“Peer Device Identity Address”,是为了和White List中做比对:在Resolution的过程中确定一个Resolving List中的条目,得到“Peer Device Identity Address”,并和White List中的条目比较。
再次感谢指正,有空我修改一下文章。
谢谢!!
zhay
2017-06-08 17:50
@wowo:@wowo,多谢回复。感觉这句话也有点问题:“使用Local IRK将Identity Address加密为Resolvable Private Address”,据spec,Resolvable Private Address是由IRK和随机数prand生成的,所以我的理解是Resolvable Private Address的生成和解析只于IRK有关.
我上段话中peer device identity address的应用场景有误,如你所说,是为了和白名单作对比。BLE设备在发起Advertising、Scanning或者Connecting操作的时候,都可以设置白名单策略。
wowo
2017-06-09 08:34
@zhay:是的,Identity Address和Resolvable Private Address没有任何关系。
dong
2017-09-03 19:59
@wowo:identity address应该是peer device的static address或者public address吧,每个device必须要有其中1个。假如两个device都使用privacy功能,就算双方在广播、连接之前都已将对方的IRK固化在程序里,可是整个广播连接过程也无法知道对方的identity address吧(只能知道双方的resolvable/non-resolvable address),在我看来只有在pairing的phase 3阶段时候交换双方的identity address information时候才能让双方都拥有对方的identity address,求wowo指导啊。
wowo
2017-09-04 10:17
@dong:你总结的很对啊,呵呵~~
LL privacy是比较简单的安全机制,如果两个设备打算“更深一步的交流”,使用配对、绑定等更强大的安全机制,则本文所涉及的内容就out了。这时双方就应该坦诚相见,把自己的identity address告知对方。
panda
2017-04-07 15:13
Hi wowo,
LL Privacy机制是白名单(white list)机制的进阶和加强。LL Privacy机制可以脱离白名单机制单独使用,不过这样的话好像没什么威力。
---------------------------------------------------------------------------------
这有点矛盾。LL Privacy机制是白名单的升级版本,完全覆盖了白名单的功能。所以单独使用LL Privacy机制是很自然的选择。是这样理解吗?
wowo
2017-04-10 09:13
@panda:这里的意思是:
LL Privacy是通过加密蓝牙地址的手段保证通信安全;
而白名单功能是通过过滤不信任的地址,保证通信安全;
从本质上讲,它们两个没有关系;
但是,如果不过滤非法地址,加密自己的地址又有什么意义呢?
panda
2017-04-10 09:27
@wowo:如果蓝牙地址解析不成功,则无法建立连接;这就起到了过滤的作用了。
如果再增加白名单,相当于double check。
wowo
2017-04-10 16:15
@panda:如果“地址解析不成功“,就“……(无法建立连接)”,后面这一段省略号,正是白名单的策略。
也就是说,当地址解析不成功的时候,要怎么处理,正是白名单的一部分。所以无论如何,白名单都在的,呵呵~~
panda
2017-04-10 19:24
@wowo:我再查看了spec(BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B] 4.7 RESOLVING LIST)
The Identity Address may be in the White List.

我的理解是:resolving List中的Peer_Identity_Address_Type/
Peer_Identity_Address可以占用一条White List,也可以不占用White List,而在resolving List中单独实现类似的WhiteList。
这可能和linklayer的具体实现相关了。

我现在用的ble芯片,一条White List占用8个bytes,一条resolving List占用68Bytes。WhiteList和Resolving List应该就是独立实现的。

两种说法都能成立,呵呵
wowo
2017-04-11 13:56
@panda:抱歉,我上面的回复有些问题,我们慢慢的再梳理一下:
1. 本设备的resolve list中,保存了一些这样的条目,Local IRK | Peer IRK | Peer Device Identity Address | Address Type
2. 本设备收到其它设备的广播信息时,如果发现peer地址为resolvable address,则尝试遍历自己的resolve list,使用IRK解析resolvable address并和Peer Device Identity Address比较。
3. 如果resolvable address解析成功:
    a)如果没有使能白名单机制,则进行后续的操作。
    b)如果使能了白名单机制,则根据具体的白名单策略(此时对比的是解析后的Peer Device Identity Address),决定后续的动作。
4. 如果resolvable address解析不成功:
    a)拒绝后续的操作(此时不依赖白名单机制)。

回到我们这个话题上:
LL Privacy确实可以单独存在,但二者的功能不完全相同。
白名单的思路是:只有我认识的(放在了白名单中)才是好人,我才愿意和你玩。
LL Privacy的思路是:只有能和我对上暗号的才是好人,我才愿意和你玩。
二者加在一起的思路是:只有我认识的并且能和我对上暗号的,我才愿意和你玩。潜在的思路是什么,可以在实际的应用场景中挖掘。
panda
2017-04-11 15:33
@wowo:梳理的很清楚,赞~

使用IRK解析resolvable address并和Peer Device Identity Address比较。
~~~~·这里已经是白名单的思路,所以privacy的思路包含了白名单的思路。LL Privacy的思路已经是“能和我对上暗号并且是我认识的,我才愿意和你玩。
chong
2017-03-15 17:06
写的真好,看英文版的spec很是烧脑,看了您写的这些关于蓝牙的知识,感觉学到了很多呢,真心感谢
miranda
2017-01-20 15:20
wowo好棒
把死板的spec讲解的这么细致又通俗易懂,期待讲解ble的pairing和bonding~
AndyPeng
2016-12-06 14:15
hi,wowo同志,请问蓝牙的安全机制怎么实现,即便监听者在配对开始时就监听也是无法解密加密数据?因为用蓝牙分析仪也是必须填写link key才能破解;谢谢!
AndyPeng
2016-12-06 14:17
@AndyPeng:我的理解是既然监听是全程的窥视,双方没有‘秘密’,怎么实现加密,想不明白;
wowo
2016-12-06 14:51
@AndyPeng:虽然监听是全程的窥视,但也只能窥视到空中传输的信息,但蓝牙的安全机制里面,有一个东西(pincode,或者说link key),不会在空中传输。这就保证了窥视者无法解密。
wowo
2016-12-06 14:52
@wowo:顺便多说一句,空中传输的是加密后的密文,如果有人能从密文里解出key,就可以破解了(这是有可能的)。
AndyPeng
2016-12-06 15:09
@wowo:感谢这么及时的回复,刚才也度娘了一下,也基本了解了,justwork方式在配对过程中是不提供MITM保护的;我起初误解以为justwork是受到MITM保护,因为这是无法理解的事情;谢谢!
chen_chuang
2016-12-02 14:49
wowo大神,有没有讲解蓝牙室内定位的计划
wowo
2016-12-03 11:10
@chen_chuang:帅锅,不要叫大神啊,不敢当啊!!
暂时没有涉及到室内定位的打算啊,因为觉得和蓝牙的关系不大啊,室内定位的关键点在于拿到TX Power和RSSI之后的算法吧?

发表评论:

Copyright @ 2013-2015 蜗窝科技 All rights reserved. Powered by emlog