3.6.3.1、配对特征交换得到临时密钥(TK)值 性：
0
Authenticated MITM protection：可靠中间人保护 Unauthenticated no MITM protection：不可靠无中间人保护 No security requirements：无安全需求 MITM 为 man-in-the-middle 即中间人的意思，而这里的“人”应 该是第三方蓝牙设备。可靠中间人保护就是在 TK 共享是不会有第三 方设备知道共享的 TK 密钥；不可靠无中间人保护就是说 TK 共享时第 三方蓝牙设备很容易知道共享的 TK 值，所以是不可靠的传输；而无 保护就是光屁股在外面跑，也不怕被别人盗取数据。 然而事实上配对特征交换不只是简单的交换 IO 能力，同时 TK 也 不单单由 IO 决定，在安全管理协议中的配对特征交换主要完成：交 换 IO 能力、OOB(Out Of Band:带外)认证数据可用性、认证需求、秘 钥大小以及图 3-66 中第 3 阶段将要分配的特定密钥。IO 能力、OOB 认证数据可用性以及认证需求用来决定图 3-66 中第 2 阶段计算 STK 生成的方法，其实就是决定 TK 的生成方法。
认证需求是指需不需绑定和需不需要防止 MITM。 密钥大小：在协议规范中有规定密钥的大小为[7Bytes,16Bytes]， 也就是[56bits,128bits]，但是注意在 BLE 中所有密钥都是 128bits 长度的密钥，所以如果长度不够，那么就将高位补 0，从而达到 128bits。
3.6.3.1.1、Input 和 Output 能力 特征交换时， 将自己的综合能力发送给对方设备，对方设备也会 把自己的 IO 综合能力发送过来，最后根据两个设备的能力最终选择 那种方式实现 TK 值的共享，也就是说 TK 值虽然需要共享，但是这个 密码不是两个设备通过无线进行通信得到的，而是通过人为输入或者 默认的方式实现的。 那么两个设备 IO 能力综合会有哪些产生 TK 的方 式呢？见表 3-20。 从表 3-20 可以知道， IO 能力的交换决定的 TK 值的方式只有两种，
3.6.3.1.2、Just Work:只工作 仅工作方式两设备使用的是默认的 TK 值，即 6 个 0。对于这种方式 是一个不可靠的加密链路，它不能防止 MITM 攻击。这种方式使 用时可靠的前提是，确保在配对绑定是能保证没有 MITM 攻击，那么 在之后的连接中加密的数据是无法被其它设备窃听的，也就是说这种 方式保护的是将来的加密链路安全，但是不能保护配对绑定过程。
3.6.3.1.3、Passkey Entry:输入密码 上面有提到 TK 的共享并不会是通过无线传输的，而是通过人为
3.6.3.1.4、Out of Band:带外 带外是使用另一无线方式将数据传给蓝牙设备，如果带外本身能 式下的 TK 值是 128bits 的随机数，被虽然还是有概率被第三方猜中，
3.6.3.2、身份确认以及短期秘钥(STK)生产 配对的第 1 阶段通过特征交换仅仅得到 TK 值，而 TK 值是用来做 什么的呢？在第 2 阶段用来作为密钥进行计算两个重要的值： 身份确认值 短期秘钥(STK)值
3.6.3.2.1、身份确认值计算 Pairing Request command, ：配对请求命令 Pairing Response command, ：配对应答命令 initiating device address type, ：发起者设备地址类型 initiating device address, ：发起者设备地址 responding device address type, ：应答者设备地址类型 responding devices address)：应答者设备地址
3.6.3.2.2、短期秘钥(STK)值计算 短期密钥 STK 计算了干什么呢？为什么叫做“短期秘钥”呢？STK 存在的目的在于配对绑定过程的第 3 阶段不再使用明文进行数据传 输，而是使用 STK 作为长期秘钥 LTK 将需要交互的数据进行加密，第 3 阶段传输是在未来加密链路中使用到的 LTK、IRK 以及 CSRK 等等密 钥，所以必须进行加密处理，也就是说在绑定配对过程中，第 3 阶段 就已经使用加密的密文传输。 然而 STK 或者 LTK 并不能直接作为将要发送的数据包进行加密的 密钥，为了传输的数据包更加的安全，加密数据包的密钥是会话密钥 Session Key(SK)，也就是说会话密钥 SK 是用 STK 或者 LTK 当做密钥通 过加密引擎函数 e 计算得到的，计算公式如下： SK=e(LTK,(SKDslave||SKDmaste)) 参数 LTK 即为长期密钥，上文提到 STK 可以代替 LTK 作为密钥计 算 SK，但是什么情况下可以使用 STK 代替 LTK 呢？当两个设备第一 次进行配对绑定时，在第 3 阶段就需要进行加密链路传输数据，而此 时长期密钥 LTK 是没有共享的，所以需要通过第 2 阶段计算得到的 STK 作为长期密钥 LTK 来计算会话密钥 SK。也就是说只要加密链路传 输数据包那么必须使用会话秘钥 SK 进行链路加密 。那么具体判断使
3.6.3.3、特定密钥计算 在配对绑定的第 3 个阶段传输就是两个设备商量好了的特定的 密钥，然而是不是有个问题，这些密钥到底是从哪儿来的呢？所有密 钥都是通过计算得到。
3.6.3.3.1、长期密钥 LTK 计算LTK=d1(ER,DIV,0)=e(ER,0||DIV) 然而这里最难搞定的还是 ER 和 DIV 这两个参数。ER(Encryption Root)在 nrf51822 中其实是一个 128bits 的伪随机数，并掩膜在 Flash 中 。协议原文： ER is used to generate LTK and CSRK. ER can be assigned, randomly gene rated by the 这参数就这一句话，但是我在协议中却找了好长时间啊！DIV 它
EDIV 即为加密分散器，这个值是在配对绑定过程中是由从机发送 也被固定在 flash 中，协议原文： IR can be used to generate IRK and other requ ired keys. IR can be assigned, randomly
0
/6 
工商网监
湘ICP备2023018690号
3143
淘帖
1285
发表评论
赞
回复
