Hacker News Reader

Comment by koolba | Hacker News Reader

Full disk encryption (FDE) is a UX issue, not a technical one. You don't need a secure cryptographic processor, but the UX sucks without one.

A simple, working, FDE setup would be something like LUKS running at boot:

    1. Turn on phone
    2. Phone loads up initial bootstrap OS
    3. Phone prompts user for master key
    4. Master key is used to unlock volume
    5. Regular OS boot continues

If the master key has enough entropy, brute forcing it becomes impossible. The phone won't "disable" as there's no self-destructing component (i.e. "secure crypto chip") but that doesn't mean it can be cracked. Boil as many oceans as you'd like, you're not going to brute force 256 bits of entropy.

The UX problem is that the master key is a PITA to enter if it's long enough to be cryptographically secure. That's what a crypto chip is supposed to solve. A limited number of attempts with a shorter passphrase.

View on HN

On the other hand, phones do not need to be rebooted often. And if I'm upgrading my OS the stupid thing is going to make me wait 20 minutes while it precompiles every app, so screw it I don't care if I have to spend 40 seconds inputting a password.

Right, but it may reboot at the most inopportune moments, like after the battery runs out, and where you may not have access to the 20 character long master password which is impossible to remember.

How about a QR code on a business card kept in your wallet? Scan the QR code (with you phone's camera) to input the long passphrase (or even better just random bits).

There could still be a short pin/passphrase in addition to that. Keepass allows for something similar by having a local file + passphrase to unlock a password vault.

Backups of the QR code could be as easy as photocopying it!

If you're putting it in your wallet, just use plaintext.

> If you're putting it in your wallet, just use plaintext.

That has the same issue of not being able to input it into the phone. The QR code can be easily scanned.

Sure OCR of plain text is possible but some more standardized like a QR Code would be better.

I'd rather just type than fuss with getting a QR code to scan in possibly-bad lighting. I just tested a password of 30 random lowercase letters, which is total overkill for security, and it took less than 30 seconds to type into my phone. Doing that perhaps once a month, or once you find a charger after your battery dies, is no problem.

> I'd rather just type than fuss with getting a QR code to scan in possibly-bad lighting.

Nothing says you can't do either, or even both[1]. The idea of using a QR Code is so that mom/dad/grandpa/grandma can use a long password to unlock their phone without having to type it in.

Bonus points if the QR Code itself is in the shape of a key!

[1]: Which would be "something you have" + "something you know".

A ring or bracelet with an NFC tag in it. Well, a ring is probably too small for a proper NFC tag, but either way: NFC jewellery.

They absolutely make rings w/NFC tags. At least men's rings, I assume they may do it for women's too.

Neat. Does android support NFC for the bootup FDE decrypt?

I doubt it. But you might not prefer it to, depending on the threats you want to secure against. If you had extremely valuable secrets, someone could just execute you and use your NFC jewelry to unlock those secrets.

Or rip off your fingers if you use your fingerprints to unlock, or just drug you with scopolamine to unlock it.

I'm looking for normal corporate security here, not fighting the KGB.

Really? That is something I dreamed about for a long time. A small object on the finger is the least obstructive form factor and becomes part of self. But unlike a fingerprint, a ring can be replaced if somehow compromised.

e.g. http://amzn.com/B00UTEHH8K claims "Lock and Unlock Your Smart Phone or Tablet Quickly, Hide the App When You Leave Your Smart Phone Alone"

Use Diceware and you will have no problem remembering a secure passphrase.

https://en.wikipedia.org/wiki/Diceware

For what it's worth, the "optimizing apps" thing is going away in Android N.

https://developer.android.com/preview/api-overview.html#jit_...

Only for new devices that support it

I do find it somewhat amusing that Android went from Dalvik precompiled to Dalvik JIT, to ART precompiled, to ART JIT.

It's actually a rather logical set of steps, it follows the same pattern as elsewhere probably for the same underlying reasons.

Compiled once is easier to develop, prove correct and validate functionality. Just in time offers convenience in deferring compilation, but increases storage requirements and can decrease the initial runtime performance due to compiling the code. If you have spare cores this starts to make more sense. If you have a mechanism of profiling and automatically tuning the optimization of frequently used codepaths / infrequently used ones then JIT also starts to have payoffs (this is where human hours making a smarter compiler pay off across many applications that don't warrant the human hours optimizing directly).

Another interesting aspect of the evolution of the Dalvik and ART runtimes is that they are runtimes for (mostly) battery-powered devices. A JIT compiler was an obvious next step but less obvious is that it had to be battery conscious. It was designed to JIT as little code as possible to attain the greatest gain in performance as possible. That's not how you would design a JIT compiler for server Java!

Dalvik interpreted was the first step. You could sort of call it "precompiled" if you call dex a precompiler.

Also, the system update install process will happen while the phone is in use, and only require a reboot after installation is finished. The whole process will be much faster.

Not only that, but Android N will be able to boot all the way to the lock screen before asking for the password, and even support functionality like phone calls, limited notifications, or alarms (so if your phone reboots in the night you'll still get woken up in the morning).

Phones spend most of their lives powered on. You need to be required to enter a similarly good password to unlock it while the phone is running, or disk encryption has accomplished nothing at all.

Not true at all. Any attack against the encrypted data itself will be stopped. Any attack that requires restarting the phone to load different software will be stopped. Having a secure boot password and also a software-enforced pin to unlock accomplishes a great deal. And as a bonus, when a security measure is not grossly inconvenient you get more people using it.

The key is in memory. How many attackers are prepared to read the flash chip but not the RAM?

In theory it should be easy to keep the key from leaving the CPU's cache.

Sometimes collection agencies rotate their phone numbers when they call you so you can't block them, the only way to turn off the phone.

You could turn off notifications, or use airplane mode.

The other UX problem is you need to make sure that someone doesn't replace the initial bootstrap OS with something else that captures the master key.

So, that's where you need the secure cryptographic processor and the trusted environment, etc.

Wait, Android doesn't use LUKS?

Argh. Just give me a stinkin' smartphone that runs Linux. These are solved problems, people.

Jolla / Sailfish ?

Last I checked, it does. I'm pretty sure for instance the Nexus 5X relies on standard LUKS for FDE.

What may be protected through other means is the key used to encrypt that filesystem. The user enters a pin or a pattern to unlock said key on boot, and that key is used to initiate LUKS.

Maybe that's what they have cracked here?

Isn't Android running a really old Linux because they can't rebase? So they have to cherry pick... or has that stopped now?

No, but they tend to stick to the LTS releases and the kernel tends to not get a version update for the life of the device.

So it doesn't track the latest, but it's also not "really old" in that upstream Linux still considers it a supported version.

No it's actually very old. This is from my Nexus 5X, running Android N preview build:

    $ uname -a
    Linux localhost 3.10.73-gef93fe9 #1 SMP PREEMPT Fri May 20 20:48:13 UTC 2016 aarch64 Android

There was a technical reason for pinning it at this version (also known the "Android kernel"), but I don't remember what that specific reason was.

You also want the passphrase to be easily changed, separately from the master key (because changing the master key is slow and resource-intensive).

Even if you have a strong passphrase, there's some probability of leaking some number of bits of it via side-channels every time it's entered (e.g. surveillance cameras, fingerprints on the screen, shoulder surfing, vulnerable code, TEMPEST, etc). Plus, people often keep a backup copy of their passphrases (unique, strong passphrases are hard to remember), so there's also a cumulative risk of the backup leaking over time, as well.

Long-term confidentiality is just surprisingly hard in the real world.

>Full disk encryption (FDE) is a UX issue, not a technical one.

Most of the secutity is pretty much a UX issue. Otherwise century-old one-time pad would fit all.

And with a crypto chip it's much easier to share the device. Think of family or classroom/work devices.

QR code maybe? I think that might work...

Reply on news.ycombinator.com