Atalla Cryptographic Subsystem (ACS)

Certificate

Approved Algorithms (7)

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

flowchart LR
  %% Deterministic review-risk graph for Atalla Cryptographic Subsystem (ACS)
  %% Review prompts and evidence gaps, NOT vulnerability findings.
  subgraph CMVP["CMVP-disclosed clues"]
    C2["[low] Firmware update / recovery<br/>/ rollback (referenced in<br/>text)<br/><i>update<br/>Firmware Load</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>Unauthenticated<br/>Self-test<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>HTTPS<br/>no library/version identified</i>"]
    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."]
    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 Atalla Cryptographic Subsystem (ACS)
  %% confidence: high = structured record field; medium = structured but soft; low (dashed) = bare keyword hit, context unverified
  subgraph CMVP["CMVP-disclosed clues (deterministic)"]
    C2["[low] Firmware update / recovery / rollback (referenced in text)<br/><i>update<br/>Firmware Load</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>Unauthenticated<br/>Self-test<br/>Status Output</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>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

Atalla Cryptographic Subsystem (ACS) Hardware Version: C9B60-2108A, C9B60-2108B and C9B60-2108C, C9B60-2108D, C9B60-2108E Firmware Version: Loader Version 1.24; PSMCU Version 1.0.1 or 1.0.3; CMS-OCT Version 0.95,1.0.0, or 1.0.3; CMS-NTX Version 1.0.0; Loader Stage 1 Version 1.10; Loader Stage 2 Version 1.20; Boot Version 1.23 FIPS 140-3 Document Version 1.78 May 13, 2025 © 2025 Utimaco Inc This document may be freely reproduced in its original entirety. i

Atalla Cryptographic Subsystem Contents © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. ii

Introduction The Atalla Cryptographic Subsystem (ACS), hereafter referred as ACS, is a secure cryptographic coprocessor designed for use in a variety of high security applications. This document specifies the ACS security rules, including the services offered by the cryptographic module, the roles supported, and all keys and CSPs employed by the module. The ACS module is designed to comply with FIPS 140-3 Level 3 Security requirements. Related Documents

© 2025 Utimaco Inc This document may be freely reproduced in its original entirety. 3

Atalla Cryptographic Subsystem Glossary Term Definition ACS Atalla Cryptographic Subsystem, also called Icarus Adapter AES Advanced Encryption Standard symmetric encryption algorithm that uses a 128-bit block and a key size of 128,

CBC Cipher Block Chaining

• A method of encrypting multiple blocks sequentially, by chaining the encrypted output from one block in as the IV to the next block, requiring each block to be processed in the same order in order to decrypt and get the clear data back. CCM Counter with CBC-MAC
• A method of encrypting data and providing an integrity check, using only one key CKG Cryptographic Key Generation CMS Control and Monitoring System, comprised of three separate microcontrollers (CMS-Cerberos, CMS-OCT, and CMS-Nitrox-LPT) that monitor the security perimeter and environmental conditions and keep the Internal Master File Keys. CPU Central Processing Unit, also called Processor CRC Cyclic Redundancy Check
• Used as a simple method of verifying code integrity. CSP Critical Security Parameter
• This is a term used to indicate any cryptographic key or data that is used in a cryptographic algorithm. DES Data Encryption Standard symmetric encryption algorithm that uses a 64-bit block and a key size of 56 bits, plus parity DMA Direct Memory Access
• Dedicated hardware that transfers data directly to or from memory across the PCIe BUS. DRAM Dynamic Random Access Memory, also referred to as DDR or just RAM
• data is not retained when power is not present. DRBG Deterministic Random Bit Generator, NIST Special Publication 800-90Arev1 ECB Electronic Code Book
• A method of encrypting each block of data independently of any others. Only that one encrypted block and the key are needed to decrypt the data. © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 4

Atalla Cryptographic Subsystem Term Definition EC or ECC Elliptic Curve Cryptography algorithm

• An asymmetric cryptographic algorithm used to define a point on a curve (public key) and an intersection point (private key) ECDSA Elliptic Curve Digital Signature algorithm
• EC algorithm used to create digital signatures ENT SP800-90B entropy source Flash Programmable read-only (nonvolatile) memory
• Used to store all code and data that is retained when powered off. IV Initialization Vector
• Used as input to a symmetric cryptographic operation MD Message Digest
• The resulting output from a hash algorithm operation NVRAM Nonvolatile RAM: General purpose memory maintained as nonvolatile Personality Secure software application running inside the secure boundary PSMCU Physical Security Monitoring Control Unit, refers collectively to all 3 of the microcontrollers that comprise the CMS, or specifically to the CMS-Cerberos microcontroller, which is the only interface via serial port from the Cavium Octeon processor. PSP Public Security Parameter RAM Random Access Memory: General purpose volatile memory RBG Random Bit Generator: A device or algorithm that outputs a random sequence that is effectively indistinguishable from statistically independent and unbiased bits. RSA Rivest Shamir Adelman algorithm
• An asymmetric cryptographic algorithm used to define a public-private keypair that can be used to create digital signatures. SHA Secure Hash Algorithm that uses 256, 384, or 512 bit sizes SSP Sensitive Security Parameter Triple-DES Triple Data Encryption Standard that uses three separate DES symmetric algorithm operations with different keys to increase the overall strength of the algorithm that can use 2 DES keys (112-bits) or 3 DES keys (168-bits) Table 1 Terms and Definitions © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 5

Atalla Cryptographic Subsystem Product Overview The ACS module is designed to comply with FIPS 140-3 overall Level 3 Security requirements. The ACS is a multi-chip embedded cryptographic module. It consists of a secure hardware platform, a firmware secure loader, and three separate microcontrollers, collectively called the Physical Security Monitoring Control Unit (or PSMCU) The purpose of the cryptographic module is to load Approved (RSA and ECDSA signed) application programs, called “personalities,” in a secure manner. The module is in an Approved mode of operation until a personality is loaded and started, at which point the module enters a non-compliant state. Verification that the module is in Approved mode can be observed by running the “getstatus” and “version” commands. This security policy addresses only the hardware and the firmware secure loader; the personality is not included in the current FIPS validation. But, the PCI-HSM version of the personality, as well as the Loader are included in the PCI-HSM validation. This approach creates a common secure platform with the ability to load trusted code (the personality). Once control passes from the loader to a personality, the module enters a non-compliant state. Note that the PSMCU is always running and no personality, no matter what its FIPS 140-3 validation level, will have access to the module’s secret keys and CSPs. © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 6

Atalla Cryptographic Subsystem The cryptographic boundary of the ACS for the FIPS 140-3 Level 3 validation is the outer perimeter of the secure metal enclosure that encompasses all critical security components. Table 3 Cryptographic Module Tested Configuration The hardware features of the ACS include: • Tamper penetration detection grid © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 7

Atalla Cryptographic Subsystem

• Tamper detection and response hardware
• AES cryptographic hardware
• Used by the loader for encryption algorithm
• Triple-DES cryptographic hardware
• Latent functionality unused and in default disabled state.
• MD-5 hardware
• Latent functionality unused and in default disabled state.
• SHA-1 cryptographic hardware
• Latent functionality unused and in default disabled state.
• SHA-256 cryptographic hardware - Latent functionality unused and in default disabled state.
• SHA-512 cryptographic hardware
• Used by loader for hash algorithm
• Hardware-based random number generator
• Used as entropy source for SP 800-90Arev1
• Large number math acceleration in hardware
• Used by both RSA and ECC algorithms.
• 16 CPU cores
• Only one core is used by the Loader, all others are held in reset. Note: All cryptographic support uses a combination of hardware algorithm and software to process the operations. In addition to the hardware cryptographic algorithms used by the module, Tamper Detection and Response hardware also monitors the penetration grid and environmental conditions. © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 8

Vendor Affirmed

CKG [SP 800- 133rev2]

Section 6.1

Cryptographic Key Generation; SP 800- 133rev2 and IG. D.H.

Symmetric Key Generation

Atalla Cryptographic Subsystem Table 4 Approved Algorithms Note: The module does not implement any non-approved algorithms allowed in the approved mode of operation, non-approved algorithms allowed in the approved mode of operation with no security claimed or non-approved algorithms not allowed in the approved mode of operation.

The cryptographic boundary of the module is the outer perimeter of the secure metal enclosure that encompasses all critical security components. The red line around the outer metallic enclosure, as shown in Figure below, represents the cryptographic boundary. Note: There is no visibly discernable difference between hardware versions other than the part number. Figure 1: Front and back side of the Atalla Cryptographic Subsystem © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 9

Atalla Cryptographic Subsystem 3. Cryptographic Module Interfaces

There are four physical data paths into and out of the ACS.

• LED (Qty. 64)
• used to provide continuous status of the module. The LEDs are physically mounted on the printed circuit board. There are 4 groups of 16 LEDs that are directly controlled by 4 different hardware components. The first is the PSMCU, which secures the top level cryptographic keys and provides the interface to the Octeon CPU core. The second and third are the CMS microcontrollers which control and monitor the various power supplies and environmental conditions. Finally, the Octeon CPU core running the Loader has the final 16 LEDs, of which 6 are externally visible along the back edge connector that can be seen from the rear of the unit. There are also two other LEDs visible on the rear edge connector, one from the PSMCU and one for the network link and activity for the RJ45 Ethernet port. The RJ45 Ethernet port is disabled and not used by the Loader and the RJ45 Activity LED is turned off. A diagram of the physical placement of the LEDs is shown in the figure below and a description of the LEDs is given in in the table below. © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 10

Atalla Cryptographic Subsystem Left Right NIC RJ45 Connector

14 12

1 9

10 9

11 8

1 2

3 16

14 12

12 10

4 9

5 1 2

14 12

1 2

Figure 2 Status LED Layout © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 11

Atalla Cryptographic Subsystem © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 12

Atalla Cryptographic Subsystem Table 5 Status LED Meanings © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 13

Atalla Cryptographic Subsystem

• RJ45 Ethernet (Qty. 1), compatible with 10/100 Base T IEEE 802.3.
• Not used by the loader and not in the scope of this document.
• Serial port. This is standard RS-232.
• PCIe. This interface is the primary interface used to send commands and data to, and receive status from, the ACS. In addition, this is the primary power connection to the ACS. The following table shows the relationships among the physical and logical ports: Table 6 Ports & Interfaces Note: No SSPs of any type are output from the module under any condition. The data which is output is of informational nature, such as version numbers, command return codes and error messages, etc.

Primary main system power is derived from the 3.3V pins on the PCIe connector. The supplies derived from the 3.3V pins are

• Nitrox 1.8V (PLL, VPH & VPTX)
• External printer interface (LPT)
• CMS main power
• Octeon PCIe 1.5V supply
• Octeon DDR4 memory supplies (2.5V, 1.2V and 0.6V) In addition to the power from the PCIe connector there is an additional power connector on the right side of the board. This connector provides 12V that is used solely to provide the CORE (0.9V) power for the Octeon through a step down regulator. Also, on the PCIe connector there is a 3.3Vaux supply pin that provides standby power to the two CMS chips as well as the PSMCU. This power is present whenever the HOST has power available regardless of whether it is turned on or not. Finally, there is a battery supply input that provides power to the PSMCU to maintain perimeter penetration detection and security keys when neither the 3.3V or 3.3Vaux power from the HOST is available. The power requirements are: © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 14

Atalla Cryptographic Subsystem

• 3.3V: 10 W
• 3.3Vaux: 250 mW
• Vbat: 100 mW
• 12V: 80 W (maximum)
• Total Power: 91 W 4. Roles, Services and Authentication

An unauthenticated role has access to services as specified in Table 9. These services fall under Exception “e” (show status, show version, and self-tests) or Additional Comment 5 (zeroization) from FIPS 140-3 IG 4.1.A. A Crypto Officer is responsible for the overall security of the module. Only an operator in the Crypto Officer role can load a personality into the ACS.

A User can perform a limited number of the services available on the module as indicated in the following section.

© 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 15

Atalla Cryptographic Subsystem Table 7 Roles, Service Commands, Input and Output

The ACS supports identity-based authentication of operators. The operator’s identity is represented by public key stored on behalf of the respective operator. Signing with the corresponding private key authenticates the operator. Note that the module is only able to store four operator identities – one capable of assuming the Crypto Officer (CO) and the other three capable of assuming the User role for one of the three different personality modes. The Crypto Officer role is far more security relevant than the User role from the FIPS perspective, so authentication for a Crypto Officer requires a significantly longer key. A Crypto Officer is required to be properly authenticated and its authentication mechanism is controlled by the PSK (private key) and PECSK (private key), which are used to sign personality images, and the LSK (private key) and LECSK (private key) (not SSP’s), which are used to sign the Loader firmware. A CO uses his knowledge of the PSK (private key) and PECSK (private key) to create signed personality images for download to the unit. Similarly, the CO uses his knowledge of the LSK (private © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 16

Atalla Cryptographic Subsystem key) and LECSK (private key) to create signed loader images. A 4096-bit RSA key and a P-521 ECDSA private key shall be used for the authentication process. A User is required to be properly authenticated and his authentication mechanism is controlled by the GSK (private key), which is used to sign the ‘go’ command for each of the three personality types. A User uses his knowledge of the GSK (private key) to sign either the ‘go’ command, the ‘go-pci’ command, or the ‘go-fips” command which allows the Loader to exit and start a personality of the same designated type. The User’s authentication key is a 2048-bit RSA key. Table 8 Roles and Authentication © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 17

following legend applies: 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. © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 18

Atalla Cryptographic Subsystem © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 19

Atalla Cryptographic Subsystem © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 20

Atalla Cryptographic Subsystem © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 21

Atalla Cryptographic Subsystem © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 22

Atalla Cryptographic Subsystem © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 23

Atalla Cryptographic Subsystem © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 24

Atalla Cryptographic Subsystem © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 25

personality in one of 3 different types (A PCI-HSM validated personality mode, a FIPS validated personality mode, and a mode for personalities that have not been PCI-HSM or FIPS validated). This service must be authenticated by an operator in the User role by verifying a signature of the “go” command for the specified personality type (i.e. go, go-pci, or go-fips), which must also match the type of the personality stored in flash. If the PSMCU active “type” value has not been selected (i.e. type = “General”), any of the 3 personality types can be loaded. If the PSMCU active “type” value has already been selected (i.e. type != “General”) by a previous personality load, then only that same type of personality can be

SigVer, KTS

an implicit indicator for the use of an approved service

Atalla Cryptographic Subsystem © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 26

loaded, without resetting the PSMCU “type” value. Once the PSMCU “type” value has been selected and the personality has been enrolled in an association, it will require the personality to be reset to factory state and then be server power- cycled or rebooted. If the personality is loaded and not enrolled into an association yet, it will automatically reset the “type” to “General” on the next power cycle or reboot.

Atalla Cryptographic Subsystem Table 9 Approved Services Note: The services that correspond to the “Perform self-tests” mandatory service include RSA Signature Test, ECDSA Signature Test, SHA Test, AES Test, RBG Test, DRBG Test, Entropy Test, CCM Test, and CRC Test. The self-tests can also be invoked on-demand by power cycling the module. Note: All services that specify an approved security function correspond to the “Perform approved security functions” mandatory service. The module does not support any Non-Approved services. 5. Software/Firmware Security The integrity of the module’s executable firmware is verified using CRC-32 (EDC), a 64-bit EDC, and approved integrity techniques for the following firmware components:

• CRC-32 - Loader Stage 1, Loader Stage 2, and Boot
• 64-bit EDC
• PSMCU, CMS-OCT, CMS-NTX © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 27

Atalla Cryptographic Subsystem • RSA SigVer (FIPS 186-4) (Cert. #A2606) using 4096-bit modulus with PKCS #1.5 padding and SHA2-512, ECDSA SigVer (FIPS 186-4) (Cert. #A2606) using P-521 and SHA2-512 – Loader The firmware integrity tests can be invoked on-demand by power-cycling the module. The required CASTs are executed for the RSA and ECDSA approved integrity techniques prior to the execution of the firmware integrity test. Please refer to Section 2.10 of this document for more information.

6. Operational Environment Not Applicable. The module has a limited operational environment and is validated with Physical Security Level
7. The embodiment of the ACS is of a multi-chip embedded module. The Physical Security and Security Control Unit (PSMCU) within the ACS continually monitors the physical security of the module for attempts to physically penetrate the cryptographic boundary. Depending on states of (PSMCU) two major events are generated within the secured boundary of the
8. A "reset event" is one that forces the module to become temporarily inoperable. This is a noncatastrophic event. When the conditions that cause the "reset event" are removed the unit will operate.
9. A "tamper event" is one that forces the module to become permanently disabled. This is a catastrophic event. In the disabled state all critical security parameters are erased and the module can only provide status information to users. Any physical penetration results in a “tamper event”. This event causes active zeroization of all cleartext CSPs. The following table specifies the required actions required by the operator to ensure the physical © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 28

Atalla Cryptographic Subsystem Table 10 Physical Security Inspection Guidelines In addition to physical penetration monitoring, the module supports Environment Failure Protection Table 11 EFP/EFT The following table specifies the temperature range that the hardness of the module’s enclosure was tested at. Table 12 Hardness Testing Temperature Ranges

For FIPS 140-3 validation the EFP/EFT functionality was tested in order to meet the Security Level 3 requirements. © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 29

Atalla Cryptographic Subsystem Events are signals that are generated by hardware circuits that monitor the physical environment. There are no actions required by the operator to enable the monitoring of the physical environment. There is no method for the operator to disable the monitoring of the physical environment. When events have occurred, the unit becomes non-operational either by going into the permanent ALARM state or the temporary RESET state. The detected events are:

• Physical penetration - the secure boundary has been penetrated or otherwise broken. This event shall happen also by grid, switch, and signal level detection mechanisms.
• Battery low - the battery output voltage that powers the physical detectors and maintains Critical Security Parameters falls below or increases above of the normal operating voltage established for this circuitry.
• Voltage out of limits - the host system voltage is outside of the normal operating range.
• Thermal out of limits 1 - the module temperature is outside of the normal operating range while operating on external power.
• Thermal out of limits 2
• the module temperature is outside operational limits of components while operating on battery power only.
• Card removal detection event
• the ACS is removed from the host. This event is not catastrophic but rather warning event. The module is up and running but not functioning (in suspend mode) and requires the “resume” command from the authorized personnel, which will reset the flag. © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 30

8. Non-invasive Security This section is not applicable due to no requirements currently being defined in SP 800-140F.
9. Sensitive Security Parameters Management The following table specifies the SSPs utilized by the module. The module supports the zeroization of all SSPs. r ) © 2025 Utimaco Inc This document may be freely reproduced in its original entirety. 31

Atalla Cryptographic Subsystem r d r d) © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 32

Atalla Cryptographic Subsystem Table 13 SSPs The following table specifies the module’s only entropy source, which is internal to the module’s cryptographic boundary. Table 14 Non-Deterministic Random Number Generation Specification © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 33

Atalla Cryptographic Subsystem 10.Self-Tests The following self-tests are performed automatically by the module without requiring operator intervention.

1. Pre-operational self-tests a. Pre-operational software/firmware integrity test: i. Firmware Integrity Test: The integrity of the Loader is verified at startup by checking a 4096-bit RSA signature and ECDSA P-521 signature.Stage 1, Stage 2, and Boot are verified by CRC-32. PSMCU, CMS-OCT, and CMS-NTX are verified by a 64-bit EDC. All must be verified successfully to continue b. Pre-operational critical functions test: i. Memory: Done during DDR RAM initialization ii. Key Integrity Check: All Loader keys are stored encrypted using CCM. The key CCM MAC is used to verify integrity before these keys are used. All PSMCU CSPs are stored within the PSMCU in cleartext form use leftmost 16-bytes of SHA-512 hash as the check digits. The check digits are used to verify integrity before these keys are used.
2. Conditional self-tests a. Conditional cryptographic algorithm test i. SHA2-512 hash - Known answer test ii. AES-ECB 256-bit Encrypt – Known answer test (ECB is only used for self-tests) iii. AES-ECB 256-bit Decrypt – Known answer test (ECB is only used for self-tests) iv. AES-CBC 256-bit Encrypt – Known answer test v. AES-CBC 256-bit Decrypt – Known answer test vi. RSA SigVer (FIPS 186-4) 4096-bit modulus with SHA2-512 - Known answer test vii. ECDSA SigVer (FIPS 186-4) P-521 with SHA2-512 - Known answer test viii. SP800-90Arev1 Counter DRBG (instantiate/generate/reseed) – Known answer test ix. SP800-90B ENT (P) Self-Test- 4096 entropy samples generated with continuous health-tests (APT and RCT) enabled. x. AES -CCM 256-bit Encrypt – Known Answer Test xi. AES -CCM 256-bit Decrypt – Known Answer Test xii. Continuous SP800-90B ENT (P) Health Tests (APT and RCT). xiii. Continuous SP800-90Arev1 DRBG periodic self-tests (Instantiate/Generate/Reseed). b. Conditional software/firmware load test: i. Firmware Load Test: This is a series of tests used to validate the integrity of the Loader firmware or personality when loaded into the module. These tests include CCM for secure and authenticated key transport, Signature test (RSA 4096-bit modulus and ECDSA P-521 curve both with SHA-512), AES-256 file decryption, and CRC-32 for simple integrity check. © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 34

Atalla Cryptographic Subsystem c. Conditional critical functions test: i. “go” command personality start validation: The “go” command is authenticated using a 2048-bit signature. Following this, the personality integrity is validated with CRC-32, then decrypted using AES-256, then validated again by verifying its signatures (RSA 4096-bit modulus and ECDSA P-521 curve both with SHA-512), prior to passing control to it. Failure of any of the above tests results in an error state. Recovery from the error state requires power cycling. When an error state occurs, cryptographic operations (like “go”, personality load, etc.) are disabled until the error state has been rectified. Since the module is only powered-on for short periods of time (30-60 seconds to start a personality, 3-

4 minutes to update flash) self-tests are periodically performed by nature of the design (i.e. power-on

self-tests, conditional self-tests, and signature tests on every start of the card). The only time the loader remains active for more than a couple minutes is if the ACS card has tampered or entered test state, in which case it is prevented from doing any cryptographic or security-related operations, permanently, so there is no need for periodic self-tests, in this case. In addition to the automatic self-tests, the module supports cryptographic algorithm self-test services (<algorithm> Test). These services allow the user to request on-demand invocation of any specific test. Additionally, the user can invoke all of the self-tests on demand by power-cycling the module. 11.Life-cycle Assurance The module is always in an Approved mode of operation until a personality is loaded and started, at which point the module enters a non-compliant state. The ACS loads and generates its initial keys randomly in manufacturing in the factory, during the process of entering into secure state. Once secure state has been entered, the physical security monitoring of external penetration, and voltage/thermal operating conditions are continuously maintained by the PSMCU, which is battery and system powered. The monitoring is maintained for the entire ACS life cycle. During normal operational use of the cryptographic operations, any failed startup test or self-test will enter a state that does not allow any cryptographic operations to be completed without cycling the power to the ACS. If an event is detected that results in the ACS security boundary being compromised, all keys are erased immediately and the ACS enters Tampered State, which renders the device cryptographic operations unusable, ending the ACS life cycle. There is no means to recover from this state, without irreversible damage. HSM lifecycle is documented and located within the HSM security directory and available upon request. 12.Mitigation of Other Attacks The module does not implement any additional attack mitigation techniques. © 2025 Utimaco Inc. This document may be freely reproduced in its original entirety. 35