Using .NET Framework Cryptography

When writing services that communicate over the network or that persist data to servers accessed by potentially thousands of Internet users, you might want to protect the confidentiality of some or all of that data by using cryptography. Although this is the traditional purpose for encryption, it is not the only reason to employ cryptography. In addition to preserving data confidentiality, cryptography can also provide message integrity (proof that the message has not been altered since it was sent) and authentication (proof that the person who claims to be the message sender really did send the message).

In this section, we discuss types of cryptographic algorithms available in the .NET Framework and criteria for deciding how and when to use encryption in your application.

Understanding the Types of Cryptographic Algorithms

Three major varieties of algorithms are used in cryptography:

• Symmetric encryption

• Asymmetric encryption

• Hashing algorithms

Traditional encryption algorithms use symmetric cryptography, with the same key being used to encrypt and decrypt data. Any user possessing the shared key can use it to encrypt or decrypt messages.

Newer algorithms often use asymmetric cryptography, sometimes called public key cryptography, which uses different keys to encrypt and decrypt data. Each user is issued one or more pairs of keys. One key in the pair is kept private to that user, and the other key is made available publicly to others. A characteristic of asymmetric encryption algorithms is that either the private key or the public key can be used to encrypt data, and once encrypted, the data can be decrypted only by providing the other key. Users can encrypt data with the intended receiver’s public key, and know that the only person who can decrypt it is the one holding the private key from that pair. This ensures that the content of the message cannot be discovered by unauthorized individuals.

Additionally, a user can encrypt data with the private key from their key pair, and then that data can be decrypted by anyone with that user’s public key. Although this does not provide confidentiality (because anyone and everyone could have the user’s private key), it does provide another benefit not available with symmetric encryption—a way for the receiver of the data to verify that the data originated with the person who claims to be the source of it. If the recipient can successfully decrypt the data by using the sender’s public key, the recipient knows that the data had to have been encrypted using the sender’s private key and has not been changed since originally encrypted. This newer style of cryptography is the technology that enables the .NET platform’s strong names and Authenticode signatures to identify the origin of an assembly and verify that the file containing the code has not been altered since originally created. The downside to asymmetric cryptography is that it is much less efficient to perform than symmetric cryptography, thus necessitating that developers find creative ways to gain the advantages of asymmetric cryptography without vastly increasing encryption/decryption overhead.

Hashing algorithms are not truly encryption algorithms, because unlike symmetric and asymmetric cryptography, hashing algorithms are one-way doors. You send a large set of data through a hashing algorithm, and it quickly produces a statistically unique “signature” consisting of a smaller amount of data. For instance, a hashing algorithm run over an assembly might produce a hash result only 128 or 160 bits long, depending on the algorithm employed. Because multiple sets of data might hash to the same result, it is not possible to “decrypt” a hash value into its original larger set of data. Because it is unlikely that other sets of data that happened to hash to the same result would appear to be valid assemblies, hashing algorithms can be used as a shortcut in the computation of digital signatures for items such as assemblies—it’s necessary only to encrypt the hash value, rather than the entire assembly file, using asymmetric encryption. Typically, the hash value for a set of data is computed before the data is distributed and then sent with the data to its intended recipients. Before the data is used, the recipient computes the hash value for the received data and verifies that it is identical to the original hash value supplied by the sender. Hash values are used as a unique identifier for assemblies, as you saw in Exercise 9.2 when using an assembly’s SHA1 hash value to uniquely identify it for a code group. They are also used frequently for authentication, so that the system can avoid transmitting or storing actual passwords.

Choosing an Encryption Algorithm

Many criteria can come into play when choosing which type of encryption and which particular algorithm of that type to employ. Some of these criteria are related to business guidelines (your organization might have lists of approved cryptographic algorithms), and some are related to what makes the best sense technically.

For example, encryption algorithms are available in various strengths, generally measured by the estimated length of time required for someone to break the encryption and find some way of decrypting the data. There is generally a trade-off between performance and strength—the stronger the algorithm or longer the key length, the longer it takes to encrypt the data.

Be aware that some cryptographic algorithms such as TripleDES are available only if the high encryption pack has been installed on the system on which the encryption is being performed. The AES (also called by its original name, Rijndael) algorithm is available on any system on which the .NET Framework is installed.

Designing an Encryption Strategy

There are several ways to use cryptography from within .NET applications. One way is to take advantage of .NET’s built-in support for Secure Sockets Layer (SSL) encryption. You can run XML Web services, .NET Remoting, and anything else that can be tunneled via HTTP (such as custom communications protocols) over an SSL-encrypted HTTP connection, with very little extra programmer effort.

Note 

The details of using encryption with different types of services are covered in Chapters 10 and 11.

To use SSL, the server must have a digital certificate, obtained from a certificate authority such as VeriSign, and this certificate must be installed into IIS through the website properties dialog. If your server hosts virtual sites and you want to use SSL on those virtual sites, you must first obtain and install a digital certificate for the system’s default website and then install the certificates for the virtual sites.

If you require more control over how and when the encryption is performed (perhaps for performance reasons, you want to encrypt only a subset of the data to be transported), can’t use SSL due to firewall or political restrictions (the HTTPS port might be blocked at your organization), or want to encrypt data for storage rather than network transmission, it is necessary to use the .NET Framework’s cryptography methods, discussed next. For example, when designing your encryption approach for an XML Web service, you might choose to encrypt selected fields transmitted in SOAP headers, or the body of the message, or the body of only the messages carrying sensitive information such as credit card number, and so on.

Using System.Security.Cryptography

The .NET Framework provides a rich selection of symmetric encryption, asymmetric encryption, and hashing abstract algorithm classes, each with one or more physical implementations. The algorithm classes are listed in Table 9.11.

Table 9.11: Selected Cryptographic Algorithms Available in the .NET Framework

Algorithm	Type
SHA1	Hashing
SHA256	Hashing
MD5	Hashing
TripleDES	Symmetric
RC2	Symmetric
DES	Symmetric
Rijndael	Symmetric
RSA	Asymmetric
DSA	Asymmetric

Several classes from the System.Security.Cryptography namespace are useful in implementing cryptography in your applications. They are summarized in Table 9.12.

Table 9.12: Cryptography-Related Classes and Interfaces Available in the .NET Framework

Class	Type
cryptoprovider	One of the classes that exists for each type of cryptographic algorithm supported by the .NET Framework—for example, RijndaelManaged or DESCryptoServiceProvider
ICryptoTransform	The interface through which encryption and decryption is performed
CryptoStream	The class associating your data with the ICryptoTransform function you wish to perform

The object corresponding to the specific cryptographic algorithm class of interest, such as TripleDES, is necessary because that object is the basic one required to perform cryptography by using the specified algorithm. The Encryptor object associated with the algorithm class is used to obtain the actual encryption functions (conversely, the Decryptor object is used to obtain the decryption functions). Finally, the CryptoStream object links the output stream and Encryptorto the input stream, and when the CryptoStream.Write method is called, results in encrypted text being written to the specified output stream.

The use of the asymmetric encryption functions is beyond the scope of the exam. However, you should be familiar with the basic steps in using a symmetric algorithm to encrypt an incoming plaintext string into an outgoing ciphertext string, which can then be sent over the network, persisted to the system’s hard disk, and so on. Here is the general procedure to follow:

1. Create an instance of the Cryptographic Service Provider (CSP).

2. Create a stream to hold the output of the encryption (file or memory stream, as needed).

3. Create an Encryptor object (the encryption-oriented CryptoTransform ) by using the CreateEncryptor method of the object you created in step 1. P pass it your desired key and algorithm initialization vector (also known as IV, which is used to modify the behavior of the encryption algorithm) to control the encrypted output.

4. Create a CryptoStream object that can write encrypted data. Pass it the output ciphertext stream and Encryptor objects created in steps 2 and 3.

5. Call the CryptoStream.Write method, passing to it the plaintext data to be encrypted as a byte array, the transform to be used (if any), and the length of the data.

6. Call the CryptoStream.FlushFinalBlock method to ensure that all encrypted data is written to the CryptoStream object, if required.

7. Convert the output stream into the desired form (string, byte array, or other form).

   Note 

   You will use the cryptography capabilities of the .NET Framework in Chapter 11 when exploring SOAP data encryption.