COMSEC: September 2007 Archives


September 23, 2007

Apparently the iPod SHA-1 thingamajig has been reverse engineered. As I said earlier, I'm not convinced that this actually was intended to lock down the iPod. However, it's interesting to ask how one would actually do that in a way that was harder to reverse engineer.

Two goals were ascribed to the alleged SHA-1 in the database:

  • Stop any programs other than iTunes from managing the iPod.
  • Lock the iPod to a specific instance of iTunes.

If all you have is a hammer, everything looks like a nail, and if you're a COMSEC guy, problems like this bring crypto to mind. At a high level, there are two cryptographic strategies for this kind of job: encrypt the database which is then decrypted by the iPod/iTunes or apply an integrity check which is checked by the iPod/iTunes. Each of these have advantages in some contexts, but we can treat them mostly the same for the purposes of our discussion, so without loss of generality, let's talk about an integrity check.

The difficulty, as with most cryptographic contexts, is key management. We want to make sure that only legitimate copies of iTunes can produce databases that the iPod can verify, which means that iTunes has to contain a key that isn't known to third party developers. There are two options here: all copies of iTunes have the same key—this is basically the same as a fixed, secret, integrity check function or one over unknown data, i.e., the situation we have now. Any system of this type is very vulnerable to key extraction via reverse engineering. Once you have the key (or the function) you can write your own program.

The other approach is to use a separate key for each copy of iTunes. When a new iPod is attached to iTunes, it gets a copy of the key (imprinted). The most attractive mechanism here is probably to use public key cryptography and put the public key on the iPod. The key can even be signed by Apple to avoid false imprinting. Then all database updates are signed and the iPod verifies them. Of course, you can still mount a reverse engineering attack and extract the key from a single copy of iTunes, but then we're in an arms race where Apple can program new iPods to ignore that key, thus forcing the third-party software authors to constantly change keys.1

Another strategy for the attacker is not to extract a single key but rather to have the third-party software extract keys from a valid copy of iTunes, though this is obviously this is a bit inconvenient if you don't want to be involved with Apple's software at all.

If this sounds like the kind of issues you have with DRM, it is. And like DRM, the attacker has an enormous advantage as long as your system is software only and he's prepared to reverse engineer it. The situation changes a lot if you are willing to have trusted hardware (in this case on the host computer) but that would be a big change for Apple.

1. If Apple is willing to force people to register online, you can make detection and revocation of extracted keys much more efficient.