Live data from Hacker News

Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

bits-please.blogspot.com

51–60 of 99 posts

Re: Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

#51
post #49

Earlier quoted context omitted.

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.

Re: Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

#52
So out of curiosity, as someone who has a nontrivial passcode on his Android device that people constantly mock, how many characters are we talking to be safe.

I have known for a long time 4 digit numeric PINs are stupid. Sadly the San Bernadino case, for all the wrong reasons, taught me all the alternative auth methods are just as risky.

Should I be worried? I don't know. But as a long time Android enthusiast and power user who does not use Google Play on his phone and restrictive permission customization like XPrivacy, I am about to just give up and have a newish iPhone for secure stuff and knock around Android for the cool open source dev I aspire to with F-Droid.

Re: Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

#53
post #44

Earlier quoted context omitted.

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.

For what it's worth, the "optimizing apps" thing is going away in Android N. https://developer.android.com/preview/api-overview.html#jit_...

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

Re: Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

#54
post #2

Since the security of Android depends on hardware and OEM software not under Google's control, depending on FDE is apparently pointless. I guarantee Google really wants to build their own branded phones with their own secure Android version and gain Apple's advantages in building secure systems because you own everything.

> Since the security of Android depends on hardware and OEM software not under Google's control, depending on FDE is apparently pointless. For 99% of the users, this is complete nonsense. Why do we encrypt the phone? Are we afraid of the NSA or whatever agency cracking our phones? No! The reason most of us encrypt the phone is to prevent others from posting our pictures or reading our mail. When somebody else finds m…

It runs the 2-factor app that secures my online accounts, which may or may not include banking.

Re: Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

#55
post #3

Would love to see the same analysis on Samsung hardware

I'll definitely try and get around to it sometime soon. However, I wouldn't be surprised if the situation is the same... After all, the KeyMaster module was initially only meant to keep encryption keys on the device, not to safeguard FDE.

Sorry for an extremely nooby question, but your comment makes me wonder:

Are Snapdragon and Exynos architectures that alike? I mean, do you have any preliminary idea how easy it would be to apply your Snapdragon method to an Exynos SoC?

Re: Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

#56
post #49

Earlier quoted context omitted.

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

Re: Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

#57
post #45
post #43

Earlier quoted context omitted.

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!

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.

Re: Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

#58
post #35

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

Wait, Android doesn't use LUKS? Argh. Just give me a stinkin' smartphone that runs Linux. These are solved problems, people.

Jolla / Sailfish ?

Re: Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

#59
post #35

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

Wait, Android doesn't use LUKS? Argh. Just give me a stinkin' smartphone that runs Linux. These are solved problems, people.

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?

Re: Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption

#60
post #35

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

Wait, Android doesn't use LUKS? Argh. Just give me a stinkin' smartphone that runs Linux. These are solved problems, people.

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