Originally published at: Upcoming Contact Key Verification Feature Promises Secure Identity Verification for iMessage - TidBITS
Apple has released details about Contact Key Verification, an upcoming option in Messages that lets you manually verify an iMessage correspondent’s identity without relying on encryption data managed centrally by Apple. The feature also watches for anomalies, warning you when changes prevent it from guaranteeing a conversation is with the same person.
Thanks for such a clear article – public key cryptography quickly gets confusing with the various keys floating about, but you have (as usual) set things out clearly so I think I understand what’s going on. However, there are two specific points I’m still not entirely clear on and wondered if you can shed any light.
The first is how the private key is exchanged between devices. The article says the keys are ‘never transmitted to Apple.’
But how do the keys move between devices? Further down states:
Which implies that the keys are transmitted to Apple-controlled servers, albeit in encrypted form (and the secret to decrypt the keys never leaves one of your devices). If this is the case, isn’t there an attack where someone could compromise Apple’s iCloud servers and try to decrypt the private keys with password attacks?
My other question is how a new device (iPad in your example) receives my private key. Is it also sent through iCloud, but encrypted with the password/passcode of an existing device? So that when this happens:
the password or passcode I enter is then used to decrypt the private key that has been sent via iCloud servers?
I guess both of these questions are about how my private key travels. Is it true that it never leaves the Secure Enclave, or is it more accurate to say that it never leaves the Secure Enclave unencrypted, but it does pass through Apple’s servers in an encrypted form?
1 Like
If I am reading Apple’s notice about this right, Apple uses CloudKit encryption, also used to synchronize other data on the iCloud Keychain, to synchronize information about the signing process for secure identity. Apple has a full security white paper that details the basic algorithm for how this works to securely transit and store end-to-end encrypted secrets. See pages 129-132 for an additional overview of iCloud Keychain sync.
As it says on page 129 of that whitepaper, this would be protected even if an external attacker gains access to Apple’s iCloud infrastructure.
I believe that this private key used for this will not be stored in the Secure Enclave - I believe that the Secure Enclave cannot be written to by iOS itself. It will instead be stored on the iCloud Keychain on each device.
3 Likes
Great question. I should have said “never transmitted in the clear to Apple” as they are only exchanged within a strong encrypted wrapper. Apple has no access to the keys.
Because all the encryption happens on devices, Apple can use absurdly strong methods that are purely “symmetrical,” meaning the same key is used for encryption and decryption. No public part is shared and there’s no effective way to brute force it—many encryption techniques have been vulnerable over time because of the trade off of using the strong key that can be used effectively for rapid transactions that occur in vast numbers.
So in the scenario you’re asking about, Apple uses the passcode/password of your hardware device accounts to derive the key use to lock the keys being exchanged among your devices. Because of the level of encryption deployed, even a compromise that fully exposed that scrambled payload could effectively never be decrypted through brute force.
In brute force attacks that used to work on leaked account databases, and attacker can try trillions of passwords, running them through a simple one-way algorithm. But because of the amount of computation used by Apple for these synced keys, even a weak device passcode/password would require many orders of magnitude more time to find a match.
All this information for all iCloud users could be posted to the internet publicly and it is exceedingly unlikely, odds of practically zero, that any key would ever be uncovered through brute force.
Correct. The out-of-band element is your knowledge of a password/passcode for your hardware device or account that you ostensibly never use anywhere else, so it can’t be leaked or socially engineered. Because you know that information, Apple can pass the device-encrypted data over iCloud among your hardware. When you’re prompted to enter the secret you know, Apple doesn’t see this because the encrypted payload is already on your hardware.
Keys used for iCloud aren’t stored in the Secure Enclave, as I understand it and as Doug noted. They have to be in regular user space in order to decrypt and encrypt data. Secure Enclave typically stores information that can be used for validation. So, for instance, your iPhone passcode is not stored in user space or in Secure Enclave—Secure Enclave only stores a hash (cryptographically iterated end result) that can’t be reverse engineered. When you enter your iPhone passcode, iOS runs your entry through the same hashing algorithm, and the result is passed to Secure Enclave, which throttles attempts. If there’s a match, Secure Enclave provides validation. But it doesn’t pass back out the hashed version nor store the plain text version.
With iCloud Keychain and similar device-based keys, a lot of components have to be stored in active memory. There’s definitely a heightened risk compared to Secure Enclave, but someone has to gain physical access or remote screen/file access, which typically means they have your device passcode/password already.
4 Likes
This is an amazing level of extra (and comprehensible!) detail, thank you so much.