I think Apple encrypts the pass keys locally on your device, then stores encrypted copies in iCloud, which you can download and decrypt on a new device.
On the new device you would be prompted for the passcode of the device you lost or broke, to decrypt and access them.
This is false; some data is end-to-end encrypted, including Health and Keychain data. Photos, contacts, and Drive are "encrypted on server" which means Apple can read them.
> If you forget your password or device passcode, iCloud Data Recovery Service can help you decrypt your data so you can regain access to your photos, notes, documents, device backups, and more. Data types that are protected by end-to-end encryption—such as your Keychain, Messages, Screen Time, and Health data—are not accessible via iCloud Data Recovery Service.
Data in iCloud is going to be encrypted by the host provider in-transit and at rest. That is not the same as being encrypted at the source by Apple. It means that Google, Amazon, Azure (and whatever other platforms Apple uses for iCloud storage) will be doing that encryption with keys that they have for Apple. All the major vendors have storage encryption both in-transit and at rest. I suspect that it would be a requirement from Apple for any future vendor, too.
It does mean that the data is not sitting in clear-text form on the provider's disks. But the exact details of that encryption may vary from provider to provider.
Photos need to be encrypted on server so they can be scanned for CSAM. Apple tried to move that bit to the phone so they could encrypt photos on server too, but we all know how that went.
> Instead of protecting all of iCloud with end-to-end encryption, Apple has shifted to focus on protecting some of the most sensitive user information, such as saved passwords and health data.
> But backed-up contact information and texts from iMessage, WhatsApp and other encrypted services remain available to Apple employees and authorities.
Same thing that happens if your FIDO/U2F key breaks. If you have a backup key (or in the case of this implementation, icloud backup), then it shouldn't matter. Otherwise you're at the mercy of the site that's requesting the credentials. They might allow you to authenticate via another method (security questions?), or lock you out permanently.
Ideally, if you can’t identity proof in person, recovery flow should be Stripe Identity or another proofing system that will consume government ID and output pass or fail. It’s the next best thing to showing up in person and having a human proof you, and saying “oops keys all gone” isn’t going to fly for the masses at scale.
It's tied to a key stored in your iCloud. So basically as long as you have a device tied to your iCloud you can get in. Presumably, if you lose access to iCloud you will have problems.
My understanding is the QR code is used to establish a quick BLE connection. The phone then pretends to to be a simple FIDO2 key. After that things proceed like any other FIDO2 workflow.
interesting, but it still needs an iPhone> -- I was kind of burned hard when trying to migrate my iCloud keychain passwords to something else so I'm curious how smooth it actually is
Semantics aside, holding private keys hostage with no recourse is Orwellian. A for-profit company has no business being a centralized identity authority.
They said in the event that everything is synced on iCloud so all your devices can use the keys, which makes me think no, it's just a password manager, without the password bit. Maybe they create a separate key for each device, but then why mention iCloud syncing at all.
It's a password manager with cryptographic vendor lockin.
There are definitely some benefits though, such as immunity from phishing. Surely we as the industry can bring them about in a way that doesn't involve cryptographic vendor lockin.
There is no password so it can't be a password manager. Without a password it avoids all the downsides of passwords like having to store them securely on both ends, rainbow tables, credential reuse, weak password choice, and having to remember them. It's a cryptographic keypair manager. Key management is always the barrier to really good real world cryptography, so I'm heartily in favour. Anything that makes it possible for regular people to use strong cryptography is a huge win.
Since it's all just FIDO2/webauthn under the hood it's hardly lockin. It's a bit of Apple UI tinsel to make life simple and their excellent icloud keychain sync.
The industry doesn’t seem to have a working software solution for mobile phone authentication secrets that both is 1) immune to persuading a user to export their data (to get phished), and 2) allows a user to export their data at any time (to prevent lock-in).
What would it look like to do #2 safely, without enabling the phishing that we see today with #1?
I get where you're coming from and you're not wrong, but at the same time, I don't buy this as an excuse for vendor lock-in here, because it seems like Apple is already backing up passkeys to iCloud.
If Apple has decided that the risk of getting your passkeys phished out of your Apple iCloud Account is outweighed by the benefit of users being able to restore/sync login details immediately when they buy a new iOS device and log into it, then I think it's reasonable for users to expect the same treatment and the same experience when they're moving away from iOS.
If Apple wasn't backing up any of the logins, and they had committed to when you trade in your phone and upgrade to the latest iPhone forcing you to manually re-create all of those keys one-by-one using your recovery option, then I'd accept not having an export option for Android/Linux/Windows. Otherwise, it will just seem really suspiciously convenient to me if they ultimately decide that exporting keys is acceptable risk unless it's to a competitor's device.
As far as I can tell, there hasn't been any official confirmation that users won't be able to export them to non-iOS devices, so maybe it's all worry over nothing. But I don't think security is a justification to apply restrictions specifically only on devices outside of Apple's ecosystem.
I don't consider this solution an excuse for vendor lock-in. I consider this a problem that has no known solutions without vendor lock-in.
If you offer users a way to export, then you offer phishers a way to social engineer users. So either you prevent social engineering (lock-in: yes), or you allow exports (lock-in: no).
Which choice has a higher precedence when serving the market of "non-technical mobile phone users"?
I think you're misunderstanding what I'm saying. Apple IS allowing users a way to export right now, we just don't know whether non-iOS devices will be supported.
I consider the binary you describe to be a justifiable reason for Apple to offer no way to export from a phone, but that's not what they're doing. And I do not consider it a justifiable reason for Apple to allow only exporting between iPhones.
Apple is syncing passkeys to iCloud, presumably so they can be synced between devices and restored if a device is lost/destroyed. That's an export option, and iCloud syncing/restoration between phones is vulnerable to phishing attacks, but Apple has decided that the user experience without iCloud backup would be so bad that they're excusing the extra risk that users have their iCloud account phished and their keys synced to an attacker's phone.
> Which choice has a higher precedence when serving the market of "non-technical mobile phone users"?
In Apple's case, they have decided that allowing users to recover accounts easily is more important for non-technical users than protecting them from export phishing attacks. They've very explicitly said here that they think that allowing export is more important than preventing phishing.
We can debate whether Apple made a good choice with that, but having made that choice, there is now no reason for them to say that Android transfers would be a unique security threat.
It sounds like your private keys are stored in iCloud, so they should be accessible on a new device as long as you remember your Apple ID, password, the device-specific PIN/passcode from your old phone.
On the new device you would be prompted for the passcode of the device you lost or broke, to decrypt and access them.