Administering the Cryptographic Settings

One of the biggest problems you’ll ever experience with cryptographic techniques is that someone will forget their password. (An employee’s sudden death or departure from the company are also things to consider and just as problematic as forgetting the password.) Forgetting the password makes the data inaccessible unless you know how to crack the cipher, in which case, the cryptographic technique is useless anyway. Unfortunately, this problem isn’t small or isolated to a few individuals. There’s a booming market of vendors who can recover your Office documents after you lose the password used to encrypt them. Office is just one of many examples. Consequently, your first administrative task is to ensure that any cryptographic method you use is not only safe but also reversible. Usually this means retaining some type of database of account statistics in a safe (locked) location that you use only in emergencies. Many organizations call this an escrow account.

In addition to user-related administrative tasks, you may need to perform a number of other cryptographic-related tasks, such as managing the authorization store or creating certificates for your organization. The following sections look at a number of configuration tasks you should know about. At the very least, you’ll want to know how to manage cryptographic classes to obtain maximum effect.

Using the Certification Authority Utility

A digital certificate is a series of numbers forming an identity that acts as a key to lock and unlock files, identify a particular individual or company, and perform other cryptographic tasks. It’s more secure than the public/private key combination generated by the Strong Name utility (SN.EXE). The “StrongName versus Publisher Evidence” sidebar in Chapter 4 provides an overview of digital certificate issues. The “Circumventing and Fixing the Standard Check” section of Chapter 6 describes some of the problems in using a public/private key pair for code verification. In general, the public/private key pair is more secure than using nothing at all, but you can’t verify the source of the key easily, nor can you validate that the code has permission to run on the host machine without a lot of extra work, such as using a hash as was shown in Chapter 6.

Many organizations do make use of third-party Certificate Authorities (CAs) to obtain digital certificates for signing their code. This is always the best approach if you intend to make your code available to third parties that don’t know you or your organization. For example, this is the approach you should use when developing shrink-wrap software. However, this approach isn’t necessarily cost effective for an organization that plans to send its software to a few trusted partners who know the developer well. In this case, using the CA built into server operating systems such as Windows 2000 Server or the newer Windows 2003 Server is a less expensive alternative.

The following sections provide some configuration tips developers can use to ensure that a stand-alone or enterprise CA works efficiently for in-house applications. In addition, this section describes techniques for generating your own certificates for use in code signing. This task is especially important in cryptographic applications where trust is everything.

(While it might be tempting to say that trust is only one piece of a greater whole, the greater whole doesn’t matter much if you don’t trust the individual or organization in the first place.)

Note

The CA setup for the following sections is a Windows 2000 server with all the latest patches and an enterprise CA installed. Your browser views will vary from the ones shown if you use a non-patched version of Windows 2000 or a stand-alone CA. Some of the options mentioned in the following sections aren’t available to systems that lack Active Directory support or if you perform the setup using a server that isn’t a domain controller. However, even with these differences, the basic concepts are the same. You still need to obtain a code-signing certificate using the server options that you do have available.

Viewing the CA Configuration

The Certification Authority Microsoft Management Console (MMC) shown in Figure 7.1 provides the means to monitor your CA setup. You won’t generally use this utility to perform configuration tasks.

Figure 7.1: Use the Certificate Authority console to view your certificates.

The first four folders contain certification information. Revoked certificates include those that someone has compromised or have expired because you didn’t renew them. The Issued Certificates folder contains a list of certificates the system has issued and who has them. The Pending Requests folder contains a list of certificates that require approval. If you set up your system to use the default settings, this folder should be empty (except for momentary entries during an initial request). The presence of entries in the Failed Requests folder requires further investigation. When you set your CA up correctly, a certificate request from an authorized user should pass, which means that these entries normally show requests from those who lack authorization.

Of the four folders, the Issued Certificates folder is the most important. When you want to revoke an existing certificate, locate the certificate in this folder, right-click the certificate, and choose Revoke from the context menu. This folder also lets you look at the certificate by double-clicking its entry. The Certificate dialog box lets you verify the status of the certificate and the period the certificate is valid. You can also view details such as the type of public key and the issuing authority.

A quick look at the Policy Settings folder holds the promise of actually making some kind of CA change. The truth is that these entries tell you which settings are in place. However, the information is useful for making quick checks and lets you track information without exposing the information to potential change. You can use the information you see to make quick decisions. For example, double-click the Administrator entry and you’ll learn that this certificate is useful for signing code.

You must perform an important developer task before going any further. Notice that most of the default certificates lack any kind of code-signing capability, with the exception of the Administrator certificate. Unfortunately, you want a code-signing certificate and it may not be such a good idea to give every programmer in your organization an Administrator certificate. Use the following steps to create a Code Signing certificate type.

1. Right-click Policy Settings and choose the New>Certificate to Issue option on the context menu. You’ll see a Select Certificate Template dialog box.

2. Highlight the Code Signing option and Click OK. The Certificate Authority console adds the new policy to the list.

Making CA Configuration Changes

When you want to make a change in the CA setup, you need to use the Active Directory Users and Computers console shown in Figure 7.2. Most CA changes involve policies used to manage the certificate. In addition, you can control the distribution of certificates.

Figure 7.2: Use the Active Directory Users and Computers console to configure the CA.

The second configuration process is the most important to a developer because any code you distribute using a certificate must be trusted on the client machine—this requirement means getting the certificate to all client machines. The following steps show how to get your CA set up to distribute the root certificate (the basis for all trust) automatically.

1. Right-click the domain entry (DataCon.domain in Figure 7.2) and choose Properties from the context menu. You’ll see a domain Properties dialog box.

2. Select the Group Policy tab (see Figure 7.3). Highlight the Default Domain Policy entry and click Edit. You’ll see the Group Policy dialog box.

   
   Figure 7.3: Select the Default Domain Policy entry.

3. Right-click Automatic Certificate Request Settings and choose New>Automatic Certificate Request. You’ll see the Automatic Certificate Request Settings Wizard.

4. Click Next. You’ll see the Certificate Template dialog box shown in Figure 7.5. The list in Figure 7.5 is generic. You can import additional entries into this list using the Import option of the Trusted Root Certification Authorities or Enterprise Trust entry of the Group Policies dialog box.

   
   Figure 7.4: Choose the Automatic Certificate Request Settings entry.

   
   Figure 7.5: Highlight the certificate you want to install automatically.

5. Select the certificate that you want to install, and then click Next.

6. Click Finish. The Wizard adds the certificate to the list shown in Figure 7.4.

Getting Your Own Certificate

At some point, you’ll want your own certificate to use for programming needs. A certificate store identifies the issuing authority, making it a lot more difficult for someone to forge a key using the technique shown in the “Circumventing and Fixing the Standard Check” section of Chapter 6. The easiest way to obtain a certificate is to use your browser. The following steps show how.

1. Open your browser and access the certificate server using an URL similar to http://YourServerName/CertSrv/Default.asp. (The URL you type very likely points to your company’s intranet site, rather than a location on the Internet.) Make sure your browser has scripting and cookies enabled (it probably will). You’ll see the initial Microsoft Certificate Services Web site.

2. Select the Request a Certificate option, and click Next. You’ll see a Choose Request Type screen. This is where knowledge of the various policies in the Policy Settings folder of the Certificate Authority console is helpful. Notice that the only entry is a User certificate. Double-click the User entry in the Policy Settings folder and you’ll see a User Properties dialog box similar to the one shown in Figure 7.6. Notice that the User certificate doesn’t include code signing. Consequently, this certificate would be useless for a developer.

   
   Figure 7.6: Selecting the User certificate is useless for a developer.

3. Choose the Advanced Request option and click Next. You’ll see an Advanced Certificate Requests screen. Because you probably don’t have a smart card or an existing certificate, you’ll need to choose the first (default) option of filling out a form.

4. Click Next. The Web server will tell you that it’s downloading an ActiveX Control to your system. Be patient; the download can take a considerable amount of time even on a high-speed network. After some time, you’ll see the form shown in Figure 7.7. This is where you fill in the requirements for your certificate.

   
   Figure 7.7: Wait for the ActiveX Control to download so you can see this form.

5. Select the Code Signing option in the Certificate Template field.

6. Select a Cryptographic Service Provider (CSP) from the list in the CSP field. One of the best choices is the Microsoft Strong Cryptographic Provider, but even the Microsoft Base Cryptographic Provider 1.0 works well. The various CSPs feature different options such as key length. A longer key makes the key harder to break but can also increase some factors such as code size.

7. Set the Key Usage option to Both so that you can use the Code Signing key for both needs.

8. Set the Key Size. A larger key is more secure, while a smaller key is more efficient. The minimum key size you should consider for code is 1,024, but some CSPs offer keys up to 16,384 bits in length. If your security needs are exceptional, you should also check the Enable Strong Private Key Protection option.

9. Check the Mark Keys as Exportable option. This check enables the Export Keys to File option. Check this option as well and type the name of a file in the File Name field. This step is essential because it gives you a physical key you can use as input to Visual Studio.

10. Select a Hash Algorithm option. Pay careful attention to this step. You must select one of the options that Visual Studio supports such as Secure Hashing Algorithm 1 (SHA-1) or Message Digest 5 (MD5). Don’t select options such as MD2 or MD4 because you’ll run into problems getting them to work right.

11. Click Submit. Internet Explorer will display a Generating Request message for a moment, and then you’ll see a Create Private Key Password dialog box.

12. Type a password in the Password field, and again in the Confirm Password field. Click OK. Internet Explorer will display a success message.

Managing the Cryptographic Classes

You might not think that you have to do anything with the existing cryptographic classes. In most cases, you don’t. However, you can manage the classes to produce better (or at least different) results. The following sections describe some techniques you can use to manage the cryptographic classes so that you can obtain the results you need using the least amount of code.

Deciding Which Cryptographic Object Creation Method to Use

The .NET Framework actually provides four distinct methods for creating cryptographic objects. All four methods result in the same cryptographic object, so there’s no reason to use one method over another for purely result motives. However, personal taste, availability of resources, self-documentation, and efficiency of coding do play a part in the selection. Here are the four choices:

Use the New Operator This is the easiest method of creating a cryptographic object and the one that most developers know. Using the New operator will guarantee that anyone reading your code will understand your code. The disadvantage is that this method isn’t flexible. You must create a specific object that relies on a specific cryptographic technology. For example, you couldn’t substitute the MD5 technique for the SHA-1 technique because this method won’t handle that kind of change.

Use the Abstract Class Create() Method This method requires slightly more work than using a specific provider. For example, instead of using the DESCryptoServiceProvider class, you’d use the Data Encryption Standard (DES) class. The advantage of using this method is that you can specify a particular DES encryption methodology, rather than use the default Cryptographic Service Provider (CSP). So, even though the code is slightly harder to read, you can use this method to extend the functionality that the .NET Framework provides.

Use the CryptoConfig.CreateFromName() Method The System.Security.Cryptography namespace contains the CryptoConfig class. Because the .NET Framework doesn’t attach this class to any particular cryptographic method such as MD5, SHA-1, or DES, you can use it to create any of these objects. This means the same code could work with any of the standard cryptographic methods as long as you code carefully. This particular method also supports algorithm mapping (described in the “Using Configuration Files to Map Algorithm Names” section). Algorithm mapping lets you change the result of a method call based on the content of a configuration file.

Use the Create() Method of an Abstract Class that Implements a Class of Cryptographic Algorithms Use this method when you need maximum flexibility and coding efficiency isn’t necessarily a concern. To use this technique, you create an object using the Create() method of a high-level cryptographic class such as the System.Security .Cryptography.SymmetricAlgorithm class. The resulting object provides access to all of the cryptographic methods supported by the master class. For example, the SymmetricAlgorithm class supports the DES, Ron’s Code 2 (RC2), Rijndael, and Triple DES methods. This technique also supports algorithm mapping (described in the “Using Configuration Files to Map Algorithm Names” section).

Using Configuration Files to Map Algorithm Names

Algorithm mapping is the process you use to change the result of a call to specific cryptography classes. Normally the DES.Create() and CryptoConfig.CreateFromName(“DES”) method calls produce a DESCryptoServiceProvider object as output. However, you can change the system to output another cryptographic object by modifying the settings in the Machine.Config file. For example, you may want to use a third party CSP in place of the CSP provided by Microsoft. You can create this mapping so that your existing code also uses the new CSP without any changes. In short, the change modifies your code to use an updated CSP.

Note

You can find the Machine.Config file in the \WINDOWS\Microsoft.NET\Framework\ <Version>\CONFIG folder. The examples in this section rely on the contents of the \WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG folder.

The Machine.Config file is XML-based. This format means that you use tags to identify major sections, elements to hold data, and attributes to modify the meanings of the tags. Here’s an example of an entry that modifies the DES.Create() and CryptoConfig.CreateFromName(“DES”) methods. Listing 7.1 shows a typical mapping entry.

Listing 7.1: Mapping an Algorithm to a Class

<configuration> <!-- Bunches of other entries -->    <mscorlib>       <cryptographySettings>          <cryptoNameMapping>             <cryptoClasses>                <cryptoClass ThirdPartyDES="ThirdPartyDESClass,                             ThirdPartyDESAssembly,                             Culture=’en’,                             PublicKeyToken=1234567890123456,                             Version=1.0.0.0"/>             </cryptoClasses>             <nameEntry name="DES"                        />             <nameEntry name="System.Security.Cryptography.DES"                        />          </cryptoNameMapping>       </cryptographySettings>    </mscorlib> </configuration>

The Machine.Config file is relatively large and you shouldn’t change any of the entries without knowing what they do. I prefer to place this entry at the end of the file so that I can find it easily. Placing the entry at the beginning of the file may not work because there are other definitions you need.

The first entry is the <cryptoClasses> tag. You can add more than one entry to the list. However, the example only uses one entry. The <cryptoClass> tag contains the information for the class you want to map to a particular algorithm. You can use any legitimate .NET class, even existing classes. For example, you might want to ensure that everyone uses triple DES encryption at all times, so mapping the TripleDES class to the DES class makes sense. The <cryptoClass> tag must include the following information:

• A string that describes the class

• The name of the assembly that contains the class

• The culture (the language and elements associated with a particular country) associated with the assembly

• A public key token associated with the assembly

• The assembly version number

The assembly must appear in the GAC. You can add the assembly to the GAC using the GACUtil utility. All of the information you need to create a class entry appears in the \WINDOWS\assembly folder as shown in Figure 7.8.

Figure 7.8: Validate the information for a class entry using the assembly folder information.

After you create and verify the <cryptoClasses>, you must create one or more <nameEntry> tags. Each <nameEntry> tag contains the name of an existing algorithm-associated class such as the two shown in Listing 7.1. You then use the class attribute to define the name of the class you want associated with the class defined by the name attribute.

Using Configuration Files to Map Object Identifiers (OIDs)

Some forms of data encryption rely on Abstract Syntax Notation One (ASN.1) OID entries. These entries appear as additions to the hash value and identify the maker or type of the encryption algorithm. The CSP signs both the hash value and the OID, so this added information becomes part of the signed package—making it nearly impossible for someone to change the encryption source information.

Tip

You’ll find that companies use ASN.1 entries for more than just cryptographic work. The best place to learn about these entries is the ASN.1 Consortium at http://www.asn1.org/.

Normally, you don’t need to worry about ASN.1 OIDs because Microsoft provides them for any encryption technology provided as part of .NET. In addition, most third party vendors don’t use this technology. However, you might want to use an encryption technology that relies on an ASN.1 OID, making a map to that OID required.

As with the algorithm name map described in the “Using Configuration Files to Map Algorithm Names” section, you must make the map entry in the Machine.Config file. See that section for details on this file. The vendor should provide you with everything needed to create the entry. Listing 7.2 shows a typical Machine.Config OID entry.

Listing 7.2 Mapping an OID to a Class

<configuration> <!-- Bunches of other entries -->    <mscorlib>       <cryptographySettings>          <cryptoNameMapping>             <cryptoClasses>                <cryptoClass ThirdPartyDES="ThirdPartyDESClass,                             ThirdPartyDESAssembly,                             Culture=’en’,                             PublicKeyToken=1234567890123456,                             Version=1.0.0.0"/>             </cryptoClasses>             <nameEntry name="NewDES" />          </cryptoNameMapping>          <oidMap>             <oidEntry O                       name="NewDES"/>          </oidMap>       </cryptographySettings>    </mscorlib> </configuration>

The <cryptoClasses> and <cryptoClass> tags work just like those used for an algorithm map. You can obtain the information you need from the \WINDOWS\assembly folder as shown in Figure 7.8. It’s important to include all of the entries to ensure that CLR can identify your particular class.

The <nameEntry> tag doesn’t reference one of the .NET Framework classes in this case. Instead, you must provide the name of the new class as it appears to the application developer. The class attribute associates the new class with the class definition provided by the <cryptoClass> tag.

The <oidMap> tag and its associated children associate the new class with the OID for the hashing method. The problem with this entry is that you can’t readily access the information on your machine. The vendor must provide this information to you or you must find it from a third party source when using a generally accessible algorithm.