Qualcomm® Crypto Engine Core

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Qualcomm® Crypto Engine Core
  %% 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<br/>Recovery</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth</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® Crypto Engine Core
  %% 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<br/>Recovery</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth</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 Technologies, Inc. Qualcomm(R) Crypto Engine Core Document Version: 1.1 Last Update: 09-04-2025 Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

Austin, TX 78759 https://www.atsec.com

This Security Policy describes the features and design of the module named Qualcomm® Crypto Engine Core1 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.

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. Qualcomm branded products are products of Qualcomm Technologies, Inc. and/or its subsidiaries.

Purpose and Use: The Qualcomm® Crypto Engine Core cryptographic module is a sub-chip hardware module in a single chip embodiment for the purpose of FIPS 140-3 validation. The module is a general-purpose engine that provides cryptographic services (as listed in Section 4.3) to the components residing within the same operational environment which act as operators. These operators can request module services using FIFOs and registers. Module Type: Hardware Module Embodiment: SingleChip Module Characteristics: SubChip Cryptographic Boundary: Figure 1: Cryptographic boundary and physical perimeter Tested Operational Environment’s Physical Perimeter (TOEPP): The tested operational environment’s physical perimeter is the single chip.

Tested Module Identification

• Hardware: Table 2: Tested Module Identification
• Hardware

There are no excluded components. Modes List and Description: Table 3: Modes List and Description The Qualcomm® Crypto Engine Core supports two modes of operation: approved mode and a non-approved mode. All CSPs are kept separate between the two modes through the use of a key policy management system.

Mode Change Instructions and Status: The switching of modes of operation is implicit depending on the service invoked, but the approved services are explicitly identified by an indicator. The Qualcomm® Crypto Engine Core enters the approved mode after successful completion of the conditional algorithm self-tests. When the operator invokes a non-approved service, the Qualcomm® Crypto Engine Core implicitly switches to its non-approved mode.

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

Table 6: Security Function Implementations

The AES algorithm in XTS mode is only used for the cryptographic protection of data on storage devices, in compliance with [SP800-38E]. The module ensures that the length of a single data unit encrypted with the XTS-AES does not exceed 2²⁰ AES blocks, that is 16MB of data. To meet the requirement stated in IG C.I, the module implements a check that ensures, before performing any cryptographic operation, that the two AES keys used in AES XTS mode are not identical.

N/A for this module. N/A for this module.

Not Applicable. The key generation is not implemented.

Not Applicable. The key establishment is not implemented.

Not Applicable. There are no industry protocols implemented.

Table 7: Ports and Interfaces The Qualcomm® Crypto Engine Core does not implement a Control Output interface.

Table 8: Roles The module only supports the Crypto Officer (CO) role that is assumed implicitly when a service is requested from the module.

The convention below applies when specifying the access permissions that the service has for each SSP: 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. Z = Zeroize: The module zeroizes the SSP.

Table 10: Non-Approved Services

Not Applicable. No external software or firmware is loaded.

The Qualcomm Crypto Engine Core does not have any software or firmware components. Therefore, this section is not applicable.

Type of Operational Environment: Non-Modifiable

Table 11: Mechanisms and Actions Required The Qualcomm® Crypto Engine Core cryptographic module is a single-chip hardware module which conforms to the Level 2 requirements for physical security. The Qualcomm® Crypto Engine Core is a sub-chip that is enclosed within production grade components. At the time of manufacturing, the die containing the Qualcomm® Crypto Engine Core is embedded within a printed circuit board (PCB), which prevents visibility into the internal circuity of the Qualcomm® Crypto Engine Core. The layering process which embeds the die into the PCB prevents tampering of the physical components without leaving tamper evidence. The Qualcomm® Crypto Engine Core is further protected by being enclosed in a commercial off-the-shelf mobile device which is itself made with production grade commercially available components. This mobile device enclosure completely surrounds the Qualcomm® Crypto Engine Core. There are no steps required to ensure that physical security is maintained.

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

Table 12: Storage Areas The Qualcomm® Crypto Engine Core stores all SSPs internally (the storage is non-persistent). In addition, all SSPs are stored write-only and are not readable outside of the Qualcomm® Crypto Engine Core. Therefore, any attempt to read SSPs are blocked by the Qualcomm® Crypto Engine Core control logic, which will return zeros instead of an SSP.

Table 13: SSP Input-Output Methods The module does not provide SSP entry or output services. Instead, SSPs are provided from the caller within the tested operation environment’s physical perimeter (TOEPP) hardware via a single-chip TOEPP path, which is not considered SSP establishment by Table 1 of FIPS 140-3 IG 9.5.A. SSPs can only be written to the Qualcomm® Crypto Engine Core by the boot loader by writing to the key registers or into the FIFOs assigned to the particular use case. Any attempt to write to a non-assigned FIFO is blocked. The Qualcomm® Crypto Engine Core ensures that there is no means to obtain CSP or key data from the Qualcomm® Crypto Engine Core by placing the CSPs into writeonly registers. This action prevents an entity interacting with the Qualcomm® Crypto Engine Core from being able to read the CSPs.

Table 14: SSP Zeroization Methods

Name AES key

Input - Output Input parameter

Storage Hardware register:Plaintext Hardware FIFO:Plaintext

Storage Duration Until module is powered off

Zeroization Power-off

Related SSPs

The successful power-off of the module is an implicit indicator that zeroization has completed. Table 15: SSP Table 1

Name HMAC key

Input - Output Input parameter

Storage Hardware register:Plaintext Hardware FIFO:Plaintext

Storage Duration Until module is powered off

Zeroization Power-off

Related SSPs

The Qualcomm® Crypto Engine Core is solely implemented in hardware and does not have any software or firmware components. As such, the module does not perform any pre-operational software/firmware integrity test. Instead, the module performs the CASTs listed in Conditional Self-tests section.

Table 17: Conditional Self-Tests

Cryptographic algorithm self-tests (CASTs) are automatically performed during power-up of the Qualcomm® Crypto Engine Core without any operator intervention. During CAST execution, no services are available, and input and output are inhibited by the Qualcomm® Crypto Engine Core control logic.

N/A for this module. Table 18: Conditional Periodic Information

Table 19: Error States If any of the self-tests fail, the Qualcomm Crypto Engine Core will enter the error state. Data output is prohibited, and no further cryptographic operation is allowed in the error state. The Qualcomm® Crypto Engine Core control logic enforces this prohibition by preventing external usage while the module is in the error state. In addition, neither caller-induced nor internal errors reveal any sensitive material to callers. Once the Qualcomm® Crypto Engine Core is in the error state, it will only respond to a module reset command. A reset will cause the Qualcomm® Crypto Engine Core to re-execute its CASTs. The Qualcomm® Crypto Engine Core will remain unavailable until it passes its CASTs.

The operator can initiate the cryptographic algorithm self-tests by power cycling the module.

The Qualcomm® Crypto Engine Core is a sub-chip module that runs on the Snapdragon 8 Gen 3 Mobile Platform SoC. 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; it should look like the picture in Figure 2. If one of these verifications fails, 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 the Self-Tests section will be executed automatically and without operator intervention.

The operation of the Qualcomm® Crypto Engine Core does not need FIPS 140-3 specific guidance. The FIPS 140-

For using the cryptographic services of the Qualcomm® Crypto Engine Core, the manual for the Qualcomm® Crypto Engine Core covers the description of the register set as well as the use of the FIFOs channels should be used.

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.

Because the module does not have persistent storage, all SSPs are zeroized and the module is securely sanitized when powered down. Thus, the module may be distributed to other operators or disposed of after each power off.

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.

The Qualcomm Crypto Engine Core does not implement security mechanisms to mitigate other attacks.