Strong-Named assemblies, signing, delay signing

Strong-Named Assemblies

If an assembly has a unique tag, the assembly can be called a strong-named assembly. This unique token is generated by the public/private key encryption in the. NET Framework. A strong-named assembly contains four unique flags for the assembly's attributes: file name (without extension), version number, language culture information (if any), public key. This information is stored in the assembly's manifest (manifest). The manifest contains the assembly's metadata and is embedded in a file in 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"

Weakly Named Assemblies

In fact, there is no weak name of the assembly, but only for the strong naming of the assembly corresponding to a concept. A weakly named assembly is an assembly that does not have a unique tag, in fact, the structure of a strong assembly and a weak assembly is identical, that is, there is a unique identifier, and the latter does not. One difference between them is that a strong named assembly has a publisher's public/private key signature pair, which uniquely identifies the publisher of the Assembly

Advantages of strong naming

Because strong-Named assemblies use public/private key pairs for unique signatures, different corporate public/private key pairs cannot be the same, so the generated programs are not the same, which solves the previously old DLL Hell problem (two different companies may develop an assembly with the same name, if the program with the same name Set is placed in the same directory, an assembly overlay occurs, and the last assembly that is installed overwrites the previous assembly, which may cause the application to not function correctly. Any two strongly named assemblies, even if they are the same name, Windows knows they are two different versions because their unique tags are not the same. And you can use the config file to control the application to properly load the DLL you want to load.

One of the bad things about strong naming is the problem of deployment, if the strong-named assembly is deployed to the GAC in a global manner, if you want to deploy to another computer, you cannot deploy it directly in Xcopy, and you must copy the strong-named assembly to the GAC on the other computer.

Public key, public key token, private key

The public key accounts for 160 bytes, 32 bytes are header information, and 128 bytes of data are loaded. The public key is visible to the developer of the program. Because the public key accounts for 160 bytes, one assembly may refer to many other assemblies, so a large portion of the resulting file will be occupied by the public key, which is inconvenient when used, so a public key token concept is presented, and the public key token only accounts for 8 bytes. The public key token is a hash of the public key (using the SHA1 algorithm), which reverses the 8 bytes of the result of the hash, resulting in the public key token, as shown in the following: Generating the publicly key token fromthe publicly key. The public key token is recorded in the AssemblyRef table, and the developer and end user see the public key token, not the public key. However, in the resulting assembly manifest, AssemblyDef records the entire public key instead of the 8-byte public key token. The CLR never uses a public key token when making a security or trust decision because several public keys are hashed and may get the same public key token. Private keys are not visible to ordinary people.

You can run Sn–t to view the assembly's public key directly using the VS-bring command-line tool, note that the T is capitalized, and if it is lowercase, it will say "failed to convert key to token-assembly" (NULL) "Invalid public key". All commands for the SN tool are case-sensitive

The principle of signature

The main principles are: (Diagram and Text reference "CLR via C # chapter III")

1. Hash the contents of the PE file, then put the hashed value, the RSA signature with the private key, and add the signed value to the CLR header of the PE file. The public key is also added to the assembly's metadata.

2. When generating the metadata table FileRef, the CLR hashes the files in the Assembly, obtains a hash value, and adds the file and the corresponding hash value to the FILEREF metadata table.

When validating:

When the DLL is loaded on another user, the PE file is hashed, a hash is obtained, and the RSA digital signature value is de-signed with the public key, and a value is obtained if the two equals, the contents of the file are not tampered with. In addition, the system hashes the contents of the files in the assembly and compares the hashed values to the hashes stored in the FileDef table of the manifest file. Any one hash value is not the same, indicating that at least one file in the assembly has been tampered with and the assembly cannot be installed to the GAC.

Note: When hashing a file, you can choose a different hashing algorithm, default is SHA1, but the contents of the PE file is hashed, the hash algorithm can only be SHA1, cannot be modified.

How to sign an assembly

There are two ways to sign assemblies in VS, one through project properties and the other by adding AssemblyKeyFile, using AssemblyKeyFile as follows:

In this way, VS has a warning that the other way is to implement the signature, so Microsoft is not recommended in this way.

Another way is through project properties

On the Signatures tab, tick sign the assembly, and select the appropriate key file.

Both of these signature methods need to generate a good key file in advance, the key file can be generated with the Sn.exe tool, specifically see:. NET tool Chapter (iv)-SN. EXE

Of course, when using the second approach, you can also generate keys via the VS interface, such as:

Select New in the drop-down box to be reborn as a key file.

Delay signing

If a strong-named assembly is to be generated, each build needs to be signed, the private key file is accessed frequently during development, and the private key file is generally very confidential, and it may be a little cumbersome to use it frequently. So there is a mechanism for delaying signing. Delay signing means that in the development phase, only the public key is provided to the developer, only the public key is signed for the Assembly, and the private key is used for signing when the final package is released. You can use the tool Sn.exe to extract the public key from a key file. You also want to delay signing and tell the compiler that you want to delay signing. If you use the C # compiler, you can set a delay signature inside the project properties.

Once the compiler detects that a delay signature is required, when a clear item is generated, it logs the public key of the assembly in the AssemblyDef, and when the assembly is generated, the generated PE file reserves space for the RSA digital signature. The contents of the file are not hashed at this time.

When installed in the GAC, an error occurs because the private key is not signed. If you want to install successfully, you must cancel the system verification. After the formal signature, the system verification must be restarted. To delay signing an assembly, you have the following steps:

1. Generate a key file with Sn.exe and export the public key file using the relevant commands;

2. Set the project properties, tick the "Delay signature" option, and select the appropriate public key file to delay signing the project;

3. Use the SN-vr switch to tell the system not to validate the assembly;

4. The assembly can be successfully installed in the GAC and can be referenced by other assemblies. (The assembly does not have a true signature at this point, and any assembly with the same name can overwrite it).

5. When packing the release, use the SN.EXE–R command to formally sign the assembly with the private key file;

6. Restart the validation of this assembly using the SN–VU command;

7. The assembly can be successfully installed in the GAC

Strong-Named assemblies, signing, delay signing