Trusted Platform Module ST33KTPM2A / ST33KTPM2I

Certificate

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

flowchart LR
  %% Deterministic review-risk graph for Trusted Platform Module ST33KTPM2A / ST33KTPM2I
  %% 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/>update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>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 ST33KTPM2A / ST33KTPM2I
  %% 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/>update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Self-Test<br/>UnAuth<br/>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 ST33KTPM2A / ST33KTPM2I Document Version: 04-02 Date: 2025-11-13 Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

This document is the non-proprietary FIPS 140-3 Security Policy for the STMicroelectronics Trusted Platform Module ST33KTPM2A / ST33KTPM2I (ST33KTPM2A is also branded commercially “STSAFE-V100TPM”). It contains the security rules under which the Module must operate and describes how this module meets the requirements as specified in FIPS PUB 140-3 (Federal Information Processing Standards Publication 140-3) for an overall Security Level 2 module.

The FIPS 140-3 security levels for the Module are listed in table below: Table 1: Security Levels Public Material – May be reproduced only in its original entirety (without revision).

The ST33KTPM2A / ST33KTPM2I module, hereafter denoted as the Module, is a fully integrated security module implementing the revision 1.59 of the Trusted Computing Group (TCG) specification for Trusted Platform Modules (TPM) version 2.0.

Purpose and Use: The Module is intended for use by US Federal agencies or other markets that require FIPS 140-3 validated Level 2. The Module is designed to be integrated into personal computers or any other embedded electronic systems. TPM is primarily used for cryptographic keys generation, keys storage, keys management and secure storage for digital certificates. Module Type: Hardware Module Embodiment: SingleChip Module Characteristics: Cryptographic Boundary: The cryptographic boundary of the Module is defined as the perimeter of the IC package and both versions of the Module are represented in the next figure. The Module is composed of:

• Two CPU cores, each including an MPU.
• 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.
• An entropy source covered by an ESV Certificate.
• SPI and I2C master/slave blocks.
• An administration block dedicated to chip security configuration and alarms detection. Public Material
• May be reproduced only in its original entirety (without revision).

Figure 1

• HW block diagram Public Material
• May be reproduced only in its original entirety (without revision).

Tested Module Identification

• Hardware: The operating environments covered by the FIPS 140-3 validation are summarized in the table below: Table 2: Tested Module Identification
• Hardware ST33KTPM2A and ST33KTPM2I are manufactured in the UFQFPN32 WF package:
• UFQFPN32 WF
• Ultra-thin pitch Quad Flat No-lead 32-pin Wettable Flanks
• 5 x 5 mm Figure 2
• UFQFPN32 WF Package
• TSSOP 20-pin
• 6.5 x 4.4 mm Public Material
• May be reproduced only in its original entirety (without revision).

Figure 3

• TSSOP20 Package The ST33KTPM2I product is also manufactured in the WLCSP24 package:
• WLCSP 24-pin
• 1.8 x 2.5 mm Figure 4
• WLCSP24 Package

No components have been excluded from the cryptographic boundary. Public Material – May be reproduced only in its original entirety (without revision).

Table 3: Modes List and Description

Approved Algorithms: The Module implements the Approved cryptographic algorithms listed in the table below: Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 4: Approved Algorithms Vendor-Affirmed Algorithms: The Module implements the Vendor Affirmed cryptographic algorithms listed. D.H N/A Table 5: Vendor-Affirmed Algorithms Non-Approved, Allowed Algorithms: The Module implements the Non-Approved, but Allowed cryptographic algorithms listed. Public Material – May be reproduced only in its original entirety (without revision).

Table 6: Non-Approved, Allowed Algorithms The Module implements the Non-Approved, Allowed cryptographic Algorithms with No Security The Module implements the Non-Approved, Not Allowed cryptographic algorithms listed. Public Material – May be reproduced only in its original entirety (without revision).

Table 8: Non-Approved, Not Allowed Algorithms

Next table shows the Security Function Implementations that the Module implements: Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

n Table 9: Security Function Implementations

Notes: KAS [56Ar3] - Per [IG] D.F Scenario 2 path (2), compliant key agreement scheme where testing is performed end-to-end for the shared secret computation and key derivation.

The Module implements:

• A Hash-DRBG based on SHA2-256 and is compliant with the [90A] standard (state is referred to as drbgState in SSPs table). It is seeded at each module start-up with 512 bits issued from the ENT (P). Hash-DRBG is used for any generation of random values used as SSP in a cryptographic operation. It can be reseeded by using the service TPM2_StirRandom.
• A transient Hash-DRBG based on SHA2-256 and is compliant with the [90A] standard (state is referred to as tdrbgState in SSPs table) involved only in primary keys generation and seeded as defined in [TPM2.0 Part1] and [TPM2.0 Part3].
• An entropy source as detailed below: Table 10: Entropy Certificates Public Material
• May be reproduced only in its original entirety (without revision).

Name ST33KTPM2A, ST33KTPM2I entropy source

Type

Operational Environment

Sample Size

Entropy per Sample

Conditioning Component

For Key Generation, see Section 2.5 and Section 2.6 above.

Key Agreement Information For Key Agreement, see Section 2.5 and Section 2.6 above. Key Transport Information For Key Transport, see Section 2.5 and Section 2.6 above.

The Module does not implement any Industry Protocols. Public Material – May be reproduced only in its original entirety (without revision).

The Module’s ports and associated logical interface categories are listed below: Table 12: Ports and Interfaces Additional details concerning the ports and interfaces of TPM: 1. Control and data inputs are multiplexed over the same physical interface. Control and data are distinguished by properly parsing input TPM command parameters according to input structures description, indicated for each command in [TPM2.0 Part3]. Some commands only deal with Public Material – May be reproduced only in its original entirety (without revision).

2. Status, data and control output are multiplexed over the same physical interface. Status, data, 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 the Module from using input data externally from the “data input path” and prevent the Module from outputting data externally from the “data output path”.
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.
7. 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.

The pin layouts for the various packages are shown in the next figures. The ST33KTPM2A / ST33KTPM2I security modules support both SPI and I2C physical interfaces but only one interface is configured during TPM boot. The interface configured remains active until the next module reset. Public Material – May be reproduced only in its original entirety (without revision).

UFQFPN32 / UFQFPN32 WF configuration The pin layouts for the UFWFPN32 / UFWFPN32 WF packages are shown in the next figure. Figure 5

• UFQFPN32 / UFQFPN32 WF Pinout Diagram The table below gives a description of the products’ pins. Table 13
• UFQFPN32 / UFQFPN32 WF Pins Definition Public Material
• May be reproduced only in its original entirety (without revision).

TSSOP20 configuration The pin layouts for the TSSOP20 package are shown in the next figure. Figure 6

• TSSOP20 Pinout Diagram The table below gives a description of the products’ pins. Table 14
• TSSOP20 Pins Definition Public Material
• May be reproduced only in its original entirety (without revision).

WLCSP24 configuration The pin layouts for the WLCSP24 package are shown in the next figure. Figure 7

• WLCSP24 Pinout Diagram bottom view The table below gives a description of the products’ pins. Table 15
• WLCSP24 Pins Definition Public Material
• May be reproduced only in its original entirety (without revision).

The Module implements the following authentication techniques in accordance with the Level 2 requirements: Table 16: Authentication Methods

The Roles Table below lists all operator roles supported by the Module. Public Material – May be reproduced only in its original entirety (without revision).

Table 17: Roles The Module does not provide a maintenance role or maintenance interface and does not support concurrent operators. The role is implicitly selected by the TPM operator on service execution by proving the knowledge of the enhanced authorization commands sequence and/or the authorization value of an object. All services are accessible under the roles defined above and no specific access rights are considered to operate with keys and SSPs. Full services inputs and outputs are defined in [TPM2.0 Part3]. The next table Table 18 – Mapping between services The SSPs modes of access shown in the table below are defined as:

Some details about information found in the table:

• In “Name” column, (I) indicates that service is usable with sessions integrity mechanism, (E) indicates that service is usable with encryption session (encryption of 1st parameter of response), (D) indicates that service is usable with decryption session (decryption of 1st parameter of command) Public Material
• May be reproduced only in its original entirety (without revision).

• In “Indicator” column, the value of indicator can be Approved (bit field 01b), non-Approved (bit field 10b) or non-security relevant (bit field 00b).
• In “Inputs” column, commands inputs are not exhaustive, some non-security parameters are voluntarily missed. Full inputs of all commands are defined in [TPM2.0 Part3]
• In “Outputs” column, Outputs of all responses are defined in [TPM2.0 Part3]
• In “Security Function Implementation” column, security functions are referenced by their identifiers indicated in Table 4, Table 5, Table 11, and Table 12.
• In “Roles” column, NA indicates that the service does not require authentication. The list of roles is indicated in paragraph 4.2. r Z Z Z Z Z Z Z Public Material
• May be reproduced only in its original entirety (without revision).

Name

Description

Indi cato r

Inputs

Outputs

Secu rity Func tions

SSP Access ey: Z - objHmac Key: Z - contextE ncKey: Z - dupSeed: Z - dupInSy mKey: Z - dupOutS ymKey: Z - dupOutH macKey: Z - creSeed: Z - creSymK ey: Z - creHmac Key: Z - ephSens EccKey: Z - ephPubE ccKey: Z - seqAuth: Z - drbgSeed : Z - tdrbgStat e: Z - fuSymKe

r Z Z Z Z Z :Z e: Z Public Material – May be reproduced only in its original entirety (without revision).

r y: Z G G G G G :G :G G G G Public Material – May be reproduced only in its original entirety (without revision).

r G,E,Z Public Material – May be reproduced only in its original entirety (without revision).

r E :E h: E E G G,E,Z ) Public Material – May be reproduced only in its original entirety (without revision).

r E E E E W,E W W y W W R Public Material – May be reproduced only in its original entirety (without revision).

r d l W,E,Z Public Material – May be reproduced only in its original entirety (without revision).

r G,R,E E E E Public Material – May be reproduced only in its original entirety (without revision).

Name

Description

Indi cato r

Inputs

Outputs

Secu rity Func tions

SSP Access - phProof: E - ehProof: E - shProof: E - ekRsa: E - ekEcc: E - shProofF orReseed : G,E User (U) - objSeed: G,E - objSymK ey: G,E - objHmac Key: G,E - objSens: G,R - objPub: G,R,E - tdrbgStat e: G,W,E - drbgState : W - objAuth: W - nullSeed: E - phSeed: E - ephSens EccKey:

r E E E E E : G,E G,E G,R G,R,E e: G,W,E :W W E E Public Material – May be reproduced only in its original entirety (without revision).

r E E E E E : G,E E E G,R,E,Z R G G,E,Z R R Public Material – May be reproduced only in its original entirety (without revision).

r : W,E E E R,W Public Material – May be reproduced only in its original entirety (without revision).

r E,W,Z E,W,Z W,E,Z G,R,Z Public Material – May be reproduced only in its original entirety (without revision).

r : W,E E (I/E/D) W,E,Z E Public Material – May be reproduced only in its original entirety (without revision).

r E E E (I/E) G : W,E E W Public Material – May be reproduced only in its original entirety (without revision).

r E E E Z e Public Material – May be reproduced only in its original entirety (without revision).

r E E e Public Material – May be reproduced only in its original entirety (without revision).

r E e G E e e e Public Material – May be reproduced only in its original entirety (without revision).

r E E G E Public Material – May be reproduced only in its original entirety (without revision).

r E E e E Public Material – May be reproduced only in its original entirety (without revision).

r E E E E E E Public Material – May be reproduced only in its original entirety (without revision).

r n n Public Material – May be reproduced only in its original entirety (without revision).

r Public Material – May be reproduced only in its original entirety (without revision).

r Public Material – May be reproduced only in its original entirety (without revision).

r e: G,W,E,Z : W,E W E E E E E E E E E E : G,E Public Material – May be reproduced only in its original entirety (without revision).

r G Z Z Public Material – May be reproduced only in its original entirety (without revision).

r Z Z Z Z Z : W,E Z Z G :Z Z Z Z Z Public Material – May be reproduced only in its original entirety (without revision).

r :W h: W y: G Public Material – May be reproduced only in its original entirety (without revision).

r y: E,Z G,E,Z R R R E E R Public Material – May be reproduced only in its original entirety (without revision).

r W W W W E E E E W Z Public Material – May be reproduced only in its original entirety (without revision).

r W,Z W,Z W,Z W,Z Public Material – May be reproduced only in its original entirety (without revision).

r Public Material – May be reproduced only in its original entirety (without revision).

r Public Material – May be reproduced only in its original entirety (without revision).

r Public Material – May be reproduced only in its original entirety (without revision).

r s : W,E W Z Public Material – May be reproduced only in its original entirety (without revision).

r E E E E E E E E Public Material – May be reproduced only in its original entirety (without revision).

r Table 19: Approved Services Public Material – May be reproduced only in its original entirety (without revision).

The integrity mechanism provided by sessions 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. The encryption mechanism provided by sessions 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. Public Material – May be reproduced only in its original entirety (without revision).

All Approved services implemented by the Module are listed in the table below: Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 20: Non-Approved Services Public Material – May be reproduced only in its original entirety (without revision).

Loading of firmware onto the 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 firmware. Several commands are necessary to transport the full firmware. Data outputs are inhibited until the loading session has completed successfully. Execution of the successfully loaded firmware is only effective after the next reset of the security module. New firmware versions must be validated through the FIPS 140-3 validation process. Any other firmware loaded into this module is out of the scope of this validation and requires a separate FIPS 140-3 validation. The core memory loader (CML) represented in Figure 8 is non-modifiable, only the TPM instances are modifiable by using an authenticated firmware upgrade mechanism. The Module contains two instances of the firmware but only one instance is executed after a boot sequence. Public Material
• May be reproduced only in its original entirety (without revision).

The Module is composed of the following firmware component(s):

• Core Memory Loader executable (aka CML)
• TPM application instance 1 executable
• TPM application instance 2 executable The firmware integrity is verified by computing a CRC-16 [ISO 13239] over the active firmware and comparing it to a reference value. Firmware integrity is verified during the boot sequence before the execution of the code blocks (CML and TPM). If a failure is detected during the boot sequence, the TPM enters an infinite reset loop that can be exited only by a power-off/power-on sequence. If a failure is detected during the self-tests execution, the security module enters failure mode. 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 8
• Firmware block diagram

The operator can initiate the integrity test on demand by using the TPM2_SelfTest command with the full parameter set to YES or by using the TPM2_IncrementalSelfTest command. Public Material – May be reproduced only in its original entirety (without revision).

Type of Operational Environment: Limited The operational environment of the Module is “limited” because it allows loading authenticated firmware that meets all applicable requirements of [140-3] standard. 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 validation process. Any other firmware loaded into this module is out of the scope of this validation and requires a separate FIPS 140-3 validation. The core memory loader (CML) represented in Figure 8 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. Public Material – May be reproduced only in its original entirety (without revision).

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

Zeroization Zeroization of CSPs can be triggered by specific services as detailed in Section 9.3. It occurs in a sufficiently small time-period to prevent the recovery of the sensitive data between start of zeroization and the zeroization completion. Physical security mechanisms The security module is encapsulated in a hard opaque package to prevent direct observation of internal security components. It implements additional security mechanisms:

• An active metal shield, located inside the package and covering the internal circuitry and the memory components. Cutting, removing, or modifying the shield layer will cause the security module to reset and enter a shutdown mode.
• An internal circuitry detecting environmental conditions outside the nominal operating range. Power supply voltage and temperature are continuously monitored. If conditions exist outside the range determined by the tamper detection circuitry, the security module resets and enters a failure mode. The Module remains in failure mode as long as the environmental condition causing the tamper event persists. Table 21: Mechanisms and Actions Required

EFT has been performed for all security module configurations. Low and high temperatures have been measured at a nominal voltage of 3.3V. Low and high voltage have been measured at ambient temperature (25°C). The nominal operating ranges are:

• Between 1.62V and 3.8V for voltage
• Between -40°C and +125°C for temperature Public Material
• May be reproduced only in its original entirety (without revision).

Table 22: EFP/EFT Information Public Material – May be reproduced only in its original entirety (without revision).

Hardness testing was conducted at the temperature indicated in the table below: Table 23: Hardness Testing Temperatures Public Material – May be reproduced only in its original entirety (without revision).

The Module does not claim support of non-invasive attack mitigation techniques referenced in [140F]. Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 25: SSP Input-Output Methods Public Material – May be reproduced only in its original entirety (without revision).

Table 26: SSP Zeroization Methods All usage of these SSPs by the Module are described in the services detailed in section 4. The next table lists the SSPs used as keys. Temporary storage duration column was removed for readability purposes because when temporary storage is indicated, duration corresponds to the duration of a command execution. The algorithms indicated in “Generate by” and “Used by” columns correspond to items in the SFI table. Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Table 27: SSP Table 1 Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

Public Material – May be reproduced only in its original entirety (without revision).

The use of SHA-1 for digital signature generation is non-Approved and only available through non-Approved services. All other applications of SHA-1 are acceptable, where collision resistance is not required. Public Material – May be reproduced only in its original entirety (without revision).

The next table gives the security strength of a key depending on the underlying algorithm used and its Table 29

• Security Strength of a Key Depending on the Underlying Algorithm Used and its Size Public Material
• May be reproduced only in its original entirety (without revision).

The Module performs self-tests to ensure the proper operation of the Module. Per FIPS 140-3 these are categorized as either pre-operational self-tests or conditional self-tests. Pre-operational self–tests are available on demand by power cycling the Module. The Module performs the following pre-operational self-tests in the table below: Table 30: Pre-Operational Self-Tests

The Module performs the following conditional self-tests as shown in the table below. The bit index indicated in the “Indicator” column corresponds to the index in the algo_status field in the TPM2_GetTestResult response. Public Material – May be reproduced only in its original entirety (without revision).

Table 31: Conditional Self-Tests Public Material – May be reproduced only in its original entirety (without revision).

Table 32: Pre-Operational Periodic Information Public Material – May be reproduced only in its original entirety (without revision).

Table 33: Conditional Periodic Information

Table 34: Error States All cryptographic functions are inhibited while the Module is in an error state. 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, self-tests completed successfully. If not, the subsequent 4 bytes indicate the list of algorithms not fully self-tested. Public Material – May be reproduced only in its original entirety (without revision).

Installation and Initialization: The following steps must be performed in order to securely install, initialize, and start up the Module in the FIPS 140-3 Approved mode of operation:

• Connection of the Module with its environment must be done according to the pinout description detailed in section 3.2.
• Command TPM2_SetCapability with the following parameters must be sent to the Module to configure it in FIPS 140-3 Level 2 mode: o setCapability = TPM_CAP_N_CONFIGS (0x80100000) o configuration = TPM_PT_CONFIG_FIPS_SL2_MODE (0x00000000) o enable = YES (0x01) o lock = YES (0x01) Module operation: Once configured in FIPS 140-3 Level 2, the following restrictions are enforced by the Module:
• The default authValue of hierarchies (owner, endorsement, lockout, platform) must be changed prior to being used in an authorization session. If not done, the authorization will be reported as failed.
• Use of other authorization sessions than the ones described in section 4.1 is prohibited except for the following use cases:
• First use or use after TPM2_Clear (for the owner, endorsement, or lockout authValue) or use after reset (for the platform authValue) of the TPM2_HierarchyChangeAuth command to change the default authValue of the hierarchies.
• If the minimum length of an object’s authValue is less than 112 bits (14 bytes), the creation of the object will fail with the error TPM_RC_AUTHSIZE. This concerns keys, NV indices and Hash/HMAC sessions.
• Use of a policy authorization session will fail and report TPM_RC_AUTH_FAIL if one of the following policy commands is not part of the policy: Public Material
• May be reproduced only in its original entirety (without revision).

Table 35

• List of policy commands to use in a policy session TPM is operated in an Approved mode of operation as long as no non-Approved service using a nonApproved algorithm is used. No specific rules of operation are required to operate this module at FIPS 140-3 Level 2. TPM is in normal operation mode when all pre-operational and conditional self-tests (apart from firmware load and PCT tests) are complete. All Approved and non-Approved services with the corresponding indicator reporting if the service uses an Approved cryptographic algorithm or a security function. Products list: The Module configurations indicated in Table 8 are defined into several manufactured products listed hereafter. The default firmware version of ZA9 and AC5 modules configuration is 10.257. To operate with firmware version 10.512, the Module must first be field upgraded to 10.512. Public Material
• May be reproduced only in its original entirety (without revision).

The current FIPS 140-3 Level 2 Security Policy applies to the Module configurations listed above when the Module is configured in FIPS 140-3 Level 2 mode with the command TPM2_SetCapability. For the configurations supporting both SPI and I2C interfaces, the selection of the mode is done during the boot of the Module.

No specific initialization procedure is required. Public Material – May be reproduced only in its original entirety (without revision).

No initialization procedures are required.

Rules of Operation

1. The Module provides two operator roles: the Cryptographic Officer and the User role. Each role is associated with a set of services as detailed in the services table.
2. The Module, evaluated at FIPS 140-3 Level 2, requires authentication to access some of the services as detailed in the services table.
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.
13. The Module does not support a self-initiated cryptographic output capability.
14. For all zeroization methods, the Module must be in direct control of the operator.

End-of-life of the product requires the following zeroization commands to be executed to remove all CSPs from the memory of the Module:

• TPM2_Init
• TPM2_Clear
• TPM2_ChangeEPS
• TPM2_ChangePPS Public Material
• May be reproduced only in its original entirety (without revision).

• TPM2_VendorCmdZeroizeEK
• TPM2_NV_UndefineSpace or TPM2_NV_UndefineSpaceSpecial Public Material
• May be reproduced only in its original entirety (without revision).

The Module does not implement any mitigation method against other attacks. Public Material – May be reproduced only in its original entirety (without revision).

References and Definitions The following standards are referred to in this Security Policy: Public Material – May be reproduced only in its original entirety (without revision).

Table 40

• References Public Material
• May be reproduced only in its original entirety (without revision).

Table 41

• Acronyms and Definitions Public Material
• May be reproduced only in its original entirety (without revision).