3 ms·

side topic: could you elaborate how FIDO1 (not FIDO2) yubikeys do 'ykman fido reset' ? my question is (in domain of U2F/FIDO1 and non resident keys), what exac

by rdslw 6y ago

side topic: could you elaborate how FIDO1 (not FIDO2) yubikeys do 'ykman fido reset' ? my question is (in domain of U2F/FIDO1 and non resident keys), what exactly is resetted, and if RP (websites) will provide the same initial data on enrollment, will the second enrollment end in the same keys EVEN after reset? If not, what exactly is storred and resetted on yubikey (again, OLD ones with only U2F)

tialaramex 6y ago
I have never used 'ykman fido reset' and didn't implement it. However the obvious way to implement this, which I'd guess is what Yubico did, is very simple: Randomize the secret key that makes your authenticator unique. Doing this has a similar effect (cryptographically at least, it's not going to magically remove initials painted on with nail polish or something) to replacing the authenticator with a different one from the same batch. The thing that makes the simplest possible FIDO authenticator work is a single secret symmetric key known to nobody and used only one that one specific authenticator, 256-bit AES would do, we'll call the key K. The exact details will be proprietary, obviously there are opportunities to add features/ cost reduce the product, but basically: When it is asked to enroll somewhere the authenticator generates a completely random elliptic curve key pair, then it signs a blob with the private key from that pair, encrypts the private key using K in AEAD mode and hands over the signed blob, the public key and the encrypted private key which it says is just a neutral opaque identifier, looks random, could be anything. A relying party (remote web site) stores the public key, the opaque identifier (remember that's actually the private key encrypted) and some way to relate these to its existing user database. When you use U2F or WebAuthn's second factor mode to sign in, the relying party hands back that opaque identifier. Your authenticator takes the opaque identifier and tries to decrypt it with K. AEAD mode means it'll be able to verify it minted this identifier with K and if so, get back that private key. So now it can sign a blob with the private key and prove you are still in possession of the authenticator which was enrolled.

by rdslw 6y ago

tialaramex 6y ago

I have never used 'ykman fido reset' and didn't implement it. However the obvious way to implement this, which I'd guess is what Yubico did, is very simple: Randomize the secret key that makes your authenticator unique. Doing this has a similar effect (cryptographically at least, it's not going to magically remove initials painted on with nail polish or something) to replacing the authenticator with a different one from the same batch. The thing that makes the simplest possible FIDO authenticator work is a single secret symmetric key known to nobody and used only one that one specific authenticator, 256-bit AES would do, we'll call the key K. The exact details will be proprietary, obviously there are opportunities to add features/ cost reduce the product, but basically: When it is asked to enroll somewhere the authenticator generates a completely random elliptic curve key pair, then it signs a blob with the private key from that pair, encrypts the private key using K in AEAD mode and hands over the signed blob, the public key and the encrypted private key which it says is just a neutral opaque identifier, looks random, could be anything. A relying party (remote web site) stores the public key, the opaque identifier (remember that's actually the private key encrypted) and some way to relate these to its existing user database. When you use U2F or WebAuthn's second factor mode to sign in, the relying party hands back that opaque identifier. Your authenticator takes the opaque identifier and tries to decrypt it with K. AEAD mode means it'll be able to verify it minted this identifier with K and if so, get back that private key. So now it can sign a blob with the private key and prove you are still in possession of the authenticator which was enrolled.