感谢ikimi的投递

代码签名是对可移植可执行文件（PE文件）或脚本（如VBS）进行数字签名以确认软件作者及保证文件在签名后未被修改、篡改、破坏的方法。对于普通用户而言，代码签名最直观的感觉是，在WindowsVista及以上操作系统中，当某个行为触发UAC时，弹出的对话框，可以清晰辨识发起人的身份。

时至今日，正规的软件著作权人一般都会对自己的程序进行数字签名。

对PE文件、脚本文件部署数字签名，需要代码签名数字证书，并使用工具软件将证书部署到文件中。这种工具软件就是业内所称的代码签名软件。笔者作为一名PKI爱好者，就国内四款具有图形化界面的签名软件做一横评。

测试环境：Windows 10 1803 Build17134.254

签名软件：

1、数字签名工具专业版（开发商：亚数信息科技（上海）有限公司，下文简称“TrustAsia”，Symantec/ DigiCert 在华合作伙伴）（自带测试证书），当前最新版本：3.2.0

2、代码签名证书助手（开发商：北京天威诚信电子商务服务有限公司，下文简称“天威诚信”，Symantec/ DigiCert 在华合作伙伴），当前最新版本：1.0.16.308

3、沃通代码签名工具WoSignCode（开发商：沃通电子认证服务有限公司，WoTrusCA Limited，下文简称“沃通”，CA机构），当前最新版本：3.0.1.10

4、环玺信息数字签名工具（开发商：环玺信息科技（上海）有限公司，下文简称“GlobalSign”，GlobalSign中国代表）（自带测试证书），当前最新版本：1.3.6.1

下文若无特别说明，横评所用代码签名证书：TrustAsia、GlobalSign测试证书（sha1RSA、sha256RSA各一），ikimi（sha256ECDSA）。（说明：sha1、sha256为散列算法，RSA、ECC、DSA为加密算法，ECDSA为ECC、DSA结合体）

评测宗旨：选取与代码签名相关的且大众化的场景，测试场景基本按复杂性、安全性递增排列。此外，由于代码签名设计到多个维度的参数，下述所列场景中，部分维度参数会多重排列组合。

场景1：单签名（sha1证书sha1签名）

四款工具均能对文件进行签名，但需要指出的是，GlobalSign在不添加时间戳时直接报错“无法获取SHA1签名选项！请检查规则设置是否正确、有效。”无法进行签名，考虑到代码签名过程中添加时间戳不是必须项，因此，不配置时间戳就不能代码签名，不妥，这一点笔者早先在使用GlobalSign老版（1.3.5.2）软件时已发现此问题，并通过QQ、Email等方式反馈给GlobalSign，遗憾的是，当前的最新版（1.3.6.1）仍未修复此问题

场景2：单签名（sha256证书sha1签名，微软交叉签名）

本例使用的证书路径，(Microsoft CodeVerification Root) —— VeriSign Class 3 PublicPrimary Certification Authority - G5 —— SymantecClass 3 SHA256 Code Signing CA —— 终端用户证书（sha256RSA）

TrustAsia、天威诚信、GlobalSign（需配置时间戳）通过，沃通能签名，但不合需求，签名无法指定sha1散列算法，签名散列算法取自数字证书散列算法，无法满足场景需求，未通过，不过，这个根据数字证书散列算法自动匹配签名散列算法倒是完全符合场景3的需求

TrustAsia、天威诚信、沃通在进行微软交叉签名的时候，可以自动判别证书是否支持微软交叉签名，对于不支持微软交叉签名的证书，GlobalSign直接提示“签名失败！”

TrustAsia提示无法使用该证书进行微软交叉签名

天威诚信提示无法使用该证书进行微软交叉签名

沃通提示找不到微软交叉签名证书

GlobalSign直接提示“签名失败！”

场景3：单签名（sha256证书sha256签名）

TrustAsia、沃通、GlobalSign均能对文件签名，其中，GlobalSign出现了与场景1同样的情形，不能在不添加时间戳的情况下满足需求；天威诚信可以签名，但签名算法为sha1，不合需求，未通过

场景4：双签名（sha1证书sha1签名，sha256证书sha256签名）

四款软件均能完成签名，但GlobalSign仍然需要在添加时间戳的情况下才能完成代码签名。

场景5：双签名（sha256证书sha1签名，sha256证书sha256签名）

TrustAsia、GlobalSign通过，GlobalSign仍然需要在添加时间戳的情况下才能达成本需求。由于本场景的第一部分“sha256证书sha1签名”同场景2（不考虑是否进行微软交叉签名），所以沃通未通过，同时，天威诚信不支持相同散列算法证书同时进行sha1、sha256签名，所以也未通过。

场景6：追加sha256签名（已有sha1签名）

TrustAsia、沃通、GlobalSign（仍需配置时间戳）通过，天威诚信直接用sha256签名覆盖原有签名，未通过。

场景7：已有主签名和扩展签名，再追加扩展签名

因为场景6，所以本场景天威诚信亦不支持，其余三款软件，经测沃通和GlobalSign（仍需配置时间戳）通过，TrustAsia对于已有扩展签名的文件不再追加新的扩展签名。

需要多个扩展签名的实例，驱动程序、安全软件等系统底层的程序，微软的相关策略所致。

Nvidia驱动程序

卡巴斯基虚拟键盘驱动

以上场景主要考量签名软件对于不同需求代码签名的支持程度，下面的8-13共六个场景侧重于时间戳的部署。

场景8：单签名部署MSAuthenticode规范时间戳

四款软件均支持。

场景9：单签名部署RFC3161协议时间戳

四款软件均支持。

场景10：双签名，主签名部署MSAuthenticode规范时间戳，扩展签名部署RFC3161协议时间戳

四款软件均支持。

场景11：扩展签名部署MSAuthenticode规范时间戳

沃通支持，其余三款软件对扩展签名仅支持部署RFC3161协议时间戳。

之所以将此场景作为常见签名类型列入本次测试，是考虑到sha1的弱安全性和WindowsXP SP3不支持RFC3161协议，需要在sha256扩展签名的情况下同时仍部署MSAuthenticode规范时间戳。

场景12：时间戳支持自定义

沃通支持，其余三款软件时间戳的配置固定若干常见项。

数字签名工具专业版（TrustAsia）

代码签名证书助手（天威诚信）

沃通代码签名工具WoSignCode（沃通）

环玺信息数字签名工具（GlobalSign）

场景13：单独补签时间戳

TrustAsia、沃通支持

场景14：命令行操作

TrustAsia、沃通支持

有了命令行工具，便于软件开发商批量、快速部署代码签名。

场景15：支持非RSA加密算法数字证书

尽管RSA加密算法数字证书在代码签名领域中市场份额高，但不容否认，ECC加密算法凭借其抗攻击性强、运算速度快的特点，随着安全等级的提高，RSA加密算法密钥长度会成指数级增加，而ECC加密算法密钥长度只是成线性增加，ECC优势不言而喻。举个栗子，128位安全加密需要3072位RSA密钥，却只需要一个256位ECC密钥，当提高到256位安全加密，则需要一个15360位RSA密钥，却只需要一个512位ECC密钥。

测试证书CN=ikimi使用的是ECC加密密钥，密钥长度384位（散列算法sha256）。

经测试，TrustAsia、GlobalSign可以从系统中正确枚举出该证书，天威诚信、沃通无法枚举，若证书是以匙包文件形式存在的话，沃通支持导入，但考虑到CA/BForum已经要求CA必须使用UKEY等硬件设备存储密钥，因此沃通仅支持匙包文件形式的ECC加密算法代码签名数字证书，本场景测试仍判定为不通过。

数字签名工具专业版（TrustAsia）

代码签名证书助手（天威诚信）

沃通代码签名工具WoSignCode（沃通）

环玺信息数字签名工具（GlobalSign）

总结：从功能点上来说，天威诚信比TrustAsia、沃通和GlobalSign少了一些。

考虑到业内安全需求和CA/BForum制定的策略，对于代码签名而言，目前，场景4最能保证安全性和兼容性，所以这四款软件基本都能满足软件开发商（尤其是不熟悉代码签名部署的开发人员）对于代码签名的需求。