5 ms·
Right, but even if you did that, wouldn't you still have to store that key somewhere? Also, hi from downstairs!
by markbao 15y ago
Right, but even if you did that, wouldn't you still have to store that key somewhere?
Also, hi from downstairs!
- daeken 15y ago1) 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.
- deleted 15y ago[deleted]
- FaceKicker 15y agoCouldn'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?
- daeken 15y agoYep, that's pretty much it. Where 'hash' is PBKDF2 with a good HMAC function and 10k+ rounds.
- ENOTTY 15y agoIf you do that, I'd imagine that the phone would not be able to pull updates from those services while the phone is locked.
- FaceKicker 15y agoDamn, good point. I'm out of ideas then. :)
- IgorPartola 15y agoUnless it is a dumb protocol, you should be fine. Session IDs FTW.
- mentat 15y agoIf you're a registered Apple developer, it's worth watching how they're dealing with this in iOS 5.
- walexander 15y agoThe 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.