维基百科

代码签名

代码签名（英语：Code signing）是对可执行文件或代码进行数字签名以确认软件作者及保证软件在签名后未被修改或损坏的措施。此措施使用加密散列来验证真实性和完整性。[1]

代码签名可以提供几大功能价值。最常用的需求是代码签名为部署提供了安全性。在某些编程语言中，它也可用来帮助防止命名空间冲突。几乎每个代码签名的实现都提供某种数字签名机制来验证作者或构建系统的身份，以及校验对象是否未被修改。它也可用来提供对象相关的版本信息，以及存储对象的其他元数据。[2]

代码签名作为软件安全性依赖的效果取决于所支持签名密钥的安全性。与其他公钥基础设施（PKI）技术一样，系统的完整性依赖于发布者对其私钥免受未经授权访问的保护。存储在通用计算机的软件中的密钥易于受到影响。因此，将密钥存储在安全、防篡改的硬件密码设备（也称硬件安全模块，HSM）是更加安全的最佳实践。[3]

安全保证

许多代码签名的实现提供方法来使用涉及一组密钥的系统来签名代码，这类似SSL与SSH的流程。例如，在.NET中，开发人员每次构建之时，都将使用一个私钥来签名自己的库或可执行文件。此密钥唯一且分属给单个开发人员、小组，或者特定应用程序或实体。开发人员可以自己生成此密钥，也可以从受信任的数字证书认证机构（CA）获取一份密钥。[4]

代码签名在分发目的下很有价值，因为所提供代码的源代码可能并不明显，如Java applet、ActiveX控件或其他类似代码。它的另一个重要用途是，为现有软件安全地提供更新和补丁。[5]Windows、Mac OS X和大多数Linux发行版为更新使用代码签名，从而确保其他人不可能通过补丁系统分发恶意代码。它可以使操作系统验证更新是否合法，即使更新是由第三方或借助物理介质（如光盘、U盘）分发。

在Windows和Mac OS X上，首次运行（英语：First run (computing)）软件时将检查代码签名以验证软件的身份，确保软件没有被第三方分销商或下载网站恶意篡改。因为平台的分散性，这种代码签名形式没有在Linux上使用，软件包管理系统是所有软件形式（不仅仅更新和补丁）的主要发行模式，并且允许直接检查源代码的开放源代码模型（如果需要）。

使用证书颁发机构（CA）完成受信识别

用于代码签名的公钥应该可以追溯到受信任的根机构CA，使用安全的公钥基础设施（PKI）是最佳做法。这虽不能保证代码本身的可信，但可以确保它来自所声明的来源（更明确来说，来自特定私钥）。[6]一个CA提供者可以提供根级别的信任，并能以代理方式将信任分配给其他人。如果用户信任一个CA，那么用户也相信该CA及其代理生成的密钥所签名的代码合法性。许多操作系统和框架都内置对一个或多个现有CA的信任（例如VeriSign/Symantec、DigiCert、TC TrustCenter、Comodo、GoDaddy及GlobalSign等）。对大型组织来说，实现与公共CA功能相同但仅在组织内信任的私有CA也是常见的选择。

CA的替代品

类似目的的另一种方式是——开发人员可以使用自己生成的密钥。在此种情况下，用户首次通常必须直接从开发人员那里获取公钥，以便验证对象的来源。许多代码签名系统将存储签名中的公钥。部分软件框架和操作系统将在执行前检查代码的签名，并允许用户选择是否信任该开发者。应用程序开发者可以在安装程序中包含公钥以提供类似的系统。然后可以使用密钥来确保需要运行的任何后续对象（例如升级、插件或其他应用程序）都是来自同一开发人员。

时间戳

时间戳旨在解决证书过期后开始出现的信任警告。在实际应用中，时间戳将使代码的信任期延长到证书有效期之后。[7]

如果由于鉴权泄露或失效而必须撤销证书，则撤销事件的具体时间将纳入撤销记录。在这种情况下，时间戳有助于确认代码是在证书信任受损之前还是之后签署。

问题

同任何安全措施一样，代码签名也可以被击破。用户可能被诱骗而运行无签名乃至拒绝被验证的代码[需要解释]，并且系统只能尽可能保持私钥的安全性。[8][9]

同样重要的是，代码签名不会保护最终用户免受软件作者的恶意行为或无意破坏，而只是确认软件未被作者以外的人修改。

实现

IBM的Lotus Notes自第一版开始有一个PKI的代码签名，并且客户端和服务器软件都有“执行控制列表”来控制指定用户对数据、环境和文件系统的访问级别。个别设计元素（栓脚本、动作、代理等活动项目）始终使用编者的ID文件来签名，其中包括编者和域的公钥。核心模板（如邮件模板）由Lotus模板开发团队持有的专用ID签名。

微软公司为微软测试的驱动程序提供了一种代码签名（基于Authenticode）。因为驱动程序是在内核中运行，它们可能破坏系统的稳定性或者使系统出现安全漏洞。就此原因，微软将测试提交到其WHQL计划的驱动程序。在驱动程序通过测试后，微软会将此版本的驱动程序标记为安全。在32位系统上，安装未通过微软验证的驱动程序可以在用户被警告该代码未被签名时选择允许安装。对于.NET（托管）代码来说，它有一种称为强名称签名（英语：Strong Name Signing）的额外机制，它采用公钥/私钥和SHA-1散列而不是证书。不过，微软不鼓励用强名称签名来代替Authenticode。[10]

游戏和消费设备中的未签名代码

在诸如游戏主机等消费者设备语境中，未签名代码通常指一个未被通常必须有加密密钥的应用程序接受和执行的软件。大多数主机游戏必须使用主机制造商设计的私钥签名，否则游戏不会在主机上加载。使未签名代码被执行通常有几种方法，包括软件漏洞、使用modchip、运用交换技巧（英语：Swap Magic）技术，或者运行一个softmod（英语：softmod）。

对于有签名的应用程序复制到另一张DVD上就不能启动的原因，通常不那么显而易见。在Xbox上，原因是Xbox可执行文件（XBE）包含一个媒体类型标志，它指定了XBE可引导形式的媒体类型。对几乎所有Xbox软件来说，此设置使得可执行文件只能从工厂生产的光盘启动，将可执行文件复制到可烧录媒体上将终止软件的可执行性。

但是，因为可执行文件本已签名，因此仅更改标记值不可行，那将使可执行文件的签名失效，从而在最初的验证阶段就检查失败。

互联设备的增长

伴随着物联网（IoT）增长的互联设备正成为代码签名的新需求。随着越来越多的传感器和设备被接入紧密的网络生态系统，证书颁发机制已被扩展到人员识别以外的机器识别。与代码签名一样，该技术使用数字证明确保了代码的物理真实性和完整性，及在产品生命周期内随时进行代码的验证与升级。这正为代码签名创造新的纬度：提高安全意识，以及需要在专用的保护环境中保存私有签名密钥，为整个系统建立信任的根源。鉴于恶意软件和高级持久威胁（APT）的流行，许多软件供应商、在线服务提供商、企业IT组织和高科技IoT设备的制造商都面临着增加其高科技制造和代码签名过程安全性的压力。[11]

参见

参考资料

  1. ^ Introduction to Code Signing. （原始内容存档于2017-08-03）. 
  2. ^ Hendric, William. A Complete overview of Trusted Certificates - CABForum (PDF). 2015 [2015-02-26]. （原始内容存档 (PDF)于2019-04-22）. 
  3. ^ Securing your Private Keys as Best Practice for Code Signing Certificates (PDF). 
  4. ^ Hendric, William. What is Code Signing?. 17 June 2011 [26 February 2015]. （原始内容存档于2018-06-20）. 
  5. ^ Digital Signatures and Windows Installer. （原始内容存档于2017-08-30）. 
  6. ^ 存档副本 (PDF). [2017-03-29]. （原始内容存档 (PDF)于2014-02-26）. 
  7. ^ Morton, Bruce. Code Signing (PDF). CASC. [21 February 2014]. （原始内容存档 (PDF)于2014-02-26）. 
  8. ^ 存档副本. [2017-03-29]. （原始内容存档于2014-04-16）. 
  9. ^ http://www.eweek.com/c/a/Security/Theres-A-Racket-Brewing-In-the-Code-Signing-Cert-Business/[失效链接]
  10. ^ Strong Name Bypass: .. [2017-03-29]. （原始内容存档于2010-02-12）. 
  11. ^ Code Signing. （原始内容存档于2017-02-24）. 

外部链接

检索自“https://zh.wikipedia.org/w/index.php?title=代码签名&oldid=77840245”