| Standard | FIPS 140-3 |
|---|---|
| Overall level | 1 |
| Module type | Software-hybrid |
| Embodiment | Multi-Chip Stand Alone |
| Status | Historical |
| Caveat | Interim Validation |
| Vendor | Google, LLC |
| Algorithm | ACVP Cert |
|---|---|
| AES-XTS | A2268 |
| HMAC-SHA2-256 | A2268 |
| SHA2-256 | A2268 |
flowchart LR
%% Deterministic review-risk graph for Tensor G2 UFS Inline Storage Encryption Cryptographic Module
%% Review prompts and evidence gaps, NOT vulnerability findings.
subgraph CMVP["CMVP-disclosed clues"]
C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>Update</i>"]
C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>self-test<br/>status output</i>"]
C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</i>"]
end
subgraph Inference["Derived inference"]
I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
I3["Possible only, some<br/>services may process input<br/>before, or without,<br/>operator authentication."]
I6["Possible only, a<br/>runtime/OS is referenced,<br/>but its membership in the<br/>cryptographic boundary is<br/>not established."]
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?"]
R6["If the OS/runtime is<br/>in-boundary, could its<br/>CVEs be hidden by<br/>firmware-only versioning?"]
end
subgraph Evidence["Evidence needed to close"]
E2["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>update image format ·<br/>signature-before-parse<br/>proof · anti-rollback /<br/>downgrade policy"]
E3["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
E6["confirm the disclosure<br/>itself (keyword hit,<br/>context unverified) ·<br/>runtime identity and<br/>config · kernel/runtime<br/>hardening profile ·<br/>patch/backport manifest"]
end
C2 --> I2 --> R2 --> E2
C3 --> I3 --> R3 --> E3
C6 --> I6 --> R6 --> E6
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,C6 clue;
class I2,I3,I6 infer;
class R2,R3,R6 risk;
class E2,E3,E6 evidence;flowchart LR
%% Deterministic clue tier for Tensor G2 UFS Inline Storage Encryption 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["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>Update</i><br/>src: text:keyword"]
C3["[low] Self-test / status surface (referenced in text)<br/><i>self-test<br/>status output</i><br/>src: text:keyword"]
C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>linux<br/>kernel</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,C6 clueLow;Google, LLC. Non-Proprietary FIPS 140-3 Security Policy for Tensor G2 UFS Inline Storage Encryption Cryptographic Module Software Version: 1.2.0 Hardware Version: 4.1.0 Documentation Version : 1.1 Last Update: June 18, 2024 This document may be freely distributed in its entirety without modification
| # | Section | Page |
|---|
Overall Security Level 1 2. Cryptographic Module Specification The module is a multi-chip standalone Software-Hybrid module designed for on-the-fly hardware encryption for a flash storage device. The module’s cryptographic boundary includes the following components:
The module is specified in the following table. Component Type Version UFS Pixel FIPS CMVP Module Software 1.2.0 UFS ISE Hardware 4.1.0 The module has been tested on the following platforms. Table 2-1 Tested Operational Environments Operating Systems Tested Platform Processor on the Tested PAA\Acceleration Hardware Versions Platforms Linux Kernel 5.10 Google Pixel 7 Google Tensor G2 With PAA The table below lists approved cryptographic algorithms employed by the module: Table 2-2 Approved Algorithms CAVP Algorithm Mode / Method Description / Use / Function Cert and Key Size(s) / Standard Key strength(s) #A2937 AES AES-XTS 256 bits Symmetric Encryption/Decryption [FIPS 197; SP 800-38E] #A2938 HMAC HMAC-SHA2- At least 112 bits Software integrity test [FIPS 198-1] 256 #A2938 SHA SHA2-256 N/A Pre-requisite algorithm of HMAC[FIPS 180-4] SHA2-256 used for software integrity test Notes:
Figure
Figure
4. Roles, Services and Authentication The module supports Crypto Officer (CO). The cryptographic module does not provide any authentication methods. The module does not allow concurrent operators. The Crypto Officer is implicitly assumed based on the service requested. The module provides the following services to the Crypto Officer. Table 4-1 Roles, Service Commands, Input and Output Role Service Input Output Module’s Hardware Component Crypto Officer (CO) AES-XTS Key and message (plaintext Encrypted message or encryption and message for Encryption or Decrypted message decryption cipher text for decryption) Module’s Software Component Crypto Officer (CO) Show Version API Command to get Module’s ID and module’s version component’s versions (SW and HW) Crypto Officer (CO) Perform Self-Tests On-Demand Self-Test (Power Pass/Fail status cycling) Note: Return value of 1 for success; Failure results in panic to kernel Crypto Officer (CO) Show Status API Command to check the Module’s operational status status Crypto Officer (CO) Perform Zeroization API Command to zeroize all Zeroized and released SSPs memory space Table 4-2 defines the relationship between access to SSPs and the different module services. The modes of access shown in the table are defined as:
Service Description Approved Keys and/or Roles Access Indicator Security SSPs Rights to Functions SSPs Show Status Show module’s N/A N/A CO N/A None current status Perform Zeroize the SSPs N/A AES-XTS CO Z None Zeroization stored in the module Key Note: With regard to the Indicator defined in FIPS 140-3 standard, as the Module is always operated in the approved mode (without the Operator’s configuration), the service successful completion status will be functioning as the Indicator.
9. Sensitive Security Parameter Management Table 9-1 SSPs Establishment Use & related Security Zeroization Key/SSP/ Strength Generation Function and Import/ Name Type Cert. Export Storage keys AES- 256 AES-XTS N/A Import: N/A Temporarily Power down Used for XTS Key bits Entered via stored in the tested Symmetric Cert # Module’s Module's platform Encryption A2937 API hardware and (plaintext) registers. Decryption Export: No Notes: Key Generation The module does not provide any key generation service or perform any key generation for any of its Approved algorithms. Keys are instead provided by third party applications and stored in memory location outside of the cryptographic module boundary (i.e., within a DMA descriptor located in memory within the Tested Operational Environment’s Physical Perimeter (TOEPP) of the tested platform). The module does not support any key establishment methods or asymmetric algorithms and hence no key generation services for them. Key Entry and Output The module does not support manual key entry or key output. SSP (AES-XTS Key is the only SSP) can only be exchanged via a DMA descriptor inside the TOEPP of the device. All SSPs are entered to module per the request from the module’s calling application running on the same tested platform. Keys/SSPs are electronically entered into the module via Module’s API in plaintext form. The Module doesn’t output the SSPs. Key Storage The module does not provide persistent keys/SSPs storage. After the SSP (AES-XTS Key is the only SSP) is entered to the module via the Module’s API, the module temporarily stores it in the Module’s hardware register. The Module’s hardware register is internal to the hardware module and is not shared with any external component (operating system or other hardware). No process other than the module itself can access the keys/SSPs in its memory. Key Zeroization All SSPs are zeroized when the system is powered down. Input and output interfaces are inhibited while zeroization is performed. The successful act of powering off the module serves as the implicit indicator of zeroization.
10. Self-Tests When the module is loaded or instantiated (after being powered off, rebooted, etc.), the module runs preoperational self-tests. The operating system is responsible for the initialization process and loading of the library. The module is designed with a default entry point (DEP) which ensures that the self-tests are initiated automatically when the module is loaded. Prior to the module providing any data output via the data output interface, the module would perform and pass the pre-operational self-tests. Following the successful preoperational self-tests, the module would execute the Conditional Cryptographic Algorithm Self-tests (CASTs). The self-test success or failure is output as a return value of the library load API call, which is functioning as the self-test status indicator. If one of the self-tests fails, the module transitions into an error state and outputs the error message via the module’s status output interface. While the module is in the error state, all data through the data output interface and all cryptographic operations are disabled. The error state can only be cleared by reloading the module. All self-tests must be completed successfully before the module transitions to the operational state. Below are the details of the self-tests conducted by the module. Pre-Operational Self-Tests
The module performs on-demand self-tests initiated by the operator, by powering off and powering the module back on. The full suite of self-tests is then executed. The same procedure may be employed by the operator to perform periodic self-tests.