为 slkd 配对策略暴露机制型 Security Interface

[sanchuanhehe]

What to build

把配对 mechanism 与 policy 拆开。

内核继续负责时序敏感的配对状态机、DLI 往返、密码学、活动 session key 和链路加密安装；slkd 决定 IO capability、认证方法、MITM、auto-pair、trust、accept 或 reject，并持久化 BondCredential。

内核应提供 pairing prompt/action Interface，以及特权 credential import/remove Interface。wrapped host material 是基础能力；opaque controller token 只能作为 Controller Backend 显式声明的可选、版本化 capability，不能假定现有 OpenHarmony vendor ABI 或所有芯片已经支持。

Acceptance criteria

• pairing prompt 携带 controller id、connection、request id、peer capability、可选方法、security requirement 与 deadline。
• slkd 可以按 request id 选择方法、accept、reject、提供 passkey、OOB 或 PSK，并得到明确完成结果。
• 内核不再硬编码 Keyboard+Display、auth request、key distribution 或自动接受需要用户决策的配对。
• 未连接 policy owner、owner timeout、slkd 退出或响应非法时 fail closed，并清理 pairing state。
• 特权 BondCredential import/remove 至少支持 wrapped host material，并按 controller 和 peer 归属。
• opaque token 通过独立、可选、版本化 Credential Interface 暴露；不得扩散为通用 op(int, void*)。
• Backend 未声明 opaque credential capability 时，slkd 明确选择 wrapped host material 或报告不支持。
• token 的 controller 归属、生命周期、reset 后有效性、撤销与错误语义由 Adapter capability 定义。
• 内核只保留活动连接需要的 credential，删除、断开与失败路径会清理敏感 buffer。
• Controller Backend 的 hardware op 不得包含 trust、auto-pair 或用户授权 policy。
• Interface 受 capability 与唯一 owner 约束，普通用户和 raw DLI 不能绕过 policy。
• 测试覆盖各配对方法、accept/reject/timeout、daemon crash、restart recovery、revoke、无 token capability 和不支持 key export 的 Adapter。

Reference evidence

当前公开 OpenHarmony SleVendorInterfaceT 只有 lifecycle/op/channel 能力，没有 credential import、export 或 token opcode。因此 opaque token 是需要单独设计的未来 capability，而不是已验证的厂商 ABI。

Blocked by

• 明确 DLI Host、Controller Backend 与内部 Channel Seam #1
• 收窄控制面并限制 raw DLI 命令 #5