The “key space” (number of possible unique keys) is short—you only need to try 26 shifts in all.Cryptography in Operating Systems
Cryptography—from the Greek kryptos, meaning “hidden, secret,” and grapho, meaning “I write”—is the science and practice of secret communications. Because of many overlaps between merely hiding information and making it possible to determine whether or not information has been tampered with, both integrity and confidentiality are significant elements of cryptography.
Cryptography strikes a number of emotions in the heart of the reader—because it has elements of extremely complex mathematics, it can be viewed as somewhat dry and dull; because it frequently requires the reader to accept that certain operations are secure, or slow to compute, it can be viewed as requiring a suspension of disbelief. There is also an element of fear that goes along with accepting that cryptography makes the statement that you accept the possibility that you will lose access to the data you are protecting (if you lose your keys, or if the encrypted data is corrupted, for instance) and that this is the price of fully ensuring that your data is protected.
In this chapter, we will introduce you to the most important current cryptographic techniques that you will encounter in the course of your computing endeavors. We will use pictures to make things clear and allegory where it aids understanding. We will start with a set of basic cryptographic knowledge—a “primer,” if you will—and then proceed to demonstrate some of the algorithms that use those cryptographic bases. Then, we will discuss the protocols that wrap the algorithms up and provide for a mechanism in which to communicate about cryptographic algorithms, and we will finish with a discussion of cryptography’s uses in modern operating systems and applications.
Cryptography has a rich history, and we shall occasionally refer back to some great moments in secret communications, not because they are covered in the exam so much as because we hope they are interesting to the reader.
Locks and keys have been used for centuries to keep items—and communications—hidden. In many locks in the physical world, it is possible to close the lock without having the key (or the code, for a combination lock). Other locks require a key to lock them, that key also being required to unlock them.
There are analogous mechanisms in the online world, except that the terminology is different. Locking and unlocking are not common terms in cryptography—instead, we talk of “encrypting” data to turn it from readable into unreadable and “decrypting” data to go from unreadable to readable. Locks are now “algorithms” or methods by which encryption is done, and keys, thankfully, are still represented by the term “keys.” The two kinds of encryption (same key, different key) are referred to as symmetric and asymmetric, respectively.
As you’ve probably guessed, since “symmetric” means, in one meaning, that two sides are in balance, or equal, symmetric key cryptography is the use of one key to both encrypt and decrypt, and the encryption algorithm is sometimes the same as the decryption algorithm.
A simple example is the “Caesar” cipher, in which letters are shifted by a number of characters. The number of the shift is the key, and the operation is a shift to the right to encrypt and a shift to the left to decrypt. Many children used code wheels to create their own Caesar cipher texts and challenged others to break their codes.
For instance, if the message we wanted to secretly communicate (the “plain text”) was “THERE ARE THREE PEOPLE TO SEE CAESAR” and the shift was 8, the letter T would be replaced by B (when a shift takes us to Z, we wrap around to A), H becomes P, and so on to give the encrypted message known as “cipher text” as follows:
THERE ARE THREE PEOPLE TO SEE CAESAR
BPMZM IZM BPZMM XMWXTM BW AMM KIMBIZ
There are several obvious disadvantages to this encryption method, which make it a very easy cipher to break.
The “key space” (number of possible unique keys) is short—you only need to try 26 shifts in all.
There’s a lot of Ms in the cipher text, because that’s what E becomes in this cipher—and E is the most common letter in the English language. This is a basic form of the analysis technique known as “frequency analysis.”
Because spaces and other punctuation characters are not altered, we may be able to use those to give some idea of the meaning of the document or the placement of particular words (any communication between these Romans is liable to mention Caesar, so look for a 6-letter word and see if its second and penultimate letters are the same).
Modern symmetric ciphers are designed to avoid these and several other weaknesses—a cipher should have a large enough key space that decrypting it using “brute force” (trying every possible key) would, on average, take many times longer than the plain text’s useful life. A cipher should generally have the same chance of encrypting a character to any other character so that frequency analysis is impractical, and all characters in the message should be subject to encryption.
The big problem that faces any symmetric key cipher is that their simplest use requires that the key be shared—a “shared secret”—between the two parties in the cipher. In some senses, that is to be expected, because the encrypted text is itself a secret that is shared between sender and recipient. However, if the sender has multiple recipients, he will need to generate multiple keys to be sure that each recipient sees only those messages meant for him.
This is not a problem unique to the digital world—to use the physical world analogy, I talk about the story of the Queen’s Jewels, which is such an old story to me now that I can’t remember if it’s historically accurate, or merely one of the interpretations of Alexandre Dumas’ Three Musketeers. In the story, the Queen must send jewels to a sympathizer without the possibility that they are intercepted along the route. She finds a strong box and secures it with a padlock to which only she has the key. The box is then sent to the sympathizer; he doesn’t have the key to unlock the box, but he adds his padlock to the box so that it is doubly locked. The box is then returned to the Queen, who unlocks and removes her padlock, before sending it on to the sympathizer, who unlocks his padlock and finally opens the box.
The end result: the jewels have been received with the knowledge that they could not have been intercepted along the way.
Similarly, in the digital world, many cryptographic operations are associative and commutative—meaning that they can be performed in any order and still produce the same result. If the encryption and decryption processes are both associative and commutative, for instance, you can take a message, encrypt it with key K1, encrypt it again with key K2, decrypt it with K1, and decrypt it with K2 to perform the same process as in the “Queen’s Jewels” story above.
The obvious drawback to this solution is that the message is sent three times before it is finally decrypted and at each of these transmissions could be intercepted and subjected to cryptanalysis.
Because cryptanalysis is best done on long, nonrandom texts, the solution to this problem is to create a shared key, which is sent using the “Queen’s Jewels” technique, and then use the shared key to encrypt the actual text to be sent. This shared key, which is valid for one session only and then discarded, is known as a “session key.” The exchange of the shared session key is unsurprisingly known as a “key exchange.”
Clever as these solutions may be, there are still some problems to overcome with symmetric key cryptography—the most notable is that the sender has no way to verify the identity of the recipient. Asymmetric key cryptography helps to solve that issue.
A British invention of the 1970s, “nonsecret encryption” provided for asymmetric key cryptography, in which a pair of unequal (hence “asymmetric”) keys is created. [The British government held the discovery of “nonsecret encryption” as a state secret until 1997, so it is fortunate that American researchers later independently discovered and published their own public key algorithms.]
For each pair of keys in asymmetric cryptography, one key is held privately, the other is published. They are referred to as the “private key” and the “public key,” respectively. The public key can be given out freely without compromising the private key at all. A sender can encrypt a message using the receiver’s public key, and be sure that it can only be decrypted using the related private key—which means that the encrypted message can then only be read by the holder of the private key. As long as the public key is trusted to be associated with the intended recipient and the private key has not been exposed, only the intended recipient will be able to decrypt the message.
The one common drawback with asymmetric key cryptography is that it is computationally expensive. This is mostly because of the size of the keys involved, which have to be much larger than keys providing similar protection strength for symmetric cryptography; first, because they are mathematically derived rather than simply randomly assigned; second, because these keys are longer lived and must survive against sustained attack for longer; third, because the public key is deliberately exposed and needs to be resistant to attempts to brute-force guess the associated private key.
Because asymmetric key cryptography is so slow to perform, it is generally used sparingly—for instance, in an encrypted communication, the public/private key pairs will generally be used only to establish and prove claimed identities and to exchange information used to calculate a shared session key. The shared session key is then used with a symmetric encryption algorithm to provide encrypted data transport with less impact to processing time.
In asymmetric encryption, encryption is generally performed using the public key, and decryption is generally performed using the private key—this is easy to remember, because encrypting data is something anyone should be able to do, but decrypting is an operation reserved only for the targeted recipient. The exception to this is in digital signatures, as we shall see later.
In cooking, a hash is when perfectly good meat and vegetables are sliced, diced, and otherwise rendered into small portions that bear no obvious resemblance to their original selves, save that their flavor can be recognized.
In cryptography, a hash is when a piece of plain text is sliced, diced, and otherwise rendered into a small “digest” or “hash” that bears no obvious resemblance to the original text, except that the same text will always produce the same hash.
You will often hear hash algorithms described as being based on mathematical “one way functions”—these are functions that are relatively easy to calculate going forward, but the inverse of the function is such a complex procedure that it is significantly harder to reverse the function than it would be to simply try every single possible input against the function to try and match its result.
There are a couple of reasons to generate hashes:
A hash can serve as a check that a document is untampered—if the sender and the recipient agree on the hash of a transferred document, they each possess the same document. Note that there are several “checksumming” algorithms that perform roughly this same task but without providing the cryptographic rigor described below.
A cryptographic hash may serve as a placeholder for a document—a proof that you possess, or once possessed, the document whose hash you have calculated. As noted below, it should be practically impossible to calculate the hash without having the original document.
A cryptographic hash can be used to verify a piece of information that is too sensitive to store—for instance, a password or a credit card number. If you send me a password when you first create your account and I store its hashed value, the next time you send me your password I can hash what you send me and verify that it matches the value I have stored.
Cryptographic hashes are required to possess a few specific properties to be useful:
It must be practically impossible to reconstruct the original data from the hash
Two similar documents must produce vastly different hashes
It must be practically impossible to construct two pieces of data that generate the same hash
Computing the hash must be a quick process
By “practically impossible,” of course, we mean that the time taken to achieve the goal must be far, far longer than the duration in which the goal is useful.
Care should be taken when using a hash for calculating a digest of small pieces of data—for passwords or credit cards, for instance. An attacker with access to the hash codes may be able to mount a bulk attack against the entire database at once, unless appropriate care is taken. Typically, the addition of a random component, known as a “salt,” to each piece of data being hashed will protect against this kind of bulk attack—that way, two users with the same password will not have the same hash. Storing the salt with the hashed value is necessary to ensure that the hash can be regenerated when checking the hash.
There are a number of hash functions in common use that the Security+ Objectives require you to know about. The algorithms below are all based around manipulation of bits, repeated several times over to make reversal of the algorithm difficult, and to make the time required to do brute-force analysis (repeatedly trying to create the result from different inputs) infeasibly long.
Algorithms in cryptography are often given either generic names or names based on the last names of the algorithm’s inventors. This is an example of the first naming scheme—“Secure Hash Algorithm” (SHA)—and it is the name for a series of algorithms that each were selected by the National Institute of Standards and Technology (NIST) to provide standardized cryptographic hash functions for widespread public use.
SHA-0 and SHA-1 each produce a 160-bit “digest” from any input message up to 2^64-1 bits in length.
SHA-2 is a family of hash functions that provide output digests in a number of different lengths—224, 256, 384, and 512.
SHA-3 has not yet been selected at the time of writing but will be chosen from a public competition between entries submitted by a number of cryptographers. The winner is scheduled to be announced in 2012.
The competition to create a SHA-3 standard was inspired by several advances in the cryptanalysis of SHA-0 and SHA-1, which are now significantly weaker than they were originally designed to be. New cryptographic designs that are required to use hashing should not use SHA-0 or SHA-1 but should use SHA-2 and have configurable extension points that would allow the addition and use of SHA-3 when it is finally selected and implemented.
Another generic name is Message Digest 5 (MD5)—there are others from its stable, particularly MD2 and MD4. All these Message Digest algorithms are known to have collision-resistance flaws which could result in the creation of two documents that have the same hash. This has been demonstrated in a number of interesting ways, including the creation of two X.509 certificates, one benign, and the other quite definitely malign in nature—because the signature that identifies the certificate is built from a hash, and particular certificate authorities (CAs) were still signing using the MD5 hash, the two certificates appeared genuine because the first was genuinely signed and the second evaluated to the same MD5 hash.
It is strongly recommended that instead of MD5, a different hashing algorithm such as any of the SHA-2 family is used for new cryptographic designs. Again, it is recommended that any system you create or purchase, that uses cryptographic hashes at its base, should have extension points allowing the addition and use of stronger hashes at a later date as they are developed.
Many hashes are created for specific purposes or are proprietary. One such hash is the one created for the LAN Manager product from Microsoft and 3Com. The LAN Manager, LANMAN or LM, Hash is frequently used as an example of a hash that has long outlived its ability to protect against attack but has survived in use simply because there are so many old systems that use it, and it is therefore considered by some to be too risky to turn off, because applications that still use it may break. Such applications include older versions of Windows and non-Windows implementations of the server Message Block protocol used for network file sharing.
The LM Hash uses an encryption algorithm at its base—this is not unusual. It is relatively common to build a key from the clear text to be hashed, then use that key to encrypt some chosen fixed text (usually zeros) to produce a hash. In the case of the LM Hash, the encryption algorithm used is Data Encryption Standard (DES), which we shall describe later.
When an LM Hash is created from a password (as that is the designated purpose of the LM Hash), the password is converted to uppercase, padded with nulls to make it 14-bytes long, and then broken into two parts of up to 7 bytes each. Each of these 7-byte parts is used to generate a DES key, which is used to encrypt a fixed string (the string is “KGS!@#%$”—the programmer’s initials followed by the shifted numbers from 1 to 5 on a U.S. keyboard). The two 8-byte values produced in this way are concatenated to give a 16-byte value that is the final result—the LM Hash of the password.
If you’ve been paying close attention so far, you’ve probably spotted some of the problems with this—the biggest is that the 16-byte LM Hash is really two independent 8-byte hashes, each of which can be calculated separately; the second part is likely to be built from fewer than seven characters (simply because users will tend to choose the shortest passwords allowed) with fixed known characters (nulls) making up the remainder of the key.
There is no salt involved in the creation of the LM Hash, and so a collection of LM Hashes can be attacked en masse—by creating the LM Hash of likely passwords, and then comparing the calculated hashes with all the hashes in storage. Another problem with the lack of salt is that two users sharing the same password can be discovered and that tables of possible LM Hash values and their password equivalents can be generated and compared against any system’s stored hash values.
The bright side of this picture is that such bulk attacks require bulk access to databases of LM Hashes. These are not readily available in most systems—although there are specialist tools that can access this data, they generally require complete unfettered physical access to a system with the password database on board. Physically securing your data center and any Active Directory Domain Controllers is the best way to prevent abuse of LM Hashes if you still need to keep them in use.
Better still is to remove the LM Hashes completely and the ability to generate them. Windows Vista and Windows server 2008 no longer generate these hashes by default, and earlier versions of Windows can be configured to avoid the use of LM Hashes, too.
The replacement of the original LanManager Hash function was achieved with the NT LAN Manager (NTLM) protocol, which provides the ability to authenticate a user against either the LM Hash or the new “NT Hash.” Where possible, disabling the LM Hash at the Domain Controller means that the NTLM protocol will only use the NT Hash to verify authentication attempts.
The NT Hash is an MD4 hash of the user’s password—it is a true hash, and it uses the full Unicode character set available to Windows, where the LM Hash used only a limited subset of the US-ASCII character set. As such, it is less susceptible to brute-force guessing, or bulk cracking, if the passwords are strong.
The NT Hash is still not salted, and as a result, if you have physical access to a system, or otherwise have administrator access allowing you to read the password hashes, you can tell if two users have the same password, because they will have the same hash.
Digital signatures represent a combination of cryptographic hashes and asymmetric encryption.
One of the most frequently asked questions by novice developers of cryptographic applications is how to encrypt using the private key or decrypt using the public key—both of these operations are often forbidden by cryptographic frameworks. The reason is to prevent applications from accidentally using keys inappropriately and thereby posting freely decryptable text across a network.
If you think a while about what it would mean to have a piece of data encrypted using a user’s private key, you may be able to guess how someone might like to do this. Encrypting data with your private key does not protect it against interception—your public key is supposed to be public, and so you must assume that your attacker has a copy of it. So any data encrypted with your private key must be either public already or protected in some other way. By encrypting data with your private key, however, you make it clear that the file was encrypted by you. It’s like putting your thumbprint, seal, or signature on the file.
But remember how we said that asymmetric key cryptography is slow and expensive? If the document file is at all large, signing it by encrypting the whole file will take a long time, as will verifying the signature by decrypting it. Additionally, it would be handy if we could uncouple the verification of a signature from the document itself—perhaps if we want to read the document without verifying its signature, or spending a lot of time on decryption.
Instead, a digital signature is created by creating a cryptographic hash of the document to be signed and then encrypting the hash with the private key of the signer. This has several benefits—a single document can be signed by multiple parties, signature of any document is fast, a signature can be sent or held separately from a document or along with it. And because the hash is encrypted using the sender’s private key, any recipient can verify that it came from the sender, because only the sender’s public key will decrypt the signature and turn it into the hash of the document.
A digital signature based on a poor quality hash or encryption algorithm carries forward those quality problems to the signed document—so, for instance, it might prove possible to create a new document, similar to the original, but with important elements changed, and which generates the same hash value. This would mean that the signature of the original document would also verify the forgery.
[For those of you wondering how a digital signature can be created when the cryptography library prevents encryption using the private key, there are separate functions for signing data, which will calculate the hash and encrypt it with the private key to produce the signature.]
A certificate that you hang on your wall lists a limited set of qualities about you—claims that you make—and confirms them by the presence of a signature of a reputable body (see Figure 11.1).
Similarly, a digital certificate lists a set of claimed qualities about the person, organization, or computer identified in the certificate and confirms those claims by the presence of a digital signature of a reputable body. It ties those claims to a public/ private key pair so that the user of the private key can be verified as the subject of the claims in the certificate.
The subject of a certificate, the person, organization, or computer about which the certificate holds details is known as the Subject. The reputable body that signs the certificate is known as the Issuer.
The standard for digital certificates is the ITU-T X.509 certificate standard. There are a number of different versions of this certificate standard, at the time of writing version 1 up to version 3, each adding features over the last. X.509 is a standard for Public Key Infrastructure in general and covers other topics such as certificate revocation lists (CRLs) and certificate path validation rules.
FIGURE 11.1
Comparing a Paper Certificate to an X.509 Certificate
The X.509 standard specifies the binary representation of a certificate, and there are numerous standards for exchanging the certificate in various forms—for cross-platform use, distinguished encoding rules (DER) encoding should be used when exporting a certificate to a text-based medium (for instance, when the import process is via a text field in a browser); public key cryptography standards (PKCS) #12 encoding (Personal Information Exchange [PFX]) should be used when including the private key along with the certificate.
Certificates are public objects and possess only public pieces of information—whenever you see documents that talk about removing the private key from the certificate, they are missing the point. A certificate may be considered as being paired with a private key, dependent on a private key, related to a private key, but when you package the private key with the certificate, it is no longer just a certificate. It is then something else—a certificate store or a PFX/PKCS#12 file.
A typical certificate contains a list of information about its Subject, provided by the Subject when requesting the certificate, and verified by the Issuer when signing it (see Figure 11.2).
Some important fields are
Version—0, 1, or 2 representing versions 1, 2, or 3.
Serial number—this number is generated by the Issuer and should generally be an unpredictable number for greatest security. Many Issuers are still configured to issue serial numbers in sequence. The serial number only has meaning to the Issuer, as a means of tracking individual certificates that might be issued to the same name or with the same key.
Issuer and Subject names—these aren’t “names” as you or I would recognize them—they are generally entries in a hierarchical directory, such as “CN = www.whitehouse.gov, S = DISTRICT OF COLUMBIA, OU = Office of Administration, O = Executive Office of the President, L = Washington, C = US.” For most automated processes, it is enough that the “CN” entry should match the name that is being verified, whether it’s a Web site address, or an e-mail address, or some other value.
Valid From and Valid To dates—these are dates during which the use of the private key to represent the subject of the certificate is to be considered valid. This is not the same as saying that the certificate is not usable after that date. For instance, if I digitally sign a document in 2009 and you want to verify that signature in 2030, you will need a reliable means to check the certificate relating to the document—which is the certificate that was valid in 2009. Certificates never truly go away, they expire, or are revoked (see the PKI chapter for more on certificate expiration and revocation).
Public key—this is effectively one-third of the point of a certificate—remember that a certificate is a list of claims, signed by a reputable authority, and which ties the use of a public/private key pair to those claims.
FIGURE 11.2
A Typical Digital Certificate
There are several other possible attributes and claims that can be present in a certificate, but these are probably the most important.
Most certificates in current use are what the CompTIA Security+ Objective refers to as single certificates—single in the sense that they are independent of any certificates other than their Issuer’s.
The word “single” does not imply single use—these certificates may be used for a single purpose or multiple purposes indicated by values known as “Key Usage” and “Enhanced Key Usage” values. The “Key Usage” value is a set of bits that can be on or off, meaning any of the values listed in Table 11.1.
The Enhanced Key Usage values are stored as hierarchical numeric values—Object Identifiers (OIDs)—in a format called ASN.1. Unless you’re seriously into numbers as a form of entertainment, you won’t really need to understand much of the format of the OID, but to give you a flavor of some of these usages, we list the common ones in Table 11.2. Be prepared for the prospect that many of the certificates you encounter may have been issued under rules drafted before the related Enhanced Key Usage was defined, so for instance, the certificate for www.whitehouse.gov does not have “server authentication” in its list of Enhanced Key Usages!
Key usage value |
With this value set, the public Key can be used For: |
digitalSignature |
Verifying digitally signed documents |
nonRepudiation |
Verifying the claim that an action being performed is approved by the certificate’s owner |
keyEncipherment |
Encrypting a key for transport |
dataEncipherment |
Encrypting data other than keys for transport |
keyAgreement |
Exchanging information used to create a shared key |
keyCertSign |
Verifying a signature on a certificate |
cRLSign |
Verifying a signature on a certificate revocation list (see the PKI chapter) |
encipherOnly |
Encrypting data during a key exchange—requires keyAgreement to be set |
decipherOnly |
Decrypting data during a key exchange—requires keyAgreement to be set |
“Dual-sided certificate” is a term you will only encounter in the CompTIA Security+ Objectives and documents derived from them.
The more usual term for this is a “dual key pair” or “dual key certificates.” Two key pairs and two certificates are generated. One certificate and its related key pair is used for encryption, the other is used for data signing (and nonrepudiation) purposes. The key pair used for signing is generated and held by the user and is not stored in any kind of key management system outside the user’s control. The key pair used for encryption may be backed up in a key management system for later recovery.
The theory behind dual key pairs is that it allows enterprise use of certificates to cover two scenarios:
1. Data encryption, with the ability for later recovery of encrypted data in the absence of the user, by use of the restored key from key management
2. Peruser strong identification, with the ability to assert that any action approved by the user can be acknowledged by a document signed by that user’s certificate
To do these with one certificate and key pair alone would be impossible, since the requirement for recovery of the encrypting private key would conflict with the requirement for secrecy of the signing private key. This is particularly valuable in enterprises, where it is important to recover documents after an employee has left the company, but where it is still important to rely on the assurance that only the employee herself/himself could have digitally signed documents.
Implementation of a dual key scheme could be performed by process alone, with each user remembering to request two certificates using appropriate templates, but when there is operating system and application support for dual key certificate schemes, it is much less likely that a user will forget to protect their signing key.
Practitioners of information security rely on a number of different taxonomies to ensure that they cover their system’s security needs entirely. One of the simplest such groupings available is Confidentiality, Integrity, and Availability (CIA) (see Figure 11.3). (We would add logging/monitoring/auditing as the fourth unit that binds these together but that fourth unit is not generally aided by cryptographic technology.) A security solution should generally be assessed as to how well it fits each, and all, of these three categories. Let’s look at what cryptography can achieve for us here.
Confidentiality addresses a system’s ability to keep information hidden from those people, systems, and processes that are not meant to see it.
FIGURE 11.3
The CIA Triangle
Obviously, cryptography has a lot to say about this, particularly in the matter of encryption. Encryption is the process of taking a readable document and producing from it a document that is unreadable unless you possess a proper key to decrypt it. That provides confidentiality, but confidentiality is not an on/off switch that you either have or don’t. As we shall see later, there are various degrees to which an encryption technique will protect data from an attacker, and advances in mathematics, and quantum computing, continually threaten to make sudden changes to the degree of confidentiality that is conferred.
Hashes, too, contribute to confidentiality in that they can be used to store a verifying code for passwords and other information that should not be stored but will later need to be verified.
Integrity addresses a system’s ability to ensure—and to prove—that information being processed is the result of the application of approved processes to the original data.
What this means is that data cannot be modified without approval or where it is modified that such modifications are detected. This is clearly the territory of hashes and digital signatures—hashes for those cases when the hash itself is unlikely to be modified and digital signatures when there is a possibility of such modification or when you want to track who had the information at its last modification.
Availability addresses a system’s ability to be present and to provide data to its approved users.
It is often considered to be the reverse side of confidentiality—if I encrypt a document and then throw away the key, the document is very definitely confidential, but it is not available any more. However, availability also has a relationship with integrity—if a system maintains its integrity to such a degree that no data can be modified, that too is a reduction in the availability of the data.
For cryptography, availability generally refers to the correct implementation of key and certificate management and of the availability of cryptographic algorithms across the community of users. After all, it would hardly make sense to encrypt e-mail messages if the recipient didn’t use the same encryption algorithms as you, or if the keys required to decrypt those messages were tied to physical items (such as smart-cards and readers) that were not available at the place those e-mails were supposed to be read.
Nonrepudiation is a component of information security that tries to remove the possibility that someone could perform an action and then later claim that was not truly them, but someone using their name without permission.
An example would be someone who buys products from an online store using their credit card, and receives the product, but then claims that they did not actually authorize the card to be used for that purchase, and demands their money back. This is an example of the customer repudiating the transaction and is a significant problem with modern day credit card transactions. Because every transaction requires the credit card number be given to every vendor, it is very easy for a card holder to claim that they did not approve of a transaction, and because of legal requirements to combat fraud, credit card providers will force a refund, even when the vendor can show that products were shipped to the card holder’s address.
A signature on a purchase request goes some way to preventing this—then the purchase request becomes a legal document confirming that the products were indeed ordered by the person whose signature is on the purchase request.
In much the same way (but of course, much stronger), a digital signature can be used as proof that the owner of the key associated with the signature approved of, or at least was aware of, a document or an action. [How do you sign an action? You don’t—you sign a document approving an action and you demonstrate that processes are in place that would prevent the action from occurring without a signed approval.]
When comparing cryptographic algorithms, whether discussing encryption techniques or digital signatures, we often want to know how strong the algorithms are.
In much of the discussion above, we have talked about encryption, or hashing, or signing, as if those processes were Boolean operations—that they either do or do not, encrypt, hash, or sign the documents involved.
That’s true, for the most part, any algorithm that encrypts “strongly enough” is as useful as any other algorithm that encrypts strongly enough and any algorithm that does not do so is very difficult to realistically describe as “encryption.”
However, as mathematical techniques for cryptanalysis improve, the “strong enough” bar moves ever upward. An encryption algorithm’s strength is measured as the number of operations it takes, on average, to decrypt the data without knowing the key. At its introduction, the algorithm’s strength should be proportional to half the number of possible keys. So, an algorithm with 64-bit key length begins life with a theoretical strength proportional to ½264–that’s 263. As long as the algorithm is complex enough to provide that level of protection, it is as strong as its original design. This strength algorithm would be described as having 64-bit strength.
Mathematical advances in optimization of the algorithm’s decryption processes sometimes make it possible to “shortcut” some, or many, of the steps—a typical advance would reduce the complexity of the algorithm to 250 operations—significantly below the designed strength. That may still be above the strength required by your use of the algorithm, and as long as the “current best” optimizations do not bring the algorithm’s strength below the required strength, it is still usable.
Making this more complex is the requirement that you make these decisions for the future—when encrypting a document, you typically want it to be secure for more than just until the end of the week, and so you have to make an estimate as to what mathematical developments are likely over the next year or two, and possibly over the next decade or more.
Just as encryption algorithms are ranked by the number of operations required to produce a valid decryption without knowing the key, and this is balanced against the size of the key, so too hash functions are ranked by the number of operations required to produce a colliding document in one of the three scenarios that hash functions are designed to protect against—discovering a document based on its hash, creating a colliding document based on a hash, and creating a pair of colliding documents (two documents usually that share large portions and change in only a small area and which generate the same value when hashed).
Choosing the strength of encryption and hash algorithms by the number of bits in their keys or outputs is not a significant measure, except when comparing two algorithms of the same family—for instance, comparing SHA-256 against SHA-512. The latter is, at least in theory, 2256 times stronger than the former.
Comparing asymmetric key algorithm strengths against symmetric key algorithms is particularly difficult. Because asymmetric keys are generated, whereas symmetric keys are chosen from a completely random space, there is already a significant difference between key sizes. According to RSA, for instance, the strength of a 1024-bit RSA key is roughly equivalent to the strength of an 80-bit symmetric key; the relationship is not linear—for more information, see www.rsa.com/rsalabs/node.asp?id=2004.
When proposing cryptography-based solutions to my customers, I find it’s best to get past the fear factor with a simple mantra—I choose “Encryption is used when we would rather risk destroying the data, than risk it falling into the wrong hands.” It’s something that’s worth repeating over and over to remind yourself that data loss is what encryption is all about—both in the sense of “loss as destruction,” and “loss as exposure.”
Obviously, to maintain availability, as we discussed earlier, it is important to consider how to handle the inadvertent loss of a key, or how to prevent it, and how to manage a key’s life cycle.
The first question you should ask related to any key (this applies as much to a symmetric key as it does to the private key of a public/private key pair) is whether it is acceptable for anyone other than the key holder to be able to have access to the key. The initial reaction is to say “no, of course not”—but that may ignore the possibility that the key holder may deliberately or accidentally destroy the key.
If the key’s purpose is to identify the user, and you may need to point to use of the key as proof of the user’s involvement, then the answer is quite definitely that you do not want anyone other than the user to have access to that key. Such a key should be stored only in the users’ private certificate store, ideally on a smart card or other hardware device subject to antitampering protection.
The life cycle of such a key follows from creation through use, renewal, and finally to either revocation or expiration. It is the simplest of key life cycles.
Other keys may require the ability to be recovered on behalf of the key owner, or in some cases, on behalf of the organization to which the key owner belongs—for instance, to decrypt files after an employee has left the company.
The life cycle on such a key goes from creation, archive and distribution, through use, renewal and possible recovery, and finally heads to revocation or expiration.
You will read more in Chapter 12 on how keys are generated, archived in key escrow, and revoked through CRLs or Online Certificate Status Protocol (OCSP) requests and responses.
There are a number of encryption algorithms available for use and more are created over time. This list is by no means complete but represents some of the more important algorithms at the time of writing and covers the requirement for the CompTIA Security+ Objectives.
DES is another of those generic names that indicates it comes out of NIST. The DES algorithm uses a 56-bit key, and as you would expect from something with such a small key size, it is a symmetric key encryption algorithm—asymmetric keys are usually more than a thousand bits in length.
It is also a “block” encryption algorithm, meaning that it encrypts in blocks—in DES’ case, a block is 64 bits—one block at a time. While block ciphers are not in themselves designed to encrypt streams of data, it is possible to use what is known as a “mode of operation” to encrypt a stream using the block cipher. Modes of operation, such as Cyclic Block Chaining (CBC) or Cipher Feedback (CFB), are beyond the scope of the Security+ Objectives, but the interested reader should have no difficulty finding documentation to read.
Although it is technically beyond the scope of this document, the simple ingenuity of output feedback (OFB) is worth discussing, particularly as it pertains to creating a stream cipher from any block cipher. In OFB, the block cipher is used, with the encryption key, to encrypt a random value known as an “Initialization Vector (IV).” The resulting block of encrypted bits is used as a key stream to encrypt the plain text stream, by combining the two streams using an XOR operation. Whenever a new block of the key stream is needed, the previous block of the key stream is encrypted again using the block cipher and key. The IV will need to be known to decrypt the stream at the receiving end, and it is often sent in clear text at the start of the communication (see Figure 11.4).
FIGURE 11.4
The Overview of OFBs Operation
A stream cipher created using OFB has the advantage that, as described in the Queen’s Jewels earlier, a stream can be encrypted by a sender, encrypted again by the recipient, decrypted by the sender, and then decrypted by the recipient so that a symmetric key algorithm can be used to protect data without sharing a key. The decryption process is exactly the same as the encryption process except that the cipher text is used as input and the plain text is created as output.
As the name implies, “Triple DES” (3DES) is an algorithm built from three applications of the DES algorithm. Rather than the obvious process of running the DES encryption three times, 3DES first encrypts using DES and the first key, then decrypts using the second key, and finally encrypts using the third key. This method was chosen in large part so that a hardware implementation of 3DES could be used to also implement DES by setting all three keys to the same 56-bit value.
When applying an encryption algorithm more than once to a set of data, it’s important to do some heavy-duty cryptanalysis on the result to ensure that the repeated application of the algorithm does not cause leakage of information that could be used to decrypt. As you can see from the Caesar cipher we discussed above, in some encryption algorithms, the process of encrypting with two keys is the same as encrypting with one key. Worse, in some contexts (such as when the two keys add up to 26 in the Caesar example), the repeated application of the encryption algorithm leads to less security (or none) than the application of one key alone.
3DES has had much cryptanalysis thrown at it, and as a result, we can be fairly confident that it is more secure than DES. By using a different key at each stage, 3DES starts with triple the theoretical security of DES, and triple the key size, at 168 bits. A speed optimization may be to use a 112-bit key such that the first DES cycle and the third DES cycle use the same 56 bits as keys—this allows optimization of the internal state of the first and third DES cycles.
RSA, named after Rivest, Shamir, and Adleman, its inventors, is the name of a company whose focus is on public key infrastructure and cryptography, as well as the name of an asymmetric cryptography algorithm, which is why we encounter this abbreviation in this section on cryptographic algorithms.
Because the RSA algorithm relies on mathematical operations—particularly exponentiation—it is possible to apply it to any size of input, although there are some measures required in implementing the algorithm to ensure that small input does not cause an easy time guessing the plain text. A padding scheme is always used to ensure that there is some significant randomness in the input.
At the other end of the scale, too large an input to the RSA algorithm is a bad idea also, as the RSA algorithm can be quite slow. As such, the RSA algorithm—and most asymmetric key cryptographic algorithms—will generally be used only to encrypt an exchange of a suitable symmetric key for a stream or block cipher to be used for bulk encryption.
With Advanced Encryption Standard (AES), we return to the land of the generically named symmetric key block cipher, as the AES comes to us from another NIST competition to develop a good encryption algorithm, this time to replace DES as it became clear that DES was approaching a time when it would be easy to crack using relatively inexpensive hardware.
AES was the name NIST gave to the winner of the competition, which was previously called “Rijndael,” an amalgam of the names of its two designers, Joan Daemen and Vincent Rijmen. The AES cipher is actually a specialization of the Rijndael cipher, as the AES cipher has a block size of 128 bits, whereas the Rijndael cipher can have any block or key size from the selection of 128, 160, 192, 224, and 256 bits. The AES cipher supports key sizes of 128, 192, or 256 bits. The cipher is often known by its name and the number of bits of key—for instance, AES-128 and AES-256 are often supported ciphers and refer to AES with 128-bit and 256-bit keys, respectively.
Elliptic Curve Cryptography is another mathematically based technique for cryptographic operations, rather than being based in bitwise logic, and like RSA, can essentially be used with any size of key. The bit strength of Elliptic Curve encryption is theorized to be roughly half the size of the key—so a 256-bit elliptic curve cryptography (ECC) key has strength of about 128 bits, compared with an RSA key for the same strength, which would need to be 3072 bits in length.
Ironically, Elliptic Curves are also used in integer factorization techniques that make RSA seem likely to have a reduced life span. So, Elliptic Curves are causing the demise of the very encryption scheme that they are being used to replace.
Elliptic Curves are relatively recent but have so far survived very well against cryptanalysis.
One-time pads are the perfect encryption method and have been mathematically proven to be so. They are, unfortunately, very impractical.
The way a one-time pad works is that a stream of random characters (the one-time pad) is generated (see Figure 11.5) and distributed securely between the sender and recipient. The stream must be of at least the same size as the stream to be encrypted. When it is time to send the encrypted traffic, the plain text is combined with the stream of random characters, usually using a simple XOR combination, to generate cipher text. At the recipient’s end, the cipher text is decrypted by reversing the process.
FIGURE 11.5
Image of a Tear-Off Pad with Random Numbers
Obviously, the biggest flaw with this method of encryption is that the stream of random numbers or bits has to be shared between two people while remaining secret. Transferring a stream of bits securely is the problem that encryption is designed to solve, and here, we are solving it by requiring that you first transfer a stream of bits securely. That is only going to work if the threat to secrecy that you are trying to solve is reduced at the time or place that you exchange the random bit stream for the one-time pad. For instance, if you meet your recipient once a year, and generate the one-time pad at that time, you can exchange secret data later, when you and your recipient are separated by significant distances and perhaps one or two eavesdroppers.
Other flaws with one-time pads in practical use involve the problem of whether you can truly generate random bit streams, how to cope with the prospect that you do not know how many messages of what length you will be sending, and there are known issues with synchronizing if you get out of sync on the bit stream.
The S/Key protocol avoids much of this difficulty by using a single key to generate a one-time pad. The key is encrypted multiple times under the user’s control, and the result of that encryption is given to the authenticating party. The user can then authenticate by providing a value that, when encrypted once, results in the value held by the authenticating party. The authenticating party then holds the value the user gave them as the check value for the next time the user needs to authenticate. This is not truly the same as the theoretical one-time pad with its perfect security, as the strength of the authentication is limited by the size of the original key and the strength of the encryption protocol.
General-purpose encryption algorithms are often adapted to fit specific uses. Two such protocols that the CompTIA Security+ Objectives specifically call out are Wired Equivalent Privacy (WEP) and Temporal Key Integrity Protocol (TKIP), both invented to protect IEEE 802.11 wireless network traffic (also known as “Wi-Fi”).
WEP is particularly worth knowing about, if for no other reason than it is an object lesson in the old maxim “don’t write your own cryptography unless you are a cryptography expert,” along with its corollary, “you are not a cryptography expert.”
When the 802.11 standard for wireless networking was introduced, the only option to include privacy on the wireless traffic was WEP. As its name implies, the goal was to give you the sort of protection for your traffic that you would expect if you were connecting through a wire. That’s essentially marketing hyperbole, of course, because a wire presents significant privacy for your traffic—especially if you can see the wire from end to end.
Because there is money to be made in offering different strengths of encryption, WEP was offered in two strengths—64 bit and 128 bit. A later 256-bit version was offered by some vendors.
The WEP encryption algorithm used a 24-bit random IV and added to it the key bits generated by the user. For that reason, the 64-bit encryption used 40 bits of key, the 128-bit encryption used 104 bits of key, and the 256-bit encryption used 232 bits of key. These key bits were generally entered as hexadecimal values. The key and IV are used for an RC4 stream cipher, which requires generating a key stream that is then combined using the XOR operation to encrypt or decrypt data.
Obviously, the first major flaw with this algorithm is that 40 bits of keying material is really very small, particularly on a busy wireless network, where a large amount of traffic can be intercepted and analyzed in a small time. Because the key in use for this transmission was not changed during the transmission, nor was there any key negotiation, it became clear that WEP could be cracked, and eventually in less than a minute, by forcing the Access Point to generate large amounts of error traffic.
Even with the 128- or 256-bit versions of the WEP algorithm, however, the 24-bit IV led to the repeating of encrypted data, which allows an attacker to deduce the key stream, and forge data that the Access Point will accept as genuine.
While WEP was being broken by attackers, the Wi-Fi Alliance approved a subsequent TKIP. TKIP was approved as a part of the Wi-Fi Protected Access protocol (WPA).
TKIP uses RC4 as well but has several advantages over WEP—most notably, each data packet is encrypted using a different key, and instead of merely concatenating the IV and the key, TKIP combines them using a key mixing function. TKIP also uses a sequence counter, so that replay attacks fail, as the sequence counter is different when the replay attack is attempted.
WPA2, an update to WPA, also allows the use of AES as the basis of an encryption protocol instead of RC4.
You will no doubt have noticed by now that one common theme to all these cryptographic algorithms is that they are ephemeral. Their useful life span is measured in years, rarely decades. By comparison, Web browsers have been around for about a decade and a half; the underlying protocols of the Internet, Transmission Control Protocol (TCP) and Internet Protocol (IP), have been around for over three decades, essentially unchanged in that time, and with no plans to provide a complete replacement—even when IPv6 is widely deployed, the TCP on top of it, and much of the IP technology, remains unaltered, as will the use of HTTP for Web browsing.
Particularly because of the constantly changing list of reliable cryptographic algorithms, but also because it makes good engineering sense, the first thing that needs to be done when deciding to use cryptography is to agree between sender and recipient on a choice of cryptographic algorithm and to exchange keying information where necessary.
This process of agreement prior to exchange is defined in a “protocol” specification—just as in real life, a protocol is the set of agreed upon rules by which work is done rather than the doing of the work itself.
Some protocols are interactive between the two parties—where each side will say “here’s what I can do,” and between them they will choose a common cryptographic method that they will use for their communication. Other protocols are declarative in that the creator of the encrypted content will essentially say “here’s some content, encrypted using XYZ algorithm”; the reader of such a piece of data will either support or not support the algorithm defined in the protocol.
There are some specific protocols that the CompTIA+ Security Objectives have asked for you to be aware of.
Secure Sockets Layer (SSL), or Transport Layer Security (TLS), refers to essentially the same protocol but in different versions. SSL was originally invented by Netscape, the makers of the Web browser Netscape Navigator, as a means to allow credit card transactions to be carried out securely over the World Wide Web. Other browsers adopted SSL so that they too could perform secure credit card transactions.
As we discussed earlier, advising against creating your own cryptography, SSL 2 had some flaws that needed correcting; while Netscape produced SSL 3 to correct these flaws, Microsoft also developed its own private communication technology (PCT) standard, also correcting the flaws in SSL 3. These two competing standards, of course, had their own flaws, although these flaws were considerably less significant than the flaws in SSL 2.
In an effort to achieve a harmony of standards, as well as to address the flaws in SSL 3, Netscape allowed for automatic and royalty-free licensing of the SSL 3 protocol, and worked with members of the Internet Engineering Task Force (IETF) to produce a new unified standard based on SSL 3, and with lessons learned from SSL and PCT.
This new standard is called TLS, and although it is a new name, it is functionally a logical development from SSL. In fact, the version number embedded in a TLS 1.0 stream is “3.1,” essentially declaring that a TLS-capable client is actually an SSL 3.1 client.
TLS was first publicly defined in the IETF document Request for Comments (RFC) 2246, which can be found at http://tools.ietf.org/html/rfc2246—the current version at time of writing is TLS 1.2, which is available at http://tools.ietf.org/html/rfc5246. Those RFCs are linked for informational purposes only—RFCs in general are not easy to read, and the TLS RFCs are no exception. If you want to understand SSL or TLS in any depth—and particularly if you need to design or implement solutions based on SSL or TLS—I would recommend reading Eric Rescorla’s book “SSL and TLS—Designing and Building Secure Systems.”
From this point on, I will refer to TLS, but you should consider that most of what I describe in TLS will also apply to SSL.
TLS was designed as an extra layer on top of TCP/IP, but underneath an application, so as to make it easy to add TLS to an existing application. This means that TLS is divided into three sections—negotiation, communication, and closure. Four sections, if you count the inclusion of error information.
TLS is not completely a “black box” addition—there are some subtleties to developing an SSL/TLS compliant program—as such, you should be careful when choosing TLS programs to ensure that the developers thoroughly understood the protocol before beginning development.
The description below is of the process of a basic TLS session using a version at or after SSL 3.0. Some messages are the same with SSL 2, but since SSL 2 has been deprecated for over a decade and is deemed “noncompliant” by industry standards such as PCI DSS, it is not worthwhile discussing SSL 2’s behavior.
We will begin with a discussion of the negotiation process, which follows Figure 11.6.
FIGURE 11.6
A Normal SSL Handshake
The negotiation, or handshake, portion of TLS begins with one party behaving a server and the other acting a client. The TLS client starts by sending a clientHello message, which tells the server the highest version of TLS that it supports, and a list of the cryptographic algorithms—called Cipher Suites—it supports. The clientHello also contains a freshly generated random number (to be used later, in generating a shared key), an optional session ID, and a list of Compression Suites. Compression, if chosen, obviously must be performed before encryption and after decryption, because encrypted data should not have any recognizable patterns that would enable compression.
The server responds with a server-Hello, indicating one Cipher Suite that it has chosen from the list offered by the client and one Compression Method. The serverHello also contains a random number generated by the server, an optional session ID, as well as the highest version number of TLS that is supported by the server and the client. After the serverHello message, it sends a Certificate message, identifying itself to the client. The certificate message consists of a list of X.509 certificates, representing a chain from the first certificate (representing the server itself) up to a root that the client is asked to trust. The chain is optional and may be absent if the server expects that the client already has its Issuer installed as a trusted certificate. Finally, the server sends a serverHelloDone message, which indicates only that the server has nothing more to say.
Now the client sends a clientKeyExchange message, containing its half of the key exchange. There are two supported key exchange methods, RSA and Diffie Hellman. In the RSA method, a further random number, known as the Pre Master Secret, is encrypted by using the server’s public key (from the Certificate message), and this is used (along with the previous client and server random numbers) to generate a shared “master secret” and further keying material used by client and server and the Cipher Suite negotiated between them.
At this point, each side has all the material it needs to start encrypting using the shared key, and to indicate this, the client and the server will send a ChangeCipher-Spec message and a Finished message, which simply indicates that all traffic from this point forward will be encrypted and possibly compressed using the negotiated Cipher Suite and Compression Suite. After the ChangeCipherSpec message, the first encrypted message is sent—a Finished message, that contains a hash of the previous handshake messages sent by the sender. This is to ensure that the client and server can verify that they received exactly the handshake messages that were originally sent.
Once the TLS connection has been made and the session has been negotiated, further traffic is sent as a series of TLS data records, each of which is prefixed with 5 bytes of clear text—one byte for the record type value, two for the TLS version (in every TLS record), and two for the length of the record. The remaining bytes in the record are encrypted, and when decrypted consist of the data, a keyed Hashed Message Authentication Code (HMAC) summarizing the data traffic in this TLS connection so far, and padding values to allow data of different lengths to match the block size if a block cipher is chosen as the Cipher Suite.
Termination of the TLS connection is often ignored in applications that use TLS—and this is safe for protocols where both parties can reliably tell if all data has been successfully transmitted based on the data alone, for instance, if there is a content length field, or an encoding that allows the end of data to be signaled in stream. For protocols where it is important to tell the difference between a deliberate but unexpected closure of the TCP stream and an attacker’s injection of a “FIN” flag to close the stream, the closing party should always send a Close Notify alert, and the receiver should check for this and complain if it is not received before the TCP stream is closed. The Close Notify message is one of a range of Alert messages that can be sent to signal errors. For full details of these Alerts, please refer to the RFC or the SSL and TLS book referenced earlier.
There are two other forms of TLS negotiation you should be aware of. The first is a simpler form of negotiation, used when resuming an existing session (see Figure 11.7). In this case, the client sends a clientHello containing the session ID that it received in the serverHello when it previously established the session. If the server approves (indicating this by returning the same session ID in a new serverHello message), the server will send a ChangeCipherSpec and Finished message to which the client responds with its own ChangeCipherSpec and Finished message—as shown in Figure 11.7. The master secret and the key information built from it remain the same as negotiated at the beginning of the session, with new client and server random values to prevent replay attacks.
FIGURE 11.7
SSL Resume Handshake
The other TLS negotiation worth considering is for mutual authentication—where the previous negotiations contain a Certificate message only from the server; for a mutual authentication sequence, the server will request a certificate from the client by sending a Certificate Request handshake message. The client, if it has a suitable certificate, will send it in a Certificate message and will prove its ownership of the certificate by sending a Certificate Verify message, which is a string signed by the private key associated with the client’s selected certificate. A diagram of SSL mutual authentication is shown in Figure 11.8.
FIGURE 11.8
An SSL Mutual Authentication Handshake
The usual use case for TLS still remains the one for which it was originally designed: that of protecting World Wide Web transactions over HTTP. HTTP itself is a text-based protocol, which makes debugging and analysis by humans easy, but also makes theft of data in transit by humans and machines alike even easier.
HTTPS is the most native possible implementation of TLS with HTTP, and served for many years as the model for how TLS should be used. A new port was reserved—443 for HTTPS versus port 80 for HTTP—and all connections to that port would be considered to be using TLS from the moment they connected (and therefore, starting with a serverHello message) until such time as the HTTPS connection was terminated, leading to the implicit closure of the TLS connection.
S-HTTP, by contrast, does not use TLS at all but instead treats each HTTP request and response as an individual message to be protected using the Cryptographic Messaging Syntax (CMS) encapsulation protocol. This allows each request and response to be signed or encrypted, according to options specified on each resource available from the Web server. Of course, with such flexibility and individual control comes the price that S-HTTP is difficult to administer. HTTPS is sufficient for most sites and as such is the protocol most commonly used for providing protected content across the Web.
Many other TCP-based protocols have added options to use TLS to protect their content over the years—Simple Mail Transfer Protocol (SMTP), Lightweight Directory Access Protocol (LDAP), and Network News Transfer Protocol (NNTP) use a STARTTLS command to indicate a request from the client to use TLS, and FTP uses an “AUTH TLS” command with options to indicate whether commands, data, or both are clear or encrypted.
Secure/Multipurpose Internet Mail Extensions (S/MIME) offers signing and encryption of e-mail messages in a similar way to the S-HTTP protocol—in S/MIME, the components being signed or encrypted are the MIME parts of the message. Again, CMS is used with some minor modifications to fit the CMS protocol in with MIME.
By using detached signatures, where one MIME part containing clear text is signed to provide a separate MIME part containing its signature, S/MIME signed messages can be sent without worrying about whether or not the recipient is capable of displaying or interpreting S/MIME messages. A recipient who is unable to process the S/MIME part will simply see the text message without the ability to verify the signature on the message.
Because S/MIME messages are sent across a transport medium that does not allow for both endpoints to be connected and communicating at the same time, an S/MIME encrypted exchange usually starts with an unencrypted message signed by the sender’s certificate. This message includes a SMIMECapabilities attribute, which describes the preferred encryption protocols supported by its sender. The recipient of this first message now has all the ingredients needed to respond with encrypted data—a certificate, with which the message was signed and which can be used to encrypt the Content Encryption Key (CEK) in their response.
Comparing S/MIME with SMTP/TLS provides an even greater contrast than between HTTPS and S-HTTP. Remember that SMTP mail transport is often achieved over multiple hops, and with the possibility that not all hops are active at any one time. As a result, SMTP/TLS can only secure one link at a time—it is possible that even if you connect to your local SMTP server using TLS, it may not necessarily connect to the next SMTP server in the chain with any protection whatever. S/MIME, on the other hand, provides protection on the message at all points from sender to recipient—it even protects the message from the SMTP servers that carry it!
So, while S-HTTP is generally seen as too much of a good thing to be implemented, and HTTPS is chosen as the default, in e-mail, S/MIME is generally chosen over SMTP/TLS, because S/MIME protects the mail itself, rather than the transport of the mail across a single link.
Secure Shell (SSH) was invented in 1995 in an attempt to prevent password-sniffing attacks on the rlogin and Telnet protocols commonly used for shell (console) access to UNIX systems.
Since then, SSH has developed into more than just a shell access tool, and operates as a secured network layer, equivalent in many ways to SSL and TLS. There are some significant differences that are worth commenting on:
While TLS sits as a thin layer between the application and the transport layer (usually TCP), SSH essentially provides its own transport layer on top of TCP. Applications can be made to execute through an SSH tunnel, without any change to the application—though this can be problematic for applications using protocols such as FTP, which opens different ports throughout the communication. The usual method of tunneling FTP over SSH is to tunnel only the command connection (control channel) through encrypted SSH and to allow the data to continue to flow unprotected on regular ports.
SSH authenticates using public and private keys but does not take advantage of a PKI to verify trust. Trust is assigned one host at a time, by the client user accepting an offered public key as being associated with the host to which the client is asked to connect and by the client checking that key every time it connects. This can make the deployment of SSH time-consuming in an enterprise environment, where trust would be indicated in TLS by adding a trusted enterprise root certificate to issue all enterprise-owned certificates. However, because each connection is initially confirmed by a human being, this can be seen as avoiding the problems encountered in making a TLS connection to a server whose CNAME does not generally match its host name.
SSH is generally provided along with a small suite of applications—the SSH client/server application itself to replace rlogin and Telnet; the SFTP application to replace FTP; the SCP application to copy files securely and utilities to manage the relationship between public keys and trusted partner hosts. Although these replace existing applications, they generally do not work the same as those applications and cannot be treated as drop-in replacements.
SSH is popular among Linux/UNIX users and mostly spreads out from the community of open source admirers. Microsoft Windows does not natively support SSH nor does Microsoft offer any SSH implementations or toolkits, which can make it difficult to ask for your partners to use SSH-based protocols if they are Microsoft-heavy environments.
While SSH has recently become an IETF documented standard with RFC documents, some aspects are still not standardized or fully documented—particularly, SFTP has never been standardized, and interoperability can be problematic as a result, with different implementations expecting slight differences in behavior. FTPS (File Transfer Protocol over Transport Layer Security) by comparison has been an RFC standard since 2005.
SSH and SSL are often compared, but while they both achieve the aim of secure communications protected by public key authentication, they do so in different ways. When assessing the need to protect communications, both options should be considered, depending on who you are connecting to and what the communications will focus on.
IPsec, by contrast to SSH and SSL, works below the transport layer and above the IP packet layer. By adding IPsec rules to your connections, you can allow any application that uses an IP-based protocol (even UDP apps!) to take advantage of the security offered by IPsec.
IPsec contains two security mechanisms for general data—Authentication Header (AH) and Encapsulating Security Payload (ESP). The other part of IPsec, Internet Key Exchange (IKE), operates before communication protected by AH or ESP, to establish a Security Association (SA) between two hosts, negotiating between those hosts to authenticate, as well as to agree on encryption methods and keys.
IKE can authenticate parties and establish encryption keys by using public keys or by using a preshared key (PSK)—this would be a passphrase or other secret combination of characters that is communicated outside the connection between the systems to be connected and must be the same on each of the two hosts. A PSK can be created for several connections, and PSKs between different connections should be different to avoid possibility of confusion or spoofing of traffic.
Each IKE negotiation results in two SAs, one inbound and one outbound, at each host. Obviously, one host’s inbound SA will match the other host’s outbound SA and vice versa. The SA consists of an IP address, a Security Parameters Index (SPI), and the key associated with the SA. The SPI is simply a random number generated by the host that created its associated key and along with the IP address of that host can be viewed as an index into the database of SAs.
IKE operates over UDP, on port 500, and negotiates using a number of different methods (as described above—public key encryption, X.509-based certificate signing, or PSKs) to exchange nonces—random numbers—that are used to generate keys for the actual data protection (see Figure 11.9).
Once the IKE exchange has taken place between two hosts, the actual traffic can be started. It is a common myth that with IPsec, all traffic is encrypted—this is only true for traffic protected by ESP. When using IPsec to segment networks (such that a shared network can be broken up into several virtually separated networks of IPsec-supported computers), the AH protocol is all that is required to achieve such authentication.
FIGURE 11.9
A Sample of IKE Operation
AH operates as IP protocol number 51 (thus is neither UDP nor TCP and does not have an associated port number) and inserts a header into each protected data packet containing the SPI of the negotiated SA to which this packet is associated, a Sequence Number to prevent replay attacks, and an integrity check value (ICV), which is generally a keyed MAC of the AH header (excluding the ICV) and any data following it (see Figure 11.10). This allows each packet to be verified independently of any other packets (other than the key exchange performed by IKE).
ESP operates as IP protocol number 50, and its IP header contains the SPI of the connection, a Sequence Number to prevent replay attacks, encrypted payload data (the IP packet that has been encrypted), encrypted padding to align the payload data with block sizes for block ciphers, an encrypted Next Header value, and an ICV just as in AH protocol. The Next Header value refers to the header inside the payload data rather than a header following the ESP header—there usually is no such following header, but the decrypted payload data can be considered to be the logically following data.
Authentication is technically optional for ESP, but practically it would be unwise to operate ESP without authentication, as this provides encryption but no verification of identity in either direction. Without authentication, you would know that there would be no eavesdroppers between you and the endpoint to which you are communicating—but how would you know that the endpoint is not an eavesdropper engaged in a man-in-the-middle attack?
The ICV in ESP protects the integrity of the contents of the ESP header (payload data included) except for the ICV itself (see Figure 11.11).
Comparing IPsec to the protocols we have discussed before, it is clear that there are some advantages and some disadvantages.
IPsec authenticates hosts to one another and cannot authenticate users. This can be an advantage or a disadvantage, depending on how you need to authenticate. Obviously, there are numerous authentication methods that authenticate users and which can be run over the top of IPsec.
IPsec protects any application, without that application being aware of its being protected. This means you do not have to get special versions of your application that support IPsec—but it does mean that the application typically is unaware that it is being protected, so the application cannot generally make decisions to throw away its own protection measures if they are unnecessary.
FIGURE 11.10
An AH Header Format
FIGURE 11.11
ESP Header Format
IPsec requires that routers accept and pass protocols 50 and 51—some routers are not configured (or configurable) to do so.
IPsec builds its ICV, and creates its SA, over values that include the IP address of each host—this makes it difficult to use across a Network Access Translation (NAT) router. To deal with this, an encapsulation known as NAT-Tunneling (NAT-T) was developed. This has been criticized for revealing internal IP addresses, but there is really no way around that when NATs are in use.
IPsec ESP can operate either in Transport mode, in which it uses addresses on the local network, or in Tunnel mode, in which the source and destination IP addresses inside are from different physical—and logical—networks than those that are carrying the outer packets. As we shall see later, this Tunnel mode is used for creating virtual private networks (VPNs).
IPv6, if you choose to deploy it, offers some advantages to IPsec users. First, all IPv6-capable systems are required to support IPsec. Additionally, because there are no NAT devices for IPv6 (they are not necessary), there is no need to use NAT-T when carrying IPsec traffic. This may make it easier to adopt IPsec in future.
VPNs offer the allure of being physically present in one location, while behaving as if attached to the local network of a different location entirely. To truly be a VPN, the traffic shared among devices on the VPN must be protected so as to provide confidentiality, integrity, and authentication (see Figure 11.12). Confidentiality satisfies the privacy aspect that implies outsiders should not be able to see traffic, integrity satisfies the privacy aspect that outsiders should not be able to change or prevent the network traffic, and authentication satisfies the aspect of privacy that says you have to be able to distinguish between insiders and outsiders.
FIGURE 11.12
A VPN in Use
Point-to-Point Tunneling Protocol
Point-to-Point Tunneling Protocol (PPTP) is the oldest of the VPNs under consideration here and unsurprisingly is the least fully featured or secure by itself.
Described in RFC 2637, it is a relatively simple encapsulation of the Point-to-Point Protocol (PPP) over an existing TCP/IP connection. It consists of two connections (perhaps more in multilink environments, although this is less common today)—the control connection is a TCP connection to port 1723 and the IP tunnel connection is carried over the Generic Routing Encapsulation (GRE) protocol, carrying the user’s data itself.
PPTP connections can be established in either direction, although it is more common in the TCP/IP case for a client to initiate the connection—the call-back scenario was more commonly supported for dial-up access to systems. The control connection is established first, and a Start-Connection-Request message is sent, which the other party responds to with a Start-Connection-Reply message.
Once the control connection itself has been established using these messages, the client sends an Incoming-Call-Request message to the server, requesting that a tunnel connection be created. The server responds with an Incoming-Call-Reply message, which the client needs to acknowledge with an Incoming-Call-Connect message. These Incoming-Call messages negotiate a pair of random Call ID numbers associated with each end of the connection—these Call IDs uniquely identify traffic in the GRE tunnel, so that the same tunnel can contain multiple Call IDs, in case multiple users need to make VPN connections to the same server.
The GRE data traffic then can begin and consists simply of PPP packets encapsulated in the GRE header. The Call ID is included in the Key field of the GRE header, along with the packet’s length, an optional Sequence Number, and acknowledgment number.
Closure begins with a Stop-Connection-Request, which the other party responds to with a Stop-Connection-Reply, after which the TCP connection between client and server is severed. To prevent resources being used by an inactive session, a “keep-alive” or echo packet is sent periodically—if the keepalive has not been received or responded to in 60 s, either side may disconnect the TCP connection and discard any further traffic through the GRE protocol for that connection.
As you can tell from the description, this is a very simple protocol and does not consider security in itself. Security requirements of PPTP are left to the PPP portion of the traffic.
PPTP connections can be authenticated through the PPP layer using Microsoft’s MCHAP (Microsoft Challenge Handshake Authentication Protocol) or the EAP-TLS protocol. Encryption can be provided by the Microsoft Point-to-Point Encryption (MPPE) protocol, which is based on RC4 with session keys of 40-bit, 56-bit, or 128-bit length.
Because PPTP is so simple, it is frequently implemented, even in non-Microsoft operating systems such as Mac OS X and Linux. As a simple protocol, it is ideal for small low-power devices, such as mobile phones and personal digital assistants (PDAs).
PPTP’s biggest failing, besides its passing of security considerations to the underlying PPP protocol, is that it uses a protocol (GRE) other than TCP or UDP, which may be blocked at firewalls, NATs, and routers.
Layer 2 Tunneling Protocol (L2TP) was defined originally in RFC 2661, with the current version, L2TPv3, defined in RFC 3931. The name refers to the fact that Layer 2 (the same layer as Ethernet) traffic is tunneled over UDP, a Layer 4 Protocol.
Unlike PPTP, L2TP uses one data stream only on UDP port 1701. L2TP packets are divided between control and data by a flag in the header. Because L2TP operates over UDP, it has to implement its own acknowledgment and retransmission mechanisms for the control messages it uses.
Like PPTP, L2TP uses PPP to encapsulate data traffic that is sent across the tunnel, and connections or “calls” are created and torn down over the implied circuit created by the UDP traffic to port 1701 at the server. The server responds to whatever port the client sent its UDP messages from—this may be port 1701, but is generally a random port number.
Instead of connections and calls, L2TP sets up tunnels and sessions, for similar purposes.
The L2TP negotiation consists of data exchanged over UDP, beginning with a Start-Control-Connection-Request, containing a Tunnel ID used by the initiator to identify its end of the connection. The recipient responds to this with a Start-Control-Connection-Reply, containing its own Tunnel ID, and acknowledging the Tunnel ID of the initiator. The initiator then sends a Start-Control-Connection-Connected message, indicating that it accepts the Tunnel ID from the recipient.
Just as in the PPTP case, the negotiation continues from this point to establish a Call, beginning with an Outgoing-Call-Request, followed by an Outgoing-Call-Reply. These messages contain the session IDs to which this call is associated, as well as a Remote End ID value (also known in some documentation as the Assigned Call ID), which is a unique identifier for the call being attempted. A final Outgoing-Call-Connected message completes the handshake, and data can flow, marked with the Tunnel IDs and Call ID to ensure that it can be uniquely distinguished from other traffic.
Again, as in the PPTP case, there is a message to disconnect a call and a message to disconnect a tunnel—these are the Call-Disconnect-Notify and Stop-Control-Connection-Notification messages.
If it sounds like L2TP is PPTP with a few different names, that’s because L2TP was designed to include the best features of PPTP and Cisco’s Layer 2 Forwarding (L2F) protocol.
FIGURE 11.13
L2TP/IPsec Packet Showing Multiple Levels of Encapsulation
L2TP’s main usability benefit comes in its use of a single pseudoconnection over a protocol that is forwarded by most routers, UDP. L2TP’s biggest security benefit also comes from the use of a well-defined protocol—Ipsec. L2TP is most often used as a VPN by combining it with Ipsec ESP so that VPN traffic is encapsulated in five layers (see Figure 11.13):
1. PPP
2. L2TP
3. UDP
4. IPsec ESP
5. IP
Although this might sound confusing, the L2TP/IPsec VPN is a common method of maintaining trusted and encrypted connections from machine to machine across uncontrolled external networks.
Most of our discussion to date has been about cryptography in transit—talking about how to protect data sent across the network. This is because it has often been assumed that the network is the most unsafe environment for private data. With increased use of laptops, third-party data centers, and hard drive backup storage, it has become clear that protecting data “in flight” should include protecting that data in storage on the operating system.
Over the years, this has seen a number of developments in encryption technologies, leading to the widespread deployment of cryptography within most enterprises.
The first application of encryption to stored data was that of file and folder encryption. In many cases, this encryption is carried out in a rather manual and ad hoc manner—running an application to encrypt a file, then running the companion decryption application when the file was needed to be edited. For folders, often an archiving utility was used that would compress and store a folder (or a set of files) into the archive file, which was encrypted. The Zip format is one example of an archive format that supported encryption of its compressed archives, initially using RC4 encryption, and in current incarnations using the AES algorithm with 128 or 256 bits.
With Windows 2000, Microsoft added a more automated approach to file and folder encryption by adding its Encrypting File System (EFS) to the file system used in Windows—New Technology File System (NTFS). EFS has continually been added to in subsequent releases of the operating system, with new encryption algorithms such as AES replacing the original DES and 3DES and new options for encryption and recovery of encrypted files.
A file is encrypted either when it is moved into, or created in, a directory that has been flagged as “encrypted” or when the file itself is flagged for encryption. When first encrypted, a file is protected so that only its owner and the system’s Data Recovery Agents (DRA) can access it. There may be zero or more DRAs, but the default is for the local administrator account, or in a domain environment, the first domain controller’s administrator account to own the DRA key.
Once a file has been encrypted in EFS, it can be made available to other users by adding them to the list of allowed users (see Figure 11.14).
FIGURE 11.14
Adding Allowed Users to an EFS File
The process of encrypting a file in EFS begins with the creation of a random File Encryption Key (FEK), which is the key for the symmetric algorithm used to encrypt the data of the file (see Figure 11.15). This FEK is itself encrypted by using the public keys of each user who has been added to the list of allowed users, with one encrypted copy of the FEK for each user. These encrypted FEKs are stored in the metadata for the file in a file attribute called $EFS. Note that allowing access to the FEK is not related to the NTFS permissions on the file—a user must have appropriate NTFS access permissions to read and write the $EFS attribute or the encrypted bits of the file itself, but can only do so if they possess a private key that allows them to decrypt the FEK.
FIGURE 11.15
EFS Using an FEK to Encrypt a File
Particularly worth noting is that while EFS-encrypted files are not decrypted to disk when they are opened by applications, any process that involves reading from the files and writing them out again will generally remove the encryption. Copying an EFS-encrypted file within a local system retains the encryption, as long as the target directory is NTFS. Copying an EFS-encrypted file across the network results in the decrypted contents of the file being transmitted over the network and then re-encrypted on its arrival.
As we have already discussed, encryption of e-mail is generally performed in one of two ways—either by encrypting the network connection using SMTP START-TLS or POP3-over-TLS or by encrypting the message itself using a protocol such as S/MIME.
Encrypting the connection between mail client and mail server—or more properly, the mail user agent (MUA) and the mail transport agent (MTA)—is particularly useful when the authentication method chosen is that of a simple username and password. By encrypting the connection itself, a user makes it impossible for anyone listening in on the network stream to read their password.
Encrypting and/or signing the message itself allows for that message to be encrypted and signed while it sits in storage, allowing the message to remain protected for the foreseeable life of the message. Again, as with file and folder encryption, it is possible to copy data out of an encrypted message and save it to an unencrypted format. Preventing this copying of encrypted content to a plain text version would require the use of a digital rights management (DRM) technology.
The first “portable” computer I ever used weighed 23½ pounds; as computers get lighter and lighter (my current laptop is 5½ pounds), they get easier to steal. As they get smaller and smaller, they get easier to lose. One reporter for Newsweek even complained that he cannot find his laptop and thinks it was thrown out with the recycled newspapers by his wife. Perhaps he should not put his laptop in a manila envelope even if that’s what they do in the commercials.
Laptops are an easy target for thieves, as they are quick to steal, and often have significant monetary value not only in themselves as a free computer, but also in the data they contain, as personal details and bank information can raise a high price on the black market.
To reduce the cost of this threat to their organization’s data, most enterprises have taken to requiring encryption of their laptops’ hard drives. Rather than rely on EFS and a user’s individual preferences as to which documents are secret, and which should be publicly available, these enterprises choose to encrypt the entire hard drive as a complete unit.
As with EFS, the data itself is encrypted using a common cryptographic algorithm, such as AES (with a 128-bit or 256-bit key), and an algorithm that chooses a predictable IV for each block of the hard drive. This allows for individual blocks on the hard drive to be read from and written to randomly without having to store an extra value with each block, which would dramatically reduce the hard drive’s available space. In Microsoft’s implementation for Windows Vista and Windows server 2008, called BitLocker, the key that is used for this encryption is known as the Full Volume Encryption Key (FVEK). This FVEK is stored at several places throughout the disk to cope with the possible catastrophe of damage to the disk, and each place it is stored, it is encrypted using extra keying material chosen by the user. This keying material may be a large binary key stored on a USB key, or a key derived from a password or passphrase, or a combination of both.
One final possibility for encrypting the FVEK for its storage on disk is the use of a Trusted Platform Module (TPM) chip—a specialized piece of cryptographic hardware which is designed to hold secret keys and to use them to decrypt data upon request without revealing the key.
The longest portion of the encryption process is that of initial encryption (also any eventual full decryption or full reencryption in the case of a compromised key), where the entire disk must be read, encrypted, and written again. During this process, the disk can still be used—the initial encryption will only encrypt those blocks that are not already encrypted, and any write access to areas of the disk that have not yet been encrypted will cause encryption to occur naturally, ahead of the full disk encryption scan.
Once a disk has been encrypted, the overhead of encrypting and decrypting data is minimal—typically much less than 10 percent. This is because the encryption or decryption of one block can be done while waiting for the next block to be read from, or written to, the disk.
You should note that Microsoft’s BitLocker is far from being the only technology for Whole Disk Encryption—there are many solutions from companies such as Pretty Good Privacy (PGP) and Utimaco, as well as open source solutions such as TrueCrypt. However, they all work very similarly to BitLocker in that there is a key, an encryption algorithm, and an algorithm for choosing an IV by the physical location on disk of a block; the key is protected by a user’s choice of keying material, and once this keying material has been provided, and the volume encryption key is in memory, the rest of the operating system behaves as if the drive is fully decrypted.
As we briefly mentioned above, the TPM is a relatively recent addition to a computer’s arsenal and is a specialized, tamper-resistant, hardware device designed to engage in a few simple cryptographic operations.
As with most cryptographic systems, the TPM has a single root key called the storage root key (SRK), which is strongly protected inside the TPM, and is used to protect all the other keys the TPM device handles. In addition to the SRK, the operating system can request a number of other key pairs to be generated and encrypted (or “wrapped”) with the SRK such that the private key is only available inside the TPM for decryption or signing operations.
In addition to wrapping a key, the TPM can “seal” the key such that it can only be used in the event that a number of system measurements (selected at the time of sealing) are the same that they were when the key was sealed. These system measurements include the BIOS code and settings stored in the computer’s firm-ware, as well as the boot sector of the disk. By carefully writing BIOS and boot code to exploit this sealing against system measurements, it is possible to ensure that a boot environment has not been modified since it was created and to use that assurance to decrypt a volume encryption key for Full Volume Encryption.
In this way, the presence of an unaltered BIOS, boot disk, and TPM can itself be used as the source of keying material for a disk encryption suite such as BitLocker to ensure that the system is only able to boot if it has not been tampered with. This protects, in large part, against laptop thieves who either attempt to read the hard drive without the system being booted normally or who try to modify the operating system as a method of gaining access to the encrypted hard drive.
Use of a TPM and Full Disk Encryption is not sufficient to guarantee complete protection against theft; however, a thief could still boot the operating system and use a network exploit, or DMA-based interface such as FireWire, to attack the running operating system through its external ports, and gain access to the decrypted hard drive in that manner.
For this reason, a well-protected laptop is one that has full disk encryption that relies on both a TPM and some form of external keying material, such as a passphrase or a USB key. The last component in this scenario is a well-trained user, who knows to keep the USB key separate from the laptop, to not write down the passphrase and store it with the laptop, and to turn off, or hibernate, the computer when leaving it in an environment where there is a risk of theft.
For the most part, of course, a laptop thief is likely only to wipe the system completely to sell it to a trusting buyer, so most laptop thefts are unlikely to cause a breach of data protection—however, because there is a chance of such a breach, and the cost to reputation of having to admit to that breach possibility is so great, encryption is a cheap way to ensure that data is not only protected, but is seen to be protected.
In this chapter, we have given you a brief introduction to many of the cryptographic concepts, algorithms, protocols, and applications that are in widespread use today.
We discussed the difference between symmetric key (or secret key) and asymmetric key (or public key) cryptography and the strengths and weaknesses of each technique.
The use of hashes, and specifically the SHA, MD5, LANMAN, and NTLM hashes, were discussed, along with how the use of asymmetric key encryption of a hash with a private key leads to the concept of a digital signature. On the digital signature, we built the concept of a certificate and identified the difference between a single certificate and a dual-sided certificate.
Next, we addressed how the use of cryptography applies to the classical security triangle of CIA before moving on to address the way that digital signatures and encryption could lead to a nonrepudiation solution, allowing a user to demonstrate that they could not deny authorizing a document.
Comparing the strength of algorithms was our next point of discussion, along with the key management techniques that are necessary to ensure that encrypted data have maximum appropriate availability.
To ensure that you have a thorough grounding in the most commonly used encryption algorithms, we then discussed specific algorithms, namely, DES, 3DES, RSA, AES, Elliptic Curve Cryptography, and one-time pads. Building on those algorithms, we covered the application of cryptography to cryptographic protocols, starting with the wireless protocols WEP and TKIP, and then leading into the more general network protocols, SSL/TLS, S/MIME, SSH, and IPsec. IPsec led us in to the concept of a VPN, with the assistance of IPsec being very useful in securing the two protocols PPTP and L2TP.
Finally, we discussed the use of cryptography in operating systems and storage, particularly relating to file and folder encryption, e-mail, Whole Disk Encryption, and the TPM hardware component.
Asymmetric key cryptography and symmetric key cryptography offer different benefits and difficulties while they each protect data from being seen by unauthorized third parties.
Cryptographic hash algorithms use one-way functions to create a uniformsized “digest” of a message, with the properties that two similar documents will produce vastly dissimilar hashes, and that it is computationally infeasible to produce two documents with the same hash or one document that will produce a given hash.
Combining asymmetric key cryptography with hashes to produce digital signatures enables the creation of signed documents such as X.509 certificates, which are used to allow trusted third parties to assert identity claims on behalf of the certificate’s subject.
Block ciphers encrypt fixed-size blocks at one time—they can either be used with fixed-sized blocks, or padding, or using a chaining technique such as OFB, CBC, or CFB to create a stream cipher.
Stream ciphers encrypt streams of data, as many bytes at a time as you need—usually, a stream cipher generates a key stream, which appears random, and is combined with the data to be encrypted or decrypted, usually using the bitwise XOR operation.
Wireless Transmission Protocols have progressed from the use of WEP, which can be broken in seconds, to the use of AES, in WPA2, which has not yet been broken.
SSL and TLS are two different names for versions of the same basic underlying protocol, which is commonly used in secured Web transactions today. SSL/TLS make use of X.509 certificates for authentication and key exchange, symmetric key cryptography for stream encryption, and keyed HMACs for integrity.
S-HTTP and S/MIME protect the individual messages so that they may be protected in storage as well as in transit, whereas HTTPS and SMTP-TLS protect only the communication channel between endpoints.
Combining IPsec with L2TP results in a secure VPN between a client and a VPN server so that the client behaves as if it was directly connected to the same network as the VPN server.
EFS provided natively in Microsoft Windows since early versions of Windows NT server provides automatic file-level encryption that allows for sharing between multiple users and recovery through the use of a DRA. The same functionality can be had for other operating systems by using third-party applications and tools.
Whole Disk Encryption allows for protection of data held in storage on a laptop’s hard drive even after the laptop is stolen.
A TPM allows measurements of the BIOS, boot sector, and other components’ configuration to be used as keys to unlock encrypted drives and other secrets.
Q: Are the public and private keys interchangeable?
A: Not generally, but it should depend on the algorithm. The public and private keys are developed using different algorithms from one another, and it may be possible to derive the public key from the private key. Because the public and private keys are used for different operations, they are often designed to have different mathematical properties.
Q: What are the separate operations that a public or private key can be used for?
A: The public key is used for encryption and for verifying signed hashes; the private key is used for decryption and for signing hashes. While verification of a signed hash is technically a decryption operation and signing a hash is technically an encryption operation, it is best to think of these as separate from general encryption and decryption, because of the fixed sizes of hashes.
Q: Why does a digital signature encrypt a hash of the document rather than the whole document?
A: There are a couple of reasons—first, the cryptographic algorithms have been analyzed for signing a hash rather than a large document, and second, the encryption process is slow on large files, whereas calculating the hash is fast.
Q: Why are the symmetric and asymmetric key sizes so drastically different for the same strength?
A: Symmetric keys can essentially be picked entirely at random, but creating an asymmetric key requires generating it from the random source and a large number of mathematical restrictions, which will build up the size of the key as required.
Q: Why are so many of these algorithms based on block encryption rather than stream encryption?
A: Because encryption algorithms and hash algorithms are often designed to swap and manipulate bits that are separated from one another by more than 8 bits, they work well on wider numbers of bits than a simple stream cipher would do. As we discussed earlier, there are several proven techniques for creating a stream cipher from a block cipher, so it really doesn’t matter which you use for many operations.
Q: You describe one-time pads as the “perfect” encryption method—why is that?
A: A stream cipher’s design mimics the creation of a series of random bits and the combination of those bits with the plain text to create cipher text. A onetime pad doesn’t just mimic that, it perfectly is that—a one-time pad is a series of random bits that can be combined with the plain text to create cipher text.
Q: Both WEP and TKIP use RC4—if WEP can be broken, why isn’t TKIP broken yet?
A: WEP made many mistakes that TKIP hasn’t copied—TKIP repeatedly cycles keys, it uses a large and random IV, and it takes active protection methods against a detected attacker.
Q: Your diagram shows a negotiation for client certificates or mutual authentication, but this is not the behavior I observe on my Web server when I enable client certificates. Why is this?
A: Microsoft’s Internet Information server (IIS) and possibly others do not do the simplest version of this exchange when they connect. By default (and the behavior can be changed to work as in the diagram for better performance), IIS will first complete an SSL handshake without asking for a certificate from the client, and then, if client certificates are enabled, it will request a renegotiation with the client, during which it will perform a client authentication handshake.
Q: You mention the use of a keyed HMAC to provide integrity for the TLS traffic—I thought the traffic was encrypted, doesn’t that provide integrity enough?
A: No—without the HMAC, it would be possible for an attacker to flip a bit (or several bits) in the stream, if the attacker knew that flipping those bits would cause an interesting effect. Remember that with the way that stream ciphers are generated, a single bit in the plain text stream is represented by a single bit in the cipher text stream, and a change to that bit in one stream will be indicated by a change to the bit in the other stream. The stream will decrypt, and the decryption routine will not detect any failure, although the bit(s) selected by the attacker will have been flipped. Unless there is additional verification of the content of the stream, the attacker could change the stream unnoticed.
Q: Are there other VPN types than PPTP and L2TP?
A: Yes—in recent years, SSL VPNs have become successful. These VPNs work over an SSL-encrypted TCP connection, usually using the HTTPS protocol, because this protocol is typically allowed through all firewalls. Other VPN technologies include IPsec Tunnel mode VPN, although this is often difficult to manage because of routing and NAT problems; and in future versions of Windows, the DirectAccess “VPN-less” connection makes use of IPv6, IPsec, and a number of different Tunneling protocols.
Q: I have tried adding users to a file using EFS, but one user doesn’t have a public key to add, and the other, although he does have a key, can’t access the file even though I have added him. Why is that?
A: The first user does not have a public key because he has not yet requested a key pair. You can enable autoenrollment on the domain controller to make the user register a key pair when he next logs on or you can ask him to encrypt a file for himself that will create a key pair.
The second user does not have NTFS rights that allow him to read the file and its associated $EFS stream. Check the NTFS rights assigned to this file.
Q: When I backup a file from an EFS-encrypted folder, is it still encrypted in the backup? What about backing up from an encrypted hard drive?
A: Most backup software will recognize EFS-encrypted files and store them with their encryption intact. It takes more effort to try and find a key that would allow them to decrypt the file before backing it up.
Backing up from a hard drive that has Whole Disk Encryption applied to it is different—the backup tool cannot “see” the hard drive’s encryption, once the system has been booted, and so the files backed up are backed up in clear text, as if the disk encryption did not exist.
Q: What happens if my TPM chip gets destroyed or I move my encrypted hard drive to another motherboard? Have I lost my data?
A: Encryption systems based on the TPM chip will all have some means of recovering the data that must be used if any of the BIOS or boot sector measurements have changed or if the TPM chip is unable to decrypt the appropriate key. BitLocker, for instance, has its own recovery mode where the user will be asked to enter a recovery key, which was generated at encryption time (and which the user was strongly encouraged to save, print, and store away in a safe place). In Active Directory domain environments, the recovery key can be stored in Active Directory for later recall by desktop support staff.
1. What cryptographic properties should a strong symmetric cipher have?
A. The number of bits in the key should be large so as to discourage brute-force cracking
B. Encryption should be slow so as to discourage brute-force cracking
C. Bits in the cipher text should never be the same value as the corresponding bit in the plain text
D. The same plain text should always generate the same cipher text
E. The cipher should prevent the use of keys chosen by poor random number generators
2. Which key is used to decrypt traffic encrypted using an asymmetric cipher?
A. The sender’s public key
B. The recipient’s public key
C. The sender’s private key
D. The recipient’s private key
E. A negotiated shared secret
3. What technique improves the protection given by a cryptographic hash of small data?
A. Signing the hash with a private key
B. Padding the data with null bytes to match the block size of the hash algorithm
C. Prefixing the small data with a random value prior to hashing it
D. Repeating the data two or more times
4. What is the process required to digitally sign a document?
A. Calculate a hash of the document and encrypt the hash with the recipient’s public key
B. Calculate a hash of the document and encrypt the hash with the sender’s private key
C. Encrypt the document with the recipient’s public key and attach a hash to the document
D. Encrypt the document with the sender’s private key and attach a hash to the document
E. Encrypt the document and its hash with a shared secret key negotiated through public key exchange
5. Why is a digital signature not simply performed by encrypting the entire document using the sender’s private key? Select one or more answers.
A. Because it would be slow on large documents
B. Because encryption of large amounts of data with the private key could expose information about the private key
C. Because nobody has carried out cryptanalysis on this method
D. Because not all the document is important enough to encrypt
E. Because encrypting the whole document would be more likely to create a colliding hash
6. How should you encrypt an X.509 digital certificate to protect it in normal use?
A. Use the RSA encryption algorithm with a key derived from the certificate’s private key
B. Use the DES encryption algorithm with a shared secret key that will be published for certificate users to fetch
C. Use the base64 encoding scheme
D. No encryption is necessary for normal use of a certificate
7. When verifying a certificate from the Web site “www.whitehouse.gov/”, which of the following Subject names would be correct matches?
A. CN = www.whitehouse.gov, S = District of Columbia, OU = Office of Administration, O = Executive Office of the President, L = Washington, C=US
D. CN = www.whitehouse.gov
E. CN = *.gov
8. Between which dates should you keep a certificate on file?
A. From the Valid-From date until the Valid-To date
B. From the Valid-From date until the certificate is revoked or expires, whichever is the sooner
C. For all dates during which you intend to use the certificate to verify or decrypt protected data
D. From the day it first appears in a revocation list, until the Valid-To date
9. In a dual-sided certificate, what private keys should be retained by the issuing organization for later recovery? Choose one.
A. No private keys should ever be held by anyone but the owner
B. The signing key
C. The decrypting key
D. Both the signing and the decrypting key
10. One-time pads would be the perfect source of a key stream for symmetric encryption—but what makes them impractical? Choose one or more answers.
A. Their length
B. The secrecy required to exchange and protect them
C. Transcription errors when reading from the paper of the pad
D. The fact that you can only use them once
11. I am sending a document by e-mail to a client that must remain protected through its transmission to the client, but which I want the client to be able to read, print, or distribute once the client has received it. Which protocol or protocols would achieve this?
A. S/MIME
B. S-HTTP
C. SMTP with STARTTLS
D. FTP over TLS.
E. All of the above
12. With which key is an EFS-protected file encrypted?
A. The shared FEK
B. The file creator’s private key
C. A key made from combining the file creator’s public key with the FEK
D. The FEK after it has been encrypted with the file creator’s public key
13. By roughly how much does Whole Disk Encryption reduce the available storage space?
A. 5 percent
B. 10 percent
C. Three or four disk sectors
D. It depends on the block size of the encryption algorithm
14. What is the difference between TPM “Wrap” and “Seal”?
A. The “wrap” operation will allow a key to be used at any time; the “seal” operation will allow a key to be used only when system measurements match those present at the time of sealing the key
B. The “wrap” operation allows a key to be revealed if the system measurements match those at its creation; the “seal” operation never allows a key to be revealed but may allow it to be used
C. The “wrap” operation uses symmetric cryptography keys; the “seal” operation uses asymmetric keys
D. The “seal” operation is designed not to leak the key, the “wrap” operation may leak the key under some attacks
15. What are the necessary components to fully protect a laptop using Whole Disk Encryption?
A. A TPM or similar key operation component
B. A well-trained user
C. External key material—for example, a USB stick or a passphrase
D. A BIOS and boot sector that support the use of encryption and the TPM
E. All of the above
1. A and D
2. D
3. C
4. B
5. A, B, C, D
6. D
7. A, D
8. C
9. C
10. A and B
11. A
12. A
13. C
14. A
15. E
