5

I'm getting conflicting information on how the security keys are stored and used. Where are the public and private keys stored? If the private key is stored on the Yubikey itself, how many can it hold?

If the both keys are stored on the service you are authenticating against (Gmail), does it send the yubikey the private key to unencrypt to use the private key for signing?

Yubikey Website:

During the registration process, the key pairs are generated on the device (secure element) but the key pairs are not stored on the YubiKeys. Instead, the key pair (public key and encrypted private key) are stored by each relying party/service that initiated the registration. Therefore, this approach allows for an unlimited number of services to be associated with the U2F-certified YubiKeys.

FIDO Website:

The U2F device and protocol need to guarantee user privacy and security. At the core of the protocol, the U2F device has a capability (ideally, embodied in a secure element) which mints an origin-specific public/private key pair. The U2F device gives the public key and a Key Handle to the origin online service or website during the user registration step. Later, when the user performs an authentication, the origin online service or website sends the Key Handle back to the U2F device via the browser. The U2F device uses the Key Handle to identify the user's private key, and creates a signature which is sent back to the origin to verify the presence of the U2F device. Thus, the Key Handle is simply an identifier of a particular key on the U2F device.

https://fastmail.blog/2016/07/23/how-u2f-security-keys-work/

https://developers.yubico.com/U2F/

https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#site-specific-public-private-key-pairs

https://www.yubico.com/authentication-standards/fido-u2f/#toggle-id-4

Derpy
  • 53
  • 3

2 Answers2

7

The keys can be either stored on the device, or encrypted and returned in the key handle. Both are allowed (and mentioned) by the spec.

From the implementation considerations:

U2F tokens might not store private key material, and instead might export a wrapped private key as part of the key handle.

Also in the raw message format specification:

A key handle [length specified in previous field]. This a handle that allows the U2F token to identify the generated key pair. U2F tokens may wrap the generated private key and the application id it was generated for, and output that as the key handle.

This leaves the decision to the manufacturer of the U2F device.

Yubico chose to return the encrypted private key as the key handle, allowing an unlimited number of credentials.

If a device manufacturer chooses to store the private key on the device itself, the number of possible keys will be limited by the amount of storage available. You'd have to look at the specs for a specific device.

Marc
  • 4,091
  • 1
  • 17
  • 23
0

Source from: https://developers.yubico.com/U2F/Protocol_details/Key_generation.html

Simple Summary

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.

  • KeyHandle Length specification is variable 0-255 (FIDO U2F Raw Message Formats 11 April 2017, section 4.2), but Yubikey currently uses 64 bytes.
  • Yubikey currently encrypts PrivateKey with AES-256 in CCM mode

Limitation

Each credential consists of a private key along with metadata associated with that credential, which all require storage space. This puts an upper limit to the number of credentials that can fit on any one device.

To avoid this limitation, YubiKeys use the following approach:

Yubikey Solution

@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.

Solution Valid Version

"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)."

PathToLife
  • 133
  • 6