SPEKE v2：口令认证与密钥协商技术详解 双方只掌握同一段口令时，如何在不发送口令明文的前提下确认彼此，并得到用于通信的会话密钥？SPEKE 将口令参与的密钥交换与双向密钥确认结合起来，解决这一问题。本文以 IoT Connect 的 SPEKE v2 实现为例，介绍四消息交互、曲线基点构造、X25519 共享秘密计算、HKDF 密钥派生和 AES-GCM 数据保护。 SPEKE 与 SPAK

摘要 随着物联网设备规模的持续扩张，"设备身份可验证"已成为万物互联信任体系的基础问题。在本地中枢（Hub）架构下，设备接入决策由局域网内的边缘节点执行，而身份信任的材料与策略仍由云端认证服务供给，由此形成"边缘执行、云端背书"的协同认证范式。这一范式中的证书链校验，横跨传输层端点认证与应用层业务认证两个信任域，涉及证书路径验证、撤销状态判定、身份属性策略与

CoAP 本地控制可靠性：发现、会话与重启恢复 摘要 本文链路中的 CoAP 运行在 UDP 之上，常见失败表象是：控制端已经发出请求，设备却没有回复。根因未必在网络，也可能是双方对设备身份、Session 或消息序列的理解已经不一致。 本文以 OpenHarmony iot_management 的本地控制链路为背景，梳理双端口发现、设备信息合并、baseUrl、PUUID、Session、se

IoT 设备身份建立：从 PIN/PAKE 到 AuthCode 会话 摘要 IoT 设备首次接入和日常控制面对的是两类不同问题：首次接入时，设备可能只有 PIN，没有长期身份；日常控制时，系统则需要低开销地验证控制端并复用安全会话。 本文说明 PIN/SPEKE、CloudSetup、AuthCode 与本地控制 Session 的关系：它们不是替代方案，而是身份建立链路中的不同阶段。 1. 网

OpenHarmony 局域网设备控制架构解析：从设备发现到业务控制 摘要 在局域网 IoT 场景中，设备连上 Wi-Fi 并不等于控制端已经能够安全控制设备。一个完整的本地控制系统还需要解决设备发现、网络可达、身份建立、安全会话、业务控制和状态同步等问题。 本文以 OpenHarmony iot_management 组件为背景，分析 BLE、Wi-Fi、CoAP、SPEKE 和本地控制 Ses