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

21–30 of 141 posts

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

#21

Post by DaSHacka »

londons_explore wrote: post #10
modeless wrote: post #5

Earlier quoted context omitted.

I'm glad ADP exists now, but you have to make sure everyone you message has it enabled too, or your messages are still Apple's to read whenever they choose. Meanwhile Google's equivalent backup feature (whatever other faults it may have) has been end-to-end encrypted by default for everyone since long before ADP was even available at all. The risk of losing access is practically nonexistent because the password is yo…

> the password is your screen lock code You mean the one that by default is a 4 digit number and therefore trivially brute forcable? And neither android hardware nor the google servers have any kind of secure element enforcing brute force protections like '3 tries then we wipe the keys'.

> And neither android hardware nor the google servers have any kind of secure element enforcing brute force protections

The Titan M chip is present on all Pixel devices:

https://grapheneos.org/faq#encryption

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

#22

Post by j16sdiz »

xvector wrote: post #8
ls612 wrote: post #3

Earlier quoted context omitted.

The more charitable interpretation is that for most people losing their photos and messages is a bigger threat than the government spying on them. For those who might have a different tradeoff there is Advanced Data Protection.

ADP is a total joke if it doesn't also disable plaintext backups for the people you're talking to

https://support.apple.com/en-us/102651

> With Advanced Data Protection, the number of data categories that use end-to-end encryption rises to 25 and includes your iCloud Backup,...

> iCloud Backup (including device and Messages backup) (3)

> (3) .... Advanced Data Protection: iCloud Backup and everything inside it is end-to-end encrypted, including the Messages in iCloud encryption key.

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

#23

Post by modeless »

j16sdiz wrote: post #22
xvector wrote: post #8

Earlier quoted context omitted.

ADP is a total joke if it doesn't also disable plaintext backups for the people you're talking to

https://support.apple.com/en-us/102651 > With Advanced Data Protection, the number of data categories that use end-to-end encryption rises to 25 and includes your iCloud Backup,... > iCloud Backup (including device and Messages backup) (3) > (3) .... Advanced Data Protection: iCloud Backup and everything inside it is end-to-end encrypted, including the Messages in iCloud encryption key.

Yes, your backup is e2e encrypted after you enable the off-by-default ADP. But some of your friends probably didn't enable ADP, and the keys to decrypt your messages to them are stored in their backups which Apple can read at will.

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

#24

Post by Jtsummers »

modeless wrote: post #13
Jtsummers wrote: post #12

Earlier quoted context omitted.

> ADP is a total joke if it doesn't also disable plaintext backups for the people you're talking to Do you consider all security to be a joke then? If you send me a message, how will you actually guarantee that I do not make a copy of it once it's on my own computer?

There's no guarantee, but some apps intended for security actually make at least a minimal effort to be excluded from plaintext backups, rather than intentionally sending their encryption keys to the backup service that just happens to be run by the same company...

Ok. So you concede that there is no way for you to ensure that messages you send me, that I can decrypt, are left unreadable by anyone but me.

So what secure communication system should we be using given that none of them can guarantee that the recipient doesn't leak information to another country by choosing to use a compromised version of the client?

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

#25

Post by charliebwrites »

conradev wrote: post #17
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...

Not if you have "Advanced Data Protection" turned on: https://support.apple.com/en-us/108756

Do we have any guarantee that enabling ADP utilizes a new key that isn’t already in a previous non-ADP back up?

Would be a shame if they claimed they can’t decrypt but an old back up had the keys to the kingdom

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

#26

Post by londons_explore »

modeless wrote: post #11
londons_explore wrote: post #10

Earlier quoted context omitted.

> the password is your screen lock code You mean the one that by default is a 4 digit number and therefore trivially brute forcable? And neither android hardware nor the google servers have any kind of secure element enforcing brute force protections like '3 tries then we wipe the keys'.

> neither android hardware nor the google servers have any kind of secure element enforcing brute force protections I don't know why you would say this when it is obviously false. https://security.googleblog.com/2018/10/google-and-android-h...

do they actually enforce these limits? I couldn't find any google UI which says "2 tries left or your data will be permanently erased".

One can't implement brute force protections without such a UI...

"You need to wait 5 minutes" isn't sufficient for a 4 digit pin...

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

#27

Post by conradev »

charliebwrites wrote: post #25
conradev wrote: post #17

Earlier quoted context omitted.

Not if you have "Advanced Data Protection" turned on: https://support.apple.com/en-us/108756

Do we have any guarantee that enabling ADP utilizes a new key that isn’t already in a previous non-ADP back up? Would be a shame if they claimed they can’t decrypt but an old back up had the keys to the kingdom

You're trusting a whole lot of trust in the first place. But I imagine that they did not do that.

I can't sign into Apple Music on Android because it doesn't support security keys – small price to pay.

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

#28

Post by modeless »

Jtsummers wrote: post #24
modeless wrote: post #13

Earlier quoted context omitted.

There's no guarantee, but some apps intended for security actually make at least a minimal effort to be excluded from plaintext backups, rather than intentionally sending their encryption keys to the backup service that just happens to be run by the same company...

Ok. So you concede that there is no way for you to ensure that messages you send me, that I can decrypt, are left unreadable by anyone but me. So what secure communication system should we be using given that none of them can guarantee that the recipient doesn't leak information to another country by choosing to use a compromised version of the client?

My complaint is not about guarantees, it's about defaults. Default non-e2e-encrypted backups of message encryption keys are the problem here. No system can guarantee absolute security, but that doesn't mean they're all equivalently bad. Some are definitely more secure than others, and defaults have a lot to do with it!

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

#29

Post by firecall »

londons_explore wrote: post #10
modeless wrote: post #5

Earlier quoted context omitted.

I'm glad ADP exists now, but you have to make sure everyone you message has it enabled too, or your messages are still Apple's to read whenever they choose. Meanwhile Google's equivalent backup feature (whatever other faults it may have) has been end-to-end encrypted by default for everyone since long before ADP was even available at all. The risk of losing access is practically nonexistent because the password is yo…

> the password is your screen lock code You mean the one that by default is a 4 digit number and therefore trivially brute forcable? And neither android hardware nor the google servers have any kind of secure element enforcing brute force protections like '3 tries then we wipe the keys'.

I don’t believe that on Android or iOS it defaults to 4-Digits anymore, does it?

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

#30

Post by Jtsummers »

modeless wrote: post #28
Jtsummers wrote: post #24

Earlier quoted context omitted.

Ok. So you concede that there is no way for you to ensure that messages you send me, that I can decrypt, are left unreadable by anyone but me. So what secure communication system should we be using given that none of them can guarantee that the recipient doesn't leak information to another country by choosing to use a compromised version of the client?

My complaint is not about guarantees, it's about defaults. Default non-e2e-encrypted backups of message encryption keys are the problem here. No system can guarantee absolute security, but that doesn't mean they're all equivalently bad. Some are definitely more secure than others, and defaults have a lot to do with it!

> Some are definitely more secure than others, and defaults have a lot to do with it!

That's great, naming those would have been better though since it would have actually answered the question.

Post reply on HN