Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Revisiting Android disk encryption

nelenkov.blogspot.com

Post reply on HN
Print view View original

11–20 of 35 posts

Re: Revisiting Android disk encryption

#11

Post by kabdib »

Hadn't internalized how essentially trivial it was to brute-force a PIN once you'd copied off the file system blocks.

With Android-L moving key material to trusted execution environments, expect interesting attacks on those. I am curious about state-mandated security holes in TEEs as well, since it's much easier to hide backdoors in chips than in publically reviewable software (I would much prefer to see a dedicated security processor than a "secure mode" of what is essentially the whole SOC).

Re: Revisiting Android disk encryption

#12

Post by kaoD »

philjohn wrote: post #10
aw3c2 wrote: post #2

The 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...

Your link repeats again and again (and again) that his criticisms only apply to password storage. In his own words "as a Key Derivation Function, it is still very much useful and secure".

As GP said, Android uses it as a disk encryption KDF.

Re: Revisiting Android disk encryption

#13

Post by jareds »

I wonder if full disk encryption by default will render Android unusable to blind people such as my self? When I encrypted my Nexus 7 2012 running 4.4 it turns out that you are prompted to enter your password before the talkback screen reader starts talking. Needless to say this is a major issue and no one from Google appears to be interested in fixing it as far as I can tell. With my iPhone Voiceover comes up talking and allows me to enter my password while still having the device encrypted.

Re: Revisiting Android disk encryption

#14

Post by wtbob »

csirac2 wrote: post #7

Obviously, 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…

> 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.

Do you mean a firing alarm, or a pending alarm? One can cancel a firing alarm just by swiping, no passcode needed.

I would prefer to have to enter my code in order to cancel a pending alarm. Otherwise I can imagine practical jokers cancelling an alarm if they have the chance.

Re: Revisiting Android disk encryption

#15

Post by TheLoneWolfling »

aw3c2 wrote: post #2

The 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…

Thank you.

Re: Revisiting Android disk encryption

#16

Post by JshWright »

csirac2 wrote: post #7

Obviously, 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…

I wish it was easier to decouple the passphrase for the key and the passcode to unlock the device...

They have _very_ different security properties. Offline brute forcing the unlock passcode is far harder (presumably it's stored in the encrypted fs), so a shorter code is fine. Offline brute forcing of the encryption key passphrase is much easier (as TFA explains), but I'm never going to use a 'good' passphrase there, as it would be far too annoying to have to type it every time I unlock the phone...

Re: Revisiting Android disk encryption

#17

Post by mbq »

csirac2 wrote: post #7

Obviously, 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…

That is a very good feature because forcing user to perform mentally demanding operation to dismiss the alarm decreases the risk of falling back to sleep (;

Re: Revisiting Android disk encryption

#18

Post by higherpurpose »

jareds wrote: post #13

I wonder if full disk encryption by default will render Android unusable to blind people such as my self? When I encrypted my Nexus 7 2012 running 4.4 it turns out that you are prompted to enter your password before the talkback screen reader starts talking. Needless to say this is a major issue and no one from Google appears to be interested in fixing it as far as I can tell. With my iPhone Voiceover comes up talkin…

The article seems to say that it won't require a password unlock again, after the boot one.

Re: Revisiting Android disk encryption

#19

Post by higherpurpose »

JshWright wrote: post #16
csirac2 wrote: post #7

Obviously, 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…

I wish it was easier to decouple the passphrase for the key and the passcode to unlock the device... They have _very_ different security properties. Offline brute forcing the unlock passcode is far harder (presumably it's stored in the encrypted fs), so a shorter code is fine. Offline brute forcing of the encryption key passphrase is much easier (as TFA explains), but I'm never going to use a 'good' passphrase there,…

Google needs to solve that part of the problem. Apple has already solved it with TouchID.

Google needs to do the same and mandate all OEMs must certify for fingerprint scanning technology (that has a high-standard of accuracy and security, not the gimmicks HTC and Samsung have tried before), or at least incorporate the same kind of technology Nymi uses in all Android Wear watches, so you can unlock the phones with that. Google should either acquire or replicate what these guys are doing:

http://www.getnymi.com/

Re: Revisiting Android disk encryption

#20

Post by ancientworldnow »

JshWright wrote: post #16
csirac2 wrote: post #7

Obviously, 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…

I wish it was easier to decouple the passphrase for the key and the passcode to unlock the device... They have _very_ different security properties. Offline brute forcing the unlock passcode is far harder (presumably it's stored in the encrypted fs), so a shorter code is fine. Offline brute forcing of the encryption key passphrase is much easier (as TFA explains), but I'm never going to use a 'good' passphrase there,…

It requires root, but Cryptfs (available in the play store and f-droid) enables just such a feature. In fact, it's written by this blog post's author.

http://nelenkov.blogspot.com/2012/08/changing-androids-disk-...

https://play.google.com/store/apps/details?id=org.nick.crypt...

Post reply on HN