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模式
随后可以再看看
这篇文章很好的说明了蓝牙使用CBC来加密MIC，用CTR来加密明文，并使用AES算法作为基本的\(CIPH_k()\)算法。
现在回过头来看规范原文，蓝牙规范规定了使用AES作为加密算法，将Session Key作为AES的密钥。从而实现对密文的加密。
小结
这里有几点要注意，
- 配对绑定是生成LTK的流程，是Host的流程。该流程并没有进行过什么将通信数据进行加密的过程。
- 对通信数据进行加解密是底层Controller层的工作，一般都是在硬件层面实现。
- 所谓的对数据进行加解密，本质也只是通过AES算法生成的特殊密钥数据，然后对数据进行异或处理，并非直接将数据进行AES操作。所以本质上是不需要AES解密功能的，只需要使用AES加密算法，即可完成对数据流的加解密。听起来可能有些矛盾，这一点需要对上面两篇博客好好研究才能明白这套算法的原理。