Trusted Platform Module ST33KTPM2XSPI / ST33KTPM2XI2C

Certificate

Approved Algorithms (11)

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

flowchart LR
  %% Deterministic review-risk graph for Trusted Platform Module ST33KTPM2XSPI / ST33KTPM2XI2C
  %% 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>recovery<br/>upgrade<br/>firmware load</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>status output</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>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."]
    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?"]
    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"]
    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
  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,C6 clue;
  class I2,I3,I6 infer;
  class R2,R3,R6 risk;
  class E2,E3,E6 evidence;

flowchart LR
  %% Deterministic clue tier for Trusted Platform Module ST33KTPM2XSPI / ST33KTPM2XI2C
  %% 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>recovery<br/>upgrade<br/>firmware load</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>status output</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>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,C6 clueLow;

Security Policy, page by page

STMICROELECTRONICS Trusted Platform Module ST33KTPM2XSPI / ST33KTPM2XI2C Level 1 Date: 2024-03-06 Document Version: 01-02 NON-PROPRIETARY DOCUMENT FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

This document is the non-proprietary FIPS 140-3 Security Policy for the STMicroelectronics Trusted Platform Module ST33KTPM2XSPI / ST33KTPM2XI2C. It details how the module meets the requirements specified in [FIPS 140-3] for a Security Level1 module.

Next table indicates the security levels reached by the security module. Table 1 - Security Levels FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

The current FIPS 140-3 level 1 security policy always applies (no mode lock requested) to this security module configuration. SPI or I2C mode selection is done during the boot of the security

The security module supports the following cryptographic algorithms (both approved and nonapproved). Algorithm certificate numbers for each approved algorithm are listed below. All algorithms, keys size or curve lengths listed below are part of services offered by the module. FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

Table 5 - Approved Algorithms Table 6 - Vendor Affirmed Approved Algorithms

1 Seed or reseed SP800-90A approved DRBG with a minimum of 414 bits of entropy. Generate random

numbers not dedicated to being used as cryptographic material.

2 Per [IG] D.F Scenario 2 path (2), [56Ar3] compliant key agreement scheme where testing is performed end-to-end

for the shared secret computation and a KDF compliant with oneStepKdf [56Cr1] without key confirmation.

5 Symmetric keys and seeds used for generating the asymmetric keys are either generated by using

KBKDF or DRBG methods. Methods are detailed per SSPs in Table 19 and Table 20. FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

Table 9 - Security Function Implementations FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

RSA/ECC HW accelerator RAM RAM S bus

CPU core MPU

CPU core MPU C-AHB bus

SPI / I2C interface

A block diagram of the security module with its associated cryptographic boundary is provided in Figure 2. memory Read RAM RAM ST ROM cache APB/AHB Cryptographic bridge boundary f APB Security Administrator EDES+ HW Clock generator Reset manager ENT (P) Timers GPIOs module Power mngt GPIO GND VC C LEGEND Instructions Input/output data/commands External control Internal data Cryptographic Internal control boundary Figure 2 - HW block diagram Module is composed of:

• Two CPU cores, each including a MPU (Memory Protection Unit)
• Memories (RAMs, Flash and ROM) that store data or FW
• HW accelerators for CRC (16 and 32-bits), symmetric cryptographic operations (AES) and asymmetric cryptographic operations (RSA/ECC)
• A clock generator and timers
• ENT (P)
• SPI and I2C1 master/slave blocks
• An administration block dedicated to chip security configuration and alarms detection

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

1. The Module provides one operator role: the Cryptographic Officer.
2. The Module, evaluated at FIPS 140-3 Level 1, does not claim to provide authentication.
3. The Module allows the operator to initiate power-up self-tests by power cycling or resetting the Module.
4. Power up self-tests do not require any operator action.
5. Data output is inhibited during key generation, self-tests, zeroization, firmware loading, and error states.
6. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the Module.
7. The Module does not support concurrent operators.
8. The Module does not support a maintenance interface or role.
9. The Module does not support manual key entry method.
10. The Module does not have any proprietary external input/output devices used for entry/output of data.
11. The Module does not output intermediate key values.
12. The Module does not provide bypass services or ports/interfaces. FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

their mapping to physical ports of the module are described below: Table 11 - Ports and Interfaces Here are some details concerning the ports and interfaces of TPM: distinguished by properly parsing input TPM command parameters according to input structures description, indicated for each command in [TPM2.0 Part3]1. and control are distinguished by properly setting output TPM response parameters according to output structures description, indicated for each command in [TPM2.0 Part3].

3. The logical state machine and the command structure parsing of the module prevent from using input data externally from the “data input path” and prevent from outputting data externally from
4. While performing key generation or key zeroization (no manual key entry on TPM), the output data path is logically disconnected while the output status path remains connected to report any possible failure during command processing. Generally, the output data path is only connected when TPM outputs response containing data.
5. To prevent the inadvertent output of CSPs in plaintext form on TPM2_Duplicate, the two following independent internal actions are performed: a. Verification of the encryptedDuplication attribute of the key to be duplicated b. Verification of the handle of the new parent of the key to be duplicated encryptedDuplication attribute must be set to 0 and new handle must be set to the null handle to authorize outputting the private part of the key in plaintext form.
6. The logical state machine and command structure of the module guarantees the inhibition of all data output via the data output interface whenever an error state exists and while doing selftests. The status output interface remains active during the error state to output the status of the security module with the service TPM2_GetCapability and TPM2_GetTestResult. FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

1 The internal security function is not directly callable from the security module external interfaces. Function is used (or might be used) by the services listed in this table. When a service

is usable with a session, (I) is added next to the service name. When a service can additionally use the encryption mechanism of a session, (I/E) is added next to the service name. FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

Table 15 - Non-Approved Services FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

A block diagram of the FW is provided in Figure 4. Core Memory Loader Sequencer Sequencer HWINTF HWINTF library TPM2.0 commands library TPM2.0 commands TPM2.0 core TPM2.0 core Memory Memory management and management and low-level services low-level services Cryptographic Cryptographic library library TPM instance #1 TPM instance #2 Figure 4 - FW block diagram FW integrity is verified by computing an EDC (CRC-16 ISO 13239) over the active FW and comparing it to a reference value. FW integrity is verified during boot sequence before execution of one of the code blocks (CML and TPM) and can be triggered on demand by the operator with the execution of the service TPM2_SelfTest (full parameter must be set to YES) or TPM2_IncrementalSelfTest. If failure is detected during boot sequence, TPM enters an infinite reset loop that can be exit only by a power-off/power-on sequence. If failure is detected during self-tests, the security module enters failure mode. FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

Module operational environment is “limited” because it allows loading authenticated firmware that meets all applicable requirements of [FIPS 140-3] standard. Loading of FW on the security module can be achieved by using two services:

• TPM2_VendorCmdFieldUpgradeStart that performs the software/firmware load test detailed in the self-test section of this document to determine if the authorizations to start a loading session are granted
• TPM2_VendorCmdFieldUpgradeData that transports the protected (confidentiality and integrity) parts of the FW Data outputs are inhibited until the loading session has completed successfully. Execution of the successfully loaded FW is only effective after the next reset of the security module. New firmware versions must be validated through the FIPS 140-3 evaluation process. Any other firmware loaded into this module is out of the scope of this validation and require a separate FIPS 140-3 validation. The core memory loader (CML) represented in Figure 4 is non-modifiable, only the TPM instances are modifiable by using an authenticated firmware upgrade mechanism. The security module contains two instances of the FW but only one FW instance is executed after a boot sequence. FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

The security module meets the Physical Security protection requirements for single-chip module at FIPS 140-3 Level 1. The module is production grade.

Zeroization, performed for physical security purposes by some services (refer to detailed services in Table 15), occurs in a sufficiently small time-period to prevent the recovery of the sensitive data between the time of detection and the actual zeroization. FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

The security module does not claim support of non-invasive security attack mitigation techniques referenced in [NIST SP800-140F]. FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

Table 18 - SSP Zeroization Methods Next tables list all the SSPs in the security module.

1 Temporary storage duration column was removed for readability purpose because when temporary storage is indicated, duration corresponds to the duration of a command execution.

2 The algorithms indicated in this column correspond to the certified algorithms listed in Table 5.

3 The algorithms indicated in this column correspond to the certified algorithms listed in Table 5.

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

Table 19 - SSPs (list of keys) Table 20 - SSPs (not used as keys)

1 Temporary storage duration column was removed for readability purpose because when temporary storage is indicated, duration corresponds to the duration of a command execution.

2 The algorithms indicated in this column correspond to the certified algorithms listed in Table 5.

3 The algorithms indicated in this column correspond to the certified algorithms listed in Table 5.

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

Table 21 - Security strength of a key depending on the underlying algorithm used and its size FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

The security module implements:

• A Hash-DRBG based on SHA256 and compliant with the [SP800-90A] standard (state is indicated as drbgState in Table 20). It is seeded at each module start-up with 512 used as SSP in a cryptographic operation. It can be reseeded by using the service TPM2_StirRandom.
• A transient Hash-DRBG based on SHA256 and compliant with the [SP800-90A] standard (state is indicated as tdrbgState in Table 20.) involved only in primary keys generation and seeded as defined in [TPM2.0 Part1] and [TPM2.0 Part3].
• An ENT (P) as detailed in table below. Table 22 - Non-Deterministic Random Number Generation Specification FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

Self-tests run by the cryptographic module are split into two categories:

• Pre-operational self-tests
• Conditional self-tests The self-tests do not require operator intervention to run.

In case of self-test failure, the security module outputs the return code TPM_RC_FAILURE as defined in [TPM2.0 Part2] via the status interface and the module enters the failure state. In failure state, the module does not perform any cryptographic functions and all data output via the data output interface are inhibited. The only usable services in failure state are TPM2_GetTestResult and TPM2_GetCapability to get a status on the functionality whose selftest failed. Failure can be exit by resetting the security module. If pre-operational self-tests passed successfully, no success status is indicated but commands that require self-tests to be completed can be successfully executed.

The module performs the following pre-operational self-tests: Table 23 - Pre-Operational Self-Tests

The Module performs the following conditional self-tests:

1 Bit index indicated corresponds to the index in the algo_status field in the TPM2_GetTestResult

response FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

Table 24 - Conditional Self-Tests Successful completion of self-tests can be verified through use of TPM2_GetTestResult command. The first 4 bytes of response indicate self-tests status. If they are equal to 0, selftests completed successfully. If not, the subsequent 4 bytes indicate the list of algorithms not fully self-tested. FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

The security module does not claim mitigation of other attacks. FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT

IMPORTANT NOTICE – PLEASE READ CAREFULLY STMicroelectronics NV and its subsidiaries (“ST”) reserve the right to make changes, corrections, enhancements, modifications, and improvements to ST products and/or to this document at any time without notice. Purchasers should obtain the latest relevant information on ST products before placing orders. ST products are sold pursuant to ST’s terms and conditions of sale in place at the time of order acknowledgement. Purchasers are solely responsible for the choice, selection, and use of ST products and ST assumes no liability for application assistance or the design of Purchasers’ products. No license, express or implied, to any intellectual property right is granted by ST herein. Resale of ST products with provisions different from the information set forth herein shall void any warranty granted by ST for such product. ST and the ST logo are trademarks of ST. All other product or service names are the property of their respective owners. Information in this document supersedes and replaces information previously supplied in any prior versions of this document. This document may be reproduced only in its original entirety without revision. www.st.com FIPS140-3 SECURITY POLICY NON-PROPRIETARY DOCUMENT