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

Posted 2021-02-07 crazyprince

1. 前言

前面文章介绍了两种BLE的安全机制：白名单^[4]和LL privacy^[3]。说实话，在这危机四伏的年代，这两种“捂着脸讲话（其它人不知道是谁在讲话，因而不能插话、不能假传圣旨，但讲话的内容却听得一清二楚）”的方法，实在是小儿科。对于物联网的应用场景来说，要做到安全，就必须对传输的数据进行加密，这就是LE Encryption要完成的事情（当然，只针对面向连接的数据），具体请参考本文的介绍。

2. 基本概念

从字面理解，Encryption是一个名词，意思是“加密术”，因此LE Encryption就是“BLE所使用的加密技术”的意思。了解加密概念的同学应该都知道，通信过程中的加密无非就是如下简单的流程：

数据发送方在需要发送数据的时候，按照一定的加密算法，将数据加密； 数据接收方在接收到数据的时候，按照等同的解密算法，将数据解密。

因此，对LE Encryption来说，需要考虑的事情无非就两条：

1）加密/解密的事情，需要在协议的哪个层次去做？ 2）使用什么样的加密/解密算法？

对问题1来说，很好回答：无论是从安全的角度，还是从通信效率的角度，都应该由链路层（LL，Link Layer^[1]）在发送/接收数据的时候，完成加密/解密动作（具体可参考）。而问题2呢，到底要使用什么的算法，这是蓝牙标准化组织的事情，我们在本文只需要了解最终的结论即可（具体可参考）。

3. packet的加密/解密过程

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

图片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解密生成明文数据包。

 

理解了加密/解密的过程之后，问题随之而来：

1）LTK是怎么来的？

2）SKD是个什么东西？怎么来的？

3）Encryption Engine又什么东西呢？

对于问题1，需要由SMP解答（也就是我们常说的配对过程），具体可参考后续的文章。问题3比较单纯，就是一个由Bluetooth specifiction所规定的加密算法，后面会单独写一篇文章介绍。而问题2，则涉及到LE Encryption的操作流程，具体可参考后面第4章的介绍。

4. Encryption Procedure

LE Encryption的过程主要由Link Layer控制（具体可参考“BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part B] 5.1.3 Encryption Procedure”）：当连接建立之后，Link Layer可以应Host的请求，使能对数据包的Encryption操作，过程如下（具体可参考“BLUETOOTH SPECIFICATION Version 4.2 [Vol 6, Part D]  6.6 START ENCRYPTION”）：

图片2 Start Encryption

1）Host A发送LE Start Encryption HCI命令，请求Link Layer启动加密。该命令的格式如下：

Command	OCF	Command parameters	Return Parameters
HCI_LE_Start_Encryption	0x0019	Connection_Handle Random_Number Encrypted_Diversifier Long_Term_Key

 

Connection_Handle，连接句柄；  Random_Number和Encrypted_Diversifier分别简称为Rand和EDIV（Rand是一个64bits的随机数，EDIV是一个16bits的Diversifier），它们在LE Legacy Pairing的过程中，用于在多个LTK标识某一个具体的LTK。而在新的LE Secure Connections Pairing过程中，则不再使用（赋值为0即可）。关于LE的配对过程，可参考后面SMP的分析文章，这里不再详细描述；  Long_Term_Key，保存在Host段的加密key。

2）LL A收到Host的加密请求之后，会向LL B发送LL_ENC_REQ PDU以请求加密，该PDU的格式为：

Rand(8 octets)

EDIV(2 octets)

SKDm(8 octets)

IVm(4 octets)

 

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的格式为：

Event	Event code	Event Parameters
LE Long Term Key Request	0x3E	Subevent_Code Connection_Handle Random_Number Encryption_Diversifier

 

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，该命令的格式为：

Command	OCF	Command parameters	Return Parameters
HCI_LE_Long_Term_Key_Request_Reply	0x001A	Connection_Handle Long_Term_Key	status Connection_Handle

5）LL B收到LTK之后，会向LL A回应一个LL_ENC_ RSP PDU，该PDU的格式为：

SKDs(8 octets)

IVs(4 octets)

 

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）、重启加密等过程，比较简单，这里就不详细介绍了，具体可参考BLE Spec^[2]中的相关描述。

5. 参考文档

[1] 蓝牙协议分析(3)_蓝牙低功耗(BLE)协议栈介绍

[2] Core_v4.2.pdf

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

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

 

原创文章，转发请注明出处。蜗窝科技，www.wowotech.net。