7 ms·

This can happen only because of a design flaw in the security architecture of Android (L). Unlike iOS and like traditional PCs, the disk encryption key is alwa

This can happen only because of a design flaw in the security architecture of Android (L). Unlike iOS and like traditional PCs, the disk encryption key is always in memory when the device is booted and nothing is really protected if you get a device in that state. It's an all-or-nothing proposition. On iOS, there are different encryption keys that are used to protect different classes of information. Specifically, when an iOS device is locked, the operating system loses a key that can decrypt files that are of a certain protection class that are not supposed to be readable when the device is locked. Only by entering the password when unlocking the device (or reloading it from Touch ID memory), that key can be derived again. The effect is, for example, all your mail can be protected and rendered unreadable while the device is locked. With this security architecture, no bug in the password "gatekeeper UI" can lead to you being able to read the protected information if the device gets locked successfully.

devit 11y ago
You can do that on PC by hibernating instead of locking the screen (assuming it works on the OS and hardware being used) and then rebooting instead of shutting down after hibernation.
- mehrdada 11y ago
  If you do that, you'll lose 100% of your PC's functionality, whereas iOS is quite useful in locked mode. With some neat tricks, it even fetches new mail for you, for instance: basically it encrypts new messages by encrypting them with a public key whose private key is encrypted and the key is not available while the device is locked[+]. A hibernated PC cannot do this and lots more. [+]: technically, it generates a new AES key, encrypts the message under it, encrypts that key under a key derived from ECDH over Curve25519 with the system public key (whose private key is encrypted and inaccessible while locked) and saves the encrypted file and the wrapped key somewhere to be decrypted when it gets unlocked and gets rid of the AES key.
  - devit 11y ago
    That's not as secure as hibernation, because someone who can break into the running device can at least read all your new mail and if they aren't using an ad-hoc e-mail protocol or implemented it carelessly also read all mail and probably get the e-mail username and password too. This also only really works for software specifically designed for this mode. EDIT: it can actually be mostly secure if the client public key is sent before locking and then the encryption is done by the server: the attacker would only learn the number and timing of new messages and their size (assuming an ad-hoc protocol and very carefully implemented software). It's also sort of possible to do it with generic software by simply dumping HTTPS TCP traffic to disk and decoding it once the system is unlocked (although it allows a MITM to fill up your disk unless the ciphersuite allows authentication with a key that doesn't allow decryption).
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
mtgx 11y ago
Jesus, why do Android engineers keep getting security so wrong so often? And they even bragged so much about how L is (finally) getting storage encryption by default, which they promptly killed after the Nexus 6 launch (because apparently they are stupid and launched the device without hardware accelerated encryption, even though the chip supported...ugh). We still haven't heard anything about it being re-enabled in Android M again (or ever). Also, I remember reading about Android <4.4 (optional) storage crypto being seriously broken as well. It's unfortunate because many people probably still believe they are getting default storage encryption. Heck, all the new stories on encryption and the FBI still (falsely) mention how Android is encrypting the storage by default. It reminds of media sites saying Skype is P2P and secure against eavesdropping years after Microsoft announced it changed its infrastructure to a centralized wiretap-friendly model, just like everyone else. The gap between iOS and Android in terms of security (and privacy, too) seems to only be increasing every year. If they keep this up I may finally switch to an iPhone after years of being an Android-only user. https://medium.com/@FredericJacobs/apple-ios-9-security-privacy-features-8d82d9da10eb https://medium.com/@FredericJacobs/apple-ios-9-security-priv... And that's even without mentioning the horrible update problem that Android has. I've just learned to live with that by installing custom ROMs after my phone stops being supported a year into its life-cycle, which is obviously not ideal in terms of security nor is it something I should have to do to get better security.
- raverbashing 11y ago
  I have to agree Add to that forgetting a month in a calendar and an Alarm that rings for one second and stops Almost justifies the extra price for the iPhone
- personjerry 11y ago
  Maybe Blackberry's security-oriented design isn't so lackluster after all
  - blinkingled 11y ago
    Given their track record - it was quite great actually.
deleted 11y ago
[deleted]
cnvogel 11y ago
That's one of the things that I find inexcusably and also rather sad: Given the amount of customization that Android systems require to run on a particular vendors hardware, they don't seem to make use of the multitude of security features present in modern processors, or just the ability to solder on a dedicated TPM/security processor. But I'm genuinely curious, maybe someone here on HN knows: Which of the other mobile phone systems (Windows Phone; Firefox OS; Ubuntu for Mobile; Tizen; Blackberry; ...) have a halfway decent security architecture, similar to iOS?
- pjmlp 11y ago
  I would add Symbian to your list. It was there first.
  - alanh 11y ago
    I can't tell if you are implying Symbian had a good security story, or if you are merely reminding us that it is basically the original smartphone OS.
    - pjmlp 11y ago
      It had a good security history. The whole point of Symbian OS S60 3rd Edition (aka Symbian OS 9.1) release was to introduce DRM support and a security model based on certificates for API sets. Many, included myself, were disappointed that they didn't took the opportunity of such breaking change in the programming model, to throw the Symbian C++ dialect out of the window.
icebraining 11y ago
Even with the Android/PC architecture, you can have a much better design. For example, jwz's XScreenSaver separates the graphical process (more complex and bug-prone) from the daemon. If you manage to crash the password input screen (or the screensaver itself), the daemon will just restart it.
- kelnos 11y ago
  Not true, actually. See https://www.jwz.org/xscreensaver/toolkits.html https://www.jwz.org/xscreensaver/toolkits.html ... (I'm assuming this hasn't changed, of course, as this was written over 10 years ago... but the fundamental reasons why he was unable to write the dialog as a separate process should still remain, since they're fairly well-known and not-particuarly-surmountable issues with X.) The password input screen uses only low-level X11 calls (and not a higher-level GUI toolkit) in an attempt to reduce the library dependency list and therefore the possibility of crasher bugs. But if you do indeed manage to find a crash bug in libX11 (or a dep) that you can trigger from xscreensaver's password entry box, that will indeed unlock the screen. Now, the xscreensaver configuration panel is written using GTK, which is indeed a separate process, and a crash in the config panel won't affect the screen locker.
  - icebraining 11y ago
    Oh, I don't remember that page, I must have missed it. Still, Android doesn't run X, and since they control the whole OS, it shouldn't be too hard to avoid having input "pass through" the lock screen.

devit 11y ago

You can do that on PC by hibernating instead of locking the screen (assuming it works on the OS and hardware being used) and then rebooting instead of shutting down after hibernation.

mehrdada 11y ago
If you do that, you'll lose 100% of your PC's functionality, whereas iOS is quite useful in locked mode. With some neat tricks, it even fetches new mail for you, for instance: basically it encrypts new messages by encrypting them with a public key whose private key is encrypted and the key is not available while the device is locked[+]. A hibernated PC cannot do this and lots more. [+]: technically, it generates a new AES key, encrypts the message under it, encrypts that key under a key derived from ECDH over Curve25519 with the system public key (whose private key is encrypted and inaccessible while locked) and saves the encrypted file and the wrapped key somewhere to be decrypted when it gets unlocked and gets rid of the AES key.
- devit 11y ago
  That's not as secure as hibernation, because someone who can break into the running device can at least read all your new mail and if they aren't using an ad-hoc e-mail protocol or implemented it carelessly also read all mail and probably get the e-mail username and password too. This also only really works for software specifically designed for this mode. EDIT: it can actually be mostly secure if the client public key is sent before locking and then the encryption is done by the server: the attacker would only learn the number and timing of new messages and their size (assuming an ad-hoc protocol and very carefully implemented software). It's also sort of possible to do it with generic software by simply dumping HTTPS TCP traffic to disk and decoding it once the system is unlocked (although it allows a MITM to fill up your disk unless the ciphersuite allows authentication with a key that doesn't allow decryption).

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

mtgx 11y ago

Jesus, why do Android engineers keep getting security so wrong so often? And they even bragged so much about how L is (finally) getting storage encryption by default, which they promptly killed after the Nexus 6 launch (because apparently they are stupid and launched the device without hardware accelerated encryption, even though the chip supported...ugh). We still haven't heard anything about it being re-enabled in Android M again (or ever). Also, I remember reading about Android <4.4 (optional) storage crypto being seriously broken as well. It's unfortunate because many people probably still believe they are getting default storage encryption. Heck, all the new stories on encryption and the FBI still (falsely) mention how Android is encrypting the storage by default. It reminds of media sites saying Skype is P2P and secure against eavesdropping years after Microsoft announced it changed its infrastructure to a centralized wiretap-friendly model, just like everyone else. The gap between iOS and Android in terms of security (and privacy, too) seems to only be increasing every year. If they keep this up I may finally switch to an iPhone after years of being an Android-only user. https://medium.com/@FredericJacobs/apple-ios-9-security-privacy-features-8d82d9da10eb https://medium.com/@FredericJacobs/apple-ios-9-security-priv... And that's even without mentioning the horrible update problem that Android has. I've just learned to live with that by installing custom ROMs after my phone stops being supported a year into its life-cycle, which is obviously not ideal in terms of security nor is it something I should have to do to get better security.

raverbashing 11y ago
I have to agree Add to that forgetting a month in a calendar and an Alarm that rings for one second and stops Almost justifies the extra price for the iPhone
personjerry 11y ago
Maybe Blackberry's security-oriented design isn't so lackluster after all
- blinkingled 11y ago
  Given their track record - it was quite great actually.

deleted 11y ago

[deleted]

cnvogel 11y ago

That's one of the things that I find inexcusably and also rather sad: Given the amount of customization that Android systems require to run on a particular vendors hardware, they don't seem to make use of the multitude of security features present in modern processors, or just the ability to solder on a dedicated TPM/security processor. But I'm genuinely curious, maybe someone here on HN knows: Which of the other mobile phone systems (Windows Phone; Firefox OS; Ubuntu for Mobile; Tizen; Blackberry; ...) have a halfway decent security architecture, similar to iOS?

pjmlp 11y ago
I would add Symbian to your list. It was there first.
- alanh 11y ago
  I can't tell if you are implying Symbian had a good security story, or if you are merely reminding us that it is basically the original smartphone OS.
  - pjmlp 11y ago
    It had a good security history. The whole point of Symbian OS S60 3rd Edition (aka Symbian OS 9.1) release was to introduce DRM support and a security model based on certificates for API sets. Many, included myself, were disappointed that they didn't took the opportunity of such breaking change in the programming model, to throw the Symbian C++ dialect out of the window.

icebraining 11y ago

Even with the Android/PC architecture, you can have a much better design. For example, jwz's XScreenSaver separates the graphical process (more complex and bug-prone) from the daemon. If you manage to crash the password input screen (or the screensaver itself), the daemon will just restart it.

kelnos 11y ago
Not true, actually. See https://www.jwz.org/xscreensaver/toolkits.html https://www.jwz.org/xscreensaver/toolkits.html ... (I'm assuming this hasn't changed, of course, as this was written over 10 years ago... but the fundamental reasons why he was unable to write the dialog as a separate process should still remain, since they're fairly well-known and not-particuarly-surmountable issues with X.) The password input screen uses only low-level X11 calls (and not a higher-level GUI toolkit) in an attempt to reduce the library dependency list and therefore the possibility of crasher bugs. But if you do indeed manage to find a crash bug in libX11 (or a dep) that you can trigger from xscreensaver's password entry box, that will indeed unlock the screen. Now, the xscreensaver configuration panel is written using GTK, which is indeed a separate process, and a crash in the config panel won't affect the screen locker.
- icebraining 11y ago
  Oh, I don't remember that page, I must have missed it. Still, Android doesn't run X, and since they control the whole OS, it shouldn't be too hard to avoid having input "pass through" the lock screen.