5.7 Firmware Specifics

This section provides detailed descriptions of the features enabled by the 5.7 firmware (includes 5.6.x).

CTAP 2.1 Feature Summary

CTAP 2.1 is the evolution - and first update - of CTAP 2.0, which was introduced for FIDO2/WebAuthn several years ago. The new features enabled by CTAP 2.1 are primarily enterprise-focused, but also support new FIDO2 use cases. Yubico supported CTAP 2.1 features even before that standard was approved, for example, credential management introduced in 5.2.1 (see Managing Credentials) and uvRetries introduced in 5.5.0.

In firmware 5.7 the PIV and OpenPGP applications both support unicode PINs, as well as counting each unicode code point as a single character.

These CTAP 2.1 features are also available in the Security Key series for FIDO-only deployments (see Security Key Series).

CTAP 2.1 support gives organizations:

  • Improved control of the CTAP 2.1 authenticators they have deployed
  • Ability to list compliance requirements such as:
    • Permissible authenticators
    • PIN requirements
  • More granular control of the end user experience
  • Additional capabilities for CMS vendors through the storage of additional data, etc.:
    • To configure authenticators
    • To manage the authenticator lifecycle
  • Management beyond the scope of FIDO2, through the ability to associate the FIDO2 credentials on the authenticator with other credentials on other protocols, such as certificates on the PIV module.

Note

You might need to scroll horizontally to see the table below.

New Capabilities Available per Firmware Version
New Capabilities
YubiKey 5
Series
Security
Key Series
Security
Key Series
Enterprise
Edition
YubiKey Bio
Series Multi-
protocol
Edition
YubiKey Bio
Series
FIDO
Edition
YubiKey 5
FIPS Series
5.7.4
PIN Management Flexibility
Temporary FIDO2 PIN can be set
(forces user to change upon next use)
 Yes Yes Yes Yes Yes Yes
Configure FIDO2 minimum PIN length Yes Yes Yes Yes Yes Yes
Enhanced Asset Tracking
Capable of Enterprise Attestation
(requires custom configuration)
 Yes   Yes Yes Yes Yes
Serial number retrievable by client
software in Windows without Admin rights
Yes
Also applies
to earlier
firmware
versions
  
Yes
New in 5.7
 Yes Yes Yes
Enhanced Smart Card Capabilities (PIV)
RSA-3072 and RSA-4096 support Yes     Yes Yes Yes
Ed25519 and X25519 key types Yes     Yes Yes Yes
Future-proofed for Compliance Yes Yes Yes
Enhanced PIN complexity
Yes
Requires
custom
config
  
Yes
Off by
default
Yes
Off by
default
Yes
Off by
default
Yes
On by
default
Default minimum PIN length 4 4 6 6 4 8
Enhanced Credential Storage
Support for 100 passkeys Yes Yes Yes Yes Yes Yes
Support for 24 PIV certificates Yes     Yes   Yes
Support for 64 OATH credentials Yes         Yes
Support for 2 OTP seeds Yes         Yes

FIDO2 Extensions

Enterprise Attestation

Enterprise Attestation (EA) enables Identity Providers (IdPs) to read the serial number (or other unique identifier specific to the organization) on custom-programmed keys during FIDO2 registration. This satisfies a variety of asset tracking requirements, and can aid in account recovery by enabling an end user to prove they have a specific FIDO2 device. In addition to support from the Relying Party (RP) and/or IdP, EA requires platform support (see Current Platform/RP Support).

EA’s ability to identify individual authenticators as opposed to just the type of authenticator changes the privacy model of the FIDO protocol, making the FIDO credential behave more like a certificate. Typical use-cases are:

  • Tracking of individual authenticators on registration to ensure only authenticators issued by the organization are used. This resolves a common compliance requirement that previously could only be solved by policy or by custom AAGUIDs.
  • If the organization knows what serial number a user was issued but does not see it registered or did not register it on the user’s behalf, the organization can take appropriate steps to help the end user register their authenticator. This will help organizations roll out phishing-resistant MFA.
  • Tying the FIDO credential to a PIV certificate by matching serial numbers (or other device-specific information) between the FIDO2 EA certificate and the PIV Attestation certificate.
  • Identify individual authenticators in troubleshooting scenarios. When a key is lost or broken, a user can be guided by an IT admin who knows what authenticator holds which credential. The admin can advise which key is being used and which should be de-activated. The serial number of a back-up authenticator can be identified, too.

Developers seeking more information can refer to Enterprise Attestation on developers.yubico.com.

Current Platform/RP Support

At present, few RPs support EA; however there is platform support for it in Chrome and some Chromium based browsers. Windows 11 is required on Windows platforms.

CMS vendor support for EA is currently a little sparse; however, that is rapidly changing.

Minimum PIN Length and Minimum PIN Length Extension

minPINLength enables the minimum PIN length to be set on an authenticator. The minPINLength needs to be set locally by a client tool such as the Yubico Authenticator or ykman. Once set, it cannot be shortened without resetting the authenticator.

minPINLengthExtension enables IdPs to support FIDO registration self-enrollment processes by enforcing the configured minimum PIN length. If configured via an allowed list on the YubiKey, the Relying Party (RP) is enabled to query the minPINLength of the authenticator.

This extension resolves compliance requirements for organizations that need to enforce use of specific PIN lengths. Before 5.7, this was only possible through the deploymnent of YubiKey 5 FIPS Series (authenticators certified for FIPS 140-2 have a minimum PIN length of 6) or custom configuration, in which there were no checks the RP could perform unless the authenticator had a custom AAGUID.

Current Platform/RP Support
No current RP supports this feature; however there is platform support for it in Chrome and some Chromium based browsers. Windows 11 is required on Windows platforms.

Force PIN Change

Force PIN change or forcePINChange (FIDO 2.1 specification) enables vendors or IT admins to prompt end-users to change their FIDO2 PIN. This is valuable in a pre-registration/enroll-on-behalf-of scenario where the organization does not want to know their end users’ PINs. End-users are prompted to set their own PIN (may be combined with minPINLength), i.e. a PIN not known by the organization.

This feature also minimizes the number of helpdesk calls due to forgotten PINs because end-users can set PINs that are meaningful to them.

Current Platform Support
There is no need for explicit RP support for force PIN change. It only requires support on the platform, and it can only be set by communicating with the YubiKey directly. The forcePINChange flag is set on the client/platform side, which is where it will trigger the flow. Chrome and some Chromium-based browsers support it. Windows 11 is required on Windows platforms.

Always User Validation

alwaysuv was introduced to prompt users for user verification (UV) each time, which provides consistency in behavior between different platforms and RPs. End-users are often confused because the setting uv=preferred/discouraged behaves differently depending on whether the user is on a macOS or a Windows machine.

This feature is enabled by default in the YubiKey Bio: it always asks for biometrics and never “plain touch” in a second factor flow when UV is not necessarily required. Otherwise an end user might touch the fingerprint sensor with an unenrolled finger and successfully authenticate when only performing User Presence (UP), therefore thinking they “bypassed the biometrics” or that the biometric sensor was faulty, allowing an unenrolled finger to authenticate.

An organization might want to enable it so that users always enter their PIN, ensuring they are less likely to forget it.

Current Platform/RP Support
This setting is internal to the authenticator and requires no specific platform or RP support.

Blob Storage

There are two blob storage options available on the YubiKey 5.7. Both Credential Blobs and Large Blobs require support on the platform as well as from the RP.

Credential Blob

A credBlob is 32 bytes of unencrypted storage per credential that can be set during registration and retrieved during authentication for discoverable credentials. This feature allows for a small amount of secret data to be associated with a discoverable credential during makeCredential. The blob is opaque to the authenticator. This enables IdPs to include a small amount of information such as a certificate thumbprint to aid in authentication scenarios. PII can be stored in this field if it is used with credProtect.

There is a great variety of use cases, as the credBlob enables storage of arbitrary data. For example, it can:

  • Be used as HPKP-like public key hash to identify, e.g., kerberos certificates to trust when using a given credential (“on prem AD”).
  • Provide information about the issuance of the specific credential.

Large Blob

authenticatorLargeBlob storage is 4096 bytes of compressed, shared storage on the authenticator. It is managed by the platform, and is always encrypted with the Large Blob Key - a per-credential symmetric encryption key that is used by the platform to read the contents of the large blob. Large blobs can be used for storing authentication certificates or other artifacts linked to the private FIDO2 key stored on an authenticator.

The large blob feature allows for a “large” amount of data to be added to a discoverable credential upon creation. The typical use case of this is a public SSH key.

Creating an SSH key using a discoverable FIDO2 credential enables the authenticator to be hardware-bound and perform SSH authentications using a key stored in the FIDO2 applet.

With the addition of large blob the user can take the authenticator to a new machine without needing to copy the public part to the new client machine.

Any other data can be associated with the key, such as linkage to a PIV certificate or details on the creation of the credential.

Note that a largeBlobKey is necessary to decrypt the data in the Large Blob.

FIDO Level 2

YubiKey 5.7 will undergo FIDO Level 2 certification for assurance of attestable hardware-bound credentials. This enables YubiKeys for use with e-government use cases (citizen-facing) and corporate compliance mandates that require FIDO L2 certification.

PIV Enhancements

Additional Key Types Supported

In accordance with the August 2023 Department of Defense memo on stronger public key algorithms, the 5.7.x firmware supports RSA-3072 and RSA-4096.

In addition, the 5.7.x firmware also supports the Ed25519 and X25519 key types.

PIV Management Key (AES)

Given that after December 31, 2023, three-key TDEA is disallowed for encryption unless specifically allowed by other NIST guidance (decryption using three-key TDEA is allowed for legacy use) the default management key with the 5.7.x firmware uses AES-192 instead of TDES. The management key uses the same default value as previous keys (TDES and AES-192 keys are the same length. If you need to know what these values actually are, go to the “General Information” section in the “Yubico PIV Tool” guide on our developers’ site).

Beginning with firmware 5.4.x, the management key type held in PIV slot 9b expanded to include AES keys (128, 192 and 256) as defined in SP 800-78-4 Cryptographic Algorithms and Key Sizes for Personal Identity Verification <SP800-78-4, section 5). The PIV management key in AES format enables current and future FIPS-compliant CMS services.

To summarize, standard YubiKey 5 Series keys with firmware 5.7.x and later use AES-192 for the management key by default. TDES, along with AES-128 and AES-256, are supported as options. YubiKey 5 FIPS Series keys with firmware 5.7.x and later allow AES only, with AES-192 as the default.

YubiKeys with firmware 5.4.x through 5.6.x use TDES for the management key by default, and AES-128, AES-192, and AES-256 are supported as options.

YubiKeys with firmware 5.3.x and older support TDES only.

For additional technical information, see PIV AES Management Key in Smart Card (PIV Compatible).

Advanced Key Management Functions

With the 5.7.x firmware, the PIV application supports advanced key management functions such as moving and deleting keys:

  • The ability to move keys enables retaining retired encryption keys on the device to decrypt older messages.
  • The ability to delete keys enables destroying key material without overwriting with bogus data or resetting the PIV application.

Generate a New Key Pair

The four new algorithms (alg) that can be used for key generation are:

  • RSA-3072 (0x05)
  • RSA-4096 (0x16)
  • Ed25519 (0xE0)
  • X25519 (0xE1)

For more information, see Generate asymmetric key pair.

Import a Key

The four new algorithms (alg) that can be used for key import are:

  • RSA-3072 (0x05)
  • RSA-4096 (0x16)
  • Ed25519 (0xE0)
  • X25519 (0xE1)

For more information, see Import asymmetric key pair.

Below is the updated list of tags for the import data. Values followed by an asterisk (*) are new for firmware 5.7.

List of Tags for Import Data
Algorithms Key Element Tag
RSA-1024 (0x06)
RSA-2048 (0x07)
RSA-3072 (0x05)*
RSA-4096 (0x16)*
 prime P 0x01
prime Q 0x02
prime p exponent dP 0x03
prime q exponent dQ 0x04
CRT coefficient QInv 0x05
ECC-P-256 (0x11)
ECC-P-384 (0x14)
 private value s 0x06
Ed25519 (0xE0)* seed 0x07*
X25519 (0xE1)* seed 0x08*

Move a Key

Keys can be moved from any slot except F9 (attestation) to any other slot except F9 using the instruction 0xF6.

Moving a Key
CLA 00
INS F6
P1 Destination slot
  9A, 9C, 9D, 9E,
  82, 93, 84, 85, 86, 87, 88, 89, 8A, 8B, 8C, 8D, 8E, 8F,
  90, 91, 92, 93, 94, 95
P2 Source slot
  9A, 9C, 9D, 9E,
  82, 93, 84, 85, 86, 87, 88, 89, 8A, 8B, 8C, 8D, 8E, 8F,
  90, 91, 92, 93, 94, 95
  P2

Delete a Key

Any key can be deleted from any slot, including F9 (Attestation) using the instruction 0xF6 with a value of 0xFF for P1.

Deleting a Key
CLA 00
INS F6
P1 FF
P2 Source slot
  9A, 9C, 9D, 9E,
  82, 93, 84, 85, 86, 87, 88, 89, 8A, 8B, 8C, 8D, 8E, 8F,
  90, 91, 92, 93, 94, 95
  F9

YubiKey PIV Metadata

YubiKey 5 PIV metadata enables services and client software to obtain information about PIV keys from a central location, which means it is no longer necessary to query PIV attestation. The YubiKey PIV application can therefore report on characteristics of cryptographic keys in the specified PIV slot. Integration with CMS vendors is thus facilitated by YubiKey PIV metadata.

PIV metadata was already available starting with the 5.3.0 firmware. For details, see the Get Metadata section of the PIV extensions.

PIN Complexity

This feature prevents users from adopting simple patterns or common PINs, and thereby significantly reduces the risk of users setting easily guessable PINS on their devices. PIN Complexity is available on YubiKeys with firmware version 5.7.0 and later; however,

Note

The PIN complexity feature is available only with custom configuration, specified before you order keys.

When PIN complexity is enabled:

  • It applies to all the applications on the YubiKey that process PINs.

  • The PINs for the different applications are all still separate and distinct, but they will all follow the same set of rules.

  • It is applied to PINs for the following protocols on the YubiKey:

    • FIDO2
      • PIN
    • PIV
      • PIN
      • PUK
    • OpenPGP
      • user PIN
      • admin PIN
      • reset code
    • yubihsm-auth
      • credential PINs
      • YubiKey access codes
    Unicode Characters

    In firmware 5.7, the support for Unicode PINs has been extended to include the PIV and OpenPGP applications. Each unicode code point is counted as a single character.

    PIN Blocking

    The PINs that will be blocked are those that:

    • Are less than 6 characters
    • Contain only one unicode character, e.g. 111111
    • Are on the following blocklist:
      • 123456
      • 123123
      • 654321
      • 123321
      • 112233
      • 121212
      • 123456789
      • password
      • qwerty
      • 12345678
      • 1234567
      • 520520
      • 123654
      • 1234567890
      • 159753
      • qwerty123
      • abc123
      • password1
      • iloveyou
      • 1q2w3e4r

Expanded Storage (FIDO2 and OATH)

The FIDO2 and OATH applications both have increased storage capacity. FIDO2 has been increased to 100 discoverable credentials (aka Passkeys), and OATH storage has been increased to 64 seeds. As before, all storage limits are per-application, so users can store data up to the maximum for each application simultaneously for a potential total of 190 credentials:

  • Up to 100 passkeys
  • 24 PIV certificates (limited by overall memory used)
  • 64 OATH seeds
  • 2 OTP seeds

Restricted NFC

Restricted NFC mode prevents wireless device manipulation before a YubiKey NFC with the 5.7 firmware is taken out of its blister pack or other packaging such as a tray. To ensure that these keys cannot be tampered with during shipping, this mode is enabled by default on new NFC keys with the 5.7 firmware.

When these keys are taken out of their packaging, the only permitted action via the NFC connection is reading the URL configured by Yubico on the NDEF tag set by Yubico. Because both major mobile OSs read NDEF tags and open URLs by default, users immediately learn how to disable Restricted NFC mode. The NDEF tag is set to https://www.yubico.com/getting-started/.

When tapped against a mobile device, a YubiKey 5.7 NFC will cause the browser to open to the configured URL with the instructions for enabling full NFC operation. The end user is instructed to plug the key into USB power such as a USB charger or computer USB port for 3 seconds. This action is sufficient to disable Restricted NFC mode. The user can re-enable the restriction as often as they desire using ykman or the Yubico Authenticator.

Yubico Crypto Library

Over the past few years Yubico has developed a library in-house that performs the underlying cryptographic operations (encryption, signing, etc.) for RSA and ECC.

Click for Yubico Support.