Nothing Is Too Hidden to Hack

In William Gibsons definitive cyberpunk short story, “Burning Chrome,” the narrator is a hardware hacker called Automatic Jack. As the story begins, Jack describes the attack console used by his partner: “I knew every chip in Bobbys simulator by heart; it looked like your workaday Ono-Sendai VII, the Cyberspace Seven, but Id rebuilt it so many times that youd have had a hard time finding a square millimeter of factory circuitry in all that silicon.”

Ive always thought that sentence a pardonable piece of literary license: After all, Gibson famously wrote his groundbreaking stories on a manual typewriter. I had to rethink that characterization, though, after reading MIT doctoral candidate Andrew Huangs account of his attack on the hardware security of Microsofts Xbox.

At one point, Huang wrote, “maybe Ill sacrifice a GameCube for the sake of curiosity and dissolve the package with hot sulfuric…or better yet, try and shave the package down so I can extract the pinout through visual inspection.” Were not talking about scanning tunneling microscopes or multi-gigahertz oscilloscopes here. Were talking about exceedingly well informed, but essentially low-tech, attacks.

Huangs disclosures convey implicit messages that have to be understood by anyone involved in developing or deploying IT.

First, theres no such thing as security based on obscurity or inconvenience. Someone, somewhere, will dig deep enough to figure out what youve done and how—either for financial gain, or just for the sake of curiosity.

Second, theres no “technology floor” below which it becomes intrinsically safe to send valuable information in unencrypted forms. Even at a microscopic level, formal protocols at some point turn into actual volts and amperes: Anything that “friendly” hardware can process as bits, invasive hardware can analyze as intercepted signals that an attacker can then deconstruct.

About 15 years ago, I was in a panel discussion with someone who said that the next 10 years worth of computer price/performance gains would all be absorbed by the user interface. Reality turned out to be even more resource-intensive, I would argue, in that the typical Windows system of 1995 was actually more sluggish in many ways than the 8 MHz 8086-based DOS machine that was on my desk at the time of that conversation.

Between 1995 and 2005, it wouldnt surprise me if another decades worth of hardware performance progress were to be absorbed in security—either on our increasingly mobile (and therefore vulnerable) client devices, or at the level of the network infrastructure.

Distributed processing, and a well-developed sense of shared responsibility, are the levers that we need to pry ourselves loose from this burden—and get back to improving the return on our IT investments.

E-mail me and tell me how youll gain leverage against security problems.