Continuing the discussion from Apple advances user security with powerful new data protections:
The latest iOS 17.2 update arrived this week, bringing Contact Key Verification to the public. This feature, announced a year ago, promises to drastically improve the security of your iMessages through two technologies: Key Transparency, and Contact Key Verification. In this post I’ll talk about why this added security matters, what these two new features actually do, and how you can opt in to higher levels of security in iMessage on your phone right now.
How End-to-End Encryption Works in iMessage
Securing messages in apps like iMessage (which use end-to-end encryption) involves “public key cryptography” - Basically, let’s say you’re messaging your friend Alice. Alice has two keys: one public key and one private key. But you can think of the public key more of a lockbox that you can put a message in, and the only way to open that lockbox and read the message is to use the private key to “open” or decrypt it.
How this generally works is: Alice gives you herpublic key, and you use it to encrypt a message one-way before you send the message back to her. She can then use her separate private key on her device to decrypt that message and read it, and she’ll be the only person who can ever read that message.
This is all well and good, until you consider… how do you get Alice’s public key in the first place?
Some applications take a “peer to peer” approach, where you ask Alice’s device to send you her public key directly. This works well, if Alice and everybody else you message has a device that is always online all the time. But if the other person’s device is off, or in airplane mode, or otherwise disconnected from the internet - this approach doesn’t work super well!
This is why many messengers, including Signal, Google RCS, WhatsApp, and yes, iMessage, take a different approach to exchanging these keys. They use a central key server which distributes keys on everyone’s behalf. Now instead of asking your friend Alice for her public key directly, your phone asks Apple what Alice’s public key is, and Apple responds with Alice’s public key.
On its face, this isn’t a direct threat to your encryption. It doesn’t matter if Apple knows Alice’s public key, because the public key can’t be used to decrypt messages sent to Alice at all: it’s public.
However, this is still a position of power Apple has placed themselves in. The most notable threat is the possibility of Apple including additional public keys in their response, perhaps ones under Apple’s or someone else’s control rather than only your friend Alice’s. Then when you send messages to Alice in the future after receiving that malicious response, your friend Alice isn’t the only person who can decrypt that message anymore, maybe Apple or someone else can too!
This threat is exactly what key verification in iMessage is aiming to address.
Key Transparency
The first way Apple tries to solve this problem is through a technology called Key Transparency.
The way this works is similar to Certificate Transparency, a technology already in widespread use for auditing security certificates in web browsers. The short explanation of Key Transparency is that Apple has created a verifiable ledger of public keys which new data can only be appended to, but the existing data in the ledger can never be modified. This means that Apple can’t sneakily add fake public keys for a person to that ledger, and then later remove them before anyone notices.
When you enable Contact Key Verification in the Apple ID settings on your device, and then send a message to your friend Alice, your phone will locally compare Alice’s public keys which it receives from Apple’s key exchange server with what the public Key Transparency ledger says that Alice’s public keys should be. This comparison ensures that the keys that Apple’s key exchange server sends you are no different than what they’re sending to everybody else.
Additionally, your phone will routinely monitor or audit that universal Key Transparency ledger for what it says about your own keys, to make sure that ledger only has the public keys your device expects it to have.
Contact Key Verification
This automatic key verification through Key Transparency is a huge security improvement, but Apple is also releasing a second mechanism which provides even higher assurance than that. Manual contact key verification is this second mechanism, and it’s something that users of high-security messaging apps like Signal and Element are probably already familiar with.
In this system, you now have the ability to manually compare verification codes with the person you’re communicating with, cutting Apple’s servers, including the key transparency ledger, out of the verification process entirely.
To do this, you can open the contact’s profile in iMessage and it will display an 8-digit authentication code under the Advanced Message Security section which you can compare in person, over the phone, or via any other out of band communication method you’d like. This code acts as sort of a unique identifier of the public key for that person, and when you mark it as verified a hash of that person’s public key is linked to your friend’s contact card on your device.
If Apple’s key exchange server ever sends you a different public key in the future or the key changes from what’s stored in your friend’s contact card for any other reason, iMessage displays an error directly in the conversation transcript for you to investigate further.
Enabling Key Verification in iMessage
To take advantage of these security features with your contacts, both of you will have to open your Apple ID settings in the Settings app and enable Verification in iMessage under the Contact Key Verification section. I definitely recommend you do so immediately, and spread the word about this change as well. It adds a layer of security to your conversations with essentially no downside, so it’s a no brainer for anyone using this service.
This is a repost from my blog at jonaharagon.substack.com, which I didn’t think was a right fit for the Privacy Guides blog (as it’s not really an added privacy feature), but might be of interest to forum users given this topic being previously discussed.
