7 ms·
Coming from iOS, one thing that I didn't really like about Android was how clumsy the decryption process was. The process is detailed here [1] and it involves t
by zxcvgm 12y ago
Coming from iOS, one thing that I didn't really like about Android was how clumsy the decryption process was. The process is detailed here [1] and it involves the framework being put in a special mode that only handles password entry. In this mode, none of the regular services are running, so I'm not sure how incoming calls & SMSes are handled (or if they are even handled). It's like getting stuck at the boot screen with a password prompt.
In iOS, encryption is not performed at the block layer but at the filesystem level, and some files are encrypted with hardware-derived keys (thanks to a unique 256-bit AES key burned into the processor), allowing the OS to be booted normally, but not having access to certain files until the user enters his/her passcode (full details here [2]). Even if you don't immediately enter the passcode after boot, the phone is still in a somewhat functional state.
I'm glad that Android is taking steps to at least implement by-default disk encryption by relying on a hardware-backed key store.
[1] https://source.android.com/devices/tech/encryption/android_crypto_implementation.html https://source.android.com/devices/tech/encryption/android_c...
[2] https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2014.pdf https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2...
- mbq 12y agoOn the other hand, the more system is loaded without user input the greater chance that it can be exploited; also filesystem-level encryption leaks some meta information.