Hashing is a type of cryptography that isn't an encryption algorithm. Instead, hashing is used to produce a unique identifier—known as a hash value, hash, checksum, message authentication code (MAC), fingerprint, or message digest—of data. The data could be a file, a hard drive, a network traffic packet, or an e-mail message. The hash value is used to detect when changes have been made to a resource. In other words, hashing is used to detect violations of data integrity.

For example, a hash value computed now may be compared with a hash value created last week. If the two values are the same, the data hasn't been changed. If the two values are different, then the data has been modified. Figure 4.1 shows the basic functionality of a hash or MAC value.

Figure 4.1. The MAC value is calculated by the sender and the receiver using the same algorithm.

Unlike traditional cryptography, which transforms data into ciphertext, hashing produces a hash value without modifying the original data. Because of this special feature, hashing can be used to protect or verify data integrity. It can also be used to verify whether a copy procedure produced an exact duplicate of a data set. For example, when a hard drive is being imaged to create an exact duplicate (as is done in forensic investigations), a hash is produced of the original drive before the duplication process. Then a hash is produced of the original drive and the duplicate drive after the duplication process. If the two hashes of the original drive are the same, no modifications have occurred to the original drive. If the duplicate drive's hash value is the same as the original drive's, then that proves the duplicate is an exact copy of the original.

Hashing takes a variable-length input and produces a fixed-length output. For example, Message Digest 5 (MD5) is a 128-bit hash algorithm. This means that no matter what the size of the input data, the output hash will always be 128 bits long.

The strength of hashing is its one way-ness: It can be performed in only one direction. It isn't mathematically possible to convert a hash value back to its original data. Thus, if someone obtains your hash value, they won't be able to re-create the original data that produced the hash.

However, that isn't to say that hashing is totally attack proof. Hashing can be attacked using a method known as reverse engineering, reverse hash matching, or a birthday attack. These attack methods are commonly used by password-cracking tools. Most secure systems store passwords in their accounts database in hashed form. Hashes can't be performed in reverse, so this is generally a secure solution. However, since the hash algorithm used by commercial software is known (or can be easily discovered), password crackers can be written to exploit the stored password hashes. Attack tools compare hashes from potential passwords with the hashes stored in the accounts database. Potential passwords are either generated on the fly using all possible combinations of characters or pulled from a precompiled list of passwords (known as dictionary lists). Each potential password is hashed, and then that hash value is compared with the accounts database. If a match is found, the password cracker tool has discovered a password for a user account.

This form of hashing attack exploits the mathematical characteristic that if two messages are hashed and their hashes are the same, the messages must be the same. This can be written H(M)=H(M') then M=M'.

The most common or widely used hashing algorithms are as follows:

Symmetric cryptography is also called private key cryptography or secret key cryptography. It uses a single shared encryption key to encrypt and decrypt data (see Figure 4.2). When symmetric cryptography is used to encrypt files on a hard drive, the user is the only person in possession of the single secret key. When symmetric cryptography is used to encrypt communications traffic, the two communication partners each have a copy of the one shared secret key. For example, the secure communication session protocol of Secure Socket Layer (SSL) uses symmetric cryptography. In either use, symmetric cryptography protects confidentiality.

Figure 4.2. A symmetric encryption system

Symmetric cryptography is very fast in comparison to asymmetric cryptography (discussed next). Its speed is due to the way its algorithms are designed and the fact that a single key is used to encrypt and decrypt data.

Symmetric cryptography provides for strong encryption protection when larger keys are used. However, the protection is secure only as long as the keys are kept private. If a symmetric key is compromised or stolen, it no longer offers true protection (just as your door lock no longer provides security if someone gets a copy of your house key).

Key exchange or distribution under symmetric cryptography is a common problem. To use symmetric cryptography to encrypt communications traffic between you and someone else over the Internet (or some other untrusted network), you must have a means to securely exchange the secret keys. If you already have a means to exchange the secret keys securely, why aren't you using that mechanism to communicate? Thus, some out-of-band communication solution must be implemented to securely exchange keys. Mechanisms include shipping a floppy with a key, reading it over the phone, or using a different network to transmit the key. However, the preferred method is to deploy a complete Public Key Infrastructure (PKI) solution that employs asymmetric cryptography to exchange symmetric cryptographic keys. The exchanged secret keys are used to encrypt the traffic for a single communication session; then they're discarded. PKI is simply a concept of how to deploy different aspects of various cryptography mechanisms into a single complete real-world solution.

Since each member of a network in a symmetric cryptography solution needs to have a shared secret key with every other member in order to support secure communications, n(n-1)/2 keys are needed. Thus, symmetric cryptography isn't scalable when used alone.

Symmetric cryptography is divided into two forms:

Other than the basic difference in whether the original data is preexisting and static or produced on the fly, both ciphers function in much the same manner. Unless the symmetric cryptography solution is based around a one-time pad (meaning every key is used only once), the same encryption key is used on each block or buffer block for a given data set or communication session.

The most widely used symmetric cryptography solutions are listed in Table 4.1.

Asymmetric cryptography is also called public key cryptography. It uses key pairs consisting of a public key and a private key (see Figure 4.3). Each communication partner in an asymmetric cryptography solution needs their own unique key pair set (i.e. a private key and a public key); this makes asymmetric cryptography much more scalable than symmetric. The private key of the key pair must be kept private and secure. The public key of the key pair is distributed freely and openly.

Figure 4.3. An asymmetric encryption system

The public and private keys are related mathematically, but possession of the public key doesn't allow someone to generate the private key. Thus, the integrity of the private key is protected. In addition, the keys always work in unison: If the public key is used to encrypt data, only the private key can decrypt it. Likewise, if the private key is used to encrypt data, only the public key can decrypt it.

Asymmetric cryptography functions as follows:

Asymmetric cryptography is much slower than symmetric cryptography, so it isn't generally suited for encrypting large amount of data. It's often used as the secure exchange mechanism for symmetric cryptographic keys. It provides several security services: authentication, integrity protection, and non-repudiation.

The most widely used asymmetric cryptography solutions are as follows:

Confidentiality protects the secrecy of data, information, or resources. It prevents or minimizes unauthorized access to data (see Figure 4.4). It ensures that no one other than the intended recipient of a message receives it or is able to read it. Confidentiality protection provides a means for authorized users to access and interact with resources, but it actively prevents unauthorized users from doing so.

Figure 4.4. Cryptographic systems protect data from internal and external disclosure.

Integrity is the security service that protects the reliability and correctness of data. Integrity protection prevents unauthorized alterations of data (see Figure 4.5). It ensures that data remains correct, unaltered, and preserved. Integrity protection provides a means for authorized changes to be implemented, but it actively prevents unauthorized changes to protected data. Integrity protection resists changes by unauthorized activities (such as viruses or intrusions) and accidents by authorized users (such as mistakes or oversights). Often an integrity check uses a hashing function to verify that data remains unchanged in storage or after transit.

Figure 4.5. A simple integrity-checking process for an encrypted message

One common example of a cryptographic solution that provides for integrity protection is a digital signature.

Digital Signatures

A digital signature is an electronic mechanism to prove that a message was sent from a specific user (that is, it provides for non-repudiation) and that the message wasn't changed while in transit (it also provides integrity). Digital signatures operate using a hashing algorithm and either a symmetric or an asymmetric encryption solution.

Digital signatures using asymmetric encryption solutions operate as follows:

1. The sender writes a message.

2. The sender computes a hash of the message.

3. The sender uses the sender's private key to encrypt the hash.

4. The sender attaches the encrypted hash to the message.

5. The complete message package is sent to the receiver.

6. The receiver strips off the encrypted hash.

7. The receiver uses the sender's public key to decrypt the hash.

8. The receiver computes a hash of the message.

9. The receiver compares the two hash values.

Digital signatures using symmetric encryption solutions (see Figure 4.6) operate as follows:

1. The sender writes a message.

2. The sender computes a hash of the message.

3. The sender uses the shared secret key to encrypt the hash.

4. The sender attaches the encrypted hash to the message.

5. The complete message package is sent to the receiver.

6. The receiver strips off the encrypted hash.

7. The receiver uses the shared secret key to decrypt the hash.

8. The receiver computes a hash of the message.

9. The receiver compares the two hash values.

Figure 4.6. A digital signature process using symmetric encryption

In either case, if the hash values match, then the recipient gets verification that integrity was maintained and that the sender did send the message (non-repudiation). If the hash values don't match, then the recipient doesn't have verification of either integrity protection or non-repudiation.

Authentication verifies the identity of the sender or recipient of a message. In cryptography terms, authentication occurs differently in symmetric cryptography than it does in asymmetric cryptography. In symmetric cryptography, a single shared secret key is held only by the two communication partners. Thus, when an encrypted message is received and is properly decrypted by the recipient's copy of the shared secret key, authentication occurs. The recipient is authenticated because possession of the correct key proves that this is the correct recipient of the encrypted message. Likewise, the sender is authenticated because the recipient's ability to extract an intelligible message from the received encrypted material using the secret key proves that the sender, the only other user with possession of the same secret key, encrypted and sent the message.

In asymmetric cryptography, a sender uses the recipient's public key to encrypt data. This forces authentication of the recipient since the recipient is the only user in possession of the corresponding private key. Likewise, when the sender's private key is used to encrypt data, then any recipient can verify the sender's identity by decrypting that data with the sender's public key.

Non-repudiation prevents the sender of a message or the perpetrator of an activity from being able to deny that they sent the message or performed the activity. In symmetric cryptography, non-repudiation is supported when a recipient is able to decrypt a message using the shared secret key. This proves that the other holder of the shared secret key is the actual sender who sent the message. In asymmetric cryptography, non-repudiation is supported when a sender's private key is used to successfully decrypt a message. This proves that the sender's private key was used to encrypt the data. Since the sender is the only user who has possession of the sender's private key, no one else could have encrypted and sent the message.

One common example of a cryptographic solution that provides for non-repudiation is a digital signature.

Access control restricts access to secured data to authorized users. Cryptographic access control is enforced through the concept of possession of encryption keys. In a symmetric cryptography solution, a maximum of two people have valid possession of the shared secret key. Thus possession of the shared secret key is proof of authorization: The holder of the shared secret key is authorized to access anything encrypted with that key. In asymmetric cryptography, only one person is in valid possession of the private key. Thus, possession of the private key is proof of authorization: The holder of the private key is authorized to access anything encrypted with the corresponding public key.

Certificates serve a single purpose: proving the identity of a user or the source of an object. They don't provide proof as to the reliability or quality of the object or service to which they're attached; they only provide proof of where that product or service originated.

Certificates work under a theory known as the trusted third party. This theory states that if user A trusts user C and user B trusts user C, then user A can trust B and vice versa. With certificates, the trusted third party is a certificate authority (CA) (see Figure 4.7). If two users have certificates issued by the CA, then the two users can trust each other's identity. Certificates work this way on the Internet and within private organizations.

Most certificates used on the Internet and within private networks are based on the X.509 version 3 certificate standard. This standard dictates how certificates are to be constructed and their required components, such as the subject's public key, the CA's distinguishing name, a unique serial number, and the type of symmetric algorithm used for the certificate's encryption (see Figure 4.8).

Figure 4.7. The certificate authority process

Figure 4.8. A certificate illustrating some of the information it stores

A user or a subject uses the following procedure to obtain a certificate:

Another entity known as a registration authority (RA) may be deployed in a CA solution. The RA can't create new certificates; rather it serves as a distribution point for the certificate revocation list (CRL) and possibly as an Online Certificate Status Protocol (OCSP) host (see the later section "Revocation"). CAs must have defined certificate policies and certificate practice statements.

Certificates have a specific expiration date, which is sometimes called the lifetime date. Once that date is reached, a certificate is automatically rejected as invalid. However, a CA may have cause to revoke or invalidate a certificate before its predefined expiration date. Revocation is the process by which a CA invalidates a certificate.

Revocation may occur because the subject's identity information has changed, the subject used the certificate to commit a crime, or the subject used the certificate in such a way as to violate the CA's certificate policy.

When a certificate is revoked, it's added to the CA's CRL. Once a certificate's expiration date is reached, it's removed from the CRL, since the timestamp automatically invalidates the certificate. Thus, the CRL contains only those certificates that have been revoked but have yet to expire. Figure 4.9 shows the certification revocation process.

Figure 4.9. Certification revocation process

The CRL is freely distributed to all users and applications. You should always consult it before accepting a certificate. When issued to a requesting user or application, a CRL is assigned a lifetime date as well. When the CRL exceeds this lifetime, it can no longer be relied on, and you should obtain a new, updated version of the CRL.

When a user application, such as a web browser, receives a certificate from a server, such as a web server, the application first verifies that the date on the certificate is still valid. Next, it checks the local copy of the CA's CRL. If the CRL is no longer valid, an updated copy of the CRL is obtained. The application checks to see whether the certificate appears on the CRL. If it doesn't, the application presents the certificate to the user for a final acceptance choice. The user can elect to accept or reject the certificate as well as indicate whether to make this same acceptance or rejection choice for all future instances of this certificate.

The CRL process is widely used, but it isn't the only mechanism for informing users and applications about the status of certificates. Online Certificate Status Protocol (OCSP) is another solution that functions on a direct query basis. Each time an application receives a new certificate, it sends a query to an OCSP CA server. The CA responds directly to indicate whether the certificate is still valid or has been revoked. By using OCSP, large CRLs aren't transmitted repeatedly to every requesting system, and queries are direct, immediate, and current.

The term trust model refers to the structure of the trust hierarchy used by a certificate authority system. The basic trust model scheme used by CAs is a hierarchical structure with a single top-level root CA. Below the root CA are one, two, or more subordinate CAs. Below each subordinate CA may be one, two, or more subordinate CAs, and so on. Subordinate CA's can sometimes be called intermediate or leaf CAs. In this model, all CAs have a single parent CA, but they may have multiple child CAs (see Figure 4.10). The root CA is the start of trust; all CAs and participants in a hierarchical trust model ultimately rely on the trustworthiness of the root CA.

Figure 4.10. A hierarchical trust structure

Cross-certification occurs when a CA from one organization elects to trust a CA from another organization (see Figure 4.11). This is also called a bridge trust structure. In this way, certificates from either organization are accepted by the other organization. In most cases, the root CA is configured to trust the other root CA.

Figure 4.11. A cross or bridge trust structure

A trust list is a form of trust model where a web browser or similar application is provided a list of root certificates of trusted CAs. The web browser trusts numerous sources of certificates because of the presence of the trusted CA's root certificate on the list of trusted CAs.

Centralized key management gives complete control of cryptographic keys to the organization and takes control away from the end users. A centralized key-management solution requires a significant investment in infrastructure, processing capabilities, administrative oversight, and communication bandwidth.

In a centralized management solution, copies of all cryptographic keys are stored in escrow. This allows administrators to recover keys in the event that a user loses their key, but it also allows management to access encrypted data whenever it chooses.

Other important aspects of centralized key management are that keys must be created only on secured, dedicated servers; keys can be distributed only to authorized users and only in a secure fashion; keys can be modified only by administrators; and revocation of keys and corresponding digital certificates is at the discretion of the organization. Figure 4.12 shows an example of a centralized key management solution.

Figure 4.12. A centralized key-generating facility

Centralized key management is often unacceptable to a user community since it provides them with no control over their privacy, confidentiality, or integrity. In fact, every key generated by the centralized system is stored in escrow. Therefore, nothing encrypted by an end user is completely private, since an administrator could extract the key from escrow and use it to decrypt a message or file.

An alternate scheme is known as decentralized key management. In this type of environment, end users generate their keys (whether symmetric or asymmetric) and submit keys only as needed to centralized authorities (see Figure 4.13). For example, to request a digital certificate, an end user would transmit only their public key to the CA. The end user's private key is always kept private so they're the only entity in possession of it. Plus, since the public key is already public, its compromise won't result in a complete compromise of the end user's secured solution.

Figure 4.13. A decentralized key-generating system

In a decentralized key management system, end users are ultimately responsible for managing their own keys and using escrow to provide fault tolerance. If an end user fails to take the necessary precautions, a lost or corrupted key could mean the loss of all data encrypted with that key.

Cryptographic keys and digital certificates should be stored securely. If a private key (asymmetric) or a secret key (symmetric) is ever compromised, then the security of all data encrypted with those keys is lost. Reliable storage mechanisms must be used to protect cryptographic keys. There are two methods or mechanisms for storing keys: hardware based or software based.

Key escrow is a storage process by which copies of private keys and/or secret keys are retained by a centralized management system (see Figure 4.14). This system securely stores the encryption keys as a means of insurance or recovery in the event of a disaster. In terms of cryptography, a disaster is when a key is lost or damaged. If such a key is stored in escrow, it can be recovered by a key escrow agent and used to recover any data encrypted with the damaged or lost key.

However, escrow can be seen in another light if you're an end user intent on obtaining complete and total security. If you're assigned your private key or secret key, then the issuing CA (or cryptographic server) probably retains a copy of the key in escrow. This means that at any time a key recovery agent could pull your key out of escrow and use it to decrypt anything you've encrypted with your public key or your secret key without your permission. Obviously, key escrow works great in private corporate environments, but it doesn't apply well to the public Internet.

Figure 4.14. A key archiving or escrow system.

Most cryptographic keys and all certificates have a built-in expiration date. Upon reaching that date, the key or certificate becomes invalid, and no system will accept it. Keys and certificates are assigned a lifetime with control settings known as valid from and valid to dates. Keys and certificates past their valid to dates should be discarded or destroyed.

If the valid to date for a key or certificate is approaching, you should request a renewal. If you fail to renew before the lifetime expires, then you must perform the complete request process from scratch.

Keys and certificates can be revoked before they reach their lifetime expiration date.

Suspension is an alternative to revocation. Suspension can be used when a key or certificate will be temporarily removed from active use but the subject (or the CA) doesn't wish to invalidate it. When a key or certificate is suspended, it can't be used to sign or encrypt any new items, but previously signed or encrypted items can be verified or decrypted. The key or certificate can be reactivated at a later date.

Recovery is the process of pulling a key or certificate from escrow. Recovery can be used when a user loses their key or their key has been corrupted. This process can also be used to extract a key for the purpose of decrypting data even when the user still has valid possession of their key. The latter option may be necessary in a private corporate environment, but it's unacceptable in a public environment, such as the Internet.

Key recovery can only be performed by a key recovery agent. The key recovery agent is an administrative-level user who has the encryption key to the escrow database. They can decrypt and extract the necessary key from the escrow database and either give a copy to the user or use the key to decrypt all data. If the latter occurs (as is common in most cryptographic solution implementation), the end user must be issued a new key, which must be used in turn to re-encrypt all the data that should be secured.

Renewal is the process by which a key or certificate is reissued with an extended lifetime date before the key or certificate expires. The renewal process doesn't require a complete repeat of the request and identity proofing process; rather, the old key (which is about to expire) is used to sign the request for the new key. This allows the CA to quickly determine whether the end user's key or certificate can be immediately extended (or reissued with a new lifetime date) or rejected and revoked according to its existing lifetime dates. The decision of the CA often depends on the end user's compliance with the organization's certificate policy (the acceptable use policy for the key or certificate).

After a key or certificate is no longer needed or it has expired or been revoked, it should be properly disposed of. This process is known as key destruction: the removal of the key or certificate from all software and hardware storage devices. For keys and certificates that are still valid, the CA should be informed about the destruction of the key or certificate. This action allows the CA to update its CRL and OCSP servers.

Reasons to use key destruction include going out of business, changing identity, or having obtained replacement keys or certificates.

Cryptographic keys and digital certificates can be used in a wide variety of applications. Cryptographic keys, both symmetric and asymmetric, are involved in numerous security and protection solutions. These include the following: