Right, but even if you did that, wouldn't you still have to store that key somewhere?

Also, hi from downstairs!

1) Assuming a virgin device, applications can't access the DB this stuff is stored in, or other applications' files (if an application wants to safely store stuff on its own, outside of the OS mechanisms), so it's not too big a concern that applications be unable to do this.

2) If you get physical access to the device, you can pull the DB and whatever IDs are involved. Without encryption, this is game over instantly; with encryption, your goal is to delay it as long as humanly possible.

Couldn't you have something like:

key = hash(hardware serial number, user password)

And then store the key only in memory every time the user unlocks the phone and wipe it from memory when they lock their phone?

If you do that, I'd imagine that the phone would not be able to pull updates from those services while the phone is locked.

If you're a registered Apple developer, it's worth watching how they're dealing with this in iOS 5.

Unless it is a dumb protocol, you should be fine. Session IDs FTW.

Damn, good point. I'm out of ideas then. :)

Yep, that's pretty much it. Where 'hash' is PBKDF2 with a good HMAC function and 10k+ rounds.

The correct answer is to use a TPM - Trusted Platform Module - for that key. Accessing the TPM itself requires a password, but the hardware prevents against bruteforce/dictionary attacks.

Does Apple iPhone uses mobile TPM? Any known mobile phone?

The iPhone does not, and I'm not aware of any that do. Even the Blackberry, which is intended for high security of such things, simply uses PBKDF2. However, a TPM is the best solution here.