BLE中的配对原理分析三

BLE中的配对原理分析三

说明

​ 前面的两篇博客已经把LTK的生成给了出来，但是也说到LTK并非是最后用于AES加密的实际密钥。今天我们就再进一步分析，通信时候的数据到底是如何被加密成密文，密文究竟是如何被解密成明文的。

架构说明

​ 首先要明确一点，这里的部分其实已经跟HOST层的安全规范无关了，涉及到底层也就是Controller层的安全规范。HOST层更多的是通信双方对于密钥信息的确认和同步，Controller层是对密钥的使用。

session key

​ 前面已经讲过上层已经生成好LTK，那么底层就可以开始启动加密通信了，而加密通信的第一步是启动LL层的Encryption Start procedure，这部分内容在

BLUETOOTH CORE SPECIFICATION Version 6.0 | Vol 6, Part B Link Layer Specification

的5.1.3.1 Encryption Start procedure。

这个流程交互的数据包如下：

​ 其中的Rand和EDIV这个上一篇以及讲过了，这里就不重复了，关键是SKD和IV。SKD和IV有主从各出一半，然后组成完整的SKD和IV。

​ SKD是Session Key Diversifier，用于和LTK一同通过AES算法生成session key。

​ 而IV是初始向量，如果有用到相关分组加密需要有初始向量的场景会用到，不过BLE中一般无用。

上述specification中提到只要主从都有LTK,那么再在得到SKD后就会得到Session key,不然就会报错。

AES-CCM

​ 在BLE Controller Link Layer的安全部分描述中，最开是便提到了BLE使用AES-CCM算法作为基本数据加密方案。关于AES-CCM这套东西，网络上有很多写得好的文章已经描述了。

​ 大家可以先看看

分组密码的模式——ECB、CBC、CFB、OFB、CTR_ofb是指分组密码的哪种工作模式-CSDN博客

这篇文章，对分组密码的模式有一个基本的认识，特别是要CTR和CBC模式

随后可以再看看

蓝牙加密（AES-CCM）-CSDN博客

​ 这篇文章很好的说明了蓝牙使用CBC来加密MIC，用CTR来加密明文，并使用AES算法作为基本的\(CIPH_k()\)算法。

​ 现在回过头来看规范原文，蓝牙规范规定了使用AES作为加密算法，将Session Key作为AES的密钥。从而实现对密文的加密。

小结

​ 这里有几点要注意，

1. 配对绑定是生成LTK的流程，是Host的流程。该流程并没有进行过什么将通信数据进行加密的过程。
2. 对通信数据进行加解密是底层Controller层的工作，一般都是在硬件层面实现。
3. 所谓的对数据进行加解密，本质也只是通过AES算法生成的特殊密钥数据，然后对数据进行异或处理，并非直接将数据进行AES操作。所以本质上是不需要AES解密功能的，只需要使用AES加密算法，即可完成对数据流的加解密。听起来可能有些矛盾，这一点需要对上面两篇博客好好研究才能明白这套算法的原理。