技术分享｜代码签名的安全注意事项

代码签名（或者软件签名）为可信计算环境提供技术支持，能有效保障软件在开发、构建、分发、维护过程中可信任、不被篡改。基于代码签名实现白名单机制，能有效减少白名单的生成和维护成本。同时签名系统自身的安全性也至关重要，假如自身不安全，会导致整个信任链不安全，带来严重的安全问题。根据我国等保4级的技术要求，在安全计算环境相关章节，提到“应构建从操作系统到上层应使用程序的信任链，以实现系统运行过程中可执行程序的完整性检验，防范恶意代码等攻击，并在检测到其完整性受到破坏时采取措施恢复，例如采使用可信计算等技术”，代码签名技术就是一种实现该信任链的技术方案。

NIST（美国国家标准和技术研究院）在2018年1月26日发布了《Security Considerations for Code Signing》的技术白皮书，详情了代码签名的技术基础、基本架构和安全风险，为代码签名系统提供安全指导，原文可以在NIST的官方网站查找下载：https://csrc.nist.gov/publications。

本文对该技术白皮书进行了翻译，详情给国内的安全工作者。

———————————————

1前言

最近的安全相关事件表明，在软件的开发、构建、分发和维护阶段，需要一个安全的软件供应链来保护软件产品（或者者称为代码）。特别值得关注的是安装和升级软件，对于平台的安全性起着关键作使用，必需以安全和自动的方式分发和升级各种软件产品，包括固件，操作系统、移动应使用程序和应使用程序容器映像，以防止伪造和篡改。保护软件的一种有效且常见的方法是对软件应使用数字签名。数字签名既提供数据完整性验证，以证实代码未被修改，还提供源代码验证，以标识签名时谁控制了代码。当用者验证签名时，他即可以确信软件来源正确，并且传输过程中未被篡改。

本白皮书针对正在实施代码签名系统或者审查现有系统安全性的软件开发人员和产品供应商，旨在提高系统安全性，提高用户对代码真实性和完整性的信心。系统集成商和管理员可能会担心在其系统上安装并运行的应使用程序的可信赖性，他们可以从代码签名处理方案中取得想要的信息，以保护他们的软件供应链。

本白皮书详情了当今广泛部署的典型代码签名处理方案的功能和架构，形容了几种典型的代码签名使用例，并确定了在将代码签名处理方案应使用于这些使用例时可能出现的少量安全问题。最后，本文提供了规避这些安全问题的方案建议，并提供了更多信息资源作为参考。正确应使用这些建议将有助于确保软件供应链的安全。

NIST计划开发进一步的指导以帮助组织评估、部署或者管理代码签名系统。本文档中形容的少量粗粒度的建议下一步将会进行细化，成为代码签名的实践指导。

2基础知识

本节简单形容一下代码签名过程是如何工作的，整个工作过程中有三个基本角色：开发者、签名者和验证者。

开发者负责编写、构建和提交将要签名的代码。开发者维护一个安全的开发环境，包括源代码库，在完成开发和测试流程后将代码提交给签名者。

签名者负责管理使用于签订软件的密钥。这个角色可以和开发人员属于同一个组织，也可以是独立公正的第三方。该过程的安全性依赖于私钥的保护，所以签名者必需在保证安全的设施上生成代码签名的私钥/公钥对。在许多情况下，签名者通过证书签名请求将公钥提供给证书颁发机构（CA）。CA将确认签名者的身份，并提供与签名者绑定的签名证书。任何人都可以用与此证书关联的公钥来验证用此密钥对签订的代码的真实性和完整性。假如没有用CA，则必需用可信的带外机制来分发公钥。

签名人通过技术和程序控制确保只有受权代码被签订。当开发人员提交代码进行签名时，签名人将验证他们的身份和权限以请求签名。签名者也可能采取额外的步骤来验证代码能否可信。最终，可能需要代码签名系统的两个或者多个可信代理商来批准请求，并生成数字签名。在某些情况下，还可以将签名代码提供给时间戳受权机构，以标记代码签名的时间。

验证者负责验证代码签名。验证者可能是与签名代码相同的开发者提供的软件组件（例如：使用于签名固件升级），或者者也可能是由平台提供的共享组件（例如：操作系统）。

3 结构组成

代码签名体系结构由多种逻辑组件组成。图1所示的代码签名/验证体系结构具备四个不同的组件：代码签名系统（CSS）、证书颁发机构（CA）、时间戳受权机构（TSA）和验证程序。