Qualcomm® Inline Crypto Engine (UFS)

Certificate

Approved Algorithms (16)

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>update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>Status Output<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["Possible only, some<br/>services may process input<br/>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["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"]
    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>update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>Status Output<br/>Show Status</i><br/>src: text:keyword"]
    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,C3,C5 clueLow;

Security Policy, page by page

Qualcomm® Inline Crypto Engine (UFS) Versions 3.2.0, 3.2.1, 4.0.1 and 4.0.2 Version 1.1 Last update: 2024-07-24 Prepared by: atsec information security corporation

9130 Jollyville Road, Suite 260

Austin, TX 78759 www.atsec.com © 2024 Qualcomm Technologies, Inc. / atsec information security.

© 2024 Qualcomm Technologies, Inc. / atsec information security.

2 of 24

This Security Policy describes the features and design of the module named Qualcomm® Inline Crypto Engine (UFS) using the terminology contained in the FIPS 140-3 specification. The FIPS 140-

3 Security Requirements for Cryptographic Modules specifies the security requirements that will be

satisfied by a cryptographic module utilized within a security system protecting sensitive but unclassified information. The NIST/CCCS Cryptographic Module Validation Program (CMVP) validates cryptographic modules to FIPS 140-3. Validated products are accepted by the Federal agencies of both the USA and Canada for the protection of sensitive or designated information. and including this notice. Other documentation is proprietary to their authors.

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. This document is the non-proprietary FIPS 140-3 Security Policy for versions 3.2.0, 3.2.1, 4.0.1 and

4.0.2 of the Qualcomm Inline Crypto Engine (UFS). It has a one-to-one mapping to the [SP 800-

140B] starting with section B.2.1 named “General” that maps to section 1 in this document and ending with section B.2.12 named “Mitigation of other attacks” that maps to section 12 in this document. © 2024 Qualcomm Technologies, Inc. / atsec information security.

3 of 24

Table 1 - Security Levels © 2024 Qualcomm Technologies, Inc. / atsec information security.

4 of 24

The Qualcomm Inline Crypto Engine (UFS) 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 800-38E. The underlying AES for AES-XTS is compliant to FIPS 197. The Qualcomm Inline Crypto Engine (UFS) has been tested on the following platforms with the corresponding module variants and configuration options:

2 Snapdragon, Qualcomm QCM6490, and Qualcomm QCS6490 are products of Qualcomm

Technologies, Inc. and/or its subsidiaries. © 2024 Qualcomm Technologies, Inc. / atsec information security.

5 of 24

Table 2 - Cryptographic Module Tested Configuration The table below lists all security functions of the module, including specific key strengths employed for approved services, and implemented modes of operation. Table 3 - Approved Algorithms Table 4 - Non-Approved Algorithms Not Allowed in the Approved Mode of Operation NOTE: the module does not implement any non-approved but allowed, or non-approved but allowed with no security claimed algorithms.

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 listed in Table 2 which form the physical perimeter for the module. Consequently, the embodiment of the Qualcomm Inline Crypto Engine (UFS) is a single-chip cryptographic module. © 2024 Qualcomm Technologies, Inc. / atsec information security.

6 of 24

Below is an illustrative diagram. Figure 1 – Cryptographic Boundary of Qualcomm Inline Crypto Engine (UFS) Figure 2 - Snapdragon 8 Gen 1 Mobile Platform © 2024 Qualcomm Technologies, Inc. / atsec information security.

7 of 24

Figure 3 - Snapdragon 8+ Gen 1 Mobile Platform Figure 4

• Qualcomm QCM6490 Figure 5
• Qualcomm QCS6490 © 2024 Qualcomm Technologies, Inc. / atsec information security.

8 of 24

Figure 6

• Snapdragon 8 Gen 2 Mobile Platform Figure 7
• Snapdragon 695 5G Mobile Platform Figure 8
• Snapdragon 6 Gen 1 Mobile Platform © 2024 Qualcomm Technologies, Inc. / atsec information security.

9 of 24

Figure 9

• Qualcomm QCM4490 Figure 10
• Qualcomm QCS4490 Figure 11
• Snapdragon 4 Gen 2 Mobile Platform © 2024 Qualcomm Technologies, Inc. / atsec information security.

10 of 24

Figure 12

• Snapdragon 8 Gen 3 Mobile Platform Figure 13
• Snapdragon 7 Gen 1 Mobile Platform

The Qualcomm Inline Crypto Engine (UFS) supports two modes of operation; (1) the approved mode in which the approved services are available; and (2) the non-approved mode, in which the non-approved services are available. When the Qualcomm Inline Crypto Engine (UFS) starts up successfully, after passing all the selftests, 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 non-Approved services listed in Table 8. Section 4 provides details on the service indicator implemented by the module. The service indicator identifies when an approved service is called. 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 AESXTS. 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 selected context key is referenced and will be used for the operation by the Qualcomm Inline Crypto Engine (UFS). © 2024 Qualcomm Technologies, Inc. / atsec information security.

11 of 24

Table 5 - Ports and Interfaces As indicated in Table 5, all status output and control input are directed through the interface of the cryptographic boundary, which is the registers and interrupts of the Qualcomm Inline Crypto © 2024 Qualcomm Technologies, Inc. / atsec information security.

12 of 24

The Crypto Officer role is assumed implicitly. Concurrent operators are not allowed.

The following table describes the approved services: © 2024 Qualcomm Technologies, Inc. / atsec information security.

13 of 24

Service Zeroization Configuration of parameters for key Status output Setting encryption and decryption keys

Description Zeroizes the SSP Configures the registers to hold parameters such as index of the key Show status of the module state Configuring the keys to be used by module

Approved Security Functions None None None None

Keys and/or SSPs AES key N/A N/A AES key

Roles

Access rights to Keys and/or SSPs Z N/A N/A W

Indicator None None None None

Table 7 - Approved Services G = Generate: The module generates or derives the SSP. E = Execute: The module uses the SSP in performing a cryptographic operation. 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. Table 8 - Non-Approved Services

There is no operator authentication; assumption of role is implicit by the used service(s). © 2024 Qualcomm Technologies, Inc. / atsec information security.

14 of 24

The Qualcomm Inline Crypto Engine (UFS) does not support any software or firmware component. Therefore, this section is not applicable. © 2024 Qualcomm Technologies, Inc. / atsec information security.

15 of 24

The Qualcomm Inline Crypto Engine (UFS) is a single chip hardware module. The procurement, build and configuring procedure are controlled. Therefore, the operational environment is considered non-modifiable. © 2024 Qualcomm Technologies, Inc. / atsec information security.

16 of 24

The Qualcomm Inline Crypto Engine (UFS) is a sub-chip enclosed in the platforms that are listed in Table 2 that are made up of production grade component 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. © 2024 Qualcomm Technologies, Inc. / atsec information security.

17 of 24

The Qualcomm Inline Crypto Engine (UFS) does not support any non-invasive security techniques. Therefore, this section is not applicable. © 2024 Qualcomm Technologies, Inc. / atsec information security.

18 of 24

These keys are generated outside the boundary and set up by the Crypto Officer in the registers of the Qualcomm Inline Crypto Engine (UFS). The following table lists the key/CSP used by the : Table 9 - SSPs The Qualcomm Inline Crypto Engine (UFS) does not provide any SSP generation or SSP establishment methods.

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. 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).

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. © 2024 Qualcomm Technologies, Inc. / atsec information security.

19 of 24

The integrity test is not applicable since the Qualcomm Inline Crypto Engine (UFS) is implemented in hardware and is non-modifiable. There are no bypass or critical function tests.

Table 10 – Conditional Self-Tests 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.

On demand self-tests can be invoked by powering-off and reloading the module or when a reset event is received. This test performs the same conditional tests that are performed during powerup. During the execution of the on-demand self-tests, cryptographic services are not available, and no data output or input is possible.

If any of the conditional self-tests or on-demand 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 locked, 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. Table 11 - Error States © 2024 Qualcomm Technologies, Inc. / atsec information security.

20 of 24

The Qualcomm Inline Crypto Engine (UFS) is a sub-chip module that runs on the platforms listed in Table

2. These SoCs are delivered from the vendor via a trusted delivery courier. On the reception of the SoC, the operator shall first check all sides of the box to verify that it has not been tampered 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, it should look similar to the pictures in Figure 2 through Figure
3. If one of these verifications fail, the operator shall contact their Qualcomm representative which released the delivery before operating the module. Once the product is received by the customer and powered up the test defined in section 10 will be executed.

As stated in section 9.4, the module does not perform 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.

There is no specific crypto officer guidance required for the module. Note: AES XTS The module does not support AES-XTS with data unit lengths greater than 2^20 AES blocks. 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.

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. © 2024 Qualcomm Technologies, Inc. / atsec information security.

21 of 24

The Qualcomm Inline Crypto Engine (UFS) does not implement security mechanisms to mitigate other attacks. © 2024 Qualcomm Technologies, Inc. / atsec information security.

22 of 24

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 © 2024 Qualcomm Technologies, Inc. / atsec information security.

23 of 24

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 FIPS140-3_IG Implementation Guidance for FIPS PUB 140-3 and the Cryptographic Module Validation Program September 2020 https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-1403-ig-announcements FIPS197 Advanced Encryption Standard November 2001 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf SP800-38A NIST Special Publication 800-38A - Recommendation for Block Cipher Modes of Operation Methods and Techniques December 2001 http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf 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 http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf SP800-140B NIST Special Publication 800-140B - CMVP Security Policy Requirements March 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf © 2024 Qualcomm Technologies, Inc. / atsec information security.

24 of 24