Non-Proprietary FIPS 140-2 Security Policy Google LLC. Cr50 U2F Cryptographic Library Firmware version: 1.0.1 Hardware version: H1B2P Date: September 19, 2023 Prepared By: 2400 Research Blvd, Suite 395 Rockville, MD 20850 Google LLC 2023 Version 1.0 Page 2 of 15 Public Material – May be reproduced only in its original entirety (without revision). Introduction Federal Information Processing Standards Publication 140-2 — Security Requirements for Cryptographic Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but Unclassified environment. The National Institute of Standards and Technology (NIST) and Canadian Centre for Cyber Security (CCCS) Cryptographic Module Validation Program (CMVP) run the FIPS 140 program. NVLAP accredits independent testing labs to perform FIPS 140-2 testing; the CMVP validates modules meeting FIPS 140-2 validation requirements. Validated is the term given to a module that is documented and tested against the FIPS 140-2 criteria. More information is available on the CMVP website at: http://csrc.nist.gov/groups/STM/cmvp/index.html About this Document This non-proprietary Cryptographic Module Security Policy for the Cr50 u2F Cryptographic Library from Google LLC. provides an overview of the product and a high-level description of how it meets the overall Level 1 security requirements of FIPS 140-2. The Cr50 u2F Cryptographic Library may also be referred to as the “module” in this document. Disclaimer The contents of this document are subject to revision without notice due to continued progress in methodology, design, and manufacturing. Google LLC. shall have no liability for any error or damages of any kind resulting from the use of this document. Notices This document may be freely reproduced and distributed in its entirety without modification. Google LLC 2023 Version 1.0 Page 3 of 15 Public Material – May be reproduced only in its original entirety (without revision). Table of Contents Introduction 2 Disclaimer 2 Notices 2 1. Introduction 5 1.1 Scope 5 1.2 Overview 5 2. Security Level 5 3. Cryptographic Module Specification 6 3.1 Cryptographic Boundary 6 4. Modes of Operation 8 5. Cryptographic Module Ports and Interfaces 8 6. Roles, Services and Authentication 8 7. Physical Security 10 8. Operational Environment 10 9. Cryptographic Algorithms and Key Management 11 9.1 Cryptographic Algorithms 11 9.2 Non-Approved Algorithms 11 9.3 Cryptographic Key Management 12 9.4 Key Generation 12 9.5 Key Storage and Zeroization 13 10. Self-tests 13 10.1 Power-On Self-Tests 13 10.2 Conditional Self-Tests 14 10.3 Critical Function Tests 14 11. Mitigation of Other Attacks 14 12. Crypto Officer and User Guidance 14 13. Glossary 15 Google LLC 2023 Version 1.0 Page 4 of 15 Public Material – May be reproduced only in its original entirety (without revision). List of Tables Table 1- Security Level 5 Table 2- Physical Port and Logical Interface Mapping 8 Table 3– Approved Services, Roles and Access Rights 9 Table 4– non-Approved or non-security relevant services 9 Table 5 - Approved Algorithms in firmware 11 Table 6- Approved Algorithms in hardware 11 Table 7- Non-Approved Algorithms 11 Table 8- Approved Keys and CSPs 12 Table 9- Power-On Self-Tests 13 Table 10 - Conditional Self-Tests 14 Table 11 - Glossary of Terms 15 List of Figures Figure 1- GSC Chip Physical Boundary (Front) 6 Figure 2 - GSC Chip Physical Boundary (Back) 6 Figure 3– Cr50 Cryptographic Library Boundary Block 7 Figure 4- Tamper Evidence and damage to the module 10 Google LLC 2023 Version 1.0 Page 5 of 15 Public Material – May be reproduced only in its original entirety (without revision). 1. Introduction 1.1 Scope This document describes the cryptographic module security policy for the Google LLC. Cr50 u2F Cryptographic Library firmware-hybrid module. It contains a specification of the security rules, under which the cryptographic module operates, including the security rules derived from the requirements of the FIPS 140-2 standard. 1.2 Overview The Cr50 U2F Cryptographic Library is a firmware-hybrid module residing in the Google LLC Google Security Chips (GSC) (Hardware Version: H1B2P) chip (Single-Chip embodiment). The GSC contains an ARM V7-M CPU which the firmware runs on. The module is responsible for low-level cryptographic primitives on Google Security Chips (GSC) used in recent versions of Google Chromebooks. The module’s functionality is focused on primitives required to implement the FIDO2/WebAuthn Authenticator model. This standard permits users to log into internet accounts using their Chromebooks with Cr50 U2F with physical presence verification. Cr50 is the Chrome Operating System firmware running on the GSC chip which is considered a non- modifiable operational environment. The firmware portion of the module can utilize full hardware algorithm implementations in the GSC chip for hashing, keyed-hashing and big-number operations in its Approved mode of operation. The module performs Approved key generation, signature generation, random bit generation, keyed- hashing and signature verification operations in support of U2F-related requests in Cr50. 2. Security Level The following table lists the level of validation for each area in FIPS 140-2: FIPS 140-2 Section Title Validation Level Cryptographic Module Specification 1 Cryptographic Module Ports and Interfaces 1 Roles, Services, and Authentication 1 Finite State Model 1 Physical Security 3 Operational Environment N/A Cryptographic Key Management 1 Electromagnetic Interference / Electromagnetic Compatibility 1 Self-Tests 1 Design Assurance 1 Mitigation of Other Attacks N/A Overall Level 1 Table 1- Security Level Google LLC 2023 Version 1.0 Page 6 of 15 Public Material – May be reproduced only in its original entirety (without revision). 3. Cryptographic Module Specification 3.1 Cryptographic Boundary The cryptographic boundary is the outer perimeter of the chip shown in the below figure. The physical embodiment is a single-chip module as defined by FIPS 140-2. The hardware version of the GSC chip is H1B2P. Figure 1- GSC Chip Physical Boundary (Front) Figure 2 - GSC Chip Physical Boundary (Back) Google LLC 2023 Version 1.0 Page 7 of 15 Public Material – May be reproduced only in its original entirety (without revision). The logical boundary is depicted in the block diagram below: Figure 3– Cr50 Cryptographic Library Boundary Block Google LLC 2023 Version 1.0 Page 8 of 15 Public Material – May be reproduced only in its original entirety (without revision). 4. Modes of Operation The module supports two modes of operation: Approved and Non-Approved. The module will be in FIPS- approved mode when all power up Self-Tests have completed successfully, and only Approved or allowed algorithms are invoked. See Table 5 and 6 (below) for a list of the supported Approved algorithms. The non-Approved mode is entered when a non-Approved algorithm is invoked. See Table 7 for a list of non-Approved algorithms. 5. Cryptographic Module Ports and Interfaces The module provides the following number of physical and logical interfaces to the device, and the physical interfaces provided by the module are mapped to the FIPS 140-2 defined logical interfaces: data input, data output, control input, status output, and power. The logical interfaces and their mapping are described in the following table: FIPS 140-2 Interface Physical Port/Interface Module Interface (API) Data Input Assigned pins to USB, I2C, SPI, UART and GPIO on the H1B2P chip API input parameters Data Output Assigned pins to USB, I2C, SPI, UART and GPIO on the H1B2P chip API output parameters and return values Control Input Assigned pins to USB, I2C, SPI, UART and GPIO on the H1B2P chip API input parameters Status Output Assigned pins to USB, I2C, SPI, UART and GPIO on the H1B2P chip API return values Power Input Assigned pins to USB, I2C, SPI, UART and GPIO on the H1B2P chip N/A Table 2- Physical Port and Logical Interface Mapping As a firmware-hybrid module, control of the physical pins on the GSC chip is outside the module scope. When the module is performing self-tests, or is in an error state, all output on the module’s logical data output interfaces and access to the cryptographic functions in hardware are inhibited. 6. Roles, Services and Authentication The cryptographic module implements both User and Crypto Officer (CO) roles. The module does not support user authentication. The User and CO roles are implicitly assumed by the entity accessing services implemented by the module. A user is considered the owner of the thread that instantiates the module and, therefore, only one concurrent user is allowed. The Approved services supported by the module and access rights within services accessible over the module’s public interface are listed in the table below: Service Approved security functions Keys and/or CSPs Roles Access rights to keys and/or CSPs Module Initialization N/A N/A CO N/A Keyed hashing HMAC-SHA-256 HMAC key User, CO Execute Hashing SHA-256 None User, CO N/A Google LLC 2023 Version 1.0 Page 9 of 15 Public Material – May be reproduced only in its original entirety (without revision). Service Approved security functions Keys and/or CSPs Roles Access rights to keys and/or CSPs Signature generation/ verification ECDSA (P-256) ECDSA public and private key User, CO Write/Execute Key Generation ECDSA (P-256) ECDSA public and private key User, CO Write/Execute Attestation ECDSA (P-256) ECDSA private key User, CO Write/Execute Generate and Sign U2F Certificate ECDSA (P-256) ECDSA private key User, CO Write/Execute Random Bit Generation TRNG HMAC_DRBG User, CO Write/Execute On-Demand Self-test N/A N/A User, CO Execute Zeroization N/A All keys User, CO Write/Execute Show status N/A N/A User, CO N/A Table 3– Approved Services, Roles and Access Rights The module provides the following non-Approved services which utilize algorithms listed in Table 4: Service Non-Approved Functions Keys and/or CSPs Symmetric encryption/decryption AES (non-compliant) N/A Authenticated Symmetric encryption/decryption AES GCM (non-compliant) N/A Wegman-Carter polynomial hashing Ghash (non-compliant) N/A Signature generation/ verification RSA (non-compliant) N/A Key Encapsulation (asymmetric encryption/decryption) RSA (non-compliant) N/A Key Generation RSA (non-compliant) N/A Hashing (TPM2) SHA1/SHA2-384/SHA2-512 N/A Table 4– non-Approved or non-security relevant services Google LLC 2023 Version 1.0 Page 10 of 15 Public Material – May be reproduced only in its original entirety (without revision). 7. Physical Security The module is a single-chip cryptographic module which meets the requirements for opacity and tamper evidence. The module is encased in 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 physical security mechanism is a hard, opaque packaging. The module hardness testing was performed at a single ambient temperature of 72 °F. No assurance is provided for Level 3 hardness conformance at any other temperatures. Figure 4- Tamper Evidence and damage to the module 8. Operational Environment The module’s operational environment (Cr50) is non-modifiable. The module does not contain a mechanism to update its firmware. Google LLC 2023 Version 1.0 Page 11 of 15 Public Material – May be reproduced only in its original entirety (without revision). 9. Cryptographic Algorithms and Key Management 9.1 Cryptographic Algorithms The module implements the following approved algorithms in the firmware: CAVP Cert # Algorithm Sizes Standard Mode/Method Use Vendor Affirmed CKG N/A SP 800-133r2 N/A Seed for asymmetric key pair generation with B=U. A2353 ECDSA P-256 FIPS 186-4 Signature Generation Component, Key Pair Generation, Signature Generation, Signature Verification Digital Signature Services HMAC 256-bits FIPS 198-1 HMAC-SHA-256 Generation, Authentication SHS 256-bits FIPS 180-4 SHA-256 Digital Signature Generation, Digital Signature Verification, non-Digital Signature Applications DRBG HMAC-SHA-256 SP 800-90Arev1 HMAC_DRBG Random Bit Generation Table 5 - Approved Algorithms in firmware The module implements the following approved algorithms in the hardware: CAVP Cert # Algorithm Sizes Standard Mode/Method Use N/A TRNG P NIST SP 800-90B ENT Entropy source utilized for random bit generation A2352 SHS 256-bits FIPS 180-4 SHA-256 Digital Signature Generation, Digital Signature Verification, Conditioning Function, non- Digital Signature Applications HMAC 256-bits FIPS 198-1 HMAC-SHA-256 Generation, Authentication Table 6- Approved Algorithms in hardware 9.2 Non-Approved Algorithms The following non-approved usages are associated with the legacy PIN encryption/decryption service and TPM2 hashing service listed in Table 4. Algorithm Use AES (non-conformant) Encryption and Decryption EC DH (non-conformant) Key Agreement (P-256) RSA (non-conformant) Key Generation; Signature generation/ verification; Key Encapsulation (asymmetric encryption/decryption) SHS (non-conformant) Message digest TPM2 (SHA-1, SHA-384, SHA-512) Table 7- Non-Approved Algorithms Google LLC 2023 Version 1.0 Page 12 of 15 Public Material – May be reproduced only in its original entirety (without revision). 9.3 Cryptographic Key Management The module supports the following CSPs listed below in Table 5. The CSP access policy is denoted in Table 3 above. Keys and CSPs Description Algorithm and Key Size Generation / Input Output Storage U2F Entropy Input (Stored Seed) Entropy to seed DRBG upon initial instantiation 512 bits Internally generated. Output via API in plaintext FLASH U2F HMAC key MAC for authentication of key handles HMAC SHA-256 Internally generated. Output via API in plaintext FLASH Device ID for u2F Device unique key HMAC SHA-256 Internally generated. Output via API in plaintext FLASH ECDSA Public/ Private key pair Signing key per user/ origin ECDSA P-256 Internally generated. Output via API in plaintext RAM Entropy Input (direct from TRNG)1 Entropy to seed DRBG after first instantiation 576-bits Input via API in plaintext Does not exit the module RAM System DRBG State V and Key values 256-bits Internally generated. Does not exit the module RAM Table 8- Approved Keys and CSPs 9.4 Key Generation The module includes an SP 800-90A Approved DRBG. The module requests a minimum of 256-bits of entropy from the entropy source for use in key generation. The module generates symmetric keys in accordance with IG D.12 and SP 800-133rev2, Section 4. The Approved DRBG seeded by an SP 800-90B conformant entropy source. The module retrieves entropy from a physical (ENT-P) noise source residing inside the physical boundary in alignment with Scenario 1 (b) described in FIPS 140-2 IG 7.14. The module also implements a factory-derived entropy pool consistent with IG 7.14 2(a) which is filled from an entropic source at manufacturing time prior to shipping. An estimated 512-bits of full entropy is loaded at the factory. 1 Per SP 800-90B, the initial entropy estimate of a binary noise source is calculated as HI=min(Horiginal, Hsubmitter). As a result, HI=min(0.80, 0.79) = 0.79. Google LLC 2023 Version 1.0 Page 13 of 15 Public Material – May be reproduced only in its original entirety (without revision). 9.5 Key Storage and Zeroization The cryptographic module does not perform persistent storage of keys. Keys and CSPs are passed to the module by the calling application. The keys and CSPs are stored in memory in plaintext. Keys and CSPs residing in internally allocated data structures (during the lifetime of an API call) can only be accessed using the module defined API. The operating system protects memory and process space from unauthorized access. All private or secret keys are zeroized either at session termination or by power-cycling the module. The output data path is provided by the data interfaces and is logically disconnected from processes performing key generation or zeroization. No key information will be output through the module’s data output interface when keys are zeroized. 10. Self-tests FIPS 140-2 requires the module to perform self-tests to ensure the integrity of the module and the correctness of the cryptographic functionality at start up. Some functions require conditional tests during normal operation of the module. The supported tests are listed and described in this section. 10.1 Power-On Self-Tests Power-on self-tests for both the hardware and firmware algorithm implementations are run upon the initialization of the module and do not require operator intervention to run. If any of the tests fail, the module will not initialize. The module will enter an error state and no services can be accessed. The module implements the following power-on self-tests in the Cr50 u2F Cryptographic Library: Type Test Description Integrity Test ● SHA-256 hash over the executable firmware image Known Answer Test ● ECDSA (Signature Generation and Verification. Curve: P-256) ● HMAC (Generation and Verification with SHA-256) ● SHS (SHA-256) ● SP 800-90 HMAC_DRBG KAT including SP 800-90A Health Tests, required per IG C.1 Table 9- Power-On Self-Tests The Power-on self-tests can be run on demand by rebooting the module or by issuing the “on-demand self-test command via the module’s API. Google LLC 2023 Version 1.0 Page 14 of 15 Public Material – May be reproduced only in its original entirety (without revision). 10.2 Conditional Self-Tests Conditional self-tests are run during operation of the module. If any of these tests fail, the module will enter an error state, where no services can be accessed by the operators. The module can be re- initialized to clear the error and resume FIPS mode of operation. Each module performs the following conditional self-tests: Type Test Description Pair-wise Consistency Test ECDSA Key Pair generation SP 800-90B Health Tests Adaptive proportion test and repetition count test performed on startup, on demand and continuously. Table 10 - Conditional Self-Tests 10.3 Critical Function Tests The module does not implement any specific critical function tests. 11. Mitigation of Other Attacks No specific claims for this section. 12. Crypto Officer and User Guidance 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 the Approved mode of operation automatically if the power-up self-tests complete successfully, and only Approved or allowed algorithms are invoked. The non-Approved mode is entered when a non- Approved algorithm is invoked. See Table 7 for a list of non-Approved algorithms. If any of self-tests fail during power-up, the module will transition to an error state. The status of the module can be determined by the availability of the module. If the module is available, it has passed all self-tests. If it is unavailable, it is in the error state or has not been properly initialized. Google LLC 2023 Version 1.0 Page 15 of 15 Public Material – May be reproduced only in its original entirety (without revision). 13. Glossary Acronym Definition ADB Android Debug Bridge AES Advanced Encryption Standard API Application Programming Interface CAVP Cryptographic Algorithm Validation Program CBC Cipher-Block Chaining CCCS Canadian Centre for Cyber Security CFB Cipher Feedback CKG Cooperative Key Generation CMVP Crypto Module Validation Program CO Cryptographic Officer CPU Central Processing Unit CSP Critical Security Parameter DH Diffie-Hellman DRBG Deterministic Random Bit Generator DSS Digital Signature Standard EC Elliptic Curve ECB Electronic Code Book ECC Elliptic Curve Cryptography EC DH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature Authority FIPS Federal Information Processing Standards GCM Galois/Counter Mode HMAC Key-Hashed Message Authentication Code IG Implementation Guidance KAT Known Answer Test LLC Limited Liability Company N/A Not-Applicable NIST National Institute of Standards and Technology NDRNG Non-Deterministic Random Number Generator NVLAP National Voluntary Lab Accreditation Program RAM Random Access Memory RSA Rivest Shamir Adleman SHA Secure Hash Algorithm SHS Secure Hash Standard SP Special Publication Table 11 - Glossary of Terms