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.
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!
Because such design is the first thing that comes to mind when I read apple's wording of "iPhone 3G S offers highly secure hardware encryption that enables instantaneous remote wipe.".
So such design would work and is simple enough, hence "pretty sure".
I wasn't getting snippy with you, dude. I was really wondering if you knew something we didn't beyond speculation. My comrade Stephen (author of article above) suggested pretty much the same thing.
I didn't find it snippy either. Basically my position is "if it looks like a common sense thing to do that's probably what it is, unless there is a big reason to dig deeper into it".
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.
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.
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.
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.