Category: books

Book Review: Red Team Blues

Book Review: Red Team Blues

As a rule, book reviews are not a thing I usually do.

So when I received an out-of-the-blue email from Cory Doctorow last week asking if I would review his latest book, Red Team Blues, it took a minute to overcome my initial skepticism. While I’m a fan of Cory’s work, this is a narrow/nerdy blog about cryptography, not a place where we spend much time on literature. Moreover, my only previous attempt to review a popular cryptography novel — a quick sketch of Dan Brown’s abysmal Digital Fortress — did not go very well for anyone.

But Cory isn’t Dan Brown. And Red Team Blues is definitely not Digital Fortress.

This became obvious in the middle of the first chapter, when a character began explaining the operation of a trusted execution environment and its various digital signing keys. While it’s always fun to read about gangsters and exploding cars, there’s something particularly nice about a book whose plot hangs around a piece of technology that most people don’t even think about. (And if that isn’t your thing, there are exploding cars and gangsters.)

This still leaves the question of how a cryptography blog reviews a work of fiction, even one centered on cryptography. The answer is pretty simple: I’m not going to talk much about the story. If you want that, there are other reviews out there. While I did enjoy the book immensely and I’m hopeful Cory will write more books in this line (with hopefully more cryptography), I’ll mainly focus on the plausibility of the core technical setup.

But even to do that, I have to provide a few basic details about the story. (Note: minor spoilers below, but really only two chapters’ worth.)

The protagonist of Red Team Blues is 67-year-old Martin Hench, an expert forensic accountant with decades of experience tracing and recovering funds for some of the most powerful people in Silicon Valley. Martin is on the brink of retirement, lives in a bus named “the Unsalted Hash” and loves bourbon nearly as much as he despises cryptocurrency. This latter position is presumably a difficult one for someone in Martin’s line of work, and sure enough his conviction is quickly put to the test.

Before long Martin is hired by his old friend Danny Lazer — sort of a cross between Phil Zimmerman, David Chaum and (maybe) Max Levchin — who begs him to take one last career-defining job: namely, to save his friend’s life by saving his newest project: a cryptocurrency called TrustlessCoin.

TrustlessCoin is a private cryptocurrency: not terribly different from real ones like Monero or Zcash. (As a founding scientist of a private cryptocurrency, let me say that none of the things in this novel have ever happened to me, and I’m slightly disappointed in that.)

Unlike standard cryptocurrencies, TrustlessCoin contains one unusual and slightly horrifying technological twist. Where standard cryptocurrencies rely on consensus algorithms to construct a public ledger (and zero-knowledge proofs for privacy), TrustlessCoin bases its integrity on the security of mobile Trusted Execution Environments (TEEs). This means that its node software runs inside of systems like Intel’s SGX, ARM’s TrustZone, or Apple’s Secure Enclave Processor.

Now, this idea isn’t entirely unprecedented. Indeed, some real systems like MobileCoin, Secret Network and Intel’s PoET take a fairly similar approach — although admittedly, these rely mainly on server-based TEEs rather than mobile ones. It is, however, an idea that makes me want to scream like a child who just found a severed human finger in his bowl of cornflakes.

You see, TEEs allow you to run software (more) securely inside of your own device, which is a good and respectable thing to do. But distributed systems often require more: they must ensure that everyone else in the network is also running the software in a similarly-trustworthy environment. If some people aren’t doing so — that is, if they’re running the software on a computer they can tamper with and control — then that can potentially harm the security of the entire network.

TEE designers have been aware of this idea for a long time, and for years have been trying to address this using secure remote attestation. Attestation systems provision each processor with a digital signing key (in turn certified by the manufacturer’s root signing key) that allows the processor to produce attestations. These signed messages “prove” to remote parties that you’re actually running the software inside a valid TEE, rather than on some insecure VMWare image or a Raspberry Pi. Provided these systems all work perfectly, everyone in the system can communicate with everyone else and know that they are running the software on secure hardware as well.

The problems crop up when that assumption breaks down. If even a single person can emulate the software inside a TEE on their own (non-trusted device or VM) then all of your beautiful assumptions may go out the window. Indeed, something very similar to this recently happened to Secret Network: clever academic researchers found a way to extract a master decryption key from (one) processor, and were then able to use that key to destroy privacy guarantees across the whole network. (Some mitigations have since been deployed.)

It goes without saying that Red Team Blues is not about side-channel attacks on processors. The problem in this novel is vastly worse: Danny Lazer has gone and bribed someone to steal the secret root signing keys for every major mobile secure enclave processor: and, of course, they’ve been all been stolen. Hench’s problem is to figure out whether it’s even possible to get them back. And that’s only the beginning of the story.

As its name implies, Red Team Blues is a novel about the difference between offense and defense: about how much more difficult it is to secure a system than it is to attack one. This metaphor applies to just about every aspect of life, from our assumptions about computer security to the way we live our lives and build our societies.

But setting all these heavy thoughts aside, mostly Red Team Blues is a quick fun read. You can get the eBook without DRM, or listen to an audiobook version narrated by Wil Wheaton (although I didn’t listen to it because I couldn’t put the book down.)

Digital Fortress: I read it so you don’t have to

Once in a while I run into a work of dramatic fiction that takes such a powerful, realistic look at modern cryptography — and its implications for our national security — that we should all be grateful to the author. They’ve made us all a little bit smarter.

Needless to say, Dan Brown’s Digital Fortress is not one of those books.

What is Digital Fortress? I’m not sure. It may be a practical joke. I’m hoping so, anyway, because the alternative — that Dan Brown spent time learning about cryptography and this is what came out — is too terrible to contemplate.

Miraculously, the end result is so ridiculous that it’s almost tolerable. Almost.

(Before I go further, I should warn you that there are huge spoilers below. But don’t worry about it because (a) you shouldn’t read this book, and (b) the plot is so predictable that I doubt it can really be spoiled.)

Where to begin? Let me just hit some of the high notes:

  • Matt Blaze gets whacked. Ok, Brown doesn’t call him Matt Blaze. The character in the book is named Greg Hale (single syllables, get it?) But we know he’s Matt Blaze because he single-handedly discovered a backdoor (“a few lines of cunning programming”) in the Skipjack cipher, one that would have let the NSA “read the world’s email”.For his efforts, Blaze/Hale is rewarded with a thankless job at the NSA which he hates. And not without reason! Everyone suspects him of being a turncoat (while simultaneously giving him access to their most important secrets, go figure.) Then to cap off the job experience, he’s horrifically murdered. I personally would have ended the book halfway through, and just made Hale the bad guy. Who could blame him
  • The EFF are the bad guys. Did you know that the National Security Agency (2011 ops budget: $9 bazillion) lives in constant terror of the “sharks” over at the Electronic Frontier Foundation (2011 ops budget: $67.34, mostly spent on construction paper)?I did not know this. I sure hope it’s true.Near the end of the book the NSA’s “firewall” goes down for a few minutes, and within seconds the EFF sharks are circling. This does not appear to be a metaphor — they’re actually swimming in literal circles around the NSA’s cyber-perimeter, trying to ferret out our nation’s secrets. Only our hero Susan Fletcher can stop them, thanks to her long, willowy legs staggering intellect.
  • The NSA has a secret supercomputer named TRANSLTR that can brute-force any cryptosystem. Hmm. Ok. This one is actually pretty accurate.
  • TRANSLTR is stumped by a new cipher that uses “rotating cleartext” to resist brute-force attacks. No, seriously. “Rotating cleartext”. Brilliant! This is such a good idea that I hereby offer to make this scheme a reality for only $800. My only condition is that you must never, ever try to decrypt anything with it.

I suppose I could also mention the NSA’s recruiting program for cryptographers, which would make a Big Ten football coach blush. Or the way that brilliant, righteous people always seem to be beautiful and athletic, while stupid evil people look like trolls (have you ever been to a crypto conference, Dan?)

These and other details are embedded in a stew of unintentional comic awfulness that really defies summarization. But it’s good. Not to read, mind you. Just to know about, so you have a reason to chuckle while you’re lamenting the damage that Brown’s writing has done to your temporal lobe.

I really could not recommend this book less, and am considering sending Dan Brown a bill for the time I spent reading it. But if you’re afflicted by a terrible case of Seasonal Affective Disorder and just need some levity in your life, it might keep you giggling through the long dark months ahead.

Happy Thanksgiving everyone!

In defense of Applied Cryptography

Over the weekend I found myself re-reading a few bits of Bruce Schneier’s Applied Cryptography for a historical research project, and it reminded me what a fantastically wonderful, completely insane piece of writing it is. I’m sure Bruce Schneier needs no additional validation in his life, but I do think it’s worth saying a few words about the book — and why we need more works like it in our field.

I should preface this all by saying that Applied Cryptography is probably one of the most influential crypto books ever written. It certainly played a part in getting me interested in the field. If you don’t own a copy, you should, if only to be awed by Bruce’s knowledge of bizarre, historical ciphers and all of the ways they’ve been broken. (Though the most recent edition is from 1996, so don’t go looking for up to date information in it.)

Much the way a hard-core Nirvana fan will roll their eyes if you mention “Nevermind”, people in the crypto research community tend to get a little bent out of shape if someone references Applied Cryptography. This is not because AC is a lousy book, or because the material is inaccessible or wrong. Quite the contrary. Rather, the case against Applied Cryptography is that it made cryptography too damned accessible. And that has led to a whole lot of fail, some on a pretty grand scale.

The detailed argument goes something like this: Applied Cryptography demystified cryptography for a lot of people. By doing so, it empowered them to experiment with crypto techniques, and to implement their own code. No problem so far.

Unfortunately, some readers, abetted by Bruce’s detailed explanations and convenient source code examples, felt that they were now ready to implement crypto professionally. Inevitably their code made its way into commercial products, which shipped full of horribly ridiculous, broken crypto implementations. This is the part that was not so good. We’re probably still dealing with the blowback today.

Just for one modest example, take this fragment of code spotted in a Diebold voting machine, circa 2003:

// LCG – Linear Conguential Generator – used to generate ballot serial numbers 
// A psuedo-random-sequence generator  
// (per Applied Cryptography, by Bruce Schneier, Wiley, 1996) 
#define LCG_MULTIPLIER 1366 
#define LCG_INCREMENTOR 150889 …

Thanks to Applied Cryptography, the Diebold coders were able to write a perfectly functional Linear Congruential Generator in no time at all. You certainly can’t blame Bruce for anything here — the LCG code is fine. It’s certainly not his fault that Diebold missed the part where he warned never to use LCGs for security applications. Whoops!

Although it’s all said with love, some people really do blame Applied Cryptography for this sort of thing. Even Bruce has at various points himself apologized for this aspect of the book.

(Not coincidentally, you’ll notice that his more recent books are nowhere near as brazenly useful as AC. Where Practical Cryptography is all crapped up with grave warnings about the dangers of rolling your own crypto implementations, Applied Cryptography just laid it all out there sans apology, like a copy of the Anarchist Cookbook left open in a middle school library.)

But I said that I’m writing this post to praise the book, not to damn it with faint praise.

What’s magical about Applied Cryptography is really two things. First of all, it’s an incredible historical document. If there’s a cipher that was used in the period 1970-1996, you’ll read about it in Applied Cryptography. Even if the cipher was based on the cryptographic equivalent of an abacus, even if it was broken in the same conference in which it was published, Bruce will still give you a full design description and the address of the guy who owns the patent.

And you have to love the understated way in which he sums up his opinions. Take, for example, the section on the FEAL cipher. After four dense paragraphs in which he lays out not one, but eleven devastating attacks culminating in the total demolition of FEAL (and possibly, the ritual suicide of its designers), he could have written something terrible, capping it with three exclamation points. Instead, he leaves it with the following, dry remark:

Whenever someone discovers a new cryptanalytic attack, he always seems to try it out on FEAL first.

All joking aside, I’ve found Applied Cryptography (and its massive bibliography) to be incredibly useful, particularly when examining historical crypto software, and (most importantly) when finding prior art to current crypto patents. Applied Cryptography is like a key to a time period that’s not well covered by Google Scholar or other Internet search tools. It’s helped me through more than one trip to the library.

The other magical thing about AC is that you really feel that after writing it, Bruce must have been a few pounds lighter — and some of that weight was his soul. I’m not saying he’s soulless! (Though he does work for BT now, doesn’t he?) It’s just that there’s just no way to read through this monster of a book, with its enormous compendium of bibliographies and source code, and imagine someone writing this thing just for the money or even for the fame. In my opinion it’s an achievement of practical cryptography that has not been matched either before or since.

And that’s too bad, because someone really should try.