Remix.run Logo
modeless 14 hours ago

Then they turn around and upload your iMessages to their own servers in a form that they can read, breaking their own E2EE. Google Messages fixed this issue a long time ago. Why hasn't Apple? https://james.darpinian.com/blog/apple-imessage-encryption

philsnow 14 hours ago | parent | next [-]

What is "Google Messages"? I can't count the number of articles people have written over time about how many first-party messaging apps Google themselves have put out (and then put down), not to mention what messaging apps get shoveled on by third-party android integrators.

> the main reason a message wouldn't be properly end-to-end encrypted in Google's Messages app is when communicating with an iPhone user, because Apple has dragged their feet on implementing RCS features in iMessage

(or with any other android user who isn't using a first-party device / isn't using this one app)

> [...] Android's equivalent cloud backup service has been properly end-to-end encrypted by default for many years. Meaning that you don't need to convince the whole world to turn on an optional feature before your backups can be fully protected.

You make it out to seem that it's impossible for Google to read your cloud backups, but the article you link to [0] earlier in your post says that "this passcode-protected key material is encrypted to a Titan security chip on our datacenter floor" (emphasis added). So they have your encrypted cloud backup, and the only way to get the key material to decrypt it is to get it from an HSM in their datacenter, every part of which and the access to which they control... sounds like it's not really any better than Apple, from what I'm reading here. Granted, that article is from 2018 and I certainly have not been keeping up on android things.

[0] https://security.googleblog.com/2018/10/google-and-android-h...

modeless 13 hours ago | parent [-]

HSMs are designed to protect encryption keys from everyone including the manufacturer. Signal trusts them for their encryption features. It's the best security possible for E2EE backups with passcode recovery, and Apple does it too for the subset of data that they do real E2EE backups on, like Keychain passwords. Characterizing using an HSM to implement E2EE securely as "not any better than" just giving up on E2EE for messages backups is ridiculous.

philsnow 12 hours ago | parent [-]

The HSMs that Signal and Apple are using are on-device though. Yes you still have to trust Signal / Apple to not exfil your key matter once decrypted by the HSM, but I submit that that is materially better than having the HSMs be hosted in a datacenter.

modeless 12 hours ago | parent [-]

Signal and Apple and Google all use HSMs in datacenters as well as on device.

TheNewsIsHere 13 hours ago | parent | prev | next [-]

You can enable Advanced Data Protection to address that issue with iMessages.

Giving users an option between both paths is usually best. Most users care a lot more that they can’t restore a usable backup of their messages than they do that their messages are unreadable by the company storing them.

I used to work at a company where our products were built around encryption. Users here on HN are not the norm. You can’t trust that most users will save recovery codes, encryption seed phrases, etc in a manner that will be both available and usable when they need them, and then they tend to care a lot less about the privacy properties that provides and a lot more that they no longer have their messages with {deceased spouse, best friend, business partner, etc}.

modeless 13 hours ago | parent [-]

> Apple can still read any message you exchange with practically anyone through their iCloud backups, since they are overwhelmingly likely to have backups enabled and overwhelmingly unlikely to have proactively enabled the non-default "Advanced Data Protection" feature.

> They could have implemented iMessage to not backup messages from people who enabled ADP, but they didn't. They won't even inform you when your conversation partner has uploaded your messages to Apple's servers in a form that Apple can read.

> Android's equivalent cloud backup service has been properly end-to-end encrypted by default for many years. Meaning that you don't need to convince the whole world to turn on an optional feature before your backups can be fully protected.

> Apple's stated reason for not enabling end-to-end encryption on iCloud backups by default is that it would cause data loss when users lose their devices. But Google's implementation avoids this problem. Furthermore, Apple does do end-to-end encryption by default on other critical information that would be painful to lose, such as your account passwords stored in Keychain. So that excuse doesn't seem to hold water.

runjake 14 hours ago | parent | prev | next [-]

This is your blog post, so I'll ask you a question. What are you trying to state in Belief #1? The message is unclear to me with how it's worded:

  > In this table, in the "iCloud Backup (including device and Messages backup)" row, under "Standard data protection", 
  > the "Encryption" column reads "In transit & on server". Yes, this means that Apple can read all of your messages 
  > out of your iCloud backups.
In addition to the things you mentioned, there's certainly a possibility of Apple attaching a virtual "shadow" device to someone's Apple ID with something like a hide_from_customer type flag, so it would be invisible to the customer.

This shadow device would have it's own keys to read messages sent to your iCloud account. To my knowledge, there's nothing in the security model to prevent this.

microtonal 12 hours ago | parent | next [-]

This shadow device would have it's own keys to read messages sent to your iCloud account. To my knowledge, there's nothing in the security model to prevent this.

Matthew Green has some great posts about iMessage security. This one describes the key lookup issue:

https://blog.cryptographyengineering.com/2015/09/09/lets-tal...

Looking at the linked Apple Platform Security, it seems like the Apple Identity Service is still used as a public key directory.

shawnz 14 hours ago | parent | prev | next [-]

The table has two categorizations: "In transit & on server" and "End-to-end". The former, which covers iCloud backups in the default configuration, is explicitly NOT end-to-end, meaning there are moments in time during processing where the data is not encrypted.

However, iCloud backups actually are listed as "End-to-end" if you turn on the new Advanced Data Protection feature.

digiown 14 hours ago | parent | prev | next [-]

Or Apple can also push an update, which you can't refuse, that upon first message to iCloud just uploads your private key. It's a bit foolish to count on encryption implemented by the adversary you're trying to hide from. Of course, this will most likely only affect individuals targeted by state-level actors.

shawnz 11 hours ago | parent [-]

IIRC Apple has attempted to implement some defences against this, for example by requiring the passcode to be inputted before an update can be installed to prevent another San Bernardino scenario. A cursory search indicates that they also have some kind of transparency log system for updates, but it seems to only apply to their cloud systems and not iOS updates.

14 hours ago | parent | prev [-]
[deleted]
14 hours ago | parent | prev [-]
[deleted]