8 ms·

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-passcode-exploit/ http://www.cnet.com

by ctz 11y ago

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-passcode-exploit/ 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.

mehrdada 11y ago
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.
- soisses 11y ago
  Seems photos are accessible with a new iOS9 flaw: http://www.idownloadblog.com/2015/09/20/ios-9-access-photos-contacts-locked-iphone-security-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?
  - linkydinkandyou 11y ago
    Careful! The paid Apple astroturfers will quickly down vote you off of hacker news!
    - dang 11y ago
      Accusations of astroturfing and shillage without evidence are not allowed on HN, so please don't do this here.
  - daxelrod 11y ago
    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.
    - giovannibajo1 11y ago
      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.
  - mehrdada 11y ago
    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.
- bilbo0s 11y ago
  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 ???
  - misnome 11y ago
    > 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.
  - mehrdada 11y ago
    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.
    - crazysim 11y ago
      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.
ignoramous 11y ago
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?
linkydinkandyou 11y ago
Thank you for inserting the Truth here. I'm sick and tired of Apple's paid apologists trying to take over ever thread here.
JoshTriplett 11y ago
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.

by ctz 11y ago

mehrdada 11y ago

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.

soisses 11y ago
Seems photos are accessible with a new iOS9 flaw: http://www.idownloadblog.com/2015/09/20/ios-9-access-photos-contacts-locked-iphone-security-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?
- linkydinkandyou 11y ago
  Careful! The paid Apple astroturfers will quickly down vote you off of hacker news!
  - dang 11y ago
    Accusations of astroturfing and shillage without evidence are not allowed on HN, so please don't do this here.
- daxelrod 11y ago
  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.
  - giovannibajo1 11y ago
    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.
- mehrdada 11y ago
  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.
bilbo0s 11y ago
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 ???
- misnome 11y ago
  > 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.
- mehrdada 11y ago
  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.
  - crazysim 11y ago
    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.

ignoramous 11y ago

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?

linkydinkandyou 11y ago

Thank you for inserting the Truth here. I'm sick and tired of Apple's paid apologists trying to take over ever thread here.

JoshTriplett 11y ago

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.