1. Home
  2. Secure Domain
  3. Technical Deep Dive

    Introduction

    Yubico’s YubiKey 5 FIPS Series is currently undergoing FIPS 140-3 validation. This article provides a technical examination of two key protocols, Secure Channel Protocol 11 (SCP11) and Client-to-Authenticator Protocol 2.2 (CTAP2.2), detailing how they enable YubiKeys to meet the stringent FIPS 140-3 requirements for cryptographic modules, especially over USB and NFC interfaces.

    FIPS 140-3: Core Security Requirements for Cryptographic Modules

    FIPS 140-3, succeeding FIPS 140-2, is the NIST standard specifying security requirements for cryptographic modules. Validation signifies that a module has undergone rigorous testing by accredited labs, covering aspects like cryptographic algorithm implementation, key management, physical security, and authentication mechanisms. The YubiKey 5 FIPS Series chipset is certified at Physical Security Level 3, providing tamper-evidence and tamper-resistance.

    YubiKeys as FIPS-Compliant Authenticators

    YubiKeys function as hardware security tokens, offering phishing-resistant multi-factor authentication (MFA). The YubiKey 5 FIPS Series targets Authenticator Assurance Level 3 (AAL3) of NIST SP800-63B. This requires hardware-based cryptography and robust protection against various attack vectors. SCP11 and CTAP2.2 are integral to achieving this.

    Secure Channel Protocol 11 (SCP11) Deep Dive

    Overview and Advantages over SCP03

    SCP11, defined by GlobalPlatform, is an asymmetric protocol employing Elliptic Curve Cryptography (ECC) and X.509 certificates to establish a secure communication channel between a host and a YubiKey (acting as a Secure Element).

    Key advantages of SCP11 over the symmetric SCP03 include:

    • No Pre-shared Secret Requirements: Eliminates the operational burden and risk of distributing and managing symmetric keys for each YubiKey-host pair.

    • Dynamic Trust Relationships: Leverages a Public Key Infrastructure (PKI) with certificate authorities (CAs) for trust management, allowing new systems and YubiKeys to establish secure connections without prior explicit pairing.

    • Scalable Deployment: Centralized trust management via CAs supports secure communication for thousands of YubiKeys with multiple systems.

    • Enhanced Security Separation: Asymmetric private keys never leave their respective devices (host or YubiKey), maintaining strong security boundaries.

    Cryptographic Algorithms in SCP11

    SCP11 utilizes several FIPS-approved cryptographic algorithms:

    • Elliptic Curve Cryptography (ECC) using NIST P-256 curves for key agreement and digital signatures.

    • AES-GCM (Advanced Encryption Standard - Galois/Counter Mode) for authenticated encryption of the secure channel.

    • SHA-256 (Secure Hash Algorithm 256-bit) for hashing functions.

    • X.509 certificate-based authentication for verifying the identity of communicating parties.

    Yubico’s SCP11 Implementation

    Yubico has implemented a subset of the GlobalPlatform SCP11 specification, focusing on its most secure variants, ensuring both command and response messages are MACed and encrypted. This implementation is available in YubiKey firmware 5.7.2 and later.

    YubiKeys support two primary SCP11 variants:

    • SCP11a: Provides mutual authentication, typically used for secure communication with Credential Management Systems (CMS) for provisioning or managing credentials on the YubiKey.

    • SCP11b: Provides unilateral authentication (card-to-host), typically used by client applications (e.g., mobile apps, physical access readers) to establish a secure channel with the YubiKey, especially over NFC.

    SCP11b: Client-to-YubiKey Secure Channel (Detailed Flow)

    SCP11b establishes a secure channel where the YubiKey authenticates itself to the client.

    SCP11b Flow

    1. Authentication Phase (YubiKey to Client) & Initial Key Material Exchange

      1. Client → YubiKey: INITIALIZE UPDATE The client application sends an INITIALIZE UPDATE command to the YubiKey, providing a client nonce (host challenge). Purpose: Initiates the secure channel process and provides the client’s initial random data for key derivation.

      2. YubiKey → Client: INITIALIZE UPDATE Response The YubiKey responds with:

        • Its ephemeral public key (e.g., One-Time Ephemeral Card Encryption Key - OCECKEC).

        • Other key derivation data (e.g., key information, YubiKey’s nonce/card challenge).

        • A Card Authenticator (a cryptogram generated by the YubiKey). Purpose: YubiKey provides its ephemeral key material and a cryptographic proof of its identity.

      3. Client-Side Authentication & Shared Secret Computation:

        • The client generates its own ephemeral key pair (public and private keys).

        • The client uses its newly generated ephemeral private key and the YubiKey’s ephemeral public key to compute a shared secret (via ECDH).

        • Using this shared secret (or keys derived from it), the client verifies the YubiKey’s Card Authenticator.

        • If successful, the YubiKey is now authenticated to the client.

    II. Key Exchange Completion Phase

    1. Client-Side Preparation & Transmission to YubiKey:

      • The client computes a "Host Cryptogram" (or receipt).

      • Client → YubiKey: EXTERNAL AUTHENTICATE command, containing:

        • The client’s ephemeral public key.

        • The Host Cryptogram/Receipt. Purpose: Client provides its ephemeral key material and confirms correct processing to the YubiKey.

    2. YubiKey-Side Shared Secret Computation & Verification:

      • The YubiKey uses its ephemeral private key and the client’s ephemeral public key to compute the shared secret.

      • The YubiKey verifies the Host Cryptogram/Receipt.

    III. Secure Channel Established

    1. Session Key Derivation & Channel Activation:

      • Both client and YubiKey derive session keys (S-ENC, S-MAC, S-RMAC) from the shared secret.

      • The secure channel is now active for protected communication.

    This is particularly valuable for NFC interactions, protecting against eavesdropping.

    SCP11a: CMS-to-YubiKey Secure Channel (Detailed Flow)

    SCP11a provides mutual authentication, essential for sensitive management operations.

    SCP11a Flow

    1. Authentication Phase (Mutual) & Key Exchange Initiation

      1. Prerequisite: Certificate Infrastructure Both CMS and YubiKey possess ECKA certificates from a trusted CA.

      2. CMS → YubiKey: INITIALIZE UPDATE Command Includes Host Challenge and optionally CMS’s certificate (CERT.Host.ECKA). Purpose: Initiate negotiation, provide CMS challenge and certificate.

      3. YubiKey → CMS: INITIALIZE UPDATE Response Includes:

        • YubiKey’s certificate (CERT.SD.ECKA).

        • YubiKey’s Ephemeral Public Key.

        • Card Challenge.

        • Card Authenticator (cryptogram). Purpose: YubiKey provides its certificate, ephemeral key, challenge, and authenticator.

      4. CMS-Side Processing: YubiKey Authentication & Shared Secret Computation (Part 1)

        • CMS verifies YubiKey’s certificate.

        • Generates its own ephemeral key pair.

        • Computes shared secret using its private ephemeral key and YubiKey’s public ephemeral key.

        • Derives intermediate keys.

        • Verifies YubiKey’s Card Authenticator.

        • If successful, YubiKey is authenticated to CMS. Purpose: CMS validates YubiKey, computes shared secret, confirms YubiKey’s authenticity.

    II. Key Exchange Completion & Second Half of Mutual Authentication (CMS to YubiKey)

    1. CMS → YubiKey: EXTERNAL AUTHENTICATE Command Includes:

      • CMS’s Ephemeral Public Key.

      • CMS’s certificate (CERT.Host.ECKA) if not sent earlier.

      • Host Authenticator (cryptogram computed by CMS). Purpose: CMS provides its ephemeral key, certificate, and authenticator.

    2. YubiKey-Side Processing: CMS Authentication & Shared Secret Computation (Part 2)

      • YubiKey verifies CMS’s certificate.

      • Computes shared secret using its private ephemeral key and CMS’s public ephemeral key.

      • Derives intermediate keys.

      • Verifies Host Authenticator.

      • If successful, CMS is authenticated to YubiKey. Mutual authentication is complete. Purpose: YubiKey validates CMS, computes shared secret, confirms CMS’s authenticity.

    III. Secure Channel Established

    1. Session Key Derivation & Channel Activation

      • Both CMS and YubiKey derive final session keys from the shared secret.

      • The secure channel is active.

    SCP11 Data Confidentiality and Integrity

    SCP11 ensures both confidentiality (eavesdropping resistance) and integrity (tampering resistance). Each command’s MAC value is chained from the previous one, preventing tampering and replay attacks.

    Client-to-Authenticator Protocol 2.2 (CTAP2.2) Deep Dive

    Role in FIDO2 and User Verification (PIN/UV)

    CTAP is part of the FIDO2 framework, defining communication between clients (browsers, operating systems) and authenticators (YubiKeys) over transports like USB and NFC. CTAP2.2 enhances security, especially for PIN/User Verification (UV) mechanisms critical for FIPS 140-3.

    A key design principle of CTAP2 is that plaintext PINs are never sent to the authenticator from the client platform if the pinUvAuthProtocol is used. This mitigates risks from compromised client platforms.

    With FIPS 140-3 in view, Yubico implemented CTAP2.1 (and by extension, 2.2) improvements for FIDO2 PIN, such as Force PIN Change and Minimum PIN Length features.

    Protecting PIN Transmission

    The CTAP2 PIN/UV authentication protocol (specifically pinUvAuthProtocolOne or pinUvAuthProtocolTwo) uses an Elliptic Curve Diffie-Hellman (ECDH) key agreement to establish a shared secret between the client platform and the YubiKey for the PIN operation. Encryption and authentication keys are then derived from this shared base key. The protocol employs AES-CBC for encrypting PIN data and HMAC with SHA-256 for authentication, ensuring the PIN itself is protected during transit to the authenticator where it is verified.

    For YubiKeys targeting FIPS 140-3:

    • PINs are encrypted during transmission via the CTAP2 pinUvAuthProtocol.

    • PIN complexity (minimum 6 characters for FIPS YubiKeys, up to 63 alphanumeric) is enforced.

    • Secure key derivation is used for PIN protection mechanisms.

    Protected Use Cases

    CTAP2.2, in conjunction with FIDO2, enables:

    • Passwordless authentication flows.

    • Phishing-resistant multi-factor authentication.

    • Secure authorization for financial transactions.

    • Protected administrative access to critical systems.

    Mapping SCP11 and CTAP2.2 to FIPS 140-3 Technical Requirements

    Cryptographic Module Security Levels (FIPS 140-3 Section 4)

    SCP11 and CTAP2.2 contribute by:

    • Employing FIPS-approved cryptographic algorithms (ECC P-256, AES, SHA-256).

    • Implementing secure key establishment and management.

    • Providing strong, hardware-backed authentication mechanisms.

    • Ensuring secure communication channels.

    The YubiKey 5 FIPS Series can be used in an Overall Security Level 1 or 2 FIPS environment, with the chipset providing Physical Security Level 3.

    Secure Key Management and Derivation (NIST SP 800-133)

    Both protocols align with NIST SP 800-133:

    • Secure Generation: Ephemeral session keys in SCP11 and CTAP2 PIN protocol are generated securely.

    • Key Diversification: Session keys are unique per session.

    • Protection: Cryptographic keys are protected in transit (via secure channel or encrypted PIN protocol) and at rest (private keys never leave the YubiKey).

    • Key Separation: SCP11 uses dynamic, internally generated session keys distinct from static transport keys.

    Authentication Mechanisms and Entropy Requirements (NIST SP 800-63B)

    YubiKey FIPS Series supports AAL3 of NIST SP800-63B. SCP11 and CTAP2.2 contribute via:

    • Hardware-based cryptographic operations.

    • Support for multi-factor authentication (possession of YubiKey + PIN/biometric).

    • High-entropy key generation for session keys.

    • Certificate-based authentication (SCP11a).

    • Protection against replay and man-in-the-middle attacks.

    PIN Brute-Force Attack Protection

    The YubiKey implements robust anti-brute-forcing for PINs:

    • FIPS-compliant YubiKeys enforce a minimum PIN length of 6 characters.

    • The FIDO2 application on YubiKeys supports lockout after a specific number of failed attempts (e.g., 3 failed PIN attempts for FIDO2 might render the PIN unusable until reset, or 8 total might block the credential).

    • Increasing time delays can be implemented by the client platform based on authenticator feedback.

    • PIN reset for FIDO2 typically requires resetting the FIDO application on the YubiKey, a process implying physical presence.

    • The PIV functionality has its own well-defined PIN retry counters and unblocking mechanisms.

    FIPS-Compliant Authentication Workflows in Detail

    Scenario 1: NFC Access Control with SCP11b

    Employee approaches a secure door with an NFC-enabled YubiKey.

    1. Access control reader activates and initiates communication with the YubiKey.

    2. Reader sends INITIALIZE UPDATE command to the YubiKey (includes Reader nonce).

    3. YubiKey responds to INITIALIZE UPDATE with:

      • Key derivation data.

      • YubiKey’s ephemeral public key.

      • A Card Authenticator.

    4. Reader generates its own ephemeral key pair.

    5. Reader calculates shared secret using its private key and YubiKey’s public key.

    6. Reader verifies YubiKey’s Card Authenticator. If successful, YubiKey is authenticated.

    7. Reader computes Host Cryptogram/Receipt.

    8. Reader sends EXTERNAL AUTHENTICATE to YubiKey with Reader’s ephemeral public key and Host Cryptogram.

    9. YubiKey verifies Host Cryptogram, derives session keys.

    10. Secure channel established; subsequent communication is encrypted and MACed.

    11. Reader requests authentication credentials (e.g., a challenge to be signed).

    12. YubiKey performs cryptographic operation and returns signed data.

    13. Access control system verifies signature, grants access. This SCP11b flow protects the NFC link from eavesdropping and tampering.

    Scenario 2: Secure Government Cloud Access with CTAP2.2

    Government administrator accesses FedRAMP cloud environment requiring AAL3 via agency mobile device.

    1. Cloud provider (Relying Party) prompts for YubiKey authentication via NFC.

    2. Administrator taps YubiKey to mobile device.

    3. Cloud provider (via browser/client) sends authenticatorGetAssertion request with userVerification="required".

    4. Browser/client platform prompts for PIN (min 6-char for FIPS YubiKeys).

    5. Administrator enters PIN.

    6. PIN is securely transmitted to YubiKey using CTAP2.2 pinUvAuthProtocol (encrypted).

    7. YubiKey verifies PIN internally.

    8. Upon successful PIN verification, YubiKey locates FIDO2 credential for the cloud provider (rpId).

    9. YubiKey signs the challenge from authenticatorGetAssertion using the hardware-backed private key.

    10. Digital signature (assertion) is returned to client, then to cloud provider.

    11. Cloud provider verifies signature, grants access. CTAP2.2 ensures phishing-resistant MFA, and the PIN protocol protects user verification over NFC/USB.

    Implementation Considerations for FIPS Compliance

    Organizations should:

    • Ensure YubiKey applications (PIV, FIDO2, OATH, SCP11-accessible applets) are placed in FIPS-approved mode of operation, typically during initialization by a Crypto Officer.

    • Adhere to PIN policies (length, complexity, retry limits) mandated by FIPS and NIST SP 800-63B.

    • Utilize FIPS-validated YubiKey firmware versions.

    • Ensure client applications and management systems correctly implement their side of SCP11 and CTAP2.2 protocols.

    Conclusion

    SCP11 and CTAP2.2 are foundational for the YubiKey 5 FIPS Series' compliance with FIPS 140-3. They provide secure channels, robust authentication mechanisms, and protection for cryptographic keys and operations, enabling organizations to meet stringent federal security requirements.

    Further Technical Resources