Apple’s iMessage was the first widely available messaging service to provide secure end-to-end encryption by default, starting from when it launched in 2011. As security threats have evolved, we’ve continued to strengthen iMessage by upgrading the protocol with stronger cryptographic primitives and adding more robust key management that takes advantage of hardware protections offered by the Secure Enclave. In iOS 14, we added BlastDoor, an advanced sandboxing mechanism that makes it vastly more difficult to attack the device with malicious content in the Messages app. And in iOS 16 we introduced Lockdown Mode, a groundbreaking protection for the very small number of users who face grave, targeted threats to their digital security — and which includes powerful additional security hardening in the Messages app when enabled. Today, we’d like to share an overview of our next significant advance in iMessage security: Contact Key Verification, a new feature that’s designed to detect sophisticated attacks against iMessage servers and allow users to verify that they’re messaging only with whom they intend.
iMessage uses end-to-end encryption to ensure that only the sender and recipient of a message can read it. To achieve this strong security property, each device in a user’s iMessage account generates its own set of encryption keys, and the private keys are never exported to any external system. Typically, the provider of an end-to-end encrypted messaging service operates a key directory service, which maps a user’s identifier — such as an email address or phone number — to public keys for each of their registered devices. When Alice wants to send Bob a message, Alice’s device contacts the key directory service and requests the list of public keys for Bob’s devices. Alice’s device can then start an encrypted conversation using the encryption keys it received for Bob and send him a message using the transport specified by the protocol.
While a key directory service like Apple’s Identity Directory Service (IDS) addresses key discovery, it is a single point of failure in the security model. If a powerful adversary were to compromise a key directory service, the service could start returning compromised keys — public keys for which the adversary controls the private keys — which would allow the adversary to intercept or passively monitor encrypted messages.
Some messaging systems try to address this issue with an out-of-band, peer-to-peer verification step, where two users can verify each other’s encryption keys using long verification numbers or QR codes. This solution is useful to confirm that the key directory service returned the correct public keys for a user’s specific set of devices at a particular point in time. However, since every device generates and stores its own keys, signing in to a messaging service on a new device generates a brand new key; users who rely on manual key verification would then have to re-verify keys in every conversation to confirm their conversations are secure, which is a challenging user experience that doesn’t scale. The Signal messaging service, for example, includes the ability to transfer an account to a new device in a way that avoids the need for manual key re-verification, but if Alice signs in to a new device without using this mechanism, the participants in all of her conversations are warned that their “safety number with Alice has changed,” even if they had never manually verified that safety number with Alice.
To both secure the key discovery protocol and provide a great user experience in iMessage, we started with a set of strong requirements:
- Secure a source of truth for key material and metadata in a way that cannot be altered by unauthorized entities, including the key directory service operator.
- Automatically verify the key material and metadata presented by the key directory service against this source of truth.
- Synchronize the source of truth across all current and future devices authorized by a user for their account.
- Detect split views between what the key directory service presents for a user’s own identifiers and what it presents to peers (other conversation participants) for that user.
- Scale to billions of users and all of their conversations, including one-to-one discussions and group chats.
- Notify users only when an unexpected security condition occurs. Warnings must be rare and accurate, rather than the system relying on the user to notice ongoing positive indicators of security.
Key Transparency
Our solution to this problem is iMessage Contact Key Verification, using a mechanism called Key Transparency (KT). KT builds on the ideas of Certificate Transparency but uses a verifiable log-backed map data structure, which can provide cryptographic proofs of inclusion and be audited for consistency over time. These properties allow for higher scalability and better user privacy.
WhatsApp recently took a great step forward in this area as the first to deploy a KT system for messaging called Auditable Key Directory (AKD). This system significantly improves scalability of the relevant data structures by batching map revisions as the key directory service inserts identifiers and keys. It also employs Verifiable Random Functions to prevent auditors from recognizing user identifiers. Using proofs from AKD, devices verify that the keys received from the key directory service are included in the map. External parties can audit the correct operation of AKD using consistency proofs provided by the service.
iMessage Contact Key Verification advances the state of the art of Key Transparency deployments by having user devices themselves verify consistency proofs and ensure consistency of the KT system across all user devices for an account. These improvements protect against key directory compromise as well as compromise of the transparency service itself, and can detect split views presented by both services. Apple’s transparency service uses the verifiable, log-backed map data structure described in CONIKS. To maintain user privacy, this sparse map is indexed with a SHA-256 hash of the output of a Verifiable Random Function (VRF) for an iMessage identifier — similar to WhatsApp’s AKD. The map is highly performant and generally merges any changes within minutes. But Apple’s transparency service sets a new bar by producing Signed Mutation Timestamps (SMTs), which are auditable promises to make changes to the map. SMTs make device keys immediately verifiable, thereby maintaining the instant usability of iMessage.
Automatic verification
iMessage Contact Key Verification augments the existing IDS protocol with an account-level ECDSA signing key that is generated on the user’s device and stored in iCloud Keychain. Since iCloud Keychain is itself end-to-end encrypted, this key is available only to the user on their trusted devices. Each device uses the synchronized account key to sign its iMessage public keys. The account keys and signatures are included in the IDS service database along with the existing data. Additionally, when a user opts in to — or out of — Contact Key Verification, the opt-in state is added to the user’s IDS entry. During the sign-in flow, the IDS service sends all this data to the Key Transparency service to merge into the KT maps.
When a user enables iMessage Contact Key Verification, their devices automatically and cryptographically verify that the data presented by IDS is included in the KT map. When Alice messages Bob, her device queries the KT service and verifies the response that it receives from the IDS service for Bob. If Alice’s device detects a validation error, and both she and Bob have enabled iMessage Contact Key Verification, Alice is notified about the error directly in the Messages conversation transcript.
This automatic protection extends to Alice’s own devices. Periodically, every one of her devices will query IDS for her own account information, verify the response against the KT service, and notify Alice of any inconsistencies. Alice’s devices will additionally compare the KT data for her identifiers, device records, and opt-in state against records stored in an end-to-end encrypted CloudKit container. This database is maintained by Alice’s devices and is not readable or modifiable by Apple. The combination of the KT service’s data structure and the end-to-end encrypted database prevents IDS from presenting different data about Alice’s devices to Alice than it presents to Bob’s devices. Alice is notified about any self-verification failures with a notification, a badged Settings app icon, and an explanation of the error in the Contact Key Verification pane of Apple ID settings.
iMessage Contact Key Verification includes several important protections unique to our implementation of Key Transparency. In addition to verifying inclusion proofs, the Messages app verifies that SMTs are merged to the map within a 48-hour Maximum Merge Delay — similar to SCT auditing in Certificate Transparency (CT), but performed on-device instead of remotely. While CT deployments and WhatsApp’s KT deployment rely on third-parties to verify consistency of all the data structures, the Messages app directly verifies the consistency of critical append-only logs in Apple’s KT system — right on the user’s device. To detect split-view attacks by an attacker who may have compromised the KT service, Messages also gossips log hashes — by including them in the encrypted part of a small percentage of messages — with other iMessage clients and verifies the consistency of log hashes received via gossip.
Even with gossip and device consistency verification, there remains a set of consistency issues that can be detected only by third-party auditors. Certificate Transparency has demonstrated the importance of this type of auditing ecosystem, but our key transparency deployment is drastically larger. The largest CT logs have had approximately two billion entries over the last four years (Google’s Xenon 2023), while Apple’s Key Transparency log receives more than two billion entries per week. As we work to achieve operational maturity and resolve bugs at this tremendous scale, we will be launching Key Transparency with an internal auditing service across our production KT trees. We plan to share more details about our public auditing strategy in 2024.
Contact verification
In addition to advancing the state of the art on automatic key validation, iMessage Contact Key Verification also advances the ability to manually compare contact verification codes for users who need that level of assurance, by extending the verification to cover future signed-in devices. Using the Vaudenay SAS protocol, users can compare short codes to verify that they have the same view of each other’s account key as presented by the IDS service. When the user marks the code as verified, the hash of the peer’s account key is saved to an end-to-end encrypted CloudKit container and linked to the peer’s contact card. If the account key ever changes — for instance, if the iMessage identifier moves to another account entirely — Messages displays an error in the conversation transcript.
Because the user’s account key and the verified hashes for their contacts are synced via end-to-end encrypted mechanisms, this verification remains consistent across all of the user’s devices, including when they sign in on a new device. And because the contact card is linked, all conversations with the peer’s identifiers — phone number and email address — are marked as verified. Group chats with peers that have been independently verified one-to-one are also automatically marked as verified.
For users with a public persona, a public verification code encoding the account key hash is available in the Contact Key Verification pane in Apple ID settings. Users can insert these public verification codes into a contact card to ensure that they are communicating with the posted account key from the very first message.
iMessage Contact Key Verification is available in the developer previews of iOS 17.2, macOS 14.2, and watchOS 10.2. We look forward to sharing even more details, including a complete technical walkthrough of our implementation, in a future post soon.
iMessage Contact Key Verification displays detected key validation errors in the Messages conversation transcript and allows users to compare short verification codes to verify they're messaging with whom they intend.