The limitations of Android N Encryption

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

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

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 (relevant portion starts at 6:56)

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?

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

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)

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.

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. :(

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.

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.