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

31–40 of 141 posts

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

#31

Post by jjcob »

londons_explore wrote: post #26
modeless wrote: post #11

Earlier quoted context omitted.

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

The waiting time increases after failed attempts.

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

#32

Post by londons_explore »

jjcob wrote: post #31
londons_explore wrote: post #26

Earlier quoted context omitted.

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

The waiting time increases after failed attempts.

In general that isn't secure unless the security chip has access to a secure time server to know that the required amount of time has passed.

Otherwise you can simply say "yeah, we power cycled you and now the year is 100,000, can I have another guess?"

I don't see any mention of that functionality in any public documentation.

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

#34

Post by ThePowerOfFuet »

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

Not if you live in the UK.

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

#35

Post by unloader6118 »

modeless wrote: post #23
j16sdiz wrote: post #22

Earlier quoted context omitted.

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.

There are some fundamental different between two ecosystems.

On Google, the Google Drive and Photo are encrypted to a key owned by google.

On iCloud, the iCloud Drive and Photo are encrypted to your account key. In which, without ADP, this key is shared with Apple. When ADP is enabled, Apple does not store this key. iCloud Backup is stored with the same technology as iCloud Drive.

When it comes to lost password account recovery:

- Google can just reset your password, and your drive and photo are still accessible. All barrier are procedural, not technical.

- iCloud (with ADP), they can still reset your password, but then your icloud drive and icloud photo are loss forever.

There are some trade off ..:

- Lost password recovery experience. _Some_ user will lost their password anyway. How high should the bar be?

- Cloud first? or local device first with cloud backup?

- Are you giving the cloud data same protection as local device?

In google's solution, they put the google drive data at risk...

In apple's solution, it need extra steps to ensure you have proper account recovery flow covered.

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

#36

Post by gU9x3u8XmQNG »

tgma wrote: post #19
modeless wrote: post #18

Earlier quoted context omitted.

Yes but when Messages in iCloud is enabled that "client-side" encryption key is itself included in your iCloud backup (that Apple can read), as disclosed. So Apple can read your messages regardless of whether you enable or disable Messages in iCloud. The only things that prevent it are disabling cloud backups entirely, or enabling ADP. But even those don't really prevent it because unless everyone you message also do…

Good to know, hence my 95% certainty. Fortunately for me, each new device starts with DFU restore and installation of my own Configuration Profile which supervises the device, disable automatic pairing with new devices, disables useless apps like Game Center, and most importantly disables iCloud Backup entirely, etc.

How are you achieving this? I’d like to know more. Thanks in advance.

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

#37

Post by modeless »

unloader6118 wrote: post #35
modeless wrote: post #23

Earlier quoted context omitted.

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.

There are some fundamental different between two ecosystems. On Google, the Google Drive and Photo are encrypted to a key owned by google. On iCloud, the iCloud Drive and Photo are encrypted to your account key. In which, without ADP, this key is shared with Apple. When ADP is enabled, Apple does not store this key. iCloud Backup is stored with the same technology as iCloud Drive. When it comes to lost password accou…

That's all fine, but tangential to my complaint, which is about iMessage specifically. iMessage, as a system that strongly promotes e2ee as a core feature, should not be backing up its encryption keys to non-e2ee iCloud backup in any scenario. Messages should fall in the same category as keychain passwords and (yes!) Memoji, backups of which are always end-to-end encrypted even when ADP is not enabled.

In fact I would say calling iMessage an e2ee system is false advertising until this is corrected. Reasonable people would assume that an Apple system advertised as e2ee would make an effort to prevent Apple servers from having the keys to decrypt most iMessages, while the reality is with these defaults it's likely that a large majority of iMessages can be decrypted by Apple servers at will.

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

#38

Post by tgma »

gU9x3u8XmQNG wrote: post #36
tgma wrote: post #19

Earlier quoted context omitted.

Good to know, hence my 95% certainty. Fortunately for me, each new device starts with DFU restore and installation of my own Configuration Profile which supervises the device, disable automatic pairing with new devices, disables useless apps like Game Center, and most importantly disables iCloud Backup entirely, etc.

How are you achieving this? I’d like to know more. Thanks in advance.

Perhaps I should document it and link to it in detail but basically you use Apple Configurator to create a profile and set its restriction flags accordingly and keep it somewhere you can redeploy with ease and simply DFU restore the iOS device so that it gets the latest clean iOS image. After that you don’t activate it by going through the setup screen. Instead you use the connected Mac with Apple Configurator to “Prepare” the device and the computer activates it and pairs it with your “organization” public key and you can add the profiles you created in the previous steps to apply the configuration restrictions. It’s like having an enterprise MDM except you don’t need a server just the local profile is enough.

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

#40

Post by FireBeyond »

londons_explore wrote: post #32
jjcob wrote: post #31

Earlier quoted context omitted.

The waiting time increases after failed attempts.

In general that isn't secure unless the security chip has access to a secure time server to know that the required amount of time has passed. Otherwise you can simply say "yeah, we power cycled you and now the year is 100,000, can I have another guess?" I don't see any mention of that functionality in any public documentation.

So now you just need to fake a cell tower and a GPS constellation so that the phone gets a new time on power cycle. Which would be about 60s minimum, to boot and acquire.

And that’s with a power cycle, so 14,000 a day? I’ll not going to assume the button will last more than 100,000 presses, so I don’t see many combinations being tried.

Post reply on HN