Quantum cryptography is useless

Bruce Schneier is right on the money with this article criticizing quantum crypto.  Quantum cryptography (not quantum computing) is one of those concepts that appeals to the public and the more theoretically-minded, but is next to useless for providing actual security.  Here are some less-known problems with it that I haven’t seen discussed much elsewhere.

Quantum cryptography is focused on one narrow aspect of security: key establishment.  To put it simply, this involves exchanging photons with a particular polarization.  The transmitter randomly sets their polarizer to one angle or the other and sends a photon.  The receiver also tunes their detector to a particular polarization.  The measured value at the receiver is dependent both on the sending and receiving polarizer states, as well as the bit transmitted.  The sender and receiver repeat this process many times in both directions to get a set of bits.  Some will be errors and some will be usable as a key, shared between both but secret.

To receive a photon, an attacker also has to choose a polarization.  By measuring the photon, the state of the attacker’s polarizer is encoded in the photon.  This means that the attacker cannot learn the bits without desynchronizing the sender and receiver.  If the error rate is too high, an attacker is present (or the fibre is bad).

There are a number of well-known issues with quantum crypto.  This key exchange process requires a reliable, non-influencable source of random bits at both the sender and receiver.  Also, there needs to be some kind of pre-existing shared secret between both parties to authenticate themselves.  The only way to do this is through classic crypto (e.g., public key).  Otherwise, the attacker could just splice a receiver and transmitter into the cable and perform a standard MITM attack.  Finally, the actual communication between the two parties is encrypted with a traditional cipher like AES, using the shared key.

I think this alone is enough to undermine the case for quantum crypto.  If you are convinced to spend lots of money and effort to replace classical crypto for the sole purpose of key exchange, shouldn’t standard crypto be considered unreliable for authentication and bulk encryption also?  This is Bruce’s point and is based on simple threat analysis.

Recently, this paper was published describing how bright flashes of light could temporarily overwhelm the detector circuit, allowing an attacker to trick the receiver into accepting bits as unmodified.  The receiver has multiple detectors, each with a different polarization.  Normally, only a photon with the proper polarization triggers the corresponding detector.  But a bright pulse at a particular frequency can temporarily blind multiple detectors, leaving the remaining one to trigger on a subsequent pulse.  By varying the frequency of the bright pulse to select individual detectors, the attacker can manipulate the receiver into thinking the originally transmitted bits are being received correctly.

This is a clever attack because it is based on unstated assumptions.  Quantum crypto doesn’t specify how a perfect detector circuit can be designed.  That’s just a black box.  The designers assume that individual photons can go into the black box and be measured securely.  But it’s not a black box, it’s a real world circuit that depends on optoelectronics and has associated limitations.

You can draw an analogy here to side channel or differential fault analysis.  The AES algorithm might be considered computationally secure, but there are many underlying assumptions in a real-world system that implements it.  There has to be a computer running the algorithm.  It may be realized in hardware or software.  It requires memory (DRAM, disk, core, tape?) to store intermediate state.  It takes up physical space somewhere.  It gets its input over some kind of busses.  The environment may be hostile, with varying voltage, heat, clock frequency, etc.

What other attacks could there be?  Is it possible to determine which polarizer was selected in the transmitter by probing it with light while it is preparing to send the photon?  Does it consume more current when switching from one state to another?  Are there timing variations in the transmitted photons based on whether the polarizer switched state or not?

Classical crypto implementations have been continually hardened in response to these kinds of attacks.  I think the perceived theoretical invulnerability of quantum crypto has resulted in less attention to preventing side channel or fault analysis attacks.  In this sense, quantum crypto systems are less secure than those based on classical crypto.  Given its cost and narrow focus on strengthening only key exchange, I can’t see any reason for using quantum crypto.

Dangers of amateur cryptography

This math blog has begun a series of articles on cryptography.  While that blog had some good articles on mathematics, it was pretty clear the cryptography series would have some issues.  Whenever I read articles about engineers picking up cryptography, warning sirens go off in my head.

When the first article on block ciphers stated incorrectly that the DES initial/final permutations were to prevent brute force attacks, I posted a correction.  I also noted that if he’s going to write about how to do cryptography, it would be good to provide a disclaimer.

I like your blog overall, but this series on crypto is a bit dangerous for amateurs. The devil is in the details, and it’s very easy to make a critical mistake. So while it’s good to give people an intro, I suggest a big warning letting them know that there are some dangerous assumptions lurking below the surface, and that they should always use well-reviewed implementations and protocols (i.e. SSL) rather than rolling their own for pure ego reasons.

The next article on modes of operation for block ciphers had a completely incorrect description of counter mode.  John Kelsey pointed out other issues with this article.  I again requested that Mark use this as a good example how it is hard to get crypto right.

After that, he posted a correction to the description of counter mode.  Unfortunately, his correction was wrong also as another reader and I pointed out.

I am not picking on Mark.  He’s a smart person.  However, it’s important that we pay attention to how hard it is to get cryptography right.  I write about crypto here as well, often getting friends to review articles to be sure there aren’t issues with my description.  I hope my articles have never given the idea that crypto is easy.  When someone focuses on the primitives, like block ciphers, even a correct description can give the reader the false impression that using block ciphers is straightforward.  The book Applied Cryptography, with its nice but simple descriptions, created a generation of engineers with this misconception.

The articles and comments on them are vaguely reminiscent of the “rainbow tables” fiasco.  Even a well-written, detailed description of password hashing with a big disclaimer attached still resulted in dozens of engineers proposing flawed solutions of their own.  When will we learn?

MD5 considered primeval

The SF Chronicle talked to me last week about a forensic tool that uses MD5 to ensure its evidence has not been tampered with after collection.

Cellebrite’s Ofrat said that despite the theoretical possibility of hacks to MD5, the likelihood is low. “You’d have to have the best hacker in the world,” he said. But his firm is studying SHA-256 and will move to that if it becomes an industry standard, he said.

I appreciate his humble acknowledgement that anyone who can run a software tool is now “the best hacker in the world”. But perhaps they should move to more secure hash functions like SHA-256 anyway.  After all, other forensic software has moved to SHA-256 since at least 2003 after the US government (NIST) standardized on it in 2002.  Is that standard enough for Cellebrite?

FTC workshop on RFID

If you’re in Washington, DC on September 23, check out this workshop on RFID.  It aims to explore the security and privacy ramifications.

Workshop participants will discuss the increasing prevalence of contactless payment devices in everyday consumer transactions, including credit card purchases and public transit.  Panelists will further discuss the growing utilization of item-level tagging in the retail sector.  The workshop will explore security and privacy threats and proposed solutions, as well as consumer awareness and education initiatives regarding these developments.

I’ve never attended one of these workshops but one phrase is troubling.  The focus on “consumer awareness and education” seems to represent an attitude that the only problem with RFID is PR.  I doubt any of the security or privacy problems with RFID can be solved by user education.  Transcripts of the last workshop the FTC held on this subject can be found here.

The event will be webcast if you can’t make it and comments can be submitted until October 23.

Xbox 360 security talk

This recent video of Michael Steil and Felix Domke talking about the Xbox 360 security scheme is the best overview I’ve seen so far.

Michael previously gave a nice talk summarizing the security flaws in the original Xbox.

The CPU itself supports hashing and/or encryption of physical pages, based on flags set in the upper word of the 64-bit virtual address.  They talk about how Felix was able to leapfrog off shader-based DMA to write to an unencrypted register save state structure, jumping through a syscall gate (sorta like return-to-libc) that was improperly validated by the hypervisor.  The end result was arbitrary code execution in the context of the hypervisor.  Quite impressive.

I’ve always wondered how different security features like encrypted RAM that have long been present in smart cards would take to “trickle-up” to the more complex platforms like game consoles.  While the Xbox 360 security is much better than the original Xbox, it seems like the big-systems people are reinventing techniques already tested and worked out in the microcontroller world.

For example, the 360 was vulnerable to a timing attack, where an internal secret key can be guessed by timing how long it takes to validate the submitter’s HMAC.  I’d be extremely surprised if any mainstream smart card were vulnerable to such a well-known legacy bug.

I have yet to see anyone publish information about applying power or RF-based side channel analysis to a game console, despite smart cards adding countermeasures to these almost 10 years ago.  Even earlier attacks on encrypted RAM have still not been attempted on modern systems.

These attacks probably haven’t been needed yet since software bugs were still present. However, the push by game consoles and cellphone manufacturers to increase their resistance to software attacks means it won’t be long before side-channel resistance becomes a must-have feature.  It will be interesting to see how long it takes big-system manufacturers to add countermeasures and whether they’ll choose to learn from the hard lessons we have seen in the smart card world.