发布.net 强名称私钥的含义？答案

【问题标题】：implications of publishing a .net strong name private key?发布.net 强名称私钥的含义？
【发布时间】：2012-05-28 15:29:57
【问题描述】：

假设我想发布一个开源类库。我想知道我是否应该用它发布 snk。例如，我确实想要一个 snk 来使 dll GAC 友好。我见过有公开 snk (NHibernate) 和未公开的 (DevExpress) 的大项目，以及双方的小项目，所以没有普遍的协议，这是肯定的。

假设我不公开私钥。这个库的用户本身就是开发人员，如果他们想要进行任何更改，要么需要重新编译我的源代码，要么对强名称验证进行例外处理。脖子都疼，我去过。

假设我发布了它。我看不到如何利用它。 CAS 和其他东西不再广泛使用，更重要的是，它甚至在 .NET 4.5 中已被弃用。所以这不像是可怜的用户根据它的公钥令牌授予我的程序集一些权利，而坏人用相同的令牌产生一个错误的程序集。如果一个坏人可以将他自己的 dll 放在某人的计算机上，那么阻止他们的并不是强大的名称。

我认为没有人会检查程序集的公钥标记。当然，运行时检查它是否在编译引用程序集后没有更改，但仅此而已。发布者不发布他们的令牌，所以据我所知，我在编译我的时可能会首先引用一个错误的程序集。

所以我倾向于发布 snk。在我看来，它在理论上提供的安全性很小，在实践中没有安全性，所以为什么要让我的用户的生活更加艰难。也许我应该进行 X.509 代码签名（使用真正私有密钥的代码签名），但我认为大多数人也不会检查。

发布还是不发布？最好的论点获胜。理论方面、实践方面、MS™ 指南，都欢迎。

【问题讨论】：

标签： .net security strongname

【解决方案1】：

我不会发布它。

它将允许攻击者重新编译程序集，向其中添加恶意代码。更改后的程序集将与您的程序集具有相同的强名称。

如果您不发布密钥，您可以分发库的“受信任”二进制文件和没有密钥的源代码。如果第 3 方开发人员需要自定义库，他们只需为其生成一个新密钥（但生成的程序集将具有与官方版本不同的强名称，允许运行时区分两者）。

【讨论】：

我得到了第一部分，但是如果攻击者编译了一个恶意程序集，下一步是什么？如果他可以让某人运行这段代码，他可以让他们运行任何其他代码，所以他一开始就不需要我的强名。如果攻击者可以使用特定的公钥令牌生成程序集，他会更容易吗？
假设您有一个应用程序引用了您的强命名程序集。如果将程序集替换为具有相同名称但签名不同的文件，则运行时将不会加载它，因为应用程序要求程序集的特定版本。如果没有强名称键，运行时将加载任何具有相同文件名的程序集。
看看这篇关于强名称的文章：msdn.microsoft.com/en-us/magazine/cc163583.aspx
您仍然没有回答坏人如何利用强名。他不能只是替换别人机器上的dll。

【解决方案2】：

您不应该分发强命名密钥，但这与安全性几乎没有关系。

强命名是一种识别技术，而不是一种安全措施。它仅用于防止意外的装配身份冲突。（为了使其足够强大以供“严肃”的安全使用，它需要可撤销的密钥而不是自行生成的密钥。）

但是，防止意外碰撞是不将签名密钥分发到开源项目的充分理由。这是防止您的版本 1.2.3.4 看起来与其他人从修改的源代码编译的版本 1.2.3.4 相同的主要因素。鉴于为项目开放源代码的主要目标之一通常是允许人们分发从更改的代码编译的程序集，人们甚至可能会争辩说，适当的个性化强命名对于开源项目而不是封闭源代码分发。

【讨论】：