1-10. Verify That a Strongly Named Assembly Has Not Been Modified

CHAPTER 1 ■ APPLICATION DEVELOPMENT



Strong Name tool to verify the strong name of the specified assembly, and the -f switch forces strong

name verification even if it has been previously disabled for the specified assembly. (You can disable

strong name verification for specific assemblies using the -Vr switch, as in sn -Vr Recipe01-09.exe; see

recipe 1-11 for details about why you would disable strong name verification.)



■ Tip You may need to start the command line with administrator privileges to use this tool, depending on the

configuration of your system. Right-click the Command Prompt item in the Start menu and select “Run as

administrator.”



If the assembly passes strong name verification, you will see the following output:

Microsoft (R) .NET Framework Strong Name Utility



Version 2.0.50727.42



Copyright (C) Microsoft Corporation. All rights reserved.



Assembly 'Recipe01-09.exe' is valid

However, if the assembly has been modified, you will see this message:

Microsoft (R) .NET Framework Strong Name Utility



Version 2.0.50727.42



Copyright (C) Microsoft Corporation. All rights reserved.



Failed to verify assembly -Strong name validation failed for assembly 'Recipe01-09.exe'.



1-11. Delay-Sign an Assembly

Problem

You need to create a strongly named assembly, but you don’t want to give all members of your

development team access to the private key component of your strongly named key pair.



24



CHAPTER 1 ■ APPLICATION DEVELOPMENT



Solution

Extract and distribute the public key component of your strongly named key pair. Follow the

instructions in recipe 1-9 that describe how to give your assembly a strong name. In addition, specify the

/delaysign switch when you compile your assembly. Disable strong name verification for the assembly

using the -Vr switch of the Strong Name tool (sn.exe).



■ Note If you are using Visual Studio, you can configure your strongly named assembly to be delay-signed by

opening the project properties, selecting the Signing tab, and checking the Delay Sign Only box.



How It Works

Assemblies that reference strongly named assemblies contain the public key token of the referenced

assemblies. This means the referenced assembly must be strongly named before it can be referenced. In

a development environment in which assemblies are regularly rebuilt, this would require every

developer and tester to have access to your strongly named key pair—a major security risk.

Instead of distributing the private key component of your strongly named key pair to all members of

the development team, the .NET Framework provides a mechanism called delay-signing, with which you

can partially strongly name an assembly. The partially strongly named assembly contains the public key

and the public key token (required by referencing assemblies) but contains only a placeholder for the

signature that would normally be generated using the private key.

After development is complete, the signing authority (who has responsibility for the security and

use of your strongly named key pair) re-signs the delay-signed assembly to complete its strong name.

The signature is calculated using the private key and embedded in the assembly, making the assembly

ready for distribution.

To delay-sign an assembly, you need access only to the public key component of your strongly

named key pair. No security risk is associated with distributing the public key, and the signing authority

should make the public key freely available to all developers. To extract the public key component from

a strongly named key file named MyKeyFile.snk and write it to a file named MyPublicKey.snk, use the

command sn -p MyKeyFile.snk MyPublicKey.snk. If you store your strongly named key pair in a CSP key

container named MyKeys, extract the public key to a file named MyPublicKey.snk using the command sn

-pc MyKeys MyPublicKey.snk.

Once you have a key file containing the public key, you build the delay-signed assembly using the

command-line C# compiler by specifying the /delaysign compiler switch. For example, to build a delaysigned assembly from a source file named Recipe01-11, use this command:

csc /delaysign /keyfile:MyPublicKey.snk Recipe01-11.cs

When the runtime tries to load a delay-signed assembly, the runtime will identify the assembly as

strongly named and will attempt to verify the assembly, as discussed in recipe 1-10. Because it doesn’t

have a digital signature, you must configure the runtime on the local machine to stop verifying the

assembly’s strong name using the command sn -Vr Recipe01-11.exe. Note that you need to do so on

every machine on which you want to run your application.



25



CHAPTER 1 ■ APPLICATION DEVELOPMENT



■ Tip When using delay-signed assemblies, it’s often useful to be able to compare different builds of the same

assembly to ensure they differ only by their signatures. This is possible only if a delay-signed assembly has been

re-signed using the -R switch of the Strong Name tool. To compare the two assemblies, use the command sn -D

assembly1 assembly2.



Once development is complete, you need to re-sign the assembly to complete the assembly’s strong

name. The Strong Name tool allows you to do this without changing your source code or recompiling the

assembly; however, you must have access to the private key component of the strongly named key pair.

To re-sign an assembly named Recipe01-11.exe with a key pair contained in the file MyKeys.snk, use the

command sn -R Recipe01-11.exe MyKeys.snk. If the keys are stored in a CSP key container named

MyKeys, use the command sn -Rc Recipe01-11.exe MyKeys.

Once you have re-signed the assembly, you should turn strong name verification for that assembly

back on using the -Vu switch of the Strong Name tool, as in sn -Vu Recipe01-11.exe. To enable

verification for all assemblies for which you have disabled strong name verification, use the command sn

-Vx. You can list the assemblies for which verification is disabled using the command sn -Vl.



■ Note If you are using the .NET Framework 1.0 or 1.1, the command-line C# compiler does not support the

/delaysign compiler switch. Instead, you must use the System.Reflection.AssemblyDelaySignAttribute

assembly-level attributes within your code to specify that you want the assembly delay-signed. Alternatively, use

the Assembly Linker tool (al.exe), which does support the /delaysign switch. Refer to the Assembly Linker

information in the .NET Framework SDK documentation for more details.



1-12. Sign an Assembly with an Authenticode Digital

Signature

Problem

You need to sign an assembly with Authenticode so that users of the assembly can be certain you are its

publisher and the assembly is unchanged after signing.



Solution

Use the Sign Tool (signtool.exe) to sign the assembly with your software publisher certificate (SPC).



26



CHAPTER 1 ■ APPLICATION DEVELOPMENT



How It Works

Strong names provide a unique identity for an assembly as well as proof of the assembly’s integrity, but

they provide no proof as to the publisher of the assembly. The .NET Framework allows you to use

Authenticode technology to sign your assemblies. This enables consumers of your assemblies to confirm

that you are the publisher, as well as confirm the integrity of the assembly. Authenticode signatures also

act as evidence for the signed assembly, which people can use when configuring code access security

policy.

To sign your assembly with an Authenticode signature, you need an SPC issued by a recognized

certificate authority (CA). A CA is a company entrusted to issue SPCs (along with many other types of

certificates) for use by individuals or companies. Before issuing a certificate, the CA is responsible for

confirming that the requesters are who they claim to be and also for making sure the requestors sign

contracts to ensure they don’t misuse the certificates that the CA issues them.

To obtain an SPC, you should view the Microsoft Root Certificate Program Members list at

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/

rootcertprog.asp. Here you will find a list of CAs, many of whom can issue you an SPC. For testing

purposes, you can create a test certificate using the process described in recipe 1-13. However, you can’t

distribute your software signed with this test certificate. Because a test SPC isn’t issued by a trusted CA,

most responsible users won’t trust assemblies signed with it.

Some CAs will issue your SPC as a Personal Information Exchange file, which has a .pfx suffix—this

is the file format that is needed to sign an assembly. Some CAs, however, will issue you with two files

(either a private key file (.pvk) and an SPC (.spc) file or a private key file and a certificate file (with a .cer

suffix)—if this is the case, you will have to convert your files to the PFX format—see the following usage

details for instructions.

Once you have a PFX file, you use the Sign Tool to Authenticode-sign your assembly. The Sign Tool

creates a digital signature of the assembly using the private key component of your SPC and embeds the

signature and the public part of your SPC in your assembly (including your public key). When verifying

your assembly, the consumer decrypts the encrypted hash code using your public key, recalculates the

hash of the assembly, and compares the two hash codes to ensure they are the same. As long as the two

hash codes match, the consumer can be certain that you signed the assembly and that it has not

changed since you signed it.



Usage

If your CA has not issued you with a Personal Information Exchange (PFX) file, then the first step is to

convert your certificate to the correct format using the pnk2pfx.exe tool. If you have received a PVK file

and a CER file, then you should type the following at the command prompt:

pvk2pfx -pvk MyPrivateKey.pvk -spc MyCertificate.cer -pfx MyCertificate.pfx

If you have received a PVK file and an SPC file, then type the following command:

pvk2pfx -pvk MyPrivateKey.pvk -spc MyCertificate.spc -pfx MyCertificate.pfx

Both of these commands create the MyCertificate.pfx file. To sign an assembly, you type the

following command at the command prompt:

signtool sign –f MyCertificate.pfx MyAssembly.exe



27