Of course, if the software is not open source, that's hard to police. But abstracting away the key generation from the user doesn't mean that the services can read your messages.
https://support.apple.com/guide/security/imessage-security-o...
This is about to change with contact key verification and transparency, though.
A BIG part of successful encryption is key exchange.
A successful SSL/TLS man-in-the-middle attack exchanges false asymmetric keys.
They keys are still generated and kept using software they wrote.
Second, they also control who they trade the keys between.
This is contrasted to some chat apps (which are painful asf to use) where you have to manually exchange keys, meaning you have to engage with the party you want to talk to and so you can confirm who you are really encrypting messages for. It’s physically impossible to be given the wrong person’s key because you personally had to get them.
This is a prerequisite for forward secrecy, which is arguably much more relevant.
> It’s physically impossible to be given the wrong person’s key because you personally had to get them.
Does that matter at all if the (in your threat model non-trustworthy) software just exfiltrates all messages?
If you don't trust your encryption software, it's game over (unless it encrypts everything fully deterministically and you regularly audit its outputs).
Some people said they are finally adding key transparency features to let you do that, but it should have been there since the start. Something a lot of people already use called SSH literally has had that since forever. It’s like basic 101 cryptography if you design an encrypted protocol that isn’t using a trusted third party for key verification (like certificate authorities in TLS/SSL).
If you implement ANY encrypted protocol, key verification is extremely important. If you aren’t verifying keys are possessed only by your recipient, you cannot verify who can read your message.
> It’s like basic 101 cryptography if you design an encrypted protocol that isn’t using a trusted third party for key verification (like certificate authorities in TLS/SSL).
SSH/TOFU is one model, PKI is another. Both have their respective merits, especially when combining PKI with certificate transparency.
[1] https://security.apple.com/blog/imessage-contact-key-verific...
[2] https://engineering.fb.com/2023/04/13/security/whatsapp-key-...
Even with that, there are still two concerns:
- Compromised clients: either malicious updates or buggy code.
- Security design issues: for example, if iCloud can just surreptitiously add keys to your account, it can trivially make the security moot. (I am aware this is currently an issue, though apparently it is finally going to be resolved somehow.) At least this one is tamper-evident though.
I hope I'm not misrepresenting reality here. Either way, software with reasonably strong E2EE guarantees that still has decent user experience is more possible than it ever has been. The last remaining problem is account recovery, and Apple has a bit of a leg up on this one since a lot of Apple users will have multiple devices that they can use as a backup, even if they lose a device and forget their password simultaneously.
- To ensure that you message is unreadable, you must correctly encrypt the data symmetrically or asymmetrically with a key. Well we can assume Apple or Meta can do this properly.
- Second, as the sender or recipient, you MUST verify the authenticity of the key, whether you are using asymmetric or symmetric encryption.
In TLS/SSL, key verification is handled by third parties called certificate authorities.
In SSH, key verification is handled by comparing the key signature that the SSH client displays.
Most of these services right now do not do either (trusted third party or display of a key), therefore it cannot be verified overall. (That said, some people said they are doing what SSH is doing soon.)
I’m happy Apple is doing those things to exchange your own key between your own devices. This is already way better than most services. However, that problem is orthogonal to the problem of key exchange between you and a recipient.
This is because encryption needs keys, but when you talk to your friend over these services, under no point did you personally exchange any keys. This means that you’ve decided to let the service generate and keep the keys for you.
It’s like getting a deposit box at the bank but instead of keeping your key, you give your key to the bank to keep.
What would stop the bank from opening your box would be its own ethics policy and the quality and depth of their internal processes. They are not physically prevented from bypassing them however.
It’s still a W with these rudimentary E2E chat implementations because your ISP and government might find it a lot more difficult to read but it’s not quite exactly super strong security.