AN/KRC-6 (ATCS-BBU)

Certificate

Approved Algorithms (24)

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

flowchart LR
  %% Deterministic review-risk graph for AN/KRC-6 (ATCS-BBU)
  %% 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>Firmware Load<br/>Upgrade</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>self-test<br/>Status Output</i>"]
    C5["[low] Protocol / secure-channel<br/>references (may be KDF<br/>names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i>"]
    C6["[low] Operating system / runtime<br/>referenced (boundary<br/>membership not asserted)<br/><i>operating system<br/>kernel<br/>uboot</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 AN/KRC-6 (ATCS-BBU)
  %% 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>Firmware Load<br/>Upgrade</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"]
    C5["[low] Protocol / secure-channel references (may be KDF names, not a live channel)<br/><i>TLS<br/>SSH<br/>IPSEC</i><br/>src: text:keyword"]
    C6["[low] Operating system / runtime referenced (boundary membership not asserted)<br/><i>operating system<br/>kernel<br/>uboot</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

Ultra Intelligence & Communications. AN/KRC-6 (ATCS-BBU) Non-Proprietary FIPS 140-3 Cryptographic Module Security Policy Hardware Version: AN/KRC-6(v)1 Firmware Version: 1.1.1 Document Version 2.2 February 2025 Document prepared by www.lightshipsec.com AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. Contents AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. Tables AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. Figures Figure 1

• AN/KRC-6 (ATCS BBU) 6 Figure 2
• Module Block Diagram and Cryptographic Boundary 7 Figure 3
• Placement of tamper evident seals 20 Figure 4
• Placement of tamper evident seal 21 AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. This is the non-proprietary cryptographic module security policy for the AN/KRC-6 (ATCS-BBU) version 1 from Ultra Electronics TCS Inc., (operating as Ultra Intelligence & Communications), hereafter referred to as "Ultra". This security policy was prepared as part of the validation of the module. This policy describes how the Module meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-3, which details the U.S. and Canadian government requirements for cryptographic modules. More information about the standard is available from csrc.nist.gov/projects/cryptographic-module-validation-program This document also describes how to run the module in a secure Approved mode of operation. The Module has been validated at the FIPS 140-3 section levels shown in the table below. Table 1 – Security levels The Module has an overall security level of 2. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. 2. Cryptographic Module Specification The Base Band Unit (BBU) hereafter referred to as the "Module", is a multiband, point-to-point (PTP), point-tomultipoint (PMP) and Mesh radio system capable of providing at-the-halt communications across multiple echelons and on-the-move access capability. The system offers up to 400 Mbps throughput and operational flexibility. The Module operates as a component of the larger Amphibious Tactical Communications System (ATCS). The Module can also be referred to as the ATCS BBU. Each module can communicate wirelessly with other devices using up to two waveforms. Each waveform can be configured for the local RF channel frequencies, polarization and topology (LBH, NBH or UNW). The Module operates in VHF (RF band 3+) The Module offers encrypted digital communications over the TLS protocols, and management via SNMPv3 using HMAC-SHA-1 and AES-CFB-128. The Module can manage multiple VLANs. Each VLAN can be configured to be either encrypted or non-encrypted (see 4.7 Bypass Capability). The Module is classified as a hardware module with a multiple-chip standalone embodiment and is designed to operate within a non-modifiable operational environment.

The module's logical and physical boundaries are defined by the outer casing. This boundary encompasses the complete set of hardware and firmware components. Figure 1 – AN/KRC-6 (ATCS BBU) AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. The block diagram below illustrates the principle physical components of the module. Figure 2 – Module Block Diagram and Cryptographic Boundary The Module's firmware and operating system is executed primarily in the modem component. Secondary firmware related to the management of the physical ethernet ports is executed in the ethernet controller's independent CPU.

The Module was tested in the configuration listed below and was found to be compliant with FIPS 140-3 requirements. Table 2 – Hardware Tested Configuration

The last four digits of the Module's firmware version listed in the Tester Configurations table above, is the build number of the firmware that was tested by the CSTL. From time to time, Ultra may recompile the module to address non-security relevant bug fixes, vulnerabilities or upon client request. For builds that preserve the same version: 1.1.1, Ultra affirms continued compliance with the FIPS 140-3 standard, but these builds will not have been tested by the CSTL. A security relevant change would be reflected in the version of the module, for example: 1.1.2. Any firmware version of the module other than 1.1.1 is outside the scope of this security policy. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

The Module implements the following algorithms: Table 3 – Approved algorithms AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. AES-GCM is only used as part of TLS 1.2 GCM cipher suite. The module constructs the IV internally in compliance with IG C.H technique 1a. The IV is sourced entirely from the module's DRBG. The counter portion of the IV is set by the module within its cryptographic boundary. Per RFC 5246, when the nonce explicit part of the IV exhausts the maximum number of possible values for a given session key, the module will trigger a handshake to establish a new encryption key. No parts of the TLS v1.2/v1.3, and SNMP protocols, other than the KDF, have been tested by the CAVP or CMVP. KAS-ECC-SSC is only used in the context of a key agreement schemes. The module's use of KAS-ECC-SSC is compliant with FIPS 140-3 IG D.F.

The module does not implement any allowed algorithms, with or without security claimed.

The Module can only operate in the Approved mode. There are no Non-Approved Algorithms.

The Module supports one mode of operation: Approved. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. 3. Cryptographic Module Interfaces The following table lists the module's port and interfaces, both physical and logical. Table 4 – Ports and interfaces The Module acts as the manager of other hardware devices within the ATCS system. The module can issue control commands to the Dehydrator Unit (DU), the two Radio Frequency Units (RFU) and the Power Distribution Unit (PDU). However, none of these devices are classified as 'cryptographic modules'. Therefore, for the purposes of The physical enclosure of the Module includes the additional 'LAN3' and 'BBU-Link' ports. These ports exist for a future version of the Module. In this version, these ports are not provisioned and are non-functional. When the Module is performing self-tests, or is in an error state, the data output interface is disabled. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. The module's operations are managed by authorized users. Each user's account is assigned one of the following Referred to as the "Admin" role in Ultra documentation, users assigned this role are responsible for module configuration, which includes passwords, keys and certificates. The Crypto Officer has access to all services offered by the module. Detailed Crypto Officer responsibilities are described in section 11.1

• Administrator Guidance. Operator (OP) A user assigned the Operator role has access to general security services, including cryptographic operations and other approved security functions. Detailed Operator responsibilities are described in section 11.4
• Nonadministrator Guidance. Monitor (MON) A user assigned the Monitor role has read only access to all data, including non-security critical data. Neither the Operator nor Monitor roles have permission to load keys or perform user management activities.

The Module supports concurrent users. Up to 10 users may be logged concurrently. The memory and process management features of the operating system maintain separation of users and corresponding services. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. The Module supports role-based authentication using account names and passwords. Passwords are stored as keys using the Module's implementation of PBKDF with SHA2-256 as the PRF. The module uses an iteration count of 1,000. Table 6

• Roles and Authentication The Module's authentication mechanism has been designed to meet the following objectives:
• the probability shall be less than one in 1,000,000 that a random attempt will succeed, and
• during a one-minute period, the probability shall be less than one in 100,000 that a random attempt will succeed. Each user is authenticated using a password. Passwords must contain:
• at least 1 lowercase character (a to z)
• at least 1 uppercase character (A to Z)
• at least 1 numeral (0 to 9)
• at least 1 non-alphanumeric character (~!@#$%^&*_-+=`|\(){}[]:;"'<>,.?/) The Module requires that passwords be 16 to 30 characters long, drawn from the pool of 94 characters. The password strength is 1 in 1.52 x 1059. The Module also enforces the following:
• Passwords cannot be changed more than once in any 24-hour period.
• After their first login, users are required to change the default password assigned.
• After each failed login attempt, the Module imposes a 3 second timeout before another attempt can be made.
• After 3 unsuccessful login attempts, the user account is locked for 15 minutes.
• Passwords are valid for a maximum of 30 days. After which, users are prompted to change their passwords.
• The previous 5 passwords may not be reused.
• A user account that has been inactive for 35 days, is automatically disabled.
• After 10 minutes of inactivity, the Module requires the user to reauthenticate. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

The following table lists the approved services available to Module operators. Table 7 – Approved services AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. Note: The module operates exclusively in the approved mode using approved security functions. The use of an approved security function is indicated implicitly by the completion of the corresponding service. Access rights are indicated using the following notation:

• 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
• Zeroize: The module zeroizes the SSP.

The Module does not implement any non-approved services. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

The Module supports a bypass capability. Each of the two Waveforms supported by the Module can be linked to one of the VLANs managed by the Module. Each VLAN can be configured to be either encrypted or non-encrypted (bypass). The Module can simultaneously output data in either a cryptographically protected or non-protected form – on separate VLANs or waveforms. The bypass capability is enabled when the operator assigns a non-encrypted VLAN to a Waveform. A confirmation action will be required from the operator. Furthermore, a bypass alarm will remain active to inform the operator which waveform is set to accept an unencrypted VLAN, regardless of the administrative status of the Waveform. The exit-bypass condition occurs when the operator assigns encrypted VLANs to both Waveforms. The bypass capability is tested during the Module's boot sequence by the bypass self-test (see section 10.4). AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. 5. Software Security The module's firmware is comprised of two components: the bootloader and the firmware image. This latter component contains all firmware executed by the modem and ethernet controller. The integrity of both components is checked during the boot sequence by the module's bootloader. The following three tests are performed:

• The bootloader performs a known-answer test (KAT) of its SHA2-256 implementation.
• The bootloader checks the integrity of itself using SHA2-256.
• The bootloader checks the integrity of the firmware image using SHA2-256. Both hashes were created when the Module was compiled. They are stored in the Module and contained within the cryptographic boundary. A user can invoke the integrity test on-demand by rebooting the Module. If an integrity test fails, the Module will enter an error state, regardless of how the test was invoked (see section

The Module supports the upgrading of the firmware image component. Firmware upgrades can be performed by a user assigned the Operator or Crypto Officer role. Upgrades are performed through the GUI of the management laptop. Only firmware authenticated by Ultra can be loaded into the Module. See section 10.3 Firmware Load Test for a description of how the Module verifies the authenticity of firmware upgrades. If the module is unable to verify the authenticity of the firmware an error is raised (see 10.5 Error Handling). If the new firmware is determined to be authentic, the Module transfers the new firmware to non-volatile memory and invokes a reboot. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. 6. Operational Environment This section is not applicable. A cryptographic module that has a physical security rating above 1, has no operational environment requirements. The Module provides the following operational environments: Table 8 – Operational Environments. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. 7. Physical Security The module is enclosed in a production-grade weatherproof aluminum alloy case that is opaque to the visible spectrum, which defines the cryptographic boundary of the module. There are no openings (slits and/or holes) in the enclosure to give any visual or physical access to internal components. The module is classified as having a multi-chip standalone embodiment.

The module's enclosure is sealed using four (4) tamper evident seals, that prevent the enclosure from being opened without signs of tampering. The tamper evident seals shall be properly installed for the module to operate in the approved mode of operation. The part number for ordering tamper evident seals is 612-990311-402. 7.1.1. Storage Tamper evidence seals should be stored in a climate-controlled facility, that can maintain a maximum temperature of 90°F (32°C) and a relative humidity between 35% to 90%. Stored in this manner, the seals will remain viable for a minimum of 1 year. Cooler temperatures extend the shelf life. The Crypto Officer is responsible for securing and having control at all times of any unused tamper evident seals. 7.1.2. Application If the tamper evident seals have not been pre-applied by Ultra, the Crypto Officer is responsible for their application. The locations of the tamper evident seals are shown in Figure 3

• Placement of tamper evident seals. Figure 3
• Placement of tamper evident seals The Crypto Officer shall prepare to apply tamper evident seals as follows:
• The Crypto Officer shall wash their hands prior to application, to minimize contamination from body oils.
• The application is to be done in a clean environment.
• The surface temperature of the Module shall be between 35°F (2°C) and 90°F (32°C). AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications.

• The surface of the Module shall be cleaned using 90% isopropyl alcohol and a clean paper towel. A second paper towel shall be used to dry the surface. Do not allow the alcohol to air dry as contaminants may remain on the surface. It is critical that the application be performed in a manner that does not allow finger oils to transfer to the
• Peel back a portion of the liner (backer) to expose a portion of the adhesive side of the seal.
• Affix the exposed portion of the adhesive to the intended surface.
• Peel away the balance of the liner to fully affix the seal making sure that no bubbles or wrinkles are formed. It is not possible to reposition a seal once applied. The seal will indicate tampering. Seals shall be placed to cover two screws in each of the four corners of the module cover as shown in Figure 4. Seals do not need to contact the side panels of the module enclosure. Figure 4
• Placement of tamper evident seal 7.1.3. Verification The physical security of the Module shall be periodically verified per the table below: AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. 8. Non-invasive Security This section is not applicable. There are currently no approved non-invasive mitigation metrics defined at the time of writing. (Ref: ISO/IEC 19790:2012 Annex F) AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. 9. SSP Management The Module manages the SSPs, and keys listed in the following two tables. Table 10 – SSPs AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. A static ECDSA public/private key pair exists in the module firmware, but these keys are only used for testing the implementation of ECDSA. The module does not use these keys operationally. SSPs stored in volatile memory (RAM) are zeroized by powering down or rebooting the Module. SSPs stored in non-volatile memory (Flash) can be zeroized using either of the following two methods:

• invoking the zeroise command from the web interface, or
• holding the zeroisation push button for 30 seconds. Both methods will result in the zeroisation of all SSPs stored in the module, returning the Module to the factorystate. The zeroisation of SSPs stored in Flash memory involves reformatting the entire memory with zeroes. Upon completion of the zeroisation service, the Module automatically reboots which zeroizes SSPs stored in volatile memory. The Module does not overwrite an unprotected SSP with another. This approach ensures that sensitive data cannot be recovered. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

The Module does not implement any algorithms / keys that will transition from approved to non-approved before the validation expires. The Module's digital signature, block cipher, hashing and key establishment algorithms are compliant to the requirements of CNSA 1.0.

The following entropy sources are available to the module and have been tested to NIST SP800-90B. Table 11 – Non-Deterministic Random Number Generation Specification AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. 10. Self-tests The Module performs both pre-operational and conditional self-tests. Once invoked, the Module will perform no functions or services until the self-test(s) has been completed.

Pre-operational self-tests are performed automatically after the Module has been powered up. No action from the operator is required. In its pre-operational state, the Module performs the Cryptographic Algorithm Self-Test (CAST) that is required for the subsequent firmware integrity test. Once the integrity test has passed, the Module performs a suite of cryptographic algorithm tests pre-operationally. All tests must be passed for the Module to transition to an operational state. If any test fails, the Module transitions to an error state (see section 10.5 Error Handling). While the pre-operational self-tests are being performed, the data output interface is inhibited. The module performs the following pre-operational self-tests: Table 12 – Pre-operational self-tests While operating in the pre-operational state, the Module also performs its suite of cryptographic algorithm selftests (CASTs) and health checks for the DRBG's Generate / Instantiate / Reseed functions as specified in section

Pre-operational self-tests can be invoked on-demand by rebooting the module.

Conditional self-tests are performed by the Module during operation when specific conditions occur. The Module performs the following conditional self-tests: Table 13 – Conditional self-tests AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. Upon failure of the conditional bypass self-test, the module will transition to the soft error state. The failure of any other self-test will induce a transition to the hard error state. The Crypto Officer will be required to take the actions described in section 10.5 Error Handling. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Upon receiving a firmware upgrade request, the Module invokes its firmware load test. This test entails the Module computing the expected MAC of the new firmware image using HMAC-SHA2-256 and its embedded configuration integrity key. This MAC is compared to the MAC of the firmware image received. If the MACs match, the Module accepts the new firmware and copies it into the non-volatile memory.

Each Waveform can be connected to either an encrypted data path or a non-encrypted data path. The configuration of each Waveform is stored in a single configuration file for the entire module. Whenever the user makes any change to the configuration of the module, this file is updated and the module calculates a new message authentication code (MAC) of the entire configuration file, using HMAC-SHA2-256 and the configuration integrity key. The new configuration file MAC is stored in a non-volatile memory location. During the boot process, the module performs both a pre-operational bypass self-test and a conditional bypass self-test. The conditional test is performed first. This test involves calculating a MAC of the existing configuration file and comparing it to the previously calculated MAC. The bypass test fails if the MACs do not match. When this occurs, the module raises a configuration alarm and transitions into a soft error state where cryptographic and traffic operations are inhibited. The user must invoke the "Reset settings" service to clear the error condition. The pre-operational test involves assigning each Waveform to the non-encrypted data path followed by the encrypted data path. For each assignment, a test packet is sent through the module's transfer switch and hardware encryption engine. The module then checks the transmitted packet counts for each Waveform. If the counts are not what is expected, the test fails causing the Module to transition to the hard error state.

If the bypass self-test fails, the module enters the "soft error state". If any other self-test fails, the module enters the "hard error state". When the module enters any error state it automatically stops transmitting by shutting off the waveform interfaces. This is to ensure any data output via the data output interface is inhibited. The user can recover from the soft error state by invoking the "Reset settings" service (see section 10.4 Bypass self-test). To recover from a hard error state, the Module must be power cycled. In either case, an error message is logged in the module System Log. A service status is shown for the Crypto Officer through the WebGUI for review. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. 11. Life-cycle Assurance The following sections describe how to install, configure, operate and eventually dispose of the Module. Additional information and recommended replacement Modules can be found on Ultra's website or by contacting customer service at 514 855 6363.

The Crypto Officer is responsible for the initialization, configuration, and management of the Module. The Crypto Officer can receive the Module from the vendor via trusted delivery courier including but not limited to DHL, UPS, and FedEx. The Crypto Officer can also arrange for pick up directly from Ultra. Upon receipt of the Module, the Crypto Officer should check the package for any irregular tears or openings. Upon opening the package, the Crypto Officer should inspect the tamper-evident seals. If there is suspicion of tampering, the Crypto Officer shall contact Ultra immediately.

The Crypto Officer is responsible for the initialization of the module through the Web Interface. The Crypto Officer must login to the module using the default username "CryptoOfficer" and password "CryptoOfficer11!". Once first-time authentication has been completed, the Crypto Officer is forced to create a new password respecting the password restrictions enforced by the Module as defined in section 4.4 . The following steps are required to enable the secure operation of the Module:

• The Crypto Officer must change the default authentication password upon first-time login,
• The Crypto Officer must verify that the installed firmware version number is listed in the certificate. Only a CMVP validated version is allowed to be used.
• The Crypto Officer must rename the default "CryptoOfficer" username,
• The Crypto Officer may choose to add users with Operator or Monitor profiles (optional). The Operator profile is equivalent to the User role per FIPS definitions.
• The Crypto Officer must configure an encrypted VLAN by selecting the traffic encryption key length (128 or 256 bits) and entering the encryption key.
• The Crypto Officer may enable traffic authentication mode and enter the traffic authentication key (optional).
• The Crypto Officer must assign one of the two previously configured encrypted VLANs to the wireless interface. By default, the wireless interfaces are in bypass mode.
• The Crypto Officer must ensure that the module does not show any FIPS alarm.
• The Crypto Officer must enter the SNMP privacy and authentication passwords, if required by policy.
• The module is ready for configuration of non-security related parameters. For additional initialization guidance, please reference the "ATCS Technical Manual".

The Crypto Officer can configure and monitor the Module via the secure Web-based GUI. The Crypto Officer should check the System Status and System Logs frequently for errors. If the Module ceases to function normally, contact Ultra customer support. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

The Module's web-based interface and configuration options available to a user assigned the Operator or Monitor profile are a subset of the interface and configuration options available to the Crypto Officer. Refer to Section 11.1

• Administrator Guidance for details. The Operator has access to the same web-based interface and configuration options as the Crypto Officer, except for the following. The Operator cannot:
• Perform any user management action such as add or delete users,
• Change any other user's password,
• Add, modify, or delete any encryption keys,
• Enable, modify parameters, or disable SNMP,
• Enable, modify parameters, or disable NTP. The Monitor profile grants the user read-only access to non-security-related parameters within the Module.

The internal components of the Module cannot be replaced on the field. In case of hardware malfunction or defect, the Crypto Officer shall:

• zeroize the unit if possible, and
• send the Module to the maintenance facility for repair via a trusted delivery courier.

There are no known CVEs with this module.

The Module is expected to last for the duration of the validation certificate. If the validation certificate has expired and no new validated firmware upgrade has been made available, the Module is considered void and must no longer be used. The Crypto Officer must arrange for disposal of the module hardware in accordance with regulation: DFARS 252.245-7005 Reporting, Reutilization, and Disposal. https://www.acquisition.gov/dfars/part-252-solicitation-provisions-and-contract-clauses#DFARS_252.245-7004 AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. 12. Mitigation of Attacks The module does not claim mitigation of attacks. AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. Acronyms AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.

Ultra Intelligence & Communications. Document History AN/KRC-6 (ATCS-BBU) © 2025 Ultra Intelligence & Communications This document may be reproduced and distributed only in its entirety, without modification.