Qualcomm® Inline Crypto Engine (UFS)

Certificate

Approved Algorithms (2)

Security Levels (Table 1)

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

flowchart LR
  %% Deterministic review-risk graph for Qualcomm® Inline Crypto Engine (UFS)
  %% 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>Recovery</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>AES ECB<br/>AES XTS<br/>Show Status</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i>"]
  end
  subgraph Inference["Derived inference"]
    I2["Possible only, trusted<br/>code is reachable through<br/>update and recovery paths."]
    I3["Some services may process<br/>input before, or without,<br/>operator authentication."]
    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?"]
    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["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["pre-auth reachability<br/>matrix · rate limits and<br/>output redaction ·<br/>abuse-case tests"]
    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
  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,C5 clue;
  class I2,I3,I5 infer;
  class R2,R3,R5 risk;
  class E2,E3,E5 evidence;

flowchart LR
  %% Deterministic clue tier for Qualcomm® Inline Crypto Engine (UFS)
  %% 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>Recovery</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>AES ECB<br/>AES XTS<br/>Show Status</i><br/>src: securityPolicy.services"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>HTTPS<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,C5 clueLow;
  class C3 clueHigh;

Security Policy, page by page

Qualcomm Technologies, Inc. Qualcomm® Inline Crypto Engine (UFS) Prepared by: atsec information security corporation

Austin, TX 78759 www.atsec.com

Qualcomm® Inline Crypto Engine (UFS) Table of Contents

Qualcomm® Inline Crypto Engine (UFS)

Qualcomm® Inline Crypto Engine (UFS) List of Tables List of Figures

Qualcomm® Inline Crypto Engine (UFS)

This document is the non-proprietary FIPS 140-3 Security Policy for versions 3.2.1 and 4.0.1 of the Qualcomm® 1 Inline Crypto Engine (UFS) Cryptographic Module. It contains the security 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 an overall Security Level 1 module.

In preparing the Security Policy document, the laboratory formatted the vendor-supplied documentation for consolidation without altering the technical statements therein contained. The further refining of the Security Policy document was conducted iteratively throughout the conformance testing, wherein the Security Policy was submitted to the vendor, who would then edit, modify, and add technical contents. The vendor would also supply additional documentation, which the laboratory formatted into the existing Security Policy, and resubmitted to the vendor for their final editing.

1 Snapdragon and Qualcomm branded products are products of Qualcomm Technologies,

Inc. and/or its subsidiaries.

Qualcomm® Inline Crypto Engine (UFS)

Purpose and Use: The Qualcomm® Inline Crypto Engine (UFS) Cryptographic Module is classified as a sub-chip hardware module in a single chip embodiment for the purpose of FIPS 140-3 validation. It provides AES-XTS encryption and decryption of block storage devices as defined in SP 80038E. The underlying AES for AES-XTS is compliant to FIPS 197. The module includes separate AES Engines for encryption and decryption for both ECB and XTS mode. Module Type: Hardware Module Embodiment: SingleChip Module Characteristics: SubChip Cryptographic Boundary: The cryptographic boundary of the Qualcomm Inline Crypto Engine (UFS) is the sub chip component shown with blue box. The module has been tested on the platforms which form the physical perimeter for the module. Consequently, the embodiment of the Qualcomm Inline Crypto Engine (UFS) is a single-chip cryptographic module. Below is an illustrative diagram. Figure 1: Block Diagram

Qualcomm® Inline Crypto Engine (UFS) Figure 2: Snapdragon® XR2 Gen 2 Platform Figure 3: Snapdragon X Elite Compute Platform Figure 4: Snapdragon X1 Plus Tested Operational Environment’s Physical Perimeter (TOEPP): The TOEPP of the module is defined as the entire system-on-chip.

Qualcomm® Inline Crypto Engine (UFS) Tested Module Identification

• Hardware: N/A 4.0.1 N/A 4.0.1 N/A Table 2: Tested Module Identification
• Hardware N/A N/A N/A

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

Modes List and Description: Nonapproved Table 3: Modes List and Description When the Qualcomm Inline Crypto Engine (UFS) starts up successfully, after passing all the pre-operational self-tests, the module is operating in the approved mode of operation by default and can only be transitioned into the non-Approved mode by calling one of the nonApproved services. Section 4 provides details on the service indicator implemented by the The Qualcomm Inline Crypto Engine (UFS) can be configured to operate in one of the following two settings where the settings can be changed prior to each service request:

• Full Disk Encryption (FDE) that performs an encryption of all write operations and a decryption of all read requests with one key.
• Per-File Encryption (PFE) that performs an encryption of one write operation and a decryption of one read operation with a key dedicated to this operation. The Qualcomm Inline Crypto Engine (UFS) supports a key storage outside of the boundary which allows up to 64 software selectable key contexts. Each context holds 2 AES keys needed for AES-XTS. One such context may be used for FDE or otherwise all 64 contexts may be used for PFE. When an encryption configuration is established, the chosen software

Qualcomm® Inline Crypto Engine (UFS) selected context key is referenced and will be used for the operation by the Qualcomm Inline Crypto Engine (UFS).

Approved Algorithms: Table 4: Approved Algorithms Vendor-Affirmed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms: N/A for this module. Non-Approved, Allowed Algorithms with No Security Claimed: N/A for this module. Non-Approved, Not Allowed Algorithms: Table 5: Non-Approved, Not Allowed Algorithms

Qualcomm® Inline Crypto Engine (UFS) Table 6: Security Function Implementations

The length of a single data unit encrypted or decrypted with AES XTS shall not exceed 220 AES blocks of data per XTS instance. An XTS instance is defined in Section 4 of SP 800-38E. To meet the requirement stated in IG C.I, the module implements a check to ensure that the two AES keys used in AES XTS mode are not identical. The XTS mode shall only be used for the cryptographic protection of data on storage devices. It shall not be used for other purposes, such as the encryption of data in transit.

Not Applicable. The key generation is not implemented.

Not Applicable. The key establishment is not implemented.

Not Applicable. There is no industry protocol implemented.

Qualcomm® Inline Crypto Engine (UFS)

Table 7: Ports and Interfaces

Qualcomm® Inline Crypto Engine (UFS)

Qualcomm® Inline Crypto Engine (UFS) Z W Table 9: Approved Services

Table 10: Non-Approved Services

Not Applicable. No external software or firmware is loaded.

Qualcomm® Inline Crypto Engine (UFS)

The Qualcomm Inline Crypto Engine (UFS) does not support any software or firmware component. Therefore, this section is not applicable.

Qualcomm® Inline Crypto Engine (UFS)

Type of Operational Environment: Non-Modifiable

Qualcomm® Inline Crypto Engine (UFS)

N/A Table 11: Mechanisms and Actions Required The Qualcomm Inline Crypto Engine (UFS) is a sub-chip enclosed in the platform listed in Table 2 that is made up of production grade components and conform to the Level 2 requirements for physical security. At the time of manufacturing, the die is embedded within a printed circuit board (PCB), which prevents visibility into the internal circuity of the Qualcomm Inline Crypto Engine (UFS). The layering process which is used to embed the die into the PCB also prevents tampering of the physical components without leaving tamper evidence. The Qualcomm Inline Crypto Engine (UFS) is further protected by being enclosed in commercial off the shelf mobile device utilizing production grade commercially available components and that the mobile device enclosure that completely surrounds the Qualcomm Inline Crypto Engine (UFS). There are no steps required to ensure that physical security is maintained.

Qualcomm® Inline Crypto Engine (UFS)

The Qualcomm Inline Crypto Engine (UFS) does not support any non-invasive security techniques. Therefore, this section is not applicable.

Qualcomm® Inline Crypto Engine (UFS)

Table 12: Storage Areas The module does not provide persistent storage of SSPs. The SSP i.e., the AES keys are provided by the caller are set up by the CO and are temporarily stored in hardware registers. Once the keys are written to the registers, they are not readable from outside the Qualcomm Inline Crypto Engine (UFS).

Table 13: SSP Input-Output Methods N/A The caller provides the AES keys for encryption and/or decryption. These keys are input to the module in plaintext form by the entity residing within the same physical perimeter of the SoC on which the Qualcomm Inline Crypto Engine (UFS) runs. The module does not output any SSPs.

Table 14: SSP Zeroization Methods N/A When the Qualcomm Inline Crypto Engine (UFS) performs a module reset, it will zeroize all SSPs contained within itself. The registers for the SSPs will implicitly be set to zero upon the reset, indicating the zeroization was successful. Table 15: SSP Table 1

Qualcomm® Inline Crypto Engine (UFS) Table 16: SSP Table 2

Qualcomm® Inline Crypto Engine (UFS)

Conditional tests are performed automatically without any operator intervention during power-up of the Qualcomm Inline Crypto Engine (UFS); these tests ensure that the cryptographic algorithms work as expected. While the conditional tests are executing, services are not available, and input and output are inhibited.

Table 17: Conditional Self-Tests Self-Tests are performed automatically without any operator intervention during power-up of the Qualcomm Inline Crypto Engine (UFS); these tests ensure that the cryptographic algorithms work as expected. While the pre-operational tests are executing, services are not available, and input and output are inhibited.

Qualcomm® Inline Crypto Engine (UFS) Table 18: Conditional Periodic Information Periodic self-tests can be invoked by powering-off and reloading the module or when a reset event is received. These tests perform the same pre-operational tests that are performed during power-up. During the execution of the periodic self-tests, cryptographic services are not available, and no data output or input is possible.

Table 19: Error States If any of the conditional self-tests or periodic test fails, the Qualcomm Inline Crypto Engine (UFS) will enter the error state. Data output is prohibited, and no further cryptographic operation is allowed in the error state. This is performed by the control logic that and prevents external usage when an error is detected. To recover from the error state, re-initialization is possible by successful execution of the power up tests, which can be triggered by either a power-off/power-on cycle or the receipt of a reset event. Once the module is in Error state, the Qualcomm Inline Crypto Engine (UFS) will only respond to a reset which will cause it to re-execute the power up tests. If the error persists, the Qualcomm Inline Crypto Engine (UFS) will remain unavailable.

Qualcomm® Inline Crypto Engine (UFS)

The Qualcomm Inline Crypto Engine (UFS) is a sub-chip module that runs on the SoCs defined in Table 2. The vendor uses a trusted delivery courier to transport the SoC to their customers. On the reception of the SoC, the operator shall first check all sides of the box to verify that it has not been tampered with during the shipment. Then, after opening the box the operator shall verify that the moisture barrier bag is still sealed and does not present any trace of tampering. Finally, after retrieving the SoC, the operator shall perform a visual inspection of the external package of the module. If one of these verifications fail, the operator shall contact their Qualcomm Technologies’ representative who released the delivery before operating the module. Once the product is received by the customer and powered up, the tests defined in section

There is no specific Administrator guidance required for the module.

There is no specific non-Administrator guidance required for the module.

N/A Therefore no specific design or rules to be followed.

N/A There are no maintenance requirements.

As stated in section 9, the module does not possess persistent storage of SSPs. SSP values only exists in volatile memory and these values are zeroized when the module is reset. The procedure for secure sanitization of the module at the end of life is simply to power it off, which is the action of zeroization of the SSPs. As a result of this sanitization via power-off, the SSPs are removed from the module, so that the module may either be distributed to other operators or disposed.

ClearCase, a version control system from IBM/Rational, is used to manage the revision control of the hardware code (Verilog code) and hardware documentation. The ClearCase version control system provides version control, workspace management, parallel development support and build auditing. The Verilog code is maintained within the ClearCase database used by Qualcomm Technologies Inc.

Qualcomm® Inline Crypto Engine (UFS)

The Qualcomm Inline Crypto Engine (UFS) does not implement security mechanisms to mitigate other attacks.

Qualcomm® Inline Crypto Engine (UFS) Appendix A. Glossary and Abbreviations AES Advanced Encryption Standard CAVP Cryptographic Algorithm Validation Program CMVP Cryptographic Module Validation Program CSP Critical Security Parameter FIPS Federal Information Processing Standards Publication FSM Finite State Model KAT Known Answer Test NIST National Institute of Science and Technology SoC System on a Chip XTS XEX-based Tweaked-codebook mode with cipher text Stealing

Qualcomm® Inline Crypto Engine (UFS) Appendix B. References FIPS140-3 FIPS PUB 140-3 - Security Requirements For Cryptographic Modules March 2019 https://doi.org/10.6028/NIST.FIPS.140-3 FIPS1403_IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program April 2025 https://csrc.nist.gov/Projects/cryptographic-module-validationprogram/fips-140-3-ig-announcements FIPS197 Advanced Encryption Standard November 2001 https://doi.org/10.6028/NIST.FIPS.197-upd1 SP800-38A NIST Special Publication 800-38A - Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 https://doi.org/10.6028/NIST.SP.800-38A SP800-38E NIST Special Publication 800-38E - Recommendation for Block Cipher Modes of Operation: The XTS AES Mode for Confidentiality on Storage Devices January 2010 https://doi.org/10.6028/NIST.SP.800-38E SP800-140B NIST Special Publication 800-140Br1 - CMVP Security Policy Requirements November 2023 https://doi.org/10.6028/NIST.SP.800-140Br1

Referenced URLs

• www.atsec.com
• https://doi.org/10.6028/NIST.FIPS.140-3
• https://csrc.nist.gov/Projects/cryptographic-module-validation-
• https://doi.org/10.6028/NIST.FIPS.197-upd1
• https://doi.org/10.6028/NIST.SP.800-38A
• https://doi.org/10.6028/NIST.SP.800-38E
• https://doi.org/10.6028/NIST.SP.800-140Br1