Strongly-named assembly, signature, delayed Signature

Strong namingProgramSet

If an assembly has a unique tag, this assembly can be called a strongly-named assembly. In the. NET Framework, the unique tag is generated through public/private key encryption. A strongly-named Assembly contains four unique flag Assembly features: File Name (without extension), version number, language and cultural information (if any), and public key. This information is stored in the Assembly List (manifest. The list contains the Assembly metadata and is embedded in a file of the Assembly. The following string identifies two different assembly files:

"Mytype, version = 1.0.1.0, culture = neutral, publickeytoken = bf5779af662fc055"

"Mytype, version = 1.0.1.0, culture = en-US, publickeytoken = bf5779af662fc055"

Weak naming assembly

In fact, there is no weak name assembly, but it is a concept generated to correspond to a strong name assembly. A weak named assembly is an assembly without a unique flag. The structure of the strong assembly and the weak assembly is the same. It is a unique identifier, but the latter does not. One difference between them is that a strongly-named assembly has a publisher's public/private key signature pair that uniquely identifies the publisher of the Assembly.

Benefits of strong naming

Because the strongly-named Assembly uses a public/private key pair for unique signature, different company public/private key pairs cannot be the same, so the generated programs are also different, this solves the previously encountered DLL hell problem (two different companies may develop an assembly with the same name, if the same name of the program set is placed in the same directory, then, the Assembly overwrites the Assembly. The Assembly that is finally installed overwrites the previous Assembly, which may cause the application to run abnormally ). Even if the names of any two strongly-named assembly are the same, Windows knows that they are two different versions, because their unique tags are different. You can use the configuration file to control the application to load the DLL you want to load correctly.

One bad thing about strong naming is deployment. If a strongly naming assembly is deployed and installed in GAC globally, if you want to deploy it on another computer, you cannot directly deploy it in xcopy mode. You must also copy the strongly-named assembly to the GAC on another computer.

Public Key, Public Key tag, Private Key

The public key accounts for 160 bytes in total, 32 bytes are header information, and 128 bytes are data. The Public Key is visible to program developers. Because the public key occupies 160 bytes, one assembly may reference many other assembly, so a large part of the space in the final generated file will be occupied by the public key, which is not convenient to use, as a result, the concept of public key tag is proposed. Public Key tag only occupies 8 bytes. The public key is used to hash the Public Key (using sha1Algorithm) To reverse the last eight bytes of the hash processing result. The public key tag is obtained. For details, see:Generate public key token from Public Key. The assemblyref table records the Public Key tag. What developers and end users see is the Public Key tag rather than the public key. However, in the generated assembly list, assemblydef records the entire public key instead of the eight-byte Public Key mark. CLR never uses public key tags when making security or trust decisions, because several public keys may get the same public key tag after being hashed. Private keys are invisible to common users.

You can directly use the command line tool provided by Vs to run Sn-t to view the public key of the Assembly. Note that T must be capitalized here, if it is in lower case, an error is reported, "the public key that failed to convert the key to mark -- Assembly" (null) "is invalid ". All commands of the SN tool are case sensitive.

Signature principles

The main principles are as follows: (for images and texts, refer to Chapter 3 of CLR via C #)

1. Hash the content of the PE file, and then use the private key to sign the RSA and add the signed value to the CLR header of the PE file. The Public Key is also added to the Assembly metadata.

2. When generating a metadata table fileref, CLR will also hash the files in the Assembly to get a hash value, and add the files and their corresponding hash values to the fileref metadata table at the same time,

Verification:

When this DLL is loaded by another user, the PE file is hashed to obtain a hash value, and then the RSA Digital Signature value is unsigned by the public key to obtain a value, if the two are the same, the contents of the file are not tampered. In addition, the system also performs hash processing on the file content in the program set, and compares the hash value with the hash value stored in the filedef table of the list file. If any hash value is different, it indicates that at least one file of the Assembly is tampered with and the Assembly cannot be installed to GAC.

Note: You can select different hash algorithms for file hashing. The default hash algorithm is sha1. However, when hashing the PE file content, the hash algorithm can only be sha1, it cannot be modified.

How to sign an assembly

There are two methods in vs to sign an assembly, one is to use project properties, the other is to add assemblykeyfile, and the following is to use assemblykeyfile:

When this method is used, VS has a warning that other methods are used to implement signatures. Therefore, Microsoft does not recommend this method.

Another way is to use Project Properties

On the signature tab, select "sign for assembly" and select the corresponding key file.

Both signatures generate a secret file first. You can use sn.exe to generate a secret file. For details, see:. Net tools (IV)-Sn. exe

Of course, when using the second method, you can also generate a key through the vs interface, such:

Select new in the drop-down box to generate a new key file.

Delayed Signature

If you want to generate a strongly-named assembly, you need to sign each time you create Chengdu. during development, you will frequently access private key files, which are generally very confidential, frequent use may cause some trouble. So there is a mechanism to delay the signature. Delayed signature means that in the development phase, only the public key is provided to developers. Only the public key signs the Assembly and uses the private key for signature at the end of packaging and publishing. You can use tool sn.exe to extract the public key from a key file. To delay the signature, you also need to tell the compiler that you want to delay the signature. If you use the C # compiler, you can set a delayed signature in the project properties.

Once the compiler detects that a delayed signature is required, it will record the public key of the Assembly in assemblydef when generating the configuration item. When generating the assembly, the generated PE file reserves space for the RSA digital signature. The file content will not be hashed at this time.

When installing GAC, an error is reported because the private key is not used for signature. If the installation is successful, you must cancel the system verification. After the formal signature, you must restart the system verification. To sign an assembly delay, perform the following steps:

1. Use sn.exe to generate a key file and use related commands to export the public key file;

2. Set project properties, check the "delayed signature" option, and select the corresponding public key file to sign the project delayed;

3. Use the-VR switch of Sn to tell the system not to verify the Assembly;

4. The Assembly can be successfully installed in GAC and can be referenced by other assembly. (But at this time, the Assembly has no real signature, and any assembly with the same name can overwrite it ).

5. Use the sn.exe-R command to sign the Assembly with the private key file;

6. Run the Sn-vu command to restart the verification of this Assembly;

7. The Assembly can be successfully installed in GAC.