®
01
区分产品支持能力与证明材料
我们会审查硬件、固件、许可和运行模式方面的厂商文档。某个算法可用，并不自动意味着可以在所需的验证或认证范围内使用它。备份、复制和密钥迁移也必须支持新的密钥类型。针对新的信任锚，我们会规划角色、访问凭证和密钥仪式。有状态的签名算法还需要格外细致的状态管理，不会仅因为产品提供了这一选项就未经审查直接引入。
您对 OTOKO® 的委托
我们为您承接的工作。
HSM 可能已经支持某种算法，但 CA、服务商或后续的验证方可能尚未支持。我们会梳理整条信任链，包括证书配置文件、信任库、状态服务和签名格式。设备和文档较长的生命周期会影响过渡进程。并行层级结构可能是合理的选择，但需要明确的对应关系：哪个应用信任哪条链，新旧构件之间又该如何区分？
可能的服务范围
- 梳理证书层级结构、密钥和执行验证的应用
- 评估具体 PKI 和 HSM 配置对新算法的支持情况
- 规划并行或受支持的混合过渡模式
- 筹备密钥仪式和信任分发
- 测试证书验证、吊销和签名流程
具体范围、您的参与方式以及验收标准，我们会在项目开始前明确约定。
把技术讲清楚
我们是这样落实任务的。
02
以受控方式分发信任
验收环节涵盖代表性证书的签发与验证，以及错误场景、吊销信息和旧客户端的行为表现。信任分发的先后顺序会在切换之前确定。长期签名验证和归档要求会与相关责任方协调一致。最终成果是一套经过记录和测试、并明确标示适用边界的配置方案。
一个可验证的成果
这将成为您后续工作的基础。
- PKI 与 HSM 迁移架构
- 兼容性矩阵
- 包含密钥仪式和测试文档的试点
移交环节将实施成果与文档记录结合在一起。我们会共同检查约定的场景，并记录尚待完成的任务。
您的项目详情
将 PKI 与 HSM 作为一条完整的信任链一并迁移。
我们会依据产品和应用的实际支持情况来规划 PQC 项目。如果 CA、证书格式、程序库或负责校验的应用无法处理某种新算法，那么仅在 HSM 中支持这种算法是不够的。
按版本和用途逐项验证支持情况
我们会针对 HSM、固件、客户端、PKI 以及各个使用方系统建立兼容性矩阵。支持密钥生成，并不能说明所有所需的签名、导入或备份流程都已得到支持。因此，每一项结论都会明确对应到具体的版本和操作。
批准和认证事项会被单独考虑。具备某项 PQC 技术功能，并不会自动获得在特定受监管场景中使用的批准。所需的证明材料和厂商承诺，会作为前提条件被列入项目计划。
以受控方式部署新的信任链
在切换之前，我们会审查证书配置文件、大小、传输和存储方式，以及信任锚的分发方式。使用受限程序库或对证书有固定假设的应用，可能需要额外的调整。因此，试点至少要包含一次完整的证书签发，以及一次由真实使用方完成的成功校验。
对于过渡阶段，我们会规划现有证书的剩余有效期、吊销机制以及可能并存的多种状态。密钥材料无法笼统地转换为新算法，通常需要生成新的密钥并签发新的证书。回退方案也必须考虑到已经签发的对象及其相关依赖关系。
示例项目场景
该服务在日常工作中如何发挥作用。
示例：某个内部 PKI 需要为未来的切换做好准备。我们会选定一个范围明确的测试服务，使用计划采用的版本对 CA 和 HSM 进行检验，并在客户端测试证书校验功能。不受支持的系统会作为具体的迁移依赖项被清楚地标记出来。
该示例说明的是一种可能的流程，并非客户案例。
在迈出第一步之前
您关于 面向 PKI 与 HSM 的 PQC 的问题。
是否每台 HSM 都必须更换？
这需要根据具体型号、固件、运行模式和所需算法才能判断。扩容、并行运行和更换等方案会相互比较评估。
并行证书链和混合签名是一回事吗？
不是。并行证书链和密码学组合算法是两种不同的过渡方案，具体哪种可行取决于所涉及的产品和验证方。
