HDMI breakout lets you sniff HDCP crypto keys


There’s two really useful parts to this hack which involves sniffing the HDMI protocol’s HDCP security keys. The first is just getting at the signals without disrupting communications between two HDCP capable devices. To do so [Adam Laurie] started by building an HDMI breakout cable that also serves as a pass-through. The board seen above is known as an HDMI screw terminal board. The image shows one cable connecting to itself during the fabrication process. What he did was cut one end off of an HDMI cable, then used a continuity tester to figure out which screw terminal connects with which bare wire. After all the wires are accounted for the end with the plug goes to his TV, with a second cable connecting between the board’s socket and his DVD player.

The rest of his post is dedicated to sniffing the security keys. His weapon of choice on this adventure turns out to be a Bus Pirate but it runs a little slow to capture all of the data. He switches to a tool of his own design, which runs on a 60MHz PIC32 demo board. With it he’s able to get the keys which make decrypting the protected data┬ápossible.

Zigbee AES key sniffing


[Travis Goodspeed] posted a preview of what he’s working on for this Summer’s conferences. Last weekend he gave a quick demo of sniffing AES128 keys on Zigbee hardware at SOURCE Boston. The CC2420 radio module is used in many Zigbee/802.15.4 sensor networks and the keys have to be transferred over an SPI bus to the module. [Travis] used two syringe probes to monitor the clock line and the data on a TelosB mote, which uses the CC2420. Now that he has the capture, he’s planning on creating a script to automate finding the key.

TEMPEST: A Signal Problem


TEMPEST is the covername used by the NSA and other agencies to talk about emissions from computing machinery that can divulge what the equipment is processing. We’ve covered a few projects in the past that specifically intercept EM radiation. TEMPEST for Eliza can transmit via AM using a CRT monitor, and just last Fall a group showed how to monitor USB keyboards remotely. Through the Freedom of Information Act, an interesting article from 1972 has been released. TEMPEST: A Signal Problem (PDF) covers the early history of how this phenomenon was discovered. Uncovered by Bell Labs in WWII, it affected a piece of encryption gear they were supplying to the military. The plaintext could be read over that air and also by monitoring spikes on the powerlines. Their new, heavily shielded and line filtered version of the device was rejected by the military who simply told commanders to monitor a 100 feet around their post to prevent eavesdropping. It’s an interesting read and also covers acoustic monitoring. This is just the US history of TEMPEST though, but from the anecdotes it sounds like their enemies were not just keeping pace but were also better informed.

[via Schneier]

Use the CPU cache to prevent cold boot? No.


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!)]