I was wondering if someone providing a service can identify me (other than by IP, browser fingerprinting etc.) purely based on the code generated by the Yubikey when I touch it, if I use the same Yubikey on two different accounts.
I.e. will the provider know implicitly that the same Yubikey was used?
With Yubikey's alphanumeric one-time passwords, yes:
Each Yubikey had a unique public identifier. The authentication server must know this ID in order to select the correct AES key for the OTP. The proprietary Yubico OTP protocol should no longer be used.
With FIDO U2F, no:
The Yubikey creates a unique keypair for each combination of device+user+service. This is described in the Registration section. The FIDO protocol is newer and focuses on both secure authentication and user privacy.
During registration, Yubikey creates a new privatekey but doesn't store it locally, it instead encrypts the privatekey* and uploads with registration success message in the ~64 Byte* keyhandle. The public key is included as well without encryption.
During authentication, the server will return the keyhandle. Yubikey will try decrypt the keyhandle using master key, and sign the challenge if decryption was successful.
As Public Key & KeyHandle are Unique to the registration, and masterkey is never revealed. The server is unable to cross reference with other registrations.
@Marc answer notes that FIDO specification (Proposed FIDO U2F Implementation Considerations 11 April 2017, Section 2.2 Generation of Key Handles) approves this "wrapped private key" solution.
During credential registration, a new key pair is randomly generated by the YubiKey, unique to the new credential. The private key, along with some metadata about the credential, is encrypted using authenticated encryption with a master key. This master key is unique per YubiKey, generated by the device itself upon first startup, and never leaves the YubiKey in any form. For FIDO2 capable YubiKeys, this master key is re-generated if FIDO2 RESET is invoked, thereby invalidating any previously created credentials.
The encryption used for each credential is AES-256 in CCM mode, which allows us to cryptographically tie things like the AppID to the private key, ensuring that the credential can only ever be used with the correct RP. The encrypted (and authenticated) data then forms the 64-byte key handle, which is sent to the server as part of the registration flow, to be stored by the RP for later.
For authentication, the RP returns the key handle to the YubiKey. Here it is decrypted to re-form the private key which is needed to sign the challenge to complete the authentication. Due to the authenticated encryption used, we know that the private data has not been altered in any way, and can verify that the credential is being used with the correct AppID.
By using this approach, the YubiKey does not need to store any per-credential data, and can thus register and use any number of credentials. This is true for both U2F and for WebAuthn "non-resident keys". For WebAuthn resident keys, internal storage must still be used.
"The following applies to any YubiKey or Security Key by Yubico with a firmware version of 4.4 or greater ( this includes any YubiKey FIPS device)."
I'm not too sure. Put this in separate question.
But I just gave github a try with the same key twice, and breakpointed the exception:
""" DOMException: The user attempted to register an authenticator that contains one of the credentials already registered with the relying party. """
According to fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-javascript-api-v1.2-ps-20170411.html#idl-def-RegisteredKey It seems the server will trust the client to check if the list of existing registered keys it passes don't match the key to be registered.
https://developers.yubico.com/U2F/Protocol_details/Key_generation.html
