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

The limitations of Android N Encryption

blog.cryptographyengineering.com

Post reply on HN
Print view View original

21–30 of 31 posts

Re: The limitations of Android N Encryption

#21

Post by Wonnk13 »

emsy wrote: post #6
Wonnk13 wrote: 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.

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.

Re: The limitations of Android N Encryption

#22

Post by 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

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)

Re: The limitations of Android N Encryption

#24

Post by caf »

tytso wrote: post #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…

Looking at the code, it seems to keep the keys in a map called s_ce_keys, though there is a comment referencing b/26948053 which presumably is a bug to stop it doing that.

Re: The limitations of Android N Encryption

#25

Post by tytso »

tytso wrote: post #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…

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

Re: The limitations of Android N Encryption

#26

Post by __michaelg »

leonatan wrote: post #9
__michaelg wrote: post #7

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…

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

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.

Re: The limitations of Android N Encryption

#27

Post by c13k »

Wonnk13 wrote: post #21
emsy wrote: post #6

Earlier quoted context omitted.

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.

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.

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.

Re: The limitations of Android N Encryption

#28

Post by leonatan »

__michaelg wrote: post #26
leonatan wrote: post #9

Earlier quoted context omitted.

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

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.

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.

Re: The limitations of Android N Encryption

#30

Post by matthewdgreen »

bitmapbrother wrote: post #29

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.

The code is here. It's pretty explicit. https://android.googlesource.com/platform/system/vold/+/andr...

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

Not really sure what else I can offer you.

Post reply on HN