蓝牙低能耗安全连接 – 数值比较

•  正常工作
• 数值比较（仅适用于 LE 安全连接）
•  密钥输入
•  带外 (OOB)

数字比较仅适用于 LE 安全连接，不适用于传统配对。所以这是一个较新的关联模型，今天我们将深入了解它。

1. 第 1 阶段 – 配对特征交换

我在第 1 部分中谈到了配对功能交换，但我想在这里回顾一下。表 1 是配对请求/响应数据包定义。在“AuthReq”字段中，有一位名为“SC”。如果设备支持 LE 安全连接配对，则 SC 字段应设置为 1，否则应设置为 0。如果两个设备都支持 LE 安全连接配对，则应使用 LE 安全连接配对，否则应使用 LE Legacy应使用配对。

表 1 配对请求/响应

*位顺序为 LSB 到 MSB。

因此，如果两个设备想要通过 LE 安全连接进行配对，则必须将“SC”设置为 1，以指示对等设备“我有安全连接的能力”。

2. 第 2 阶段 – 密钥生成方法选择

配对特征交换后，发起者和响应者应确定将使用哪种密钥生成方法。以下是密钥生成方法的 C 语法编码示例：

表 2 列出了用于数字比较的发起和响应设备的 IO 能力。当发起设备和响应设备都具有显示和是/否 I/O 功能，或显示和键盘 I/O 功能时，将使用数字比较关联模型。

表 2 用于数值比较的 IO 功能映射

* – 表示它适用于除数字比较之外的其他密钥生成方法。

3. 第 2 阶段 – 身份验证

密钥生成后，配对将进入第 2 阶段，即身份验证。目的是防止中间人 (MITM) 攻击并生成用于加密连接链路的密钥。

在公钥交换中，每个设备都会生成自己的椭圆曲线 Diffie-Hellman (ECDH) 公私密钥对。公钥-私钥对包含私钥和公钥。

• SKa，发起设备的私钥
• PKa，发起设备的公钥
• SKb，响应设备的私钥
• PKb，响应设备的公钥

图1、Numeric Comparison的认证流程

配对是通过发起设备将其 PKa 发送到响应设备来启动的。响应设备用它自己的 PKb 进行回复。交换公钥后，设备就可以开始计算 Diffie-Hellman 密钥；您可以看到它从图 1 中的 1b 末尾开始。

之后，每个设备都会选择一个随机的 128 位随机数。该值用于防止重放攻击。

• Na，发起设备的 128 位随机数。
• Nb，响应设备的 128 位随机数。

随后，响应设备计算承诺 Cb，该承诺是使用 Nb、PKa、PKb 和 0 计算得出的。如步骤 3、图 1 所示。

步骤 4，响应设备在接收发起设备的 Na 之前必须共享 Cb。

步骤 5，发起设备必须在接收响应设备的 Nb 之前共享其 Na。

步骤6，发起设备在收到响应设备的Nb后必须检查来自响应设备的Cb。

此时，发起或响应设备已经知道对等设备的公钥和随机数。发起设备可以确认来自响应设备的承诺(Cb)。此时的失败表明存在攻击者或其他传输错误，并应导致配对过程中止（步骤 6.a）。

假设承诺检查成功，两个设备各自计算 6 位确认值，并在各自的设备上向用户显示。用户应检查这些 6 位值是否匹配并确认是否匹配。如果不匹配，则配对中止。

4. 第 3 阶段 – 长期密钥，LTK

当认证成功后，两台设备开始计算LTK，用于链路加密。这是配对和重新连接难题的最后一部分：在不同的关联模型中，验证对等设备并防止中间人 (MITM) 攻击。由于 LTK 计算对于任何 LE 安全连接关联模型都很常见，因此我将在下一篇博文中更详细地讨论它。

 5. 结论

根据用户体验和便利性，与第 3 部分“密钥输入、数字比较”相比，只需要 YES 和 NO 两个按钮来指示这两个设备之间的 6 位确认值是否匹配，而不需要数字键盘用于密钥输入，从“0”到“9”，因此这是简化硬件 I/O 功能的改进。同时，由于数字比较仅适用于 LE 安全连接，因此它可以针对窃听和 MITM 等威胁提供增强的保护。所以，如果您开始开发一款对隐私敏感并且需要蓝牙 LE 链路高度保护的产品，那么这里是您不错的选择。

6. 报文说明

Pairing DHKey Check的作用：

"Pairing DHKey Check"是在生成Diffie-Hellman密钥交换（DHKey）过程完成后执行的一步，目的是验证双方设备在此次密钥交换过程中生成的密钥是否一致。Diffie-Hellman密钥交换是一个开放密钥交换的方法，允许双方在没有共享秘密的情况下建立一个共享密钥。

在蓝牙4.2及以上版本中引入的LE Secure Connections配对过程，使用的是ECDH（Elliptic Curve Diffie-Hellman）密钥交换，提供了比之前标准更高的安全级别。

通过DHKey Check ECDH过程生成的密钥将用于加密通信，因此这个检查步骤确保了没有中间人（Man in the Middle, MitM）攻击。如果检查失败，表明密钥交换过程可能被干扰，配对过程将被终止。

DHKey Check的工作原理：

1. 生成确认值：在最初的密钥交换步骤后，设备A和设备B各自使用自己的私钥和对方的公钥来创建一个DHKey。然后，它们各自使用该DHKey和一些随机数（RAND）来生成一个确认值（DHKey Check Value）。

2. 交换确认值：设备A和设备B将各自生成的确认值发送给对方。

3. 验证确认值：接收到对方确认值的设备将进行验证，看是否和自己计算的值匹配。这个过程确保双方都有一样的DHKey。

4. 确认结果：如果确认值匹配，则认为密钥交换是安全的，配对过程继续；如果不匹配，则配对过程失败，并且设备需要重新启动配对过程或终止连接

最后，进行IRK交换，对应报文Opcode: Identity Information (0x08)