The Cryptographic Object Model of the .NET Framework

for RuBoard

One of the first things a developer will notice of any reasonable cryptographic library is an abundance of different algorithms that perform equivalent functions. Nothing is static in the field of cryptography. Over time, new algorithms are invented and old algorithms are broken, so any application using cryptography needs to be able to adopt these new algorithms and retire the old ones over time. Consequently, a good cryptographic library has to have easy extensibility by third parties (to accommodate new algorithms) as one of its fundamental design goals if it is to be useful over time. Users must be able to add new and improved algorithms to the system in a way that makes them available seamlessly to current and future applications. Additionally, a cryptographic library must also be able to accommodate multiple implementations of a particular cryptographic algorithm coexisting on the same machine. For example, a Web server handling e-commerce transactions is likely to include a hardware accelerator for improving the performance of cryptographic operations (for example, establishing SSL/TLS connections).

The .NET Framework cryptographic object model was designed to facilitate the addition of new algorithms and implementations in an interoperable manner. In the model, a category of algorithms, such as "symmetric algorithms," is represented by a single abstract base class. Figure 30.9 shows a portion of the object hierarchy for secret key ciphers such as Triple DES, Rijndael (AES), and RC2. Individual algorithms in the category are represented by abstract algorithm classes, which are subclasses of the base class, and algorithm implementation classes are subclasses of the abstract algorithm classes. In Figure 30.9, the SymmetricAlgorithm class is the abstract base class for all symmetric key ciphers (for example, Rijndael ). Each algorithm is then represented by an abstract subclass of SymmetricAlgorithm ” TripleDES , Rijndael , RC2 , and so on. Each of these classes is then subclassed by one of the implementation classes ” TripleDESCryptoServiceProvider (an implementation of TripleDES using CryptoAPI), RijndaelManaged (a managed code implementation of Rijndael ), or RC2CryptoServiceProvider .

Figure 30.9. The Crypto object model.

NOTE

The Rijndael algorithm was chosen as the winner of the Advanced Encryption Standard (AES) contest sponsored by the U.S. Government's National Institute of Standards and Technology (NIST) as the replacement for DES, the Data Encryption Standard. Throughout the .NET Framework, we refer to the algorithm by its original name .

For secret key ciphers, the abstract base class SymmetricAlgorithm defines the top of the object hierarchy. The SymmetricAlgorithm class defines methods and properties that are common to all algorithms in this class, and every class representing a secret key cipher is a subclass of SymmetricAlgorithm . For example, a symmetric algorithm is defined only for certain key lengths, so the SymmetricAlgorithm class defines an abstract LegalKeySizes property to represent the set of valid key sizes (in bits) for a cipher. The specific properties defined by each abstract base class are described in more detail in the later sections of this chapter.

Individual algorithms are represented in the model as subclasses of the abstract base class. These abstract algorithm classes have two functions. First, where possible, they expose algorithm-specific details, such as key and block sizes, by providing implementations of properties and methods defined by the abstract base class. For example, the Rijndael algorithm is defined for key sizes of 128, 192, and 256 bits, so the Rijndael class provide an implementation of the LegalKeySizes property that returns these specific values. The second function of an abstract algorithm class is to define properties and methods that are common to every implementation of the algorithm they represent but do not apply to other algorithms. The IsWeakKey method on the TripleDES abstract algorithm class is an example of such a method. This method checks potential TripleDES keys against a list of known weak keys (specific keys that should not be used with the TripleDES algorithm because there are known attacks against them).

Implementations of a particular algorithm are supplied in subclasses of the corresponding abstract algorithm class. So, for example, an implementation of the TripleDES algorithm is provided by a specific class, TripleDESCryptoServiceProvider , that is a subclass of the TripleDES class. The naming convention used for algorithm implementation classes included in the .NET Framework is to concatenate the name of the algorithm class with a string identifying the source of the implementation. A CryptoServiceProvider suffix denotes an implementation based on the Microsoft Cryptographic Service Providers (CSPs) that ship as part of the Windows CryptoAPI library of functions; RC2, DES, and TripleDES are implemented on top of CryptoAPI in the .NET Framework. A Managed suffix denotes an algorithm implemented in managed code (a language that runs on top of the Common Language Runtime, such as C#). The Rijndael algorithm is implemented in C#, so its implementation class is denoted RijndaelManaged .

Although the crypto object model contains a large number of abstract classes, its design has a number of advantages for developers. First and foremost, is it very easy to extend the model to add your own (or a third party's) algorithms and implementations. Have a hardware cryptographic accelerator on your system that implemented Rijndael? Create a subclass of the Rijndael class that interfaces to your hardware device, and now any managed code can use your device. Want to add a new algorithm to the .NET Framework, say the RC6 secret key cipher? Create an abstract RC6 class that subclasses SymmetricAlgorithm , and then create an implementation class ( RC6Managed , perhaps) that subclasses RC6. We discuss extending the cryptographic framework in more detail in the next chapter.

We have focused in this section on the portion of the object hierarchy that relates to secret key ciphers, but equivalent object hierarchies also exist for public key algorithms (rooted at the AsymmetricAlgorithm class) and cryptographic hash functions (rooted at the HashAlgorithm class). The following is a quick summary of the three algorithm- related hierarchies that are included in the .NET Framework crypto object model:

• HashAlgorithm (abstract)

  • SHA1 (abstract)

    • SHA1CryptoServiceProvider (an implementation of SHA-1 using CryptoAPI)

  • SHA1Managed (an implementation of SHA1 in C#)

  • SHA256 (abstract)

    • SHA256Managed (an implementation of SHA256 in C#)

  • SHA384 (abstract)

    • SHA384Managed (an implementation of SHA384 in C#)

  • SHA512 (abstract)

    • SHA512Managed (an implementation of SHA512 in C#)

  • MD5 (abstract)

    • MD5CryptoServiceProvider (an implementation of MD5 using CryptoAPI)

  • KeyedHashAlgorithm (abstract)

    • HMACSHA1 (an implementation in C#)

    • MACTripleDES (an implementation in C#)

  • SymmetricAlgorithm (abstract)

    • TripleDES (abstract)

      • TripleDESCryptoServiceProvider (an implementation of TripleDES using CryptoAPI)

    • RC2 (abstract)

    • RC2CryptoServiceProvider (an implementation of RC2 using CryptoAPI)

  • DES (abstract)

    • DESCryptoServiceProvider (an implementation of DES using CryptoAPI)

  • Rijndael (abstract)

    • RijndaelManaged (an implementation of Rijndael in C#)

  • AsymmetricAlgorithm (abstract)

    • RSA (abstract)

    • RSACryptoServiceProvider (an implementation of RSA using CryptoAPI)

    • DSA (abstract)

      • DSACryptoServiceProvider (an implementation of DSA using CryptoAPI)

Given all the crypto classes that exist in the .NET Framework, plus the ability to arbitrarily extend the object model with new algorithms and implementations, you might be thinking right now, "How can a program ever know what new implementations of an algorithm exist on a system?" Or, equivalently, "How does a program know what the user 's preferred secret key cipher is?" Developers have to be able to answer these questions easily to make their programs robust to changes in the object hierarchy, which is why the .NET Framework also includes a configuration system for the cryptography classes. The key feature of the crypto configuration system is that it defines a "default implementation type" for each abstract base class and abstract algorithm class in the crypto object model. Every abstract class in the crypto object model defines a static Create() method that, when called, creates an instance of default implementation for the abstract class. This allows a developer to ask for an instance of "the default implementation of the SHA-1 algorithm"

 SHA1 sha1 = SHA1.Create(); 

without having to know the specific name of the class that implements SHA-1. Of course, if you know that you want an instance specifically of the CryptoAPI-based implementation of SHA-1, you can create that instance directly:

 SHA1CryptoServiceProvider sha1 = new SHA1CryptoServiceProvider(); 

In the remainder of this chapter and the next, example code demonstrating cryptographic functions will use the static Create() methods (and, implicitly, the cryptographic configuration system) whenever possible. If the example demonstrates a property of the abstract base class, such as the ComputeHash(byte[]) method of the HashAlgorithm class, we will just use an instance of the default HashAlgorithm :

 HashAlgorithm hash = HashAlgorithm.Create(); hash.ComputeHash(someByteArray); 

Unless you have a particular reason to request a specific implementation of an algorithm, we suggest that you always create cryptographic objects using Create() . This will allow your programs to take advantage of newer algorithm implementations as they are developed and made available through the cryptographic configuration system.

for RuBoard