使用数字签名对强命名程序集进行签名是一种不好的做法吗？答案

【问题标题】：Is it a bad practice to use a digital signature to sign a strongly named assembly?使用数字签名对强命名程序集进行签名是一种不好的做法吗？
【发布时间】：2014-03-06 20:30:50
【问题描述】：

我很好奇，通过 Google 研究，我一直在了解数字签名和强命名程序集。如果您真的很努力，似乎可以使用数字签名来签署强命名程序集。

我推测，通过这种做法，可以通过这种方式绕过数字签名的目的。

微软说：

“强名称本身并不意味着像数字签名和支持证书所提供的那样的信任级别。”
--http://msdn.microsoft.com/en-us/library/wd40t7ad%28v=vs.110%29.aspx

我是否正确猜测以这种方式使用数字签名实际上是一种不好的做法，这可能会造成安全漏洞并且绝对没有任何用途？或者甚至有可能吗？使用数字签名作为强名称是可能的还是比什么都不做更好？除了正确使用数字签名之外，它是否提供了一些额外的安全性。

【问题讨论】：

Microsoft .NET Framework 程序集由 Microsoft 强命名和数字签名。
@MichaelLiu Umm 你想说什么？详情？
否。强命名并不是为了防止 DLL 地狱。名称中的 version 防止了 DLL 地狱，但这并不是名称 strong 的原因。 strong 这个名字的由来是公钥令牌，而 that 是出于安全目的：提供 evidence 作为 evidence 的输入i>安全政策.
GAC 中的程序集必须具有强名称；如果您没有证据证明代码的来源，则不应将代码放入 GAC。再说一遍：DLL Hell 解决部分名称是version。 I-want-to-run-code-actually-written-by-Microsoft 解决问题是 key token。
不幸的是，存在两个非常相似的东西，因为它会导致像这样的对话混乱！ :-) 如果我成为 .NET 之王，并有机会重来一遍，我会使用证书进行强命名和签名同样的事情，并让强名称密钥生成工具生成自签名证书。

标签： c# .net-assembly digital-signature strongname

【解决方案1】：

使用数字签名对强命名程序集进行签名是一种不好的做法吗？

没有。这是一个非常好的做法。

如果您真的很努力，似乎可以使用数字签名来签署强命名程序集。

这有点棘手，因为强命名和数字签名都会修改程序集。程序集必须先进行强命名，然后再签名。

我推测通过这种做法可以绕过数字签名的目的，因为强命名的程序集可能会被黑客入侵

好的，所以您推测存在攻击。我推测没有。说明漏洞和提议的攻击。

（至少有些帖子是这样说的）。

你想让我们猜是哪个帖子这么说的吗？

“强名称本身并不意味着像数字签名和支持证书所提供的那样的信任级别。”

没错。强名称和数字证书相似，但它们解决的问题不同。强名称解决了程序集的识别问题。签名解决了信任链问题。

我见过一些互联网海报的例子，他们试图完全做到这一点，认为他们正在保护自己的软件。

强命名和证书签名都不能保护软件！安全系统的目的不是保护软件，而是保护用户。我们没有驾驶执照来保护机动车辆部免受忍者攻击。我们有驾驶执照，以证明执照持有人确实是他们所说的人并且被允许驾驶。任何认为强命名是为了保护软件的人都非常非常困惑。

我是否正确猜测以这种方式使用数字签名实际上是一种不好的做法，这可能会造成安全漏洞并且绝对没有任何作用？

不，你在每一个方面都错了。

穿越溪流是好事还是坏事（请原谅幽默。）？

为什么会是一件坏事？我们所拥有的只是您声称存在攻击，没有任何证据表明确实存在攻击。

或者有可能吗？

当然可以。

我看到的帖子中提到了将两者结合使用（使用数字签名对程序集进行签名，特别是强命名（未数字签名））是可能的还是比什么都不做更好？

您要求我们对我们未阅读且您未提供链接的帖子的准确性发表评论。我们如何知道它们是否准确？

【讨论】：

没有必要去寻找其他的帖子，我确信有些不准确，有些不准确。我把它们作为我提出问题的动力，它们对问题的实质并不重要。我会考虑删除那部分。问题的重点很简单（至少在我自己看来），但我会看看我是否能让它更好地匹配接受的答案。
在产品中，我们从每个程序集的强名称和数字签名开始。我们在未连接到互联网或公司网络的机器上遇到问题。在医疗保健行业，这很正常。在数字签名的 EXE 进程开始之前有很长的延迟。这是由系统尝试更新的过期证书吊销列表引起的。但不存在互联网访问或 DNS 服务器，因此 DNS 超时为 +/- 30 秒。必须在进程开始之前发生。这是数字签名产生问题和额外工作的情况。

【解决方案2】：

不存在用于对程序集进行强签名的密钥的信任链。您不能将相同类型的密钥用于强名称签名和“代码签名”：因此“混合和匹配”没有问题。这两种类型的签名服务器有两种不同的用途，您需要在特定情况下选择您需要的一种（很可能只是强名称签名，而 .Net 没有内置验证另一种）。

对于强名称签名，您不能说特定密钥是否属于特定实体，这与其他类型的签名不同，您知道签名证书的来源（即身份验证签名或 HTTPS 的 SSL 证书）并且可以合理确定来源。

强签名告诉您，程序集由同一“实体”创建的同一密钥签名，但没有迹象表明该“实体”是什么/谁。你不能真的说“这个新版本的程序集是由 FooBar 公司构建的”，你只能说“它是由与之前的相同的公司/组构建的”。

注意：确实有一些“众所周知的”公钥（即由 Microsoft 签名的框架程序集），但您无法获得任何程序集并仅通过查看公钥就说“由 X 签名”。

请注意，这在 Eric Lippert 的回答 - Signing of .NET Assemblies 中有详细介绍。

【讨论】：

好的，到目前为止一切顺利，证实了我所读到的大部分内容。是不是比什么都不做更糟糕？您是否通过不正确地使用证书来强烈命名程序集而冒着您的证书的风险。（尽管我认为您是在说这是一件困难且令人望而却步的事情。）
找到 Eic Lippert 的正确重复答案 - stackoverflow.com/questions/1334631/signing-of-net-assemblies。我相信您无法为强签名提供自定义证书，因此您不能那样“冒险”。
我认为你的评论，就像@Michael Liu 一样，回答了这个问题……至少差不多，除了他们是 cmets。
@amalgamate - 我已经嵌入了评论，而且我认为 Eric 的回答也涵盖了你的主要观点 - 两种类型的歌唱只是不同且不相关。
顺便说一句，+1，您在帮助我理解这一点上做了很多工作。

【解决方案3】：

只是把它分成清晰的部分，因为我不太很确定你在问什么。

是否可以使用数字签名的私钥（例如 Authenticode）来强命名程序集？

是的，至少在理论上是这样——因为所有的键都是字节序列。

这样做有什么意义吗？

由于您不需要为强命名的私钥付费，因此使用付费数字签名来做这件事没有多大意义，不。您支付的是与数字签名相关的信任。正如 Eric Lippert、Alexei 和其他人所解释的那样，强命名并不代表信任。

如果你这样做，会不会是一个安全漏洞？

没有。无论您是进行数字签名还是强命名，也无论您使用什么私钥，您通过程序集提供的所有内容都是公钥。公钥意味着是公共知识——这就是非对称密码学的重点。只要您的私钥保持私密，就没有漏洞。

ETA：不过，我希望看到问题中提到的关于使用 Authenticode 签名的强命名（而不是将两者结合起来）的帖子。

【讨论】：

+1：我认为“与程序集一起分发是公钥”是对这个问题的主要关注点的答案。
我想你很清楚我实际上在问什么。
我很高兴。 :-) 请查看编辑后的答案（底部）-如果您可以链接到这些帖子中的任何一个，我希望看到它们是出于兴趣。
这是许多帖子中的一篇，他们的脑海中似乎有这个想法，但我知道这是一个问题的一部分，其中操作也不清楚这一点。大多数都是这样。 stackoverflow.com/questions/8300865/…，我想我记得一些关于手机应用程序的帖子，这些帖子似乎对自己更加模糊，但是当我简要浏览浏览器历史时找不到它们。关键是看到别人糊涂之后，我自己的理解也发现了一些糊涂的地方。
是的，我认为重点不是使用 Authenticode 来进行强命名，而是客户想要SN - 并且OP 已经在对他的代码进行Authenticode 签名并想知道仅此一项是否可以达到强命名的目的-事实并非如此。正如@AlexeiLevenkov 所说，这两个概念有不同的用途。