我有一些蓝牙LE v4.2 信标，我仅与连接 已知设备，我们称之为“读者”。信标是程序并由我安装。我使用数据并出售服务。
我想使用硬编码的共享密钥来实现配对或通信。我主要担心的是，只有已知且经过身份验证的设备才能发送数据（具有完整性保护）。
什么是我最好的选择？
一些预设：
我发现有趣的文档关于蓝牙低功耗（BLE）安全性：
答案 0 :(得分：1)
我对Nordicsemi devzone的问题的回答给了我一些提示。在下面找到我正在寻找的答案。我希望这会有所帮助。
资源：
忘记CSRK。几乎没有BLE堆栈支持这是一个坏主意。一个原因是它只支持在一个方向上写无响应。另一个是你需要保持写入计数器存储在闪存中。第三个是MITM可能会在一段任意时间内延迟消息，并且在此期间不需要有效连接。与普通的AES-CCM相比，它没有任何好处，除了CCM需要2.5次往返设置BLE。
资源：
没有配对：
如果从BLE安全性中删除配对步骤，则基本上只有AES-CCM具有预共享密钥，其中每个连接具有从共享密钥派生的自己的密钥和来自每一侧的随机数。 LESC是关于您要删除的配对步骤，因此在这种情况下不适用。
Vs Out of Band（OOB）：
预共享密钥是OOB（带外）配对的示例。这可能听起来有点奇怪，但实质上您使用工厂中的生产设置作为共享密钥的媒介。您不希望预先共享LTK或任何BLE绑定数据，而只需要在闪存中的某个位置使用密钥，该密钥可用于常规OOB配对。
首选解决方案是带外配对。
资源：
第一次连接时，您应该验证其他设备，并且可以在绑定时使用预共享密钥来执行此操作。您可以使用Passkey Entry或OOB进行绑定。密钥输入使用的密钥很短，所以我建议使用带有OOB的128位密钥，这样更安全。
LESC和Legacy都以128位加密密钥结束，这些密钥同样安全。配对完成后功耗相同。 LESC使用更复杂的算法，因此在配对过程中会使用更多的功率。不同之处在于密钥生成算法。这取决于你想要防御什么样的攻击。如果您使用遗留系统执行OOB并且您确定攻击者无法获取OOB数据，那么您就是安全的。如果攻击者可以获得此数据，您应该选择LESC。你连接什么样的中央设备？它是否支持OOB和/或LESC？
事实上，带有预共享密钥的LESC带外存档非常复杂，因为oob有效负载的计算应该是用私钥签名的随机数，并且这种机制在软设备中实现但不可访问。因此，我们可以重新发明轮子，或者只是决定这种计算是无用的，因为使用预共享密钥不可能带外带外。此外，LESC配对计算密集程度更高，没有任何好处。
有关带外传统配对的详细说明，请参阅bluetooth.com。
主密钥将包含在新的FW版本代码中（这可能是我的主要弱点，但我对此无能为力）。我将使用legacy Out Of Band pairing。用于配对通信加密的临时密钥（TK）将使用生成函数fc从主密钥推导出来（受蓝牙规范中描述的f5功能的启发）。
此密钥生成函数fc的定义使用带有128位密钥T的MAC函数AES-CMACT。
该功能的输入是：
字符串“******”使用扩展ASCII映射到keyID，如下所示：
密钥生成函数fc的输出如下：
传统知识计算如下：
答案 1 :(得分：0)
我不会在工厂配对，而是在FW中添加其他程序控制机制。我正在考虑可绑定的LE链接，列入白名单的MAC地址（只要我们不讨论随机/混淆的地址）。
如果您可以访问生产中的芯片/设计，您可以让生产测试站使用有线/无线可用接口并在其中添加白名单MAC地址......？
或者，在BLE通告数据中使用供应商特定数据，并在LE中心添加您过滤的X标识字节。
或者，使用自定义服务UUID组并添加到adv数据，允许中心对其进行过滤。
等等 - 重点是;我设置生产预配对的经验总是陷入混乱，并且始终是一种机制，可以清除您的配对并手动设置您或您的客户想要的东西。如何处理替换，升级等以及突然的隐式或显式突破性更改 - 总是设计一些东西，以便有办法让事情从头开始再次运行。可能使用PC上的配置工具或手机/应用程序中的管理员模式等产品取决于产品，但不依赖于生产定义的配对。