为什么.NET不验证BCL/CLR？

BCL 和 CLR 中的所有 .NET 程序集（以后仅使用 CLR）都是强命名和数字签名 https://stackoverflow.com/questions/1334631/signing-of-net-assemblies。提供数字证书是为了提供组件未被篡改或替换的信任措施。然而，.NET 似乎从未检查过数字签名（它可以检查强名称如 Hans指出 https://stackoverflow.com/questions/7385084/why-does-net-not-verify-the-bcl-clr/7385229#7385229).

It makes sense that checking on assembly load is flawed becaused an modified CLR could fake the answers. My thinking is that the only safe place from the perspective of .NET¹ to check is on start of the framework as part of the unmanaged code that boot straps the framework. Big downside is the performance impact.

I am looking at this from the perspective of a developer, in otherwords how do I know that my application is not being compromised by an already owned CLR², or put another way is there anyway for an application to trust the CLR?

所以我的问题是为什么 .NET 不验证 CLR？是因为性能影响还是还有其他原因？

---

1. I am focusing on .NET, it is possible to mess with Windows and thus break the idea but if you already own Windows you don't really need to own .NET.
2. Example of this is user inputs password into application, it is stored in a SecureString but the BCL is compromised so the attacker is now getting that info. It allows them to capture the information for something else. I realise the attacker if he could replace the CLR could put a key logger on the machine too, but that is (hopefully) detectable with a decent security tool. There is also lots of other ways to attack this, the core is how do I know if SecureString has been changed.

这在 .NET 3.5 SP1 中进行了更改，旨在作为启动性能改进 http://blogs.msdn.com/b/shawnfa/archive/2008/05/14/strong-name-bypass.aspx对于完全信任运行的应用程序，使其与不进行此类检查的本机程序具有同等地位。验证强名称的成本很高，而且由于 DLL 数量众多，托管程序的冷启动往往很慢。您可以使用 .config 文件重新打开它：

<configuration>
    <runtime>
        <bypassTrustedAppStrongNames enabled="false"/>
    </runtime>
</configuration>

或者通过编辑注册表项，使其对所有 .NET 程序生效：

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"AllowStrongNameBypass"=dword:00000000

还要在 64 位计算机上设置 HKLM\Software\Wow6432Node 密钥。