Qualcomm® Crypto Engine Core

Certificate

Approved Algorithms (42)

Security Levels (Table 1)

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/>Firmware Load</i>"]
    C3["[high] Unauthenticated /<br/>self-test / status service<br/>surface<br/><i>Self-Test<br/>Status output</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® 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/>Firmware Load</i><br/>src: text:keyword"]
    C3["[high] Unauthenticated / self-test / status service surface<br/><i>Self-Test<br/>Status output</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® Crypto Engine Core Module versions 5.7.0, 5.7.2 and 5.7.3 Document Version 1.1 Last update: 07-08-2024 Prepared by: atsec information security corporation

Austin, TX 78759 www.atsec.com

Qualcomm® Crypto Engine Core

1.1 1.2 2.1 2.2 2.3 4.1 4.2 4.3 6.1 9.1 9.2 9.3 9.4 9.5 10.1 10.2 10.3 10.4 11.1 11.2 11.3 11.4

Qualcomm® Crypto Engine Core

This Security Policy describes the features and design of the module named Qualcomm® Crypto Engine Core 1 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. This document is the non-proprietary FIPS 140-3 Security Policy for versions 5.7.0, 5.7.2 and 5.7.3 of the Qualcomm Crypto Engine Core. 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. [Number Below] N/A N/A N/A

1 Qualcomm branded products are products of Qualcomm Technologies, Inc. and/or its

Qualcomm® Crypto Engine Core N/A Table 1 - Security Levels

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 Qualcomm Crypto Engine Core has been tested on the following platforms with the corresponding module variants and configuration options: [Part Number and Version] N/A N/A N/A N/A N/A N/A N/A N/A N/A N/A 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.

2 Snapdragon is a product of Qualcomm Technologies, Inc. and/or its subsidiaries.

Qualcomm® Crypto Engine Core N/A Table 3 - Approved Algorithms

Qualcomm® Crypto Engine Core Table 4 - Non-Approved Not Allowed in the Approved Mode of Operation

Qualcomm® Crypto Engine Core

The cryptographic boundary of the Qualcomm Crypto Engine Core is represented by the blue box. The module has been tested on the Snapdragon 8 Gen 2 Mobile Platform SoC, Qualcomm QCM4490 SoC, Qualcomm QCS4490 SoC, Snapdragon 4 Gen 2 Mobile Platform SoC, and Snapdragon XR2 Gen 2 Platform SoC which forms the physical perimeter for the module. Below is an illustrative diagram. Figure 1 - Hardware Block Diagram Figure 2: Snapdragon 8 Gen 2 Mobile Platform

Qualcomm® Crypto Engine Core Figure 3 - Qualcomm QCM4490 Figure 4 - Qualcomm QCS4490

Qualcomm® Crypto Engine Core Figure 5

• Snapdragon 4 Gen 2 Mobile Platform Figure 6
• Snapdragon XR2Gen 2Platform The tested operational environment’s physical perimeter (TOEPP) is the entire single chip.

The Qualcomm Crypto Engine Core supports two modes of operation: approved mode and a nonapproved mode. 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 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. If the module is in the non-approved mode of operation and

Qualcomm® Crypto Engine Core the operator requests an approved service, the Qualcomm Crypto Engine Core implicitly switches to its approved mode. All CSPs are kept separate between the two modes.

Qualcomm® Crypto Engine Core

Table 5 - Ports and Interfaces All status ports and control ports are directed through the interface of the Qualcomm Crypto Engine Core cryptographic boundary. The registers of the Qualcomm Crypto Engine Core are used for control input and status output interfaces. Qualcomm Crypto Engine Core FIFOs are implemented to provide the high-speed interfaces for data input and data output. The Qualcomm Crypto Engine Core does not implement a Control Output interface. If a caller wants to use a non-Approved cipher, a separate “pipe pair” must be used or a new key for the non-Approved cipher must be loaded.

Qualcomm® Crypto Engine Core

The module only supports crypto Officer (CO) role that is assumed implicitly when a service is requested form the module. Table 6 - Roles, Service Commands, Input and Output

Qualcomm® Crypto Engine Core

The Qualcomm Crypto Engine Core does not provide a bypass capability. All services are implemented within the Qualcomm Crypto Engine Core. The service indicator In Table 7, the convention below applies when specifying the access permissions (types) that the 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. The following table describes the services available in approved mode: E, W E, W E, W E, W N/A N/A N/A Z W

Qualcomm® Crypto Engine Core N/A N/A N/A N/A Table 7 - Approved Services The following table describes the services available in Non-approved mode: Table 8 - Non-Approved Services

There is no operator authentication; assumption of role is implicit by the used service(s).

Qualcomm® Crypto Engine Core

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

Qualcomm® Crypto Engine Core

The Qualcomm Crypto Engine Core is a single-chip hardware module with a non-modifiable operational environment. The procurement, build and configuring procedure are controlled by the Vendor.

Qualcomm® Crypto Engine Core 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-theshelf 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. N/A N/A

Qualcomm® Crypto Engine Core

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

Qualcomm® Crypto Engine Core

Table 10 below lists the SSPs used within the Qualcomm Crypto Engine Core. N/A N/A Zeroization Authentication N/A N/A Authentiregisters during Table 10

• SSPs The Qualcomm Crypto Engine Core does not perform SSP generation for any algorithms.

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 singlechip 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 write-only registers. This action prevents an entity interacting with the Qualcomm Crypto Engine Core from being able to read the CSPs.

Qualcomm® Crypto Engine Core

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.

When the Qualcomm Crypto Engine Core receives a reset event, it will zeroize all SSPs contained during power-off, indicating implicitly that SSP zeroization was successful.

Qualcomm® Crypto Engine Core

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

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 Table 11 as the pre-operational self-test. The Qualcomm Crypto Engine Core does not implement a pre-operational bypass test nor preoperational critical functions test.

The Qualcomm Crypto Engine Core conditional self-tests are CASTs and have been listed in Table 11. These CASTs are executed during each power-on. The Qualcomm Crypto Engine Core does not implement a Software/Firmware Load Test, Manual Entry Test, Conditional Bypass Test, or a Conditional Critical Functions Test. Table 11 - Conditional Cryptographic Algorithm Self-Tests

The operator may invoke self-tests on-demand by powering-off and reloading the Qualcomm Crypto Engine Core. During the execution of the on-demand self-tests, no cryptographic services are available, and no data output or input is possible.

Table 12 below lists the causes that trigger the Qualcomm Crypto Engine Core to enter its error state. When entering its error state, the Qualcomm Crypto Engine Core sets the BIST_FAILURE register to indicate that it is in the error state. While in the error state, all data input and output are prohibited and no further cryptographic operation is allowed. The Qualcomm Crypto Engine

Qualcomm® Crypto Engine Core 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 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. Table 12 - Error States

Qualcomm® Crypto Engine Core

The Qualcomm Crypto Engine Core is a sub-chip module that runs on the Snapdragon 8 Gen 2 Mobile Platform SoC, Qualcomm QCM4490 SoC, Qualcomm QCS4490 SoC, Snapdragon 4 Gen 2 Mobile Platform SoC, and Snapdragon XR2 Gen 2 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 similar to the picture in Figure 2. 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 Table 11 will be executed.

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.

The operation of the Qualcomm Crypto Engine Core does not need FIPS 140-3 specific guidance. The FIPS 140-3 functional requirements are always met. 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. NOTE:

• The module ensures that the AES algorithm in XTS mode is only used for the cryptographic protection of data on storage devices, as specified in [SP800-38E]. The module does not support AES-XTS data units longer than 220 AES blocks. In compliance with IG C.I, the module performs a check to ensure that the two AES-XTS keys are different.

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® Crypto Engine Core

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

Qualcomm® Crypto Engine Core Appendix A. Glossary and Abbreviations AEAD Authenticated Encryption with Associated Data AES Advanced Encryption Standard CAST Cryptographic Algorithm Self-test CAVP Cryptographic Algorithm Validation Program CBC Cipher Block-chaining CCCS Canadian Centre for Cyber Security CCM Counter with Cipher Block Chaining-Message Authentication Code CMAC Cipher-based Message Authentication Code CMVP Cryptographic Module Validation Program CO Crypto Officer CSP Critical Security Parameter CTR Counter Mode DES Data Encrypted Signature ECB Electronic Code Book FIFO First-in First-out (Queue) FIPS Federal Information Processing Standards Publication GCM Galois Counter Mode HMAC Hash Message Authentication Code KAT Known Answer Test MAC Message Authentication Code NIST National Institute of Science and Technology PCB Printed Circuit Board SHA Secure Hash Algorithm SoC System on a Chip SSP Sensitive Security Parameter TDES Triple-DES TOEPP Trusted Operating Environment Physical Perimeter XTS XEX-based Tweaked-codebook mode with cipher text Stealing

Qualcomm® Crypto Engine Core 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 March 2023 https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-1403-ig-announcements FIPS180-4 Secure Hash Standard (SHS) August 2015 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS197 Advanced Encryption Standard November 2001 http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf FIPS198-1 The Keyed Hash Message Authentication Code (HMAC) July 2008 http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.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-38B NIST Special Publication 800-38B - Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication October 2016 http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf SP800-38C NIST Special Publication 800-38C - Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality July 2007 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf SP800-38D NIST Special Publication 800-38D - Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC November 2007 http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.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

Qualcomm® Crypto Engine Core SP800-67r2 NIST Special Publication 800-67 Revision 2 - Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher November 2017 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-67r2.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

Referenced URLs

• www.atsec.com
• https://doi.org/10.6028/NIST.FIPS.140-3
• https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-140-
• http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf
• http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
• http://csrc.nist.gov/publications/fips/fips198-1/FIPS-198-1_final.pdf
• http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
• http://csrc.nist.gov/publications/nistpubs/800-38B/SP_800-38B.pdf
• http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.pdf
• http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
• http://csrc.nist.gov/publications/nistpubs/800-38E/nist-sp-800-38E.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-67r2.pdf
• https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-140B.pdf