Apple launched a new iMessage security feature yesterday in beta called Contact Key Verification. We learned the basics of how it works yesterday but now Apple has published technical details of how the next-level iMessage security feature operates – including a unique solution to a problem that other messaging services face.
The new iMessage security feature protects against a threat that hasn’t been seen in the wild yet, but Apple has built a robust defense to help make sure it stays that way.
When enabled, the opt-in Contact Key Verification gives automatic alerts if the iMessage key distribution services return device keys that have not been verified (e.g. if an unrecognized device has been added to an iMessage account).
And even more security is available by using CKV in person, on FaceTime, or via another secure method like another phone call.
Now Apple has shared in-depth details on how the new iMessage security feature works on its Security Research blog.
Here’s a brief history of the security features Apple has implemented with iMessage over the years:
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.
Going into Contact Key Verification, here’s what’s happening:
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.
Aiming to “both secure the key discovery protocol and provide a great user experience in iMessage” Apple built Contact Key Discovery around six 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.
For more in-depth details on Key Transparency, Automatic verification, and more, check out Apple’s full post on the topic.
The company also highlights a “complete technical walkthrough” for the feature will be published “soon.”
FTC: We use income earning auto affiliate links. More.
Comments