本文内容可在SIG蓝牙联盟发布的Core_v4.2里找到，比较分散。
名词解析：Legacy Pairing：传统配对
Secure Connections Pairing：安全连接配对
上一章我们聊了配对特性交换，这章我们来谈谈 蓝牙的密钥生成。此阶段主要是生成LTK，从而由LTK生成IRK、CSRK以及会话密钥等专用密钥。
回顾一下加密方式和加密方法关系表：
| BLE4.2以前（不包含BLE4.2） | BLE4.2及以上版本 |
|---|---|
| 传统配对 | 传统配对 / 安全配对 |
| Just Works / Passkey Entry / Out Of Band (OOB) | Just Works / Passkey Entry / Out Of Band (OOB) / Numeric Comparison |
传统配对要想生成LTK，则需要先生成TK（临时密钥）和STK（短期密钥），TK则由加密方法不一样取值不一样，加密方法是Just work：TK为0；Passkey Entry：TK为用户输入的6个数字；Out Of Band (OOB)方式：TK由内部伪随机生成器生成。而STK是由TK、Srand、Mrand三个参数通过函数S1生成。
STK = S1（TK，Srand，Mrand）
我们看一下Passkey Entry的流程图（copy自csdn用户：SZ_Devin）：
Master即发起端（Initiator）；Slave即响应端（Respoinder）；我们来理解一下流程图的具体步骤以及每个步骤所做的事吧：
~>1.发起端由内部伪随机发生器生成Mrand和赋值TK（加密方法是Just work：TK为0；Passkey Entry：TK为用户输入的6个数字；Out Of Band (OOB)方式：TK由内部伪随机生成器生成）；响应端也相应的生成Srand和TK；若采用的是OOB方式，则TK由发起端生成，通过OOB方式分享给响应端。
~>2.发起端通过公式：Mconfirm = c1(TK, Mrand, Pairing Request command,…)，计算得出M/confirm/i值；响应端通过公式：Sconfirm = c1(TK, Srand, Pairing Request command,…)，计算得出Scomfirm值。
~>3.发起端 / 响应端交换各自计算出来的值Mconfirm / Scomfirm；发起端将Mrand发送给响应端，随即响应端通过 M/confirm/i’ = c1(TK, Mrand, Pairing Request command,…)，当 M/confirm/i’ = M/confirm/i则此步验证成功，反之失败并断开连接；如果验证成功后，响应端将Srand分享给发起端，发起端也通过函数S/confirm/i’ = c1(TK, Srand, Pairing Request command,…)，当S/confirm/i’ = S/confirm/i则验证成功并继续下一步操作，反之失败并断开连接。
~>4.以上所有不走都成功通过的话，则双端都会进行计算STK = s1（TK，Srand，Mrand），此时STK已经生成成功了，值得注意的是，双端的STK值是由同一个式子计算得到的，所以他们应该是相等的。
生成的STK极容易被破解，后续双端会根据STK各自生成LTK（双端的LTK不相等），有了LTK后就可以生成IRK、CSRK以及会话秘钥等。
以上就是传统配对第二阶段–秘钥生成的所有内容。
安全连接配对第二阶段比传统配对要复杂一点点，但不要紧，我们一个个来分析一下：
2.1、认证阶段准备 — 公钥交换：
要想交换公钥，首先要生成公钥：Initiator和Respoinder（即Non-Initiating）各自生成随机数作为各自的私钥SKa和SKb，由 PK = SK * G 双端各自生成公钥PKa和PKb；（G是椭圆曲线的基点，知道他的出处就行，不必纠结为什么是G）。
公钥对交换：如下图所示，Initiator和Respoinder将自己的公钥PKa和PKb分享给对方，利用公式：DHKey = P256（SKa，PKb）以及DHKey = P256（SKb，PKa）计算出各自的DHKey，需要注意的是，此时双方各自生成的DHKey是相等的，不要问为什么会相等，问就是数学的优雅。
2.2、认证阶段1— Just Works or Numeric Comparison
如果在前期配对特性交换时MITM位被设置为1并且双端都拥有显示yes/no的能力或者键盘和显示全功能的时候，此认证阶段采用Numeric Comparison；否则采用Just Works。
先来看一下此种加密方式下的认证流程图吧：
Initiator和Respoinder公钥交换并计算出DHKey后，双端会随机生成随机数作为各自的参数Na和Nb，此种加密方法下双端的ra和rb都被设定为0；Respoinder会利用自身的参数，通过公式：Cb = f4（PKb，PKa，Nb，0）计算出Cb，然后将Cb分享给Initiator，随后Initiator将自己的Na分享给Respoinder，Respoinder收到Initiator的Na后，会将自己的Nb分享给Initiator，Initiator通过公式：Cb’ = f4（PKb，PKa，Nb，0），通过Cb’验证Respoinder刚刚分享的Cb和Nb正不正确，如果Cb’ != Cb，Initiator认为此次认证失败并断开连接；如果相等则双方同时计算：Va = g2（PKa，PKb，Na，Nb）。此时双端会显示Va的值，用户通过屏幕观察双端的Va是否相等而选择点击 yes 或者 no。
2.3、**认证阶段1— Passkey Entry **
Passkey Entry这种加密方法和上一中加密方法也有一点相似，不同的是Passkey Entry需要用户输入密码赋值给ra和rb；认证阶段会重复多次等特点。我们先来看看这种加密方法的流程图吧：
~>步骤2a/2b：双端其中一端会生成6个数的数字秘钥，用户需要手动在另一端输入此秘钥，并且此秘钥就是双端的ra和rb。并且ra和rb被划分成20bit，形成ra1、ra2、…、ra20和rb1、rb2、…、rb20。
~>步骤3a/3b：双端各自生成一个随机数作为各自的Na和Nb。
~>步骤4a/4b：公式计算出Ca和Cb：Ca = f4(PKa,PKb,Na,ra)、Cb = f4(PKa,PKa,Nb,rb)。
~>步骤5：Initiator分享Ca给Respoinder。
~>步骤6：Respoinder分享Cb给Initiator 。
~>步骤7：Initiator分享Na给Respoinder。
~>步骤7a：验证Initiator分享过来的Ca和Na，通过公式计算Ca’ = f4(PKa,PKb，Na，rb)，如果Ca’ = Ca，则认证通过，若不相等则认证失败并断开连接。
~>步骤8：若果步骤7a认证拖过后，Respoinder会分享Nb给Initiator。
~>步骤8a：验证Respoinder分享过来的Cb和Nb，通过公式计算 Cb’ = f4(PKb,PKa,Nb,rb)，如果Cb’ = Cb，则认证通过，否则认证失败并断开连接。
值得注意的是，最开始ra和rb被划分成了20bit，因此步骤3a/3b 到步骤8a 会重复20次，因此图中的Na、Ca、Nb、Cb后面都会带个i的原因，i 是逐次递增知道等于20次。此外每次计算只取ra和rb 20bit中的1bit，这样就算受到外部攻击，也只是泄露20bit的其中1bit，就会降低秘钥泄露的风险。
2.4、**认证阶段1— Out of Band **
经过上面两个加密方法流程的探究，你应该也学会了怎么看图说话了，这里的流程形式上跟上面也差不多，这里我就不再赘述了。（偷偷懒）
2.5、**认证阶段2 — LTK（长期密钥）生成 **
本文基于本人查阅蓝牙标准5.0以及众多文章理解得到，未免有丁点错漏，请多包涵。至此，长期密钥也生成了，就可以根据长期密钥生成各种需要的密钥了。本章结束。
