)
一. 概念
1. 概念
蓝牙CTKD是蓝牙4.2版本引入的一种交叉传输密钥派生的安全机制，全称 Cross-transport key derivation，主要用在蓝牙双模设备上，它可以跨越BLE和BT的边界，通过将BLE配对生成的LTK转化成BT配对的LinkKey，从而直接实现BT的配对，当然也可以通过BT配对生成的LinnkKey转化成BLE的LTK来实现BLE的配对。
2. 应用场景
主要应用在蓝牙双模设备上，如蓝牙耳机、蓝牙手表上，通过手机APP连接BLE，并通过BLE的配对转化生成BT的配对密钥，反之一样，通过BT的配对转换生成BLE的配对密钥，从而实现一次配对完成BT和BLE的配对，提升双模产品的配对体验。
3. 蓝牙设备端要求
BT和BLE的MAC地址必须保持一致。
在蓝牙核心规范中CTKD的介绍中并没有直接说明BT和BLE的MAC地址要保持一致，但是在分析蓝牙配对绑定的流程中发现双方只在BLE配对的时候交换了一次MAC地址，并没有发现有交互BT MAC的流程。
但核心规范中的Controller层规范中读MAC地址的命令中有这样的描述：On a BR/EDR/LE Controller, the public address shall be the same as the BD_ADDR。
所以通过理论和实践结合可以得出结论：支持CTKD特性的蓝牙双模式设备，BT和BLE的MAC地址需要保持一致。
设备BLE配对需要支持安全配对 Secure Pairing
Secure Pairing是蓝牙4.2支持的一种安全配对方式。与legacy Pairing配对方式使用AES对称加密算法来加密链路不同的是，Secure Pairing使用椭圆曲线ECDH的公钥算法来进行配对和鉴权流程，从而可以做到防窃听攻击，增强了链路的安全性。
4. 算法介绍
不管是LinkKey转LTK还是LTK转LinkKey，都会用到SMP中的算法h6/h7
4.1. 算法 h6
函数 h6 用于将给定大小的密钥从一种类型转换为另一种具有等效安全强度的密钥类型。
h6 函数的定义使用了具有 128 位密钥 W 的哈希函数 AES-CMACW。
函数 h6 的输入为：
- W：128 位
- keyID：32 位
keyID 作为哈希函数 AES-CMAC 的输入 m，W 的最高有效 128 位作为密钥 k。
h6 的输出如下：
h6(W, keyID) = AES-CMACW(keyID)
4.2. 算法 h7
函数 h7 用于将给定大小的密钥从一种类型转换为另一种具有等效安全强度的密钥类型。
h7 函数的定义使用了具有 128 位密钥 SALT 的哈希函数 AES-CMACSALT。
函数 h7 的输入为：
- SALT：128 位
- W：128 位
W 作为哈希函数 AES-CMAC 的输入 m，SALT 作为密钥 k。
h7 的输出如下：
h7(SALT, W) = AES-CMACSALT(W)
二. 密钥转换
1. BLE密钥转换为BR/EDR的密钥
Derivation of BR/EDR link key from LE LTK
我们可以观察下流程，在BLE 鉴权配对后，就有了BR/EDR linkkey的生成步骤，但是是否生成linkkey以及怎样生成linkkey就有流程讲究了！
1.1. 步骤一：确认支持LTK转换Linkkey
在SMP中pairing request/response的packet中，有两个field
其中Key Distribution的格式如下：
其中LinkKey是一个1比特字段。
当SMP在LE传输层上运行时：
- 该字段置为1表示设备希望从LTK推导出链路密钥。
- 若发起方和响应方的密钥分发/生成字段中的LinkKey位均被设为1，则应使用从LTK计算BR/EDR链路密钥的流程。
- 不支持LE安全连接的设备必须将该比特置零，并在接收时忽略此比特。
当SMP在BR/EDR传输层上运行时：
- 此字段保留供未来使用。
我们抓取一个btsnoop，来看下
可以看到上面两段都支持SC以及LinkKey，所以我们确定了希望转换Linkkey的机制，就剩下怎么转换的问题了！也就是步骤二了
1.2. 步骤二：本地计算Linkkey
LE 物理传输的长期密钥（LTK）可被转换为用于 BR/EDR 传输的 BR/EDR 链路密钥，具体转换流程如下，其中使用中间链路密钥（ILK）作为中间值，流程图如下：
若至少有一台设备将 CT2 设置为 0，则流程为：
- ILK = h6(LTK, "tmp1")
- BR/EDR 链路密钥 = h6(ILK, "lebr")
若两台设备均将 CT2 设置为 1，则流程为：
- ILK = h7(SALT, LTK)
- BR/EDR 链路密钥 = h6(ILK, "lebr")
字符串 "lebr" 通过 ASCII 编码映射为 keyID：0x6C656272。
字符串 "tmp1" 通过 ASCII 编码映射为 keyID：0x746D7031，并映射为 SALT（盐值）：0x00000000_00000000_00000000_746D7031。
注意：若 LTK 的加密密钥长度小于 16 字节（128 位），则需在 LTK 被掩码之前推导 BR/EDR 链路密钥。
NOTED：4.2的流程有点区别，只会用到h6算法，这个大家知道就可以了，Core 4.2的方式为：
ILK =h6(LTK, “tmp1”)
BR/EDR link key =h6(ILK, “lebr”)
2. BR/EDR的密钥转换为BLE密钥
Derivation of LE LTK from BR/EDR link key
我们可以先看下流程图，我们可以看下如果你要连接需要安全等级的l2cap通道，那么需要配对，生成linkkey，然后加密，然后来判断是否是否支持cross-transport key(CRTK) generation,也就是图示①，①包含步骤一/二, 然后再进行本地计算以及Key的分发，也就是图示②,②步骤包括步骤三/四。
2.1. 步骤一：确认支持SMP over BR/EDR
在确定这个需要几个，我直接贴btsnoop了
以上就是本地问下对端以及对端问询本地是否支持Extended feature，以便查询是否有Fixed channel的支持，因为SMP over BR/EDR是fixed channel,也就是0x07,如下图
这个步骤交互出来就是类似这样
但是哈·，别认为到这里就结束了·，这个只是互相告诉支持Fixed channel了，但是都支持哪些Fixed channel呢，所以需要额外的交互，如下图：
只有双方都支持，那么才有下一步谈恋爱的可能，哈哈
2.2. 步骤二：SMP交互支持
关于SMP的交互可以查看此文章：https://wlink.blog.csdn.net/article/details/146436664
这个里面主要是CT2会影响key的算法流程
下面我们就来介绍下BR/EDR linkkey转换BLE ltk的流程
2.3. 步骤三：本地计算LTK
LTK（LE物理传输密钥）可转换为BR/EDR传输的BR/EDR链路密钥，具体过程如下（使用中间链路密钥ILK作为中间值），流程图如下：
若至少有一台设备将 CT2 设置为 0，则流程为：
- ILTK = h6(Link Key, "tmp2")
- LTK = h6(ILTK, "brle")
若两台设备均将 CT2 设置为 1，则流程为：
- ILTK = h7(SALT, Link Key)
- LTK = h6(ILTK, "brle")
字符串 "brle" 通过 ASCII 编码映射为 keyID：0x62726C65。
字符串 "tmp2" 通过 ASCII 编码映射为 keyID：0x746D7032，并映射为 SALT（盐值）：0x00000000_00000000_00000000_746D7032。
NOTED：4.2的流程有点区别，只会用到h6算法，这个大家知道就可以了，Core 4.2的方式为：
ILTK =h6(Link Key, “tmp2”)
LTK =h6(ILTK, “brle”)
2.4. 步骤四：进行Key的分发
这个我们就不介绍了，可以看我的SMP的文章
