Live data from Hacker News

The limitations of Android N Encryption

blog.cryptographyengineering.com

11–20 of 31 posts

Re: The limitations of Android N Encryption

#11
post #6
post #4

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

I'm coming to the same conclusion. Despite being a happy Sony Xperia for years now, I think my next phone is an iPhone.

Which kind of sucks, because I don't want to spend eight trillion dollars on a phone, but...

Re: The limitations of Android N Encryption

#12
post #6
post #4

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

Yeah, I need a new phone (screen dying, probable battery swelling) and would like a newer macbook, but the latest Apple offerings (and prices) on both fronts drove me to look outside the bubble for the first time in a while.

I can say the competition has gotten good enough that it's only obviously worse when you look a bit closer than a quick glance at owner sentiment and specs. That's the best I can say. And those are the handful of stand-out devices—the overwhelming bulk is still trash.

So: Apple's stumbled really hard, but the competition's still basically a whole different product category, so I guess I'll just wait and see what things look like in 2017 :-/

Re: The limitations of Android N Encryption

#13
post #8

Earlier quoted context omitted.

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 m…

"Garbage"? Can you explain why?

The design and implementation surface area for TrustZone is just too big to be secure.

Protecting a few secrets is a bit different from a Quasi-hypervisor environment that could be used to implement such a scheme.

Re: The limitations of Android N Encryption

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

Re: The limitations of Android N Encryption

#15

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

Maybe the thief filled your Google Drive first :o

Re: The limitations of Android N Encryption

#16

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

Maybe the thief filled your Google Drive first :o

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.

Re: The limitations of Android N Encryption

#17

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

Maybe the thief filled your Google Drive first :o

[deleted]

Re: The limitations of Android N Encryption

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

Re: The limitations of Android N Encryption

#19
post #8

Earlier quoted context omitted.

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 m…

"Garbage"? Can you explain why?

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

Re: The limitations of Android N Encryption

#20
post #19
post #8

Earlier quoted context omitted.

"Garbage"? Can you explain why?

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

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.
Post reply on HN