Reverse Engineering the Nike+ Hardware

The Nike+ hardware is obviously an interesting device.  We haven’t heard a whole lot about hacking one until now, but [Dimitry] has decided to change that. Many would assume that the data transmitted off of these sensors is quite simple, however there’s a bit more than meets the eye. Amongst other challenges, all the data packets coming out of the transceiver are encrypted. [Dimitry] claims to have decoded this data stream and made use of it.

This hack also outlines how one can use this without the stock iPod receiver using a 2.4 GHz chip from Sparkfun. A lot of work has been done to figure out how these packets are decoded and the process one goes through to do this is well outlined in this post. This could serve as a good example for those wanting to figure out similar devices.

One thing [Dimitry] hasn’t done yet is release the source code for this hack. He cites some ethical issues that might not seem obvious on first glance, including the ability to follow someone in a crowd or simply jamming their data. He does add though that if you have a good reason for wanting it, to simply email him. We’re looking forward to what [Dimitry] comes up with in the future using this setup!

Intel: High-bandwidth Digital Content Protection cracked

Intel says that HDCP has been cracked, but they also say that it’s unlikely this information will be used to unlock the copying of anything. Their reasoning for the second statement is that for someone to make this work they would need to produce a computer chip, not something that is worth the effort.

We question that logic. Not so much for Blu-Ray, which is the commonly associated media format that uses HDCP, but for HD digital cable programming. There are folks out there who would like to have the option of recording their HD television shows without renting a DVR from the cable company. CableCard tuners have been mostly absent from the market, making this type of recording difficult or impossible. Now that there’s a proven way to get the encryption key for HDCP how hard would it really be to create a man-in-the-middle device that uses that key to authenticate, decrypt, and funnel the audio and video to another encoder card? We know next-to-nothing about the protocol but why couldn’t any powerful processor, like an ARM, or even an FPGA (both rather inexpensive and readily available) be programmed for this task?

Leave a comment to let us know what you think about HDCP, and what the availability of the master-key really means.

[Thanks Dave]

TV hack bypasses HDCP


Reader [GRitchie] wrote in with an interesting find in his new TV set: with just some minor soldering it was possible to tap into an unencrypted hi-def video stream.

HDCP (High-bandwidth Digital Content Protection), used by Blu-Ray players and cable or satellite receivers, normally ensures a DRM-protected link between the device and a compatible display. Any properly-licensed device that forwards HDCP content (such as an HDMI switch box) is expected to provide encrypted output; those that don’t may get blacklisted by the system and become expensive paperweights. It’s something of an annoyance for users who feel this oversteps fair use applications such as time-shifting.

[GRitchie] found that his new TV with “InstaPort” Fast HDMI Switching didn’t perform this re-encryption step between the set’s internal switcher and the next stage in decoding. Soldering just eight wires directly from the switching chip’s output to an HDMI cable provided an unencrypted output that could then be received by a PC for later replay.

What’s not clear at this point is whether the capability is peculiar to just this one make and model, or applies to anything with the new Fast HDMI Switching. If the latter, it will be interesting to see how this plays out…nearly all of the major HDTV manufacturers are evaluating InstaPort for new sets, which would make any attempt at HDCP blacklisting awkward, to say the least.

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]

Google releases keyCzar

Google has released keyCzar, a cryptographic toolkit that supports encryption and authentication for both symmetric and public-key algorithms.

Cryptography is a common problem area for web programmers. keyCzar aims to help alleviate some of the issues by supplying safe defaults, tagging versions, and a simple interface.

[via Zero Day]

Pirate Bay hits the road, angles for encryption

Piratbyrån and their hearties from The Pirate Bay are on a pan-European summer journey that will end at the Manifesta art biennial in Italy, but in the meantime they’ve been hard at work lobbying for total network encryption, a system that would protect users of a network (say, a P2P network) from deep packet inspection and other forms of activity analysis.

The system by which this will be achieved is called IPETEE, and it works by replacing the basic operating system network stack and doing all encryption and decryption itself. More details can be found in the IPETEE technical proposal.

Ars Technica pointed out numerous holes in the scheme, noting that most torrent apps already have encryption options. IPETEE applies to more than just torrents, though, so the larger problem is that encrypted packet still need source and destination IP addresses, meaning that one of the most crucial things you’d want to keep private (your destination site) is still accessible.