Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

Cryptography and Certificates

J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation

Published: November 2002

Last Revised: January 2006

Applies to:

• Microsoft® ASP.NET

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for the starting point and a complete overview of Building Secure ASP.NET Applications.

Summary: This section provides an overview of certificates, certificate stores, cryptography and cryptography support in the .NET Framework. (7 printed pages)

Contents

Keys and Certificates
Cryptography
Summary

Keys and Certificates

Asymmetric encryption uses a public/private key pair. Data encrypted with the private key can be decrypted only with the corresponding public key and vice versa.

Public keys (as their name suggests) are made generally available. Conversely, a private key remains private to a specific individual. The distribution mechanism by which public keys are transported to users is a certificate. Certificates are normally signed by a certification authority (CA) in order to confirm that the public key is from the subject who claims to have sent the public key. The CA is a mutually trusted entity.

The typical implementation of digital certification involves a process for signing the certificate. The process is shown in Figure 1.

Figure 1. Digital certification process

The sequence of events shown in Figure 1 is as follows:

1. Alice sends a signed certificate request containing her name, her public key, and perhaps some additional information to a CA.
2. The CA creates a message from Alice's request. The CA signs the message with its private key, creating a separate signature. The CA returns the message and the signature, to Alice. Together, the message and signature form Alice's certificate.
3. Alice sends her certificate to Bob to give him access to her public key.
4. Bob verifies the certificate's signature, using the CA's public key. If the signature proves valid, he accepts the public key in the certificate as Alice's public key.

As with any digital signature, any receiver with access to the CA's public key can determine whether a specific CA signed the certificate. This process requires no access to any secret information. The preceding scenario assumes that Bob has access to the CA's public key. Bob would have access to that key if he has a copy of the CA's certificate that contains that public key.

X.509 Digital Certificates

X.509 digital certificates include not only a user's name and public key, but also other information about the user. These certificates are more than stepping stones in a digital hierarchy of trust. They enable the CA to give a certificate's receiver a means of trusting not only the public key of the certificate's subject, but also that other information about the certificate's subject. That other information can include, among other things, an e-mail address, an authorization to sign documents of a given value, or the authorization to become a CA and sign other certificates.

X.509 certificates and many other certificates have a valid time duration. A certificate can expire and no longer be valid. A CA can revoke a certificate for a number of reasons. To handle revocations, a CA maintains and distributes a list of revoked certificates called a Certificate Revocation List (CRL). Network users access the CRL to determine the validity of a certificate.

Certificate Stores

Certificates are stored in safe locations called a certificate stores. A certificate store can contain certificates, CRLs, and Certificate Trust Lists (CTLs). Each user has a personal store (called the "MY store") where that user's certificates are stored. The MY store can be physically implemented in a number of locations including the registry, on a local or remote computer, a disk file, a data base, a directory service, a smart device, or another location.

While any certificate can be stored in the MY store, this store should be reserved for a user's personal certificates, that is the certificates used for signing and decrypting that particular user's messages.

In addition to the MY store, Windows also maintains the following certificate stores:

• CA and ROOT. This store contains the certificates of certificate authorities that the user trusts to issue certificates to others. A set of trusted CA certificates are supplied with the operating system and others can be added by administrators.
• Other. This store contains the certificates of other people to whom the user exchanges signed messages.

The CryptoAPI provides functions to manage certificates. These APIs can be accessed only through unmanaged code. Also, CAPICOM is a COM-based API for the CryptoAPI, which can be accessed via COM Interop.

Note   The .NET Framework 2.0 supports classes such as X509Store and X509Certificate2 in the System.Security.Cryptography.X509Certificates namespace for managing the certificates. You do not need to use unmanaged code. For more information, see "System.Security.Cryptography.X509Certificates namespace."

More Information

For more information, see Cryptography, CryptoAPI, and CAPICOM.

Cryptography

Cryptography is used to provide the following:

• Confidentiality. To ensure data remains private. Confidentiality is usually achieved using encryption. Encryption algorithms (that use encryption keys) are used to convert plain text into cipher text and the equivalent decryption algorithm is used to convert the cipher text back to plain text. Symmetric encryption algorithms use the same key for encryption and decryption, while asymmetric algorithms use a public/private key pair.
• Dataintegrity. To ensure data is protected from accidental or deliberate (malicious) modification. Integrity is usually provided by message authentication codes or hashes. A hash value is a fixed length numeric value derived from a sequence of data. Hash values are used to verify the integrity of data sent through insecure channels. The hash value of received data is compared to the hash value of the data as it was sent to determine if the data was altered.
• Authentication. To assure that data originates from a particular party. Digital certificates are used to provide authentication. Digital signatures are usually applied to hash values as these are significantly smaller than the source data that they represent.

Technical Choices

• Use a hash when you want a way of verifying that data has not been tampered with in transit.
• Use a keyed hash when you want to prove that an entity knows a secret without sending the secret back and forth, or you want to defend against interception during transit by using a simple hash.
• Use encryption when you want to hide data when being sent across an insecure medium or when making the data persistent.
• Use a certificate when you want to verify the person claiming to be the owner of the public key.
• Use symmetric encryption for speed and when both parties share the key in advance.
• Use asymmetric encryption when you want to safely exchange data across an insecure medium.
• Use a digital signature when you want authentication and non-repudiation.
• Use a salt value (a cryptographically generated random number) to defend against dictionary attacks.

Cryptography in .NET

The System.Security.Cryptography namespace provides cryptographic services, including secure encoding and decoding of data, hashing, random number generation, and message authentication.

The .NET Framework provides implementations of many standard cryptographic algorithms and these can be easily extended because of the well-defined inheritance hierarchy consisting of abstract classes that define the basic algorithm types—symmetric, asymmetric and hash algorithms, together with algorithm classes.

Table 1. Algorithms for which the .NET Framework provides implementation classes "out of the box"

Symmetric algorithm support

.NET provides the following implementation classes that provide symmetric, secret key encryption algorithms:

• DESCryptoServiceProvider
• RC2CryptoServiceProvider
• RijndaelManaged
• TripleDESCryptoServiceProvider

Note   The classes that end with "CryptoServiceProvider" are wrappers that use the underlying services of the cryptographic service provider (CSP) and the classes that end with "Managed" are implemented in managed code.

Figure 2 shows the inheritance hierarchy adopted by the .NET Framework. The algorithm type base class (for example, SymmetricAlgorithm) is abstract. A set of abstract algorithm classes derive from the abstract type base class. Algorithm implementation classes provide concrete implementations of the selected algorithm; for example DES, Triple-DES, Rijndael and RC2.

Figure 2. The symmetric crypto class inheritance hierarchy

Asymmetric algorithm support

.NET provides following asymmetric (public/private key) encryption algorithms through the abstract base class (System.Security.Crytography.AsymmetricAlgorithm):

• DSACryptoServiceProvider
• RSACryptoServiceProvider

These are used to digitally sign and encrypt data. Figure 3 shows the inheritance hierarchy.

Figure 3. The asymmetric crypto class inheritance hierarchy

Hashing algorithm support

.NET provides following hash algorithms:

• SHA1, SHA256, SHA384, SHA512
• MD5
• HMACSHA (Keyed Hashed algorithm)
• MACTripleDES (Keyed Hashed algorithm)

Figure 4 shows the inheritance hierarchy for the hash algorithm classes.

Figure 4. The hash crypto class inheritance hierarchy

Summary

Cryptography is an important technology for building secure Web applications. This appendix has covered some of the fundamentals of certificates and cryptography and has introduced some of the classes exposed by the System.Security.Cryptography namespace, which enable you to more easily incorporate cryptographic security solutions into your .NET applications.

For more information about cryptography in .NET, see .NET Framework Cryptography Model.

© Microsoft Corporation. All rights reserved.