1. 前言

在万物联网的时代，安全问题将会受到非常严峻的挑战（相应地，也会获得最大的关注度），因为我们身边的每一个IOT设备，都是一个处于封印状态的天眼，随时都有被开启的危险。想想下面的场景吧：

凌晨2点，x米手环的闹钟意外启动，将你从睡梦中惊醒，然后床头的灯光忽明忽暗……
你的心率、血压、睡眠质量等信息，默默地被竞争对手收集着，并通过大数据分析你的情绪、健康等，随时准备给你致命一击……
我知道你家里有几盏灯、几台电器、几个人，知道你几点睡觉几时醒来，知道你一周做过几顿饭，甚至知道你有一个xx棒、一周使用几次、每次使用多久……
……

算了，不罗列了，有时间的话可以建个iot eyes的站点，专门收集、整理物联网安全有关的内容。这里就先言归正传。

经过前面几篇的蓝牙协议分析，我们对蓝牙（特别是蓝牙低功耗）已经有了一个比较全面的了解。随后几篇文章，我会focus在BLE的安全机制上。毕竟，知己知彼，才能攻防有度。

话说，蓝牙SIG深知物联网安全的水有多深，因此使用了大量的篇幅，定义BLE安全有关的机制，甚至可以不夸张的说，BLE协议中内容最多、最难理解的部分，非安全机制莫属。本文先从介绍最简单的—-白名单机制（White list）。

2. 白名单机制

白名单（white list）是BLE协议中最简单、直白的一种安全机制。其原理很简单，总结如下（前面的分析文章中都有介绍）：

所谓的白名单，就是一组蓝牙地址；
通过白名单，可以只允许特定的蓝牙设备（白名单中列出的）扫描（Scan）、连接（connect）我们，也可以只扫描、连接特定的蓝牙设备（白名单中列出的）。

例如，如果某个BLE设备，只需要被受信任的某几个设备扫描、连接，我们就可以把这些受信任设备的蓝牙地址加入到该设备的白名单中，这样就可以有效避免其它“流氓设备”的骚扰了。

不过呢，该机制只防君子不防小人，因为它是靠地址去过滤“流氓”的，如果有些资深流氓，伪装一下，将自己的设备地址修改为受信任设备的地址，那就惨了……

3. 白名单有关的HCI命令

注1：本文主要从HCI的角度分析、介绍，如非必要，不再会涉及HCI之下的BLE协议（后续的分析文章，也大抵如此）。

3.1 白名单维护相关的命令

BLE协议在HCI层定义了4个和白名单维护有关的命令，分别如下：

1）LE Read White List Size Command，获取controller可保存白名单设备的个数

该命令的格式为：

OCF	Command parameters	Return Parameters
0x000F		Status White_List_Size

Status，命令执行的结果，0为success。
White_List_Size，size，范围是1～255。

注2：由此可知，白名单是保存在controller中，由于size的范围是1～255，因此controller必须实现白名单功能（最少保存一个）。

2）LE Clear White List Command，将controller中的白名单清空

该命令的格式为：

OCF	Command parameters	Return Parameters
0x0010		Status

Status，命令执行的结果，0为success。

3）LE Add Device To White List Command，将指定的设备添加到白名单

该命令的格式为：

OCF	Command parameters	Return Parameters
0x0011	Address_type(1 byte) Address(6 bytes)	Status

Address_type，设备的地址类型[1]，0为Public Device Address，1为Random Device Address。
Address，设备的地址。
Status，命令执行的结果，0为success。

4）LE Remove Device From White List Command，将指定的设备从白名单中移除的命令

该命令的格式为：

OCF	Command parameters	Return Parameters
0x0012	Address_type(1 byte) Address(6 bytes)	Status

Address_type，设备的地址类型[1]，0为Public Device Address，1为Random Device Address。

Address，设备的地址。

Status，命令执行的结果，0为success。

最后需要说明的是，当controller处于以下三个状态的时候，以上命令除“LE Read Resolving List Size Command”外，均不能执行：

正在advertising；
正在scanning；
正在connecting。

3.2 白名单使用策略有关的命令

BLE设备在发起Advertising、Scanning或者Connecting操作的时候，可以通过Set Advertising Parameters、Set Scan Parameters或者LE Create Connection Command，设置Advertising、Scanning或者Connecting的过滤策略（Filter_Policy），具体如下：

1）Advertising时的白名单策略

LE Set Advertising Parameters Command的命令格式为：

OCF	Command parameters	Return Parameters
0x0006	… Advertising_Filter_Policy(1 byte)	Status

该命令的其它参数请参考[2]，Advertising_Filter_Policy的含义如下：

0x00，禁用白名单机制，允许任何设备连接和扫描。
0x01，允许任何设备连接，但只允许白名单中的设备扫描（scan data中有敏感信息？）。
0x02，允许任何设备扫描，但只允许白名单中的设备连接。
0x03，只允许白名单中的设备扫描和连接。

2）Scanning时的白名单策略

LE Set Scan Parameters Command的命令格式为：

OCF	Command parameters	Return Parameters
0x000B	… Scanning_Filter_Policy(1 byte)	Status

该命令的其它参数请参考[2]，Scanning_Filter_Policy的含义如下：

0x00，禁用白名单机制，接受所有的广播包（除了那些不是给我的directed advertising packets）。
0x01，只接受在白名单中的那些设备发送的广播包（除了那些不是给我的directed advertising packets）。
0x02，和白名单无关，不再介绍。
0x03，接受如下的广播包：在白名单中的那些设备发送的广播包；广播者地址为resolvable private address的directed advertising packets；给我的给我的directed advertising packets。

注3：Scanning时的白名单策略有点奇怪，既然是主动发起的，要白名单的意义就不大了吧？难道只为了减少host的响应耗电？

3）Connecting时的白名单策略

LE Create Connection Command的命令格式为：

OCF	Command parameters	Return Parameters
0x000D	… Initiator_Filter_Policy(1 byte) …	Status

该命令的其它参数请参考[4]，Initiator_Filter_Policy的含义如下：

0x00，禁用白名单机制，使用Peer_Address_Type and Peer_Address指定需要连接的设备。
0x01，连接那些在白名单中的设备，不需要提供Peer_Address_Type and Peer_Address参数。

4. 使用示例

4.1 准备工作

后续的测试需要用到如下的设备和软件：

1）蓝牙设备A，作为Advertiser，发送广播数据，接受连接。

2）蓝牙设备B，作为Scanner，扫描设备A的广播数据，发起连接。

上述的1）和2）可以是如下一种：

一个具有bluez（hcitool等工具）的Android手机，可能需要较旧的android版本才行；
带有蓝牙功能的树莓派，允许Debian、Ubuntu等系统（只要不是Android就行）；
Linux PC（或者虚拟机）加上一个具有BLE功能的蓝牙适配器。

3）bluez工具集，我们需要使用其中的hcitool命令。

4.2 相关的hcitool命令说明

hcitool中的一些命令，和白名单机制有关，总结如下。

1）hcitool lewlsz，获取controller白名单的size，对应3.1中的LE Read White List Size Command，该命令不需要参数，可直接使用，如下：

root@android:/ # hcitool lewlsz
hcitool lewlsz
White list size: 26

2）hcitool lewlclr，情况controller的白名单，对应3.1中的LE Clear White List Command，该命令也不需要参数，可直接使用，如下：

root@android:/ # hcitool lewlclr
hcitool lewlclr

3）hcitool lewladd，将指定设备添加到白名单中，对应3.1中的LE Add Device To White List Command，其格式如下：

root@android:/ # hcitool lewladd --help
hcitool lewladd --help
Usage:
lewladd [--random]

其中是必选项，为要添加的蓝牙设备的地址。地址有public和random两种，默认是public，如果需要添加random类型的地址，则要指定–random参数，例如：

root@android:/ # hcitool lewladd 22:22:21:CD:F4:58
hcitool lewladd 22:22:21:CD:F4:58

root@android:/ # hcitool lewladd --random 11:22:33:44:55:66
hcitool lewladd --random 11:22:33:44:55:66

4）hcitool lewlrm，将指定设备从白名单中移除，对应3.1中的LE Remove Device From White List Command，该命令只需要蓝牙地址作为参数，如下：

root@android:/ # hcitool lewlrm --help
hcitool lewlrm --help
Usage:
lewlrm

5）hcitool lecc，连接BLE设备的命令，对应3.2中的LE Create Connection Command，可以连接指定地址的设备，也可以直接连接白名单中的设备：

root@android:/ # hcitool lecc --help
hcitool lecc --help
Usage:
lecc [--random]
lecc --whitelist

一般情况下，我们都是通过hcitool lecc 的方式连接蓝牙设备，不过如果我们需要连接白名单中的设备，可直接使用如下命令：

hcitool lecc --whitelist

6）hcitool cmd，对于其它没有直接提供hcitool命令的HCI操作，我们可以使用hcitool cmd直接发送命令，其使用方法如下：

root@android:/ # hcitool cmd --help
hcitool cmd --help
Usage:
cmd [parameters]
Example:
cmd 0x03 0x0013 0xAA 0x0000BBCC 0xDDEE 0xFF

其中ogf、ocf和parameters可以去蓝牙spec的“HCI COMMANDS AND EVENTS”章节查询。需要注意的是，parameters可以使用各种类型（8位、16位、32位），还是很方便的。

4.3 测试步骤

这里仅仅罗列一个简单的测试，步骤包括：

1）设备A作为Advertising设备，不使用白名单，发送正常的ADV_IND（可连接、可扫描）广播包。
2）设备B扫描并连接设备A（应该可以正常连接）。
3）设备A作为Advertising设备，启用白名单，设置Advertising_Filter_Policy为0x2(只允许白名单中的设备连接)，且没有把B的地址添加到白名单中。
4）设备B扫描并连接设备A（应该不可以正常连接）。
5）设备A把设备B添加到白名单中，其它策略保持不变。
6）设备B扫描并连接设备A（应该可以正常连接）。

详细步骤如下（我没有测试，有问题的请大家留言告诉我）：
1）设备A作为Advertising设备，不使用白名单，发送正常的ADV_IND（可连接、可扫描）广播包。

# disable BLE advertising
hcitool cmd 0x08 0x000A 0x00

# 设置广播参数和广播策略
# Advertising_Interval_Min=0x0800 (1.28 second, default)
# Advertising_Interval_Max=0x0800 (1.28 second, default)
# Advertising_Type=0x00(ADV_IND, default)
# Own_Address_Type=0x00(Public Device Address, default)
# Peer_Address_Type=0x00(Public Device Address, default)
# Peer_Address=00 00 00 00 00 00 (no use)
# Advertising_Channel_Map=0x07(all channels enabled, Default)
# Advertising_Filter_Policy=0x0(禁用白名单)
hcitool -i hci0 cmd 0x08 0x0006 0x0800 0x0800 0x00 0x00 0x00 00 00 00 00 00 00 0x07 0x00

# enable BLE advertising
hcitool cmd 0x08 0x000A 0x01

# set advertising data to Eddystone UUID(可参考[3]中的介绍)
hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00

2）设备B扫描并连接设备A（应该可以正常连接）。

hcitool lescan
hcitool lecc [bdaddr of A]

3）设备A作为Advertising设备，启用白名单，设置Advertising_Filter_Policy为0x2(只允许白名单中的设备连接)，且没有把B的地址添加到白名单中。

# disable BLE advertising
hcitool cmd 0x08 0x000A 0x00

# 设置广播参数和广播策略
# …
# Advertising_Filter_Policy=0x2(只允许白名单中的设备连接)
hcitool -i hci0 cmd 0x08 0x0006 0x0800 0x0800 0x00 0x00 0x00 00 00 00 00 00 00 0x07 0x02

# 清空白名单
hcitool lewlclr

# 随便加一个地址到白名单
hcitool lewladd 11:22:33:44:55:66
# enable BLE advertising
hcitool cmd 0x08 0x000A 0x01

# set advertising data to Eddystone UUID(可参考[3]中的介绍)
hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00

4）设备B扫描并连接设备A（应该不可以正常连接）。

hcitool lescan
hcitool lecc [bdaddr of A]

5）设备A把设备B添加到白名单中，其它策略保持不变。

# disable BLE advertising
hcitool cmd 0x08 0x000A 0x00

# 设置广播参数和广播策略
# …
# Advertising_Filter_Policy=0x2(只允许白名单中的设备连接)
hcitool -i hci0 cmd 0x08 0x0006 0x0800 0x0800 0x00 0x00 0x00 00 00 00 00 00 00 0x07 0x02

# 将B添加到白名单中
hcitool lewladd [bdaddr of B]
# enable BLE advertising
hcitool cmd 0x08 0x000A 0x01

# set advertising data to Eddystone UUID(可参考[3]中的介绍)
hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00

6）设备B扫描并连接设备A（应该可以正常连接）。

hcitool lescan
hcitool lecc [bdaddr of A]

5. BLE安全机制之LL Privacy

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

A设备表示只信任B、C、D设备，因此就把它们的地址加入到了自己的白名单中，表示只愿意和它们沟通。与此同时，E设备对它们的沟通非常感兴趣，但A对自己不信任啊，肿么办？
E眼珠子一转，想出一个坏主意：把自己的地址伪装成成B、C、D中任意一个（这个还是很容易办到的，随便扫描一下就得它们的地址了）就行了，嘿嘿嘿！

那么问题来了，怎么摆脱“小人E“的偷听呢？不着急，我们还有手段：“链路层的Privacy（隐私）机制”。

6. 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]”，本文将会直接使用。

7. 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之上）是透明的。

8. 使用场景说明

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

8.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类似，不再详细说明。

8.2 设备处于扫描状态（Scanning state）时

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

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

8.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。

 

 

9. 参考文档

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

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

[3] 玩转BLE(1)_Eddystone beacon

[4] 蓝牙协议分析(7)_BLE连接有关的技术分析

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

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

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

[8] Core_v4.2.pdf

摘自:

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

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

蓝牙协议分析(10)_BLE安全机制之LE Encryption

蓝牙协议分析(11)_BLE安全机制之SM