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

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

bits-please.blogspot.com

Post reply on HN
Print view View original

61–70 of 99 posts

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

#61

Post by modeless »

kyrra wrote: post #44
Dylan16807 wrote: post #40

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

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

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

#62

Post by superuser2 »

Dylan16807 wrote: post #40
koolba wrote: 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.

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.

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

#63

Post by Dylan16807 »

superuser2 wrote: post #62
Dylan16807 wrote: post #40

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.

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.

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

#64

Post by nickik »

I would use a longer password. But currently the unlock and the encryption password are always the same. That one of the issue I would like to see changed.

I would also like to have more fine grained rules on when I can unlock with a fingerprint, when pin and when I should be forced to put in the encryption password.

Additionally I would like to use U2F NFC token on my keychain as a second factor for unlock (if I have not touched the phone for X amount of time).

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

#65

Post by dlitz »

koolba wrote: 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…

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.

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

#66

Post by superuser2 »

Dylan16807 wrote: post #63
superuser2 wrote: post #62

Earlier quoted context omitted.

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?

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

#67

Post by Dylan16807 »

superuser2 wrote: post #66
Dylan16807 wrote: post #63

Earlier quoted context omitted.

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.

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

#68

Post by hiermtt »

koolba wrote: 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…

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

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

#69

Post by wyldfire »

Pxtl wrote: post #57
koolba wrote: 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!

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.

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

#70

Post by mjevans »

haikuginger wrote: post #53
kyrra wrote: post #44

Earlier quoted context omitted.

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.

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

Post reply on HN