摘要

  • RFC 9180 的 Base 模式使持有接收方 KEM 私钥的一方能够打开密文。Open() 成功证明的是特定上下文中的密码学验证，不是远端主体的身份或权限。
  • PSK、Auth 与 AuthPSK 模式能提供对已配置秘密材料持有的有限保证；它们不会自动产生消息格式、身份目录、撤销状态、重放窗口、业务授权或安全执行结论。
  • 可靠审计应把密钥选择、模式与套件、info/AAD、外层封装、解析、时间性、政策决定和实际效果逐段记录，禁止让“解密成功”跨越这些边界。

一个控制系统收到加密负载。服务选中自己的私钥，处理 enc，构造 HPKE 上下文，并使 Open() 返回明文。随后运维看板显示“验证通过”。如果这句话仅指密码库在该上下文中接受了字节，它是准确的；如果它被读成“可信主体已获准下达指令”，它就已经越过了 RFC 9180 没有作出的几项判断。

混淆来自外观。密钥、封装、KEM、KDF、AEAD、认证标签和成功代码都很像一个完整安全协议。但 RFC 9180 定义的是 Hybrid Public Key Encryption：把密钥封装机制、密钥派生函数和带附加数据的认证加密组合起来。它给出可互操作的密码层，并没有规定谁拥有某个组织身份、消息应如何装箱、旧消息何时失效，或一段明文有没有资格改变网络与业务状态。

这不是欠缺，而是协议边界。共同层只应对能由共同层判定的事实负责。把身份、授权和后果偷偷加到解密成功之上，会让关键决定失去实际所有者。真正的风险不是密码算法没有运行；而是其他层没有运行，却被密码成功的光环掩盖。

Base 模式回答的不是“谁”

HPKE 套件由 KEM、KDF 和 AEAD 三部分组成。KEM 产生共享秘密并给出接收方可处理的封装；KDF 将秘密和上下文导向需要的密钥材料；AEAD 以密钥、随机数和附加数据保护明文。每一部分的作用都清楚，但三者合在一起仍不是身份基础设施。

在 Base 模式中，发送侧以接收方公钥 pkR 和应用给出的 info 建立上下文。它向 pkR 封装。接收侧以收到的 enc、对应私钥 skR 与相同上下文完成解封装并进入可打开密文的状态。RFC 9180 的模式属性明确把发送者认证留给其他模式：Base 具备消息和导出秘密的性质，却没有发送者认证性质。

因此，接收端得到的是“面向这把私钥的保密通道曾按给定输入建立”的证据。它没有得到“某个命名组织产生了这条消息”的证据。只要获得接收方公钥，未被认可的一方也能为该接收方构造 Base 密文。公钥可见恰恰是公钥加密的正常条件；可见性不等于发信资格。

这一区别在内部系统同样存在。一把接收公钥可以服务于多个环境、客户或自动化组件。某些组件被允许提交诊断信息，并不表示每个能够加密的组件都可提交生产变更。Base 不携带这张权限表。把“能够向此密钥加密”转换为“能够要求此系统行动”的规则，必须由密钥发行、消息分类和应用政策共同给出。

AAD 也不能代替该规则。应用可将租户、路径、版本或请求编号作为附加认证数据，使任何更改导致验证失败。但 HPKE 不判断这些字节是否真实，也不判断提交者是否有权使用其中的租户名称。一段被完整保护的错误声明仍然是错误声明；完整性保护与陈述权限并非同一属性。

认证模式增加材料证明，不增加自动治理

RFC 9180 提供三种超出 Base 的模式。PSK 模式让接收方确认发送者持有配置的预共享密钥。Auth 模式让接收方获得与发送方 KEM 私钥持有相关的保证。AuthPSK 则结合二者。对于已经妥善配置、保管和轮换密钥的系统，这些是重要能力。

它们的语言仍必须保持精确：协议证明的是秘密材料的持有。企业会把密钥或 PSK 关联到人、服务帐户、硬件模块、共享角色或整个部署环境。该关联依赖签发、交接、范围、轮换、停用和撤销记录；它不会从一次 AuthDecap() 调用中自然出现。

RFC 9180 进一步指出，Auth/AuthPSK 认证的是发送方密钥对本身，而不是任意身份。如果应用希望把电子邮件、域名、业务主体或其他标识绑定到密文或导出秘密，必须把该标识加入 info。这个要求提醒设计者：标识绑定是一项明确的应用设计，而不是可以由日志标签默默完成的推断。

此外，DHKEM 的 Auth 与 AuthPSK 在 RFC 所述的接收方密钥受损条件下存在密钥妥协冒充限制。因而，Auth 成功不应写成永久的人类意图证明或普遍的不可否认性。它是特定密钥、时间和威胁模型下的有限密码保证。

最常见的治理错误发生在翻译日志时。auth_mode=success 可以是正确技术字段；“合作方批准了变更”还需要证明：该合作方控制此密钥、该密钥在当时仍有此类消息的授权，以及本地政策接受了相应内容。若把后一结论藏进前一字段，审计便无法找到真正的授权者。

协议没有替应用画出信封

info 在建立上下文时绑定共享的应用信息，AAD 在每次 Seal()/Open() 时绑定逐消息信息，导出接口还有自己的上下文。这一划分帮助应用放置数据，却不规定这些数据怎样出现在网络上传输的对象中。

RFC 9180 不定义 HPKE 消息的线格式。采用者必须制定无歧义编码，其中至少包括 enc、一个或多个密文及其顺序、任何非隐含的 info；若接收方维护多把公钥，所选接收方密钥也可能需要在外层表达。格式不是包装纸。它决定接收器如何切分字段、识别版本、找到模式与套件，并重建正确上下文。

即使外层格式正确，语义仍须另行判断。一份明文可能是遥测、删除申请、发布许可或测试样本。HPKE 不提供业务 schema、角色模型、审批流程或执行边界。接收端应先验证结构与类型，再检查密钥—身份绑定、撤销状态、时限、重放和政策，最后才让一个受限执行器处理被允许的动作。密文被打开不是命令被批准。

这一点也改变日志设计。至少保存接收方密钥标识、模式、KEM/KDF/AEAD 套件、发送方密钥或 PSK 标识（适用时）、可安全引用的 info 与 AAD 摘要、外层消息标识、解析结果、政策判断和后续效果。调查者应能从一次实际操作向后追问：哪一条证据允许它越过前一条边界？

时间、重放和密钥记忆

加密本身不产生新鲜度。RFC 9180 只在同一上下文内、密文按发送端 Seal() 的顺序交给接收端 Open() 时提供有限的重放保护；除此之外不提供重放保护。多消息应用必须自行执行顺序并检测丢失，通常需要版本化信封、序列或不可变消息标识，并把相关顺序信息放入 AAD。

有效期、幂等窗口、nonce、业务状态条件和重复请求的处理方式都因此属于应用控制。昨天已获接受的重置请求，今天可能仍可被完美解密，却已不具任何行动权限。保留字节的密码学有效性并不续签其中的业务授权。

套件选择也不是自动政策。RFC 假定发送方与接收方就算法达成一致，但具体协商方法可能使中间人迫使双方使用较差选择。套件标识可让系统事后知道用了什么，不能证明选择过程受保护或符合组织基线。

接收方密钥还带来历史风险。RFC 9180 说明，所有模式下，密文都不对接收方密钥妥协提供前向保密：一旦长期开关秘密在后来泄露，过去发往该密钥的密文可能被解开。这不是对某个部署的指控，而是对档案保留、密钥轮换、妥协响应与历史数据访问的设计约束。

从字节到后果的证据链

第一段应记录密钥选择：接收方公钥由谁签发、用于何类消息、通过何渠道分发、何时轮换或撤销。目录中出现一把公钥，只表明一个加密目标存在，不表明所有发送者都被许可使用所有业务类型。

第二段记录发送准备：模式、套件、PSK 或发送方密钥来源、info、AAD、外层封装和协商证据。有效的密钥仍可能被用于错误租户、错误角色或过期范围。

第三段记录接收与密码操作：enc 和密文的安全摘要或持久标识、接收方密钥、上下文结果和 Open() 结果。成功应保持为成功，不得覆盖解析器和政策引擎的独立结论。

第四段记录解释与授权：schema 版本、消息类别、已识别身份、撤销状态、新鲜度检查、重放决定、政策结果与拒绝理由。一个密码学上正确的消息可以也应当因租户不符、序列陈旧、密钥已撤销或动作越权而被拒绝。

最后一段记录效果：请求了什么、批准了什么、实际执行了什么、哪个独立系统观察到结果，以及如何回滚。批准不等于执行，执行也不等于效果已核实。只有这些记录才能让一次变更不被“解密成功”四个字取代。