- 5.7 Firmware Specifics
- View page source
This section provides detailed descriptions of the features enabled by the 5.7 firmware (includes 5.6.x).
- CTAP 2.1 Feature Summary
- FIDO2 Extensions
- Enterprise Attestation
- Minimum PIN Length and Minimum PIN Length Extension
- Force PIN Change
- Always User Validation
- Blob Storage
- FIDO Level 2
- PIV Enhancements
- PIN Complexity
- Expanded Storage (FIDO2 and OATH)
- Restricted NFC
- Yubico Crypto Library
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.
FIDO2 Extensions
| New Capabilities | YubiKey 5 Series | Security Key Series | Security Key Series Enterprise Edition |
|---|---|---|---|
| PIN Management Flexibility | |||
Temporary FIDO2 PIN can be set (forces user to change upon next use) | Yes | Yes | Yes |
| Configure FIDO2 minimum PIN length | Yes | Yes | Yes |
| Enhanced Asset Tracking | |||
Capable of Enterprise Attestation (requires custom configuration) | 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 | |
| Enhanced Smart Card Capabilities (PIV) | |||
| RSA-3072 and RSA-4096 support | Yes | ||
| Ed25519 and X25519 key types | Yes | ||
| Future-proofed for Compliance | |||
| Enhanced PIN complexity | Yes Requires custom config | Yes Enabled by default | |
| Default minimum PIN length of 6 | Yes | ||
| Enhanced Credential Storage | |||
| Support for 100 passkeys | Yes | Yes | Yes |
| Support for 24 PIV certificates | Yes | ||
| Support for 64 OATH credentials | Yes | ||
| Support for 2 OTP seeds | Yes | ||
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 YubiKey Manager/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. The Relying Party (RP), if configured via an allowed list configured on the YubiKey, 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 has 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 SupportForce PIN change only requires support on the platform, and can only be set by communicating with the YubiKey directly. Chrome and some Chromium-based browsers support it. Windows 11 is required on Windows platforms.
There is no need for explicit RP support, the force PIN change (
forcePINChange) flag is set on the client/platform side, which is where it will trigger the flow.
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).
Prior to the release of the 5.4.2 firmware, the PIV management key was a TDES key. This feature expanded the management key type held in PIV slot 9b 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.
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.
| 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.
| 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.
| 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 is available with the 5.3.0 firmware. For details, see the Get Metadata section of the PIV extensions.
PIN Complexity
PIN Complexity is available on YubiKeys with firmware version 5.7.0 and later.
Note
The PIN complexity feature is available only with custom configuration, specified before you order keys.
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.
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
- FIDO2
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 the Yubico Authenticator or the YubiKey Manager/ykman.
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.
Cookies | Privacy Policy
