Use the CPU cache to prevent cold boot? No.

coldboot

Frozen Cache is a blog dedicated to a novel way to prevent cold boot attacks. Last year the cold boot team demonstrated that they could extract encryption keys from a machine’s RAM by placing it in another system (or the same machine by doing a quick reboot). Frozen Cache aims to prevent this by storing the encryption key in the CPU’s cache. It copies the key out of RAM into the CPU’s registers and then zeroes it in RAM. It then freezes the cache and attempts to write the key back to RAM. The key is pushed into the cache, but isn’t written back to RAM.

The first major issue with this is the performance hit. You end up kneecapping the processor when you freeze the cache and the author suggests that you’d only do this when the screen is locked. We asked cold boot team member [Jacob Appelbaum] what he thought of the approach. He pointed out that the current cold boot attack reconstructs the key from the full keyschedule, which according to the Frozen Cache blog, still remains in RAM. They aren’t grabbing the specific key bits, but recreating it from all this redundant information in memory. At best, Frozen Cache is attempting to build a ‘ghetto crypto co-processor’.

We stand by our initial response to the cold boot attacks: It’s going to take a fundamental redesign of RAM before this is solved.

[via Slashdot]

Reverse engineering silicon logic

[Karsten Nohl] has recently joined the team on Flylogic’s blog. You may remember him as part of the team that reverse engineered the crypto in MiFare RFID chips. In his first post, he starts out with the basics of identifying logic cells. By studying the specific layout of the transistors you can reproduce the actual logic functions of the chip. The end of post holds a challenge for next week (pictured above). It has 34 transistors, 3 inputs, 2 outputs, and time variant behavior. Also, check out the Silicon Zoo which catalogs individual logic cells for identification.

Subway hacker speaks


Popular Mechanics has an interview with [Zach Anderson], one of the MIT hackers that was temporarily gagged by the MBTA. The interview is essentially a timeline of the events that led up to the Defcon talk cancellation. [Zach] pointed out a great article by The Tech that covers the vulnerabilities. The mag stripe cards can be easily cloned. The students we’re also able to increase the value of the card by brute forcing the checksum. There are only 64 possible checksum values, so they made a card for each one. It’s not graceful, but it works. The card values aren’t encrypted and there isn’t an auditing system to check what values should be on the card either. The RFID cards use Mifare classic, which we know is broken. It was NXP, Mifare’s manufacturer, that tipped off the MBTA on the actual presentation.

The Underhanded Hardware Challenge

The Polytechnic Institute of NYU is hosting an interesting embedded systems contest. They’ve constructed a solid state cryptographic device that uses a 128-bit private key. Contestants will be tasked with designing and implementing several trojans into the system that will undermine the security. The system is built on a Digilent BASYS Spartan-3 FPGA board. The trojans could do a wide variety of things: transmitting unencrypted, storing and transmitting previously entered plain text, or just shutting down the system entirely. The modified devices still need to pass the factory testing procedure though, which will measure power consumption, code size, and function. After a qualification round, participants will be given the necessary hardware to compete.

[via NYC Resistor (Happy Birthday!)]

HOPE 2008: The impossibility of hardware obfuscation


The Last HOPE is off and running in NYC. [Karsten Nohl] started the day by presenting The (Im)possibility of Hardware Obfuscation. [Karsten] is well versed in this subject having worked on a team that the broke the MiFare crypto1 RFID chip. The algorithm used is proprietary so part of their investigation was looking directly at the hardware. As [bunnie] mentioned in his Toorcon silicon hacking talk, silicon is hard to design even before considering security, it must obey the laws of physics (everything the hardware does has to be physically built), and in the manufacturing process the chip is reverse engineered to verify it. All of these elements make it very interesting for hackers. For the MiFare crack, they shaved off layers of silicon and photographed them. Using Matlab they visually identified the various gates and looked for crypto like parts. If you’re interested in what these logic cells look like, [Karsten] has assembled The Silicon Zoo. The Zoo has pictures of standard cells like inverters, buffers, latches, flip-flops, etc. Have a look at [Chris Tarnovsky]’s work to learn about how he processes smart cards or [nico]’s guide to exposing standard chips we covered earlier in the week.

Bruce Schneier’s opinion on everything


Honestly, we were originally sent this Q&A with famed cryptographer [Bruce Schneier] as a restaurant recommendation (112 Eatery, Minneapolis). Posted last fall on NYTimes’ Freakonomics blog it covers [Bruce]’s opinion on nearly everything. Here are a few items in particular that really stuck out to us:

The most immediate threat to the average person is crime – in particular, fraud. And as I said before, even if you don’t store that data on your computer, someone else has it on theirs. But the long-term threat of loss of privacy is much greater, because it has the potential to change society for the worse.

What you’re really asking me is about the security. No one steals credit card numbers one-by-one, by eavesdropping on the Internet connection. They’re all stolen in blocks of a million by hacking the back-end database. It doesn’t matter if you bought something over the Internet, by phone, by mail, or in person – you’re equally vulnerable.

We already knew he doesn’t secure his WiFi (neither do we) and you’ll find many other interesting discussions in the article. If you want Bruce Schneier facts though, you’ll have to look elsewhere.

Breaking disk encryption with RAM dumps


If you haven’t gotten a chance yet, do watch the video of this attack. It’s does a good job explaining the problem. Full drive encryption stores the key in RAM while the computer is powered on. The RAM’s stored data doesn’t immediately disappear when powered off, but fades over time. To recover the keys, they powered off the computer and booted from a USB disk that created an image of the RAM. You can read more about the attack here.

How can you reduce this threat? You can turn off USB booting and then put a password on the BIOS to prevent the specific activity shown in the video. Also, you can encrypt your rarely used data in a folder on the disk. They could still decrypt the disk, but they won’t get everything. I don’t think this problem will truly be fixed unless there is a fundamental change in hardware design to erase the RAM and even then it would probably only help computers that are powered off, not suspended.

The potential for this attack has always been talked about and I’m glad to see someone pull it off. I’m hoping to see future research into dumping RAM data using a USB/ExpressCard with DMA access.