As I understand iMessage, when you attempt to text a number a background thread fires and checks with Apple's iMessage servers to see whether or not the number is associated with an iMessage account, then returns the end-user account details to your device so it may send a digital message addressed to that user to Apple's iMessage servers.
Replace that digital ID with a public key. Private keys are generated and kept only on your iDevice. iMessage servers are your CA. Each iDevice has a unique public key.
At this point you have a very secure, end-to-end encryption scheme. No warrantless snooping is possible, and even Apple is unaware of your message contents.
Now depending on whether you want your design to be CALEA-compatible or not, Apple can issue a new private key to the government and add it to "your" list of public keys on their CA to allow the government to intercept future messages after they have obtained a warrant. If you think you can go toe-to-toe with the FBI and exempt yourself from CALEA by claiming the design of your infrastructure does not permit for message interception, you can tweak the CA around a bit. Only one public key per user, pass private key symmetrically encrypted with a password only the user knows from one device to the other via a "secure" side channel when adding new iDevice to user's iMessage account or other workaround.
I'm absolutely not a security person, and none of what I say should be taken except as some ramblings that might have some hint of an idea beneath them. I already can think of a dozen weaknesses in this system, this kinda works only if you assume you can trust Apple to play within the rules of the framework they're making, i.e. not to try to intercept your private key, log your keystrokes, automatically add a second public key recipient to your messages, etc. Fact of the matter is, you are at their mercy. tptacek, please be gentle in gutting me.
Edit: Thanks for that link, daniel. It is comforting to know that there is indeed some base level of security. If CALEA-compliance is achieved by adding the fed's public key to a list of destination public keys for a message, that implies you should actually be able to find out whether or not you're being monitored by simply checking for new/unknown/unexpected additions to your list of public keys. Of course, there are other methods of doing this that wouldn't be as easy to detect, e.g. maybe there is an out-of-band request for additional public keys to send to, maybe the fed's public key is already embedded in the device and is being used invisibly every time, etc. etc. etc.
Edit2: For people wondering if syncing of old iMessages between devices means iMessage doesn't work like this, I don't think that's the case. I believe that's done via iCloud (i.e. backup of previously decrypted messages), as when you add a new Apple ID to iMessages on OS X, you don't get the old messages for that account, only new ones. So it's another attack vector, but not inherent weakness in the iMessage design.
Source? How can I add a new device (e.g. Messages on OSX) and get all the messages between my phone and friends?
The protocol hasn't been completely reverse engineered but enough to know it's likely decentralized like this, just MITM it (quite a bit is documented on the wiki I linked), Apple is the CA and the piping but it appears to be rather strong and decentralized in terms of chain-of-trust. Apple has put itself, probably without coincidence, in a position where they may not even be able to execute a court order to spy on a user.
The Apple security white-papers detail their hardware level certificates, I've dealt with this a lot as a Apple MDM developer.
When I have A, and want to add B, A ships its private key to B so it can decrypt the messages too? (and vise versa, obviously)
Or does A get B's public key, and A then re-encrypts and re-sends messages it receives to B?
Or is it something completely different?
Someone who actually knows should weigh in, though. GP's understanding seems a bit murky to me.
When someone sends me an iMessage, their client sends as many copies as I have devices?
Generally how this works is that the sender encrypts the message with a symmetric encryption algorithm (like AES) and then encrypts the randomly-generated AES key with RSA with each of the receivers' private keys. So you only send out a single message, but it can be decrypted by any of the intended recipients.
WINDMILLS DO NOT WORK THAT WAY.
I have a feeling they could manage.
I really had thought, that this would have happened long ago, for everybody, and so on. Would not have thought, that this was a problem for law enforcement, as it was with i.e. skype.
Nobody iMessaging me gets any indication when I get a new iPad and add it to my account, despite all their messages to me now encrypting (on their device) to n+1 of my devices now.
You can find more info here. Encryption and Data Protection section should be a good place to start.
The choice is odd because the FCC deregulated the internet to make ISPs "information services" not "common carriers". So there is precedent for expansion that makes no logical sense.