5 ms·

Is there more on this? Can this as is really be enough to maintain the security guarantees Apple currently provides?

spogbiper 4y ago
Apple currently provides no encryption at all when their users communicate with the owners of the 75% of mobile devices that are not Apple. Apple could do better for it's customers.
f_devd 4y ago
What security guarantees do Apple currently provide? I can't imagine much more than E2EE & maybe encrypted-at-rest (which is not a protocol-level feature anyway).
- hedora 4y ago
  Well, the security coprocessor on every iPhone and Mac runs a formally verified operating system that manages the at-rest encrypted messages. Also, all software running on the phone is vetted before being allowed to hit consumer devices, which adds an extra level of security between malicious developers and kernel APIs. There's no way Android will support that stuff across its entire ecosystem, so I guess it means the law is toothless? Maybe it means it will be up to each hardware manufacturer to ensure interoperability?
  - dcow 4y ago
    1. I don't think "formally verified" means what you want it to here. You mean there a hardware checks signature chain from boot to kernel, secure boot. Apple's software has too many security vulnerability to be considered "formally verified". 2. Android does support device attestation and secure boot. I 100% would love to see our future SMS replacement require frequent signatures from device attestation hardware (why not every message) and require E2EE messages.
    - hedora 4y ago
      It is a fork of this: https://people.cs.ksu.edu/~danielwang/BAS/klein-2014-microkernelverification.pdf https://people.cs.ksu.edu/~danielwang/BAS/klein-2014-microke... This is not the kernel that runs on the host CPU. It is the one that handles keys in the security coprocessor. I don’t know of many hacks of that, in practice. There was one where you could guess the pin, and use a timing attack to power down the chip before it persisted the “bad guess” count, which let people brute force pins (with special hardware). It’s worth noting that the kernel Apple ships is a fork of L4; no idea if they’ve introduced bugs since the paper was written.
      - dcow 4y ago
        Didn't realize you were talking about secure enclave.
  - f_devd 4y ago
    Encrypted at rest does not actually do anything against interoperability of protocols (as I put in my comment), a secure element/coprocessor is nice but still does nothing against compatibility. Even if the entire protocol is somehow in the coprocessor (ala BPF/SGX) there is nothing preventing the counterparty from running it on a regular CPU.
    - hedora 4y ago
      Interoperability can break security properties though. If I send you an iMessage, I can be confident that someone that steals your phone (while it is locked) cannot read that message (ignoring things like state-sponsored attacks).
      - f_devd 4y ago
        Prolonged unsupervised physical access is usually already seen as a compromise. Regardless although there is a lot more publicity on Apple's "online attack" difficulty, it's mostly the same story on any semi-recent version of android[0] (barring any unknown zero-days/backdoors from specific manufacturers). [0]: https://theconversation.com/what-if-the-fbi-tried-to-crack-an-android-phone-we-attacked-one-to-find-out-56556 https://theconversation.com/what-if-the-fbi-tried-to-crack-a...

Apple currently provides no encryption at all when their users communicate with the owners of the 75% of mobile devices that are not Apple. Apple could do better for it's customers.

f_devd 4y ago

What security guarantees do Apple currently provide? I can't imagine much more than E2EE & maybe encrypted-at-rest (which is not a protocol-level feature anyway).

hedora 4y ago
Well, the security coprocessor on every iPhone and Mac runs a formally verified operating system that manages the at-rest encrypted messages. Also, all software running on the phone is vetted before being allowed to hit consumer devices, which adds an extra level of security between malicious developers and kernel APIs. There's no way Android will support that stuff across its entire ecosystem, so I guess it means the law is toothless? Maybe it means it will be up to each hardware manufacturer to ensure interoperability?
- dcow 4y ago
  1. I don't think "formally verified" means what you want it to here. You mean there a hardware checks signature chain from boot to kernel, secure boot. Apple's software has too many security vulnerability to be considered "formally verified". 2. Android does support device attestation and secure boot. I 100% would love to see our future SMS replacement require frequent signatures from device attestation hardware (why not every message) and require E2EE messages.
  - hedora 4y ago
    It is a fork of this: https://people.cs.ksu.edu/~danielwang/BAS/klein-2014-microkernelverification.pdf https://people.cs.ksu.edu/~danielwang/BAS/klein-2014-microke... This is not the kernel that runs on the host CPU. It is the one that handles keys in the security coprocessor. I don’t know of many hacks of that, in practice. There was one where you could guess the pin, and use a timing attack to power down the chip before it persisted the “bad guess” count, which let people brute force pins (with special hardware). It’s worth noting that the kernel Apple ships is a fork of L4; no idea if they’ve introduced bugs since the paper was written.
    - dcow 4y ago
      Didn't realize you were talking about secure enclave.
- f_devd 4y ago
  Encrypted at rest does not actually do anything against interoperability of protocols (as I put in my comment), a secure element/coprocessor is nice but still does nothing against compatibility. Even if the entire protocol is somehow in the coprocessor (ala BPF/SGX) there is nothing preventing the counterparty from running it on a regular CPU.
  - hedora 4y ago
    Interoperability can break security properties though. If I send you an iMessage, I can be confident that someone that steals your phone (while it is locked) cannot read that message (ignoring things like state-sponsored attacks).
    - f_devd 4y ago
      Prolonged unsupervised physical access is usually already seen as a compromise. Regardless although there is a lot more publicity on Apple's "online attack" difficulty, it's mostly the same story on any semi-recent version of android[0] (barring any unknown zero-days/backdoors from specific manufacturers). [0]: https://theconversation.com/what-if-the-fbi-tried-to-crack-an-android-phone-we-attacked-one-to-find-out-56556 https://theconversation.com/what-if-the-fbi-tried-to-crack-a...