使用强名称（存储在 .snk 文件中的密钥对）进行签名（除其他用途外）旨在防止伪造组件。
例如：我发送了一个用强名称签名的程序集，然后其他一些开发人员使用我的程序集，所以他的程序集现在包含对我的引用，提到我的密钥对的公钥。一些用户安装了该开发人员程序集和我的程序集，并愉快地使用了该开发人员的代码。如果其他人试图生成一个看起来像我的版本的程序集并说服用户这是一个“值得安装的更新”，那么伪造的程序集将不会加载，因为我控制着我的密钥对并且伪造的程序集没有使用相同的密钥对进行签名. 好的，酷。
但是，是什么阻止了恶意方伪造我的程序集和其他开发人员的依赖程序集并“运送”它们呢？他们抓住我的程序集和那个开发人员的程序集，篡改两者，用任何密钥对我的程序集的伪造版本进行签名，然后将对其的引用添加到依赖程序集的伪造版本中，也对其进行签名，然后将两者都发送出去。我的意思是恶意“运送”两个程序集不应该比“运送”一个程序集困难得多。
使用强名称签名如何防止伪造多个程序集？
对程序集进行强命名实际上并不意味着保护已签名的程序集。这是为了保护正在加载签名程序集的其他程序集。
例如，如果一个 EXE 是受信任的，并且想要从已知位置（例如 GAC、网络共享、互联网等）加载已知 DLL，它可以使用强名称来执行此操作，并具有一定程度的信心，即组件未被篡改。
但是，如果整个程序集被反汇编然后重新组装并重新签名，那么是的，你是对的，他们可以重新编写加载其余程序集的代码行，以便加载它们新（假）密钥。
但是这种篡改是显而易见的。换句话说，强名称签名提供了篡改的明确证据，但并不能在所有情况下都阻止它。除此之外，本地管理员可以完全禁用强名称验证（出于“开发”目的），并且很明显强名称签名不是一种防弹的安全机制。
不过，Authenticode 和驱动程序签名也是如此。我们都见过一种产品，它指示用户“忽略安全警告”。如果强名称验证被禁用或整个程序集的签名被剥离，这基本上就是 EXE 会做的事情——它会忽略警告。
强命名就是，嗯…… “命名”。我从这里引用：使用强名称签名
“强名称为赋予 .NET Framework 程序集唯一标识提供了强大的机制。”
这就是你从这个机制中得到的全部。这意味着我可以伪造你的程序集和它引用的所有程序集，但我无法假装“你做到了”。我无法假装您是这些程序集的发布者。