It’s time to take stock. Cryptography provides all sorts of clever tools: encryption mechanisms control who can access information, integrity mechanisms detect whether information has been altered, and entity authentication mechanisms indicate who we’re communicating with. These cryptographic tools are all fine in theory, but the crucial services they deliver need to work effectively in real systems if we’re all going to be secure in cyberspace. Building real systems is notoriously difficult, so we must consider how cryptography can be transformed from just a fascinating idea into something that really makes us secure in cyberspace. The best way to consider how to get practical cryptography right is to think about what could go wrong.
Nuts and Bolts Are Not Enough
Cryptography works. At least, it should. Yet you will hear stories about cryptography being “broken.” The communications of Mary, Queen of Scots, and Napoleon were ultimately revealed, despite their use of cryptography. Much of the traffic protected by German Enigma machines was eventually decrypted by the Allies, giving the Allies a huge advantage toward the end of the Second World War. The cryptography used by new technologies is all too often found to have significant weaknesses. And forensic investigators are sometimes able to get around the cryptography protecting data on a seized mobile phone. How do these apparent failures of cryptography keep occurring?
Good cryptographic algorithms are very hard to design, so it might be tempting to conclude that failures of cryptographic protection are all down to weaknesses in the cryptography itself. But this is very rarely the case.
It’s worth recognizing the precise role that cryptography plays in keeping information secure, both in cyberspace and elsewhere. Cryptography provides a range of security mechanisms, each designed for a very specific purpose. For example, encryption scrambles data into an unintelligible form. This sounds useful for providing confidentiality, but there’s something of immense importance that anyone relying on encryption needs to be aware of, yet might ignore at their peril. Scrambling the data is the only thing encryption does.
Let’s think about what encryption does not do. Encryption does not come with a guarantee that the encryption algorithm used has been correctly coded or integrated into the technology it is trying to protect. Encryption doesn’t control who has access to the decryption key. Likewise, encryption plays no role in the protection of data either before it’s encrypted or after it’s decrypted.
The best way to consider the protection provided by cryptography is to appreciate that cryptography can only ever be used as part of a wider cryptosystem. This includes not just the algorithms and keys, but also the technologies on which the cryptography is implemented, the devices and processes that manage the cryptographic keys, the wider procedures for handling the data being protected, and even the people who interact with all of the above. When cryptography breaks, what has really happened is that some part of the cryptosystem has failed to work as intended. Problems with the cryptographic techniques used are not ruled out, but chances are the issue lies elsewhere.
Cryptography is vital for most of the security technologies that we use today in cyberspace. It provides, if you like, the nuts and bolts around which a secure system can be built. In the case of building a steel bridge across an estuary, nuts and bolts are essential, but they’re not enough. And if, heaven forbid, the bridge falls down, the reason is not usually that the nuts and bolts didn’t do their job.1
Using State of the Art
By all accounts, Julius Caesar was an avid user of cryptography. It’s reported that whenever he was concerned about the confidentiality of written information, he used encryption to disguise it.2 The algorithm Caesar used has come to be known as the Caesar cipher and consists of shifting the letters of the alphabet a certain number of positions. The size of the shift is the key, and it is reported that Caesar habitually used a shift of three (encrypting A to D, B to E, and so on).
The Caesar cipher tends to be the first encryption algorithm encountered by students in a cryptography course. It’s used as an illustrative example, before the students are informed how weak it is. The Caesar cipher is far too simplistic, for it leaks information about the plaintext, it has only twenty-six possible keys, and the key is revealed if just one plaintext and matching ciphertext are known. The Caesar cipher is how not to encrypt your bank account. How naive was Caesar?
Julius Caesar was many things, but naive he was not. A canny politician, defiant military commander, and ultimately authoritarian leader of the Roman Republic, Julius Caesar was a man who undoubtedly had secrets to keep. His use of any form of encryption in the BC era can only be regarded as visionary, and indicative of a man who was well aware of the value of information and how to protect it. It has been pointed out that the majority of Julius Caesar’s enemies were probably illiterate. The few who were not were extremely unlikely to be aware of encryption. If they intercepted Caesar cipher ciphertext, they would have been bamboozled. Julius Caesar knew what he was doing. The Caesar cipher was state-of-the-art encryption, and it almost certainly did the job that he required it to do. Hail, Caesar!
In the late sixteenth century, Mary, Queen of Scots, and her fellow Babington Plot conspirators cooked up their own encryption algorithms in order to keep their communications confidential (and what could need confidentiality more than plans to oust Queen Elizabeth I?).3 The problem for Mary was that neither she nor her friends were versed in the cryptographic cutting edge. Had Mary digested Italian cryptographer Giovan Battista Bellaso’s 1553 treatise La cifra del Sig. Giovan Battista Belaso, then the world might have been a very different place. Instead, Mary relied on a series of bespoke algorithms that were not dramatically advanced from the Caesar cipher. Pitched against the might of Elizabeth’s sixteenth-century intelligence agency, Mary never stood a chance. Elizabeth employed Thomas Phelippes, who was essentially a cryptographer and, notably, Arthur Gregory, who was an expert at undetectably interfering with the seals of letters.4 There is a salutary reminder there, for all of us, that confidentiality and data integrity are often both required when information needs protection.
The good news is that, today, strong cryptographic algorithms are readily available for everyone to use. Since the 1970s, cryptographic expertise has blossomed beyond the domains of the government and military. Several significant international standards specify cryptographic algorithms, including the AES, that are believed by the wider community of expertise to be extremely secure.5
You’d like to believe that the technologies we use every day in cyberspace were using these wonderful state-of-the-art cryptographic algorithms, wouldn’t you? Well, most do, but by no means all. There has been a sad history of new technologies adopting their own do-it-yourself cryptographic algorithms. This approach has been taken for a variety of reasons, some of which have a degree of legitimacy, such as the fact that certain algorithms are designed to optimize performance on specific technologies, but in many cases the cause is simply ignorance. These contemporary ventures into Mary-Queen-of-Scots cryptography have almost all ended badly, although, truth be told, not enough beheadings have taken place as a result.6
The lesson for us today is simple. When it comes to choosing a cryptographic algorithm, whether for confidentiality, data integrity, or entity authentication, choose the state of the art. Cryptographic algorithms are the core component of any cryptosystem, and there is no excuse for not using the best available algorithms. If a widely respected algorithm is being used and a cryptosystem fails, then the problem will almost certainly lie elsewhere.
Knowns and Unknowns
When experts recommend a cryptographic algorithm as state of the art, they’re saying, of course, only that they believe this to be so, from what they know about cryptography. There are no guarantees that any algorithm is secure, and there never can be. When speculating about uncertainties, it is not unhelpful to benchmark against former US secretary of defense Donald Rumsfeld’s legendary taxonomy of the knowable.7
Cryptographic algorithms are designed with primarily the known knowns of algorithm security—in other words, available best practice—in mind. Mary, Queen of Scots, lost control of her information because she was not sufficiently versed in the known knowns of the day. Her encryption algorithms shared one particular undesirable property with the simple substitution cipher we encountered earlier—namely, that when a specific key is used, the same plaintext letter (in the case of the simple substitution cipher) is always encrypted to the same ciphertext letter. Since some plaintext letters occur much more commonly than others within any language, some ciphertext letters will occur much more often than others. Careful analysis of how frequently ciphertext letters occur thus permits an informed guess as to what the underlying plaintext letters are. With a bit of intelligent trial and error, it can be surprisingly easy to use this type of frequency analysis to determine the full plaintext. Puzzles of this sort are now often published in magazines and are trivial to solve by computer.
Frequency analysis is just one of many attack techniques, most of which are much more sophisticated, that designers of contemporary cryptographic algorithms should be aware of. By Mary’s time, knowledge of frequency analysis had led to the adoption of more complex encryption algorithms, including Giovan Battista Bellaso’s Vigenère cipher, which ensures that different occurrences of the same plaintext letter are encrypted as different letters in the ciphertext.
For Mary, frequency analysis belonged to an uncertainty category that Rumsfeld, with privileged access to the most powerful intelligence agency in the world, presumably felt was not of relevance to him. It was an unknown known, something she could have (perhaps should have) known about but did not. The risk of unknown knowns has dogged the public use of cryptography since its emergence in the mid-1970s. Prior to this time, cryptography was very much an activity in the domains of governments and the military, where it was shrouded in secrecy.
When the DES algorithm was first published in the late 1970s, there was no doubt that the intelligence community knew far more about cryptography than the rest of us did. This exclusiveness led to worries (probably unfounded) that the DES algorithm might be subject to attacks that intelligence agencies, but not everyone else, would know about. In fact, it turned out there were some unknown knowns of this type, but it appears these were used to strengthen the security provided by DES, not weaken it.8 By the time the AES competition (discussed in Chapter 3) was launched, the gap between secret and public knowledge about cryptography had shrunk.
Today, public expertise in cryptography is so extensive that the chances of there being significant unknown knowns with respect to cryptographic algorithm design are lower than ever before, although the intelligence community almost certainly will know some things that the public community does not.9 It was notable that among the deluge of Edward Snowden’s 2013 revelations about the exploitation of cryptosystems by intelligence agencies, very little suggested that these agencies held an upper hand in the analysis of cryptographic algorithms.
Rumsfeld acknowledged the existence of known unknowns, things that he knew US intelligence did not know with respect to Iraq’s alleged weapons program. Several known unknowns hang over cryptography like dark clouds. Cryptography is based on an important premise. It’s not impossible for an attacker to work out plaintext from ciphertext, or find a decryption key, or factor a large number, or forge a MAC, or find an input that hashes to a particular hash value, or accomplish a host of other things. Rather, it’s hard to do these things. And the perceived level of difficulty of these tasks relies on assumptions about how much computing power an attacker can expend on the problem.
The first difficulty is that we know that powerful attackers of cryptography are out there, but we don’t know who they are or how powerful their computers might be; we can only make an informed guess. Second, and more awkward, we know that computers are getting faster and faster, but we don’t know how powerful they will be in the future. Fortunately, there are some rules of thumb about the rate of improvement in computing power that can be used to make predictions, but these will only ever be best guesses.10 Because of these two known unknowns, cryptographic algorithm design tends to be extremely conservative, assuming the existence of much more powerful attackers than are probably ever likely to be out there. Better safe than sorry.
The real cumulonimbus hanging over cryptography, however, is quantum computing. We know it’s coming. We know it will impact contemporary cryptographic algorithms (to quite varying extents). We don’t know the time frames. We don’t know how realistically the theory can be converted into practice. Quantum computing is an issue that will impact the cryptography of the future, so I’ll discuss this later.
Which brings us, finally, to Rumsfeld’s greatest fear: unknown unknowns. Could the cryptographic algorithms we use today suddenly succumb to an unexpected breakthrough that completely compromises their security? Hopefully not, but we can never be sure. The world of cryptographic algorithm design is not often shaken by such surprises, but there is past precedent.
In 2004, at one of the leading cryptography research conferences, Wang Xiaoyun, a then relatively unknown Chinese researcher, delivered an informal paper that described a devastating attack on MD5, one of the principal hash functions in use at the time.11 While this attack did not immediately threaten all applications using MD5, of which there were a great many, it exposed the fact that MD5 was significantly weaker than everyone had assumed. Most attack techniques improve steadily over time, but breakthroughs of this type are rare. A previously unknown unknown was now known, kick-starting a process that eventually resulted in the development of entirely new approaches to designing hash function algorithms.
How to Save the World
Here’s cryptography in action, as often witnessed on television dramas (and the likes of James Bond movies).
Two intelligence agents sit tensely in a car, careering through busy city streets in a race against time. The driver is panicking and urgently talking to base. The passenger, the geeky agency computer analyst, has just inserted a recently purloined memory stick into a laptop computer. “What’s on there?” asks the driver. “It’s encrypted,” responds the analyst. “Can you break the code?” asks the driver. The analyst wrestles with the keypad while mysterious symbols dance across the screen, purses his lips, and slowly exhales. “I’ve never seen this means of encryption before; it’s unbelievably complex. Whoever wrote this knew what they were doing,” he says. “But can you crack it?” fires back the driver, as a timer on the screen hurtles second by second toward zero hour. The analyst grimaces and clatters his fingers over the keypad once more. The camera focuses on the laptop, where a digital Niagara of jumbled data is pouring down the screen. The driver runs a red light, overtakes a bus, and narrowly evades a head-on collision with a motorcycle. The analyst taps away at the keyboard, muttering to himself, eyes like saucers, staring in wonder at the festival of ciphertext on screen. The driver decides to take a shortcut and makes a sudden right turn, finding the way blocked by a garbage truck. The car screeches to a halt, and the driver sighs with despair as the timer enters the final seconds of its countdown. The analyst gasps, “I’ve got it!” And the world is saved, again.
Either the analyst has knowledge of an otherwise unknown unknown about cryptography, or (to get to the point of the issue as succinctly as possible) this is . . . nonsense.
What just happened? The cryptographic expert in the passenger seat reports that the encryption algorithm is unfamiliar. How did they work it out? Ciphertext from any decent encryption algorithm should appear to be randomly generated, so you shouldn’t normally be able to determine which algorithm was used to encrypt it just from idle inspection. But let’s set this problem aside. By somehow being able to deduce that none of the encryption algorithms he is familiar with have been used, the analyst is informing us that the algorithm is unknown to him. Since the analyst also indicates that whoever encrypted the data knew what they were doing, it is safe to assume the analyst has not extracted the decryption key from the memory stick (otherwise the key management is so poor that they certainly did not know what they were doing). So, the analyst knows neither the algorithm nor the key. Where, then, did the plaintext just come from?
There is only one conclusion. The analyst has, somehow, been able to try every possible algorithm and, for each of these algorithms, every possible key. Every possible algorithm? How many possible encryption algorithms could there be? It’s not even worth trying to reason about this; the number is so large that this capability can be safely dismissed.12
Let’s be clear. If you acquire a ciphertext and you don’t know which algorithm was used to produce it, then there’s very little you can do to analyze it (assuming it has been generated by a good encryption algorithm). However, for all the reasons previously discussed, most modern uses of cryptography involve following standards that precisely specify the algorithm used. In most cases, therefore, it is entirely reasonable to assume that the algorithm is known.
So, let’s amend the plot of our spy drama. “It’s encrypted,” responds the analyst. “Can you break the code?” asks the driver. The analyst wrestles with the keypad while mysterious symbols dance across the screen, purses his lips, and slowly exhales. “I’m guessing they’ve used extremely strong encryption—probably the AES. Whoever encrypted this knew what they were doing,” he says. “But can you crack it?” Ticktock, ticktock, ticktock . . . The car screeches to a halt, and the driver sighs with despair as the timer enters the final seconds of its countdown. The analyst gasps, “I’ve got it!”
I don’t think so.
Key Length Matters
Julius Caesar was undoubtedly aware of it. The Babington Plot conspirators appeared to recognize it. Even you, having read thus far, are surely convinced of it. Surprisingly, some designers of new security technologies underestimate it. The screenwriters of intelligence thrillers, on the other hand, often choose to ignore it.
Key length matters. In other words, the number of possible keys has a significant bearing on the security of a cryptographic algorithm. You can never have too many, but you can certainly have too few.
Twenty-six, for example, is not enough! Good for Caesar maybe, but not for protecting your mobile phone calls. Mary, Queen of Scots, however, with her extended version of the simple substitution cipher, was in a much better position with respect to key length. Her encryption algorithms had substantially more keys than the simple substitution cipher had, which itself already had plenty of keys. Mary’s key length was close to being acceptable today. The take-home lesson here is clear. Key length matters, but it’s not all that matters. Having a sufficient number of possible keys is no guarantee that your head will remain fixed to your body.
Key length matters because there is an unsophisticated attack that can be launched against every cryptographic algorithm. This attack works, no matter how well the algorithm blends the input data into ciphertext, MAC, or whatever. An exhaustive key search13 simply tries out every possible key. To work, however, two things are required. The algorithm must be known, and there must be some means of determining when the correct key has been found.
Let’s return to our revised fictional drama and consider an exhaustive key search against symmetric encryption. The analyst has some ciphertext, and he wants to know the underlying plaintext. He knows (or makes an informed guess) that the encryption algorithm used was AES. He doesn’t know which key was used. In the absence of any further information, his only option is to try out every possible key, one after the other. Guess a key, decrypt. Guess another key, decrypt. Guess another key, decrypt. And so on, and so on, and so on. Assuming the plaintext is not random, it should be easy to determine when the correct key is found because, hopefully, the screen of unintelligible ciphertext will transform into a map depicting the plans for an upcoming terror plot. But can the correct key be found in time?
I’ll be perfectly frank. If the correct key for an AES ciphertext is chanced upon just minutes into an exhaustive key search, then the analyst has been lucky beyond all credible belief. How long would it really take to find the correct key? In most cases, it won’t be necessary to try out every key (this would be just as unlucky as our intelligence analyst was fortunate). On average, the correct key will be found about halfway through the search of all possible keys. Had the encryption algorithm been the Caesar cipher, then the analyst could easily work through all twenty-six possible keys, most likely finding the correct key after about thirteen attempts. He could almost do this by hand, but his laptop will perform this exercise instantaneously. But what about a real encryption algorithm?
For the sake of this exercise, let’s (impossibly) upgrade our analyst’s laptop to a supercomputer capable of processing 100 petaflops (100,000,000,000,000,000 operations per second). The AES has—wait for it—a minimum of 340 billion billion billion billion (that’s 340 undecillion for the more numerate of you) keys. A crude calculation suggests that an exhaustive search of AES using this supercomputer will take, on average, 50 million billion years to conduct.14 This is, unfortunately, just a bit longer than television program schedules tend to permit. If the future of the world relies on a successful exhaustive search of AES, then we’re all doomed.
Key length matters, with length typically measured by how many bits long the key is. The minimum AES key length on which the last calculation was based is 128 bits. There are two important aspects to key length, each of which merit further attention. These are perhaps both best illustrated by a consideration of DES, the encryption algorithm that would have been used, had our spy drama been set in the latter decades of last century.
The first is the sensitivity of key lengths. The DES has a key length of 56 bits, which is slightly less than half the key length of the AES. This does not mean that the AES has just over double the number of keys that the DES has. If the length of a symmetric key is increased by a single bit, then the number of possible keys is doubled. So the AES has 5 sextillion (5,000 billion billion) times more keys than the DES! Just think about that for a moment.
The second issue is how recommended key lengths evolve over time. When the DES was first released in the late 1970s, some people worried that its 70 million billion keys were not quite enough. It was estimated that a machine could be built for $20 million that could search all these keys in less than one day.15 However, this machine was never built, and it has been suggested that, in any case, such a device would have melted before completing its search.
Fast-forward two decades, and a DES key was found in just under half a year by a distributed exhaustive key search conducted by computers all over the world, joining efforts over the fledgling internet.16 Such an achievement had been unthinkable in the late 1970s. For two decades, DES was the state of the art in encryption, with such a search deemed computationally infeasible. But as time moves on, technological capability only ever gets better. The AES was born from the realization that the key length of DES had become a liability. Today, our supercomputer that takes 50 million billion years to find an AES key could find a DES key in less than the time it takes to hard-boil an egg.
Of course, nobody is claiming that AES will be good for 50 million billion years. Computers will continue to advance, so recommended key lengths need to factor this into account. Since nothing can be done to prevent exhaustive key search, we have to make sure there are so many keys that, within reasonable time frames, exhaustive key searches are, in all likelihood, impractical to complete. Key lengths matter, even if giving them proper consideration spoils a movie.
It Ain’t What You Do (It’s the Way That You Do It)
Napoleon Bonaparte learned, admittedly the hard way, that using good cryptography is important. In 1811 he commissioned the design of a state-of-the-art encryption algorithm, known as Le Grande Chiffre de Paris. This algorithm was designed to counter frequency analysis. By using techniques such as encrypting the more common plaintext letters into many different ciphertext letters, as well as masking common letter combinations using dummy characters, this somewhat clunky—but effective—encryption algorithm had the potential to defeat the cryptographic experts of the British army and its allies.
Within one year, Le Grande Chiffre was broken. Twelve months later, Napoleon’s forces sorrowfully retreated from the Iberian Peninsula. They had just lost a war in which, unbeknownst to them, their encrypted messages had all been read by the British. Within two years, Napoleon was “en vacances” in Saint Helena. What Napoleon never understood was that using a good cryptographic algorithm does not guarantee you security. Just using such an algorithm matters, but so does the way you use it.
Napoleon’s forces used strong encryption, but they used it carelessly.17 Their biggest mistake was to regularly encrypt only parts of messages. An efficiency saving, maybe, but a devastating security error. By sending bizarre combinations of plaintext mixed with ciphertext, the French handed a free gift to British intelligence. With sections of the plaintext known, the British analysts could make informed guesses about what the remaining plaintext was, then correlate those guesses against previously intercepted communications. It would not have taken much time to deduce the entire key of Le Grande Chiffre.
The cryptographers working to overcome the German Enigma machines during the Second World War benefited from all sorts of different kinds of carelessness in the use of cryptography. For example, many plaintext messages started with predictable words or phrases. Similarly, the key in Enigma machines consisted of a number of mechanical settings, some of which were “lazier” choices based on the physical layout of the machines, and thus more commonly selected. None of these were enough to break Enigma on their own, but a steady accumulation of knowledge about how Enigma machines could be misused certainly helped in the process of breaking them.18
We are far from immune to such problems today. For example, if modern block ciphers are not used appropriately, they can be subject to various attacks, including frequency analysis. The AES, a state-of-the-art encryption algorithm, does not encrypt letter by letter, but it will always encrypt the same block of plaintext data into the same block of ciphertext data. Frequency analysis on blocks of data (which can represent many letters) is much more difficult than on single letters, but blocks can still be analyzed in this way. For example, if a database were (naively) encrypted entry by entry, including a field for “child’s favorite food,” then among the most commonly occurring ciphertexts would be the encryption of pizza (and, you can be sure, not the encryption of brussels sprouts). The AES has encrypted pizza to perfection, but our use of the AES allows the plaintext pizza to be deduced without the encryption algorithm being broken.
The pizza problem can be remedied in various ways, all of which involve attending to the way AES is used rather than tinkering with the algorithm. For example, if a random number is included alongside each database entry, the ciphertext associated with the word pizza should become different for each entry. More generally, as mentioned earlier, block ciphers are normally deployed via modes of operation that use a variety of techniques to ensure that the same plaintext block is not transformed into the same ciphertext block every time.19
Selecting a cryptographic algorithm is one task. Using it securely, quite another. Today, we don’t just have cryptographic standards specifying algorithms, but also standards advising on ways in which algorithms should be used. The Grands Chiffres of the twenty-first century can easily become as ineffective as Napoleon’s if used inappropriately.
Following the Protocol
Cryptographic mechanisms are rarely used in isolation. Whenever you use cryptography, you are normally engaging in a cryptographic protocol involving different cryptographic mechanisms being used to deliver separate security properties. For example, when making a secure web connection using the TLS protocol discussed earlier, your web browser uses one mechanism to conduct entity authentication of the web server, another to keep the exchanged data confidential, and yet another to provide data origin authentication (sometimes the latter two are combined). The TLS protocol decrees exactly what needs to happen when, and in what order. If just one step of the protocol is not successful, then the entire protocol should fail. For example, in TLS, if the web server is not authenticated, then the protocol should end without a secure session being approved.
Mary, Queen of Scots, suffered a catastrophic protocol failure because all of her security mechanisms were compromised. She relied on an encryption algorithm that Thomas Phelippes could break. Wax seals were used to protect the integrity of the ciphertext itself. Had this integrity mechanism worked, then even though Phelippes could overcome the encryption, his obvious breaking of the seal in order to inspect the ciphertext would have alerted Mary. But Arthur Gregory could open wax seals without detection, so Mary’s data integrity mechanism also failed. Worse, Phelippes could do more than decrypt her ciphertexts. His knowledge of the system was so complete that he could also forge apparently genuine messages.
In the closing stages of the Babington Plot, Phelippes was able to forge a message from Mary to Anthony Babington, requesting the names of the chief conspirators.20 Upon receiving an apparently unadulterated message in correctly encrypted form, Babington would have erroneously assumed that it came from Mary (remember that the use of encryption does not guarantee the strong notion of data integrity introduced earlier, called data origin authentication). As it turned out, this last security failure had no bearing on proceedings, since Babington was seized before he had time to reply. Six weeks later, Babington was hung, drawn, and quartered, and within months, Mary had her own neck trimmed.
Even if strong cryptographic algorithms are chosen to implement the mechanisms used in a well-designed cryptographic protocol, the overall cryptographic protection might not be realized if the protocol is not followed correctly. Suppose, for example, the web server authentication step in the TLS protocol is mistakenly omitted or, more likely, not conducted properly. In other words, your web browser has, for some reason, failed to confirm that it is communicating with the genuine web server you believed you were connecting to. If the rest of the protocol is followed, then the end result could be that you establish a secure connection to a rogue web server. This secure connection prevents outsiders from reading the encrypted traffic, or trying to modify data sent over it, which are two of the goals of the TLS protocol. But who is at the other end of this connection?21 Well, you have no idea.
Perhaps the biggest challenge is that good cryptographic protocols are notoriously hard to design. The reason is partly that the interaction of the various different components can sometimes have unintended consequences. An example of a poorly designed protocol was the Wired Equivalent Privacy (WEP) protocol for securing early Wi-Fi networks. The WEP protocol used a stream cipher called RC4, which was arguably strong enough at the time of WEP design.22
The design of the WEP protocol had many problems, though—perhaps the most critical being that WEP specified an unusual means of making sure the encryption key used to provide confidentiality of Wi-Fi messages was constantly changed. Although changing this key is good practice, the technique used in the WEP protocol was flawed. As a result, an attacker who observed the communications on a WEP-protected Wi-Fi channel for long enough could work out the main key used to protect the network and ultimately decrypt all traffic sent over it.23 This weakness in the WEP protocol was not immediately obvious, but it proved fatal. Modern Wi-Fi networks use more carefully designed protocols to protect the information sent over them.24 (To be on the safe side, if you are using old Wi-Fi equipment, perhaps it would be best to check!)
Mind the Gap
Picking strong algorithms, with appropriate key lengths, and deploying them in sound cryptographic protocols is an excellent start to making cryptography work in practice. But it is no more than a decent launching pad. Thanks to standards, and increased recognition of the importance of using state of the art, modern cryptographic systems suffer from fewer weaknesses than older systems did because of poor design. However, they still fail. The reason is that design on paper is arguably the simplest part of the process of making cryptography work in practice. It’s what happens next that tends to go awry.
The first problem is that there’s a chasm between design and implementation. In 1997, security specialist Bruce Schneier made some astute observations about the implementation of cryptography, which remain true today:
There is an enormous difference between a mathematical algorithm and its concrete implementation in hardware or software. Cryptographic system designs are fragile. Just because a protocol is logically secure doesn’t mean it will stay secure when a designer starts defining message structures and passing bits around. Close isn’t close enough; these systems must be implemented exactly, perfectly, or they will fail.25
Schneier’s argument was that cryptographic algorithms and protocols are very special components of security systems. Great care needs to be taken during implementation to make sure that the cryptographic design described on the label is precisely the cryptographic design delivered in the box.
Since 1997, much has been learned about building secure implementations. More is known about how to write secure software, and more is understood about how to incorporate and use secure hardware components to strengthen the security of systems. But, at the same time, we use cryptography in more and more products, and not all product developers are well versed in secure implementation techniques, or inclined to employ them. Because of budgetary constraints and urgency to complete development, some products end up having flawed cryptography. As computer security expert Thomas Dullien observed in 2018: “Security is improving, but insecure computing is growing faster.”26
Despite all the wisdom, and despite the implementation horror stories of the past, there remains a gap to be minded between the cryptography of battle plans and the cryptography of frontline action.
Attacking down the Blind Side
In December 1995, as a fledgling cryptographic researcher, I was sitting in a sweltering office at the University of Adelaide, reading the posts of sci.crypt, an early internet newsgroup about all things cryptographic. In 1995, it was still possible for one person to be broadly aware of all the topics that cryptographic researchers were investigating. Indeed, if you worked in the public domain, it was still possible to know most cryptographers.
The post that really caught my attention was entitled “Timing cryptanalysis of RSA, DH, DSS,” by Paul Kocher (independent cryptography consultant). Kocher was claiming to have broken RSA, among other public-key algorithms. RSA broken? He must be bonkers! So I read on:
I’ve just released details of an attack many of you will find interesting since quite a few existing cryptography products and systems are potentially at risk. The general idea of the attack is that secret keys can be found by measuring the amount of time used to process messages.27
This sealed it for me. Kocher was clearly insane.
Paul Kocher had just announced an unknown unknown. He had not broken the RSA algorithm, which, if we allow for increases in key length due to improvements in computing power, remains as secure today as it was in 1995. He was announcing that implementations of RSA previously believed to be secure were not. The problem was not careless mistakes, resulting in flawed implementations. Kocher was announcing a completely new way of attacking implementations of cryptographic algorithms. It was an attack down the blind side. Implementing cryptography has never been the same since.
Kocher had done something that nobody outside of the intelligence community had previously imagined possible. He had access to an apparently secure device, such as a smartcard, that contained an RSA private key. For such devices, it should not be possible for anyone to read the key that is stored on it, but it should be possible to ask the device to use the key to conduct cryptographic computations (think about your credit card; you clearly don’t want a salesperson to be able to extract any keys stored on the chip, but you do want their payment terminal to be able to process your transaction using these keys).
This is precisely what Kocher did: he instructed the device to conduct RSA computations and then closely scrutinized what happened next. In particular, he measured in detail the minute differences in the timing of certain operations as the device crunched its way through RSA decryptions of different ciphertexts. By cleverly selecting which ciphertexts to analyze, and which operations to measure, Kocher was able to eventually determine the private key used to conduct the decryption operations.28 Amazing!
Kocher’s timing attacks opened up an entirely new area of cryptographic study. If you could discover a private key simply by measuring the timings of the device on which the key was being used, what other unexpected ways might there be of discovering private keys? This is just one example of a number of side channel attacks, all of which exploit different aspects of the implementation of cryptography to leak information about the secret keys on which cryptography relies. Other examples include detailed analysis of the power consumed by a device as it performs cryptographic operations, the electromagnetic radiation that the device emits, and the way a device behaves when deliberately given faulty information.29
Most side channel attacks require an ability to possess a device on which cryptography has been implemented and subject it to a form of repeated “torture” until its secrets are revealed. In a previous world where cryptography was implemented only on enormous computers sitting in special rooms in the basements of buildings, side channel analysis did not seem relevant. Today, however, when cryptography is on the devices in your pocket, side channel analysis presents a real threat. An attacker who manages to get hold of your device can then interrogate it to obtain your secrets.
This is why, hand in hand with investigations on the effectiveness of side channel attacks, ways of protecting implementations against them are being developed. Since side channel attacks are subtle, so, too, are the approaches to masking against them. This is yet more evidence, if any was really needed, of just how tricky it is to securely implement cryptography.
How to (Really) Save the World
Take two.
Two intelligence agents sit tensely in a car, careering through busy city streets in a race against time. The driver is panicking and urgently talking to base. The passenger, the geeky agency computer analyst, has just inserted a recently purloined memory stick into a laptop computer. “What’s on there?” asks the driver. “It’s encrypted,” responds the analyst. “Can you break the code?” asks the driver. The analyst wrestles with the keypad while mysterious symbols dance across the screen, purses his lips, and slowly exhales. “They’re using AES encryption,” he says. “But can you crack it?” fires back the driver, as a timer on the screen hurtles second by second toward zero hour. “I just have,” states the analyst, calmly. “They used the factory default key. What idiots,” he adds. “You can’t do that!” complains the driver. “We haven’t even made it to the great scene with the garbage truck!”
Take three.
. . . “What’s on there?” asks the driver. “It’s encrypted,” responds the analyst. “Can you break the code?” asks the driver. The analyst wrestles with the keypad while mysterious symbols dance across the screen, purses his lips, and slowly exhales. “They’re using AES encryption,” he says. “But can you crack it?” fires back the driver, as a timer on the screen hurtles second by second toward zero hour. The analyst grimaces and clatters his fingers over the keypad once more. Ticktock, ticktock, ticktock . . . The driver decides to take a shortcut and makes a sudden right turn, finding the way blocked by a garbage truck. The car screeches to a halt, and the driver sighs with despair as the timer enters the final seconds of countdown. The analyst gasps, “I’ve got it!” The driver smiles with relief. “Mate, you’re a genius!” he exclaims. “Not really,” replies the analyst. “They included the unprotected key in the computer program. All I did was look.”
Take four.
. . . “What’s on there?” asks the driver. “It’s encrypted,” responds the analyst. “Can you break the code?” asks the driver. The analyst wrestles with the keypad while mysterious symbols dance across the screen, purses his lips, and slowly exhales. “They’re using AES encryption,” he says. “But can you crack it?” fires back the driver, as a timer on the screen hurtles second by second toward zero hour. The analyst grimaces and clatters his fingers over the keypad once more. “Looks like the key is generated from a password. Just give me a moment.” Ticktock, ticktock, ticktock . . . The driver decides to take a shortcut and makes a sudden right turn, finding the way blocked by a garbage truck. The car screeches to a halt, and the driver sighs with despair as the timer enters the final seconds of countdown. The analyst gasps, “I’ve got it! Wannabe bad guys always use a password like ‘Javier Bardem’.”30
It’s the Key Management, Stupid!
Good algorithm—check. Sound protocol—check. Careful implementation—check. Side channel masking—check. Good to go?
We’re not quite done yet. Cryptography, as you know well by now, relies on keys. Indeed, assuming that the algorithms are designed and implemented correctly, cryptography translates the problem of protecting data into the (slightly easier) problem of safeguarding keys. If cryptography is going to do the job we intend it to do, then we need to take great care of our keys.31
One way of thinking about keys is to regard them as living objects. Keys are born, live their lives, and then die. Throughout this key life cycle, it is vital to nurture the key. The key life cycle includes a number of important stages. First keys are generated (created). Keys are then distributed to wherever they are needed in a cryptographic system. Then they are typically stored, awaiting use. In some systems, keys must be regularly changed. Ultimately, they are no longer required and need to be destroyed.
All these different stages in the life cycle of a cryptographic key need to be managed carefully, since a cryptographic system can fail if just one of these stages is handled inadequately. It’s just the same for your front-door key. An overly simplistic front-door key will allow anyone with a metal hook to wiggle open the lock. A crooked real-estate agent could give a copy of your front-door key to a criminal gang. If you leave your front-door key under a flowerpot by the gate, then it’s possible someone else will chance upon it. If a burglar breaks into your home and you subsequently fail to change the locks, the burglar may well return to steal all the replacement items you purchased with your home insurance payout.
Two core problems can arise if cryptographic keys are not managed properly. First, a key intended to be secret (such as a symmetric encryption key or an asymmetric private decryption or signature key) could become known. The three ways the world was (really) saved in our fictional scenario all resulted from a secret key becoming known through key management failures at different stages in the key life cycle. One was poor key generation (using a weak password). Another was poor key storage (including the key in software). A third was failure to change the key (keeping a factory default key rather than changing to a freshly generated personal key).32 Failure to keep secret keys secret at any stage in the key life cycle can be disastrous (or save the planet, depending on whose side you’re on). The need to protect secret keys is intuitive, since the same is true of physical keys.
The second core problem is that a cryptographic key’s purpose might not be what you think it is. For example, a cryptographic key might not belong to whomever you think it does. This problem does not map so readily onto physical keys. Let’s try.
Suppose you’re a fugitive on the run and you meet up with an acquaintance, who offers you shelter for the night. The acquaintance gives you their address and a front-door key. You locate the house, open the door, and find yourself at the reception desk of the local police station. Unbeknownst to you, your acquaintance is an undercover cop! Hmm . . . Why is this scenario unlikely?
Apart from your failure to see the friendly “Police Station” sign on the building and notice all the brightly colored emergency vehicles parked around it, this scenario is unlikely because physical keys need to be physically transferred, and the context provides some assurance of the purpose of the keys. When a car salesperson hands over the keys to your newly purchased car and points you to a shiny BMW in the lot, there are many reasons to believe that these must be the keys to the car. Yes, it could turn out that the keys don’t seem to open the BMW, while meanwhile, a rusty van parked next to it flashes its light in a welcoming manner and the salesman can be seen legging it down the road. That could happen. But it tends not to.
Cryptographic keys, being cyber things, lack physical context. When you connect to a remote website and the web server offers you its public encryption key in order to commence the building of a secure communication channel, how do you know that this public encryption key really belongs to the website?33 When a friend emails you their public encryption key so that you can send them an encrypted message, how do you know that an attacker has not intercepted their email and replaced your friend’s key with the attacker’s key? When you buy a cheap cryptographic gizmo from a company in Ruritania, how do you know that its cryptographic keys are not also stored in a Ruritanian government database?
The main goals of key management are to keep secret keys secret, and to make sure we’re using the right keys for the right things. Key management is arguably the hardest aspect of making cryptography work in real systems, because it’s the interface between the cryptographic technology itself and the organizations and people who need to use it.
Good Key, Bad Key
Key generation is perhaps the most sensitive key management process. Since it differs slightly between symmetric and asymmetric cryptography, I will consider these cases separately.
The security of a symmetric cryptographic algorithm is based on the assumption that symmetric keys have been generated randomly. There are two problems with this idea.
First, generating keys in a random manner is difficult. In fact, the very idea of “true randomness” tends to send philosophers and physicists into frenzied debate, which I will steer well clear of in this book.34 Genuinely random numbers, known as nondeterministic random numbers, typically require a “natural” physical source. One of the most obvious ways to generate nondeterministic randomness is to flip a coin. Assuming that the coin and the coin flipper are unbiased, each coin flip is an independent physical event equally likely to result in heads or tails. This is a great way to generate a random key, since, say, a head can be encoded by a 1 and a tail by a 0, resulting in a cryptographic key in which every bit is independent of those chosen before and after it.35 It’s also a completely impractical way of doing so for most applications of cryptography. Would you like to buy something from my website? Could you first flip a coin 128 times in order to generate an AES key, please?
Fortunately, nondeterministic random numbers can be generated from physical sources in various ways without human intervention. These include taking measurements from sources such as white noise, the atmosphere, physical oscillations, and radioactive decay, and then converting these into 1’s and 0’s.36 These techniques are all effective, if slightly cumbersome. If you have access to such a physical device and can extract true randomness from it, then fine. But what happens if you don’t?
There is another drawback to generating nondeterministic keys. You can’t use this type of technique to generate two identical random keys in two different places. Indeed, the whole point of nondeterministic random number generation is that this should not happen. The reason coin flipping is such a good way of generating randomness is that the outcome is unpredictable. However, generating two identical keys in two different places is precisely what we do want for many applications of symmetric cryptography. When you make a phone call, your phone and your mobile-network operator both have immediate need of a key that you both know, in order to encrypt your call.
When the going gets tough, what do the tough do? They cheat, of course. As discussed on several previous occasions, the output of a good cryptographic algorithm should seem “random,” so cryptography itself is a potential source of “randomness.” When you make a mobile phone call, your phone and the mobile-network operator both use a specific cryptographic algorithm to generate a new “random” symmetric key that can be used to encrypt your call. Both the phone and the operator already share a long-term symmetric key stored on your SIM card (which may well have been generated nondeterministically). This long-term key is used as input into the cryptographic algorithm, which then outputs a new shared key. The phone and the network operator use the same input and the same deterministic algorithm to generate the same key. Because this generation process is deterministic and thus repeatable in two different places, it’s not real randomness. Instead, it’s fake randomness, or pseudorandomness.
The randomness might be fake, but pseudorandomly generated keys are good enough for most applications of cryptography. A key generated by a pseudorandom number generator (the cryptographic algorithm used to create it) has the potential to be just as difficult for an attacker to guess as is a key generated by coin flips. But only the potential to be that difficult.
Over the years, use of poor pseudorandom number generators has been a point of weakness in cryptosystems. This vulnerability is probably down to oversight. It’s common to see security products advertising their use of “state-of-the-art AES 128-bit encryption,” but rare to see them boasting proudly about how the keys are generated. A bad pseudorandom number generator will not generate (seemingly) random keys. An attacker who analyzes such a generator may discover that some keys are never generated at all, or that some are generated more commonly than others. This is extremely useful knowledge if you’re an attacker considering exhaustively searching for an unknown secret key.37
As noted earlier, since large random numbers are not easily memorized, one technique sometimes used for pseudorandomly generating a key is to derive it from a password. You enter the password, and then a pseudorandom number generator is used to convert this password into a cryptographic key. If this is not done extremely carefully, all sorts of problems can arise. For example, keys derived from common passwords might be generated more commonly than others, while keys derived from highly unusual passwords might never be generated. The solution, as always, is to use the best tools available. In this case, cryptographers have designed special key-derivation functions, which are algorithms designed especially to generate keys from the likes of passwords.38
Key generation for asymmetric cryptography is even more complicated because asymmetric keys are not “simply” random numbers. The specification of every asymmetric algorithm includes information about how to generate the necessary keys. If this advice is adhered to, then all should be well. But alas, humans are notoriously poor at following advice, especially when it looks complicated. Investigations have shown that, in many cases, developers have simply not followed these instructions—the result being poor key generation. For example, studies have shown that vast numbers of RSA public keys on the internet share certain properties (more precisely, they share prime factors) that render them insecure.39 This overlap cannot be a coincidence, and it strongly suggests that the key-generation processes used were flawed.
These days, most people don’t design their own cryptographic algorithms (this message seems to have finally been heard by the majority of developers). Only the wise, however, resist the temptation to draw up their own key-generation methods on the back of an envelope.
Getting the Right Keys to the Right Places
Key distribution is one of the most critical stages of key management, and I’ve discussed it at some length. Key distribution is about getting the right keys securely to the right places.
Getting the right keys to the wrong places would clearly be a bad thing. Hence, considerable effort tends to be invested in key distribution, and there are many different techniques. As already noted, for many applications keys are distributed during manufacture, since keys come preinstalled on devices (mobile SIM cards, car key fobs, etc.). In other cases, key distribution is straightforward because devices that need to share keys are physically close to one another (for example, you read the key on the back of your Wi-Fi router and type it into devices permitted to connect to your Wi-Fi network). In centrally managed systems, keys can be distributed securely by means of closely governed processes and controls. Banks have highly secure processes for distributing keys used in the hardware of ATMs, customers’ bank cards, and so on.
Once one key has been distributed to two parties, the hassle of further key distribution can often be avoided by the use of a key-derivation function to pseudorandomly derive new keys from the original key. Your mobile-network operator distributed a key to you embedded on the SIM card that you purchased with your call plan. Each time you make a phone call, the call is encrypted with an entirely new key. This new key is derived from the key on your SIM card. Since both you and the mobile-network operator know the original key, you can both individually derive the same new key from it; nothing further needs to be distributed. This new key is used to encrypt the call and is then discarded. The next time you make a call, yet another new key is derived from the original key on your SIM card.40
Key distribution is more challenging when the communicating parties are in open systems such as the internet. By this I mean that the parties are potentially located far from one another and have no prior business relationship during which keys could have been distributed. This is typically the case when, for example, you buy something from an online store, or exchange a WhatsApp message with a new contact. As noted previously, this is precisely the type of situation that motivates the use of asymmetric encryption. Hybrid encryption provides a means of distributing symmetric keys under the protection of asymmetric encryption. Another well-known technique for distributing keys in this scenario is Diffie-Hellman key agreement, which provides a means whereby two parties can each send the other a public key and then, from these, each derive a common secret key.41
Stopping the right keys from going to the wrong places addresses only half of the key-distribution problem. Just as problematic is stopping the wrong keys from going to the right places. I flagged this issue when I discussed the problems of asymmetric encryption, noting how important it is to make sure a public key is correctly associated with the identity of its owner. Without this linkage, a criminal might be able to create a convincing copy of a legitimate website, supply you with the criminal’s public key instead of the legitimate website’s public key, and then steal your bank card details when you, in good faith, tried to pay for something. What you need is some means of making sure that the public key supplied by a website belongs to the website you believe it does.
The standard tool for linking a public key to its owner is a public-key certificate. At its heart, a public-key certificate is a simple statement, much like all those other certificates you might have hanging on your wall at home. In my house we have the following:
This is to certify Kyla has passed her Grade 2 Guitar with Merit.
This is to certify Finlay won a Class Prize for his super listening.
This is to certify Ramon completed his Adult Dog Training Class.
A public-key certificate essentially states: This is to certify the public key of www.reallycheapwidgets.com is X, where X is a valid public key of such enormity that I won’t write it out in full.42
Certificates make grand claims, but the question behind them is: “Who says so?” For the first of our wall certificates, it’s the Chief Executive of the Associated Board of the Royal School of Music; for the second, it’s the Head Teacher, St. Cuthbert’s Primary; for the third, Sarah Hickmott BSc (Hons) of Pet Necessities Professional Training. Who says so? Someone important. Someone who should know. All of these parties share a degree of authority and respect in their field.
Likewise, a public-key certificate needs to be created by someone trusted to vouch for the correctness of the linkage between a public key and its owner. In cyberspace, this role is played by a certificate authority, which could be an official body (for example, the government) or a commercial provider of such certification services.43 Anyone relying on the public key needs to be able to trust the certificate authority. If you don’t trust the certificate authority to have done its job, then you shouldn’t trust the information in the certificate. It’s that simple.
One common mistake is to read too much into the existence of a certificate. A certificate vouches only for precisely what it states, and nothing more. Finlay might well be a super listener at school, but does this make him a super listener at home? Ramon attended the dog training class, but did he actually learn anything? (Only that he loves cheese.) The simple fact that the public key of www.reallycheapwidgets.com is X does not automatically imply that the key is valid beyond a certain date or can be used to encrypt financial data, or anything else. Public-key certificates tend to include other related data to cover some of these issues. However, even a more detailed public-key certificate is just a set of facts relating to the public key. It doesn’t provide assurance about deeper issues, such as whether the public key was generated securely in the first place.44
Ultimately, a certificate is only as good as the integrity mechanisms used to protect the information contained in it. Kyla’s certificate has a watermark, is printed on regal parchment, and is adorned by various official logos. (The other two paper certificates feature colorful drawings of wax seals.) A public-key certificate, being a cyber object, needs a cryptographic data integrity solution. The certificate authority seals all the information in the public-key certificate by digitally signing it. Anyone relying on the information in the public-key certificate needs to verify this digital signature to confirm the integrity of the contents. To do so, they need the public verification key used to verify digital signatures created by the certificate authority. Since they need to be sure that this public key is really the public key associated with the certificate authority, this public key also needs to be linked to the certificate authority by means of a public-key certificate. So, who signs this one?
When you buy something online from the likes of Really Cheap Widgets, the matter of public-key certificates is largely handled for you by your web browser software. Before becoming an online trader, Really Cheap Widgets will have been required to obtain a public-key certificate from a recognized certificate authority. This certificate authority’s public key will itself have been certified by a higher certificate authority. Ultimately, a root certificate authority will have had its public-key certificate verified and installed in your web browser software.45 When Really Cheap Widgets sends its public-key certificate to your web browser, the browser software verifies all the relevant certificates. If everything is fine, then your transaction proceeds without incident. If one of the verifications fails, then your browser might issue a warning message, asking you whether you wish to continue. This message essentially informs you that the browser cannot guarantee that it is communicating with the genuine www.reallycheapwidgets.com. Whether or not you proceed is up to you. Prudence suggests you should terminate the connection.46
Hopefully, this discussion has strayed far enough into public-key management to demonstrate the general idea of using public-key certificates to vouch for the true owner of a public key. Enough, also, to show that public-key certification is a tricky business with plenty of management processes to conduct. I have not talked about how a certificate authority might identify the owner of a public key. Nor have I discussed what happens if the information contained in a public-key certificate needs to be changed. Supporting public-key certificates requires an entire infrastructure surrounding them to address those issues.47
Key distribution has its challenges, but there are many different solutions. We use cryptography every day because, when carefully chosen and implemented, these different solutions all work.
Beyond Cryptography
Recall what happens to data during the encryption process: Data . . . data . . . <encryption—kapow!> encrypted data . . . encrypted data . . . <decryption—kapow!> data . . . data . . . In other words, between the first kapow and the second, data is protected by encryption. But before the first, and after the second, it’s not.
How obvious is this? Data is not encrypted when it’s not encrypted. What an earth-shattering observation! Except that, a not uncommon failure of cryptographic protection is not to recognize when, and where, data might exist in unencrypted form.
A good illustration of the importance of endpoint security is the use of the TLS protocol for securing web connections. If you’re buying a product from an online store, you will almost certainly use TLS to encrypt the transaction details when you check out. The TLS protocol encrypts data, such as your payment card details, between your web browser and the web server of the store. It does not encrypt this data from the point at which you enter it in your keypad. Here, the data might exist in temporary memory, or indeed it might be stored somewhere on your computer. The data could be obtained by anyone standing behind you, watching as you type. It is potentially available to anyone else who has access to your computer or can run a program on your computer. The data might also be available to anyone who has installed a keylogger on your keyboard to record your keystrokes. At the web server end, goodness knows who has access. Some websites store card details in a database, meaning, potentially, that anyone with access to the database could obtain them. While online retailers should protect such data with great care (using cryptography, of course), you can never be sure.48
Digital forensic investigators coming across encrypted data don’t simply give up and go home. They know all too well that data often lies around, sometimes in surprising places, both before encryption and after decryption. A naive person trying to hide some data on a laptop might encrypt a file and then delete the original, leaving only an apparently encrypted file in their directory. However, deleting a file does not necessarily destroy it; it merely breaks the digital association between the file itself and the label the laptop uses to locate it. Someone who knows what they’re doing can rummage around on the laptop and retrieve the unlabeled “deleted” file.49
As observed during take three of the scene in which an intelligence agent is working frantically against the clock to save the world, another piece of information that could be carelessly lying around at an endpoint is a cryptographic key. The best way of storing a cryptographic key is in secure hardware. Smartcards such as bank cards and SIM cards are lightweight examples. More heavyweight technologies for storing keys are hardware security modules, which are dedicated pieces of equipment for storing and managing keys.50 Extracting a key from a secure hardware device is difficult. However, if an application has taken the lazier, and far cheaper, option of storing keys in software, then a detailed analysis of the endpoint might find them and unlock encryption.
Computer security expert Gene Spafford famously observed: “Using encryption on the Internet is the equivalent of arranging an armored car to deliver credit card information from someone living in a cardboard box to someone living on a park bench.”51 Encryption works, but for much of what you do in cyberspace, you are on the park bench.
Carbon-Based Security
Cybersecurity experts have been known, perhaps too often, to claim that humans are the “weakest link” in any security system, including cryptosystems.52 This claim seems to imply that most security incidents arise from the carelessness or stupidity of the human beings who use the system. You choose the best encryption algorithm in the business, implement it to perfection, manage the keys to the highest standards, and then what happens? Some idiotic human being writes the key on a Post-it note and sticks it on their screen.
Alas, this can happen. However, the claim that humans are the greatest point of vulnerability in a cryptosystem raises some pretty big questions. Who is serving whom in this scenario? Setting aside scary visions of the future, at least for now, most technology is designed for the benefit of human beings. Suggesting that humans are letting the technology down almost suggests that the tail is wagging the dog. Much more fundamentally, if it is, in fact, true that the points of interaction between humans and the rest of a cryptosystem are the places where things are most likely to go awry, then surely the system should be designed to counter this weakness. The human interaction part should be managed, not bemoaned.
What kind of cryptographic calamities could be induced by the human users at the endpoint of a cryptosystem? Users could encrypt a file on the secure system and then save an unencrypted copy on a memory stick, which they could then take home and lose on the bus. They could fail to encrypt sensitive material, or inadvertently turn encryption off. They could write down passwords for the derivation of cryptographic keys. They could lend smartcards containing cryptographic keys (bank cards, employee cards, identity cards) to friends. They could encrypt the data on their laptop and then lose the key. They could go to lunch, leaving their unattended cryptographically enabled device logged on and available for anyone passing by to use. Silly, silly humans. What to do?
Mistakes and incompetence are a fact of life. By far the best way of handling such risks is to deploy cryptography in such a way that there’s no human interaction at all. Mobile phone call security is a good example. You enter the number and the line connects. When did the cryptography happen? Well, it just did, without your involvement. The same is true for many of our other everyday technologies, such as internet messaging services. Cryptography happens, by default, without human intervention.
One slight risk with making cryptography so seamless is that bypassing the human prevents a level of interaction between person and machine that might be desirable from a security perspective. For example, the invisible cryptography that is in operation between the key and door of your car does not demand anything of you other than having the car key in your pocket. This leaves little room for bumbling human misuse of cryptography and allows for flexibility, since you can permit a family member to borrow the car by simply lending them the key. However, it also means that anyone who steals your car key has everything they need to open your car door and drive away.
You probably don’t want quite the same personal disengagement from the process when accessing your online bank account. This is why enabling the cryptographic services that support online banking typically requires human interaction, often through the presentation of PINs, passwords, biometrics, access codes delivered by mobile phone, and the like. These pieces of information strengthen security by linking the use of cryptography to a human being, rather than to simple possession of a security token such as a smartcard or authenticator. By involving a human, however, they also introduce a new point of vulnerability in the system: someone who can lose things, forget things, poorly choose things, or give things away.
Automatically applying cryptography also introduces some less obvious problems. For example, suppose an organization moves from a policy of permitting employees to optionally encrypt their own laptops, to enforcing laptop encryption through a centralized system. Such enforcement appears to solve the problem of information leaking from an unencrypted laptop. However, it introduces a potentially more serious vulnerability; namely, if the organization decides to use a single master key to encrypt each laptop’s encryption key, then the information on all laptops will potentially be at risk if this master key is exposed.53
As another example, using an automatically encrypted messaging service might encourage a user to be less careful about the information they send over it. Should their phone be seized as part of an investigation, the unencrypted data might be recovered from the phone itself. Ironically, default application of encryption might result in less information remaining confidential than would otherwise have been the case.
Sometimes, however, we have no choice but to involve humans in the cryptographic process. You probably don’t encrypt every attachment you send by email. Occasionally, however, you might want to send a confidential attachment. In this case, you’ll need to activate encryption in some way, either through an extension to your email software or by means of a dedicated encryption tool on your computer. Such activation requires you, the human, to do something. Sadly, encryption products can be difficult for people with little understanding or experience of computers or cryptography to use.54 Users have been known to abandon attempts to encrypt data, lost amid jargon and mystifying instructions. Humans should not be regarded as the weakest link, but a confused human has every chance of becoming so.
Cryptography serves humans, not the other way around. In a secure cryptosystem, the interaction between the cryptographic mechanisms and the human users of the technology should be carefully factored into the design, either by minimization of the need for user interaction, or by clear explanation and motivation for the relevant steps.55 The real weakest link in a cryptosystem is failure to take into account how humans will interact with the system.
Making Cryptography Work
You could be forgiven for concluding that it’s impossible to make cryptography work in practice, given the catalog of potential failures just presented. It’s informative to have absorbed this message, but that verdict is not entirely fair. It might not be easy to get cryptography right, but with care, cryptography can be made to work.
It’s certainly worth trying to do so. Some people argue that no cryptography is better than bad cryptography, since a poor cryptosystem, wherever its points of failure are, can lead to a dangerously false sense of security.56 In many contexts this argument is hard to refute. However, although cryptography is hard to get right, the case for trying to do so is surely stronger than the case for giving up before you start. After all, even the Caesar cipher will keep your secrets secret from most people you know.
There’s plenty of room for optimism. We, as a society, have become more skilled at designing cryptographic algorithms and protocols. We’ve improved our techniques for security design and implementation. We’ve developed standards for securely managing cryptographic keys. We’ve also become much more experienced at deploying cryptography, and we’ve learned many useful lessons from past mistakes. By and large, we know how to make cryptography work; what we need to do is practice what we already know.
Making cryptography work requires full consideration of the wider cryptosystem that surrounds the cryptographic algorithms and keys. We need to get every single part of this system right. Nothing made this clearer than Edward Snowden’s 2013 revelations about various ways in which our use of cryptography in cyberspace was not working. Whatever your views are on the ethics of what Snowden did, his revelations served as a useful reminder that anyone trying to subvert the protection offered by cryptography only has to find a weak point somewhere in the cryptosystem. There are many potential “somewheres,” and these are rarely the cryptography itself.