本文基于 HarmonyOS 7（API 26）官方"新能力一览"及公开官方材料整理。文中代码为说明接入结构自写的示意代码，精确接口名与参数以官方《数字盾》开发指导为准；数字盾的接入门槛、适用场景等事实性信息均标注官方出处；涉及真机表现的部分以真机实测为准，未做任何实测数据编造。
引子：转账确认页，应用自己画的那张还能信吗？
先想一个场景：用户在你的金融应用里点"转账 5000 元"，弹出一个确认页，用户点"确认"。这个确认页是谁画的？是你的应用自己画的。界面可以被仿冒、弹窗可以被覆盖、输入框可以被监听------应用层的安全确认，防的是误触，防不了恶意。
银行转账、企业签章这类"签了就要担责"的操作，需要的是把"确认"这个动作本身从应用层提进硬件可信区。HarmonyOS 7（API 26）的数字盾干的就是这件事 ：提供可信数字签名、可信 UI 确认和可信输入服务，让关键操作的安全性达到 TEE 级标准（官方新能力一览）。
这期V哥把它拆开讲：三件套各自管什么、接入的真实门槛在哪、和已写过的星盾风控（第 20 篇）、数字身份 DID（第 21 篇）怎么分工。
一、定位：把"关键操作确认"从应用层提进 TEE
数字盾在 HarmonyOS 7 安全体系里的位置很清楚。官方对三大件能力的表述是：提供可信数字签名、可信 UI 确认和可信输入服务，保护银行转账、企业签章等关键操作安全性达到 TEE 级。
V哥翻译成大白话：普通应用做安全，防线在"我的代码写得好不好"；数字盾做安全，防线在"确认动作在系统可信执行环境里完成，应用碰不到过程"。两者的差距，就是"门锁"和"金库"的差距。
三个服务各管一段：
| 服务 | 管什么 | 防什么 |
|---|---|---|
| 可信数字签名 | 签名操作在可信环境内完成，产出带硬件背书的签名结果 | 签名过程被仿冒、结果被篡改 |
| 可信 UI 确认 | 关键操作的确认界面由系统安全层渲染 | 确认页被伪造、被劫持、被覆盖 |
| 可信输入 | 密码、PIN 等敏感输入走安全输入通道 | 输入内容被键盘监听、被截屏录屏获取 |
注意三件套是组合拳：一次高危机操作，往往是"可信输入拿密码 → 可信 UI 确认让用户点头 → 可信数字签名出结果"一条链走完，单独用一件都只防一段。
二、三件套拆解：各防各的命门
可信数字签名：签出来的东西"赖不掉"
应用层签名（哪怕是国密算法）的问题在于：私钥和签名运算都在应用进程里，进程被入侵，签名就可疑。数字盾的可信签名把签名动作下沉到可信环境，签名结果与设备可信状态绑定------银行转账指令、企业电子签章，签出来就带"硬件公证"属性。
可信 UI 确认：用户点的那下"作不了假"
钓鱼的常见手法不是破你的加密，是画一个一模一样的确认页。可信 UI 确认把确认界面交给系统安全层渲染，应用拿不到这个界面的控制权------用户看到的是系统画的确认页，点的确认直接进可信通道，中间没有应用可以插手的空间。
可信输入：密码在键盘上就不落地
键盘记录、截屏录屏是输入侧两大威胁。可信输入让密码、PIN 码的输入框和键盘都在安全通道里，截屏拿不到内容、录屏录不到键盘事件。对支付类应用，这一条直接决定合规能不能过。
三、接入的真实门槛：这不是个人开发者随手能调的能力
V哥必须把这段放在最前面讲，因为这是多数人扑空的地方。数字盾不是导个包就能用的公共 API：
① 企业主体。 需要企业开发者在 AGC（AppGallery Connect）完成实名认证，并申请数字盾权限------这是定向开放的能力，不是随装随用。
② 服务端配合。 可信签名产出的结果需要服务端验签，业务后端要配合搭建验证链路；签名上下文、防重放挑战这些设计，也依赖服务端参与。纯端侧闭环做不了完整的安全闭环。
③ 场景限定。 官方给的价值场景是银行转账、支付交易、企业签章这类高危操作。普通应用的"确认删除"用不上也不该用------把所有确认都提进 TEE，用户会被确认页淹死。
V哥的判断：数字盾是"金融级应用的及格线"，不是"所有应用的加分项"。做的是支付、签章、政务、司法存证这类业务，它值得接；一般工具类应用，把精力放在数据加密和权限最小化上更实在。
四、接入结构：一条链怎么串
精确接口名以官方开发指导为准，V哥把接入结构画成一段示意代码，重点是链路分层而不是 API 细节：
typescript
// 结构示意：三件套在一条高危操作链路里的位置
// 注意：精确接口名、参数与权限声明以官方《数字盾》开发指导为准
// ① 业务前置：服务端下单，拿到本次操作的上下文（订单号、金额、有效期、挑战值）
// ② 可信输入：支付密码走安全输入通道采集（防键盘监听/截屏）
// ------ 应用拿到的只有"输入完成"事件与密文，拿不到明文
// ③ 可信 UI 确认：系统安全层渲染确认页（金额、收款方由服务端数据注入）
// ------ 用户在系统画的确认页上点头，确认事件直接进可信通道
// ④ 可信数字签名：对操作上下文签名，产出带可信背书的签名结果
// ⑤ 服务端验签：后端验证签名与上下文绑定关系，通过后才执行转账
async function transferMoney(order: TransferOrder): Promise<void> {
// V哥注：以下三步的接口名以官方文档为准，这里只表达调用次序与职责边界
const input = await trustedInputFlow(order); // 可信输入：采集支付凭据
const confirmed = await trustedConfirmFlow(order); // 可信 UI 确认：用户点头
if (!confirmed) return;
const signature = await trustedSignFlow(order); // 可信签名：对上下文签名
await serverVerifyAndExecute(order, signature); // 服务端验签后执行
}两个工程要点：签名要绑定完整上下文 ------不只签金额，还要绑请求 ID、会话、时效、随机挑战，防止签名结果被挪用到另一笔交易；验证顺序先上下文后签名------先确认请求存在且未消费、会话与期限匹配，最后才验签名本身，签名通过不代表请求一定可执行。
五、安全三件套的分工：星盾管风控，DID 管身份，数字盾管操作
HarmonyOS 7 的安全能力是一套组合，V哥把三篇的边界画一张图（见配图）：
- 星盾机密风控（第 20 篇） ：管"这个设备/这次交易可不可信"------风险因子在端侧机密空间融合计算，数据可用不可见，是事前风控；
- 分布式数字身份 DID（第 21 篇） ：管"我是我"------TEE 里颁发数字身份，按需出示、最小化暴露，是身份层；
- 数字盾（本篇） ：管"这次操作算数"------签名、确认、输入三件套落到具体操作上，是操作层。
一次完整的支付：星盾先判设备风险，DID 证明用户身份，数字盾完成操作确认。三层各司其职，缺哪层都漏风。
参考与出处
本文涉及的能力定位、接入门槛与适用场景来自以下官方材料，均为V哥动笔前逐条核验的原文出处：
- HarmonyOS 新能力一览（7 / API 26）------安全能力
- 华为开发者联盟 HarmonyOS 开发者官网
- 数字盾精确接口与权限申请流程以官方《数字盾》开发指导为准（AGC 内可查）
最后一句：安全这件事，从来不是"界面做得像"就够了------数字盾把签名、确认、输入三步全部搬进可信执行环境，应用负责发起，系统负责公证，转账按钮才真正配得上"硬件级"三个字。