Revisiting Android disk encryption • Hacker News Board

Re: Revisiting Android disk encryption

#21

Post by dvhh » Mon, Oct 06, 2014, 2:47 PM UTC

higherpurpose wrote: post #19

JshWright wrote: post #16

Earlier quoted context omitted.

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

TouchId does not replace the password, it is merely a shortcut for it, as far as the current implementation goes.

Re: Revisiting Android disk encryption

#22

Post by zxcvgm » Mon, Oct 06, 2014, 2:48 PM UTC

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

[2] https://www.apple.com/privacy/docs/iOS_Security_Guide_Sept_2...

Re: Revisiting Android disk encryption

#23

Post by JshWright » Mon, Oct 06, 2014, 3:06 PM UTC

ancientworldnow wrote: post #20

JshWright wrote: post #16

Earlier quoted context omitted.

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

> It requires root

And there's the problem... I'm trading one security improvement for a whole host of other issues...

Re: Revisiting Android disk encryption

#24

Post by jonknee » Mon, Oct 06, 2014, 3:08 PM UTC

higherpurpose wrote: post #19

JshWright wrote: post #16

Earlier quoted context omitted.

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

Touch ID still requires you to type in your password after you boot the phone. Still quite handy, but not a password replacement by any means.

Re: Revisiting Android disk encryption

#25

Post by jareds » Mon, Oct 06, 2014, 3:26 PM UTC

higherpurpose wrote: post #18

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.

I can enter a normal pin or password if the device is encrypted since the operating system is completely loaded and along with that Talkback is. It's the boot password I can not enter because not enough of the operating system is loaded for Talkback to speak.

Re: Revisiting Android disk encryption

#26

Post by icebraining » Mon, Oct 06, 2014, 4:12 PM UTC

JshWright wrote: post #23

ancientworldnow wrote: post #20

Earlier quoted context omitted.

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

> It requires root And there's the problem... I'm trading one security improvement for a whole host of other issues...

Which issues?

Re: Revisiting Android disk encryption

#27

Post by mbq » Mon, Oct 06, 2014, 4:29 PM UTC

zxcvgm wrote: post #22

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…

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

Re: Revisiting Android disk encryption

#28

Post by ancientworldnow » Mon, Oct 06, 2014, 4:54 PM UTC

JshWright wrote: post #23

ancientworldnow wrote: post #20

Earlier quoted context omitted.

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

> It requires root And there's the problem... I'm trading one security improvement for a whole host of other issues...

That's a valid concern, though you can root, install and run the app, and then unroot. It's not a good solution, but it is a solution until Android L builds in the ability to use different passwords.

Re: Revisiting Android disk encryption

#29

Post by mentat » Mon, Oct 06, 2014, 7:31 PM UTC

If you don't have a hardware bound key as part of the KDF then you will be subject to extraction and parallel breaking. It may take more computing power with scrypt but it will be doable. KDFs enforce round constraints relative to the hardware they run on. Being able to extract from that hardware means being able to apply orders of magnitude greater processing and parallelization of that process. Hardware keys like Apple's are the only way to go.

Re: Revisiting Android disk encryption

#30

Post by csirac2 » Mon, Oct 06, 2014, 9:18 PM UTC

wtbob wrote: post #14

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

Not all the time, I must admit - but when I'm blindly poking my phone or it's just grabbed out of my pocket, some part of the screen (that for me is the most likely part) makes the swipe prompt disappear and is replaced with the passcode entry.

Given that I have my N5 in a case, perhaps it's an inadvertent button press. Still, the UI should always provide swipe access to disable an alarm while the device is blaring at me.