> Do you have any encryption keys that you share between devices? Or you just enter login/password on a new device and voilà all your messages are displayed to you?
You should really look more into the iMessage encryption scheme before attempting to fear-monger about it. The approach it uses to multi-device encryption is well known[1][2], and is basically its entire innovation over other clients—an approach that every other piece of E2E-encrypted chat software has been encouraged heavily to copy, but for some reason none yet have. (WhatsApp specifically is often ridiculed for its requirement to route all your messages through a "primary device", which feels like going back in time after experiencing iMessage's approach.)
To save you the trouble of looking it up: you don't "log into iMessage." There's no such thing as a central "iMessage account." Instead, in iMessage, your devices synchronize state with one-another by participating in an ad-hoc group based on a shared "key bag" of all your devices' private iMessage signing keys.
When you get a new device and want to join it to this existing group, it sends out a signed request on an announce channel corresponding to your iCloud identity, requesting that another device in the group "invite" it to the group. From the user's perspective, this appears as their new device telling them that the iMessage sign-on needs to be confirmed on an existing device; and a modal popping up on all their existing devices, asking whether they want to accept the new device's join request.
If the user confirms the join request, then the existing device the user confirmed on will take its own iMessage keybag, encrypt it with the new device's public key, and send it to the new device. This will then allow the new device to securely "introduce itself" to the rest of the group.
Throughout this process, no key material ever travels unencrypted through Apple's servers. Apple can't recover your iMessage keys; nor are Apple's servers an implicit "participant" of your iMessage sync group. iMessage's cloud backend is, during this pairing process, just a dumb message-queue system between your client devices, one that sees only opaque encrypted messages.
(Note that this also means that it's totally possible to get "locked out of" your iMessage sync-group if you lose access to all your existing devices. This is usually fine, because 1. iMessage clients won't sync history from before a new device joined the group with that new device, so you're not losing access to anything you had any potential to recover anyway; and 2. you can make a new sync-group under an existing iCloud identity/phone number/IMEI/etc., because none of those visible identifiers are the primary key of the sync-group. The sync group has no primary key. It's not a central "entity" with an identifier. It's a mesh, that happens to be reachable through identifiers it registers to—sort of like softphone apps registering a DID number. But those actively-registered aliases aren't a means of security, nor recovery.)
> Last time I checked, iMessage apps source code was not available
People interested in messaging security don't tend to trust source code even if it is available. Unless the build process is deterministic and replicable by the researcher themselves—to produce exactly the artifact distributed by the store—then who knows what of the published source actually makes it into the published binary, and/or what-all else ends up in there as well. (Would you trust Chrome [the binary] just because Chromium is open-source? Would you trust macOS [the binary distribution] just because the XNU kernel and BSD userland are open-source?)
Instead, security researchers dump packet captures and analyze them.
And, in this case, those packet dumps reveal that iMessage does... exactly what is stated above.
Ok it's a good wall of text. Apple does copy keys from one device to another. Let's trust (again) that they absolutely have no mechanism to intercept your password and do whatever they want with your data.
Just a simple question. How do you know that when you connect to me over iMessage using state-of-the-art / end-to-end-encryption / made-from-carbon-free-alumeenium (sorry for that one), there is no man in the middle?
With this architecture without visible fingerprints, installing a MitM proxy that would relay data between two separate e2ee chats is not a problem at all:
You <-- e2ee chat --> MitM proxy <-- e2ee chat --> Me
UPD: ok, I get it that you downvoters don't have an answer to simple question and are just disturbed about the fact that security that was promised to you turned out to be just a security theater.
> Apple does copy keys from one device to another.
No, iMessage does that. That's no more "Apple" doing that, than the functioning of a copy of gpg that you installed from Ubuntu's apt repo would be the GNU Foundation or Canonical Inc. "doing that." The client is in ultimate control. Someone wrote that program, but now you have it, and you get to say what it does or doesn't do (if by nothing else than by choosing whether to run it.) The iMessage servers can't make the client do something that's not part of its executable.
You downloaded, and now have, the software—a collection of bits with a fixed function—on your device. You can do what you like to verify those bits, and then either trust them, or not; but either way they're not going to suddenly change out from under you without your consent (which you might supply implicitly by turning on auto-update, but you don't have to do that either.)
When entities like the US Navy use cryptosystems like Tor, they're not blindly installing it from the web, trusting the theoretical guarantees it makes; they're ensuring security in practice by isolating a specific version-under-test, static- and runtime-analyzing the binary to ensure it meets their needs, and then declaring that exact binary good and trustworthy, and giving operatives simple tools to acquire and validate that exact binary.
If you're paranoid, you do nothing less. But nothing about getting iMessage as part of your iPhone's OS stops you from doing any of that. You just take apart the IPSW it ships in, and throw it iMessage.ipa into Ghidra. Once you've verified it, you can say "the version of iMessage that ships in iOS with hash 0xXYZ, is known-good, and can be used for low-security comms."
> Let's trust (again) that they absolutely have no mechanism to intercept your password and do whatever they want with your data.
No, let's trust-but-verify that the binaries are E2E-encrypting the key-sharing process. Then there cannot be a man in the middle.
Also, as I said previously, you never "log into" iMessage, and so you don't have an iMessage "password" per se. iMessage uses your iCloud username to discover the device-group to attempt to join, but it doesn't use your iCloud account to authenticate to that group in any way. Instead, you're basically doing a https://en.wikipedia.org/wiki/Key_signing_party with yourself, manually pairing your devices with each-other through challenge-response. (This turns out to actually be a convenient kind of key-signing party—and so probably the only time key-signing parties are relevant in practice.)
In the design of the iMessage key-sharing process, the iMessage servers could be replaced with an ephemeral channel on a public IRC server, and the semantics—including the security guarantees—would remain the same. The servers only see—and pass along—opaque, encrypted blobs.
> How do you know that when you connect to me over iMessage using state-of-the-art / end-to-end-encryption / made-from-carbon-free-alumeenium (sorry for that one), there is no man in the middle?
You're moving the goalposts; intra-account multi-device key sharing, and inter-account key exchange, are separate concerns.
What you are asking about is the Fundamental Problem of Key Exchange. And the answers are as they have always been: you either do a key-signing party; or you choose a Central Authority to trust to act as a directory mapping identities to public keys (and then maybe use that key to do a challenge-response identification process with out-of-band signaling elements.)
iMessage solves key sharing better than other messaging services. Nothing[1] really "solves" key exchange any better than anything else.
[1] Except maybe Keybase, but Keybase's unique shape—an identity-aggregating service—is a necessary element of that solution. No chat service can do what Keybase does without getting into the business that Keybase is in.
Actually, I'm not. See the post above, you claimed "BlackBerry always retained the capability to read your message traffic. Apple does not." [1], and I was responding to just that: Apple can read your message traffic. You yourself have proved it in the above reply: iMessage neither allows key-signing (nor even key verification, I must add!), and the Central Authority iMessage users have to trust are Apple themselves. It also has supreme control over all updates that are shipped to your phone, so even if someone does decompile and verify his build of iMessage, it doesn't mean that the targeted user was shipped the same version at all. So let's agree to put to rest your claim that Apple can't read your messages, OK? (note, I don't claim that it does, just that it can)
Now, being NOT paranoid, I'm actually not angry at it, not in the slightest. The downsides of a real privacy and security have a very serious and negative impact on user experience, so for most users the simple capability to sync all their messages from a central server (like Telegram does, "the most secure messenger", hahaha) far outweighs the dangers of being spied upon.
What irks me is the sheepish trust that people place on people who promise them "don't worry, you are super safe, without any downsides of real security, and people buy into it. The prime offender, of course, is Telegram, where users rarely, if ever, use the "Secret chats", but still think that they have the most protected messenger. Not concerning themselves that the features they like most (capability to access from the web, instant sync of messages on any device) comes from it being the least protected of any major messenger.
You should really look more into the iMessage encryption scheme before attempting to fear-monger about it. The approach it uses to multi-device encryption is well known[1][2], and is basically its entire innovation over other clients—an approach that every other piece of E2E-encrypted chat software has been encouraged heavily to copy, but for some reason none yet have. (WhatsApp specifically is often ridiculed for its requirement to route all your messages through a "primary device", which feels like going back in time after experiencing iMessage's approach.)
[1] https://support.apple.com/en-ca/guide/security/secd9764312f/...
[2] https://support.apple.com/en-ca/guide/security/sec70e68c949/...
To save you the trouble of looking it up: you don't "log into iMessage." There's no such thing as a central "iMessage account." Instead, in iMessage, your devices synchronize state with one-another by participating in an ad-hoc group based on a shared "key bag" of all your devices' private iMessage signing keys.
When you get a new device and want to join it to this existing group, it sends out a signed request on an announce channel corresponding to your iCloud identity, requesting that another device in the group "invite" it to the group. From the user's perspective, this appears as their new device telling them that the iMessage sign-on needs to be confirmed on an existing device; and a modal popping up on all their existing devices, asking whether they want to accept the new device's join request.
If the user confirms the join request, then the existing device the user confirmed on will take its own iMessage keybag, encrypt it with the new device's public key, and send it to the new device. This will then allow the new device to securely "introduce itself" to the rest of the group.
Throughout this process, no key material ever travels unencrypted through Apple's servers. Apple can't recover your iMessage keys; nor are Apple's servers an implicit "participant" of your iMessage sync group. iMessage's cloud backend is, during this pairing process, just a dumb message-queue system between your client devices, one that sees only opaque encrypted messages.
(Note that this also means that it's totally possible to get "locked out of" your iMessage sync-group if you lose access to all your existing devices. This is usually fine, because 1. iMessage clients won't sync history from before a new device joined the group with that new device, so you're not losing access to anything you had any potential to recover anyway; and 2. you can make a new sync-group under an existing iCloud identity/phone number/IMEI/etc., because none of those visible identifiers are the primary key of the sync-group. The sync group has no primary key. It's not a central "entity" with an identifier. It's a mesh, that happens to be reachable through identifiers it registers to—sort of like softphone apps registering a DID number. But those actively-registered aliases aren't a means of security, nor recovery.)
> Last time I checked, iMessage apps source code was not available
People interested in messaging security don't tend to trust source code even if it is available. Unless the build process is deterministic and replicable by the researcher themselves—to produce exactly the artifact distributed by the store—then who knows what of the published source actually makes it into the published binary, and/or what-all else ends up in there as well. (Would you trust Chrome [the binary] just because Chromium is open-source? Would you trust macOS [the binary distribution] just because the XNU kernel and BSD userland are open-source?)
Instead, security researchers dump packet captures and analyze them.
And, in this case, those packet dumps reveal that iMessage does... exactly what is stated above.