Hacker News Reader

Comment by ctz | Hacker News Reader

iOS has had the same class of bug a few times in the past. Example: http://www.cnet.com/news/apple-promises-fix-for-ios-6-passco...

Android has a similar architecture with the 'keystore' service (for keys rather than files though). Crashing SystemUI will 'unlock' the phone, but none of the keys in the keystore will be usable. Unfortunately, no apps use the keystore in practice because it's unusably badly designed. You're vanishingly unlikely to notice if you're using a phone with a locked keystore.

View on HN

I quote from the link you posted: "...opens up access to the phone application to listen to a user's voice mails, place calls, and view contact information. Attempting to go beyond that sends users back to the passcode screen."

That's the point: what you can access is not encrypted, but lots of stuff are on iOS9: photos, mail, etc. I'd say the difference in what you can access is staggering.

Seems photos are accessible with a new iOS9 flaw: http://www.idownloadblog.com/2015/09/20/ios-9-access-photos-...

How can this be, if they are encrypted while the phone is locked?

My guess is that contacts and photos remain in the class of things that do not require the phone unlock key.

Contacts need to be accessed to display a caller's name when the phone is ringing.

Since it's possible to take a photo with the phone locked, the whole photo database may be accessible.

Yes. If you reboot an iOS phone, and then call it without ever entering the passcode before, it will display the phone number but not look it up, because contacts are encrypted. The encryption class here is "locked until first unlock", so they stay unlocked afterwards not to disrupt basic expected user functionality. The whole security design is still much better as many other things stay completely locked.

I stand corrected then. Photos are probably still encrypted under "accessible after first unlock" class. Sigh. Sorry for this mistake.

The idea of having a security architecture with different classes of data still remains, so a third party app can quite easily leverage this, for instance. Unfortunately there doesn't seem to be a comprehensive list of protection classes that each app uses for its files.

Please pardon my ignorance. I'm not a security expert.

Is there any reason this can't be fixed by just copying iOS in this regard ??? I guess the question I'm asking is, this bug is entirely fixable right ???

Not trying to diminish the seriousness of it. It sounds pretty horrible. Just saying that if Android's architecture will allow you to do something like iOS does, but it's simply unimplemented currently, that's one thing. It would be quite another thing if Android's architecture would NOT allow you to do something like iOS does. As I said... I'm not a security expert... but it SOUNDS like you can implement a fix that would mirror the protections provided in iOS ???

Is that true ???

> I guess the question I'm asking is, this bug is entirely fixable right ???

Of course. The problem android has had in the past, though, is that actually getting security updates to users could be incredibly convoluted - with every vendor and network having their own, slightly tweaked (and heavily branded) versions of android.

Yes. It requires serious engineering across the OS stack though. Also, it is generally harder and less effective to this retroactively; existing third party apps may not switch to leverage the new APIs when it is done retroactively. This makes it hard for PC operating systems to effectively adopt it, though I really hope they do it soon.

Right now it seems the low hanging fruit for Android would be to encrypt devices _at all_ (by default). Different classes of encryption is a luxury.

I did hear they did encrypt by default on the Nexus 6. Unfortunately, it seriously affected performance and was then turned off. I guess this may be due not having a fast hardware encryption path to and from the flash memory.

iOS encrypts, even if you don't set a passphrase or something and their security white paper does mention having dedicated hardware to make it seamless.

I believe a later software update for the Nexus 6 sped up encryption considerably.

How do I check if encryption is turned on for a Nexus 6?

If an Android device has encrypted storage, it has to ask you for the decryption password before it will boot (ie BEFORE you get to a lock screen). If it doesn't, then it's not encrypted.

You're right, but the KeyStore API isn't even exposed to 3P apps. AOSP, however, does use it. May be the Framework could use the state of the KeyStore (which would be set to "locked") to detect a breach?

There are a few ways that can and should be fixed to "fail closed". For instance, "locked" status should get stored somewhere outside the memory of any one process, so that if the system UI crashes, when it comes back up, before it displays any application, it should notice that it was previously in the locked state and go back to the locked state.

Reply on news.ycombinator.com