Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

usenix.org

Post reply on HN
Print view View original

101–110 of 141 posts

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#101

Post by matthewdgreen »

tpmoney wrote: post #92
matthewdgreen wrote: post #78

Earlier quoted context omitted.

On the one hand: yes. On the other hand, the ADP setting is located in the moral equivalent of the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.’ Apple could do a lot to promote this feature to more advanced users, but they don’t. I don’t believe for a second this decision is unrelated to the government pressure they’ve been receiving from the UK.

Is “Settings -> iCloud -> Advanced Data Protection” really the “moral equivalent of the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying Beware of the leopard”? Where else would you put it? I could see an argument for putting it in “Settings -> Privacy and Security -> Advanced Data Protection” but that to me feels like a “six if one, half dozen of the other” change.

You could suggest it during initial setup. You could advertise the feature beyond a weirdly named setting at the scroll-down portion of the iCloud page. You could call it something more descriptive like “end to end encrypted iCloud”, which would distinguish it from other security features. You could periodically ask users to do checkups, and verify that their backup contacts are still active and available — even if they’re not actively using ADP.

The best analogy I can give is the way Apple gradually raised MFA from an optional feature with 1-2% adoption to a recommended feature that had majority adoption (even if it was not required.) They did this by heavily encouraging users to turn the feature on during setup, and then bugging them about it after setup. Apple is capable of encouraging and advertising security features it cares about, even when there’s risk.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#102

Post by arghwhat »

fsflover wrote: post #94
arghwhat wrote: post #93

Earlier quoted context omitted.

None of your points is about whether or not the company spies or not. You also conflate the malice of the country they are in with the malice of the company itself. Google's primary business is and have always been ads, and they practically invented the kind of global tracking we have all come to know and hate. Google actively tries to expand tracking and ad exposure to their own benefit. See the Google TV Streamer h…

> Apple has a miniscule ad business They're expanding it: https://www.axios.com/2024/11/19/apple-news-ads-direct-sales... > many companies that have your data consider it a liability they would much rather be without - it's just sometimes hard to provide a service without data passing through Apple collects much more data than needed for the service. They also make it practically impossible to use the phones without…

There's a big difference between "expanding miniscule business unit" and company whose entire identity is that, so much so they're willing to pay the first company several time the revenue of their ad business every year just to decide a default setting that might boost their ad business.

And once more, you're conflating access to information and spying.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#103

Post by modeless »

eddyg wrote: post #82
modeless wrote: post #2

All that security, and then by default Apple literally just sends themselves a copy of your encryption keys to store in iCloud backup, the only cloud backup solution Apple allows you to use. "to help you recover your data" [1] (oh and also to send law enforcement your message history in plaintext on request, but we don't talk about that). [1] https://support.apple.com/en-us/102651#:~:text=in%20iCloud%2...

More people need to watch Ivan Krstic's Black Hat presentation to understand the efforts Apple goes through to ensure sensitive data (like the User Escrow Keys which get stored in Apple's Cloud Key Vault) is protected from adversarial attacks... even from inside Apple. https://www.youtube.com/watch?v=BLGFriOKz6U&t=26m50s (Be sure to watch through the section from 34m to 36m...)

Rogue insider threats are far from the only thing e2ee protects against.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#104

Post by tgma »

miki123211 wrote: post #69
modeless wrote: post #2

All that security, and then by default Apple literally just sends themselves a copy of your encryption keys to store in iCloud backup, the only cloud backup solution Apple allows you to use. "to help you recover your data" [1] (oh and also to send law enforcement your message history in plaintext on request, but we don't talk about that). [1] https://support.apple.com/en-us/102651#:~:text=in%20iCloud%2...

Most users demand: 1. That their messages won't be lost when they migrate between devices. 2. That their messages won't be lost when their device is stolen and they set up the new one from nothing but a password. 3. That Apple's password recovery flows work like any other password recovery flows, AKA that forgetting your password is a minor inconvenience, to be overcome at the Apple Store at worst, not a data loss di…

> Signal made different tradeoffs

To some degree sure, but the real issue with Signal is the app UX royally sucks, not having to do much with security trade-offs per se.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#105

Post by CharlesW »

modeless wrote: post #100
dostick wrote: post #71

Earlier quoted context omitted.

What about the “Advanced Data Protection” end to end encryption? Or by “sending copy of keys to iCloud” you mean those? It even says that “Apple will not be able to help you recover if you switch to End to end advanced data protection”.

ADP is overkill. Apple already end-to-end encrypts keychain passwords, health data, and other stuff even if you don't enable ADP. They need to do the same with iMessage, or otherwise they need to stop falsely advertising iMessage as a strong e2ee system when it literally uploads its encryption keys to Apple by default. Also, even if you enable ADP Apple can likely still read the vast majority of your messages in othe…

> ADP is overkill.

"No, not like that." :O) But seriously, you can also just turn off iCloud Backups for Messages. (iCloud > Storage > Messages > Turn Off and Delete from iCloud)

> …otherwise they need to stop falsely advertising iMessage as a strong e2ee system when it literally uploads its encryption keys to Apple by default.

iMessage is E2EE, but iCloud Backup is not, which I understand is a distinction probably not well understood by most HN readers, much less your average consumer.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#106

Post by modeless »

int_19h wrote: post #65
modeless wrote: post #2

All that security, and then by default Apple literally just sends themselves a copy of your encryption keys to store in iCloud backup, the only cloud backup solution Apple allows you to use. "to help you recover your data" [1] (oh and also to send law enforcement your message history in plaintext on request, but we don't talk about that). [1] https://support.apple.com/en-us/102651#:~:text=in%20iCloud%2...

> the only cloud backup solution Apple allows you to use Not quite. You can still have automatic local backups set up for iOS and macOS devices to your own NAS. And that NAS can then do cloud backups of whatever is on it in any way you want. It's certainly more effort than the stock iCloud solution, but it's still an option.

OK, if you have or buy a $599+ Mac from Apple in addition to your iOS device, and first connect your iOS device with a USB cable, and then enable the optional Wi-Fi sync, and regularly connect the Mac and the iOS device to the same Wi-Fi network while the Mac is not sleeping, and configure an e2ee cloud backup on the Mac to include the iOS backup, then that is actually a way to achieve a third-party e2ee cloud backup. Though it's stretching the definition a bit due to the requirement to have the Mac connected to the same Wi-Fi for the backup to occur, I'd consider a true cloud backup solution to work on any network connection or even cellular.

I'm willing to bet that the number of people who have ever set all of that up as described is in the triple digits worldwide. A rounding error.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#107

Post by modeless »

CharlesW wrote: post #105
modeless wrote: post #100

Earlier quoted context omitted.

ADP is overkill. Apple already end-to-end encrypts keychain passwords, health data, and other stuff even if you don't enable ADP. They need to do the same with iMessage, or otherwise they need to stop falsely advertising iMessage as a strong e2ee system when it literally uploads its encryption keys to Apple by default. Also, even if you enable ADP Apple can likely still read the vast majority of your messages in othe…

> ADP is overkill. "No, not like that." :O) But seriously, you can also just turn off iCloud Backups for Messages. (iCloud > Storage > Messages > Turn Off and Delete from iCloud) > …otherwise they need to stop falsely advertising iMessage as a strong e2ee system when it literally uploads its encryption keys to Apple by default. iMessage is E2EE, but iCloud Backup is not, which I understand is a distinction probably n…

I'm sorry, a messaging app that in its most common configuration has its encryption keys stored on its developer's servers in a way that allows them to decrypt messages at will cannot be reasonably called e2ee. I don't care if it's technically a different OS process doing the uploading.

It's all Apple software on Apple software and Apple's responsibility to match user expectations based on the claims Apple makes. No reasonable person would expect that Apple intentionally retains the ability to decrypt the majority of iMessage communications given their marketing of iMessage as e2ee.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#108

Post by tgma »

modeless wrote: post #98
miki123211 wrote: post #69

Earlier quoted context omitted.

Most users demand: 1. That their messages won't be lost when they migrate between devices. 2. That their messages won't be lost when their device is stolen and they set up the new one from nothing but a password. 3. That Apple's password recovery flows work like any other password recovery flows, AKA that forgetting your password is a minor inconvenience, to be overcome at the Apple Store at worst, not a data loss di…

> There's no way to satisfy those demands and have your desired level of security False. Google has done it with their backups. And Apple already does it too! Keychain passwords, health data, and a lot of other stuff is end-to-end encrypted in backups even when ADP is disabled, with recovery options if you lose your devices, no yubikey required. They simply choose not to apply the same solution to message data.

With Google password-based encryption or Keychain, you lose your data if you lost your devices and forget your Google Account password. I suspect that is a use case that is too risky (frequency x impact of data loss) for the Apple customer base that they don't want to risk it.

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#109

Post by CharlesW »

modeless wrote: post #107
CharlesW wrote: post #105

Earlier quoted context omitted.

> ADP is overkill. "No, not like that." :O) But seriously, you can also just turn off iCloud Backups for Messages. (iCloud > Storage > Messages > Turn Off and Delete from iCloud) > …otherwise they need to stop falsely advertising iMessage as a strong e2ee system when it literally uploads its encryption keys to Apple by default. iMessage is E2EE, but iCloud Backup is not, which I understand is a distinction probably n…

I'm sorry, a messaging app that in its most common configuration has its encryption keys stored on its developer's servers in a way that allows them to decrypt messages at will cannot be reasonably called e2ee. I don't care if it's technically a different OS process doing the uploading. It's all Apple software on Apple software and Apple's responsibility to match user expectations based on the claims Apple makes. No…

> I'm sorry, a messaging app that in its most common configuration has its encryption keys stored on its developer's servers in a way that allows them to decrypt messages at will cannot be reasonably called e2ee.

It's extremely common for Apple services to be encrypted in transit and on Apple's servers by default, and additionally also at rest when you opt into ADP (which is how you say "I want E2EE and understand the ramifications of that" in the Apple Cinematic Universe).¹ As you noted, for the average consumer, ADP² is overkill and therefore a terrible default.³

¹ https://support.apple.com/en-us/102651 ² https://support.apple.com/guide/security/advanced-data-prote... ³ https://news.ycombinator.com/item?id=43934995

Re: A Formal Analysis of Apple's iMessage PQ3 Protocol [pdf]

#110

Post by modeless »

tgma wrote: post #108
modeless wrote: post #98

Earlier quoted context omitted.

> There's no way to satisfy those demands and have your desired level of security False. Google has done it with their backups. And Apple already does it too! Keychain passwords, health data, and a lot of other stuff is end-to-end encrypted in backups even when ADP is disabled, with recovery options if you lose your devices, no yubikey required. They simply choose not to apply the same solution to message data.

With Google password-based encryption or Keychain, you lose your data if you lost your devices and forget your Google Account password. I suspect that is a use case that is too risky (frequency x impact of data loss) for the Apple customer base that they don't want to risk it.

The e2ee for Google backups is based on the user's screen lock code, not account password. https://security.googleblog.com/2018/10/google-and-android-h...

Unlike the account password that users need only once in a blue moon, users are required to practice entering their screen lock code at least once a week to continue using their device. Probably more often in most cases. And it's much shorter.

Chrome sync also supports e2ee, and using it requires that you set a sync passphrase that is separate from your Google account password. The account password is known to Google servers and so can't be used to secure e2ee data. The screen lock code, in contrast, is never stored in a form accessible to Google.

Post reply on HN