Apple does some additional trickery to synchronize credentials between devices, but they get away with this because their devices have contained dedicated silicon for sensitive data management for years[1]. They have some user-facing documentation on how their passkey implementation is synchronized between devices without any secret disclosure here[2][3].
[1]: https://support.apple.com/guide/security/secure-enclave-sec5...
[2]: https://support.apple.com/en-us/HT213305
[3]: https://support.apple.com/guide/security/keychain-data-prote...
Apple has no access to keychain data: https://support.apple.com/en-us/HT213305
Which again, seems like the worst of both worlds.
You login to iCloud which gives your device write access to iCloud storage. The device creates a private key inside the TPM, and uploads the public key. When you add a new device, one of your existing devices has to use its hardware key to sign your new devices key. It also must be signed by a second key derived from your iCloud password (so you). Apple doesn't go into the details on this, but I believe the originating TPM also signs the key with a chain of trust that goes back to Apple itself.
The keychain is encrypted locally and exported to iCloud. The key used to encrypt the keychain is also encrypted using the public keys of all trusted device keys in iCloud that have both a signature from another trusted device and from you.
As a user you can also just open up Keychain Access on a Mac and ask it to generate a CSV export of your entire iCloud keychain - which is how you would go about migrating to another password manager.
No one claimed it's a hardware security token, but the private keys are stored in iCloud Keychain, which is end-to-end encrypted. Apple cannot access your private keys even if iCloud is compromised by an external attacker or employee.
If you're curious about the security engineering, you should watch the "Synchronizing secrets" part of this Black Hat talk from 2016: https://youtu.be/BLGFriOKz6U?t=1353 or you should read the "Synchronization security" section of the "About the security of passkeys" support doc: https://support.apple.com/en-us/HT213305
I does not make sense to use a proprietary internet connected application on your machine and worry that that the servers might be nefarious.
[1]: https://support.apple.com/guide/security/escrow-security-for...
Apple just extended their Credential Provider API such that passkeys can now be synced using external providers, meaning password manager apps can save and offer passkeys on iOS, iPadOS, and macOS. So you can choose to sync your passkeys with whatever your favorite password manager is.
See this page: https://developer.apple.com/passkeys/
And Google announced a similar API a month or two ago.
See the section titled "Passkey support for Android apps" on this page: https://developers.google.com/identity/passkeys/supported-en...
Does that service also have to trust the OS developers? Correct me if I'm wrong, but I'm under the impression that services can decide whose passkey implementations to trust.
Seems like that should be up to the user, not the service.
For example in the case of email, you generaly dont worry about google reading your email but we should definitely be concerned if gmail allows send & recieve from only few domains or providers it chooses.
This is a personal belief based on chatting with Apple and Google employees. You don't have to agree.
Compared to using, say, KeepassXC with a unique, secure password per vault. Now you can sync on iCloud or google drive, but neither Google nor Apple can decrypt the vault; the keepassXC maintainers presumably could make a malicious update (which you'd still have to accept, since the updates aren't forced on you), but that would also affect the security of everyone using KeepassXC (and potentially be much more harmful to the economy and society as a whole than the government is willing to accept in order to get intel on an individual person of interest)
It's a know bug, but the fact that it still exists really shows how much the devs care about making it a really rock solid alternative. I've never had this issue with Google passwords, 1password or any other provider.
I've already been doing manual backups. In addition, there is a feature to make a copy of the database before writing that I've just turned on. And the "Use alternative saving method -> Directly write to database file (dangerous)" option is supposed to prevent this issue from happening with cloud storage.
I wasn't in any way arguing KeepassXC is a layperson-friendly way to manage authentication credentials, just that it gives you the most security from the big identity providers (Apple, Google) selling you out for political or selfish reasons.
Of course, there's probably only so much I can do here. Apple could presumable ship an update to their OS that allows them to access a user's database while it's unlocked, or to keylog the master password.
A yubikey might be the only thing that can really protect you here.
Have you chatted with the Apple and Google CEOs? How about with the future Apple and Google CEOs?
Of course they can, just not from the stored cloud data. But that's just software. One little patch and your cloud sync is without E2E.