5 ms·

It'd be great to have a standard to share passkeys, and we'd be more than happy to include a reference implementation in solokeys firmware. Passkeys is "just"

It'd be great to have a standard to share passkeys, and we'd be more than happy to include a reference implementation in solokeys firmware. Passkeys is "just" the new (and much better!) name for FIDO resident keys. They are available in most (all?) security keys, though they're usually not extractable from hardware devices. From a purely technical pov, I don't see any major complexity in exporting keys from one device to another (maintaining the required level of security), but of course if we want to do it across vendor we need a standard. To the best of my knowledge both Google and Apple have their own proprietary way to share passkeys claiming better end-user security. It'd be nice to get to a standard that everybody can implement, and not just a way to share passkeys safari/iOS <> chrome/android.

g_p 4y ago
I'd agree - technically speaking, there's no real barrier to a secure way to export from a FIDO key. HSMs have support for it - authenticate to the HSM, provide an encryption key (or public key), and receive an encrypted dump. I do fear resistance from the big tech "overlords", trying to protect non-technical end users from an "endgame" type phish attack, where their device is compromised and they unwittingly export a backup encrypted to an attacker-controlled key. From what I've seen so far (you may have a better idea than me), Apple and Google are giving "dip your toe into the swimming pool" type ways of sharing passkeys, but which actually revolve around scanning a QR code (proximity) shown on the (unpaired) screen/device using your (trusted) phone, which then uses BLE and similar short-range comms to let you sign in. I am not aware of any proper "migration" that takes you off one platform and onto the other platform - the above is fine as long as you never break your phone (or can afford to instantly replace it with one from the same ecosystem), but makes no provision for someone wanting to move from iOS to Android, or to get rid of their phone and move to an authenticator in their browser on Linux. In the real world, people smash and break phones, and drop them in the ocean - there need to be recovery modes from this. A good Webauthn key will likely outlast at least 2 generations of current shiny gadgets. Finally, all of this assumes users have unlimited resident key storage - most dedicated hardware keys are limited on this front, and I do hope we see options for people who want to stuck with UN + PW + FIDO2 (non-resident, as MFA). Even though I have confidence in the crypto, I like to separate concerns. A dedicated bit of hardware that can be unplugged from the USB port can resist attacks that on-platform TPM/secure elements can't, and is also inherently portable. And FIDO2/Webauthn today with non-resident keys is hugely portable (and even more portable if there was a way to pair friendly backup keys at time of initial registration).
- ecesena 4y ago
  Totally agree on the steps Apple & Google are taking, and a secure export/import should -I think- implement similar protections. By setting a PIN/fingerprint (that should already be mandatory for passkeys), using usb or NFC for proximity, and of course pub key encryption à la HSM, I think more or less you should have all the ingredients. I personally like 1) to stay away from BLE, and 2) to stay away from using a server in the middle. On a phone, of course, you have more features but you also need to make the experience incredibly smooth even in edge cases (hence BLE, hence the server). While on the topic, I found this podcast episode very very interesting [1]. As for the storage I'm not particularly concerned, if people start to use passkeys, we'll allocate more storage in hardware devices. (and I'm also personally much happier with non-resident keys, however the market seems to be moving towards passkeys, so I guess we have to embrace it.) [1] https://securitycryptographywhatever.buzzsprout.com/1822302/11122508-passkeys-with-adam-langley https://securitycryptographywhatever.buzzsprout.com/1822302/...
monkeybutler 4y ago
I really don't understand how exporting keys could be secure since I currently trust that if I still have a token and it still works, no one else has cloned it while I was asleep, etc. It also doesn't have a dedicated keypad.. Personally, I'm fine with having multiple devices I re-register together. I think the lack of encryption/decryption and the generally poor support/guidance/etc for relying party design has been its biggest hindrances. Looking at something like keybase, I don't think there was a proper way to implement zero trust services with 2FA in a way that anyone could discuss clearly. Every pkcs11 device could do that naturally if they didn't hit other barriers to adoption.
- ecesena 4y ago
  I don't want to try to provide a specification here, just high level. 1. Get public key from the destination device (where you want to import) 2. Require PIN to export a key, i.e. only the owner can export (your key won't be exported while you sleep). 3. Encrypt the passkey, such that only the destination device can decrypt it. Here, you could add more checks, for example you could enforce that the encryption key is "certified" to come from a device you trust (FIDO devices all have attestation keys). Note that the UX can be much simpler. For the end user, it could be like "plug in source key", "now plug in dst key", "enter source key PIN", and maybe it can backup all your passkeys at once like iCloud does. With this said, as long as -as you said- there's no way to clone a key without your permission, an advanced user can very much use independent devices. The issue I see is mostly how do we make it easy (and in particular possible) for the end users.
  - monkeybutler 4y ago
    I definitely prefer an open standard, (preferably where it can be attested that it is disabled) over possible proprietary implementations being setup with vendor generated pins before purchase, etc.. Based on simcards and similar, I don't think the pin situation is actually that nice for a user. You can choose from re-entering it often on the possibly keylogged device you didn't want to trust, forgetting it, having it on a piece of paper next to the token. Then you need a way for malicious code or user error to DOS it so that it can be short, then people start to ask why there is no escrow of a management puk. I'm exaggerating the limitations a bit, but the foot guns of having a plan that works seem to add up. As with enterprise HSMs I think there is always a conflict of adding features and ways to recover from every possible mistake that erode the few clear security USPs that one can put together to just make and take an understandable risk trade off.

g_p 4y ago

I'd agree - technically speaking, there's no real barrier to a secure way to export from a FIDO key. HSMs have support for it - authenticate to the HSM, provide an encryption key (or public key), and receive an encrypted dump. I do fear resistance from the big tech "overlords", trying to protect non-technical end users from an "endgame" type phish attack, where their device is compromised and they unwittingly export a backup encrypted to an attacker-controlled key. From what I've seen so far (you may have a better idea than me), Apple and Google are giving "dip your toe into the swimming pool" type ways of sharing passkeys, but which actually revolve around scanning a QR code (proximity) shown on the (unpaired) screen/device using your (trusted) phone, which then uses BLE and similar short-range comms to let you sign in. I am not aware of any proper "migration" that takes you off one platform and onto the other platform - the above is fine as long as you never break your phone (or can afford to instantly replace it with one from the same ecosystem), but makes no provision for someone wanting to move from iOS to Android, or to get rid of their phone and move to an authenticator in their browser on Linux. In the real world, people smash and break phones, and drop them in the ocean - there need to be recovery modes from this. A good Webauthn key will likely outlast at least 2 generations of current shiny gadgets. Finally, all of this assumes users have unlimited resident key storage - most dedicated hardware keys are limited on this front, and I do hope we see options for people who want to stuck with UN + PW + FIDO2 (non-resident, as MFA). Even though I have confidence in the crypto, I like to separate concerns. A dedicated bit of hardware that can be unplugged from the USB port can resist attacks that on-platform TPM/secure elements can't, and is also inherently portable. And FIDO2/Webauthn today with non-resident keys is hugely portable (and even more portable if there was a way to pair friendly backup keys at time of initial registration).

ecesena 4y ago
Totally agree on the steps Apple & Google are taking, and a secure export/import should -I think- implement similar protections. By setting a PIN/fingerprint (that should already be mandatory for passkeys), using usb or NFC for proximity, and of course pub key encryption à la HSM, I think more or less you should have all the ingredients. I personally like 1) to stay away from BLE, and 2) to stay away from using a server in the middle. On a phone, of course, you have more features but you also need to make the experience incredibly smooth even in edge cases (hence BLE, hence the server). While on the topic, I found this podcast episode very very interesting [1]. As for the storage I'm not particularly concerned, if people start to use passkeys, we'll allocate more storage in hardware devices. (and I'm also personally much happier with non-resident keys, however the market seems to be moving towards passkeys, so I guess we have to embrace it.) [1] https://securitycryptographywhatever.buzzsprout.com/1822302/11122508-passkeys-with-adam-langley https://securitycryptographywhatever.buzzsprout.com/1822302/...

monkeybutler 4y ago

I really don't understand how exporting keys could be secure since I currently trust that if I still have a token and it still works, no one else has cloned it while I was asleep, etc. It also doesn't have a dedicated keypad.. Personally, I'm fine with having multiple devices I re-register together. I think the lack of encryption/decryption and the generally poor support/guidance/etc for relying party design has been its biggest hindrances. Looking at something like keybase, I don't think there was a proper way to implement zero trust services with 2FA in a way that anyone could discuss clearly. Every pkcs11 device could do that naturally if they didn't hit other barriers to adoption.

ecesena 4y ago
I don't want to try to provide a specification here, just high level. 1. Get public key from the destination device (where you want to import) 2. Require PIN to export a key, i.e. only the owner can export (your key won't be exported while you sleep). 3. Encrypt the passkey, such that only the destination device can decrypt it. Here, you could add more checks, for example you could enforce that the encryption key is "certified" to come from a device you trust (FIDO devices all have attestation keys). Note that the UX can be much simpler. For the end user, it could be like "plug in source key", "now plug in dst key", "enter source key PIN", and maybe it can backup all your passkeys at once like iCloud does. With this said, as long as -as you said- there's no way to clone a key without your permission, an advanced user can very much use independent devices. The issue I see is mostly how do we make it easy (and in particular possible) for the end users.
- monkeybutler 4y ago
  I definitely prefer an open standard, (preferably where it can be attested that it is disabled) over possible proprietary implementations being setup with vendor generated pins before purchase, etc.. Based on simcards and similar, I don't think the pin situation is actually that nice for a user. You can choose from re-entering it often on the possibly keylogged device you didn't want to trust, forgetting it, having it on a piece of paper next to the token. Then you need a way for malicious code or user error to DOS it so that it can be short, then people start to ask why there is no escrow of a management puk. I'm exaggerating the limitations a bit, but the foot guns of having a plan that works seem to add up. As with enterprise HSMs I think there is always a conflict of adding features and ways to recover from every possible mistake that erode the few clear security USPs that one can put together to just make and take an understandable risk trade off.