Live data from Hacker News

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

bits-please.blogspot.com

41–50 of 99 posts

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

#41
post #16

It doesn't really break the encryption, as long as the password is strong enough to prevent brute forcing. Relying on a weak password and a "trusted computing" mechanism like this one from Qualcomm to prevent an attacker with physical access from brute forcing it is not really advisable. Using such a mechanism at all has downsides since it means that you lose the data if the mechanism or the entire device stops worki…

Precisely - if you're relying on no one to be able to reverse engineering the "secure enclave", you're already in deep trouble.

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

#42

Unfortunately, it seems as though fixing the issue is not simple, and might require hardware changes. So any Android phone currently on the market is basically unfixable?

Just don't use a password so weak it can be bruted for your FDE and you're fine. Treat it like most existing software-only solutions like TrueCrypt, not like a magic black box that can make a 4 digit number into a secure password. Even if the hardware were "secure" it still wouldn't be advisable to rely on it as a successful reverse engineering of the hardware could still result in a bruteforce attack on your key. And while that may be high effort and expensive, it's certainly not impossible. Never trust a half measure, this sort of TPM/Secure Enclave approach is a half measure.

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

#43
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…

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.

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

#44
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…

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

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

#45
post #43

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.

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!

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

#46
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_...

Only for new devices that support it

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

#47
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!

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

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

#48
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…

Businesses typically have rules about securing data, that covers a lot of users.

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

#49
post #45

Earlier quoted context omitted.

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.

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

#50
post #23

Earlier quoted context omitted.

But how many Android users do you know that actually have a strong password? (Speaking of which: Google's decision to not allow strong encryption passwords together with short screen unlock PINs/patterns is not helping here. It's actually possible, but they don't expose the user interface to change them separately, probably for usability reasons.) Also, while I would agree as far as PCs are concerned, moving the eMMC…

moving the eMMC to a new phone's mainboard is probably also not a likely scenario. Data recovery is, however, which is why I don't think one-sided promotion of ubiquitous hardware-locked-FDE is a good idea --- it becomes a tradeoff between others getting access to, and you losing access to, your data. Is it more important that this data be accessible by no one but you even if it means you might also lose access to it…

As someone who deals with hardware-backed encryption in laptops, it's a huge pain.

Modern phones are worse. I was at a training and happened to sit with computer forensicators and they complain about the new eMMC systems. Forensics systems for mobile devices were a piece of cake prior to that.

I suspect the eMMC thing is meant to make this difficult on purpose.

So, so much for that ...

Post reply on HN