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]时： 接收数据包时： |
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。
