3 ms·

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

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.

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.