Revisiting Android disk encryption
nelenkov.blogspot.com
Revisiting Android disk encryption
1–10 of 35 posts
Re: Revisiting Android disk encryption
#2The dreadful "you must enable Javascript for this plain website" layout strikes again. So here is the summary of the article for the fellow plain HTML lovers:
> Android has included full disk encryption (FDE) support since version 3.0, but versions prior to 4.4 used a fairly easy to bruteforce key derivation function (PBKDF2 with 2000 iterations). Additionally, because the disk encryption password is the same as the lockscreen one, most users tend to use simple PINs or passwords (unless a device administrator enforces password complexity rules), which further facilitates bruteforcing. Android 4.4 replaced the disk encryption KDF with scrypt, which is much harder to crack and cannot be implemented efficiently on off-the-shelf GPU hardware. In addition to enabling FDE out of the box, Android L is expected to include hardware protection for disk encryption keys, as well as hardware acceleration for encrypted disk access. These two features should make FDE on Android both more secure and much faster.
Re: Revisiting Android disk encryption
#3> In iOS 8, Apple has expanded the scope of data encryption and now mixes in the user's passcode when deriving an encryption key, making it harder to extract data from iOS 8 devices.
Not fully correct. In iOS8, the scope of DP (data protection) was enhanced to cover additional data with specific respect to the builtin Apple applications (SMS, photos, call logs, etc.). DP, since its introduction in iOS4, has always used the user's passcode as part of the encryption secret, and there are APIs available to create files and/or keychain items with data protection on.
Notice that there is an interaction between the multitasking/background system and data protection, as applications running background services will need access to a (part of) filesystem and (part of) keychain to operate. This is why the APIs have a very granular set of ACLs.
Re: Revisiting Android disk encryption
#4The dreadful "you must enable Javascript for this plain website" layout strikes again. So here is the summary of the article for the fellow plain HTML lovers: > Android has included full disk encryption (FDE) support since version 3.0, but versions prior to 4.4 used a fairly easy to bruteforce key derivation function (PBKDF2 with 2000 iterations). Additionally, because the disk encryption password is the same as the…
blogspot is really annoying about that. Adding ?m=1 works here: http://nelenkov.blogspot.fr/2014/10/revisiting-android-disk-...
Re: Revisiting Android disk encryption
#5hy tis is tha best
Re: Revisiting Android disk encryption
#6Mʏ ʟᴀsᴛ ᴘᴀʏ ᴄʜᴇᴄᴋ ᴡᴀs $8000 working 9 hours a week online. My younger brother friend has been averaging 12k for months now and he works about 29 hours a week. I ᴄᴀɴᴛ ʙᴇʟɪᴇᴠᴇ ʜᴏᴡ ᴇᴀsʏ ɪᴛ ᴡᴀs ᴏɴᴄᴇ I ᴛʀɪᴇᴅ ɪᴛ ᴏᴜᴛ. Tʜɪs ɪs ᴡʜᴀ I ᴅᴏ,...... www.zeejob.ℂℴm
Re: Revisiting Android disk encryption
#7Obviously, a strong passcode is a must.
But that's a big ask not just for the obvious reason, but also because the Nexus 5 is the first phone I've ever owned which demands that I unlock it first before I can access the UI to cancel an alarm.
And even then, it's a game of chance (especially when the phone is upside down while you're asleep) whether your swipe is in the correct direction (apparently UI designs actually removed the visual cues which would normally guide the user toward the correct action).
Re: Revisiting Android disk encryption
#8hy
Re: Revisiting Android disk encryption
#9Re: Revisiting Android disk encryption
#10The dreadful "you must enable Javascript for this plain website" layout strikes again. So here is the summary of the article for the fellow plain HTML lovers: > Android has included full disk encryption (FDE) support since version 3.0, but versions prior to 4.4 used a fairly easy to bruteforce key derivation function (PBKDF2 with 2000 iterations). Additionally, because the disk encryption password is the same as the…
Thing is, scrypt isn't a panacea - there are ways to make it CPU hard instead of memory hard - http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp...