[BLE--SMP]蓝牙安全管理之BLE的安全

简述

BLE的SMP一般是在连接建立之初就会立即进行的，其作用就是利用密钥分发的方式，用密钥对链路进行加密，使数据传输更加安全。这部分的内容主要是关于BLE的安全的一些补充说明吧。

BLE的SMP的一些Key相关定义

• Identity Resolving Key (IRK)：用于生成和解析random address用的，128-bit；
• Connection Signature Resolving Key (CSRK)：用于对数据进行签名已经验证签名数据，128-bit；
• Long Term Key (LTK)：加密链路用，128-bit；
• Encrypted Diversifier (EDIV)：在LE legacy pairing过程中，用于识别LTK分发，16-bit；
• Random Number (Rand)：在LE legacy pairing过程中，用于识别LTK分发，64-bit。

分发的Key的生成

IRK的生成

IRK的生成有很多可选方式，并不固定，而且其Key Size也不规定为7-16 bytes。一个Master从Slave那里得到Slave的IRK，就可以解析Slave的random address；一个Slave从Master那里得到Master的IRK，就可以解析Master的random address了。

CSRK的生成

CSRK的生成也有很多可选方式，并不固定，而且其Key Size也不规定为7-16 bytes。一个设备得到另一个设备的CSRK后，就可以对从另一个设备那接收到的数据进行签名验证了。

Legacy pairing中LTK, EDIV和Rand的生成

当Slave要和之前配对过的Master设备进行连接的加密，EDIV和Rand此时可以被Slave用来建立之前共享的LTK。每分发一次LTK, EDIV, Rand，它们都要被重新生成一次。Slave可以在Security database中映射好LTK, EDIV和Rand，以便和LTK快速对应起来。
另外Master也可以分发LTK, EDIV和Rand，这样在Role Switch之后便于快速重连。

从LE LTK产生BR/EDR Link Key

• ILK = h6(LTK, “tmp1”)
• BR/EDR link key = h6(ILK, “lebr”)

从BR/EDR Link Key产生LE LTK

• ILTK = h6(Link Key, “tmp2”)
• LTK = h6(ILTK, “brle”)

Key的分发

Legacy Pairing Key分发

Slave和Master都可以分发如下的Key：
- LTK, EDIV, and Rand（Master只有考虑后面Role切换时才会发这些）
- IRK
- CSRK

Secure Connections Key分发

Slave和Master都可以分发如下的Key：
- IRK
- CSRK

Encrypted Session建立

• Master发送配对阶段三时Slave分发给它的EDIV和Rand给Slave，然后Slave会从它的Key Map中取出对应的LTK，双方都用LTK进行加密；
• 双方都支持LE Secure Connections时，EDIV和Rand是设置为0的，因为没有LTK的分发识别问题。

用STK建立加密

用配对阶段2生成的STK（Legacy Pairing）建立加密时，如果LTK提供给了Link Layer，那么EDIV和Rand都设置为0（这里设置为0应当就是一个禁用LTK的作用吧）。
如果在建立加密时发现之前已经加密过，得执行一个encryption pause过程。

用LTK建立加密

对Legacy Pairing而言，得有LTK, EDIV, Rand信息，对Secure Connections而言，配对阶段生成的LTK即可。
基于LTK的用法，是用于长时间的加密链路用的，包括在链路断开后重连时可以跳过配对过程直接使用存储的LTK进行双方链路的加密。但是存在一种情况，当一方保留的LTK丢失，之后的加密就会失败（失败后可以选择断开链路），spec对于这种情况的处理的推荐做法如下：

从上图可看到，当与对方设备没有绑定时，如果一方LTK丢失无法加密时，对于MITM方式的，则推荐通知用户，并询问是否需要重新配对生成LTK，因为MITM方式需要用户进行一些操作。而no MITM则直接重新配对生成LTK了。当双方绑定了时，只会直接通知用户加密失败了，此时用户就知道LTK丢失了，后续可能要删除绑定的设备，然后重新配对等动作。

签名算法

LE设备可以在不加密链路的情况下，发送签名数据到对端，数据使用CSRK签名。只要对端持有这边的CSRK，就可以对数据签名验证，获得原数据。BLE使用的签名算法是NIST Special Publication 800-38B中的。

关于Slave Security Request

这个包是可选的，在分析SMP过程的流程时，看到SMP最开始是Slave向Master发送了这样的一个包，那这里来说说其作用吧。
- Master收到这个包时，要么拒绝，要么加密链路（Key已经存在时），要么初始化配对过程；
- Slave送这个包，在配对或加密正在进行时都不能送；
- Master也可以送这个包的。
Master在收到Slave的Security Request时，可能有多种处理情况，不过之间有先后顺序，其处理流程如下：