.net强名

  如果你使用.NET作为开发工具很长时间了，你肯定回会碰到“强名”（strong name）这个概念。这个概念并不意味你的组件命名方式必须类似于MyCompany.Gorilla.Biceps的方式。强名的力量体现在对组件的保护方面，.NET Framework使用强名来标识组件和保护组件使其免遭破坏。在这篇文章中我将说明如何建立强名，以及在.NET中使用强名的技巧。

1 ． 散列和签名

为了了解强名的工作原理，你必须首先理解密码学方面的两个概念：散列（ hashing ）和数字签名 (digital signatures) 。散列是用来为明文（ plaintext ）信息创建一个唯一的压缩的值。这里的“信息”是一个很广泛的概念，对于组件来说，信息就是它本身。如图 1 所示，信息作为散列作为散列算法的输入而被处理，对于强名情况，采用 SHA1 算法。

散列是不可逆的，一旦计算出来，是不可能解密的。但是，散列在比较值方面是非常有用的。如果两个组件生成同样的散列值，你可以认为这两个组件是相同的。相反，通过散列计算出来的值和以前计算的值不一样，说明组件中某个地方被修改了。

因此通过散列值你就可以知道，组件是否被修改或破坏。然而你怎样通过散列值来防止别人对你的组件的修改呢？下面就是我要讲的“数字签名”。

虽然数字签名的具体数学原理很复杂，但是概念很简单。一个数字签名依赖于两个相关的数字：公共秘匙（ public key ）和私有密匙 (private key) 。如图 2 所示，当数据通过公共秘匙加密后，它只能通过私有密匙来解密，反之亦然。

2 ．   组件的强名

  在 .NET 中共同使用散列和数字签名就能够保护你的组件免遭破坏。其原理如图 3 所示，首先从组件产生一个散列值，然后这个散列值通过你的私有密匙被加密，然后这个散列值和公共密匙被一起放置在组件中。

在运行的时候，公共语言运行时（ CLR ）通过比较散列值验证组件。首先公共的密匙用来解密散列，从当前的组件中计算出一个新的散列。如果它和原来的值吻合，那就通过了验证，如图 4 所示。

那么如果一个组件在签名之后被破坏将会发生什么样的情况呢？显然，在运行时从组件中计算出来的散列值将不会与存储在组件中通过私有密匙加密的散列值吻合，这样公共语言运行时将拒绝加载该组件。

注意强名只是保证了组件的完整性，而并非它的安全性，没有什么办法来防止某个人创建一个恶意的组件，并通过强名来给它签名。你可以通过强名来验证某个组件在签名后是否被破坏。基于你对于信息的选择。这一切将由你来决定是否相信从某个地方来的组件和代码信息。

3 ．强名的其它信息

除了从组件内容求出来的散列，强名还包含一下三个方面的信息。

l          组件简单文本名称

l          组件版本号

l          组件的语言文化代码

所有的这些信息，将为每个组件提供唯一的标识。有了这些信息，公共语言运行时可以决定一个组件是否被另一个组件通过引用的方式调用。当你从一个组件引用另一个组件，该组件将存储被调用组件的公共密匙。在运行的时候，公共语言运行时将通过这些来判断该组件是否来自正确的供应商。另外强名中的其它信息用来判断组件是否符合引用的绑定策略（ binding policy ）的要求。

4 ．使用强名的技巧

 .NET Framwork SDK 和 Visual Studio.NET 为指定强名提供了很多的工具，这是很有意义的，因为通过 Visual Studio.NET 来创建组件具有更多的选择。在你签名之前你必须创建一对密匙（公共密匙和私有密匙），通常密匙对放置在以 .snk 结尾的文件中。可以通过强名工具 sn.exe 来实现。

        sn -k MyKeyFile.snk

   如果你使用命令行编译器（ vbc.exe 或者 csc.exe ），你就可以为组件连接器 al.exe, 指定密匙对。如下面的命令行所示，你可以将存储在 MyKeyFile.snk 中的密匙对作为 MyFile.dll 的签名。

al /out:MyFile.dll MyFile.netmodule /keyfile:MyKeyFile.snk

如果你使用 Visual Studio .NET ，你仍然可以通过命令行的方式产生你的密匙对。有了密匙对之后你就可以通过设定在组件信息文件（ AssemblyInfo.vb 或者 semblyInfo.cs ）的【 AssemblyKeyFile 】属性来把它包含到组件中。例如 C ＃工程，你可以通过该属性包含密匙文件而生成一个签名组件。

[assembly: AssemblyKeyFile("..//..//MyKeyFile.snk")]

   从被编译的组件到密匙文件，【 AssemblyKeyFile 】属性中的文件名必须包含完整的相对路径。

5 ．通过延迟签名加密

保护你的私有密匙是非常重要的，如果某个恶意的人取得了你的密匙，他生成的组件将和你签过名的组件一样。因此，应当把你的密匙设于高度的保密状态，公司里面可能就只有几个人知道。这样以来，又怎么给你的组件签名呢？如果就只有你一个人知道密匙，这样会很繁琐，因为你必须为公司中每个开发者开发出来的每个组件签名。

很幸运的是 .NET 为这个问题提供了一个很好的方法：延迟签名。通过延迟签名，你可以在只知道公共密匙的情况下创建和测试组件。只有在组件实际分发给用户时才将私有密钥匙包含到组件。下面是使用延迟签名过程的一些技巧总结：

1.          从公共 / 私有密钥匙对中提取公共密匙。为了提取公共密匙，也就是存储公共 / 私有密匙对，你可以使用强名工具，命令行如下：

sn.exe -p MyKeyFile.snk MyPublicKeyFile.snk

2.          将包含公共密匙的文件分发给公司所有的开发者，同时将包含公共 / 私有密钥匙对的文件安全存放。

3.          在组件信息文件中包含公共密匙的文件，并注明延迟签名。

[assembly: AssemblyDelaySign(true)]

[assembly: AssemblyKeyFile("..//..//MyPublicKeyFile.snk")]

如果你使用组件连接工具，而非 Visual Studio .NET ，你可以使用 /delaysign 命令行来表明延迟签名。

4.          如果你把组件保存在全局程序集缓存（ GAC ）中，应关闭对组件的验证，因为 GAC 默认验证每个组件的强名。如果组件没有采用私有密钥匙来签名，这个验证将会失败。因此，出于开发和测试的目的你可以输入如下的命名行：

            sn.exe -Vr MyFile.dll

5.          这样，你就可以在开发和测试的时候很自由的使用组件

6.          当部署一个延迟签名的组件的时候，你必须通过私有密匙来给它签名。

sn.exe -R MyFile.dll MyKeyFile.snk

7.          最后，你必须通知 GAC 重新开启对组件的验证。命名行如下：

sn.exe -Vu MyFile.dll

6 ．可信任计算 (TrsutWorthy Computing)

你肯定听说过微软的“可信任计算”措施，它包含了有关微软产品的很多安全方面的措施。微软正慢慢的而且必然的朝着一个方向发展，那就是他们将使他们所有的软件产品是默认安全的。如果你知道你在做什么，你就可以降低软件（如 Windows Server 2003 ）的安全级别。虽然降低了安全级别，但太可能使你受到突发事件的攻击。

当你给你的组件赋予强名，你在做就是“可信任计算”。通过强名来分发你的组件，会使得组件不太可能成为木马和其他攻击计算机黑客程序的载体。 .NET Framework 和 Visual Studio .NET 提供的工具保证了你分发组件的完整性。因此我强烈建议你使用这些工具，通过这些工具来使得计算世界变得更安全一点。