Create and Manage Strong-Named Key Pairs in C#

To generate a new key pair and store them in the file named MyKeys.snk, execute the command sn -k MyKeys.snk. (.snk is the usual extension given to files containing strong name keys.) The generated file contains both your public and private keys. You can view the public key using the command sn -tp MyKeys.snk, which will generate output similar to the (abbreviated) listing shown here.

Microsoft (R) .NET Framework Strong Name Utility  Version 1.1.4322.573Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.Public key is07020000002400005253413200040000010001002b4ef3c2bbd6478802b64d0dd3f2e7c65ee;<$VE>6478802b63cb894a782f3a1adbb46d3ee5ec5577e7dccc818937e964cbe997c12076c19f2d7ad179f15f7dccca6c6b72aPublic key token is 2a1d3326445fc02a

The public key token shown at the end of the listing is the last 8 bytes of a cryptographic hash code computed from the public key. Because the public key is so long, .NET uses the public key token for display purposes and as a compact mechanism for other assemblies to reference your public key.

As the name suggests, you don't need to keep the public key (or public key token) secret. When you strong name your assembly , the compiler uses your private key to generate a digital signature (an encrypted hash code) of the assembly's manifest. The compiler embeds the digital signature and your public key in the assembly so that any consumer of the assembly can verify the digital signature.

Keeping your private key secret is imperative. People with access to your private key can alter your assembly and create a new strong name—leaving your customers unaware that they are using modified code. There's no mechanism to repudiate compromised strong name keys. If your private key is compromised, you must generate new keys and distribute new versions of your assemblies that are strong named using the new keys. You must also notify your customers about the compromised keys and explain to them which versions of your public key to trust—in all, a very costly exercise in terms of both money and credibility. There are many ways to protect your private key; the approach you use will depend on factors such as

• The structure and size of your organization.
• Your development and release process.
• The software and hardware resources you have available.
• The requirements of your customer base.

  Tip

  Commonly, a small group of trusted individuals (the signing authority) has responsibility for the security of your company's strong name signing keys and is responsible for signing all assemblies just prior to their final release. The ability to delay sign an assembly facilitates this model and avoids the need to distribute private keys to all development team members.

One feature provided by the Strong Name tool to simplify the security of strong name keys is the use of CSP key containers. Once you have generated a key pair to a file, you can install the keys into a key container and delete the file. For example, to store the key pair contained in the file MyKeys.snk to a CSP container named StrongNameKeys, use the command sn -i MyKeys.snk StrongNameKeys.

An important aspect of CSP key containers is the fact that there are user- based containers and machine-based containers. Windows security ensures each user can access only their own user-based key containers. However, any user of a machine can access a machine-based container.

By default, the Strong Name tool uses machine-based key containers, meaning that anybody who can log on to your machine and who knows the name of your key container can sign an assembly with your strong name keys. To change the Strong Name tool to use user-based containers, use the command sn -m n, and to change back to machine-based stores, use the command sn -m y. The command sn -m will display whether the Strong Name tool is currently configured to use machine-based or user-based containers.

To delete the strong name keys from the StrongNameKeys container (as well as the container), use the command sn -d StrongNameKeys.