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</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</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 bb1535e33256786b753f8632877c9f4e11e267de aa65234d8f3703943d6a6888 Document Version 1.1 Last update: 11-13-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 35

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

3 of 35

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

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

5 of 35

Cryptographic Library

(64 bit)

secure applications. It is part of the common library and provides APIs to the secure applications for cryptography and hashing functions. mined to be a FIPS 140-3 validated module by blowing the TZ_SW_CRYPTO_FIPS_ENABLE fuse and by determining the version number based on its HMAC value combined with the register value of the ARMv8 instruction set architecture for hash operations for SHA-1, SHA-224 and SHA-256.

The software-hybrid cryptographic module consists of the Qualcomm® Trusted Execution Environcryptographic functions are implemented within the library. The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is bound to the on-chip Pseudo Random Number Generator module with version 3.0.0 validated under FIPS 140-3 certificate #4732. The bound module resides within the same physical perimeter of the binding module. graphic module (hereafter referred to as “the module”) is a Software-Hybrid Single-Chip cryptographic module. Table 2 - Components of the Software-hybrid Cryptographic Module Table 3 describes the software component versions that comprise the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library while Table 4 describes the fuse setting that enables the FIPS validated module. The FIPS validated Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library comprises a combination of the software component versions and fuse setting combined together. The ARMv8.5-a is the instruction set version used within the Snapdragon 8 Gen 1 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 35

Enable FIPS compliance for

Q

Cryptographic Library blow to enable.

. Disabled by default and

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

Table 6 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 35

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

8 of 35

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

9 of 35

Table 6 - Approved Algorithms Table 7 lists all non-approved security functions not allowed in approved services of the module. Triple DES is CAVP certified with CAVP Cert. #A2300. 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. #A2300. 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 35

Table 7 - 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. To transition to the non-approved mode, one of the nonapproved services in section 4 of this security policy can be requested. To transition to the approved mode, one of the approved services in section 4 of this security policy can be requested. Table 10 and 11 list the services available in approved and non-approved mode of operation, respectively.

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, the bound module in the dark green box, and the physical perimeter in black. ECDH shared secret computation is CAVP certified with Cert #A2300. However, the shared secret generation does not check the key assurance requirements from SP800-56A Rev 3 regarding 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 35

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

12 of 35

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 (APIs) 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. If its integrity test or KATs fail, the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library goes into error state. To recover from a failure, the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library will need to be re-initialized. When the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is in the error state, the data output is inhibited. The only way to recover from an integrity test failure is to reset the module. 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 Crypto graphic Library. © 2024 Qualcomm Technologies, Inc. / atsec information security.

13 of 35

Table 8 - Ports and Interfaces The module does not implement a control output interface. © 2024 Qualcomm Technologies, Inc. / atsec information security.

14 of 35

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 9 lists the roles supported by the module with corresponding services with input and output. Table 9 - Roles, Service Commands, Input and Output The module does not support authentication for roles.

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

15 of 35

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 1 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.  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 = Zeroise: The module zeroises 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 10 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. * C* © 2024 Qualcomm Technologies, Inc. / atsec information security.

16 of 35

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

17 of 35

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

18 of 35

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

19 of 35

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.

The software integrity test is performed as part of the pre-operational self-tests. The software integrity test can also be invoked on-demand by calling the Get FIPS Info service.

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.

20 of 35

The procurement, build and configuring procedure are controlled. The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is installed into a commercial off-the-shelf (COTS) mobile device by the customer. The software components of this module are executed in the Qualcomm Trusted Execution Environment (TEE) TZ.XF.5.1x. 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.

21 of 35

The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is a software-hybrid module implemented as part of the Snapdragon 8 Gen 1 Mobile Platform SoC, which is the physical perimeter of the single-chip software-hybrid 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 1 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 1 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 1 Mobile Platform SoC. There are no steps required to ensure that physical security is maintained. © 2024 Qualcomm Technologies, Inc. / atsec information security.

22 of 35

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

23 of 35

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

24 of 35

# Table 12 - SSPs The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library implements Password-Based Key Derivation version 2 (PBKDF) as defined in [SP800-132]. The PBKDF 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 length of the salt should be at least 128 bits and the length of the password or passphrase should be at least 8 characters, which provides the probability of guessing this password or passphrase to be (1/10)8 assuming a scenario where all characters are digits. The caller shall observe all requirements and should consider all recommendations specified in SP800-132 with respect to the strength of the generated key, including the quality of the password, the quality of the salt as well as the number of iterations. 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. ECDSA key pair generation is done according to FIPS 186-4, Appendix B.4.2 (Testing Candidates). RSA key pair generation is done according to FIPS 186-4, Appendix B.3.3 (Probable Prime Genera© 2024 Qualcomm Technologies, Inc. / atsec information security.

25 of 35

tion). The seeds (i.e., the random values) used in asymmetric key pair generation are directly obtained from the SP 800-90Arev1 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, electronic SSP entry or output. The SSPs are provided to the module via API input parameters in plaintext form and output via API output parameters in plaintext form. During SSP entry, all data output through the data output interface is inhibited. The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library does not enter or output SSPs in plaintext format outside its physical perimeter.

All SSPs are output from and entered into the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library to and from the calling process and are destroyed from memory when released. The module does not perform persistent storage of SSPs. The SSPs will be 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.

26 of 35

The module performs pre-operational self-tests and conditional self-tests. While the module is executing the self-tests, services are not available, and data output (via the data output interface) is inhibited until the tests are successfully completed. The module is not available to be used by the calling application until the pre-operational self-tests and cryptographic algorithm self-tests are completed successfully. All the self-tests are listed in Table 13, with the respective condition under which those tests are tests (CASTs) are performed. The self-tests for the DRBG and SHA used from the bound module are implemented by the bound module. Table 13 - Self-tests © 2024 Qualcomm Technologies, Inc. / atsec information security.

27 of 35

The Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library performs pre-operational self-tests when it is loaded into memory, without operator intervention. Pre-operational self-tests ensure that the module is not corrupted. The module 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. The integrity of the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library 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 HMAC-SHA-256 algorithm goes through its cryptographic algorithm self-test before the integrity test is performed (Table 13).

The module performs self-tests on all approved cryptographic algorithms as part of the approved services using the tests shown in Table 13. Data output through the data output interface is inhibited during the self-tests. The module transitions to the operational state only after the cryptographic algorithm self-tests are passed successfully.

Pair-wise consistency tests are run whenever the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library generates an asymmetric (RSA or ECDSA) key pair. If the pair-wise consistency check fails, the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library enters an error state and returns an error status code.

The module performs on-demand self-tests initiated by calling the Get FIPS Info service. All selftests in Table 13 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. The same procedures may be employed by the operator to perform periodic self-tests.

If the module fails any of the self-tests, the module enters the error state. In the error state, the module outputs the error type through the status output interface. 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 self-tests, which can be triggered by a power-off/power-on cycle. Table 14 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 the error that has occurred. © 2024 Qualcomm Technologies, Inc. / atsec information security.

28 of 35

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

29 of 35

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 Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library is a software-hybrid module that runs on the Snapdragon 8 Gen 1 Mobile Platform. This 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 look similar to the pictures in Figure 2. 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 (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 4. The fuse enablement is mandatory to run as a FIPS validated module. This step needs to be performed only once during initial installation. 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 in © 2024 Qualcomm Technologies, Inc. / atsec information security.

30 of 35

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 4byte 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 and cryptographic algorithm 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 should contain the value QSEE_CRYPTO_SELFTEST_PASSED (1).
• If one or more of the self-tests failed, the TZ runtime environment will not be able to load Trusted Applications. The operation of the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library does not need FIPS 140-3 specific guidance. The FIPS 140-3 functional requirements are always invoked. Once operational, if the Qualcomm® Trusted Execution Environment (TEE) Software Cryptographic Library enters the Error state, the Crypto Officer needs to re-initialize the library instance in order to recover from the Error state. 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:  The AES algorithm in XTS mode can be only used for the cryptographic protection of data on storage devices, as specified in [SP 800-38E]. In addition, 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 verifies that the two keys used in AES-XTS are not equal.  The keys derived from passwords, as shown in SP 800-132, may only be used in storage applications.  In compliance with IG C.F, the module supports RSA signature generation with modulus lengths of 2048, 3072, and 4096 bits, and RSA signature generation has been CAVP tested for all of these modulus lengths. The number of Miller-Rabin tests are consistent with Appendix B of FIPS 186-4. The module performs RSA signature verification according to FIPS 186-4 with modulus lengths of 1024, 2048, 3072, and 4096 bits; RSA signature verification has been CAVP tested for all of these modulus lengths. © 2024 Qualcomm Technologies, Inc. / atsec information security.

31 of 35

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.

32 of 35

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

33 of 35

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 2024 https://csrc.nist.gov/Projects/cryptographic-module-validation-program/fips-1403-ig-announcements FIPS180-4 Secure Hash Standard (SHS) March 2012 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.

34 of 35

SP800-57 NIST Special Publication 800-57 Part 1 Revision 4 - Recommendation for Key Management Part 1: General January 2016 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf SP800-90Ar1 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- NIST Special Publication 800-131A Revision 1- Transitions: Recommen131Ar1 dation for Transitioning the Use of Cryptographic Algorithms and Key Lengths November 2015 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.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-133r2 NIST Special Publication 800-133rev2 - Recommendation for Cryptographic Key Generation December 2012 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.

35 of 35