
Extracting Qualcomm's KeyMaster Keys – Breaking Android Full Disk Encryption - laginimaineb
https://bits-please.blogspot.com/2016/06/extracting-qualcomms-keymaster-keys.html
======
koolba
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.

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

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

[https://developer.android.com/preview/api-
overview.html#jit_...](https://developer.android.com/preview/api-
overview.html#jit_aot)

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

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

~~~
Zigurd
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!

------
sdl
So if I understood correctly, there are 5 requirements for such a system to be
secure:

    
    
      1: secure/unmodifiable cryptographic processor
      2: with unremovable rate limiting
      3: and exclusive access to a hardware key
      
      4: cryptographic processor has the only function of encrypting user data based on
      5: hardware key and a user supplied pin/key
    

Errors done by Qualcomm:

    
    
      Violated 3: Hardware key not exclusivly readable by cryptographic processor
      Violated 5: Encryption based on derived key
    

Anything I overlooked?

(edited: formatting)

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

~~~
arviewer
> 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 my phone, or steals it, the four digit PIN is enough
protection. Then again, I don't use a four digit PIN, but something longer,
and from six or up it's really strong enough for manual unlocking.

People who have the means to read contents from the memory chips, they
probably have the means to use other measures to get what they want.

~~~
nitrogen
There are levels of threat and protection between those you mentioned. As the
threat from people with access to "other measures" increases, you moght at
least want to make them work for it and have to go through proper channels.

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

~~~
snassar
A friend saw me entering my longish, non-trivial passphrase into my android
phone and commented that I must not have many friends if I have to enter this
passphrase every time to use my phone.

For a moment I was torn between being proud in my passphrase and sad at my
lack of friends.

~~~
gcr
You bring up an interesting UX issue.

If I need to be constantly available to my friends, "number of seconds to a
text reply" is something that I need to minimize.

Longer passphrases prevent me from sending quick replies.

~~~
616c
Some of my more sophisticated friends take this a step further and taunt me
for not securely hiding notifications and buying a smart watch.

This confuses me because Bluetooth over the air does not strike me a secure
mechanism (is it just Bluetooth; ironically scant detail unless my Google-fu
is off, likely at this hour for me).

[http://www.wareable.com/android-wear/android-wear-hack-
alert...](http://www.wareable.com/android-wear/android-wear-hack-alert-
signalled-by-security-expert-581)

And do I need yet another smart device? The mobile first movement, with
shinier crap, moving away from standard protocols, leads me to believe I have
been passively perpetuating the biggest wart on computer science's labors. I
am kind of embarassed, a few years in and late to the party, I bought an
Android phone at all.

------
devit
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 working, while otherwise you
could simply move the SSD/flash/storage unit to a new identical device and
have it just work as long as you type the correct password.

~~~
lxgr
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 to a
new phone's mainboard is probably also not a likely scenario.

~~~
userbinator
_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, or that you not lose access, even if it
means others can access it? Hardware-locked FDE is suited only to the former
case.

~~~
616c
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 ...

------
bognition
Fascinating article, the more I learn about crypto and security the more
obvious it becomes how hard this stuff is to get right.

~~~
zeveb
You know, I'm not really all that certain that it's intellectually difficult
to get crypto right; it feels more likely that it's organisationally and
process-wise difficult to get crypto right.

What I mean is that folks want to take an existing product and layer crypto
atop it, when really they need to start from the crypto and built a product
over it. They want to do things which are mathematically impossible (e.g. let
you read data, but not let you say that data to someone else). They want to
hand the crypto to a junior developer instead of someone who knows what he's
doing.

Crypto's not hard to do; organisations are bad at doing crypto.

~~~
LoSboccacc
spot on with one minor nitpick: crypto is not hard to _use_ (as in, relying on
existing libraries/standards/practices) - doing, as in writing your own
crypto, otoh...

~~~
brainbrane
Crypto is indeed hard to use.

[https://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10...](https://www.nds.rub.de/media/nds/veroeffentlichungen/2011/10/22/HowToBreakXMLenc.pdf)

[https://en.wikipedia.org/wiki/CRIME](https://en.wikipedia.org/wiki/CRIME)

------
AdmiralAsshat
_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?

~~~
laginimaineb
I believe so.

~~~
jhallenworld
Well hold on.. there are several issues. One is that there is an exploit
allowing arbitrary code execution in the trustzone. This immediate problem
should be fixed.

The second is that allowing a firmware updates to trustzone code means that
Google could push an update which allows them to retrieve keys. Such updates
should only be allowed if the user accepts them. How the user is supposed to
know the difference between a security fix vs. Google trying to break into
their phone is the real issue.

But IOS has this same issue. If you accept a firmware update from Apple, maybe
it includes a pin logger.

~~~
laginimaineb
You're right. Let's take a second to go over the issues:

1\. The arbitrary code-execution in TZ has already been privately disclosed
and fixed.

2\. As for the second issue - I would argue that it's not an issue at all. TZ
should be updated (otherwise how would they fix the TZ code-exec
vulnerabilities?).

However, in this case gaining code execution in the TZ kernel directly leads
to the disclosure of the keys which are meant to bind the KDF to your device.
This is in direct contract with Apple's KDF. The key here is that software
shouldn't be trusted, by design.

3\. As for the last issue, I would argue that this is just a clever form of
social-engineering. After all, who's to say they didn't just swap the phone
with a dummy phone to make you insert the correct password?

However, in Android's case, you _wouldn 't even need to cooperate_. OEMs could
simply flash the new TZ code, extract the KeyMaster keys, and bruteforce the
key. All without having any help from you.

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

~~~
ysleepy
You can make it use long FDE passwords and a pattern by hackery. Some sqlite
fiddling necessary. See XDA.

------
arrty88
Would love to see the same analysis on Samsung hardware

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

~~~
pdimitar
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?

~~~
laginimaineb
Actually, I would imagine they are nothing like one another.

However, Exynos uses a TrustZone TEE implementation to implement the KeyMaster
module, just like Qualcomm's Snapdragon. This means that unless that TEE
implementation uses a hardware key which is not software accessible, the same
issue would be present. Of course, reverse-engineering a new TEE
implementation would take a long time... But it sounds like it could be fun.

~~~
pdimitar
Thank you.

You should be aware that people like you are unsung heroes and I'd like you to
know that many of us who are busy struggling to stay afloat are feeling better
knowing that people like you are doing the work you do.

Have that in mind. I wish you well.

------
woumn
If anyone is interested when the author talked about an overview of the iOS
security measures, I created a more in-depth review that is an easy read and
gives you a good over-view of the security architecture used. I'm happy to
hear feedback if you enjoy it. The blog can be found at:
[https://woumn.wordpress.com/2016/05/02/security-
principles-i...](https://woumn.wordpress.com/2016/05/02/security-principles-
in-ios-architecture/)

------
ysleepy
If your device is rooted, you can use a long password for encryption and a
pattern or even no lock for the lockscreen.

I have set it up this way, it needed some sqlite hackery. XDA dev has
appropriate infos.

------
pooze
Could someone explain how and why it uses "0x1337" in order to validate the
key?

Is that magic?

[https://github.com/laginimaineb/android_fde_bruteforce/blob/...](https://github.com/laginimaineb/android_fde_bruteforce/blob/master/keymaster_mod.py#L43)

~~~
rimantas
Isn't that just m = (m^e mod n)^d mod n? So the value itself does not matter,
you could use 42 instead of 0x1337.

------
dcdevito
[https://www.appmobi.com](https://www.appmobi.com)

the only way to fly

