深入NXP蓝牙SDK开发（x）---深挖BLE蓝牙协议栈配对过程（2）_配对密钥生成（LTK | STK）

本文内容可在SIG蓝牙联盟发布的 Core_v4.2里找到，比较分散。

名词解析：

Legacy Pairing：传统配对
Secure Connections Pairing：安全连接配对

0、开篇：

  上一章我们聊了配对特性交换，这章我们来谈谈 蓝牙的密钥生成。此阶段主要是生成STK / LTK，从而由LTK加密的链路分发本段的IRK、CSRK等密钥给对端（关于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

1、传统配对（Legacy Pairing）：

  传统配对要想生成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,…)，计算得出Mconfirm值；响应端通过公式：Sconfirm = c1(TK, Srand, Pairing Request command,…)，计算得出Scomfirm值。
  3.发起端 / 响应端交换各自计算出来的值Mconfirm / Scomfirm；发起端将Mrand发送给响应端，随即响应端通过 Mconfirm’ = c1(TK, Mrand, Pairing Request command,…)，当 Mconfirm’ = Mconfirm则此步验证成功，反之失败并断开连接；如果验证成功后，响应端将Srand分享给发起端，发起端也通过函数Sconfirm’ = c1(TK, Srand, Pairing Request command,…)，当Sconfirm’ = Sconfirm则验证成功并继续下一步操作，反之失败并断开连接。
  4.以上所有不走都成功通过的话，则双端都会进行计算STK = s1（TK，Srand，Mrand），此时STK已经生成成功了，值得注意的是，双端的STK值是由同一个式子计算得到的，所以他们应该是相等的。
  生成的STK极容易被破解，后续双端会根据STK各自生成LTK（双端的LTK不相等），有了LTK后就可以生成IRK、CSRK以及会话秘钥等。
  以上就是传统配对第二阶段–秘钥生成的所有内容。

2、安全连接配对（Secure Connections Pairing）：

  安全连接配对第二阶段比传统配对要复杂一点点，但不要紧，我们一个个来分析一下：

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’ = 4（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

  OOB方式认证，借助了外部的NFC/红外或者其他的方式交换验证数据，从根源上避免在蓝牙频段上中间人攻击、窃听、伪装等。所以OOB是更为安全的一种认证方式，当然随之而来的就是增加系统的成本。如下图就是OOB认证流程

  跟着图里的一步一步分析：
  步骤2a/2b：双端选择一个随机数，发起端将随机数赋值给ra，rb=0；响应端将随机数复赋值给rb，ra=0；
  步骤3a/3b：发起端使用f4函数计算出Ca，响应端使用f4函数计算出Cb；
  步骤4a/4b：发起端将A，ra， Ca通过OOB交换到响应端；响应端将B，rb， Cb通过OOB交换到发起端；
A是发起端的Mac地址，B是响应端的Mac地址。
  步骤5a/5b：双方校验对端交换过来的数据，Ca，ra | Cb、rb是否合法等
  步骤6a/6b：上一步骤验证成功后，双端分别选择随机数 Na 和 Nb；
  步骤7/8： 交换随机数 Na 和 Nb；
至此OOB认证完成，接下来就是生成LTK；

2.5、认证阶段2 — LTK（长期密钥）生成

  步骤 9： 双端各自利用 f5 函数生成 LTK 和 MacKey；
  步骤10a / 10b： 双端利用 f6 函数分别生成 Ea 和 Eb，然后发起端将 Ea 发送给 响应端；
  步骤 11 / 12： 响应端验证 Ea 是否正确，如果正确则执行 步骤12，将Eb发送给发起端，否则，认证失败并断开连接；
  步骤 12a： 发起端校验Eb是否正确，如果正确我们可以逆推，就证明MacKey正确，也就证明着 LTK正确了，LTK生成完成。

总结

  那么从上面所有的流程图可以很清晰的看出两种配对方式的异同之处：1、传统配对连接和安全配对连接的第二阶段最终目的都是生成LTK；2、传统配对方式的三种加密方法的流程几乎都是一摸一样的，都需要先生成TK，然后生成STK，有了STK加密链路的前提下，再生成LTK并将LTK分发给对端设备，作为再次重连时加密链路的密钥。3、安全配对方法又将第二阶段细分成了：认证阶段、和 加密阶段。认证阶段又细分为三个认证阶段：认证准备阶段、认证阶段1、认证阶段2；认证准备阶段主要是双端共同协商生成公私密钥对，为接下来的两个认证阶段做准备，安全配对连接的几种加密方法处理过程的不同就在认证阶段1，具体相异的地方还是参考上面认证阶段1的流程图，在认证阶段1就是真实的认证对端身份的阶段；认证阶段1完成后，会进行认证阶段2生成长期密钥LTK。等LTK生成并互相认证成功后，双端的链路就由LTK加密，在接下来的阶段都是加密阶段。等链路加密成功后就会进行配对的第三阶段：密钥的分发。
  至此配对第二过程正式结束，接下来进行密钥的分发；
注意：本文基于本人查阅蓝牙标准5.0以及众多文章理解得到，未免有丁点错漏，请多包涵。至此，长期密钥也生成了，就可以根据长期密钥加密链路分发各种需要的密钥了。本章结束。