
The limitations of Android N Encryption - razer6
https://blog.cryptographyengineering.com/2016/11/24/android-n-encryption/
======
tytso
So I only worked on the ext4 encryption feature in the Linux kernel which was
used to implement Android FBE, and so I'm not an expert on vold, but there
shouldn't be a reason why vold needs to hang on to the key. Vold is
responsible for pushing the keys into the kernel, but what ext4 uses to do the
per-file encryption is stored on a kernel keyring, _not_ in userspace. So vold
should be destroying the key after it loads it into memory --- it certainly
can't use the key for anything useful.

As far as being able to remove the keys while the phone is locked --- I can't
comment on future product directions, but it's fair to say that the people
working on the upper layers of the Android security system aren't idiots, and
the limitations of what was landed in the Android N release was known to them.
It is no worse than what we had in older versions of Android (with FDE, we
were using dm-crypt, and the keys were living in the kernel as well), and
while it doesn't help improve security with respect to the "evil maid" attack,
it does significantly improve the user experience.

I agree that there is certainly room to improve, and note that future changes
will require applications to make changes in how they access files, which does
make it a much trickier change to introduce into the ecosystem without
breaking backwards compatibility with existing applications.

As far as why different keys are being used for different profiles --- this
makes it much easier to securely remove a corporate, "work" profile from a
phone without needing to do a secure erase on the entire flash device ---
either because an employee is leaving their existing employer and there is
corp data on a BYOD phone/tablet, or because the phone has been lost, and
corporate security policy about how quickly corp data should be zapped from
the phone might be different from what the user might want to exercise when
they have temporarily misplaced the phone. (e.g., you might have a different
tradeoff of losing unbacked-up data from your personal files versus their
getting compromised while you hope that someone turns in your phone to
lost+found than your company's security policies might require.)

~~~
tytso
Actually, that should be "cold boot" attack, not "evil maid" attack.

------
LeanderK
I know that apple did a lot of controversial moves in the past years, but i
still get the impression that apple takes privacy seriously and tries to
respect it even when there is the fundamental need for data collection [1].

[1] [https://backchannel.com/an-exclusive-look-at-how-ai-and-
mach...](https://backchannel.com/an-exclusive-look-at-how-ai-and-machine-
learning-work-at-apple-8dbfb131932b#.ckhw18y71)

~~~
matt_wulfeck
Absolutely, and the commitment to security and privacy keeps me coming back to
iOS. The iOS white paper[0] is an excellent read for anyone interested in
security. Unlike android devies, iOS security is coupled to hardware HSM chips
which Apple refers to the secure enclave. It's used not just to encrypt and
decrypt, but to verify the entire boot process and all binaries used by the
cellular chips.

Now that google is manufacturing devices I expect them to begin following
Apple's example. Avoid garbage like TrustZone and do it right.

1\.
[https://www.apple.com/business/docs/iOS_Security_Guide.pdf](https://www.apple.com/business/docs/iOS_Security_Guide.pdf)

~~~
izacus
"Garbage"? Can you explain why?

~~~
tveita
The "trustlets" that run in the TrustZone have enhanced privileges and must be
securely written. Once crap like DRM ends up in there, as it invariably does,
it turns actively harmful.

[http://bits-please.blogspot.com/2016/05/qsee-privilege-escal...](http://bits-
please.blogspot.com/2016/05/qsee-privilege-escalation-vulnerability.html)

~~~
twr
It should be mentioned that Matthew Green linked the above blog entry in the
article, so if you didn't read either post, you should.

------
arkadiyt
For a really in-depth dive about the iOS class keys system he mentions I
recommend this 2016 blackhat talk by Ivan Krstic (head of security at Apple):
[https://www.youtube.com/watch?v=BLGFriOKz6U](https://www.youtube.com/watch?v=BLGFriOKz6U)
(relevant portion starts at 6:56)

------
__michaelg
Given that app developers need to actively use those iOS features, the obvious
question is: How much of my app data is actually encrypted that way?

It's much harder to get these things right (e.g. you want your fancy sync and
notifications to work even if the phone is locked, etc.) thus I suspect that
most apps would just use the _Protected Until First User Authentication_ class
and that's about it. Is there any way to confirm or refute that?

~~~
leonatan
In fact, that is indeed the default protection level, which is strong enough
for a default setting.

~~~
__michaelg
Sure, but it's not any better than the Android FDE, and thus kind of defeating
the point of the article. If everyone just uses the default setting, then
iOS's encryption is theoretically and architecturally better, but it won't
make a difference in practice.

~~~
leonatan
It's a compromise between security and usability, like always. And it is good
for most cases. When higher security is needed, developer can choose to
override and implement a different mechanism.

------
patcon
Still reading, but in case anyone is interested in the grugq'd hardening
project (Ironsides) that Matthew referred to, it started as an open source
project. I believe I have the fork that has the most recent public commits, as
I was playing with it a few days before it went away:

[https://github.com/patcon/darkmatter](https://github.com/patcon/darkmatter)

Unfortunately, the wiki was one of the most interesting parts, as I remember,
and that wasn't preserved.

Disclaimer: Goes without saying, but VERY stale code, and light-years behind
the current project.

EDIT: some interesting things I remember from the wiki: triggers to losing a
wifi or bluetooth signal (so that actions could be triggered if phone was
placed in a faraday bag and lost touch with a paired bluetooth device or
mobile hotspot or whatever), trigger for when temperature dropped (so actions
could be triggered if someone tried to pull a cold boot attack)

------
Wonnk13
Geez, as much as i'd love to divorce myself from the Apple ecosystem I
continually find reasons to keep my iPhone instead of opting for Android.

~~~
emsy
I'm in the same boat. Due to Apple's most recent product decisions I'm losing
confidence and I'm starting to look elsewhere. After reading up on the current
state of Android and especially how to increase privacy and security, it seems
I'll have to stick with Apple for a while longer.

~~~
Wonnk13
Slightly o/t; my 2008 macbook is on its last legs. Are ThinkPads still sending
metrics back to Lenovo HQ? I simply can't justify buying the new macbooks.

~~~
c13k
The consumer grade Thinkpads did that for a short while, not anymore. If you
buy yourself an X or T series new or even better refurbished, they will last
for years and are serviceable yourself. Wonderful machines.

------
mschwaig
I had a Moto X Play where a bug ended up just totally disabeling the lock
screen. You would turn on the device and land on the home screen even though
you had set an unlock pattern.

This bug was triggered by using Google Drive while the internal storage was
basically full. The day after that the phone got stolen, so I couldn't take a
closer look. :(

~~~
dietr1ch
Maybe the thief filled your Google Drive first :o

~~~
mschwaig
I actually wasn't sure if i should even post the Google Drive part, because
theoretically this might even be exploitable in some way. I also found other
people with the same bug online, so it really was a thing.

------
bitmapbrother
This article makes a lot of assumptions that seem to be based on how he thinks
things work instead of providing proof of how they work. He states that the
keys "seem" to live forever in userspace RAM, yet provides no proof of this.

~~~
matthewdgreen
The code is here. It's pretty explicit.
[https://android.googlesource.com/platform/system/vold/+/andr...](https://android.googlesource.com/platform/system/vold/+/android-7.0.0_r14/Ext4Crypt.cpp#75)

Here's an email from Paul Crowley to me. Paul is one of the devs on this code:
[https://twitter.com/ciphergoth/status/801220048622714880?lan...](https://twitter.com/ciphergoth/status/801220048622714880?lang=en)

Not really sure what else I can offer you.

~~~
matthewdgreen
Also, I want to clarify that I _don 't_ think the weaknesses of Android N's
encryption are the fault of Paul or anyone else on the team. I think this is
really a question of corporate priorities. If Google wanted to put a lot of
energy behind Android's device encryption, my suspicion is that they would be
much farther along than they are now.

------
imchillyb
Relying solely upon a phone's built-in encryption is much like relying solely
upon a condom to prevent pregnancy.

It's only when multiple steps are taken that a method of prevention is even
remotely reliable.

