HarmonyOS 分布式身份认证详解：设备是如何“互相信任”的？

摘要

这几年随着 HarmonyOS 的不断演进，分布式能力已经不再是一个"概念功能"，而是真正开始落地到手机、平板、手表、智慧屏以及各种 IoT 设备中。

设备之间可以互相调用能力、共享数据、协同完成任务，但问题也随之而来：

设备到底是不是"自己人"？

调用请求能不能信？

万一被伪装设备或者中间人攻击怎么办？

这些问题的答案，最终都指向了一个核心能力 ------ 分布式身份认证。

这篇文章会从系统原理、开发者视角和真实使用场景三个层面，聊清楚鸿蒙的分布式身份认证到底是怎么工作的，以及我们在开发中应该如何正确"使用它"。

引言

在传统系统里，身份认证更多关注的是"人"，比如账号密码、Token、OAuth 这些东西。但在多设备协同的时代，只认证人已经远远不够了。

举个很现实的例子：

手机调用平板的摄像头
手表控制手机播放音乐
车机读取手机里的行程信息

这些操作本质上是：
一个设备，代表某个用户，在访问另一个设备的能力。

所以在 HarmonyOS 里，身份认证不再只是"账号登录"，而是升级成了一套：

以设备为主体、以用户为中心、以系统可信机制为基础的分布式身份认证体系。

鸿蒙分布式身份认证到底解决了什么问题？

一句话先给结论：

它解决的是"跨设备调用时，设备是谁、是不是可信的、有没有资格执行这个操作"。

展开来看，主要是三点：

设备身份是否真实
设备和用户是否绑定
设备之间是否建立了可信关系

这些都不是应用层自己能搞定的事情，所以鸿蒙把它直接做到了系统层。

分布式身份认证的核心组成

设备身份：每台设备都有"身份证"

在鸿蒙系统里，每一台设备在出厂或首次初始化时，都会生成一套只属于自己的身份信息，包括：

设备硬件指纹
设备证书
设备密钥对（私钥不出安全硬件）

这些信息通常保存在 TEE（可信执行环境）或安全芯片里，应用层是拿不到原始数据的。

你可以把它理解为：
设备的身份不是靠软件生成的，而是靠硬件兜底的。

这一步的意义是，防止设备被伪造。

用户身份：设备不是"野生"的

设备身份只能说明"你是谁"，但不能说明"你为谁服务"。

这就轮到用户身份出场了。

在鸿蒙生态中，用户身份主要依托华为账号：

用户登录账号
设备和账号建立绑定关系
同一账号下的设备可以组成可信设备组

也就是说，一台设备只有在"被某个用户认领"之后，才有资格参与分布式能力。

可信关系：不是所有设备都能互相调用

当用户把多台设备加入同一个账号或者家庭空间时，系统会在后台完成这些事情：

双向设备认证
验证设备证书
建立安全通信通道
生成分布式信任关系

只有完成这些步骤的设备，才会被加入"可信设备列表"。

这一步做完之后，系统层就已经知道：

哪些设备是自己人，哪些不是。

分布式身份认证的整体工作流程

以一个最常见的场景为例：手机调用平板的分布式能力。

text 复制代码

1. 手机发起分布式调用
2. 系统自动附带：
   - 当前设备身份信息
   - 应用身份信息
   - 用户绑定关系
3. 平板侧系统进行校验：
   - 是否同一账号
   - 是否可信设备
4. 校验通过后建立安全会话
5. 分布式调用正式执行

整个过程对开发者来说是"无感"的，但在系统层已经做了非常多的安全判断。

系统层是如何实现身份认证的？

设备认证服务（DeviceAuth）

鸿蒙内部提供了分布式设备认证服务，用来完成：

基于证书的双向认证
防止设备伪装
防止重放攻击

认证不是一次性的，而是可以根据场景动态触发。

会话密钥协商

设备认证通过之后，并不会直接明文通信，而是会：

使用 ECDH 协商会话密钥
每次分布式会话单独生成
会话结束后立即失效

即使通信被截获，也无法还原真实数据。

身份认证不会绕过权限系统

这一点非常重要。

身份认证通过，只代表"你是谁"，并不代表"你能干什么"。

后面还要经过：

分布式权限校验
应用签名一致性校验
能力级权限判断

也就是说，认证和授权是两步走的。

开发者视角：我们需要做什么？

答案其实很简单：

绝大多数情况下，你不需要手写任何身份认证代码。

你要做的，主要是三件事：

声明支持分布式能力
使用系统提供的分布式 API
正确处理"设备是否可用"的状态

可运行 Demo：分布式对象同步示例

模块声明（module.json5）

json 复制代码

{
  "module": {
    "deviceTypes": ["phone", "tablet"],
    "distributed": true
  }
}

这一步是告诉系统：

这个应用是支持分布式能力的。

创建分布式对象

ts 复制代码

import distributedObject from '@ohos.distributedObject';

const options = {
  name: 'demoObject'
};

let distObj = distributedObject.createDistributedObject(options);

distObj.set('message', 'Hello HarmonyOS');

当你调用 createDistributedObject 的时候，系统会自动完成：

设备身份校验
可信关系检查
安全通道建立

监听数据变化

ts 复制代码

distObj.on('change', (key, value) => {
  console.info(`key=${key}, value=${value}`);
});

只要另一台可信设备修改了同一个对象，这里就能收到同步通知。

结合实际的应用场景分析

场景一：手机和手表的健康数据同步

手机作为主设备，手表作为采集设备。

手表采集心率数据
通过分布式对象同步给手机
手机侧只接收来自可信设备的数据

ts 复制代码

healthObj.set('heartRate', 78);

系统已经确保：

数据一定来自用户自己的手表，而不是伪造设备。

场景二：平板作为副屏控制手机

比如平板控制手机播放音乐：

ts 复制代码

controlObj.set('play', true);

在执行播放前，系统会确认：

两台设备是否同账号
是否建立可信关系
应用是否一致

否则调用会直接被系统拦截。

场景三：家庭设备协同

家庭场景下，不同设备属于同一家庭空间：

ts 复制代码

homeObj.set('light', 'on');

只有被加入家庭并通过认证的设备，才能响应这个操作。

QA 环节（常见问题）

Q：开发者能不能直接拿到设备证书？

A：不能，这些都在系统和安全硬件中，应用层不可见。

Q：分布式身份认证会不会影响性能？

A：认证主要发生在会话建立阶段，之后走的是高效安全通道，影响非常小。

Q：断网还能用吗？

A：已建立的可信关系可以在本地使用，但首次认证通常需要网络支持。

总结

简单来说，鸿蒙的分布式身份认证做了三件非常重要的事情：

用硬件级身份保证设备真实
用账号绑定保证设备归属
用系统级机制保证跨设备调用安全

对开发者而言，我们不需要重复造轮子，只要按照系统设计使用分布式能力，身份认证和安全问题就已经被系统兜底解决了。