Nbsp;   Delayed Signing

Earlier in this chapter, I discussed how the SN.exe tool can produce public/private key pairs. This tool generates the keys by making calls into the Crypto API provided by Windows. These keys can be stored in files or other storage devices. For example, large organizations (such as Microsoft) will

maintain the returned private key in a hardware device that stays locked in a vault; only a few people in the company have access to the private key. This precaution prevents the private key from being compromised and ensures the key’s integrity. The public key is, well, public and freely distributed.

When you’re ready to package your strongly named assembly, you’ll have to use the secure private key to sign it. However, while developing and testing your assembly, gaining access to the secure private key can be a hassle. For this reason, the .NET Framework supports delayed signing, sometimes referred to as partial signing. Delayed signing allows you to build an assembly by using only your com- pany’s public key; the private key isn’t necessary. Using the public key allows assemblies that reference your assembly to embed the correct public key value in their AssemblyRef metadata entries. It also al- lows the assembly to be placed in the GAC appropriately. If you don’t sign the file with your company’s private key, you lose all of the tampering protection afforded to you because the assembly’s files won’t be hashed, and a digital signature won’t be embedded in the file. This loss of protection shouldn’t be

a problem, however, because you use delayed signing only while developing your own assembly, not when you’re ready to package and deploy the assembly.

Basically, you get your company’s public key value in a file and pass the file name to whatever

utility you use to build the assembly. (As I have shown earlier in this chapter, you can use SN.exe’s

–p switch to extract a public key from a file that contains a public/private key pair.) You must also tell the tool that you want the assembly to be delay signed, meaning that you’re not supplying a private key. For the C# compiler, you do this by specifying the /delaysign compiler switch. In Visual Studio, you display the properties for your project, click the Signing tab, and then select the Delay Sign Only check box. If you’re using AL.exe, you can specify the /delay[sign] command- line switch.

When the compiler or AL.exe detects that you’re delay signing an assembly, it will emit the assem- bly’s AssemblyDef manifest entry, which will contain the assembly’s public key. Again, the presence of the public key allows the assembly to be placed in the GAC. It also allows you to build other assem- blies that reference this assembly; the referencing assemblies will have the correct public key in their AssemblyRef metadata table entries. When creating the resulting assembly, space is left in the result- ing PE file for the RSA digital signature. (The utility can determine how much space is necessary from the size of the public key.) Note that the file’s contents won’t be hashed at this time either.

At this point, the resulting assembly doesn’t have a valid signature. Attempting to install the as- sembly into the GAC will fail because a hash of the file’s contents hasn’t been done—the file appears to have been tampered with. On every machine on which the assembly needs to be installed into the GAC, you must prevent the system from verifying the integrity of the assembly’s files. To do

this, you use the SN.exe utility, specifying the –Vr command-line switch. Executing SN.exe with this switch also tells the CLR to skip checking hash values for any of the assembly’s files when loaded at run time. Internally, SN’s –Vr switch adds the assembly’s identity under the following registry subkey: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\StrongName\Verification.

When you’re finished developing and testing the assembly, you need to officially sign it so that

you can package and deploy it. To sign the assembly, use the SN.exe utility again, this time with the

–R switch and the name of the file that contains the actual private key. The –R switch causes SN.exe to hash the file’s contents, sign it with the private key, and embed the RSA digital signature in the file where the space for it had previously been reserved. After this step, you can deploy the fully signed assembly. On the developing and testing machines, don’t forget to turn verification of this assembly back on by using SN.exe’s –Vu or –Vx command-line switch.

The following list summarizes the steps discussed in this section to develop your assembly by using the delayed signing technique:

1.While developing an assembly, obtain a file that contains only your company’s public key, and

compile your assembly by using the /keyfile and /delaysign compiler switches.

csc /keyfile:MyCompany.PublicKey /delaysign MyAssembly.cs

2.After building the assembly, execute the following line so that the CLR will trust the assembly’s bytes without performing the hash and comparison. This allows you to install the assembly in the GAC (if you desire). Now, you can build other assemblies that reference the assembly, and you can test the assembly. Note that you have to execute the following command line only once per machine; it’s not necessary to perform this step each time you build your assembly.

SN.exe –Vr MyAssembly.dll

3.When ready to package and deploy the assembly, obtain your company’s private key, and then execute the following line. You can install this new version in the GAC if you desire, but don’t attempt to install it in the GAC until executing step 4.

SN.exe ­Ra MyAssembly.dll MyCompany.PrivateKey

4.To test in real conditions, turn verification back on by executing the following command line.

SN.exe –Vu MyAssembly.dll

At the beginning of this section, I mentioned how organizations keep their key pairs in a hardware device such as a smart card. To keep these keys secure, you must make sure that the key values are never persisted in a disk file. Cryptographic service providers (CSPs) offer containers that abstract the location of these keys. Microsoft, for example, uses a CSP that has a container that, when accessed, obtains the private key from a hardware device.

If your public/private key pair is in a CSP container, you’ll have to specify different switches to the CSC.exe, AL.exe, and SN.exe programs: When compiling (CSC.exe), specify the /keycontainer switch instead of the /keyfile switch; when linking (AL.exe), specify its /keyname switch instead of its /keyfile switch; and when using the Strong Name program (SN.exe) to add a private key to a delay-signed assembly, specify the –Rc switch instead of the –R switch. SN.exe offers additional switches that allow you to perform operations with a CSP.

Date: 2016-03-03; view: 631