Thread 1.4凭证共享机制：亚马逊、苹果、谷歌设备首次接入同一Mesh网络的技术突破

Thread协议自诞生起便承载着"一张低功耗Mesh网络覆盖全屋"的愿景，但现实却长期被"网络孤岛"问题困扰。苹果HomePod、谷歌Nest Hub、亚马逊Echo、宜家Dirigera、三星SmartThings等主流智能家居生态各自维护独立的Thread边界路由器(TBR)，每个TBR在首次配置时自动生成一套独立的网络凭证(Operational Dataset)，包括网络名称、PAN ID、主密钥(Master Key)、PSKc等参数。

这导致一个典型家庭可能同时存在4~5个互不通信的Thread网络——苹果的灯、谷歌的传感器、亚马逊的插座分属不同Mesh，Matter应用层虽能跨生态控制设备，但控制指令需绕行云端中转，链路长、延迟高、可靠性差。

Thread 1.4于2024年10月正式发布，其核心特性**Credential Sharing(凭证共享)**正是为解决这一根本性架构缺陷而设计。

协议机制：ePSKc临时密钥与DTLS安全通道

凭证共享的技术核心是Ephemeral Pre-Shared Key for Commissioner(ePSKc)——一种临时预共享密钥机制。其设计哲学是：不直接暴露完整的网络凭证数据集(该数据集远比Wi-Fi密码复杂)，而是通过一个短时效的一次性口令(OTP)建立安全通道，由Candidate应用(即新TBR的配套App)在获得临时管理权限后提取所需凭证。

完整的凭证共享流程包含以下关键步骤：

第一步：ePSKc生成与广播

现有TBR(如宜家Dirigera)的配套App发起"共享网络凭证"操作，TBR生成一个ePSKc临时密钥，并派生出一个用户可读的一次性口令(OTP)。TBR随即进入"ePSKc模式"，开始通过mDNS广播_meshcop-e._udp服务记录(区别于常规的_meshcop._udp)，向局域网内的Candidate应用宣告自身的存在和连接信息。

第二步：Candidate应用建立安全连接

用户在目标生态的App(如三星SmartThings App)中输入从源生态App获取的OTP。Candidate App利用该OTP派生出ePSKc密钥，监听_meshcop-e._udp广播，获取源TBR的IPv6地址和端口信息，随后通过DTLS(Datagram Transport Layer Security)协议与源TBR建立加密连接。

第三步：凭证提取与分发

DTLS连接建立后，源TBR验证ePSKc正确性，授予Candidate App临时管理权限。Candidate App随即请求并提取源网络的Active Operational Dataset(包含网络名称、PAN ID、扩展PAN ID、主密钥、PSKc、信道掩码等完整参数)。提取完成后，DTLS连接断开，源TBR退出ePSKc模式，停止广播_meshcop-e._udp。

第四步：新TBR加入统一网络

Candidate App将提取到的凭证安全存储于移动设备密钥库中(用于后续新设备入网)，并通过厂商自定义方式将凭证写入目标TBR。目标TBR加载该凭证后，以相同网络身份加入已有Mesh网络，而非创建新网络。

架构设计：三层安全模型与角色分工

凭证共享的架构设计遵循"最小权限+临时授权"原则，涉及三个核心角色：

源TBR(Border Router)：持有完整网络凭证的现有边界路由器，仅响应携带正确ePSKc的连接请求，且ePSKc模式具有时效限制(通常5分钟)，超时自动关闭。

Candidate App(移动应用)：充当"中间人"角色，负责在两个生态之间安全传递凭证。Thread规范明确要求必须通过移动App中转，TBR之间不能直接互相获取凭证。

目标TBR(新边界路由器)：接收凭证后以从属身份加入已有网络，其路由角色(Leader/Router/End Device)由网络拓扑自动决定。

安全层面，整个流程采用三层防护：(1)ePSKc的一次性和时效性防止重放攻击;(2)DTLS加密通道防止中间人窃听;(3)凭证存储于移动设备硬件安全模块(如Apple Secure Enclave、Android StrongBox)，防止凭证泄露。

程序实现：OpenThread栈的配置与CLI操作

基于Silicon Labs EFR32MG26等平台的OpenThread实现中，凭证共享功能通过以下配置启用：

在Simplicity Studio中创建SoC CLI(FTD)项目后，需在Stack组件中将OPENTHREAD_CONFIG_THREAD_VERSION配置为OPENTHREAD_CONFIG_THREAD_VERSION_1_4，并启用以下关键编译宏：

// 启用ePSKc凭证共享(边界路由器必须)

#define OPENTHREAD_CONFIG_BORDER_AGENT_EPHEMERAL_KEY_ENABLE 1

// 启用扩展Mesh诊断(边界路由器必须)

#define OPENTHREAD_CONFIG_MESH_DIAG_ENABLE 1

// 启用DHCPv6前缀委派(边界路由器必须)

#define OPENTHREAD_CONFIG_BORDER_ROUTING_DHCP6_PD_ENABLE 1

在OTBR(OpenThread Border Router)的CLI中，凭证共享的核心操作命令为：

# 生成ePSKc并开启共享窗口(PASSCODE为用户设定的临时口令，300000为有效期毫秒数)

ot-ctl ba ephemeralkey start PASSCODE 300000

# 查看当前ePSKc状态

ot-ctl ba ephemeralkey

执行上述命令后，OTBR开始广播_meshcop-e._udp mDNS服务记录，Candidate App即可发现并连接。

主流生态适配现状

生态TBR设备凭证共享支持状态

苹果Apple TV / HomePodtvOS 27开发者测试版已升级Thread 1.4，但凭证共享UI尚未开放

谷歌Google TV Streamer / Nest Hub已完成Thread 1.4升级，支持生成二维码加入网络，功能暂不可用

三星SmartThings智能中控屏2025年10月已支持凭证共享

宜家Dirigera智能网关已搭载Thread 1.4，通过IKEA App支持凭证共享

亚马逊Echo / Eero截至2026年8月尚未完成Thread 1.4升级，亚马逊已确认年内落地

Home AssistantOTBR Add-onDocker版本已支持Thread 1.4，HAOS Add-on仍在适配中

与TREL的关系与区别

凭证共享常与Thread 1.4的另一特性TREL(Thread Radio Encapsulation Link，即Thread-over-Infrastructure)混淆，但两者解决的是不同层面的问题：

凭证共享解决的是"如何让不同生态的TBR加入同一个Mesh网络"的入网问题，属于网络组建阶段的一次性操作。

TREL解决的是"已加入同一网络的TBR之间如何通过以太网/Wi-Fi骨干网中继Thread报文"的通信问题，属于网络运行阶段的持续能力。

两者互补：凭证共享让多厂商TBR汇聚到同一网络，TREL让地理分散的TBR通过有线骨干互联，共同构建大规模、高可靠的统一Thread Mesh。

展望

凭证共享的技术突破在于：它首次在不牺牲安全性的前提下，实现了跨生态Thread网络的统一。用户不再需要被迫选择"苹果全家桶"或"谷歌全家桶"，而是可以自由混搭不同品牌的Thread设备，所有TBR协同构建一张统一的低功耗Mesh网络。

随着苹果、谷歌在2026年下半年陆续开放凭证共享UI，以及亚马逊完成Thread 1.4适配，"一个家庭、一张Thread网络"的愿景将真正落地。对于设备制造商而言，基于OpenThread 1.4栈开发的产品将天然具备跨生态入网能力，大幅降低认证和适配成本，加速Matter over Thread生态的规模化普及。