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

111–120 of 141 posts

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

#111

Post by modeless »

CharlesW wrote: post #109
modeless wrote: post #107

Earlier quoted context omitted.

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 th…

Those other Apple services are not marketed over and over with the promise of end-to-end encryption. It's a major selling point of iMessage and it is a false promise when Apple deliberately collects the keys to the majority of iMessage traffic and routinely decrypts user messages (for law enforcement, we know for sure, and we can't exclude the possibility that they do it for other purposes).

ADP doesn't need to be default for iMessage to be e2ee. Keychain passwords are e2ee without ADP. So is health data. Even Memoji are e2ee in backups! And I believe they can be restored even if you lose all your devices, using the same technique Google uses in their system. Apple could literally turn it on for iMessage tomorrow using the same infrastructure. Every day they are deliberately choosing not to.

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

#112

Post by tgma »

modeless wrote: post #110
tgma wrote: post #108

Earlier quoted context omitted.

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 supp…

Yea, the problem I am pointing to is not the security side, but backup resilience aspect; in any of those scenarios (device passcode^ as you suggest for Android, or account password by default for Chrome, or a separate encryption password for Chrome), if you lose your client device and you forget the password, there is no way to get back the data, by design. I have personally encountered anecdotal situations where this happened to family and they would hate to lose their photo library, so it is not that unlikely. Me personally would opt for losing it--that almost certainly won't be the trade-off an average Apple customer wants to make. They likely expect from Apple to be able to give them their data back if their device is stolen and they have forgotten everything and go to Apple Store and present an ID.

^: I concede that this might be an acceptable thing to assume they won't get to forget. At the same time, I don't think this is a worthwhile encryption given the average 4-6 digit passcode length because you do not have the ability to mix in on-device keys (otherwise backups can't restore in other devices without another key).

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

#113

Post by mmooss »

tgma wrote: post #104
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…

> 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.

What do you see?

I've seen many non-technical end users use Signal, immediately upon trying it, with no problems. I've never seen someone have a problem.

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

#114

Post by modeless »

tgma wrote: post #112
modeless wrote: post #110

Earlier quoted context omitted.

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 supp…

Yea, the problem I am pointing to is not the security side, but backup resilience aspect; in any of those scenarios (device passcode^ as you suggest for Android, or account password by default for Chrome, or a separate encryption password for Chrome), if you lose your client device and you forget the password, there is no way to get back the data, by design. I have personally encountered anecdotal situations where th…

I think you missed my point that the screen lock code is not at all like the account password in terms of resilience to forgetting. I know people who have forgotten their account passwords and lost photos etc, similar to what you describe. However, I know nobody who has lost access to the phone they use every day by forgetting the screen lock code. That is very unlikely.

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

#115

Post by tgma »

modeless wrote: post #114
tgma wrote: post #112

Earlier quoted context omitted.

Yea, the problem I am pointing to is not the security side, but backup resilience aspect; in any of those scenarios (device passcode^ as you suggest for Android, or account password by default for Chrome, or a separate encryption password for Chrome), if you lose your client device and you forget the password, there is no way to get back the data, by design. I have personally encountered anecdotal situations where th…

I think you missed my point that the screen lock code is not at all like the account password in terms of resilience to forgetting. I know people who have forgotten their account passwords and lost photos etc, similar to what you describe. However, I know nobody who has lost access to the phone they use every day by forgetting the screen lock code. That is very unlikely.

I addressed it in the footnote: 6-digit encryption key without tying it to device is just security theatre (and people might still forget: many users are old). Longer passwords people will forget.

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

#116

Post by tgma »

mmooss wrote: post #113
tgma wrote: post #104

Earlier quoted context omitted.

> 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.

What do you see? I've seen many non-technical end users use Signal, immediately upon trying it, with no problems. I've never seen someone have a problem.

I have used Telegram, iMessage, WhatsApp and Signal extensively in multiplatform settings. Only iMessage and Telegram have good overall UX (with the latter far more featureful and smooth than the former). Sure all "work" to some degree but the overall poor UX shows. It's more about polish issues and death with a thousand cuts, rather than one specific problem, although in the case of Signal, the out of place "Story" bullshit is a turn-off.

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

#117

Post by fsflover »

arghwhat wrote: post #102
fsflover wrote: post #94

Earlier quoted context omitted.

> 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.

> you're conflating access to information and spying

So what's the difference? In this particular case, the access is unwanted and unnecessary, i.e. it very much looks like spying to me.

> There's a big difference between "expanding miniscule business unit" and

Apple is a for-profit company, not a charity. They collected a ton of personal data on everyone and are continuously expanding their ad business. How naive you must be to trust that they're on the side of users forever? It's the same discussion on HN every time: https://news.ycombinator.com/item?id=39928611

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

#118

Post by modeless »

tgma wrote: post #115
modeless wrote: post #114

Earlier quoted context omitted.

I think you missed my point that the screen lock code is not at all like the account password in terms of resilience to forgetting. I know people who have forgotten their account passwords and lost photos etc, similar to what you describe. However, I know nobody who has lost access to the phone they use every day by forgetting the screen lock code. That is very unlikely.

I addressed it in the footnote: 6-digit encryption key without tying it to device is just security theatre (and people might still forget: many users are old). Longer passwords people will forget.

It's not security theater. You didn't read, or didn't understand, the blog post I linked that explains how it provides strong security despite the low entropy passcode by using secure elements in the datacenter. I believe Apple does the same for the categories of data that are e2ee in backups when ADP is not enabled, such as keychain passwords (iMessage should be in this category and the fact that it's not is my whole complaint).

Here's that link again: https://security.googleblog.com/2018/10/google-and-android-h...

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

#119

Post by ezst »

some_furry wrote: post #76
methuselah_in wrote: post #33

[flagged]

Ah yes, so you can host your own plaintext on your XMPP server and not get end-to-end encryption.

For the record, XMPP has OMEMO as its standard E2E/PFS-preserving encryption protocol (based on your usual double-ratchet aka Signal encryption), which is regularly audited for security (and as recently as last month in the case of the Conversations Android client).

XMPP being used by several law enforcement agencies and institutions like NATO, I wouldn't default to making fun of its security.

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

#120

Post by some_furry »

ezst wrote: post #119
some_furry wrote: post #76

Earlier quoted context omitted.

Ah yes, so you can host your own plaintext on your XMPP server and not get end-to-end encryption.

For the record, XMPP has OMEMO as its standard E2E/PFS-preserving encryption protocol (based on your usual double-ratchet aka Signal encryption), which is regularly audited for security (and as recently as last month in the case of the Conversations Android client). XMPP being used by several law enforcement agencies and institutions like NATO, I wouldn't default to making fun of its security.

https://soatok.blog/2024/08/04/against-xmppomemo/

OMEMO is not always-on like Signal, so it doesn't even compare.

Post reply on HN