如何在出厂时进行蓝牙配对
How to do bluetooth pairing at factory time
我有一些蓝牙 LE v4.2 信标，我将 仅 连接已知设备 我们可以称之为 "readers"。信标是由我编程和安装的。我消费数据，我出售服务。
我想使用硬编码的共享密钥来实现配对或通信。我主要担心的是只有已知且经过身份验证的设备才能发送数据（具有完整性保护）。
我最好的选择是什么？
一些预想：
- 我们正在谈论 1000 台设备，并且每天都会有更多设备加入网络。
- 我已经在做广告过滤等了。我只连接到具有我的供应商 ID 的设备。
- 如果身份验证中缺乏任何安全性更可取，我的附加值是对数据的信任。
- 我有一个适用于所有设备的 OTA 更新系统。
我发现的关于低功耗蓝牙 (BLE) 安全性的有趣文档：
我不会在工厂中配对，而是在 FW 中添加其他以编程方式控制的机制。我在考虑可绑定的 LE 链接，白名单 MAC-addresses（只要我们不是在谈论 random/obfuscated 地址）。
如果您可以在生产环境中访问 chip/design，您可以让生产测试站使用 wired/wireless 可用接口并在其中添加列入白名单的 MAC 地址...？
或者，使用 BLE 广告数据中的 Vendor-specific 数据并添加 X 个您在 LE 中央过滤的标识字节。
或者，使用自定义服务 UUID 组并添加到 adv 数据中，允许中心对其进行过滤。
等等——重点是；我设置生产 pre-paired 东西的经验总是以混乱告终，应该 总是 有一种机制来清除你的配对并像你或你的客户一样手动设置东西，想。否则您将如何处理替换、升级等以及突然的隐式或显式破坏性更改——始终设计事物，以便有一种方法可以让事情重新开始，运行 再次从头开始。根据产品的不同，可能会使用来自 PC 的配置工具，或来自 phone/app 的 Admin-mode，等等——但不要依赖 production-defined 配对。
我在 Nordicsemi devzone 上的问题的答案给了我一些提示。在下面找到我一直在寻找的答案。希望对您有所帮助。
模式 1 级别 4（加密）与模式 2 级别 2（签名）
资源:
Forget about CSRK. It's a bad idea that almost no BLE stacks support. One reason is that it only supports Write Without Response in one direction. Another is that you need to keep a write counter stored in flash. A third is that a MITM could potentially delay a message for an arbitrary time and doesn't need an active connection during this time. It has no benefits at all compared to the normal AES-CCM except that CCM takes 2.5 round trips to set up for BLE.
如何使用 pre-shared 秘密
确保安全加密
资源：
我们需要配对吗？
没有配对：
If you remove the pairing step from BLE security you basically just have AES-CCM with pre-shared keys, where each connection has an own key derived from the shared key and a nonce from each side. LESC is about the pairing step which you want to remove, so that doesn't apply in that case.
Vs 带外 (OOB)：
A pre-shared key is an example of OOB (Out of band) pairing. That might sound a bit strange, but essentially you are using the production setup in your factory as the medium to share keys. You do not want to have the LTK or any BLE bonding data pre-shared, but rather just a key at some location in flash which can be used in a regular OOB pairing.
首选解决方案是带外配对。
带 pre-shared 密钥的 LESC 与带 pre-shared 密钥的 OOB ?
资源：
The first time you connect you should authenticate the other device, and you can do this by using your pre-shared key when you bond. You can bond by using Passkey Entry or OOB. The key used with Passkey Entry is short, so I would recommend using a 128-bit key with OOB, this is much more secure.
带外 LESC 与带外 Legacy
Both LESC and Legacy end up with 128-bit encryption keys, and these are equally secure. The power consumption will be the same after pairing is done. LESC uses a more complex algorithm so it will use more power during the pairing process. The difference is in the key generation algorithm. It depends on what kind of attacks you want to protect against. If you do OOB with legacy and you are sure that the attacker can't get the OOB data, you are secure. If the attacker can get this data, you should go for LESC. What kind of central device are you connecting to? Does it support OOB and/or LESC?
实际上带 pre-shared 密钥的带外 LESC 归档非常复杂，因为 oob 有效负载的计算应该是用私钥签名的随机数，并且该机制在软设备但不可访问。因此我们可以 re-invent 轮子，或者只是决定这个计算是无用的，因为 out-of-band 的 vedrop 是用 pre-shared 键不可能的。此外，LESC oob 配对计算量更大，没有任何好处。
带外旧版
有关带外传统配对的更多详细说明，请参阅 bluetooth.com。
临时密钥计算
新的固件发布代码中将包含一个主密钥（这可能是我的主要弱点，但我对此无能为力）。我将使用 legacy Out Of Band pairing。用于配对通信加密的临时密钥 (TK) 将使用生成函数 fc 从主密钥派生（灵感来自蓝牙规范中描述的 f5 函数）。
这个密钥生成函数 fc 的定义使用了 MAC 函数 AES-CMACT 和一个 128 位密钥 T.
函数的输入是：
- M为128位
- A1为56位
- A2为56位
字符串“******”使用扩展ASCII码映射成keyID如下：
- keyID = 0xXXXXXXXXXXXX
密钥生成函数fc的输出结果如下：
- fc(M, A1, A2) = AES-CMACM(keyID || 0x00 || A1 || A2 || 长度= 128)
TK 计算如下：
- TK = fc(主密钥, DB_ADDR_master, DB_ADDR_slave)
我有一些蓝牙 LE v4.2 信标，我将 仅 连接已知设备 我们可以称之为 "readers"。信标是由我编程和安装的。我消费数据，我出售服务。
我想使用硬编码的共享密钥来实现配对或通信。我主要担心的是只有已知且经过身份验证的设备才能发送数据（具有完整性保护）。
我最好的选择是什么？
一些预想：
- 我们正在谈论 1000 台设备，并且每天都会有更多设备加入网络。
- 我已经在做广告过滤等了。我只连接到具有我的供应商 ID 的设备。
- 如果身份验证中缺乏任何安全性更可取，我的附加值是对数据的信任。
- 我有一个适用于所有设备的 OTA 更新系统。
我发现的关于低功耗蓝牙 (BLE) 安全性的有趣文档：
我不会在工厂中配对，而是在 FW 中添加其他以编程方式控制的机制。我在考虑可绑定的 LE 链接，白名单 MAC-addresses（只要我们不是在谈论 random/obfuscated 地址）。
如果您可以在生产环境中访问 chip/design，您可以让生产测试站使用 wired/wireless 可用接口并在其中添加列入白名单的 MAC 地址...？
或者，使用 BLE 广告数据中的 Vendor-specific 数据并添加 X 个您在 LE 中央过滤的标识字节。
或者，使用自定义服务 UUID 组并添加到 adv 数据中，允许中心对其进行过滤。
等等——重点是；我设置生产 pre-paired 东西的经验总是以混乱告终，应该 总是 有一种机制来清除你的配对并像你或你的客户一样手动设置东西，想。否则您将如何处理替换、升级等以及突然的隐式或显式破坏性更改——始终设计事物，以便有一种方法可以让事情重新开始，运行 再次从头开始。根据产品的不同，可能会使用来自 PC 的配置工具，或来自 phone/app 的 Admin-mode，等等——但不要依赖 production-defined 配对。
我在 Nordicsemi devzone 上的问题的答案给了我一些提示。在下面找到我一直在寻找的答案。希望对您有所帮助。
模式 1 级别 4（加密）与模式 2 级别 2（签名）
资源:
Forget about CSRK. It's a bad idea that almost no BLE stacks support. One reason is that it only supports Write Without Response in one direction. Another is that you need to keep a write counter stored in flash. A third is that a MITM could potentially delay a message for an arbitrary time and doesn't need an active connection during this time. It has no benefits at all compared to the normal AES-CCM except that CCM takes 2.5 round trips to set up for BLE.
如何使用 pre-shared 秘密
确保安全加密资源：
我们需要配对吗？
没有配对：
If you remove the pairing step from BLE security you basically just have AES-CCM with pre-shared keys, where each connection has an own key derived from the shared key and a nonce from each side. LESC is about the pairing step which you want to remove, so that doesn't apply in that case.
Vs 带外 (OOB)：
A pre-shared key is an example of OOB (Out of band) pairing. That might sound a bit strange, but essentially you are using the production setup in your factory as the medium to share keys. You do not want to have the LTK or any BLE bonding data pre-shared, but rather just a key at some location in flash which can be used in a regular OOB pairing.
首选解决方案是带外配对。
带 pre-shared 密钥的 LESC 与带 pre-shared 密钥的 OOB ?
资源：
The first time you connect you should authenticate the other device, and you can do this by using your pre-shared key when you bond. You can bond by using Passkey Entry or OOB. The key used with Passkey Entry is short, so I would recommend using a 128-bit key with OOB, this is much more secure.
带外 LESC 与带外 Legacy
Both LESC and Legacy end up with 128-bit encryption keys, and these are equally secure. The power consumption will be the same after pairing is done. LESC uses a more complex algorithm so it will use more power during the pairing process. The difference is in the key generation algorithm. It depends on what kind of attacks you want to protect against. If you do OOB with legacy and you are sure that the attacker can't get the OOB data, you are secure. If the attacker can get this data, you should go for LESC. What kind of central device are you connecting to? Does it support OOB and/or LESC?
实际上带 pre-shared 密钥的带外 LESC 归档非常复杂，因为 oob 有效负载的计算应该是用私钥签名的随机数，并且该机制在软设备但不可访问。因此我们可以 re-invent 轮子，或者只是决定这个计算是无用的，因为 out-of-band 的 vedrop 是用 pre-shared 键不可能的。此外，LESC oob 配对计算量更大，没有任何好处。
带外旧版
有关带外传统配对的更多详细说明，请参阅 bluetooth.com。
临时密钥计算
新的固件发布代码中将包含一个主密钥（这可能是我的主要弱点，但我对此无能为力）。我将使用 legacy Out Of Band pairing。用于配对通信加密的临时密钥 (TK) 将使用生成函数 fc 从主密钥派生（灵感来自蓝牙规范中描述的 f5 函数）。
这个密钥生成函数 fc 的定义使用了 MAC 函数 AES-CMACT 和一个 128 位密钥 T.
函数的输入是：
- M为128位
- A1为56位
- A2为56位
字符串“******”使用扩展ASCII码映射成keyID如下：
- keyID = 0xXXXXXXXXXXXX
密钥生成函数fc的输出结果如下：
- fc(M, A1, A2) = AES-CMACM(keyID || 0x00 || A1 || A2 || 长度= 128)
TK 计算如下：
- TK = fc(主密钥, DB_ADDR_master, DB_ADDR_slave)