如需要了解更多蓝牙相关知识，请点击下方连接
https://blog.csdn.net/weixin_47456647/article/details/155188246?spm=1011.2415.3001.5331
蓝牙 ® 网状网络 允许选定的网络节点充当代理节点 。代理节点同时支持蓝牙 GAP/GATT 与蓝牙网状网络通信，能让 GATT 客户端（如移动、桌面或网页应用）接入蓝牙网状网络 ------ 这类应用通常会提供用于监控和控制的 GUI（图形用户界面），它们也被称为代理应用。
代理应用通过 GATT 操作来收发蓝牙网状网络的代理 PDU （协议数据单元），这类 PDU 通常会封装网状网络 PDU。代理节点负责在代理应用与蓝牙网状网络之间转发消息（双向转发）。
《蓝牙网状网络规范》提供了网络与设备安全的相关信息，但方案架构师在设计方案时，可能需要考虑规范未涵盖的额外问题。本文将分享一些思考：当你的蓝牙网状网络方案包含一个或多个代理应用时，需要考虑并解决哪些问题。
蓝牙网状网络安全密钥
蓝牙网状网络安全的核心是三类安全密钥，用于对蓝牙网状消息进行加密、认证和模糊处理：
- 网络密钥（NetKey）：用于接入特定网络或子网，对蓝牙网状消息中属于协议栈底层的字段进行加密与认证。
- 应用密钥（AppKey）：用于接入特定的蓝牙网状网络应用（如照明、空调），对消息中属于协议栈上层的字段进行加密与认证。AppKey 与特定 NetKey 绑定（二者存在数学关联），因此设备必须同时拥有这两个密钥，才能用于保护蓝牙网状消息。
- 设备密钥（DevKey）：用于保护与特定蓝牙网状网络设备的直接通信，通常仅在配置设备时使用。蓝牙网状网络中的每个设备都有唯一的 DevKey。
密钥由配网与配置流程生成并分发。
我们要配网和配置什么？
设计蓝牙 ® 网状网络代理应用时，会引出一些关于蓝牙网状网络安全的问题 ------ 这些问题不在规范范围内（规范仅关注蓝牙网状网络协议及相关流程的集合）。
通常，密钥会下发并关联到特定设备。例如，某个灯光开关会配备特定的 NetKey、一个或多个 AppKey，以及唯一的 DevKey。设备通过持有这些密钥，就能以所需方式参与网络通信。
代理应用（无论是移动、桌面还是网页应用）也需要进行配网和配置，以便获取合适的密钥，通过代理节点安全地与其他蓝牙网状网络节点交互。前文提到的蓝牙网状网络安全规则，同样适用于代理应用：任何要生成或处理蓝牙网状消息的实体，都必须持有并正确使用密钥来处理其收发的消息。
移动和桌面应用一般是安装在特定设备（如笔记本电脑）上的编译代码或可解释代码。配网和配置操作会向该设备下发蓝牙网状网络密钥 ------ 但这种方式是否正确、是否足够安全？桌面和移动设备通常是搭载复杂操作系统的平台，可运行多个应用。若配网和配置让整个平台都能获取蓝牙网状网络安全密钥，那么平台上的所有应用都可能接入你的蓝牙网状网络。这显然不是你想要的，还会给网络安全带来漏洞。不过，具体需求最终由你（架构师）决定。
更合理的做法是：将密钥下发给特定设备上的特定应用。因此，你需要确保密钥存储在设备的某个分区中，仅关联应用可访问。大多数操作系统都提供了安全分区系统的方式，应用通常运行在 "沙箱" 中，拥有私有的文件系统，仅该应用可访问 ------ 这可以作为存储特定应用专属蓝牙网状密钥的候选位置。
我们要为谁配网？
网页应用让 "蓝牙网状网络新密钥应关联到什么实体" 这个问题更复杂了。网页应用的特性是：只要设备有合适的浏览器，就能从网络上的任意设备访问它。IP 网络中可能存在多个网页应用，但这类应用的使用并不像原生胖客户端实例那样绑定到特定设备。
通常，用户通过在浏览器中输入网页应用的 URL，从 IP 网络中的设备访问该应用。通常，用户需要先通过某种方式完成应用认证，才能获得访问权限 ------ 但这一过程可能发生在各类设备上。
完成认证后，网页应用可能会限制用户仅能使用部分功能（另一用户可能能使用全部功能）。这些功能子集可能对应不同的蓝牙网状网络应用，因此也对应不同的 AppKey。例如，访问楼宇监控与控制网页应用时，一个用户可能只能操作照明控制应用，而另一个用户可以控制整栋楼宇的所有系统（不只是照明）。
此外，某个用户可能被限制仅能控制特定蓝牙网状网络子网中的设备（比如对应楼宇的某一层），这会对应特定的 NetKey。
当用户 Alice 在三楼同事的台式机上登录楼宇的蓝牙网状网络监控应用时，应使用哪些蓝牙网状网络密钥？具体该如何实现？这类问题是我们在需求和方案设计中必须回答的。
一种可能性是：蓝牙网状网络密钥关联到已认证的用户和特定网页应用，而非特定物理设备。架构师必须在需求和方案设计中解决这类问题。
代理应用应如何配网？
若应用技术支持，代理应用的配网方式应与蓝牙网状网络中的其他节点完全一致。例如，移动应用应能通过一种或多种配网传输方式和承载，支持配网协议。
但在某些情况下，这可能无法实现。承载蓝牙网状网络网页应用的 Web 服务器不太可能包含任何蓝牙协议栈。此时，需要设计专有方法，由 Web 服务器生成并分发密钥 ------ 这需要方案架构师自行设计。在为这类特殊场景设计专有方案时，应考虑标准配网流程和协议解决的问题（如认证、密钥保密性）。
密钥存储
如果我们决定将蓝牙网状网络密钥绑定到用户及他们对特定应用的使用（而非设备），且方案需求规定用户可从 IP 网络的任意设备访问应用，那么我们只能将蓝牙网状网络密钥存储在中央服务器上。我们需要设计一个数据库，将密钥集与用户、应用关联，并考虑这些集中存储密钥的安全性。这里不需要全新的安全方案：安全存储关键数据（包括安全密钥）是各类应用（尤其是网页应用）的常见需求。我们需要确保服务器的物理安全，仅允许授权人员访问（例如，需使用合适的密码短语访问加密的密钥存储）。
执行加密运算
代理应用必须构建蓝牙网状网络代理 PDU，这涉及三个需要使用蓝牙网状网络安全密钥的加密步骤：
- AppKey 用于加密和认证蓝牙网状访问载荷 PDU；
- 关联的 NetKey 用于加密和认证蓝牙网状网络 PDU；
- 蓝牙网状网络报头（包含 CTL、TTL、SEQ、SRC 字段）需通过 ** 隐私密钥（由 NetKey 派生）** 进行模糊处理。
这些加密计算应在哪里执行？我们可以选择在客户端（代理应用内部）执行，或由服务器对网络 PDU 进行安全处理后，将结果返回给客户端用于构建代理 PDU。
从安全角度看，集中在服务器执行加密函数可能是更优的选择。但也需要考虑其他因素：服务器集中处理需要足够的算力，可能还需要硬件安全模块来分担 CPU 负载。你可能认为从服务器下载密钥、在客户端本地执行计算有一定优势，但这会增加安全需求和方案的复杂度。若选择这种方式，蓝牙网状密钥及其他敏感数据必须通过 TLS 加密的 IP 连接下载，且服务器本身需通过认证 ------ 这些是网页安全领域的基础要求。
在我看来，对于可能通过各类物理客户端设备访问的网页应用，将蓝牙网状网络密钥保存在物理安全的中央位置（永不离开该位置）是最佳方案。
代理应用的其他配置问题
蓝牙网状网络安全密钥并非本文讨论的代理应用考量因素中唯一受影响的部分。例如，所有蓝牙网状网络设备都必须有唯一的单播地址。当蓝牙网状消息的发起方和最终接收方是 "可通过多台设备、由不同用户访问的网页应用" 时，消息中应使用什么单播地址？可以想象，类似的思路会引导我们得出类似结论：或许每个 "用户 + 代理应用" 的组合都应分配一个唯一的单播地址。你的配置客户端需要能够分配单播地址，以支持非标准、带外分配的场景。
其他可配置的蓝牙网状网络属性（根据配置服务器模型），也应结合整体方案需求进行评估，并以类似方式处理。
替代架构
蓝牙网状网络代理节点是 "非网状蓝牙应用与蓝牙网状网络交互" 的一种方式，它是标准的一部分 ------ 完整实现相关流程和协议，可带来互操作性优势，还能使用标准配网和配置工具。但如前文所述，有时需求、方案架构或应用技术限制会导致场景超出蓝牙规范范围，此时方案的部分内容需要采用专有设计。
不过，使用代理节点并非应用与蓝牙网状网络集成的唯一方式。另一种替代架构可以包含IP - 网状网关，它能在基于 IP 的协议与蓝牙网状网络协议之间进行转换。在这种架构下，移动、桌面和网页应用可以使用 IP 协议，完全与蓝牙协议隔离。目前还没有 IP - 蓝牙网状网络网关的标准，因此这也需要作为方案架构中的专有部分来设计。
总结
构建安全的蓝牙网状网络代理应用，需要方案架构师解决蓝牙规范未涵盖的问题。我们需要明确 "要保护的对象" 以及 "应用的访问和使用方式"，但无需完全从零开始 ------ 蓝牙网状网络代理应用可以借鉴网页、移动、客户端 / 服务器应用领域中成熟的安全方案，来构建用于蓝牙网状网络监控和控制的安全 GUI 应用。