Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA

Certificate

Approved Algorithms (2)

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

flowchart LR
  %% Deterministic review-risk graph for Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA
  %% 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</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."]
  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?"]
  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"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  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 clue;
  class I2,I3 infer;
  class R2,R3 risk;
  class E2,E3 evidence;

flowchart LR
  %% Deterministic clue tier for Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA
  %% 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</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 clueLow;

Security Policy, page by page

Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy Thales Alenia Space Version: 1.7

• Quality review

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

The purpose of this document is to define the non-proprietary FIPS 140-3 Security Policy of the Thales will also be referred to as “TASE-CM-VIPER” throughout this document. This Security Policy specifies the security rules under which the cryptographic module should operate to

This cryptographic module has been developed by Thales Alenia Space and it has been implemented within the Ground Cryptographic Processor (GCP) placed on Earth and within the Volatiles Investigating Polar Exploration Rover (VIPER) transponder unit. The aim of this cryptographic module is to enable NASA to encrypt communications at the GCP, and decrypt and authenticate them at the transponder unit using AES-GCM. It is able to encrypt/decrypt and authenticate messages from 128 bytes to 1024 bytes of information in 128-bit blocks. Although the TASE-CM-VIPER is the same for the GCP and for the VIPER transponder and can encrypt and decrypt indistinctly, in a real use case, the information will be encrypted in the GCP which will transmit it to the VIPER transponder where it will be decrypted and authenticated. The following image shows the communication process between the GCP and the VIPER transponder: Figure 1: Communication process between the GCP and the VIPER transponder The FIPS 140-3 security levels for the module are as follows: PÁG 6/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

This Security Policy is a part of the FIPS 140-3 submission package. The submission package contains: - FIPS 140-3 Algorithm Certificates: see Section “2.2 Modes of Operation and Security Functions”. - FIPS 140-3 Functional Specification and Design Documentation: see Sections “2.1 Module Description and Cryptographic Boundary”, “3 Cryptographic Module Interfaces” and [TAS-FS] document. - FIPS 140-3 User Guide: see Section “11.3 Crypto Officer and User Guidance”. - FIPS 140-3 Finite State Model: see [TAS-FSM] document. - FIPS 140-3 Configuration Item List: see [TAS-CIL] document. PÁG 7/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

The TASE-CM-VIPER is a hardware module based on a Microsemi RTG4 FPGA which implements two Helion IP cores for supporting AES-GCM encryption/decryption within the environment of the VIPER mission. This cryptographic module is classified by FIPS 140-3 as multiple-chip embedded. In addition, the cryptographic module includes the telecommand (TC) and telemetry request (TMR) libraries necessary to control and monitor the cryptographic operations and communications between the GCP and the VIPER transponder.

The TASE-CM-VIPER is composed of an FPGA which provides all the necessary to operate and interconnect the Helion IP cores (AES-GCM IP cores) to perform cryptographic operations, and the EEPROM memory to store all the AES-GCM keys and their CRCs. The model of each component is specified in the table below: Table 2: Cryptographic Module Tested Configuration The Microsemi RTG4 FPGA is composed of the following main elements: - Two Helion IP cores for AES-GCM encryption/decryption and authentication. - Other functional logic (green block) not related to the cryptographic operations, because its components functionality does not affect the security of the module. Figure 2. TASE-CM-VIPER Hardware Cryptographic Module PÁG 8/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

Figure 3: Cryptographic Boundary of TASE-CM-VIPER depicts the cryptographic module block diagram specifying the cryptographic boundary for the TASE-CM-VIPER, showing all the input/output interfaces and the information flow described below: - The plaintext is entered through the data input interface (PDI) into the TASE-CM-VIPER and it is ciphered by the Helion IP core before being output from the module through the data output interface (CDO). - The ciphertext is entered into the TASE-CM-VIPER through the data input interfaces (CDI) and it is deciphered by the Helion IP core before being output from the module through the data output interface (PDO). - All AES-GCM keys are entered into the TASE-CM-VIPER through the data input interface KEYUART by the Crypto Officer and, once the module calculates their CRCs and verifies that they match with the received CRCs through the same interface, both the keys and their CRCs are stored into the EEPROM memory. - All the TCs and TMRs are entered into the TASE-CM-VIPER through the control input interfaces HKUART and KEYUART. Because for the encryption and decryption processes, the TCs associated with each operation (plaintext or ciphertext) are loaded through the PDI and CDI interfaces, these are also considered as control input interfaces. In addition, the cryptographic module implements a Reset pin used to perform the module reset operation, also considered as a control input interface. - Because communication is established between the GCP and the VIPER transponder and ciphertext TCs are exchanged between both modules, the interface CDO is considered as control output interface. - All the status output information related to the state of the cryptographic module is output from the TASE-CM-VIPER through the HKUART interface. The status output information related to the verification of each key CRC is output through the KEYUART interface. Moreover, the cryptographic module implements three indicators (Approved Service Indicator, Self-Test Indicator and Zeroization Indicator) to indicate the use of an approved security service, the successful completion of the self-test and zeroization services respectively, also considered as status output. - Because the TASE-CM-VIPER requires power from the external power supply to the cryptographic boundary, it implements the power input interface. - The frames are received through the CDI interface by the FPGA modulated, encoded and randomized by the RF system. The green block named “Other logic” is in charge of demodulating, decoding and derandomizing these input frames through the ADC interface to feed the cryptographic module through the CDI logical interface, which is used to enter the ciphertext to be deciphered into the TASE-CM-VIPER and consists of a data signal, a valid data signal and a frame completion signal that indicates when the complete frame has been finished. It is located into the same FPGA for power consumption purpose and all the functionality implemented by this block is operational with and without the cryptographic module. The information (green arrow) between this block and the UART I/F is because the HKUART interfaces allow configuring this block by using some TCs not related to the cryptographic operation of the module. PÁG 9/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

Figure 3: Cryptographic Boundary of TASE-CM-VIPER

The TASE-CM-VIPER can only operate in Approved mode. In this mode, the cryptographic module receives the input plaintext/ciphertext which is processed by the IP core and the resultant ciphertext/plaintext is output from the module through the data output interfaces. Therefore, in this configuration, the cryptographic module supports the Approved security feature detailed in the table below: Note: AES-ECB is tested as the underlying algorithm for GCM. It is not independently invokable. PÁG 10/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

The cryptographic module uses a 96-bit external deterministic IV for the AES-GCM operations. The IV consists of a 32-bit static field which contains a fixed value identifying the cryptographic module and a 64-bit dynamic field containing a deterministic non-repetitive counter. According to the [SP 800-38D] document, the maximum number of possible values for a given key of the deterministic non-repetitive counter is 232. When the counter part of the IV exhausts the maximum number of possible values for a given key, the cryptographic module will render this key unusable and will not accept any more frames with such key. The TASE-CM-VIPER is always operating in Approved mode; therefore, it does not support non-Approved mode nor degraded mode. In addition, it does not support non-Approved security functions nor vendor affirmed methods. This section specifies the critical security parameter used by the TASE-CM-VIPER to be able to perform the security function detailed in section above. Table 4: List of CSPs used by the module PÁG 11/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

The following table summarizes the mapping between the logical interfaces required by FIPS 140-3 and PÁG 12/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

Table 5: TASE-CM-VIPER Ports and Interfaces PÁG 14/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

When the module is performing self-tests or key zeroization processes, or is in an error state, all data output through the data output interfaces and all control output through the control output interface are inhibited. The inhibition of the data output and control output interfaces is performed in the source code by checking when the module enters in one of detailed states. In addition, the TASE-CM-VIPER does not require a maintenance interface because maintenance role is not supported. PÁG 15/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

The TASE-CM-VIPER supports the roles of User and Crypto Officer. It is important to note that the cryptographic module does not allow concurrent operators to operate at the same time, as it is programmed to operate in sequential execution. Table 6: Roles, Service Commands, Input and Output The TASE-CM-VIPER does not support maintenance role because it does not need logical or physical maintenance services. Moreover, the cryptographic module does not implement the bypass capability.

Once module installation has been performed successfully, each role (User and Crypto Officer) can use the services and keys detailed in the table below depending on its type of access by using a specified API TC/TMR. The access types to keys are denoted as follows: - G = Generate: The module generates or derives the SSP. PÁG 16/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

- R = Read: The SSP is read from the module. - 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 zeroizes the SSP. PÁG 17/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

Note: The approved indicator follows Scenario #2 Global Indicator for modules that have approved service only from Section “2.4.C Approved Security Service Indicator” of the [140IG] document. The service indicator is identifiable as a positive pulse on Pin 315. For the Authenticated Encryption service, the TASE-CM-VIPER requires the input of the TMR “Load Header Information” which contains the header of the frame and will output the associated TM to indicate if an error encryption has been occurred. If no error encryption has been occurred, the module requires the input of the TMR “Load Plaintext Data” which contains the plaintext information and will output the TM “Output Ciphertext Data” containing the ciphertext frame. Ciphertext Frame” which contains the ciphertext frame and will output the plaintext data information. PÁG 18/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

The TASE-CM-VIPER does not implement authentication mechanisms, therefore, an operator can select a role implicitly based on the service accessed by the module. PÁG 19/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

FIPS 140-3 Software/Firmware requirements are not applicable because the TASE-CM-VIPER is completely hardware and does not contain software or firmware components. PÁG 20/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

The TASE-CM-VIPER is a multiple-chip embedded cryptographic module which encompasses an FPGA and an EEPROM memory used to store the AES-GCM keys and their CRCs. Its operational environment corresponds with the cryptographic module hardware and is classified as non-modifiable operational environment. Since the cryptographic module is an FPGA that sequentially executes a single process, there are no concurrent operators. PÁG 21/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

The TASE-CM-VIPER consists of production grade components protected by polymer conformal coating as a standard passivation technique and it is classified by FIPS 140-3 as a multiple-chip embedded Moreover, the physical security is enhanced because in the case of the module placed in the VIPER transponder there is no possibility of having physical access to it. Regarding the GCP module, it is placed in a secure room in NASA facilities and it is always used and managed under the supervision of the CO. Figure 4: Top view of the TASE-CM-VIPER Figure 5: Bottom view of the TASE-CM-VIPER PÁG 22/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

FIPS 140-3 Non-invasive Security requirements are not applicable because the TASE-CM-VIPER is not designed to implement non-invasive attack mitigation techniques. PÁG 23/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

This section specifies the Sensitive Security Parameters used by the TASE-CM-VIPER to be able to perform the module approved security functions. The following table summarizes the Sensitive Security Parameters (SSPs) that are used by the cryptographic services implemented: Table 8: SSPs PÁG 24/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

The TASE-CM-VIPER does not support random bit generation.

The TASE-CM-VIPER does not implement SSP generation algorithms.

The TASE-CM-VIPER does not implement SSP establishment algorithms.

All keys used by the TASE-CM-VIPER to perform approved security functions (authenticated encryption and decryption operations) must be entered into the cryptographic module. The module is able to store up to 32 AES-GCM keys and their CRCs identifying them using a unique ID from 1 to

32. In order to perform the secure key entry, the CO is responsible of completing the following steps to comply with the FIPS 140-3 standard:
33. Firstly, the cryptographic keys are entered (via USB) into the PC (non-networked) used to load the keys into the module.
34. Secondly, the CO must plug the harness to the KEYUART interface prior to powering on the TASECM-VIPER.
35. Once the harness is connected, the CO must power on the cryptographic module.
36. After the cryptographic module is powered-up and the self-tests are passed completed successfully, the cryptographic module will detect that the harness is plugged and start with the key zeroization process.
37. When the key zeroization is completed, the key uploading process starts and the CO can upload up to 32 keys in total by using the scheme depicted in the image below and the following sequence of TC and TMR: a. TC “Load New Key” → This TC is used to load the new key into the TASE-CM-VIPER. b. Enter the new key generated externally in plaintext form via software using a PC. c. TMR “Key-Status” → This TMR is used to check the CRC of the last uploaded key. PÁG 25/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

Figure 6: Key Uploading Environment The upper limit is 32 keys, but the Crypto Officer can enter a lower number of keys into the TASE-CMVIPER. Regarding the SSPs output, the cryptographic module does not support SSP output operations, because it does not allow access to the keys from outside the cryptographic boundary.

Once the Crypto Officer has completed the key uploading process depicted above, the keys are stored in the EEPROM memory. Due to the inhospitable space conditions, the module has several methods to ensure the correctness of the stored keys. On the one hand, each key is stored with its own CRC, which will be used before an authenticated encryption/decryption process to guarantee the key validity. On the other hand, the key storage is performed using the Triple Modular Redundancy (TMR) methodology in order to protect the information against Single Event Effects (SEE) that can disrupt the keys and their CRC content. Therefore, the result is that each ID, key and CRC will be stored three times in one page of EEPROM memory. ·          ·          ·          ·            ·           ·        ·         ·           · ·          ·          ·          ·            ·           ·        ·         ·           · ·          ·          ·          ·            ·           ·        ·         ·           ·
0          0          0          0           0            0        0         0           0
0          0          0          0           0            0        0         0           0

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

·           ·          ·          ·           ·           ·          ·         ·          · ·           ·          ·          ·           ·           ·          ·         ·          · Table 9: Keys Storage in EEPROM memory When a key stored in the EEPROM is selected, the TASE-CM-VIPER applies majority voting system for each of its bytes using the three possible stored values. The CRC over this key is calculated and it is compared with the CRC stored in the EEPROM, applying again the majority voting system.

The key zeroization process will be performed automatically prior the key uploading process as it is specified in Section “9.4 Security Sensitive Parameter Entry and Output”. During this process, the TASECM-VIPER will only erase the 32 memory pages where the AES-GCM keys (AES_EDK) and their CRCs are stored because these are the only memory pages which contain keys and CSPs. During the key zeroization process, all data output interfaces are inhibited in order to prevent inadvertent disclosure of sensitive information as the plaintext cryptographic keys or CSPs. The cryptographic module indicates the successful completion of the zeroization process via the Zeroization Indicator (Pin 312). PÁG 27/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

Since the cryptographic module does not implement firmware/software component, the bypass capability nor critical functions, it does not perform pre-operational self-tests. Therefore, the cryptographic module directly performs the conditional self-tests. The TASE-CM-VIPER is a hardware cryptographic module based on an FPGA and does not contain software or firmware components as specified in Section “5 Software/Firmware Security”, so it is not necessary to implement the software/firmware loading test. In addition, the module does not generate cryptographic keys, does not allow the manual key entry, and does not implement bypass capability nor critical functions. Therefore, during the conditional self-test the TASE-CM-VIPER only performs the KAT (Known Answer Test) to verify the correct operation of the AES-GCM, performing the encryption/decryption and authentication of known information. In addition, the User can perform an on-demand conditional self-test by resetting the TASE-CM-VIPER. The KAT applies for the Approved algorithm detailed in the table below: The module will be in Operative state once the conditional self-test is passed successfully (status code of the module is set to 101) and if the harness for key uploading is not plugged. Until this moment, the outputs are inhibited to prevent inadvertent disclosure of the key components or CSPs, so the module cannot output any cryptographic data or perform cryptographic operations. Moreover, if the conditional self-test fails, the module will reach the error state, not allowing to perform any cryptographic operation and keeping all data and control outputs inhibited. After an error, the cryptographic module resumes normal operation by means of a reset (Pin 305). PÁG 28/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

The configuration management list is composed of configuration item version control, change control, flaw remediation tracking and source code review, which are managed by Thales Alenia Space in a private Git repository with write access restricted to authorized developers.

The internal versioning of the VHDL source code is performed by Git automatically and the assigned version and revision are used internally to control the code development, so that it must not be confused with the final released version of the VHDL that is appended manually to the name of the VHDL code file using the following format “release-XX_YY_ZZ”, where XX is the version number, YY is the revision number and ZZ is associated with bug fixing. Regarding each associated module documentation, they are manually versioned by appending the version and revision on their filename as follow: Document-X.Y. The assigned version number is stated as part of the file name with the following naming convention:

• Naming: Name-X.Y, where Name is the unique name of the related document, and X.Y are the version and revision of the document. Every new document is named with version v1.0.
• Version Update: When the document is modified and this modification implies major changes, the ‘X’ number must be changed. However, if changes and modifications imply minor changes, then the ‘Y’ number must be changed. The configuration item list can be consulted in [TAS-CIL] document.

When the module is powered on, it is initialized to operate in Approved mode, which is its only mode of operation, complying with the following rules:

1. The cryptographic module is initialized in Approved mode of operation automatically after the self-test are completed successfully.
2. The replacement or modification of the module by unauthorized users is prohibited.
3. During the operational lifetime of the module, it will never be shut down.
4. The cryptographic module does not need to implement pre-operational self-test.
5. Conditional self-test does not require any operator action to be executed.
6. Data output interfaces are inhibited during the key entry, conditional self-test, zeroization and error states.
7. Any input interface will ignore any incomplete incoming TC or TMR.
8. Status information does not contain CSPs or sensitive data.
9. Zeroization affects the 32 EEPROM memory pages which contain the possible 32 keys to be stored. PÁG 29/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

10. The cryptographic module does not support the maintenance interfaces or role. Moreover, the cryptographic module does not implement bypass capability.
11. The cryptographic module does not implement authentication mechanisms because it is not required for Security Level 1.
12. The cryptographic module does not support manual key entry.
13. The keys are entered into the TASE-CM-VIPER in plaintext form via software.
14. The cryptographic module does not output CSPs, secret or private keys from the module.
15. According to the [SP 800-38D] document, the maximum number of invocations for each key is 232.
16. There will be a human operator who will reset the IV to the last one used in case the module’s power is lost and then restored.
17. All keys are stored into an EEPROM memory with a unique identifier which allow the user to operate with them without having access to their content or value.
18. The Crypto Officer is the one in charge of performing the key zeroization and uploading of the new keys to be stored into the EEPROM memory.
19. If the TASE-CM-VIPER is in Error state, it will not be able to perform cryptographic operations. To resume normal operation mode, the cryptographic module must be reset.

The module is shipped only to NASA via certified courier service by Thales Alenia Space, and it is shipped in Thales boxes with Thales adhesive. Therefore, the recipient will be able to notice if it is tampered. In addition, it is not possible to modify the module, notwithstanding, once the module is installed, it is possible to verify that the module identifier and version are correct as it is detailed in Section “11.3.4 Installation and Initialization Instructions”.

The integrity and confidentiality of the cryptographic module is assured by following the secure distribution methodology specified in the previous section and verifying the module version and identifier after following the steps to initialize the module in a secure manner as is specified in the section below.

When NASA receives the cryptographic module, the Crypto Officer will be the one in charge of interconnecting and anchoring the support in the GCP and the VIPER transponder. Then, the module can be initiated in a secure manner by following the steps below: Step 1: Once the TASE-CM-VIPER is installed and interconnected in a secure manner, it does not contain any AES-GCM key to operate. Therefore, the first step is to proceed with the key entry into the cryptographic module. The Crypto Officer, that is responsible for the CSPs and keeping them into the module, must follow the steps described in Section “9.4 Security Sensitive Parameter Entry and Output” to insert up to 32 keys into the module and to store them into the EEPROM memory. Step 2: After the keys are entered and stored into the cryptographic module, the Crypto Officer must power off the TASE-CM-VIPER and unplug the harness from the KEYUART port. Step 3: Finally, it is necessary to verify the correct module version and identifier by using the TMRs “Show Module Version” and “Show Module Identifier”, detailed in the [TAS-FS] document, after powering on the PÁG 30/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

When the module has been configured and the AES-GCM keys stored in a secure manner by the Crypto Officer, the TASE-CM-VIPER can be powered on to be used by or User role by using the TCs and TMRs detailed in [TAS-FS] document and the procedures specified in “4 Roles, Services, and Authentication”. Once the self-tests are passed successfully, the data encryption and decryption operations can be performed without additional security measures, because the module is always operating in Approved mode. In addition, the module does not return any private secret, key component or CSP through the output data interface. PÁG 31/34

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

The TASE-CM-VIPER is not designed to mitigate other attacks which are outside of the scope of FIPS 140-

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26

Version: 1.7 Thales Alenia Space Cryptographic Module for Microsemi RTG4 FPGA Non-proprietary FIPS 140-3 Security Policy

Date: 2024/01/26