Daniel Hruska Sending messages via iMessage is a popular way to communicate between iOS devices and Mac computers. Tens of millions of messages are processed by Apple's servers daily, and as sales of Apple-bitten devices grow, so does the popularity of iMessage. But have you ever thought about how your messages are protected from potential attackers?
Apple recently released dokument describing iOS security. It nicely describes the security mechanisms used in iOS - system, data encryption and protection, application security, network communication, Internet services and device security. If you understand a bit about security and don't have a problem with English, you can find iMessage on page number 20. If not, I will try to describe the principle of iMessage security as clearly as possible.
The basis of sending messages is their encryption. For laymen, this is often associated with a procedure where you encrypt the message with a key and the recipient decrypts it with this key. Such a key is called symmetric. The critical point in this process is handing over the key to the recipient. If an attacker got hold of it, they could simply decrypt your messages and impersonate the recipient. To simplify, imagine a box with a lock, in which only one key fits, and with this key you can insert and remove the contents of the box.
Fortunately, there is asymmetric cryptography using two keys - public and private. The principle is that everyone can know your public key, of course only you know your private key. If someone wants to send you a message, they will encrypt it with your public key. The encrypted message can then only be decrypted with your private key. If you imagine a mailbox again in a simplified way, then this time it will have two locks. With the public key, anyone can unlock it to insert content, but only you with your private key can select it. To be sure, I will add that a message encrypted with a public key cannot be decrypted with this public key.
How security works in iMessage:
- When iMessage is activated, two key pairs are generated on the device - 1280b RSA to encrypt the data and 256b ECDSA to verify that the data has not been tampered with along the way.
- The two public keys are sent to Apple's Directory Service (IDS). Of course, the two private keys remain stored only on the device.
- In IDS, public keys are associated with your phone number, email, and device address in the Apple Push Notification service (APN).
- If someone wants to message you, their device will find out your public key (or multiple public keys if using iMessage on multiple devices) and the APN addresses of your devices in IDS.
- He encrypts the message using 128b AES and signs it with his private key. If the message is to reach you on multiple devices, the message is stored and encrypted on Apple's servers separately for each of them.
- Some data, such as timestamps, are not encrypted at all.
- All communication is done over TLS.
- Longer messages and attachments are encrypted with a random key on iCloud. Each such object has its own URI (address for something on the server).
- Once the message is delivered to all your devices, it is deleted. If it is not delivered to at least one of your devices, it is left on the servers for 7 days and then deleted.
This description may seem complicated to you, but if you look at the picture above, you will surely understand the principle. The advantage of such a security system is that it can only be attacked from the outside by brute force. Well, for now, because attackers are getting smarter.
The potential threat lies with Apple itself. This is because he manages the entire infrastructure of keys, so in theory he could assign another device (another pair of public and private key) to your account, for example due to a court order, in which incoming messages could be decrypted. However, here Apple has said that it does not and will not do any such thing.
And before whom is it encrypted? Would normal SSL not be enough, the message is sent to apple and apple then dispatches the message again via SSL? Apple has the power to eavesdrop on messages anyway, so why all the noise around it? In any case, it's just a matter of preventing a third party from eavesdropping on the message, and SSL is enough for that.
If we believe that Apple doesn't send private keys, then he won't read them either. And anyway, SSL is just an implementation of asymmetric encryption on the client-server connection.
So we send the message 2x encrypted over SSL and Apple can read it, or 2x unencrypted with the fact that we request the public keys beforehand and use the same cipher as in the case of SSL and Apple can't read them in theory.
And why have the data encrypted even at Apple? Because some employee will definitely have access to them. He's been cheated on by his girlfriend, so he starts downloading her messages - it leaks and Apple is in trouble.
Funny shout..