
Wild Speculation on iPhone 3G S Hardware Encryption - ocskills
http://www.zetetic.net/blog/2009/06/09/wild-speculation-on-iphone-3g-s-hardware-encryption/
======
DenisM
I'm pretty sure they encrypt the entire flash with a random key that is stored
in the first page. When remote wipe request comes in you just need to nuke the
key to destroy data, which is a lot faster than actually overwriting 32Gb of
flash.

iTunes backups are not encrypted by default because you have a key management
issue. The primary purpose of the backup is so that you can restore it to a
different device after your main device is lost or broken. Since devices where
backup is taken and restored are different you can not use built-in key to
encrypt the data. There are only two options where to store the key - with the
backup itself (which is entirely useless) or with the user. Which is exactly
what iTunes does - it allows the user to specify a password that is used to
generate the key.

~~~
billymeltdown
Hi Denis, are you at WWDC? It would be quite rad if someone were to start
prodding the apple folks in sessions with regards to this. Inquiring minds
want to know!

~~~
yan
I'm here. What exactly do you want to know?

~~~
billymeltdown
Hi, Yan, curious if we can get more technical info out of Apple folks about
how their new "hardware encryption" feature for iPhone actually works.

------
ynniv
Wild speculation makes the front page? They probably put in a hardware block
encryptor, which is generally useful for encryption (look up Secure Virtual
Memory in Mac OS X). Yes, it is faster to wipe a block key than to wipe an
entire flash drive, but this post should have ended there instead of
speculating that Apple's engineers don't understand encryption.

If you like wild speculation, it is likely that the block key is large enough
to provide adequate security, and that it is stored locally but encrypted with
a data encryption method like RSA. The password for this might be as simple as
a 4 digit pin, but thats irrelevant because the encrypted encryption key would
be the first data wiped in the event of a data breech. If you're really
paranoid, you could store a larger key on the network. Rebooting the device
would then require network access, but it protects you against someone
removing your compact flash and reading it directly.

Obviously backup files are not encrypted, or they wouldn't be very useful. If
they are encrypted, it will only be as strong as the user specified password,
or key stored on MobileMe.

~~~
ocskills
This comment extends further into the realm of speculation than the original
post. The article doesn't even mention Apple's understanding of encryption,
let alone specifics like algorithms and key sizes.

The post only speculates about the meaning of Apple's carefully worded feature
description, the _scope_ of the device encryption, and whether it's _primary
intent_ is to enable the remote wipe feature.

With regard to four digit pins - the strength and length of a password is
hardly immaterial to security if it is being used to derive or encrypt the
key. This is especially true if the wipe needs to be triggered remotely.
Storage of the key on the network or MobileMe would present a host of other
issues that I suspect Apple would want to stay away from.

~~~
ynniv
Yes, it is more speculative, but I have lower standards for HN comments than
HN submissions.

The article doesn't mention Apple's understanding of encryption, but it seemed
to speculate that this encryption wouldn't be "real" encryption: "is it really
securing the device while running".

As for the length of the pin, it isn't as important as you think. Assuming the
attacker doesn't read the compact flash directly (there is very little you can
do at that point), you can store a strong encryption key on disk and protect
the device via an exponentially increasing lockout. If the key were also
stored in iTunes, you can always wipe the key from disk and require the phone
be re-sync'd.

Anyway, my point is that the original article is lame.

