Giving a .NET Assembly a Strong Name

转载 2004年10月07日 08:58:00

By Brent Rector<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />


You assign an assembly a strong name by associating the assembly with a pair of 1,024-bit cryptographic public and private keys. The actual process varies slightly, depending on whether the developer has access to the private key. In larger, security-oriented corporations, most developers do not have access to the private key. Instead, only a few members of a final QA or security team can access the private key.

In order to assign one or more assemblies a strong name, you must first create the 1,024-bit public and private key pair. You do this by running the Strong Name Utility (SN.EXE), like so:

sn.exe -k PublicPrivateKeyFile.snk

This randomly creates a pair of 1,024-bit cryptographic keys. You can use these keys for encryption and decryption by using the RSA public/private key algorithm. The resulting key file contains both the public and the private key. You can extract the public key from the file and place it in a separate file like this:

sn.exe -p PublicPrivateKeyFile.snk PublicKeyFile.snk

Typically, you will only perform the above steps once per corporation or division because all assemblies you produce can use the same public and private keys as long as the assemblies have unique friendly text names.

Next, you need to associate the 1,024-bit public key with an assembly. You do this by telling the compiler to read the contents of a key file, extract the public key from the key file, and place the public key into the definition of the assembly's identity. In effect, this makes the public key an extension of the friendly text name of the assembly. This also makes the assembly name globally unique because no other developer will be using the same 1,024-bit public key as part of their assemblies' name.

When you have access to the key file that contains both the public and the private key, you can associate the assembly with a public key and digitally sign the assembly (discussed later) in a single operation by including the following compiler metadata instructions in one of your assembly's source files.

// C#

using System.Reflection;

 

[assembly: AssemblyDelaySign(false)]

[assembly: AssemblyKeyFile("PublicPrivateKeyFile.snk")]

Alternatively, when you only have access to the key file that contains just the public key, you must enable delay signing of the assembly. Therefore, instead of the above attributes, you need to specify the following attributes.

// C#

using System.Reflection;

 

[assembly: AssemblyDelaySign(true)]

[assembly: AssemblyKeyFile("PublicKeyFile.snk")]

 

At this point, your assembly has a strong name. Further, if you specified that the compiler should not delay-sign the assembly (therefore, the compiler did sign the assembly), the assembly is also a valid assembly and you can load it, debug it, and generally use it as you wish.

However, if you specified that the compiler should delay-sign the assembly (therefore, the compiler did not sign the assembly), you will discover that the runtime considers the assembly to be invalid and will not load it or allow you to debug and run it.

When the compiler digitally signs an assembly, it calculates a cryptographic digest of the contents of the assembly. A cryptographic digest is a fancy hash of your assembly's file contents. Let's call this cryptographic digest the compile-time digest of the assembly. The compiler encrypts the compile-time digest using the 1,024-bit private key from your public-private key pair file. The compiler then stores this encrypted compile-time digest into the assembly. Note that this all happens during development.

Sometime later, whenever the .NET loader loads an assembly with a strong name, the loader itself calculates a cryptographic digest of the contents of the assembly. Let's call this digest the runtime digest of the assembly. The loader then extracts the encrypted compile-time digest from the assembly, extracts the public key for the assembly from the assembly itself, and uses the public key to decrypt the previously encrypted compile time digest. The loader then compares the calculated runtime digest to the decrypted compile-time digest. When they are not equal, something or someone has modified the assembly since you compiled it; therefore, the runtime fails the assembly load operation.

Note: Based on the above description, when you do not have access to the private key, you cannot encrypt the compile-time digest, thus cannot sign the assembly. In this case, you must delay-sign the assembly. Setting the delay signing option to true tells the compiler that you'll calculate, encrypt, and store the compile-time digest into the assembly at a later time. Because a delay-signed assembly does not contain a valid digital signature, the runtime will not load it.

However, developers without access to the private key need to be able to debug and test a delay-signed assembly. Therefore, such developers must inform the runtime that it should load an assembly even though it does not contain a valid digital signature.

You can instruct the runtime to skip the digital signature verification process for a particular assembly a specific system by using the following command:

sn.exe -Vr YourAssembly.dll

Technically, this instruction registers the specified assembly for digital signature verification skipping. It is a sticky setting in that the runtime never again verifies the digital signature for that assembly until you unregister it for verification skipping using the inverse command:

sn.exe -Vu YourAssembly.dll

A developer without access to the private key cannot digitally sign an assembly, so must register the assembly for verification skipping in order to debug and test the assembly.

Finally, once the developer determines that the assembly operates correctly, she hands off the assembly to the team that does have access to the private key. That team performs the delay signing operation on the assembly by using the following command:

sn.exe -R YourAssembly.dll PublicPrivateKeyFile.snk

The strong name utility computes the compile-time cryptographic digest for the assembly, encrypts the digest with the private key from the key file, and stores the encrypted digest into the assembly. The assembly will now load successfully on all systems.

Now, let's consider the effect of obfuscation on this process.

One .NET obfuscator, Demeanor for .NET, uses the .NET runtime to load the assembly it is obfuscating to insure that it obfuscates exactly those assemblies the .NET runtime will load when an application executes. Therefore, the assembly to be obfuscated must be loadable. This means that, in order for Demeanor for .NET to load an assembly, one of the following must be true.

  1. It must contain a valid digital signature or,

  2. You must have enabled digital signature verification skipping for the assembly on the obfuscating system.

Obfuscation modifies the assembly. This means that even when the assembly contains a valid digital signature before the obfuscation process (step one above), the assembly will not contain a valid digital signature after the obfuscation process.

Therefore, after obfuscating an assembly, you must either re-sign the assembly (which computes the proper digest, encrypts it, and stores it into the assembly), or you must only use the assembly on systems with digital signature verification skipping enabled, which isn't really a practical option except for developers debugging the obfuscated code.

Practically, this means that you end up using the delay-signing process when obfuscating an assembly with a strong name. The typical usage pattern for a developer using obfuscation is:

Build the assembly with delay signing enabled.
Enable strong name verification skipping for the assembly (sn.exe -Vr).
Debug and test the assembly.
Obfuscate the assembly.
Debug and test the obfuscated version.
Delay sign the assembly (sn.exe -R).

Alternatively, smaller shops that allow all developers access to the private key do the following:

Build the assembly with delay signing disabled.
Debug and test the assembly.
Obfuscate the assembly.
Delay sign the assembly (sn.exe -R).
Debug and test the obfuscated version.

 

About the Author

Brent Rector has designed and written operating systems, compilers and many, many applications. He began developing Windows applications using a beta version of Windows 1.0. Brent is the founder of Wise Owl Consulting, Inc. (http://www.wiseowl.com), a Windows software development and consulting firm and is an instructor for Wintellect (http://www.wintellect.com). Brent has developed the premier .NET code obfuscator, Demeanor for .NET, Enterprise Edition. He has also written several books on Windows programming, including ATL Internals, Win32 Programming and others.

引用三方Dll时,产生“does not have a strong name”错误

【问题描述】 1.在项目中,右键添加三方.dll文件时,无法生成,会出现如下错误。 2.这是因为.dll文件没有使用签名文件进行签名,存在着一切安全隐患,固编辑器组织生成这一行为。 对于签名...
  • sakyaer
  • sakyaer
  • 2015年08月26日 18:54
  • 1481

Assembly学习

说明:最近开始准备把学到的.NET知识重新整理一遍,眼过千遍不如手过一遍,所以我准备记下我的学习心得,已备参考。J各位都是大虾了,如果有哪些错误或者不完整的地方,还请不吝指出。多谢了。本文分为两部分:...
  • jxufewbt
  • jxufewbt
  • 2007年04月25日 18:46
  • 1009

Sign a .NET Assembly with a Strong Name Without Recompiling

Signing a .NET assembly with a strong name is easy in Visual Studio. However, what if this is a 3rd ...
  • showRaining
  • showRaining
  • 2012年04月11日 13:20
  • 242

strong name

The Secrets of Strong Naminghttp://www.ondotnet.com/pub/a/dotnet/2003/04/28/strongnaming.htmlhttp://...
  • 2066
  • 2066
  • 2004年10月09日 19:50
  • 4483

HOW TO: Create an Assembly with a Strong Name

  • zgqtxwd
  • zgqtxwd
  • 2008年05月01日 03:43
  • 242

dotfuscator 在混淆.Net Framework 4.0以上版本的时候报错的解决方法

在混淆的时候报错了,错误描述大致如下: Could not find a compatible version of ildasm to run on assembly C:\xxx.dll This...
  • winnyrain
  • winnyrain
  • 2013年12月05日 14:50
  • 11485

mysql5.7.14安装

1.关闭防火墙 禁止iptables  :  #/etc/init.d/iptables stop #chkconfig --del iptables 禁止 selinux #getenforce ...
  • zhengwei125
  • zhengwei125
  • 2016年08月30日 16:37
  • 690

Sign Assembly with strong name

Sign Assembly with Strong name : del .\Signed\*.* /F /Y "C:\Program Files (x86)\Microsoft ...
  • csharp25
  • csharp25
  • 2014年05月07日 13:16
  • 857

关于.net assembly的strong name问题

按照我当前的理解,.net assembly作为com的接班人,需要解决dll的版本问题。 错误一般发生在运行时,会抛出IO Exception,指明strong name name validati...
  • realduke2000
  • realduke2000
  • 2010年11月17日 14:16
  • 450

关于.Net的强名称(Strong Name)

.Net中的强名称(Strong Name)
  • Anor
  • Anor
  • 2008年12月30日 17:53
  • 1960
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:Giving a .NET Assembly a Strong Name
举报原因:
原因补充:

(最多只允许输入30个字)