Bitwarden is one of the few that don’t - you can export passkeys, although for now, there’s nothing to import them to unless you want to run a roll your own open source solution.
(And BitWarden isn’t even “free software”!)
In other words, it's a "standard" designed to let Apple, Google, and Microsoft enable portability between each other, but to keep software like KeePass out of the mix.
https://fidoalliance.org/specs/cx/cxf-v1.0-wd-20241003.html#...
The private key is specified as being a “PKCS#8 formatted byte string which is then Base64url encoded”. Is that insufficient?
As long as the key export API isn't actually gated (e.g. by only working over a backend-to-backend API with a mandatory "security audit" to gain access, by wrapping exported keys using vendor-specific keys and requiring a similar audit to be included as an export target etc.), everything else can be figured out. There's only so many ways you can encode an ECDSA key.
I don’t have a need for a level of security where exporting my private key to, say, Best Buy is impossible.
I think some vendors do have intentions of locking in users with passkeys (*cough* Apple *cough*), but I also think it's also not the only explanation for why import and export isn't supported by most managers.
A more charitable explanation would be that since passkeys are 'new', there's less people demanding import/export since they have very few passkeys to move around, and at least some vendors wanted to take time to develop a good solution for it / focus resources on actually getting the daily usage of passkeys working.
The year is 2025 (almost), and we're still suffering with companies closed garden syndrome.
Does this mean that any HSM where inability to export the private key is a feature is also doing it for "vendor lockin" reasons?
I do not expect random consumers to understand this concept. It’s grossly irresponsible and is simply user abuse.
I love Passkeys. They’re fantastic. I do not love how unportable the implementations for Average Joe and Jane are.
It functions both as a security feature and a vendor lock in.
I did a project 10 years ago to sign firmware for embedded devices w/ a planned 25 year product life. I spoke with two different HSM vendors. Both said the Customer would be able to backup and transfer keys from one HSM to another. Both also said that was applicable within their products only. There was no mechanism to switch to another HSM vendor (and neither offered a contingency to get the keys out if the vendor ceased business operations).
Apparently this situation has gotten no better in the last 10 years: https://www.icann.org/en/system/files/files/hardware-securit...
> In April 2023, IANA became aware of the decision by the manufacturer of the Keyper PLUS HSM – the equipment used to store private key materials for the Root Zone KSK – to cease its production of the device. Furthermore, the manufacturer will offer no successor product.
That's ridiculous.
There should be a standards-based protocol to transfer key material between HSMs. It should be tied to physical access using physical tokens. Make the protocol baroque and difficult. Heck, even make it a requirement the source HSM has to to be physically destroyed to complete the process (to prevent "cloning" attacks).
For USB authentication keys this level of cloak-and-dagger LARPing is stupid. There should be a method to export and encrypted copy of the contents of my USB token and, worst case, import it into another token manufactured by the same provider. ("But cloning!" Fine-- tie it to registering the token with the manufacturer along with real-world identity verification. Make it a premium service with an associated cost, if that's what it takes.)
There is a process of drafting a decision to put before the committee to change this ~now[1], but tbh I think the omission from v1 is a strong sign that the omission is literally intentional. I'm sure spec authors will disagree, as I am sure that many are well-meaning... but there are very strong incentives for the current giga-corps to impede and complicate it during design phases, as they are now doing to the UX. If backups and device-loss considerations for such intensely personal data is not baked in, simply, and mandated from day 1, it's intentional by someone.
[1]: https://blog.1password.com/fido-alliance-import-export-passk...
(If the hypothetical user was using Linux machines already by that point, they wouldn't have been using iOS Keychain for their Passkeys in the first place and probably would have the necessary skills or tech guru friend to load up Apple Passwords in a WINE session or in a Windows VM/dual boot.)
All else fails, there's always most sites will continue to (forever) fallback to email-based recovery because we should all face it that email accounts have been the average user's primary password manager for decades anyway.