Tensor G2 UFS Inline Storage Encryption Cryptographic Module

Certificate

Approved Algorithms (3)

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

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;

Security Policy, page by page

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

This document is the non-proprietary FIPS 140-3 Security Policy for the Tensor G2 UFS Inline Storage Encryption Cryptographic Module. It contains a specification of the rules under which the module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for a Security Level 1 Software-Hybrid cryptographic module. This security policy is for the validation of the Tensor G2 UFS Inline Storage Encryption Cryptographic Module. In this document, the terms “Tensor G2 UFS Inline Storage Encryption Cryptographic Module”, “cryptographic module” or “module” are used interchangeably to refer to the Tensor G2 UFS Inline Storage Encryption Cryptographic Module with Software version 1.2.0 and Hardware version 4.1.0. Table 1-1 Security Levels 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:

• UFS Pixel FIPS CMVP Module (Module’s Software Component, version 1.2.0)
• UFS ISE (Module’s Hardware Component, version 4.1.0) The UFS Pixel FIPS CMVP Module (hereafter referred to as ISE Driver) is the software component of the cryptographic module running in the Linux Kernel, which calls the cryptographic algorithms for the module’s pre-operational self-tests, and also sets the FIPS status of the entire cryptographic module once the preoperational self-test is completed successfully. The UFS ISE is the hardware component of the cryptographic module that supports AES-XTS encryption and decryption. This hardware resides in the Google Tensor G2 processor, located between the device’s DRAM and the Flash Storage Device so it can provide inline encryption/decryption while maintaining device performance (such as responsiveness and power consumption). Please see Figures 1, 2 and 3 below for more information.

The module is specified in the following table. Table 2-1 Tested Operational Environments The table below lists approved cryptographic algorithms employed by the module: Table 2-2 Approved Algorithms Notes:

• Not all CAVP tested modes of the algorithms are used in this module
• According to SP 800-38E, the AES algorithm in XTS mode can be only used for the cryptographic protection of data on storage devices, as specified in SP800-38E. In addition, the length of a single data unit encrypted with the XTS-AES shall not exceed 220 AES blocks, that is, 16 MiB of data. In addition, to meet the requirement in FIPS 140-3 IG C.I, the module implements a check to ensure that the two AES keys (Key 1 and Key 2) used in XTS-AES algorithm are not identical. The module always runs in the Approved Mode of Operation and does not implement any Non-Approved Security Functions. The module doesn't support degraded operational mode. Block Diagram In the following diagram, the bidirectional arrows depict the flow of the status, control and data within the device’s Tested Operational Environment’s Physical Perimeter (TOEPP). The TOEPP in the block diagram contains the module (the blue dotted region). The operations within the module’s cryptographic boundary (the blue dotted region) use the cipher from the UFS ISE (Module’s hardware component) that is included in the used at module’s initialization to perform the pre-operational self-tests. The module’s executable file is ufspixel-fips140.ko kernel loadable module.

Figure

1. Module’s Block Diagram Figure
2. Tested Platform Physical Perimeter

Figure

3. Module’s Hardware Block Diagram
4. Cryptographic Module Interfaces The module’s physical perimeter encompasses the case of the tested platform mentioned in Table 2-1. The module provides its logical interfaces via Application Programming Interface (API) calls. The logical interfaces provided by the module are mapped onto the FIPS 140-3 interfaces (data input, data output, control input, Table 3-1 Ports and Interfaces

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 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:

• 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. Table 4-2 Approved Services

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.

5. Software/Firmware Security Integrity Techniques To ensure software security, a software integrity test is performed on the runtime image of the module. The HMAC-SHA2-256 (HMAC Cert. #A2938) implemented in the module is used as an approved algorithm for the integrity test. If the test fails, the module enters an error state where no cryptographic services are provided, and data output is prohibited. The module is provided in the form of binary executable code. On-Demand Integrity Test Software Integrity test is performed as part of the Pre-Operational Self-Tests. It is automatically executed at power-on. Thus, it can be invoked by rebooting the tested platform.
6. Operational Environment The module operates in a modifiable operational environment per FIPS 140-3 Security Level 1 Specifications. The operating system is restricted to a single operator mode of operation. The procurement, build and configuring procedure are controlled. The module is installed into a commercial production grade mobile device. The external application that makes calls to the cryptographic module is the single instance of the cryptographic module, even when the application is serving multiple clients.
7. Physical Security The Module is a software-hybrid module that operates on a multi-chip standalone platform, which conforms to the Level 1 requirements for physical security. All disjoint components of the module are entirely contained within the production-grade enclosure of the host platform, which blocks physical access to the module. The tested platform (mobile device) shall comprise production grade components with standard passivation (a sealing coat applied over the chip circuitry to protect it against environmental and other physical damage) and a production grade enclosure that completely surrounds the cryptographic module.
8. Non-invasive Security The module does not support Non-invasive Security. Thus, the security requirements from Section Non-invasive Security in FIPS 140-3 are not applicable.

9. Sensitive Security Parameter Management Table 9-1 SSPs Establishment Use & related Security Zeroization Key/SSP/ Strength Generation Name Type Cert. Export Storage keys 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 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

• Pre-Operational Software Integrity Self-Tests
• HMAC-SHA2-256 KAT
• Software Integrity Test (using HMAC-SHA2-256) The module software integrity test parameters are configured at build time and then executed at runtime. As the module supports KASLR and is not loaded as a contiguous block, a series if begin/end addresses (__fips140_text_start/__fips140_text_end and __fips140_rodata_start/__fips140_rodata_end) are used to determine the code that must be checked. The HMAC value (ufs_pixel_fips_hmac_key) of that code is then calculated when building the ELF, storing the calculated digest (ufs_pixel_fips_hmac_expected) in the module. The driver is a kernel loadable module included in the vendor image for the kernel and loaded once the ramdisk holding all the kernel modules has been unpacked into memory. Once the module is loaded, the HMAC-SHA2-256 is calculated over the entire area specified as part of the build process. This is then compared to the stored value (ufs_pixel_fips_hmac_expected) from the build time calculation. A non-match will place the module into the error state. The Module conducts HMAC-SHA2-256 KAT self-test before the integrity test is performed. Conditional Algorithm Self-Tests (CASTs)
• Conditional cryptographic algorithm tests
• AES-XTS Encryption Know Answer Test (KAT)
• AES-XTS Decryption KAT
• HMAC-SHA2-256 KAT
• SHA2-256 KAT The module conducts the CASTs before the first operational use of the cryptographic algorithm. Periodic/On-Demand Self-Test

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.

11. Life-cycle Assurance The module is enabled by default (and hence used automatically) as part of the device without any user configuration. The module always runs in the Approved Mode of Operation and does not implement any NonApproved Security Functions. When the module is loaded or instantiated (after being powered off, rebooted, etc.), the module runs pre-operational self-tests without any operator intervention. The Module will be operated in an approved mode of operation when pre-operational self-tests have completed successfully. The module is provided directly to solution developers and is not intended for direct download by the general public. The module is installed on an operating system (Linux kernel 5.10) specified in Section
12. Additional Rules of Operation:
13. The module does not support concurrent operators.
14. The operating system is responsible for multitasking operations so that other processes cannot access the address space of the process containing the module.
15. The end user of the operating system is also responsible for zeroizing SSPs via wipe/secure delete procedures
16. Mitigation of Other Attacks The module does not support Mitigation of Other Attacks. Thus, the security requirements from Section Mitigation of Other Attacks in FIPS 140-3 are not applicable.