Assemblies Should Be Strong-Named

Names are a weak form of authentication or evidence. If someone you didn't know gave you a file on a CD containing a file named excel.exe, would you blindly run it? You probably would if you needed a spreadsheet, because you'd think the file would be Microsoft Excel. But how do you really know it is Microsoft Excel? .NET solves this spoofing problem by providing strong names that consist of the file's simple text name, version number, and culture information plus a public key and a digital signature.

To create a strong name, you must create a strong name key pair by using the sn.exe tool. The syntax for creating a key pair is SN -k keypair.snk. The resulting file contains a private and public key used to sign and verify signed assemblies. (I'm not going to explain asymmetric encryption; refer to the cryptography books in this book's bibliography for more information.) If this key pair is more than an experimental key, you should protect it like any other private/public key pair jealously.

Note that the strong name is based on the key pair itself, not on a certificate as with Authenticode. As a developer, you can create the key pair that defines your own private namespace; others cannot use your namespace because they don't know the private key. You can additionally get a certificate for this key pair if you like, but the strong-name identity does not use certificates. This means that the signature cannot be identified with the name of the publisher, although you do know that the same publisher is controlling all strong names of a certain key pair, assuming the private key is kept private.

In addition to using strong names, you may want to Authenticode-sign an assembly in order to identify the publisher. To do so, you must first strong-name-sign the assembly and then Authenticode-sign over that. You cannot use Authenticode first because the strong-name signature will appear as tampering to the Authenticode signature check.

IMPORTANT
Unlike certificates, strong-name private keys cannot be revoked, so you must take precautions to protect the keys. Consider declaring one trusted individual to be the keymaster, the person who keeps the private key on a floppy in her safe.

NOTE
Presently, strong names use 1024-bit RSA keys.

You should next extract the public-key portion of the key pair with SN -p keypair.snk public.snk. You'll see why this is important in a moment. The signing process happens only when the code is compiled and the binary is created, and you reference the key information by using an [assembly: AssemblyKeyFile(filename)] directive. In the case of a default Visual Studio .NET application, this directive is in the AssemblyInfo.cs or AssemblyInfo.vb file, and it looks like this in a Visual Basic .NET application:

Imports System.Reflection <Assembly: AssemblyKeyFileAttribute("c:\keys\keypair.snk")>

You should realize that such an operation could potentially leave the private key vulnerable to information disclosure from a bad developer. To mitigate this risk, you can use delay-signing, which uses only the public key and not the private/public key pair. Now the developers do not have access to the private key, and the full signing process occurs prior to shipping the code using SN -R assemblyname.dll keypair.snk command. However, your development computers must bypass signature verification by using the SN -Vr assemblyname.dll command because the assembly does not have a strong name.

IMPORTANT
Keep in mind that strong-named assemblies can reference only other strong-named assemblies.

Enforcing delay-signing requires that you add the following line to the assembly in Visual Basic .NET:

<Assembly: AssemblyDelaySignAttribute(true)>

Or in C#, this line:

[assembly: AssemblyDelaySign(true)]

Note that in C# you can drop the Attribute portion of the name.

TIP
Developers performing day-to-day development on the assembly should always delay-sign it with the public key.

Strong-Named Assemblies and ASP.NET

Strong-named assemblies used for business logic in Web applications must be stored in the server's global assembly cache (GAC) by using the .NET Configuration tool (Mscorcfg.msc) or gacutil.exe. This is because of the way that ASP.NET loads signed code.

Now let's look at permissions and permission request best practices.