Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library

Certificate

Approved Algorithms (29)

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

flowchart LR
  %% Deterministic review-risk graph for Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library
  %% 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/>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>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>application</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."]
    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?"]
    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?"]
    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"]
    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"]
    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
  C5 --> I5 --> R5 --> E5
  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,C5,C6 clue;
  class I2,I3,I5,I6 infer;
  class R2,R3,R5,R6 risk;
  class E2,E3,E5,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library
  %% 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/>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"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>application</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,C6 clueLow;

Security Policy, page by page

Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library Module version 513b121d8d789b1e5a7fd22743994650a94b222d 108c33b0d82c98ff282bac64 Document Version 1.1 Last update: 08-26-2024 Prepared by: atsec information security corporation

4516 Seton Center Pkwy, Suite 250

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

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

2 of 38

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

3 of 38

This Security Policy describes the features and design of the module named Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library using the terminology contained in 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 module 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. The Security Policy document is one document in a FIPS 140-3 Submission Package. In addition to this document, the Submission Package contains:  The validation report prepared by the lab.  Other supporting documentation and additional references. and including this notice. Other documentation is proprietary to their authors.

was further consolidated into this document by atsec information security together with other vendor-supplied documentation. 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 the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library. It has a one-to-one mapping to the [SP800-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.

4 of 38

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

5 of 38

Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library

(TEE) Software Cryptographic Library

. Disabled by default and blow to enable.

secure applications. It is part of the common library and provides APIs to the secure applications for cryptography and hashing functions. Arm® v8 instruction set architecture for hash operations for SHA-1, SHA-224 and SHA-256.

cryptographic module (hereafter referred to as “the module”) is a hybrid software Single-Chip cryptographic module that consists of components listed in the table below. The Qualcomm® Pseudo Random Number Generator module with version 3.1.0 validated to FIPS 140-3 under Cert. #4778. The bound module resides within the same physical perimeter of the binding module. Table 2 - Components of the Hybrid Software Cryptographic Module The ARMv8.5-a is the instruction set version used within the Snapdragon 8 Gen 2 Mobile Platform Snapdragon is a product of Qualcomm Technologies, Inc. and/or its subsidiaries. Arm is a registered trademark of Arm Limited (or its subsidiaries) in the US and/or elsewhere. © 2024 Qualcomm Technologies, Inc. / atsec information security.

6 of 38

The module has been tested on the operational environments indicated in Table 3 with the corresponding module variants and configuration options. Table 3 - Tested operational environments

Table 4 lists all approved security functions (cryptographic algorithms) of the module, including specific key lengths employed for approved services, and implemented modes or methods of operation of the algorithms. © 2024 Qualcomm Technologies, Inc. / atsec information security.

7 of 38

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

8 of 38

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

9 of 38

Table 4 – Approved Algorithms Table 5 lists all non-approved security functions not allowed in approved services of the module. Triple DES is CAVP certified with CAVP Cert. #A2940. However, there are two requirements from FIPS 140-3 IG C.G below that contribute to the non-compliance:

1. FIPS 140-3 requires that only 2^16 encryptions are performed with a given key; 2) the aforementioned requirement must be enforced by the module itself, not by policy. GCM is CAVP certified with CAVP Cert. #A2940. However, there are two requirements from FIPS 140-3 IG C.H below that contribute to the non-compliance: 1) the IV uniqueness must be enforced by the module;
2. FIPS 140-3 requires that only 2^32 cipher operations are performed with a given key. © 2024 Qualcomm Technologies, Inc. / atsec information security.

10 of 38

Table 5 – Non-Approved Algorithms Not Allowed in Approved Services NOTE: There are no non-approved algorithms allowed in approved mode, and no non-approved algorithms allowed in the approved mode with no security claimed.

The module implements 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. The current mode of operation of the module can be inferred by the service indicator, which indicates the approved state of the current service being invoked. No configuration is necessary for the module to operate and remain in the approved or non-approved modes. All SSPs are kept separate between the two modes. After the module successfully passes the pre-operational integrity self-test, the module is in the approved mode. If the operator requests a non-approved service, the module implicitly switches to the non-approved mode of operation. When in the non-approved mode of operation, if the operator requests an approved service, the module implicitly switches to the approved mode of operation. Table 8 and 9 list the services available in approved and non-approved mode of operation, respectively. The ECDH has been tested with CAVP certificate #A2940. However, the shared secret generation does not check the key assurance requirements from SP800-56A Rev 3 around trusted third parties during key import. There is a self-test for ECDH but is not listed since it is non-approved. © 2024 Qualcomm Technologies, Inc. / atsec information security.

11 of 38

The physical perimeter of the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is the physical perimeter of the device that contains it. Consequently, the embodiment of the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is a single-chip cryptographic module. Figure 1 shows a block diagram of the module, with the cryptographic boundary indicated in red, and the physical perimeter in black. Figure 1 – Block diagram depicting the cryptographic boundary and physical perimeter, and data flow between the components in the Snapdragon SoC Figure 2: Snapdragon 8 Gen 2 Mobile Platform © 2024 Qualcomm Technologies, Inc. / atsec information security.

12 of 38

The TOEPP (tested operational environment’s physical perimeter) of the module is the entire single chip, the Snapdragon 8 Gen 2 Mobile Platform.

The Crypto Officer interacts with the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library in two distinct ways:

1. Initializing the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library
2. The application services (API’s) invoked by users Once Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library initializes and the self-tests complete successfully, all cryptographic functions are made available. See section 10.3 for error states and error recovery. Caller-induced or internal errors do not reveal any sensitive material to callers. The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library ensures that there is no means to obtain data from itself by performing key zeroization. There is no means to obtain sensitive information from the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library. © 2024 Qualcomm Technologies, Inc. / atsec information security.

13 of 38

Table 6 – Ports and Interfaces Table 6 summarizes the cryptographic module interfaces. The logical interfaces are logically separated from each other by the API design. All status ports and control ports are directed through the interface of the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library’s cryptographic boundary, which is its software APIs. The power interface is physically separated from any other interface. The module does not implement a control output © 2024 Qualcomm Technologies, Inc. / atsec information security.

14 of 38

The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library supports the Crypto Officer role. The role is implicitly assumed based on the services requested. Table 7 lists the roles supported by the module with corresponding services with input and output. © 2024 Qualcomm Technologies, Inc. / atsec information security.

15 of 38

Table 7 – Roles, Service Commands, Input and Output

The module does not support authentication for roles.

The module provides services to operators that assume the available role. Services are accessed through documented API interfaces from the calling application. Additional services are provided by the bound Pseudo Random Number Generator module on the Snapdragon 8 Gen 2 Mobile Platform SoC. This Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library utilizes the random number generation service from the bound Pseudo Random Number Generator module. The next tables define the services that utilize approved, allowed, and non-approved security functions in this module. For the respective tables, the convention below applies when specifying the access permissions (types) that the service has for each SSP.  Generate (G): The service establishes the SSP by generation, agreement, or derivation.  Read I: The SSP exists in the module and is read by the service and may be output.  Write (W): The caller provides the SSP to the service to be imported into the module; written; or updated if the SSP already exists in the module.  Execute (E) (or use): The service uses the SSP in performing a cryptographic operation. Other access types identify the provenance of the SSP.  Zeroize (Z): The service zeroizes the SSP.  N/A: The service does not access any SSP or key during its operation. An operator can read the service indicator from a service by invoking the qsee_get_fips_approval_status() function with enum value for QSEE_FIPS_CRYPTO_SVC_TYPE. For details on the enum values please see the product documentation.

Table 8 lists the approved services in this module, the roles that can request the service, the algorithms involved, the Sensitive Security Parameters (SSPs) involved and how they are accessed, and the respective service indicator. In the service tables, CO specifies the Crypto Officer role. © 2024 Qualcomm Technologies, Inc. / atsec information security.

16 of 38

G, R G, E, Z N_* © 2024 Qualcomm Technologies, Inc. / atsec information security.

17 of 38

The SSPs can only be accessed by the bound module and hence are not listed in table 10 © 2024 Qualcomm Technologies, Inc. / atsec information security.

18 of 38

Table 9 lists the non-approved services that utilize the non-approved security functions listed in Table 5. © 2024 Qualcomm Technologies, Inc. / atsec information security.

19 of 38

Table 9 - Non-Approved Services © 2024 Qualcomm Technologies, Inc. / atsec information security.

20 of 38

The integrity of the module is verified by comparing a HMAC-SHA-256 value calculated at run time with the HMAC-SHA-256 value stored in the module that was computed at build time. If the comparison verification fails, the module transitions to the error state (Section 10.3). The HMACSHA-256 algorithm goes through its cryptographic algorithm self-test before the integrity test is performed (Table 11).

The software integrity test is performed as part of the pre-operational self-tests. The preoperational self-tests can be invoked when Get_FIPS_Info service is called.

The module consists of code that will perform algorithmic services for trusted applications. The code is compiled into a shared library. © 2024 Qualcomm Technologies, Inc. / atsec information security.

21 of 38

The procurement, build and configuring procedure are controlled. The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is installed into a commercial off-theshelf (COTS) mobile device by the customer. The software components of this module are executed in the Qualcomm Trusted Execution Environment (TEE). Therefore, the operational environment is considered limited.

Please see Section 2.3 for the tested operational environment.

There are no security rules, settings or restrictions to the configuration of the operational environment.  The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library does not have the capability of loading software or firmware from an external source.  The module does not support concurrent operators. © 2024 Qualcomm Technologies, Inc. / atsec information security.

22 of 38

The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is a hybrid software module implemented as part of the Snapdragon 8 Gen 2 Mobile Platform SoC, which is the physical perimeter of the single-chip hybrid software module. The single-chip conforms to the Level 2 requirements for physical security. At the time of manufacturing, the die of the Snapdragon 8 Gen 2 Mobile Platform SoC is embedded within a printed circuit board (PCB), which prevents visibility into the internal circuity of the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library. 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 Snapdragon 8 Gen 2 Mobile Platform SoC is further protected by being enclosed in commercial off the shelf mobile device utilizing production grade, commercially available components and said mobile device enclosure completely surrounds the Snapdragon 8 Gen 2 Mobile Platform SoC. There are no steps required to ensure that physical security is maintained. © 2024 Qualcomm Technologies, Inc. / atsec information security.

23 of 38

The module does not support any non-invasive security techniques; therefore, this section is not applicable. © 2024 Qualcomm Technologies, Inc. / atsec information security.

24 of 38

Table 10 summarizes the Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented in the module in the approved services (Table 8). # N/A n N/A © 2024 Qualcomm Technologies, Inc. / atsec information security.

25 of 38

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

26 of 38

The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library implements Password-Based Key Derivation version 2 (PBKDF2) as defined in [SP800-132]. The PBKDF2 function is provided as a service and returns the key derived from the provided password to the caller. The supported option is 1a from Section 5.4 of SP 800-132, whereby the Master Key (MK) is used directly as the Data Protection Key (DPK). The keys derived from passwords, as shown in SP 800-132, may only be used for storage applications. The SSP generation methods implemented in the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library for approved services are compliant with SP 800-133Rev2. EC key pair generation is performed according to Appendix B.4.2 of FIPS 186-4 (Testing performed according to Appendix B.3.3 of FIPS 186-4 (Probable Prime Generation). The seeds (i.e., the random values) used in asymmetric key pair generation are directly obtained from the SP 80090Arev1 Hash DRBG provided by the bound Qualcomm® Pseudo Random Number Generator module, compliant with SP 800-133r2 section 4 without the use of V (as specified in additional comment #2 to IG D.H).  The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library does not generate symmetric keys.  Intermediate key generation values are not output from the module during or after processing the service. The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library only supports manual distribution and electronic entry for SSPs. The SSPs are provided to the module via API input parameters in plaintext form and output via API output parameters in plaintext form. The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library does not enter or output SSPs in plaintext format outside its physical perimeter. © 2024 Qualcomm Technologies, Inc. / atsec information security.

27 of 38

All SSPs are output from and input to the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library through the calling process and are destroyed from memory when released. The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library does not persistently store SSPs. The SSPs are stored temporarily in plaintext in the RAM.

The module’s functions deallocate and zeroize temporary SSP values in volatile memory used during the function’s execution. The zeroization consists of writing zeroes to the memory location used by the SSP before deallocating the area. The module does not overwrite SSPs with another SSP. The zeroization service for the SSPs in volatile memory consists of powering off the module, which will remove power from the volatile memory. This action will cause the value of the SSPs in volatile memory to be overwritten by random values the next time the module is powered on. The successful act of powering off the module serves as the implicit indicator of zeroization. © 2024 Qualcomm Technologies, Inc. / atsec information security.

28 of 38

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

29 of 38

The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library performs pre-operational self-tests when loaded into memory, without operator intervention. The preoperational self-tests ensure that the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is not corrupted. The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library transitions to the operational state only after the pre-operational self-tests are passed successfully. The types of pre-operational self-tests are described in the next sub-sections. 10.1.1Software Integrity Test Section 5.1 describes the integrity test and the details if the integrity tests are defined in Table 11.

10.2.1Cryptographic Algorithm Self-Tests The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library performs self-tests on all approved cryptographic algorithms as part of the approved services using the tests shown in Table 11. Data output through the data output interface is inhibited during the selftests. The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library transitions to the operational state only after the cryptographic algorithm self-tests are passed successfully. The known answer test for DRBG is performed by the bound module. 10.2.2Pair-wise Consistency Tests Pair-wise consistency tests are run whenever the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library generates an asymmetric (RSA or ECDSA) key pair using a SHA-256 hash. 10.2.3Periodic/On-Demand Self-Tests The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library performs on-demand self-tests initiated by calling the Get_FIPS_Info service. All self-tests in Table 11 marked as “Power up” are then executed. An operator can perform the pair-wise consistency tests on demand by requesting the Key Pair Generation service for RSA or ECDSA.

If the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library fails any of the self-tests, the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library enters the error state. In the error state, the data output interface is inhibited, and the module accepts no more inputs or requests. To recover from the error state, re-initialization is possible by successful execution of the pre-operational self-tests and cryptographic algorithm selftests, which can be triggered by a power-off/power-on cycle. Table 12 lists the error state and the status indicator (through calling the qsee_get_fips_info() function with the info_type parameter set to QSEE_FIPS_SELFTEST_STATUS) values that explains © 2024 Qualcomm Technologies, Inc. / atsec information security.

30 of 38

Table 12 - Error states © 2024 Qualcomm Technologies, Inc. / atsec information security.

31 of 38

Perforce Visual Client (P4V), a version control system from Perforce, is used to manage the revision control of the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library software code. The Perforce Visual Client provides version control, branching and merging of code lines, and concurrent development. Git, an open-source version control system, is also used to manage the revision control of the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library unified crypto software code. Git provides version control, branching and merging of code lines, and concurrent development.

The Snapdragon 8 Gen 2 Mobile Platform SoC is 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 SoC package of the module, it should appear similar to the pictures in Section 2.6. 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, configured as defined in section 11.5, and powered up, the test defined in section 10 will be executed.

There are no maintenance requirements.

As stated in Section 9.4, the module does not possess persistent storage of SSPs. The SSP values only exist in volatile memory and these values vanish when the module is powered off. 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 specified in Section 9.5). As a result of this sanitization via power-off, all SSPs are removed from the module, so that the module may either be distributed to other operators or disposed.

To enable FIPS for the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library, the fuse must be set according to Table 2. The fuse enablement is mandatory to run as a FIPS validated module. This step needs to be performed only once during initial configuration. The information required for the Crypto Officer to verify the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is provided by the qsee_get_fips_info() function © 2024 Qualcomm Technologies, Inc. / atsec information security.

32 of 38

in qsee_fips_services.h. To verify that a Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is FIPS certified, the Crypto Officer should verify the following:  The HMAC of the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is on a list of HMACs of certified crypto modules.

• This can be done by invoking the qsee_get_fips_info() function with the info_type parameter set to QSEE_FIPS_MODULE_HMAC (0). The buffer parameter should point to a buffer which is at least 32 bytes long, and the buffer_len parameter should be at least 32.
• The result buffer should contain the HMAC-SHA-256 of the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library.
• To get the HMAC of the 64-bit Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library, this should be run from a 64-bit Trusted Application.  The FIPS enablement fuse is blown.
• This can be done by invoking the qsee_get_fips_info() function with the info_type parameter set to QSEE_FIPS_FUSE_STATUS (1). The buffer parameter should point to a 4-byte buffer (sizeof(uint32)) and the buffer_len parameter should equal 4.
• The result buffer should contain the value QSEE_FIPS_FUSE_BLOWN (1).  The pre-operational self-tests have passed.
• This can be done by calling qsee_get_fips_info() with the info_type parameter set to QSEE_FIPS_SELFTEST_STATUS (2). The buffer parameter should point to a 4-byte buffer (sizeof(uint32)) and the buffer_len parameter should equal 4.
• The result buffer contains an integer with below representation. Users should interpret the value correspondingly. When a self test for an algorithm is not run, the passed bit and the failed bit will be both 0. After a self test is run, it will be either passed or failed.  CRYPTO_SELFTEST_PASSED_AES (BIT0)  CRYPTO_SELFTEST_PASEED_ECC (BIT1)  CRYPTO_SELFTEST_PASSED_ECDH (BIT2)  CRYPTO_SELFTEST_PASSED_HMAC (BIT3)  CRYPTO_SELFTEST_PASSED_KDF (BIT4)  CRYPTO_SELFTEST_PASSED_RSA(BIT5)  CRYPTO_SELFTEST_PASSED_SHA(BIT6)  CRYPTO_SELFTEST_PASSED_TDES (BIT7)  CRYPTO_SELFTEST_FAILED_AES (BIT13)  CRYPTO_SELFTEST_FAILED_ECC (BIT14)  CRYPTO_SELFTEST_FAILED_ECDH (BIT15)  CRYPTO_SELFTEST_FAILED_HMAC (BIT16)  CRYPTO_SELFTEST_FAILED_KDF (BIT17)  CRYPTO_SELFTEST_FAILED_RSA (BIT18)  CRYPTO_SELFTEST_FAILED_SHA (BIT19)  CRYPTO_SELFTEST_FAILED_TDES (BIT20)  CRYPTO_SELFTEST_INTEGRITY_CHECK_PASSED (BIT29) If one or more of the self-tests failed, the corresponding crypto service will not be exposed to the users.The operation of the Qualcomm® Trusted Execution Environment (TEE) Software © 2024 Qualcomm Technologies, Inc. / atsec information security.

33 of 38

Cryptographic Library does not need FIPS 140-3 specific guidance. The FIPS 140-3 functional requirements are always invoked. To use the cryptographic services of the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library, please refer to 80-NH537-4: Qualcomm Trusted Execution Environment Version 5.0 User Guide. NOTES:  In compliance with [SP 800-38E], the AES algorithm in XTS mode shall only be used for the cryptographic protection of data on storage devices, and the length of a single data unit encrypted with the AES-XTS shall not exceed 2^20 AES blocks. In compliance with IG C.I, the module performs a check to ensure that the two AES-XTS keys are different.  The module supports option 1a from section 5.4 of [SP800-132] PBKDF, in which the Master Key (MK) or a segment of it is used directly as the Data Protection Key (DPK). In compliance with [SP800-132] and IG D.N, the following requirements are met. o Keys derived from passwords shall only be used in storage applications. The Master Key (MK) shall not be used for other purposes. The length of the MK or DPK shall be

• A portion of the salt, with a length of at least 128 bits, shall be generated randomly using the SP800-90Arev1 DRBG.
• The iteration count shall be selected as large as possible, as long as the time required to generate the key using the entered password is acceptable for the users. The minimum value is 1000.
• Passwords or passphrases, used as an input for the PBKDF2, shall not be used as cryptographic keys.
• The length of the password or passphrase is at least 8 characters. For all numeric values, the probability of guessing the value is estimated to be 10^{-8}, which is greater than 2^{-112}.  In compliance with IG C.F, the module supports 2048, 3072, 4096-bit RSA modulus lengths for RSA signature generation. All the RSA signature algorithm implementations have been tested for all implemented RSA modulus lengths. The minimum number of Miller-Rabin tests used in primality testing for key generation is consistent with Table B.1 of FIPS 186-4. The module supports RSA signature verification with 1024, 2048, 3072, 4096-bit modulus lengths, all of which have been CAVP tested. © 2024 Qualcomm Technologies, Inc. / atsec information security.

34 of 38

The elliptic curve implementation uses the Montgomery Ladder, as well as blinding of base points and private key multiplication. The RSA implementation uses base and modulus blinding to mitigate timing-based side-channel attacks. Blinding countermeasures add randomness to private key operations, making determination of secrets from observations more difficult for the attacker. © 2024 Qualcomm Technologies, Inc. / atsec information security.

35 of 38

Appendix A. Glossary and Abbreviations AES                 Advanced Encryption Standard CAVP                Cryptographic Algorithm Validation Program CBC                 Cipher Block Chaining CCM                 Counter with Cipher Block Chaining-Message Authentication Code CFB                 Cipher Feedback CMT                 Cryptographic Module Testing CMVP                Cryptographic Module Validation Program CSP                 Critical Security Parameter CTR                 Counter Mode DES                 Data Encryption Standard DF                  Derivation Function DRBG                Deterministic Random Bit Generator ECB                 Electronic Code Book ECC                 Elliptic Curve Cryptography FIPS                Federal Information Processing Standards Publication HMAC                Hash Message Authentication Code KAT                 Known Answer Test MAC                 Message Authentication Code NDF                 No Derivation Function NIST                National Institute of Science and Technology OFB                 Output Feedback O/S                 Operating System PSS                 Probabilistic Signature Scheme RNG                 Random Number Generator RSA                 Rivest, Shamir, Addleman SHA                 Secure Hash Algorithm SHS                 Secure Hash Standard XTS                 XEX-based Tweaked-codebook mode with cipher text Stealing © 2024 Qualcomm Technologies, Inc. / atsec information security.

36 of 38

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 November 2023 https://csrc.nist.gov/CSRC/media/Projects/cryptographic-module-validationprogram/documents/fips%20140-3/FIPS%20140-3%20IG.pdf FIPS180-4 Secure Hash Standard (SHS) August 2015 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf FIPS186-4 Digital Signature Standard (DSS) July 2013 http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-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 PKCS#1 Public Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1 February 2003 http://www.ietf.org/rfc/rfc3447.txt 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-38C NIST Special Publication 800-38C - Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality May 2004 http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-38c.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 © 2024 Qualcomm Technologies, Inc. / atsec information security.

37 of 38

SP800-57 NIST Special Publication 800-57 Part 1 Revision 5 - Recommendation for Key Management Part 1: General May 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf SP800-90A NIST Special Publication 800-90A - Revision 1 - Recommendation for Random Number Generation Using Deterministic Random Bit Generators June 2015 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf SP800-131A NIST Special Publication 800-131A Revision 2- Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms and Key Lengths March 2019 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf SP800-132 NIST Special Publication 800-132 - Recommendation for PasswordBased Key Derivation - Part 1: Storage Applications December 2010 http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf SP800-133 NIST Special Publication 800-133rev2 - Recommendation for Cryptographic Key Generation June 2020 https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-133r2.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.

38 of 38