Apple advances user security with powerful new data protections

[hishnash]

3 hours ago, Deadendking said:

i dont think they are allowed to use imessage

You can use iMessage (and it is end to end encrypted already in china) what is not end to end encrypted (unless you opt in on these changes) Is the optional iMessages in the cloud backup. So if your in china and what end to end encrypted (including group chats) you just need to ensure everyone in your chats turns off iMessage backups. 

 

 

3 hours ago, Deadendking said:

end to end encryption is a very good thing though, but it just locks the data that is being send between your phone or pc to the server, whether its apple, facebook or google.
so in the end these companies still have access to your data.

 End to end encryption means only you (or the intended recipient such as the iMessage contact/s) have the key to decrypt it. The service provider (apple, etc) do not have the key all they have is encrypted blobs of data and they have no way to get the key or figure it out.  

 

[Deadendking]

5 minutes ago, hishnash said:

they have no way to get the key or figure it out.

I don't know, I just Don't trust these companies...
I mean they wrote the program and they definitely know how to decrypt it so ...

[hishnash]

2 minutes ago, Deadendking said:

I don't know, I just Don't trust these companies...
I mean they wrote the program and they definitely know how to decrypt it so ...

Knowing the algorithm does not mean you can break the key.   In fact Apple will be using an industry standard algorithm that is public Apple have already published this here: https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf

Cryptography these days (in fact any time since the second world war) is no longer something were knowing the method means you can break the key. You need to know the key and the key is randomly generated on the users device bespoke to them and secured so that apple cant get it. In fact with apple devices this will be secured within the secure enclaved so regardless of the os running on there (apples or anyone else) the pain text master key cant be extracted.  

The os cant read data out of the Secure Enclave it can only ask the enclave to encrypt or decrypt bits of data it has using a key id that is stored within the enclave, many many security experts have attempted to breach Appels Secure enclave and to date have not managed, even with physical attacks and electronic attacks.  The key that is used for this cant be extracted by apple even with an os patch, by design in hardware the master key will never leave its little enclave. 

 

[Dracarris]

16 hours ago, NastyFlytrap said:

So its available on all of their servers? I very much doubt you'd be accessing an american server if you were say on vacation in europe, or in china, for some reason.

I don't know a lot about cloud backend solutions - but there is absolutely no sane reason to copy data of a EU or US customer to a Chinese server, especially if he doesn't reside in China for any amount of time. It costs Apple money and at the same time exposes data of Western citizens to the CCP.

What happens once you travel to China as a EU or US customer is a different question. In any case, end2end encryption should also help in this case.

2 hours ago, hishnash said:

 https://help.apple.com/pdf/security/en_US/apple-platform-security-guide.pdf

Man that's quite a document.

[Sauron]

On 12/8/2022 at 12:39 AM, DrMacintosh said:

Conversations between users who have enabled iMessage Contact Key Verification receive automatic alerts if an exceptionally advanced adversary, such as a state-sponsored attacker, were ever to succeed breaching cloud servers and inserting their own device to eavesdrop on these encrypted communications.

Uh... bold of Apple to assume they'd realize if such an attack were to succeed... and if they know about something like that happening surely they'd make this known to all their users and try to cleanse their servers as soon as possible, regardless of whether you turned on this specific "feature"?

On 12/8/2022 at 12:39 AM, DrMacintosh said:

And for even higher security, iMessage Contact Key Verification users can compare a Contact Verification Code in person, on FaceTime, or through another secure call.

What does this mean? Is this just a fancy way of saying "certificates"?

On 12/8/2022 at 12:39 AM, DrMacintosh said:

To further demonstrate how serious this is, the FBI is worried that Apple is implementing these features. The FBI provided multiple statements on the subject: 

The FBI wanted to get rid of all encryption that didn't have a backdoor so this is a pretty low standard to go by...

[hishnash]

7 hours ago, Sauron said:

Uh... bold of Apple to assume they'd realize if such an attack were to succeed... and if they know about something like that happening surely they'd make this known to all their users and try to cleanse their servers as soon as possible, regardless of whether you turned on this specific "feature"?

This feature is a client side change that means the phones can detect if keys etc change un-expecidily. The idea is that if say the US somehow forced Apple with a secrete judge order to let them into apples servers users with this feature enabled would get a warning on the phone.   One key part of this is also there to precept users who are in conversations with someone and that someone has thier account composted by a state actor.  Things like the state actor temoariy stealing the users phone (without them knowing) and using that moment to gain account access (2fa) and then setting up a second device that can then read the users messages.  

 

8 hours ago, Sauron said:

What does this mean? Is this just a fancy way of saying "certificates"?

Yer I think so, but I expect it is a hashed checksum version that does not require you to read back the full key. 

 

[hishnash]

4 minutes ago, wanderingfool2 said:

iMessage is no where near "safe" if Apple is capable of access it.  Literally a data breach could potentially compromise hundreds of millions of user's iMessage messages.  There is also the whole PRISM fiasco and FISA request

Tecniclay apple cant access iMessage they can however access iMessage backups (if the use has this turned on and have not turned on the new full end to end encryption).  

iMessage messages are end to end as they are sent but many users have iMessage backups enabled so that they can read old messages on devices that did not get them (eg if you buy a new Mac and still want to be able to read and search old messages you got before getting the Mac). 

[wanderingfool2]

17 minutes ago, hishnash said:

Tecniclay apple cant access iMessage they can however access iMessage backups (if the use has this turned on and have not turned on the new full end to end encryption).  

iMessage messages are end to end as they are sent but many users have iMessage backups enabled so that they can read old messages on devices that did not get them (eg if you buy a new Mac and still want to be able to read and search old messages you got before getting the Mac). 

I do not consider it safe if an iCloud backup breaks the encryption scheme.  From my understanding as well, even if you make a single iCloud backup (keeping it enabled but never actually running the backup again), the decryption keys will be available (and if already pulled by someone like the FBI could be used to decrypt current iMessage messages).

 

One can advertise all they want that iMessages are end to end encrypted, but if a large percentage backup with iCloud then it's effectively not really

[hishnash]

2 hours ago, wanderingfool2 said:

I do not consider it safe if an iCloud backup breaks the encryption scheme.  From my understanding as well, even if you make a single iCloud backup (keeping it enabled but never actually running the backup again), the decryption keys will be available (and if already pulled by someone like the FBI could be used to decrypt current iMessage messages).

No the key used for encrypting the backup is different to the keys used for messages in flight. Keys used for messages in flight are bespoke to each conversation (and rotate frequently). Also each backup slice has its own key. Keys are rotated very frequently, so gaining access to a backup key from multiple years ago only gives you access to the data in that backup slice. It has nothing to do with other backups (future backups in particular future backups) and has nothing at all to do with iMessage in flight. Since the keychain is (and has always been) end to end encrypted (if the FBI go access to the keychain, by breaching a users device) they would have the the ability to read current but not future messages.  (Forward security is a key conscep when building system like these). 

 

[LAwLz]

<removed>

 

9 hours ago, wanderingfool2 said:

I will respond as I well please.  And to be clear, the source I responded to he quite literally said that iMessage wasn't "safe" (in his response to DrMacIntosh's safe as it could get).  Yet you again try demanding "source", and clearly iMessage is no where near "safe" if Apple is capable of access it.  Literally a data breach could potentially compromise hundreds of millions of user's iMessage messages.  There is also the whole PRISM fiasco and FISA request

There is a big difference between "iMessage isn't safe" and "a backup solution that can be used for iMessage isn't safe". 

 

iCloud and iMessage are two separate things. It's very misleading to say for example "Signal is broken and doesn't provide security" just because you might use a backup solution that saves the conversations as clear text. That's a potential issue with the backup solution, not Signal. Likewise, iCloud backups being accessible by Apple doesn't mean iMessage is flawed. It just means the backup solution is. 

 

I do however thing you have some misunderstanding regarding how the backups work, but some other people have already replied to that so I'll leave you to responding to them. 

Edited December 11, 2022 by SansVarnic
Removed content.

[hishnash]

51 minutes ago, LAwLz said:

iCloud and iMessage are two separate things. It's very misleading to say for example "Signal is broken and doesn't provide security" just because you might use a backup solution that saves the conversations as clear text. That's a potential issue with the backup solution, not Signal. Likewise, iCloud backups being accessible by Apple doesn't mean iMessage is flawed. It just means the backup solution is. 

 

This is well put, in fact Signal and other secure messaging apps also suffer the same issue if the user has a full device backup solution and that backup is not end to end then these messaging apps are susceptible to message history being exposed since locally on device any disk encryption they opt to for data at rest requires the keys to be also stores alongside within the backup for the backup to be of use.  

[Montana One-Six]

On 12/10/2022 at 1:32 AM, LAwLz said:

Source?

Like I said earlier I don't have any and I'm way too lazy to search for something online. I know a few things because of what I was doing when I was in the military and back then several messengers were deemed insecure with iMessage being one of them. Plus I have seen and heard a few things during that time that make me very skeptical about any type of supposedly secure app or service that is connected via internet.

That's my source and if you don't believe me then don't.

 

[Sauron]

8 hours ago, hishnash said:

This feature is a client side change that means the phones can detect if keys etc change un-expecidily. The idea is that if say the US somehow forced Apple with a secrete judge order to let them into apples servers users with this feature enabled would get a warning on the phone.

That's a bit clearer, I still don't understand how such a powerful agent would be able to gain full access to Apple's cloud and not be able to maintain the same key... and besides if asymmetric keys change surely end to end encryption would simply fail? Isn't that the whole point?

 

Like, what does "unexpectedly" mean in this context? What tells the phone to "expect" a key change and why couldn't the malicious actor gain access to that function too?

8 hours ago, hishnash said:

Things like the state actor temoariy stealing the users phone (without them knowing) and using that moment to gain account access (2fa) and then setting up a second device that can then read the users messages.

How would you be able to distinguish this from the user just changing their settings? If you have access to their 2fa authentication the system must assume you're the legitimate user, there is no way of telling otherwise.

8 hours ago, hishnash said:

Yer I think so, but I expect it is a hashed checksum version that does not require you to read back the full key. 

well if it's like certificates you don't get to see the private key anyway, I'm just wondering whether it's meaningfully different from existing TLS encryption we already have on almost everything.

[wanderingfool2]

6 hours ago, hishnash said:

No the key used for encrypting the backup is different to the keys used for messages in flight. Keys used for messages in flight are bespoke to each conversation (and rotate frequently). Also each backup slice has its own key. Keys are rotated very frequently, so gaining access to a backup key from multiple years ago only gives you access to the data in that backup slice. It has nothing to do with other backups (future backups in particular future backups) and has nothing at all to do with iMessage in flight. Since the keychain is (and has always been) end to end encrypted (if the FBI go access to the keychain, by breaching a users device) they would have the the ability to read current but not future messages.  (Forward security is a key conscep when building system like these). 

 

Yea, that maybe true, I decided to read the white paper and yea nope I would say Apple's implementation of E2EE isn't safe from spying (if legally requested).  General idea of it still not being safe is true though as well, backups imho should never have been consider to be stored in a way that allows access to the data that you claim/advertise as E2EE.   While the stats aren't really visible, I bet the vast majority essentially use the combo which makes it pretty pointless.

 

Although it is wrong to also state keys for messages in flight are bespoke to each conversation.  Messages (not long messages or photos), are encrypted using a public key which Apple holds.  That's how Apple handles E2EE, they provide the sender with a public key and the sender uses that to encrypt the message.

 

If you specifically want to know how to access iMessages if you were law enforcement, from my theorycrafingt.  Apple internally generates a private key and public key internally when requested by law enforcement.  Apple delivers a "new" public key for Alice to Bob.  So Bob now has the "new" public key for Alice.  Bob sends a message to Alice, which goes through Apples servers.  Apple uses the private key they now have to decrypt the message, they then use Alice's actual public key to encrypt it again and send it to Alice.  So yea, at least according to their white paper, unless things have changed in how they encrypt everything I would not call it safe or secure from law enforcement as E2EE ultimately relies on the trust in Apple's servers.

 

https://web.archive.org/web/20140228173632/https://images.apple.com/iphone/business/docs/iOS_Security_Feb14.pdf

 

5 hours ago, LAwLz said:

iCloud and iMessage are two separate things. It's very misleading to say for example "Signal is broken and doesn't provide security" just because you might use a backup solution that saves the conversations as clear text. That's a potential issue with the backup solution, not Signal. Likewise, iCloud backups being accessible by Apple doesn't mean iMessage is flawed. It just means the backup solution is. 

If Signal created the backup software and the majority use it then yes I would say Signal isn't safe.

 

Apple wants to be one ecosystem they get treated as one ecosystem.  A product is not safe if at the same time you create a separate product that fundamentally undermines the security.  The protocol is secure, but the app itself isn't safe.  Safe does not equal secure.  Oh, but also read my response above, from what Apple described they could perform a MITM still.

 

3 hours ago, Sauron said:

That's a bit clearer, I still don't understand how such a powerful agent would be able to gain full access to Apple's cloud and not be able to maintain the same key... and besides if asymmetric keys change surely end to end encryption would simply fail? Isn't that the whole point?

Apple uses a public private key approach to E2EE.  So emulating someone is quite possible as there isn't really a signature attached to the sending message.

[Sauron]

2 hours ago, wanderingfool2 said:

Apple uses a public private key approach to E2EE.  So emulating someone is quite possible as there isn't really a signature attached to the sending message.

exactly, so I don't understand what this changes

[Paul Thexton]

3 hours ago, wanderingfool2 said:

If you specifically want to know how to access iMessages if you were law enforcement, from my theorycrafingt.  Apple internally generates a private key and public key internally when requested by law enforcement.  Apple delivers a "new" public key for Alice to Bob.  So Bob now has the "new" public key for Alice.  Bob sends a message to Alice, which goes through Apples servers.  Apple uses the private key they now have to decrypt the message, they then use Alice's actual public key to encrypt it again and send it to Alice.  So yea, at least according to their white paper, unless things have changed in how they encrypt everything I would not call it safe or secure from law enforcement as E2EE ultimately relies on the trust in Apple's servers.

 

https://web.archive.org/web/20140228173632/https://images.apple.com/iphone/business/docs/iOS_Security_Feb14.pdf

Your linked document is from 2014. Latest published info available here: https://support.apple.com/en-gb/guide/security/sec70e68c949/web

 

The sent message contains a signature from the sender. From the current document I believe it’s still possible for a MITM lawful intercept solution here, but Apple would need to modify the response to IDS queries on behalf of both sender and receiver in the conversation in order for them to unpack, send to authorities via side channel, and then repackage the message to the recipient. My current understanding is working on the assumption that it’s implemented in such a way that the software on iPhones themselves are written in a way to not be aware of what’s happening in the middle.

 

I don’t know enough about legislation (especially in the US) to pass any real comment as to whether this is something they’re required to be able to facilitate from a national security POV. But I wouldn’t be surprised if it were.

 

 

[LAwLz]

3 hours ago, wanderingfool2 said:

Yea, that maybe true, I decided to read the white paper and yea nope I would say Apple's implementation of E2EE isn't safe from spying (if legally requested).  General idea of it still not being safe is true though as well, backups imho should never have been consider to be stored in a way that allows access to the data that you claim/advertise as E2EE.   While the stats aren't really visible, I bet the vast majority essentially use the combo which makes it pretty pointless.

 

Although it is wrong to also state keys for messages in flight are bespoke to each conversation.  Messages (not long messages or photos), are encrypted using a public key which Apple holds.  That's how Apple handles E2EE, they provide the sender with a public key and the sender uses that to encrypt the message.

 

If you specifically want to know how to access iMessages if you were law enforcement, from my theorycrafingt.  Apple internally generates a private key and public key internally when requested by law enforcement.  Apple delivers a "new" public key for Alice to Bob.  So Bob now has the "new" public key for Alice.  Bob sends a message to Alice, which goes through Apples servers.  Apple uses the private key they now have to decrypt the message, they then use Alice's actual public key to encrypt it again and send it to Alice.  So yea, at least according to their white paper, unless things have changed in how they encrypt everything I would not call it safe or secure from law enforcement as E2EE ultimately relies on the trust in Apple's servers.

 

https://web.archive.org/web/20140228173632/https://images.apple.com/iphone/business/docs/iOS_Security_Feb14.pdf

It's important to note that Apple having the public key is not a security issue. In fact, the public key (which is generated by the device itself, not Apple) is suppose to be readable by everyone. You want your public key to be, well, public.

 

Your hypothetical attack is possible, but it is worth noting that it is possible in all E2EE (including apps like Signal), not just iMessage. That is why Signal has a "safety number" which you are suppose to verify through a separate channel to make sure the key matches that of the person you are messaging. This is also why Apple are launching their "Contact Key Verification" feature.

I don't have an iOS device so I don't know what iMessage looks like, but it seems like there haven't been a function to verify the key before. That's an issue, but at least Apple seems to be fixing that issue now. I think that's something they should have had day 1, but oh well.

 

 

3 hours ago, wanderingfool2 said:

If Signal created the backup software and the majority use it then yes I would say Signal isn't safe.

I think that's a very misleading way of presenting things because if you just say "iMessage isn't secure", people will inevitably think that the issue is within iMessage rather than the iCloud backup. It is far more accurate and nuanced to say "iMessage is safe, but the backup isn't (yet)". It's not really much longer to write/read so I don't see a point in not expressing it like that.

 

 

3 hours ago, wanderingfool2 said:

Apple uses a public private key approach to E2EE.  So emulating someone is quite possible as there isn't really a signature attached to the sending message.

I mean, how else would you do encryption between two participates that have never met before unless you use some public/private keypair? You pretty much have to use "a public private key approach to E2EE". Everyone does because how else do you do the key exchange?

Them using a public/private key pair (during the initial handshake I might add) is not an issue. Not allowing the users to verify the keys have (so far) been an issue however. An issue that they are going to fix now. It's something they should have done to begin with, but better late than never.

 

 

  

On 12/10/2022 at 9:22 PM, Sauron said:

Quote

And for even higher security, iMessage Contact Key Verification users can compare a Contact Verification Code in person, on FaceTime, or through another secure call.

What does this mean? Is this just a fancy way of saying "certificates"?

It's not certificates. iMessage does not use certificates. Please note that "certificates" and "public/private key pairs" are two separate things. Certificates use key pairs, but that's where the similarities end.

Apple is a bit light on the details right now, but it seems to me like it will be a way to verify the public key fingerprint of the person you are talking to, and to alert you if the changes (although I hope this is already the case in iMessage).

It will probably be a hash of the public key presented as a QR code or a string of numbers/letters.

 

 

7 hours ago, Sauron said:

How would you be able to distinguish this from the user just changing their settings? If you have access to their 2fa authentication the system must assume you're the legitimate user, there is no way of telling otherwise.

It's the "setting up the second device" step that would trigger a warning, since the new device would have a different key pair and different fingerprint.

 

 

7 hours ago, Sauron said:

well if it's like certificates you don't get to see the private key anyway, I'm just wondering whether it's meaningfully different from existing TLS encryption we already have on almost everything.

The part you quoted is most likely just about giving users a way to verify the public key in an easy way. As wanderingfool said earlier, right now it could potentially be possible for Apple to impersonate a device belonging to the recipient and as a result get a copy of messages. With this feature it will be possible to detect such an attack by contacting the recipient (through a separate channel) and say "hey, your device claims to have this public key, is that correct?".

[hishnash]

8 hours ago, Sauron said:

That's a bit clearer, I still don't understand how such a powerful agent would be able to gain full access to Apple's cloud and not be able to maintain the same key... and besides if asymmetric keys change surely end to end encryption would simply fail? Isn't that the whole point?

 

The reason is the per use keys are only ever on the users devices, when I send a message to you the key I use to sign that message is in may devices Secure Enclave it never even inters the main cpu cores let alone be sent to Apples servers.  So if you suddenly get a message from me (or try to send a message to me and I replay with a new public key you need to encrypt with your phone will detect that is not what was expected).  

 

 

8 hours ago, Sauron said:

if asymmetric keys change surely end to end encryption would simply fail? Isn't that the whole point?

This is for iMessage and with iMessage users expect to be able to have multiple devices and be able to buy new devices over time, so the protocol is designed for forward key addition. Eg if I know you have Key X then you can start to talk to me with key Y as long as key X cross signed key Y. That cross signing happens when you on-board a new device and need to confirm on an existing device you own.   And example of a state actor that might exploit this is if they have an agent temporarily steal your phone (in a coffy shop or when at the boarder) and use that opportunity to complete the 2fa attack so that they can cross sign third device to act as if you have just purchased a new phone (and authenticated it with iMessage).  

 

 

8 hours ago, Sauron said:

How would you be able to distinguish this from the user just changing their settings? If you have access to their 2fa authentication the system must assume you're the legitimate user, there is no way of telling otherwise.

Correct, however if you are in a group that is highly security aware knowing that the person you are messaging has just changed phones (or adding an addition device to the collection of devices that your phone is encrypting messages for... yes when you send an iMessage the sender encrypts the message key once for each device the recipient has cross signed). This is not about you have your phone cloned this is about the person you are messaging having thier phone cloned. 

 

[hishnash]

4 hours ago, wanderingfool2 said:

Although it is wrong to also state keys for messages in flight are bespoke to each conversation.  Messages (not long messages or photos), are encrypted using a public key which Apple holds.  That's how Apple handles E2EE, they provide the sender with a public key and the sender uses that to encrypt the message.

The white paper you are reading describes the encryption used before this update. The form of encrypting Appel did not call end to end. 

[Sauron]

58 minutes ago, LAwLz said:

The part you quoted is most likely just about giving users a way to verify the public key in an easy way. As wanderingfool said earlier, right now it could potentially be possible for Apple to impersonate a device belonging to the recipient and as a result get a copy of messages. With this feature it will be possible to detect such an attack by contacting the recipient (through a separate channel) and say "hey, your device claims to have this public key, is that correct?".

...I suppose, but it's tenuous at best - if I have your private key I need only snoop on your packets to get the contents of your messages, no extra iphone needed. It might defeat a very naive attacker that nonetheless has exceptional means. Not too likely imo. Besides if I were, say, Apple I could make another iphone with the same set of internal keys and IDs as yours, making the original recipient indistinguishable... if you assume complete access by an attacker or Apple itself to be malicious there really isn't much you can do.

 

not that it's a bad thing to have but I don't think such a formidable attack would be thwarted by something like this.

[hishnash]

1 hour ago, Sauron said:

Apple I could make another iphone with the same set of internal keys and IDs as yours, making the original recipient indistinguishable... if you assume complete access by an attacker or Apple itself to be malicious there really isn't much you can do.

 

No since the keys are derived within the Secure Enclave (not hard coded) and there is no way to extract the keys from the secure enclave (by design).  Apple could make a new chip that did allow you to extract the keys but that would not mean existing chips leak thier keys.   The type of attack apple could enable would be an OS update that hid the 2FA promt enabling someone to enrol a new device onto that users iCloud account and thus be cross signed by the existing device without user noticing.  These messages notifications would mean that a third party (who has not updated to a modified os) would be notified that the person they are talking to added a device to the conversation and they would also be able to check the device bespoke keys so that if they can have an alternative way of talking to that person they can verify that only that persons device is connected to the conversation and not a clone. 

 

1 hour ago, Sauron said:

if you assume complete access by an attacker or Apple itself to be malicious there really isn't much you can do.

Apples sec team build things to be robust even agaist attack by apple as one of the most common state level attack vectors is to try to plan an agent (or pay someone off) within a compnay who has access to things they should not so it is best to design the system from the start so that this cant happen. 

[LAwLz]

8 hours ago, Sauron said:

...I suppose, but it's tenuous at best - if I have your private key I need only snoop on your packets to get the contents of your messages, no extra iphone needed. 

This feature is for verifying the public key, not the private key. 

The private key is stored in the secure enclave and not readable by anyone, not even the OS (assuming you had root access). So the idea is that nobody can ever obtain the private key. It is unique to each device. As a result, nobody will be able to decrypt the handshake message assuming the correct key was used. 

 

 

9 hours ago, hishnash said:

The white paper you are reading describes the encryption used before this update. The form of encrypting Appel did not call end to end. 

I am pretty sure Apple did call it end to end encryption, and I would say it's an accurate term for it. 

End-to-end encryption does not mean "this encryption scheme is flawless and there are no potential attack vectors". 

E2EE implementations can be better or worse than other E2EE Implementations. Just because AES256 is stronger than AES128 does not mean the latter isn't "encryption". Likewise, just because I'd argue Signal's E2EE scheme is more secure than iMessage's, but that doesn't mean the latter isn't E2EE. 

[wanderingfool2]

I hit the next page button and quickly hit back...so I lost what I had typed out, so I'm going to site less sources and just write this quicker.

 

11 hours ago, Sauron said:

exactly, so I don't understand what this changes

They essentially have added an extra layer in that does at least some verification that the person is who they say they are (the person who sent you the message).  To send a message as lets say Alice as Bob, you don't actually need to know anything about Bob (except his ID).  Apple's system didn't really have any protocol in place to really confirm that it was "Bob" who messaged Alice.  Like they still likely would have needed to know Bob's account password, but they wouldn't need his physical phone.  With the new system they raise a warning that it's being sent from a different device (i.e. not Bob's original phone).

 

10 hours ago, Paul Thexton said:

Your linked document is from 2014. Latest published info available here: https://support.apple.com/en-gb/guide/security/sec70e68c949/web

 

The sent message contains a signature from the sender. From the current document I believe it’s still possible for a MITM lawful intercept solution here, but Apple would need to modify the response to IDS queries on behalf of both sender and receiver in the conversation in order for them to unpack, send to authorities via side channel, and then repackage the message to the recipient. My current understanding is working on the assumption that it’s implemented in such a way that the software on iPhones themselves are written in a way to not be aware of what’s happening in the middle.

 

I don’t know enough about legislation (especially in the US) to pass any real comment as to whether this is something they’re required to be able to facilitate from a national security POV. But I wouldn’t be surprised if it were.

 

 

Yea, they essentially just switched to ECS (faster algo) but nothing in terms of authentication.  In the US you have things like PRISM and similar gov't programs, so they would have to legally be required to if asked and if it was "reasonable" to implement.  Given it's just compromising a CA, it would I'd image be quite easy to implement. [The government actually compensates companies that end up having to do this, sometimes by a court order they make companies implement features like this for them to use]

 

10 hours ago, LAwLz said:

It's important to note that Apple having the public key is not a security issue. In fact, the public key (which is generated by the device itself, not Apple) is suppose to be readable by everyone. You want your public key to be, well, public.

Never said that Apple having a public key was a security issue.  What is a security issue is them being the only ones who distribute the public keys for iMessage.

 

10 hours ago, LAwLz said:

Your hypothetical attack is possible, but it is worth noting that it is possible in all E2EE (including apps like Signal), not just iMessage. That is why Signal has a "safety number" which you are suppose to verify through a separate channel to make sure the key matches that of the person you are messaging. This is also why Apple are launching their "Contact Key Verification" feature.

I don't have an iOS device so I don't know what iMessage looks like, but it seems like there haven't been a function to verify the key before. That's an issue, but at least Apple seems to be fixing that issue now. I think that's something they should have had day 1, but oh well.

Not possible on all E2EE, there are some E2EE that don't use public keys (but those are ones where it's pretty much the same owner, so the password is already a shared secret...like the now E2EE backups, those aren't vulnerable to MITM attacks...well strickly speaking Apple might be possible, but I don't think so...depends how they implemented the recover friend feature and I don't really want to go searching for a white paper that I'm sure will show Apple did it correctly).  More correct to say current E2EE messaging platforms.

 

Apple specifically advertised E2EE as a way that Apple wouldn't be able to read your messages (which unless their TOS specifically allowed them to, they wouldn't be allowed to legally anyways).  Unlike iMessage which just accepts all key changes in the background, Signal at least utilizes TOFU and notifies you when the key has changed, plus like you mentioned the safety number.  So in the case of signal if the government were to compel signal to poison their public key server, you would get a warning essentially that something has changed immediately (essentially it's the feature that Apple is now just offering as an optional thing)

 

You are right, it is something that Apple should have done from day 1 and not made it optional (then again companies implementing E2EE for messaging isn't about security in the sense of the government requesting specific requests for interception, but rather to prevent a state sponsored attack doing something like factoring their RSA key for billions of dollars and then using that to decrypt the traffic...E2EE makes it too costly to do so, as each person is unique now)

 

10 hours ago, LAwLz said:

I mean, how else would you do encryption between two participates that have never met before unless you use some public/private keypair? You pretty much have to use "a public private key approach to E2EE". Everyone does because how else do you do the key exchange?

Them using a public/private key pair (during the initial handshake I might add) is not an issue. Not allowing the users to verify the keys have (so far) been an issue however. An issue that they are going to fix now. It's something they should have done to begin with, but better late than never.

Emulating a current contact I should say.  Since the whole thing Sauron was talking about was it occurring when the contacts had already been communicating.  "Better late than never"...except they are making it an optional choice for all the features that should already be in place.

 

10 hours ago, LAwLz said:

Apple is a bit light on the details right now, but it seems to me like it will be a way to verify the public key fingerprint of the person you are talking to, and to alert you if the changes (although I hope this is already the case in iMessage).

It will probably be a hash of the public key presented as a QR code or a string of numbers/letters.

Yea, I agree with this.  At least on the screenshot it is similar to what Signal does.

 

9 hours ago, hishnash said:

The white paper you are reading describes the encryption used before this update. The form of encrypting Appel did not call end to end. 

Apple has actively advertised it as end to end encryption for quite some time now.  They advertised it as not being able to read your messages.  I had a link to another archive.org from a while back where they state it on their site...but I lost my post and don't care to search for the link anymore

[hishnash]

6 hours ago, wanderingfool2 said:

Apple has actively advertised it as end to end encryption for quite some time now.

Apple have advertised that some data is end to end encrypted. Not all.  Data such as key chain data. And ad it says in that document key keys used for encrypted this data (end to end encrypted data) are not stored on apples servers they are true end to end.  

iCloud backup, photos etc were not end to end encrypted when that document was written so yes while it was encrypted the keys were stored on apples servers so that when a user losses access to thier last device they were able to still get back their old photos.   If you want to look at the end to end schema Appel are using you need to look at the system used for key-chain and Apple health this is what they have been calling end to end. 

[wanderingfool2]

2 hours ago, hishnash said:

Apple have advertised that some data is end to end encrypted. Not all.  Data such as key chain data. And ad it says in that document key keys used for encrypted this data (end to end encrypted data) are not stored on apples servers they are true end to end.  

Please use context.  The conversation where you originally quoted and said "Apple did not call end to end" was talking about iMessage, which yes they did call it end to end encryption and actively advertised it as such.

 

To use the excuse that the keys were never stored on Apples servers as Apple being technically correct I think is a bit of a cheat really.  If you advertise something as E2EE and stage that it prevents Apple from reading your messages in transit...and yet they can read your messages if they so chose to (and could read your prior messages if you chose to backup with iCloud).  It would be different if Apple said that they just supported E2EE, or if they put in a measure in place when it was introduced like they are now where it warns you when it changed.

 

Really in this case the difference between E2EE and the regular system they had before is that it requires more work in the Apple servers were fully compromised to read your messages...but that realistically wasn't going to happen.