OpenSK Cryptographic Module

Certificate

Approved Algorithms (11)

Security Levels (Table 1)

Derived Review-Risk Graph (review prompts, not findings)

flowchart LR
  %% Deterministic review-risk graph for OpenSK Cryptographic Module
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[high] Firmware update / recovery<br/>/ rollback services<br/><i>Vendor_Upgrade</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Data Encryption/Decryptio n<br/>Wink Command<br/>FIDO U2F: U2F_Register</i>"]
    C4["[high] Physical/logical<br/>interfaces (some 'blocked<br/>in firmware')<br/><i>USB pins (D+ and D-)</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>IPSEC<br/>no library/version identified</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Trusted code is reachable<br/>through update and<br/>recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    I4["Interface reachability may<br/>vary by boot stage and<br/>lifecycle state."]
    I5["Possible only, a protocol<br/>is referenced, but whether<br/>it is a live channel or<br/>only a KDF/algorithm name<br/>is unconfirmed."]
  end
  subgraph Risk["Reviewer question"]
    R2["Are update images<br/>authenticated before<br/>parsing, and are<br/>downgrade/rollback paths<br/>constrained?"]
    R3["Can unauthenticated<br/>services leak state,<br/>consume resources, or<br/>transition security state?"]
    R4["Are interfaces blocked<br/>before the bootloader<br/>runs, or only after<br/>approved mode starts?"]
    R5["If a live TLS/SSH/IKE<br/>channel exists, could<br/>library CVEs apply, or is<br/>this only a<br/>KDF/documentation name?"]
  end
  subgraph Evidence["Evidence needed to close"]
    E2["update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
    E3["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    E4["lifecycle reachability<br/>matrix · boot-stage<br/>interface timing ·<br/>factory/recovery/error-state<br/>access controls"]
    E5["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>library identity and<br/>version ·<br/>certificate-validation<br/>behaviour · protocol-CVE<br/>disposition"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C4 --> I4 --> R4 --> E4
  C5 --> I5 --> R5 --> E5
  classDef clue fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef infer fill:#fff7e6,stroke:#b98500,color:#6b4e00;
  classDef risk fill:#fbe9e9,stroke:#b02a2a,color:#7a1f1f;
  classDef evidence fill:#e6f4ea,stroke:#1e7d34,color:#14532d;
  class C2,C3,C4,C5 clue;
  class I2,I3,I4,I5 infer;
  class R2,R3,R4,R5 risk;
  class E2,E3,E4,E5 evidence;

flowchart LR
  %% Deterministic clue tier for OpenSK Cryptographic Module
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[high] Firmware update / recovery / rollback services<br/><i>Vendor_Upgrade</i><br/>src: securityPolicy.services"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Data Encryption/Decryptio n<br/>Wink Command<br/>FIDO U2F: U2F_Register</i><br/>src: securityPolicy.services"]
    C4["[high] Physical/logical interfaces (some 'blocked in firmware')<br/><i>USB pins (D+ and D-)</i><br/>src: securityPolicy.portsAndInterfaces"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>IPSEC<br/>no library/version identified</i><br/>src: text:keyword"]
  end
  classDef clueHigh fill:#eef3f9,stroke:#2f6fb0,stroke-width:2px,color:#1f3a5f;
  classDef clueMedium fill:#eef3f9,stroke:#6f7f91,color:#1f3a5f;
  classDef clueLow fill:#f7f7f7,stroke:#999,stroke-dasharray:4 4,color:#444;
  class C2,C3,C4 clueHigh;
  class C5 clueLow;

Security Policy, page by page

Google, LLC. OpenSK Cryptographic Module Document Version 1.0 October 15th, 2025 Prepared by: www.lightshipsec.com Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module Table of Contents Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module List of Tables List of Figures Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

This document is the non-proprietary FIPS 140-3 Security Policy for the Google, LLC. OpenSK Cryptographic Module (running firmware version 4.0.2), hereafter referred to as, “the module”. It contains the security rules under which the module must operate and describes how the module meets the requirements as specified in FIPS PUB 140-3 for

The table below describes the individual security areas of FIPS 140-3, as well as the Security Levels of those individual areas. N/A Table 1: Security Levels Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Purpose and Use: The module is a USB 1.1/2.0 compliant Client To Authenticator Protocol (CTAP) 2.1 token, instantiated as a single chip hardware module, used for first or second factor authentication. It is also backwards compatible with Universal 2nd Factor (U2F, also known as CTAP1). CTAP standardizes how request and response messages are sent over the USB transport to the CTAP key. After registration, a user can use their Security Key with an origin-specific key pair across all online services that implement WebAuthn. CTAP and WebAuthn are both part of FIDO2, a set of standards for online authentication. The Security Key performs two operations that focus on authentication (with a backwards compatible alternative): MakeCredential (or U2F Register) associates a key pair (or credential) with an origin, google.com here, while GetAssertion (or U2F Authenticate), verifies that signature with the Titan Security Key, Chip Boundary to prove physical possession of the hardware second factor. Then, and only then, is the User able to authenticate to Google services. In addition, CTAP 2.1 provides functionality related to this process: GetInfo lists information about the Security Key. ClientPin allows setting up a PIN to unlock some of the Security Key commands. Reset performs a factory reset by deleting all stored user data, including credentials. CredentialManagement allows listing and deleting existing credentials. Selection performs a user presence check, so users can indicate what device they want to use. LargeBlobs lets you read and write a binary string to store inside the security key. There are two custom commands that are not part of the CTAP specification. Both are used for upgrading the firmware: One that provides detailed information about the running firmware version, and the other to send the new, signed firmware binary. The chip runs a version of OpenSK that manages all access control, cryptographic algorithms and the life cycle of all keys. OpenSK is an app running on top of a version of TockOS, which manages all low-level resources. Module Type: Hardware Module Embodiment: SingleChip Module Characteristics: Cryptographic Boundary: The cryptographic boundary of the module is the outer perimeter of the chip, as shown in the figures below. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Figure 1: OpenSK Cryptographic Module (Block Diagram) Figure 2: OpenSK Cryptographic Module (Front and Back) Tested Operational Environment’s Physical Perimeter (TOEPP): The module is a single-chip module as defined by FIPS 140-3. The hardware version of the module is H1B2G.

Tested Module Identification

• Hardware: Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module Table 2: Tested Module Identification

• Hardware Tested Module Identification
• Software, Firmware, Hybrid (Executable Code Sets): N/A for this module. Tested Module Identification
• Hybrid Disjoint Hardware: N/A for this module. Tested Operational Environments - Software, Firmware, Hybrid: N/A for this module. Vendor-Affirmed Operational Environments - Software, Firmware, Hybrid: N/A for this module. CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate.

There are no components within the cryptographic boundary that are excluded from the FIPS 140-3 security requirements.

Modes List and Description: The table below details the Modes of Operation supported by the module. Table 3: Modes List and Description Mode Change Instructions and Status: The module implements only one mode of operation, the approved mode, in which the approved services are available. No configuration is necessary for the module to operate and remain in the approved mode. After passing all pre-operational self-tests and cryptographic algorithm self-tests executed on start-up, the module automatically transitions to the approved mode.

Approved Algorithms: The table below lists all the Approved Algorithms supported by the module. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Table 4: Approved Algorithms Vendor-Affirmed Algorithms: The table below lists all the Vendor-Affirmed Algorithms supported by the module. D.H Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: The table below lists all the Non-Approved, Allowed Algorithms supported by the module. N/A Table 6: Non-Approved, Allowed Algorithms Non-Approved, Allowed Algorithms with No Security Claimed: The table below lists all the Non-Approved, Allowed Algorithms with No Security Claimed. Table 7: Non-Approved, Allowed Algorithms with No Security Claimed The module supports largeBlobKey FIDO extension functionality where an external party can encode an arbitrary string of bits on the device. No security is claimed for this encoded arbitrary data is considered the equivalent to plaintext. Non-Approved, Not Allowed Algorithms: The module does not support any Non-Approved Algorithms that are not Allowed in the Approved Mode of Operation. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module N/A for this module.

The table below lists the Security Function Implementations supported by the module. n n DigSigSigGen DigSigSigVer T SP 80056Ar3 T SP 80056Cr2 HMACSHA2-256: KAS-ECCSSC Sp80056Ar3: SP80056Cr2: Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module HMACSHA2-256: HMACSHA2-256: Table 8: Security Function Implementations

There is no algorithm specific information. The tables below detail the modules ESV information. Table 9: Entropy Certificates Table 10: Entropy Sources The module generates a minimum of 256 bits of entropy for key generation. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The module generates Keys and SSPs in accordance with FIPS 140-3 IG D.H. The cryptographic module performs Cryptographic Key Generation (CKG) for asymmetric keys as per SP 800-133r2 (vendor affirmed), compliant with FIPS 186-4, and using DRBG compliant with SP 800-90A]. A seed (the random value) used in asymmetric key generation is obtained from SP 800-90A DRBG. The key generation service for ECDSA, as well as the SP 800-90A DRBG have been ACVP tested with algorithm certificates found in Approved Algorithms Table.

The module provides SP 800-56Arev3 compliant key establishment according to FIPS 140-3 IG D.F scenario 2 path (1) with ECDH shared secret computation. A Hash-Based KDF specified in NIST SP 800-56Crev2 is used as the Key Derivation Algorithm. The module provides key transport according to FIPS 140-3 IG D.G using an approved key wrapping technique based on AES-CBC and HMAC-SHA2-256.

The module does not implement any industry protocols. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The table below details the module Ports and Interfaces. D-) N/A N/A N/A Table 11: Ports and Interfaces All communication between the module and a host device is conducted in accordance with the U2F and CTAP protocol. The U2F protocol is based on a request-response mechanism, where a requester sends a request message to a U2F device, which always results in a response message being sent back from the U2F device to the requester. All request-response messages are framed in ISO7816-4:2005 APDU format. This specifies how to transport the raw message and any error codes if the command failed. The CTAP2 protocol supports longer messages using CTAPHID. The CTAPHID messages are encoded in CBOR. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The module does not support authentication for roles. N/A for this module.

The module supports two roles that an operator may assume: Crypto Officer (CO) role and User role. Roles are assumed implicitly based on the service accessed. The table below lists the roles supported by the module. Table 12: Roles

The table below lists all approved services supported by the module. The abbreviations of the access rights to keys and SSPs have the following interpretation: G = Generate: The module generates or derives the SSP. R = Read: The SSP is read from the module (e.g., the SSP is output). W = Write: The SSP is updated, imported, or written to the module. E = Execute: The module uses the SSP in performing a cryptographic operation. Z = Zeroise: The module zeroises the SSP. N/A N/A V: E Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module n G,E n G,E y G,E G,E G Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module W,E G G,R :R V: E E Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module E V: E R,E W,E Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module V: E E E Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module G,E W,E R G,E V: G,E E Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module E G,E W,E R Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module V: E G,E Z: G,E G,E G,E G,R,E W Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module V: Z y Z n Z n Z Z Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module Z Z Z: Z Z Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module Z Z Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module e Z Z Z E,Z Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module e ondemand selftests by e e Table 13: Approved Services Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The module does not support any Non-Approved Services. N/A for this module.

The module supports external firmware loaded for upgrades. An Approved ECDSA Signature Verification (P-256, SHA2-256) firmware load test operation is performed prior to a firmware upgrade. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The integrity of the executable firmware is verified by comparing a SHA2-256 digest calculated at boot time with the SHA2-256 digest value stored in the module that was computed at build time.

The integrity test is performed as part of the pre-operational self-tests, which are executed when the module is initialized. The integrity test can be invoked on demand via reboot or power-cycle the module, which will perform (among others) the firmware integrity test. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Type of Operational Environment: Limited How Requirements are Satisfied: The limited modifiable operational environment of the module prevents users from accessing secret keys, private keys or SSPs which they are not authorized to access. There was no logical or physical access to the SSPs. The module is designed to accept only controlled firmware changes that successfully pass the software/firmware load test. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The table below details the Physical Security Mechanisms supported by the module. N/A N/A N/A Table 14: Mechanisms and Actions Required The module has a single-chip embodiment that employs standard passivation techniques and meets commercial grade specs regarding power and voltage ranges, temperature, reliability, and shock/vibration. The module is encased in an opaque, tamper-evident, removal-resistant IC packaging material which cannot be removed or penetrated without causing serious damage to the module (i.e. the module will not function). The table below details the module Environmental Failure Testing information. Table 15: EFP/EFT Information

The table below details the module Hardness Testing Temperature Ranges. Table 16: Hardness Testing Temperatures Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Currently, the ISO/IEC 19790:2012 non-invasive security area is not required by FIPS 140-3 (see NIST SP 800-140F). The requirements of this area are not applicable to the module. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The table below lists Sensitive Security Parameters (SSPs) storage areas for the module. Section 9.4 below selects from the storage areas listed and specifies the appropriate parameter in the “Storage” column if applicable to a specific SSP. Table 17: Storage Areas

The table below lists SSP input and output methods for the module. Section 9.4 below selects from the input and output methods listed and specifies the appropriate parameter in the “Inputs/Outputs” column if applicable to a specific SSP. N/A N/A Table 18: SSP Input-Output Methods

The table below lists SSP zeroisation methods for this module. Section 9.4 below selects from the zeroisation methods listed and specifies the appropriate parameter in the “Zeroization” column if applicable to a specific SSP. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module Table 19: SSP Zeroization Methods

The following table summarizes the keys and Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module: n h N/A N/A N/A N/A Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module n h n n n n Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module n h e serverside y y y n n n n n n n n n Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module n h n n n n n m6 Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module n m for hmacsecret hmacsecret hmacsecret h n n n n Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module n h y y y n n n n n n Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module n h Table 20: SSP Table 1 Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module N/A N/A N/A N/A Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module U2F/ServerSide FIDO2/ServerSide Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module d N/A N/A Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module N/A N/A Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module N/A U2F/ServerSide N/A N/A N/A Table 21: SSP Table 2

Per FIPS 140-3, IG C.K FIPS 186-4 CAVP tests performed are mathematically identical to FIPS 186-5 CAVP tests, therefore the module can claim FIPS 186-5 compliance for these tests. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

This section specifies the pre-operational and conditional self-tests performed by the module. The pre-operational and conditional self-tests ensure that the module is not corrupted and that the cryptographic algorithms work as expected.

Pre-operational Self-Tests are run upon the power up/initialization of the module. The module transitions to the operational state only after the pre-operational self-tests (and the cryptographic algorithm self-tests (CASTs)) are passed successfully. The design of the module ensures that all data output, via the data output interface, is inhibited whenever the module is in a pre-operational self-test condition. The Pre-Operational Self-Tests are detailed in the table below. Table 22: Pre-Operational Self-Tests

Conditional Self-Tests are run when an applicable security function or process is invoked. The Conditional Self-Tests are detailed in the table below. s s n HMACSHA2-256 n (FIPS1864) (FIPS1864) KASECC-SSC NIST P256 n NIST P256 n NIST P256 l l l l l n Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module s SP 80090Ar1 HMACSHA2256 (FIPS1864) NIST P256 HMACSHA2-256 NIST P256 e W SP80056Cr2 s l n n n l l l l l t n n N/A n Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module s SP 80090B 4.4.2 e SP 80090B 4.4.2 s Table 23: Conditional Self-Tests The module performs self-tests on all approved cryptographic algorithms supported in the approved mode of operation, using the tests shown in the table above. To ensure all conditional CASTs are performed prior to the first operational use of the associated algorithm, all CASTs are performed during the module’s initial power-up sequence. The CASTs for algorithms used in the pre-operational firmware integrity test are performed prior to the integrity test itself; all other CASTs are executed immediately after the successful completion of the firmware integrity test. Services are not available, and data output (via the data output interface) is inhibited during the self-tests. If any of these tests fails, the module transitions to the error state.

Pre-operational self-tests can be run on-demand, for periodic testing, by rebooting the module. Table 24: Pre-Operational Periodic Information Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module Table 25: Conditional Periodic Information

If any of the Pre-operational Self-Tests or Conditional Self-Tests fail, the module will output an error status and enter an error state, where all data output is inhibited. Upon entering an error state, an operator can attempt to clear the error state by removing the module from the USB port and reinserting it to restart the module. If the error state cannot be cleared, the module must be returned to the manufacturer. The table below shows the different causes that lead to the Error States and the status indicators reported. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

OpenSK Cryptographic Module Table 26: Error States Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

No configuration of the module or installation steps are required from the operator. When the module is powered on its power-up self-tests are executed without any operator intervention. The module enters in approved mode automatically if the power-up self-test completes successfully. If any of the self-tests fail during power-up, the module transitions to an Error state. The operator can verify that the module is in the Approved mode of operation and that the FIPS validated version is being used, by checking the version output using the "Vendor_Sysinfo" command and comparing it against the versioning information on the module certificate. The status of the module can be determined by the availability of the module or by executing the “Show Status” service. If the module is available, it has passed all self-tests. If it is unavailable, it is in the error state.

None. Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

The module is protected against the following non-invasive attacks: Fault Injection: Code signing Execution gating Storage parity Transmission parity Power On Self-Test Voltage monitoring Temperature monitoring Internal clock Active Security Shield Side-Channel Attacks: Constant-time (data-independent) code execution Random insertion of wait states Jittery clock Power masking Data blinding TRNG Entropy Churning Computation Throttling Google, LLC. 2025 This document may be reproduced and distributed only in its original entirety without revision.

Referenced URLs

• www.lightshipsec.com