Strong Names

An assembly strong name consists of a text name , a version number, optionally a culture, a public key (which often represents your development organization), and a digital signature. You can see the various components of the strong name by looking into Machine.config and seeing how a strong named assembly is referenced.

The following example shows how the System.Web assembly is referenced in Machine.config. In this example, the assembly attribute shows the text name, version, culture and public key token, which is a shortened form of the public key.

 <add assembly="System.Web, Version=1.0.5000.0, Culture=neutral,                PublicKeyToken=b03f5f7f11d50a3a" />

Whether or not you should strong name an assembly depends on the way in which you intend it to be used. The main reasons for wanting to add a strong name to an assembly include:

You want to ensure that partially trusted code is not able to call your assembly.

The common language runtime prevents partially trusted code from calling a strong named assembly, by adding link demands for the FullTrust permission set. You can override this behavior by using AllowPartiallyTrustedCallersAttribute (APTCA) although you should do so with caution.

For more information about APTCA, see APTCA in Chapter 8, "Code Access Security in Practice."
The assembly is designed to be shared among multiple applications.

In this case, the assembly should be installed in the global assembly cache. This requires a strong name. The global assembly cache supports side-by-side versioning which allows different applications to bind to different versions of the same assembly.
You want to use the strong name as security evidence.

The public key portion of the strong name gives cryptographically strong evidence for code access security. You can use the strong name to uniquely identify the assembly when you configure code access security policy to grant the assembly specific code access permissions. Other forms of cryptographically strong evidence include the Authenticode signature (if you have used X.509 certificates to sign the assembly) and an assembly's hash.

Note
Authenticode evidence is not loaded by the ASP.NET host, which means you cannot use it to establish security policy for ASP.NET Web applications.

For more information about evidence types and code access security, see Chapter 8, "Code Access Security in Practice."

Security Benefits of Strong Names

Strong names provide a number of security advantages in addition to versioning benefits:

Strong named assemblies are signed with a digital signature. This protects the assembly from modification. Any tampering causes the verification process that occurs at assembly load time to fail. An exception is generated and the assembly is not loaded.
Strong named assemblies cannot be called by partially trusted code, unless you specifically add AllowPartiallyTrustedCallersAttribute (APTCA.)

Note
If you do use APTCA, make sure you read Chapter 8, "Code Access Security in Practice," for additional guidelines to further improve the security of your assemblies.
Strong names provide cryptographically strong evidence for code access security policy evaluation. This allows administrators to grant permissions to specific assemblies. It also allows developers to use a StrongNameIdentityPermission to restrict which code can call a public member or derive from a non-sealed class.

Using Strong Names

The .NET Framework includes the Sn.exe utility to help you strong name assemblies. You do not need an X.509 certificate to add a strong name to an assembly.

Task To strong name an assembly

Generate the key file in the assembly's project directory by using the following command.
```
 sn.exe -k keypair.snk 
```
Add an AssemblyKeyFile attribute to Assemblyinfo.cs to reference the generated key file, as shown in the following code sample.
```
 // The keypair file is usually placed in the project directory [assembly: AssemblyKeyFile(@"..\..\keypair.snk")] 
```

Delay Signing

It is good security practice to delay sign your assemblies during application development. This results in the public key being placed in the assembly, which means that it is available as evidence to code access security policy, but the assembly is not signed, and as a result is not yet tamper proof. From a security perspective, delay signing has two main advantages:

The private key used to sign the assembly and create its digital signature is held securely in a central location. The key is only accessible by a few trusted personnel. As a result, the chance of the private key being compromised is significantly reduced.
A single public key, which can be used to represent the development organization or publisher of the software, is used by all members of the development team, instead of each developer using his or her own public, private key pair, typically generated by the sn “k command.

Task To create a public key file for delay signing

This procedure is performed by the signing authority to create a public key file that developers can use to delay sign their assemblies.

Create a key pair for your organization.
```
 sn.exe -k keypair.snk 
```
Extract the public key from the key pair file.
```
 sn p keypair.snk publickey.snk 
```
Secure Keypair.snk, which contains both the private and public keys. For example, put it on a floppy or CD and physically secure it.
Make Publickey.snk available to all developers. For example, put it on a network share.

Task To delay sign an assembly

This procedure is performed by developers.

Add an assembly level attribute to reference the key file that contains only the public key.

 // The keypair file is usually placed in the project directory [assembly: AssemblyKeyFile(@"..\..\publickey.snk")]

Add the following attribute to indicate delay signing.
```
 [assembly: AssemblyDelaySign(true)] 
```
The delay signing process and the absence of an assembly signature means that the assembly will fail verification at load time. To work around this, use the following commands on development and test computers.
- To disable verification for a specific assembly, use the following command.
```
 sn -Vr assembly.dll 
```
- To disable verification for all assemblies with a particular public key, use the following command.
```
 sn -Vr *,publickeytoken 
```
- To extract the public key and key token (a truncated hash of the public key), use the following command.
```
 sn -Tp assembly.dll 
```
Note
Use a capital “T switch.
To fully complete the signing process and create a digital signature to make the assembly tamper proof, execute the following command. This requires the private key and as a result the operation is normally performed as part of the formal build/release process.
```
 sn -r assembly.dll keypair.snk 
```

ASP.NET and Strong Names

At the time of this writing, it is not possible to use a strong name for an ASP.NET Web page assembly because of the way it is dynamically compiled. Even if you use a code-behind file to create a precompiled assembly that contains your page class implementation code, ASP.NET dynamically creates and compiles a class that contains your page's visual elements. This class derives from your page class, which again means that you cannot use strong names.

Note	You can strong name any other assembly that is called by your Web page code, for example an assembly that contains resource access, data access or business logic code, although the assembly must be placed in the global assembly cache.

Global Assembly Cache Requirements

Any strong named assembly called by an ASP.NET Web application configured for partial trust should be installed in the global assembly cache. This is because the ASP.NET host loads all strong-named assemblies as domain-neutral .

The code of a domain-neutral assembly is shared by all application domains in the ASP.NET process. This creates problems if a single strong named assembly is used by multiple Web applications and each application grants it varying permissions or if the permission grant varies between application domain restarts. In this situation, you may see the following error message: "Assembly <assembly>.dll security permission grant set is incompatible between appdomains."

To avoid this error, you must place strong named assemblies in the global assembly cache and not in the application's private \bin directory.

Authenticode vs. Strong Names

Authenticode and strong names provide two different ways to digitally sign an assembly. Authenticode enables you to sign an assembly using an X.509 certificate. To do so, you use the Signcode.exe utility, which adds the public key part of a full X.509 certificate to the assembly. This ensures trust through certificate chains and certificate authorities. With Authenticode (unlike strong names,) the implementation of publisher trust is complex and involves network communication during the verification of publisher identity.

Authenticode signatures and strong names were developed to solve separate problems and you should not confuse them. Specifically:

A strong name uniquely identifies an assembly.
An Authenticode signature uniquely identifies a code publisher.

Authenticode signatures should be used for mobile code, such as controls and executables downloaded via Internet Explorer, to provide publisher trust and integrity.

You can configure code access security (CAS) policy using both strong names and Authenticode signatures in order to grant permissions to specific assemblies. However, the Publisher evidence object, obtained from an Authenticode signature is only created by the Internet Explorer host and not by the ASP.NET host. Therefore, on the server side, you cannot use an Authenticode signature to identify a specific assembly (through a code group .) Use strong names instead.

For more information about CAS, CAS policy and code groups, see Chapter 8, "Code Access Security in Practice."

Table 7.1 compares the features of strong names and Authenticode signatures.

Table 7.1: A Comparison of Strong Names and Authenticode Signatures
Feature	Strong Name	Authenticode
Unique identification of assembly	Yes	No
Unique identification of publisher	Not necessarily . Depends on assembly developer using a public key to represent the publisher	Yes
The public key of the publisher can be revoked	No	Yes
Versioning	Yes	No
Namespace and type name uniqueness	Yes	No
Integrity (checks assembly has not been tampered with)	Yes	Yes
Evidence used as input to CAS policy	Yes	IE host ” Yes
ASP.NET host ” No
User input required for trust decision	No	Yes (pop-up dialog box)