BLE中的配对原理分析二
BLE中的配对原理分析二
以前写的一篇文章有分析过配对绑定，但是对配对的第三个阶段Key Distribution过程还有些没说明。由于这部分比较复杂，这次再来做一下分析。这里的内容基本上是基于蓝牙协议如下部分：
BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 3, Part H
legacy中的密钥
密钥类型
在2.4.1 Definition of keys and values中定义了配对绑定过程中用到的一些Key：
- IRK，用于隐私功能中对mac地址进行加解密
- CSRK，用于数据接收时的签名防篡改
- LTK，以前讲过，用于数据内容的AES加密
- EDIV，和Rand一起用来确认LTK
- Rand，生成LTK时用到的随机数
- addr，设备的mac地址
IRK
IRK的生成可以是随机的也可以时人为规定的，但这不属于蓝牙协议处理，对于设备来说更多的是由用户给予（比如用户代码写死）的。当配对流程结束后，由主机发给从机，或者从机发给主机，或者双方都发。这取决于哪一方的设备地址是需要隐私处理。
例如苹果手机的蓝牙mac地址一般需要隐私保护，当作为主机跟某个设备（比如蓝牙耳机）配对后。在密钥分发环境，手机就会将自身的IRK发送给从机设备。当手机和从设备断连一段时间后，由于隐私机制，手机mac地址发生改变。但当手机重新连接从设备后，从设备能够使用IRK解密并识别这个手机的蓝牙原始mac地址是曾经配对绑定过的，那就可以直接进行加密连接，不需要重新发起配对绑定流程。
CSRK
CSRK本质是验签密钥，用于数据信息不被篡改。跟IRK一样可以随机生成也可以人为规定。当设备有数据要发送时，它会使用 CSRK 生成签名并将其附加到数据中。然后，接收设备使用相同的 CSRK 为接收到的数据生成自己的签名。如果生成的签名与附加到数据的签名相匹配，则确认数据的完整性和真实性。
CSRK没什么特别的，本质就是验签使用，防止数据被篡改。
EDIV、Rand和LTK
这里把三个key一起来讲，因为这三个key有一定从属关系。以前讲LE Security会生成LTK，但其实legacy方式也会生成LTK。LTK用于替代STK来进行加密通信，对于第一次配对，phase3使用经历phase1和phase2生成的STK进行密钥分发无可厚非，但是要是之后主从断连重连，重新发起加密通信时还是用STK，时间长了那么会有被暴力破解的风险。为了规避这个风险，主从第一次之后的每次加密通信时都需要使用一个不同于STK，重新生成一个密钥用于加密通信，这个密钥就是LTK。
那RAND和EDIV是什么？这个问题比较复杂，需要结合后面的密钥生成和加密会话流程才能说得清，这里暂时先略过，只要明白LTK是用于第一次之后的加密通信密钥使用即可。
密钥的生成
那么IRK、CSRK、LTK要怎么生成？EDIV和Rand是什么？又要怎么生成呢？对于这些疑问，蓝牙规范BLUETOOTH SPECIFICATION Version 5.1 | Vol 3, Part H中的APPENDIX A EDIV AND RAND GENERATION和APPENDIX B KEY MANAGEMENT给出了答案。
首先是LTK的生成，蓝牙规范给出两种方式：第一种你可以简单地生成一个随机128bit的数来当LTK，然后把存到设备自己内部中，这种叫（Database Lookup）。第二种则是使用128bit的静态但随机的值叫加密根和一个每个受信任设备唯一的16bit的分散因数来生成，这种方式称为“Key Hierarchy”。
这段话出自于NIST SP 800-121中 3.2.3 Legacy Low Energy Key Generation and Distribution，原文如下：
Once the link is encrypted using the STK, the two devices distribute secret keys such as LTK, IRK,
and CSRK. Two options are specified for key generation prior to distribution. A device may simply
generate random 128-bit values and store them in a local database (called “Database Lookup” in the
specification). The other option is to use a single 128-bit static but random value called Encryption
Root (ER) along with a 16-bit Diversifier (DIV) unique to each trusted device to generate the keys.
This option is called “Key Hierarchy” in the specification. For example, the keys can be derived from
ER, DIV, and the Identity Root (IR) using the following formulas:
LTK = d1(ER, DIV, 0)
CSRK = d1(ER, DIV, 1)
IRK = d1(IR, 1, 0)
The d1 function is a called a Diversifying Function and is based on AES-128 encryption. However,
the specification allows the use of other key derivation functions.这篇规范对蓝牙SMP部分是个比较好的概况性说明，比core specification更加精炼，建议先看这份规范再去看规范原文。
使用第一种随机数生成的方式就不说了，这里讲讲第二种key hierarchy方式
key hierarchy
该方式给出的密钥的生成公式如下：
在这个公式中
- d1被称为基于AES-128加密的Diversifying方程，关于这个方程的说明参考The NIST Special Publication 800-108 (http://csrc.nist.gov/publications/PubsSPs.html)
- ER称为加密根，IR称为认证根，这两个都是128bit大小，由产品出厂时由制造商指定并存储在产品中。ER用于生成LTK，IR用于生成CSRK和IRK。
- DIV称为分散因子，16bit大小，随机生成。
由上述公式可得，由于DIV随机，ER和IR固定，那么设备每次配对生成的LTK和CSRK都是不一样的，但是IRK是一样的。
主机对从机发起配对绑定，完成后的从机通过内部的根数据和随机数生成密钥并同步给主机端，双方保存好后，那么下一次重连时，大家都知道LTK这些密钥，只要直接从存储的数据库里，根据mac地址取出来直接进行加密通信就可以了，这个过程大家是不是看着没什么问题？如果没问题那EDIV和Rand要来干嘛？
这个过程可行的基础在于主从设备都有足够的存储空间来存密钥信息，那如果从机设备没有这么多存储空间呢？我们知道LTK、IRK、CSRK每个都是128bit，也就是16个字节，三个就是48字节。如果有10个主机跟这个从机进行过绑定，那么就要存10组480个字节的密钥数据，这个数量看着好像没什么，但是对于某些资源有限的传感器设备，压力就有些大了。为了解决这个从设备存储空间不足的的问题，蓝牙规范给出了一个时间换空间的方法
EDIV和Rand的作用
前面的公式我们都知道，密钥都是由ER和IR以及DIV得到，其中ER和IR都是固定的，DIV是随机的。从机只要保存16bit的DIV也能算出来128bit的LTK、CSRK数据。如果要保存10组密钥信息，那只要保存10个16bit的DIV信息，和两个128bit的ER和IR就可以了。这样一来是不是空间就小了很多。
另外我们都知道从机保存的数据，主机那边也同样保存了一组。为了再进一步节省空间，那么干脆从机连DIV信息也不保存了，只由主机保存，要进行加密时由主机把DIV信息给到从机，从机再根据自己的ER和IR算密钥，这样从机主要保存IR和ER够了。主机则保存好DIV数据和密钥数据（LTK、CSRK、IRK）。可能有人问这样从机的存储空间是小了，但是主机却要额外承担DIV的存储，这样对主机要求不就高了吗？对于这个问题，规范设计的初衷是一般主机是手机，从机是资源有限的传感器设备。手机额外多占用点花销没什么关系。但传感器设备最好能省则省。
好了，现在从机的存储空间以及做了优化，该考虑重连时，主机给从机发送DIV信息这种方式是不是够安全了。我们知道这个过程中d1公式是公开的，ER信息是只有从机自己知道的，DIV在发送时也是公开的。那么如果我是恶意第三方，是不是可以通过已知的DIV和d1公式去穷举ER来破解LTK呢，ER不过才128bit，暴力破解也是能破解出来的。那么为了增大计算量，提高破解难度，我们需要将DIV进行转换，这里蓝牙规范给出了一个转换方法将DIV变成加密的DIV，也就是EDIV的方法：
其中Y为DIV mask，也就是DIV的掩码，公式为：
其中DHK为Diversifier Hiding Key,也就是分散系数隐藏密钥：
大家不要看上面又是生成DHK又是生成Y好像很复杂的样子，其实里面的核心就是加了个随机数Rand，把原来的DIV转成了EDIV，传输的DIV值变成传输Rand加EDIV而已。目的只是添加计算复杂度，避免直接传输DIV而已。大家可以看到DHK是由IR得到的，以前传输DIV，那破解的目标只有ER。现在传输EDIV和Rand，那么破解的值就变成了IR和ER的组合，破解次数从128bit变成了256bit。但是从机并不需要存储多余的数据，用的还是原来的ER和IR进行计算。
这个过程我们总结下就是如下：
总结
总结下来legacy方式的第一次配对绑定，从机会在phase3阶段分发LTK、CSRK、IRK、EDIV、RAND五个密钥给主机保存，而从机自身什么都不会保存。当发生重连重新进入加密通信时，主机会向从机发送EDIV和RAND值，从机收到后会结合自身的IR和ER重新计算出LTK、CSRK和IRK。随后双方使用双方已知的这三个密钥进行加密通信。
这套流程既节省了从机的存储资源，也保证了密钥的安全性（破解难度高），唯一确定就是每次从机都需要把密钥都算一遍出来。当然这套流程不是必要的，蓝牙规范也只是给了个参考，用户大可用随机数算一个LTK然后保存好，然后随便给个EDIV和RAND值给主机也行。只要从机自身保存好这些密钥和数据以及他们的对应关系，重连时能正确的根据主机发送的EDIV和RAND值选择对LTK进行加密通信就可以了。
LE Secure中的密钥
得益于LE Secure中使用到的非对称加密技术，通信双方可以不用担心LTK在配对过程中被破解的情况。因此LTK被认为是可靠的，因此密钥分发过程中，与legacy不同，不再需要分发LTK、EDIV、RAND，只需要分发IRK和CSRK和mac地址即可。后续重连时也不会对这些密钥进行交换，避免了会被破解的机会。
SMP指令与交互
SMP层协议基于L2CAP层，可以直接通过l2CAP层接口进行交互，交互指令如下：
指令说明
对于指令的说明，可以参考BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 3, Part H 3.5 PAIRING METHODS章节内容
交互过程
对于前面提及的配对三个phase的相关具体指令交互，可以参考BLUETOOTH CORE SPECIFICATION Version 5.1 | Vol 3, Part H APPENDIX C MESSAGE SEQUENCE CHARTS章节
LL层指令与交互
需要注意，SMP层更多只负责密钥的生成，具体的加密链路的创建，和数据密文的产生，则是由LL层负责。
需要注意，上文提及的LTK并非最终用于AES加密的密钥，主从在建立加密链路时，会再协商出一个随机数SKD。使用该SKD和LTK最后再会生成用于AES加密的密钥Session Key。这样的目的是保证即便使用长期不变的LTK，也能让每次通信的实际密钥不一样。关于这部分内容，后面看看有没有看再写篇博客分析下吧
