OpenHarmony 分布式设备认证流程详解

分布式设备认证是 OpenHarmony 分布式软总线的第一道门槛。本文详解从设备发现、绑定、双向认证到加密会话建立的完整链路，并梳理核心数据结构与源码模块位置。

flowchart LR
    A[发现 Discovery<br/>COAP/UDP广播] --> B[绑定 Binding<br/>PIN/二维码/NFC]
    B --> C[认证 Authentication<br/>挑战-响应+ECDH]
    C --> D[会话建立 Session<br/>AES-GCM加密通道]
    B -.公钥持久化.-> E[(信任数据库)]
    C -.会话密钥.-> F[(HUKS密钥存储)]

一、概述

分布式设备认证是 OpenHarmony 分布式软总线的第一道门槛。它的目标很简单：让两个设备安全地建立彼此信任，然后才能在它们之间传输数据、流转任务、共享资源。你可以把认证看成设备之间的"握手 + 身份验证"。

整个流程围绕一个核心组件展开——组网模块（Networking / SoftBus）。认证通过后，设备会被纳入同一"信任网络"，后续通信就不再重复走完整认证了。

二、整体阶段划分

认证流程分为 4 个阶段，按顺序执行：

阶段	名称	作用
1	发现（Discovery）	设备互相找到对方
2	绑定（Binding）	建立信任关系（PIN 码/二维码/碰一碰）
3	认证（Auth）	双向身份校验 + 会话密钥协商
4	会话建立（Session）	加密通道建立，开始通信

下面逐个展开。

三、发现阶段（Discovery）

设备在局域网上通过 COAP/UDP 广播或组播宣告自己存在。消息内容大致为：

{
  "deviceId": "哈希后的设备唯一标识",
  "deviceName": "MatePad-XX",
  "deviceType": "tablet",
  "capability": ["distributed_softbus", "screen_cast", "audio"]
}

• 发送间隔由心跳机制控制，默认几秒一次
• 接收方据此发现附近设备并将其缓存在"设备列表"中
• 这个阶段不携带敏感信息，只做初步握手

四、绑定阶段（Binding）

绑定是建立信任的关键环节。有三种常见的方式：

4.1 PIN 码绑定

1. 设备 A 向设备 B 发起绑定请求
2. 设备 B 弹出一个随机生成的 6 位 PIN 码
3. 用户在设备 A 上输入同样的 PIN 码
4. 两端用 PIN 码衍生出临时会话密钥，交换各自的身份公钥

4.2 二维码绑定

1. 设备 B 生成一个二维码，内容包含其设备信息 + 一次性临时口令（SessionKey）
2. 设备 A 扫码后，通过解析到的 SessionKey 建立一条临时加密通道
3. 在临时通道上交换长期身份公钥

4.3 碰一碰（NFC）

1. 设备 A 碰触设备 B
2. NFC 携带一次性口令（SessionKey），通过 NCI 协议传输
3. 后续流程与二维码类似，只是传输通道变成了 NFC

绑定完成后，双方各自保存对方的身份公钥到本地信任数据库（Trust DB / Credential 数据库）。

绑定的本质：交换公钥 + 用户确认。 用户确认阻止了中间人攻击。

五、认证阶段（Authentication）

绑定是一次性的。每次真正通信前，设备之间会走一个更轻量的双向认证——挑战-响应（Challenge-Response）协议：

sequenceDiagram
    participant A as 设备A
    participant B as 设备B

    A->>B: 1. AuthRequest (含 nonceA)
    B-->>A: 2. AuthResponse<br/>(nonceB + nonceA + signatureB + certB)
    A->>B: 3. AuthConfirm<br/>(nonceA + nonceB + signatureA + certA)
    Note over A,B: 4. 密钥协商 (ECDH)
    A<-->>B: 5. 加密会话建立

详细说明：

步骤	说明
AuthRequest	发起方（A）生成一个随机数 nonceA，发给 B
AuthResponse	接收方（B）生成自己的 nonceB，用自己的私钥对 (nonceA || nonceB) 签名，连同自己的证书/公钥一并返回
AuthConfirm	A 收到后用 B 的公钥验签，通过后 A 对 (nonceB || nonceA) 签名返回，B 收到后用 A 的公钥验签
密钥协商	双方验签通过后，通过 ECDH（椭圆曲线 Diffie-Hellman）协商出一个共享会话密钥

5.1 认证中的关键数据结构

字段	说明
deviceId	设备唯一标识（不可逆哈希）
publicKey	Ed25519 / P-256 公钥
signature	使用私钥签名的随机数+上下文
certificate	可选，用于设备证书链校验
nonce	一次性随机数，防止重放攻击
sessKey	ECDH 协商出的对称会话密钥

5.2 密钥派生

最终会话密钥并非直接用 ECDH 的原始输出，而是通过 HKDF 派生：

sessionKey = HKDF-Expand(ECDH-shared-secret, "softbus_session", 32)

这样做的好处是：即使某一方的公私钥对泄露，之前的会话也无法被解密（前向安全性）。

六、会话建立阶段（Session）

双向认证通过后：

1. 双方用协商出的 sessionKey 建立一个对称加密通道（AES-GCM，128/256 位）
2. 该通道承载后续所有分布式通信——文件传输、投屏、跨设备调用、数据同步等
3. 每个会话都有一个 sessionId，用完后通过 CloseSession 销毁

加密通道的可靠性由 TCP/TLS 或 QUIC 提供传输层保证，SoftBus 在此基础上封装自己的加密层。

七、信任关系的生命周期

绑定（一次操作）
  │
  ▼
公钥写入信任数据库（持久化）
  │
  ▼
每次通信 → 轻量认证（挑战-响应 + ECDH）
  │
  ▼
会话建立 → 传输数据
  │
  ▼
会话关闭 → 密钥销毁
  │
  ▼
可被用户主动解绑（删除信任记录）

特性	说明
绑定持久化	绑定一次后，即使设备重启，信任关系依然存在
认证 session 级	每次建立新连接都需要重新走轻量认证
撤销方式	用户可在设置中解除信任，两端信任数据库中的对方公钥会被删除

八、关键代码模块位置

源码层级（OpenHarmony 仓库路径）：

模块	路径	说明
SoftBus 发现	foundation/communication/softbus_lite/	轻量版发现机制
组网	foundation/distributedhardware/device_manager/	设备管理（DM）服务
认证	foundation/distributedhardware/device_manager/services/	认证的核心逻辑
绑定	base/security/deviceauth/	设备认证模块（HiChain）
信任存储	base/security/huks/	密钥管理（HUKS）

HiChain 是实现设备认证的核心安全框架，OpenHarmony 在其基础上封装了引脚认证、证书验证等能力。

九、一张图总结

flowchart TB
    A[发现 Discovery<br/>COAP/UDP] --> B[绑定 Binding<br/>PIN/二维码/NFC]
    B --> C[认证 Authentication<br/>Challenge-Response + ECDH]
    C --> D[会话 Session<br/>AES-GCM加密通道]
    B -.-> E[(信任数据库<br/>公钥持久化)]
    C -.-> F[(HUKS<br/>密钥存储)]
    A -.设备列表缓存.-> G[启动连接]

十、延伸话题

如果你感兴趣，可以进一步聊这几个方向：

• HiChain 的认证链设计 —— 它不只是验证设备本身，还能通过证书链验证设备所属的组织或开发者
• 组网与认证的交互细节 —— 当 3 台及以上设备组网时，节点之间的认证矩阵如何维护
• 可信执行环境（TEE）保护 —— HUKS 如何利用 TEE 保护私钥不泄露给主系统

欢迎加入Laval社区

社区规范：仅讨论OpenHarmony相关问题。