Can you confirm this? According to the video, the private keys are being store in Keychain not in the secure enclave. iCloud keychain is synchronized via the cloud as well. Unless you saw something differnt in the video, the secure enclave is not directly involved.
*grin* I was wondering if someone ask me to clarify my ambiguity. Buckle up!
Today, Safari already has support for these API, but its implementation is limited to the local secure enclave. The passkey system makes it so that any device on an account can get those keys from their respective secure enclaves.
I don't even know if Apple knows if they support both going forward or migration of existing Safari WebAuthn registrations for sites to the new system - there was definitely an expectation that Apple would not change the security properties underneath those websites.
In terms of the underlying technology and what this change means in terms of keychain vs local secure enclave storage, and why thats a bit nuanced:
It helps to understand that many secure enclave type systems do not have their own storage, so there is security data stored outside the secure enclave - it is just in a format that is worthless to others. You typically see this done by having creation and use of a key split:
- Your application gives policy on the properties you want your key to have.
- The secure enclave generates seed data and hands you back a secured message that may have some policy information and that seed data embedded in it.
- Whenever you supply that message, the secure enclave regenerates the same key, and recognizes/applies any policy elements it needs to pay attention to.
I'm fairly certain Apple uses this technique, and WebAuthn is designed around supporting this idea.
There are systems which do allow you to import a key directly from a file, but it is uncommon - it generally this means that the security of the key is 'tainted' already at start. Instead, secure enclaves typically have some sort of negotiation of a shared key in between them where the data is never available unencrypted, and have some sort of policy control (again, some sort of key) used to enable this negotiation.
I have not looked at how they handle this in iCloud Keychain these days, but I _suspect_ they have a mix of standard and custom protocols to do this, and hard-coded policy to only allow negotiation with Apple secure enclaves. The user-visible part of this protocol is seen when you turn on iCloud Keychain syncing or pair a new iCloud account and it starts asking for the passwords you have on other Apple devices. The passwords are used to generate cryptography keys locally, same as the passcode you enter when you reboot your device. So it isn't possible for Apple or any other party to negotiate this import without knowing the passwords or your recovery key.
These are the sorts of systems where someone like Apple wants protection from the _liability_ of potentially getting access to all your passwords - you can't be hacked for information you don't have ;-)
Anyway:
This appears to be a new policy mode for the secure enclave that they have not yet documented (likely an expansion on
kSecAttrSynchronizable) - AFAIK the current shipping operating systems can only synchronize passwords via iCloud using this system, not keys.
The behavior here is that icloud synchronizes a bunch of protected input data and policy that is meaningless outside of a secure enclave which hasn't gone through the prior negotiation - but if they have, they now all have enough information to derive the same private key and policy.
So when you go to a website, the system supplies this bundle of protected data and a bit of extra information. The secure enclave may have a policy it enforces (you need to let me go through FaceID), and then it derives the same key pair it has used previously - even if that has only ever been done on another device.
