®
01
密钥始终受到保护，由应用做出决策
HSM 会在其既定边界内保护签名密钥，但不会自行判断某个软件包是否应当发布。因此，我们会将签名调用与已识别的应用、权限和审批绑定在一起。在代码签名中，制品与审批会相互关联，以便识别事后的更改。CA 软件与 HSM 的 Provider 必须共同支持所使用的算法及密钥访问方式。信任库、状态检查和续期流程，都会结合具有代表性的对接系统进行测试。
您对 OTOKO® 的委托
我们为您承接的工作。
我们会明确谁有权申请、批准和签发证书，以及证书中确认的是何种身份。根 CA、签发 CA 和状态服务各自承担不同任务。有效期、续期窗口和吊销流程，会根据用户和设备的实际情况来选定。即使是自动续期，也需要监控：成功启动的流程，并不等于证书已经安装到所有目标系统上。
可能的服务范围
- 结合信任模型和角色模型，规划根 CA 与签发 CA
- 通过受支持的接口对接 CA 或签名应用
- 配置证书模板、续期和吊销信息
- 筹备密钥仪式和离线操作流程
- 将代码签名审批与交付链关联
具体范围、您的参与方式以及验收标准，我们会在项目开始前明确约定。
把技术讲清楚
我们是这样落实任务的。
02
演练吊销与恢复流程
管理员卡丢失、证书过期和签发 CA 被攻破，是三种不同的事件。我们会为每种情况制定相应的处理流程，并测试约定的恢复路径。验收测试会记录签发、续期、吊销以及有误申请等各类情形。现有的证书模板、设备类别和信任关系，有助于规划迁移期间的并行运行方案。
03
Microsoft AD CS、Java 应用还是自建签名服务
我们会核查各产品所支持的对接方式，例如通过 CNG Key Storage Provider、PKCS #11 或 Java Provider 实现。算法名称相同并不能保证兼容：机制、密钥属性、填充方式和 Provider 版本也必须相互匹配。对于现有的证书颁发机构，我们会明确是否可以进行合规的密钥迁移，还是需要建立带过渡阶段的新 CA。测试中会明确考虑已对接系统的信任关系。
04
在构建流水线中管控代码签名
流水线不应长期持有可自由调用的生产密钥。我们会将构建过程与签名审批分开，把签名任务绑定到已识别的系统，并规定哪些制品可以使用哪个密钥进行签名。时间戳、制品哈希值的证明以及日志记录，会依据签名格式做相应规划。HSM 在其中是一个保护组件：代码审查和是否发布的决定，仍然是开发和审批流程的职责。
05
示例：对现有企业 PKI 进行现代化改造
某机构已经在为设备、用户和内部服务使用证书。OTOKO® 会先梳理证书模板、分发方式和信任链，并在生产环境之外测试计划采用的 HSM 对接方案。随后，我们会规划切换方案，包括续期、吊销信息和回退标准。在移交之前，会对具体的对接系统进行测试：只有当登录、服务访问或签名验证在目标系统中真正生效时，签发的证书才算成功。
一个可验证的成果
这将成为您后续工作的基础。
- PKI 与签名架构
- 已实施的对接方案及测试证明
- 密钥仪式手册与运维手册
移交环节将实施成果与文档记录结合在一起。我们会共同检查约定的场景，并记录尚待完成的任务。
在迈出第一步之前
您关于 PKI 与证书 的问题。
是否必须更换现有的 PKI？
不一定。我们会核查 HSM 对接方式、现有密钥和信任链。相较于完全更换，分阶段扩展或并行层级结构可能是更合适的方案。
这样做是否会使每个签名都成为合格签名？
不会。仅凭 HSM 本身，无法构成合格电子签名。要实现这一点，还需要单独核查具体服务、流程以及相关的适用条件。
离线根 CA 是否也适合使用 HSM？
对长期使用的根密钥加以保护，是支持使用 HSM 的理由之一。但相应方案同样需要包括分离保管、明确的激活流程、已记录的仪式流程以及经过验证的恢复路径。设备本身并不能替代这些流程。
OTOKO® 能否对接 Microsoft AD CS？
我们会通过所用组合支持的 Provider 来核查并实施对接。关键因素包括 Windows 和 CA 版本、HSM 固件、客户端库以及所需的算法。现有密钥需要单独进行迁移评估。
HSM 能否防止对被篡改的软件进行签名？
它会在既定范围内保护密钥材料。制品是否可以发布，由签名流程决定。因此，我们会将 HSM 对接与身份、受限权限和可追溯的审批结合起来。
PKI 对接的验收包括哪些内容？
我们会约定针对签发、使用、续期和吊销以及违规申请的测试。此外还包括恢复流程以及 HSM 故障时的行为表现。测试范围和具有代表性的对接系统会提前确定。
