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

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。

------------恢复内容开始------------

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。

------------恢复内容结束------------

原文地址:https://www.cnblogs.com/cs794440465/p/13560731.html