签署 .NET 程序集答案

【问题标题】：Signing .NET assemblies签署 .NET 程序集
【发布时间】：2011-01-18 14:33:24
【问题描述】：

我正在尝试掌握 .NET dll/程序集的正式签名。

特别是

何时以及如何使用私钥
创建/控制私钥的最佳实践
需要对哪些类型的模块进行签名/最佳实践

【问题讨论】：

另见Best practices for signing .NET assemblies?

标签： .net code-signing

【解决方案1】：

请参阅使用Strong Name Signatures 以获得关于签名的非常好的文章。

如果我们谈论的是程序集的强命名，那么应该使用签名来防止第三方“欺骗”您的代码。强名称是程序集的一部分，因此具有相同名称和不同签名的另一个程序集是不同的程序集。这还可以防止程序集被修改和重新签名（没有私钥）。

为了有用，私钥必须保密。这通常通过delayed signing 和仔细管理私钥访问来完成。

您也可以使用Authenticode（为您的强命名程序集签名）；这可以增加对程序集实际来自谁的信心。

【讨论】：

【解决方案2】：

当您希望您的消费者知道这些程序集确实来自您（而不是冒名顶替者）时
实体/组织的私钥应该只能由少数人访问并保持在 lock-n-key 下。在开发过程中使用延迟签名。
理想情况下，您应该签署所有托管程序集。

【讨论】：

【解决方案3】：

不要将 强名称签名 与 Authenticode 签名

混淆

正如 Microsoft 所普遍描述的那样（我直接询问了一本书的作者），强名称只是一种版本控制形式，而不是身份验证。出于可靠性目的，程序集也通过强名称公钥存储在 GAC 中（您发布了新版本的库，以前的版本不会被覆盖以防止旧应用程序中出现回归错误）。

我不能 100% 确定，但 Mono 的 System 程序集与 Microsoft 的公钥匹配。不是一种真正的安全形式......

Authenticode 签名，而是用于执行代码身份验证。您需要来自受信任 CA 的付费证书，并使用 signtool.exe 或 Visual Studio 签署您的程序集。

这里所说的关于安全性、签名服务器等的所有内容都适用于这里。但关键是您没有指定要放入代码中的签名类型。

【讨论】：

【解决方案4】：

* When and how to use private keys
* Best practices for creation/control of private keys

您创建并使用密钥对（file.SNK）。仅创建一次（为您的公司/部门）并确保其安全。

* What sort of modules need to be signed/ best practice for going about it

您需要签署进入 GAC 的库。但最佳做法是签署您运送的所有程序集。

当此签名的可靠性非常重要时，您可以在发货前使用“部分签名”和最终签名。这意味着并非每个开发人员都需要访问（真实/完整）密钥对。

【讨论】：

【解决方案5】：

通常，当您的产品是软件或者您在每个软件都受到审查的环境中工作时，代码签名很有用。通过签署您办公室的定制软件，您可以将其置于比其他人更高的信任关系中。

通常，您生成私钥，然后在进行构建时，可以将该私钥附加到构建服务器上。这可以防止公司周围的开发人员访问私钥。

您签署的内容完全取决于您。我想说，在给定特定信任环境的情况下，最容易绝对无法工作的模块需要签名......例如，访问文件系统对象或数据库连接字符串的 DLL。我会养成签署最少代码量的习惯，然后从那里开始构建，否则，您将面临签署所有内容的风险，然后假设您组织中的所有内容都可以安全运行。同样，这完全取决于您组织中的安全问题级别。

【讨论】：