【IoT】加密与安全：蓝牙 BLE 安全机制之 LE 加解密与 SMP 解析

虽然蓝牙协议支持的安全机制安全性一般，但仍然值得了解一下。

BLE 的 LE 加密模式是由链路层（LL，Link Layer - 从安全和通信效率的角度）在发送/接收数据时完成加密/解密动作。

1、数据加密/解密过程

LE 加密/解密的过程如下图所示：

Master/Slave 的 LE Host 会保存一个 LTK（Long Term Key，至少 128bits），对 BLE 应用来说，这个 Key 是所有加密/解密动作源头。

每当为某个 LE 连接启动加密传输的时候，Master 和 Slave 的 LL 会协商生成一个 128bits 的随机数 SKD（Session Key Diversifier，128bits），并以它为输入，以 LTK 为 key，通过 Encryption Engine 加密生成 SessionKey。

每当有明文数据包需要发送的时候，需要对明文进行加密。

加密的过程，是以明文数据包为输入，以 SessionKey 为 Key，同样通过 Encryption Engine 加密生成密文数据包。

同样，每当收到密文数据包的时候，需要对密文解密。

解密的过程，是以密文数据包为输入，以 SessionKey 为 Key，同样通过 Encryption Engine 解密生成明文数据包。

2、加密流程

LE Encryption 加密过程主要由 Link Layer 控制，当连接建立之后，Link Layer 根据 Host 的请求使能对数据包的 Encryption 操作。

1）Host A 发送 LE Start Encryption HCI 命令，请求 Link Layer 启动加密。

该命令的格式如下：

Connection_Handle：连接句柄；

Random_Number 和 Encrypted_Diversifier 分别简称为 Rand 和 EDIV（Rand 是一个 64bits 的随机数，EDIV 是一个 16bits 的 Diversifier）；

它们在 LE Legacy Pairing 的过程中，用于在多个 LTK 标识某一个具体的 LTK；

而在新的 LE Secure Connections Pairing 过程中，则不再使用（赋值为 0 即可）；

Long_Term_Key：保存在 Host 段的加密 key。

2）LL A 收到 Host 的加密请求之后，会向 LL B 发送 LL_ENC_REQ PDU 以请求加密。

该 PDU 的格式为：

Rand 和 EDIV 就是上面的 Random_Number 和 Encrypted_Diversifier； 

SKDm（session key diversifier）：是一个 64bits 的随机数，用于和 SKDs 一起生成本次加密的 SessionKey； 

IVm（initialization vector ）：32bits 的随机数，和 IVs 一起组成 64bits 的 IV，后面 Encryption Engine 会使用。

3）LL B 收到 LL_ENC_REQ PDU 之后，会向 Host B 发送 LE Long Term Key Request HCI Event。

该 Event 的格式为：

Subevent_Code：0x05；

Connection_Handle：连接句柄；

Random_Number 和 Encrypted_Diversifier 就是 LL_ENC_REQ PDU 中的 Rand 和 EDIV，最初是由 Host A 通过 LE Start Encryption 命令发送过来的。

4）如果 Host B 能提供 LTK，则通过 LE Long Term Key Request Reply HCI 命令，将 LTK 提供给 LL B。

该命令的格式为：

5）LL B 收到 LTK 之后，会向 LL A 回应一个 LL_ENC_ RSP PDU。

该 PDU 的格式为：

SKDs 和 LL A 的 SDKm 共同组成 128bits 的 SKD； 

IVs 和 LL A 的 IVm 共同组成 64bits 的 IV。

6）LL A 收到 LL_ENC_ RSP PDU 之后，可以向 LL B 发送 LL_START_ENC_REQ PDU，开启 Encryption，LL B 则回应 LL_START_ENC_RSP PDU，这两个 PDU 均不携带任何的参数。

加密 start 之后，双方就可以安全的通信了。

当然，LE encryption 还提供了其它诸如暂停加密（LL_PAUSE_ENC_REQ/LL_PAUSE_ENC_RSP）、重启加密等过程。

3、广播模式

BLE 中有两种角色 Central 和 Peripheral ，也就是中心设备和外围设备。

中心设备可以主动连接外围设备，外围设备发送广播或者被中心设备连接。

外围通过广播被中心设备发现，广播中带有外围设备自身的相关信息。

广播包有两种：

广播包 （Advertising Data）和 响应包 （Scan Response），其中广播包是每个设备必须广播的，而响应包是可选的。

每个包都是 31 字节，数据包中分为有效数据（significant）和无效数据（non-significant）两部分。

有效数据部分：

包含若干个广播数据单元，称为 AD Structure 。

AD Structure 的组成是：第一个字节是长度值 Len ，表示接下来的 Len 个字节是数据部分。

数据部分的第一个字节表示数据的类型 AD Type ，剩下的 Len - 1 个字节是真正的数据 AD data。

其中 AD type 非常关键，决定了 AD Data 的数据代表的是什么和怎么解析；

无效数据部分：

广播包的长度必须是 31 个字节，如果有效数据部分不到 31 字节，剩下的就用 0 补全。

广播数据格式：

Flags 字段: 

TYPE = 0x01

这个数据用来标识设备 LE 物理连接的功能。

DATA 是 0 到多个字节的 Flag 值，每个 bit 上用 0 或者 1 来表示是否为 True。

如果有任何一个 bit 为 1，并且广播包是可连接的，就必须包含此数据。

各 bit 的定义如下：

bit 0: LE 有限发现模式
bit 1: LE 普通发现模式
bit 2: 不支持 BR/EDR
bit 3: 对 Same Device Capable(Controller) 同时支持 BLE 和 BR/EDR
bit 4: 对 Same Device Capable(Host) 同时支持 BLE 和 BR/EDR
bit 5..7: 预留

Service UUID: 

广播数据中一般都会把设备支持的 GATT Service 广播出来，用来告诉外面本设备所支持的 Service。

有三种类型的 UUID：

16 bit, 32bit, 128 bit。

广播中，每种类型类型有有两个类别：完整和非完整的，共有 6 种 AD Type。

非完整的 16 bit UUID 列表：TYPE = 0x02;

完整的 16 bit UUID 列表：TYPE = 0x03;

非完整的 32 bit UUID 列表：TYPE = 0x04;

完整的 32 bit UUID 列表：TYPE = 0x05;

非完整的 128 bit UUID 列表：TYPE = 0x06;

完整的 128 bit UUID 列表：TYPE = 0x07;

Local Name: 设备名字，DATA 是名字的字符串。

Local Name 可以是设备的全名，也可以是设备名字的缩写，其中缩写必须是全名的前面的若干字符。

设备全名：TYPE = 0x08 

设备简称：TYPE = 0x09

TX Power Level: TYPE = 0x0A，表示设备发送广播包的信号强度。

DATA 部分是一个字节，表示 -127 到 + 127 dBm。

带外安全管理（Security Manager Out of Band）：TYPE = 0x11，DATA 也是 Flag，每个 bit 表示一个功能：

bit 0：OOB Flag，0 表示没有 OOB 数据，1 表示有；

bit 1：支持 LEbit 2: 对 Same Device Capable(Host) 同时支持 BLE 和 BR/EDR；

bit 3: 地址类型，0 表示公开地址，1 表示随机地址；

外设（Slave）连接间隔范围：TYPE = 0x12。数据中定义了 Slave 最大和最小连接间隔，数据包含 4 个字节：

前 2 字节：定义最小连接间隔，取值范围：0x0006 ~ 0x0C80，而 0xFFFF 表示未定义；

后 2 字节：定义最大连接间隔，同上，不过需要保证最大连接间隔大于或者等于最小连接间隔。

服务搜寻：外围设备可以要请中心设备提供相应的 Service。其数据定义和前面的 Service UUID 类似：

16 bit UUID 列表：TYPE = 0x14

32 bit UUID 列表： TYPE = 0x??

128 bit UUID 列表： TYPE = 0x15

Service Data: Service 对应的数据。

16 bit UUID Service: TYPE = 0x16, 前 2 字节是 UUID，后面是 Service 的数据；

32 bit UUID Service: TYPE = 0x??, 前 4 字节是 UUID，后面是 Service 的数据；

128 bit UUID Service: TYPE = 0x??, 前 16 字节是 UUID，后面是 Service 的数据；

公开目标地址：TYPE = 0x17，表示希望这个广播包被指定的目标设备处理，此设备绑定了公开地址，DATA 是目标地址列表，每个地址 6 字节。

随机目标地址：TYPE = 0x18，定义和前一个类似，表示希望这个广播包被指定的目标设备处理，此设备绑定了随机地址，DATA 是目标地址列表，每个地址 6 字节。

Appearance：TYPE = 0x19，DATA 是表示了设备的外观。

厂商自定义数据: TYPE = 0xFF，厂商自定义的数据中，前两个字节表示厂商 ID，剩下的是厂商自己按照需求添加，里面的数据内容自己定义，我们的程序在这块添加了mac地址。

示例：

4、SM(Security Manager) 浅析

SM 在蓝牙协议中的位置如下图：

主要目的是为 LE 设备（LE only 或者 BR/EDR/LE）提供建立加密连接所需的 key（STK or LTK）。

定义了如下几类规范：
 
1）将生成加密 key 的过程称为 Pairing（配对），并详细定义了 Pairing 的概念、操作步骤、实现细节等;

2）定义一个密码工具箱（Cryptographic Toolbox），其中包含了配对、加密等过程中所需的各种加密算法;

3）定义一个协议（Security Manager Protocol，简称 SMP），基于 L2CAP 连接，实现 master 和 slave 之间的配对、密码传输等操作。

4.1、Pairing（配对）

在 SM 规范中，配对是指 “Master 和 Slave 通过协商确立用于加（解）密 key 的过程”，主要由三个阶段组成：

阶段 1：

称作“Pairing Feature Exchange”，用于交换双方有关鉴权的需求（authentication requirements），以及双方具有怎么的人机交互能力（IO capabilities）。

阶段 2：

通过 SMP 协议进行实际的配对操作，根据阶段 1 “Feature Exchange” 的结果，有两种配对方法可选：LE legacy pairing 和 LE Secure Connections。

阶段 3：

可选，经过阶段 1 和阶段 2 之后，双方已经产生了加密 key，因而可以建立加密的连接。

加密连接建立后，可以互相传送一些私密的信息，例如 Encryption Information、Identity Information、Identity Address Information 等。

4.1.1、Pairing Feature Exchange（阶段 1）

配对的过程总是以 Pairing Request 和Pairing Response 的协议交互开始，通过这两个命令，配对的发起者（Initiator，总是 Master）和配对的回应者（Responder，总是 Slave）可以交换足够的信息，以决定在阶段 2 使用哪种配对方法、哪种鉴权方式等。

具体包括：

配对方法：

Master 和 Slave 有两种可选的配对方法：LE legacy pairing和LE Secure Connections。

从命名上看，前者是过去的方法，后者是新方法。

选择的依据是：

当 Master 和 Slave 都支持 LE Secure Connections（新方法）的时候，则使用 LE Secure Connections，否则，使用 LE legacy pairing。

鉴权方式：

所谓的鉴权（Authentication），就是要保证执行某一操作的双方（或者多方，这里就是配对的双方）的身份的合法性，不能出现“上错花轿嫁对郎”的情况。

那怎么保证呢？

从本质上来说就是通过一些额外的信息，告诉对方：现在正在和你配对的是“我”，是那个你正要配对的“我”！

对 BLE 来说，主要有三类鉴权的方法（其实是两种），如下：

1）由配对的双方，在配对过程之外，额外的交互一些信息，并以这些信息为输入，进行后续的配对操作。这些额外信息也称作OOB（out of band），OOB的交互过程称为OOB protocol（是一个稍微繁琐的过程，这里不在详细介绍了）。

2）让“人（human）”参与进来。

例如：

这种需要人参与的鉴权方式，在蓝牙协议里面称作 MITM（man-in-the-middle）authentication，由于 BLE 设备的形态千差万别，硬件配置也各不相同，有些可以输入可以显示、有些只可输入不可显示、有些只可显示不可输入、有些即可输入也可显示，因此无法使用统一的方式进行 MITM 鉴权（例如没有显示的设备无法使用上面例子的方式进行鉴权）。

为此 Security Manager 定义了多种交互方法：

2.1）Passkey Entry

通过输入配对码的方式鉴权，有两种操作方法

用户在两个设备上输入相同的 6 个数字（要求两个设备都有数字输入的能力），接下来的配对过程会进行相应的校验；

一个设备（A）随机生成并显示 6 个数字（要求该设备有显示能力），用户记下这个数字，并在另一个设备（B）上输入。

设备 B 在输入的同时，会通过 SMP 协议将输入的数字同步的传输给设备 A，设备 A 会校验数字是否正确，以达到鉴权的目的。

2.1）Numeric Comparison

两个设备自行协商生成 6 个数字，并显示出来（要求两个设备具有显示能力），用户比较后进行确认（一致，或者不一致，要求设备有简单的yes or no的确认能力）。

2.3）Just Work

不需要用户参与，两个设备自行协商。

3）不需要鉴权

和 2c 中的 Just work 的性质一样。

IO Capabilities：

Security Manager 抽象出来了三种 MITM 类型的鉴权方法，这三种方法是根据两个设备的 IO 能力，在“Pairing Feature Exchange”阶段自动选择的。

IO的能力可以归纳为如下的六种：

NoInputNoOutput 
DisplayOnly 
NoInputNoOutput1 
DisplayYesNo 
KeyboardOnly 
KeyboardDisplay

鉴权方法的选择：

在“Pairing Feature Exchange”阶段，配对的双方以下面的原则选择鉴权方法：

1）如果双方都支持 OOB 鉴权，则选择该方式（优先级最高）；

2）否则，如果双方都支持 MITM 鉴权，则根据双方的 IO Capabilities（并结合具体的配对方法），选择合适的鉴权方式；

3）否则，使用 Just work 的方式（不再鉴权）。

4.1.2、 LE legacy pairing

LE legacy pairing的过程比较简单，如下图：

1）LE legacy pairing 最终生成的是 Short Term Key（双方共享），生成 STK 之后，用 STK 充当 LTK，并将 EDIV 和 Rand 设置为 0，去建立加密连接。

2）加密连接建立之后，双方可以自行生成 Long Term Key（以及相应的 EDIV 和 Rand），并通过后续的“Transport Specific Key Distribution”将它们共享给对方，以便后面重新建立加密连接所使用：

master 和 slave 都要生成各自的 LTK/EDIV/Rand 组合，并共享给对方。因为加密链路的发起者需要知道对方的 LTK/EDIV/Rand 组合，而 Master 或者 Slave 都有可能重新发起连接。

为什么 LE legacy pairing 的 LTK 需要 EDIV/Rand 信息呢？

因为 LTK 是各自生成的，不一样，因而需要一个索引去查找某一个 LTK（对比后面介绍的LE Secure Connections，LTK 是直接在配对是生成的，因而就不需要这两个东西）。

3）STK 的生成也比较简单，双方各提供一个随机数（MRand和SRand），并以 TK 为密码，执行 S1 加密算法即可。

4）TK 是实在鉴权的过程中得到的，根据在阶段一选择的鉴权方法，TK 可以是通过 OOB 得到，也可以是通过 Passkey Entry 得到，也可以是 0（Just Work）。

LE legacy pairing 只能使用 OOB、Passkey Entry 或者 Just Work 三种鉴权方法（Numeric Comparison只有在LE Secure Connections时才会使用）。

4.2、LE Secure Connections Pairing

LE Secure Connections pairing 利用了椭圆曲线加密算法（P-256 elliptic curve）：

1）可以使用 OOB、Passkey Entry、Just Work 以及 Numeric Comparison 四种鉴权方法，其中 Numeric Comparison 的流程和 Just Work 基本一样。

2）可以直接生成LTK（双方共享），然后直接使用LTK进行后续的链路加密，以及重新连接时的加密。

4.3、Transport Specific Key Distribution

加密链路建立之后，通信的双方就可以传输一些比较私密的信息，主要包括：

Encryption Information (Long Term Key) 
Master Identification (EDIV, Rand) 
Identity Information (Identity Resolving Key) 
Identity Address Information (AddrType, BD_ADDR) 
Signing Information (Signature Key)

至于这些私密信息要怎么使用，就不在本文的讨论范围了，后续碰到的时候再介绍。

4.4、Security Manager Protocol 介绍

SMP 使用固定的 L2CAP channel（CID 为 0x0006）传输 Security 相关的命令。

它主要从如下的方面定义SM的行为（比较简单，不再详细介绍）：

1）规定 L2CAP channel 的特性，MTU、QoS 等。

2）规定 SM 命令格式。

3）定义配对相关的命令，包括：

Pairing Request 
Pairing Response 
Pairing Confirm 
Pairing Random 
Pairing Failed 
Pairing Public Key 
Pairing DHKey Check 
Keypress Notification

4）定义鉴权、配对、密码交互等各个过程。

4.5、密码工具箱介绍

为了执行鉴权、配对等过程，SM 定义了一组密码工具箱。

refer：

http://www.wowotech.net/bluetooth/le_encryption.html

https://blog.csdn.net/sinat_23338865/article/details/52170581

http://www.wowotech.net/bluetooth/le_security_manager.html