SC4000 Series Mesh Radio

Certificate

Approved Algorithms (19)

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

flowchart LR
  %% Deterministic review-risk graph for SC4000 Series Mesh Radio
  %% 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<br/>Update</i>"]
    C3["[low] Self-test / status surface<br/>(referenced in text)<br/><i>unauthenticated<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>"]
  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."]
  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?"]
  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"]
  end
  C2 --> I2 --> R2 --> E2
  C3 --> I3 --> R3 --> E3
  C5 --> I5 --> R5 --> E5
  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 clue;
  class I2,I3,I5 infer;
  class R2,R3,R5 risk;
  class E2,E3,E5 evidence;

flowchart LR
  %% Deterministic clue tier for SC4000 Series Mesh Radio
  %% 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<br/>Update</i><br/>src: text:keyword"]
    C3["[low] Self-test / status surface (referenced in text)<br/><i>unauthenticated<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"]
  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 clueLow;

Security Policy, page by page

Silvus Technologies, Inc. SC4000 Series Mesh Radio

1.0 – General Information

This document defines the Security Policy for the Silvus Technologies SC4000 Series Mesh Radio, hereafter denoted the Module.

Purpose and Use: The Module is used in a family of MIMO radios used to provide a wireless mesh network. Each radio can operate in a multitude of configurations that are accessed via simple web pages within the radio. Settings such as transmit power, frequency, channel bandwidth, link adaptation and range control can be accessed by simply using a web browser to log into any radio within the network. Module Type: Hardware Module Embodiment: Multi-chip Standalone Module Characteristics: None Cryptographic Boundary:

The physical form of the Module is depicted in Figures 2 through 15. The module is composed of the baseboard circuit board surrounded by an opaque enclosure that serves as an EMI shield, heat sink, and FIPS enclosure. The Module is a multi-chip standalone embodiment with a limited operational environment. The cryptographic boundary is the surface of the entire module. The high-level block diagram showing the interconnections with external devices is shown below in Figure 1:

Figure 1 Silvus Crypto Module Block Diagram showing the crypto boundary and I/O with peripherals. The top figure is the SC4200/SC4400 and the bottom is the SL4200/SM4200. Tested Operational Environment’s Physical Perimeter (TOEPP): SC4200

Figure 3 SC4200 showing the serial number label. Figure 2 SC4200 showing two tamper evident seals. Figure 4 SC4200 showing the battery input.

Figure 5 SC4200 showing the antenna, primary, auxiliary and PTT connectors. SC4400 Figure 6 SC4400 showing one tamper evident seal.

Figure 7 SC4400 showing the second tamper evident seal. Figure 8 SC4400 showing the serial number label.

Figure 9 SC4400 showing the antenna, primary, auxiliary and PTT connectors. SL4200 Figure 10 SL4200 showing the serial number label.

Figure 11 SL4200 showing the two tamper evident seals. Figure 12 SL4200 showing antenna and primary connector. SM4200

Figure 13 SM4200 showing the serial number label. Figure 14 SM4200 showing the two tamper evident seals.

Figure 15 SM4200 showing antenna and primary connector.

The Module needs to be loaded with firmware version 4.1.0.0 to be considered FIPS 140-3 compliant. Any other firmware would render the Module non-compliant.

Hardware Operating Environments: Table 1. Operating Environments – Hardware The Module is designated as a limited operational environment under the FIPS 140-3 definitions. The Module includes a firmware load service to support necessary updates. New firmware versions within the scope of this validation must be validated through the FIPS 140-3 CMVP. Any other firmware loaded into this module is out of the scope of this validation and

requires a separate FIPS 140-3 validation. Table 1 shows the configurations that have been tested.

Modes List and Description: Table

5. Modes of Operation Mode change instructions and status indicators : To operate in an Approved mode of operation the operator must perform the following steps. The module ships in a non-approved mode of operation.
6. Open the web interface and navigate to Security->Encryption tab.
7. A popup window will appear, confirming this choice. Upon saying “OK”: a. All CSPs will be zeroized or reset to default values. All existing users will be deleted and three new users “basic”, “advanced” and “admin” with their respective roles will be auto-created with the default password - “HelloWorld”. b. The module will be subsequently rebooted into the Approved mode of operation; however, the module will not be fully in FIPS Approved mode unless the CO logs in and sets the CSPs to non-default values and configures some settings. The GUI will now show all the CSPs and settings that need to be updated on a single page: i. Enable Password Complexity and set the minimum password length to be

ii. Set the login passwords for “basic”, “advanced” and “admin” to a new password that passes the following checks:

1. Has a length greater than or equal to 8 characters.
2. Has at least 1 lower case, 1 upper case, 1 special character and 1 number. iii. Enable RF Link Encryption and set the API-Key, RF-Auth-Key, and RFSK to non-default values and enable Encryption. The CO is required to input a previously unused RF-SK. iv. Disable the SSH and SNMP service, and enable API Logs v. Creates/Uploads a new TLS-Host-Priv, TLS-Host-Pub key pair. vi. At this point, the module is fully operational in Approved mode. The user may change the Radio Mode to the Network Mode (0) setting to bring the module to operational state. Once a module is in the Approved mode, the operator may put the module into the NonApproved mode of operation by performing the following steps.
3. Open the web interface and navigate to Security->Encryption tab.
4. Change the Approved mode to disable and click “Apply FIPS Mode”.
5. A popup window will appear, confirming this choice. Upon saying “OK”: a. All CSPs will be zeroized or reset to default values. All existing users will be deleted and three new users “basic”, “advanced” and “admin” with their respective roles will be auto-created with the default password - “HelloWorld”. The module will be subsequently rebooted into the Non-Approved mode of operation. The user may check the status of the Approved mode and the firmware version in the following ways: To confirm the FIPS firmware version and hardware model and part numbers, call the “build_information” API. The output should look like below: SC4400: { "board_type":"SC4044", "rfboard":"SN 2721 opt 21 range 2200~2500 4400~4940 ", "rfboard1":"SN 2726 opt 21 range 2200~2500 4400~4940 ", "digital_board":"SN 19112", "model":"SC4400 Rev B1", "build_date":"10-10-2019", "build_tag":"streamscape_v4.1.0.0", "phy_ts":"EX_1.12_0x6d8edf62d858be4a182dfac0bb54f497550af314_06-22-22, 11:02:10", "part_no":"SC4480E-235467-SBST", "entropy_version":"Silvus Clock Jitter Entropy Module v1.0"

} SM4200: { "board_type":"SC4022", "rfboard":"SN 55883 opt 5 range 2200~2500 ", "rfboard1":"","digital_board":"SN 55883", "model":"SM4200 Rev B2", "build_date":"03-18-2022", "build_tag":"streamscape_v4.1.0.0", "phy_ts":"EX_1.12_0x33c956f734fe41896f03308bac2c79557d63809f_06-22-22, 09:53:18", "part_no":"SM4210-235-SB", "entropy_version":"Silvus Clock Jitter Entropy Module v1.0"},"id":2,"jsonrpc":"2.0" } SC4200: { "board_type":"SC4022", "rfboard":"SN 2532 opt 21 range 2200~2500,4400~4940", "rfboard1":"", "digital_board":"SN 2916", "model":"SC4200 Rev B7", "build_date":"10-09-2019", "build_tag":"streamscape_v4.1.0.0", "phy_ts":"EX_1.12_0x33c956f734fe41896f03308bac2c79557d63809f_06-21-22, 19:18:38", "part_no":"SC4240EP-235467-BB", "entropy_version":"Silvus Clock Jitter Entropy Module v1.0"},"id":2,"jsonrpc":"2.0" } SL4200: { "board_type":"SC4022", "rfboard":"SN 52918 opt 5 range 2200~2500 ", "rfboard1":"", "digital_board":"SN 52918", "model":"SL4200 Rev C3", "build_date":"02-10-2021",

"build_tag":"streamscape_v4.1.0.0", "phy_ts":"EX_1.12_0x33c956f734fe41896f03308bac2c79557d63809f_06-22-22, 09:53:18", "part_no":"SL4210-235-SB", "entropy_version":"Silvus Clock Jitter Entropy Module v1.0" } The “model”, “part_no” and “build_tag” should match the corresponding fields in Table 1. This information is also present in the Build Info page on the Web GUI. The Approved mode status can be checked using the API “fips_ready” and “fips_mode” and the GUI indicator. The “fips_mode” api returns [“1”] and the “fips_ready” returns [“”] if the module is fully in FIPS approved mode. The GUI indicator will show a green color. If the Approved mode has been requested, but the FIPS initialization steps detailed above have not been completed, the “fips_mode” api returns [“1”] and the “fips_ready” returns a JSON array of the API that need changes, e.g. [“enc_rf_auth_key”] if the RF-Auth-Key is not set to a nonFactory value. The GUI indicator on the side panel will show an amber color. If the Approved mode is disabled, the “fips_mode” api returns [“0”]. The GUI indicator will show a red color. The module does not implement a degraded mode of operation.

Table

7. Vendor Affirmed Algorithms NOTE: Module does not support Non-Approved Algorithms Allowed in the Approved Mode of Operation; see Table 8 for “No security claimed” algorithms. Table
8. Non-Approved, Allowed Algorithms with No Security Claimed

Table 9. Non-Approved, Not Allowed Algorithms

Table 10. Security Function Implementations

Note: no parts of TLS v1.3 other than the approved cryptographic algorithms and the KDFs have been tested by CAVP and CMVP. AES-GCM IV Generation The module offers two AES GCM implementations: a) AES-GCM 256-bit used by TLS v1.3. b) AES-GCM 256-bit used by the RF Wireless Link service. TLS v1.3: For TLS 1.3, the module implements the TLS_AES_256_GCM_SHA384 cipher as defined in RFC 8446 Appendix B.4. It uses the context of Scenario 5 of IG C.H. The module implements, within its boundary, a 64-bit counter for IV generation. If the IV exhaustion condition is observed, which will trigger a session termination or a re-key due to session re-establishment. In the event the module’s power is lost and restored, all previous TLS 1.3 session state is lost, hence a re-key due to session re-establishment will automatically enforce the IV uniqueness requirements. There are two configuration options: a) AES-GCM 256-bit using keys generated by KAS-ECCSSC b) AES-GCM 256-bit using a static key (RF-SK). For both cases, the IV is 96-bit, with 32 bits fixed to the unique 32-bit serial number of the module, and 48-bits dedicated to a 48-bit counter starting from

0. This follows IG C.H Scenario
1. The remaining 16 bits are fixed. If IV exhaustion is detected, the module will shut down the wireless interface and require zeroization

and subsequent FIPS initialization as described in Section 2.5. During FIPS initialization, the CO is required by policy to input a previously unused static RF-SK. AES-GCM 256-bit using KAS-ECC-SSC: If this option is chosen, the module will implement 56Ar3 compliant KAS-ECC-SSC for key agreement. In the event the module power is lost and restored, the key agreement is restarted, resulting in a new key. AES-GCM 256-bit using Static Key: If this option is chosen, the CO will input the 256-bit key to be used. Every 5 minutes, the module will record the last 48-bit counter used over the previous 5 minutes into non-volatile storage. In the event the module power is lost and restored, the module will resume the counter from the last stored value, but it will add an increment to ensure the next IV will be unique as required by 38D Section 9.1.

Table

11. Entropy Sources Entropy Information: The Silvus Clock Jitter Entropy Module relies on small differences in CPU execution times (clock jitter) as an entropy source. It resides within the overall module and supplies entropy to seed the AES CTR DRBG described below. The module complies with Section 4 of the Public Use Document (https://csrc.nist.gov/CSRC/media/projects/cryptographicmodule-validation-program/documents/entropy/E25_PublicUse.pdf). RNG Information: The module uses the AES CTR DRBG seeded by the entropy source above as its RNG source. The RNG source is used for the following:
12. Generating the SSP Cookie-Key
13. ECDSA/ECDHE KeyGen

The module implements the below sections from SP800-133r2 compliant to CKG IG D.H for cryptographic key generation: Section 4: Using the Output of a Random Bit Generator.

Section 5.2: Key Pairs for Key Establishment For ECDSA and ECDHE keys. Section 6.1: Direct Generation of Symmetric Keys For SSP Cookie-Key. Section 6.2.1: Symmetric Keys Generated using a Key Agreement Scheme For KDA for TLS v1.3 and RF Wireless Link.

The module implements SP-800 56Ar3 compliant KAS-ECC-SSC for key agreement for TLS v1.3 and RF Wireless Link. It complies with FIPS 140-3 IG D.F, Scenario 2, Path (2), whereby KAS-ECC-SCC and KDA were CAVP tested. See Section 2.6 above. The module implements the TLS v1.3 cipher suite TLS_AES_256_GCM_SHA384, utilizing the AES-GCM portion for KTS.

The module uses the following industry standard protocols which use cryptography:

• TLS v1.3
• SNMP v1, v2, v3 (Only in the Non-Approved mode).
• WPA2 (No security claimed).
• SSHv2 (Only in the Non-Approved mode)

Upon power-on, and after the pre-operational self-tests are successfully concluded, the module automatically transitions to the operational state.

The module’s ports and associated logical interface categories are listed in Table

12. Table
13. Ports and Interfaces

The module LED has the following color/pattern mapping:

• Solid Red: Module powering up. If the module spends more than 2 minutes in this state, it is bricked and needs factory repair.
• Blinking Red: This may be caused by the following:
• When configured for the approved mode, this may indicate that the module needs further configuration to be fully in the approved mode (e.g. setting CSPs to non-default values). The user needs to check the FIPS indicator to verify this. If the module is already fully in the approved mode, this could indicate that the module is in FIPS error state.
• If the user has run the “Spectrum Scan” diagnostic, the LED will blink red until the spectrum scan has completed.
• On the SC4200, a rapidly blinking red for 1s indicates that the battery charge has fallen below 20% capacity.
• If the user has set the MPS to position “Z” and power cycled the module, the module will power up with LED solid red, and then blinking green as usual. Then the zeroization process begins. Once the zeroization is completed, the LED will blink red.
• Blinking Green: Module fully powered up, but not connected to any peer module over the RF link. When configured for FIPS approved mode, this indicates that the module is ready, and all services are up.

• Solid Green: Module fully powered up and connected to at least one peer module over the RF link. When configured for FIPS approved mode, this indicates that the module is ready, and all services are up.
• Rapidly Flashing Green: On SC4200 and SC4400, when the MPS position is changed, the LED will rapidly flash green until the action mapped to the new MPS position has been completed.

The control output for BDA and PTT will be turned off when in FIPS error state. Control output for USB and Ethernet will be left on to allow the user to check the web GUI and confirm that the module is in FIPS error state. This is required since the module only has an LED interface for status output.

The module supports role-based authentication with four distinct operator roles, Cryptographic separation of roles using a standard session-based architecture. Re-authentication is enforced when changing roles and is cleared upon power reset. The module supports concurrent operators but maintains the separation of roles for each. The CO may disable concurrent user sessions by configuring the setting “Disable Concurrent Sessions” on the “GUI Login Authentication” page. If this setting is On, at most one session is allowed per user. Before opening a new session, a user must close the existing session. Note that multiple users may still have concurrent sessions but only one of each. If this setting is Off, due to resource constraints, the module can support up to 500 concurrent TLS sessions. Table 14 lists the operator roles. The Module does not support a maintenance role. CO is the only role that has access to authentication data after being authenticated. Table 14. Roles

All services offered by the module and the corresponding SSP access is described in the table below. All services running in the Approved mode are approved services, hence it uses the global indicator (“fips_mode” and “fips_ready” described in Section 2.5) to indicate the mode. Every approved service below has its own indicator, either implicit, or a log message which includes the specific service name (e.g. API Call), the status (success/failure) and the timestamp. Note, for the sake of brevity, similar SSPs are sometimes collectively represented with an asterisk (*), e.g. DRBG-* represents DRBG-EI, DRBG-State and DRBG-Seed. Table 15A. Approved Services e E) e O) e E)

Note: CO=Admin Role, BU=Basic Role, AU=Advanced Role, MN=Mesh Node Role, I=Write, O=Read, E=Execute, G=Generate, Z=Zeroize Note that none of the above unauthenticated services allow any access to the SSPs other than zeroize, which will destroy them.

The non-approved mode of operation has the same services running as the approved mode. In addition, the Wireless Link Service allows the use of non-approved/non-allowed DES/ECB and AES/ECB for the encryption/decryption of RF-link packets. The module also allows the use of Table 15B. Non-Approved Services in Non-Approved Mode e E) e O) e E) e s

connection to peer modules.

The module firmware may be updated by navigating to the Web GUI -> Tools and Diagnostics > Firmware Upgrade page and uploading the Silvus provided firmware package. The module will first shut down all interfaces that allow data output before beginning this service. The module will then authenticate and validate the package, update the firmware and auto-power cycle. Once the module powers back up, it is executing the new firmware image. The firmware package has a manifest file and the actual firmware image. The firmware image is an encrypted binary blob containing the firmware files. The module performs two checks on the externally loaded firmware.: - HMAC-SHA-256 verification of the firmware file by comparing it to the checksum inside the manifest. If there is any error during firmware load, the module will run a self-test and upon success, will re-enable the interfaces and bring itself back online. These errors are logged, and the CO may download the log file to check the reason for the upgrade failure. If the self-test fails, the module will go into the FIPS error state. If the upgrade succeeds, the module will power cycle.

All services other than the RF Wireless Link service are user initiated. The RF Wireless Link service will automatically start outputting encrypted user data over the RF interface. This service is enabled when the module is configured into the FIPS Approved Mode. To enable this service, the following two independent actions are required. CO will first enable Encryption for the Wireless Link Service, the module will verify this and then the module will check if all other Approved mode requirements are completed before turning on the wireless interface. At this point, the module is fully in the Approved mode and will begin encrypting and decrypting data on the wireless interface. The FIPS status indicator being “green” confirms that the self-initiated cryptographic output service is currently enabled and working.

Authentication Response Password authentication with invalid passwords or HMAC signatures would be responded by “Invalid Authentication”. RF Link Encryption service will drop any KAS packets that are not correctly signed with the RF-Auth-Key

The module, upon power up will run a bootloader - U-Boot. U-Boot performs a CRC-32 verification of the firmware image before eventually handing control to the OS. If the firmware integrity test fails, U-Boot performs a CRC-32 check on a secondary copy of the firmware image. eventually handing control to the OS if the check passes. If this firmware also fails integrity checks, the module will not power up. The LED changes to red and the module is considered inoperable and will need factory repair.

Integrity checks are initiated on demand by power cycling the module.

Type of Operating Environment: Limited The cryptographic module includes the following physical security mechanisms:

• Production-grade components and production-grade opaque enclosure
• Two (2) tamper-evident seals applied during manufacturing, please see Figures 2 (SC4200), 6,7 (SC4400), 11 (SL4200), 14 (SM4200).

Tamper evident seals are applied at Manufacturing. Table 16. Mechanisms and Actions Required

Method API Zeroize

Description The zeroization is performed by the module overwriting zeroes to the memory location occupied by the SSP and further deallocating that area. The completion of API Zeroize will cause the module to auto power-cycle.

Rationale

Operator Initiation Capability

1. Zeroize over TLS on the Web GUI or by calling the API “zeroize”.
2. Zeroize by moving MPS to position “Z” and power- cycling the module.

The module stores non-ephemeral SSPs in a partition on a NAND chip. Ephemeral SSPs are stored in system memory (RAM). The module also has an e-fuse EEPROM to store the Secure boot SSP used for power-up firmware integrity testing. Note that this is not claimed for security. Table

17. Storage Areas Table
18. SSP Input-Output Methods The module does not support manual SSP entry or intermediate key generation output. Plaintext output of CSPs is only allowed over a secure channel (TLS v1.3). Table
19. SSP Zeroization Methods

Note, there is a configuration API (enc_key_volatile_disable”) available to the CO that when set to “0” would force the storage of certain SSPs in RAM instead of NAND. When the module power cycles, these SSPs would revert to their factory default values, hence requiring a FIPS re-configuration after every power cycle. The following are the affected SSPs:

1. RF-Auth-Key
2. API-Key
3. RF-SK By default, this API is set to “1” and these SSPs are stored in NAND.

Each time the Module is powered up, it tests that the cryptographic algorithms still operate correctly, and that sensitive data have not been damaged. Power up self–tests are available on demand by power cycling the module. On power up or reset, the Module performs the pre-operational self-tests described in Table 22 followed by the power-up conditional tests in Table 23 below without any operator action required. All data output via the data output interface is inhibited when an error state exists and during self-tests. All KATs must be completed successfully prior to any other use of cryptography by the Module. If any of the KATs fails, the Module enters a fatal error state. The web page will switch to using HTTP only vs. HTTP/TLS and will only display a single page showing more information about the error state, e.g., which KAT failed. The user may then reboot the module to resume operation. If all KATs are completed successfully, the module will enter a functional state. The user may navigate to the Web interface and look at the informational side-panel. The entry “FIPS Status” should show a Green-filled circle which indicates the module is in Approved mode. If it is Amber, it indicates that the module is in a transitional FIPS state and requires manual configuration by the CO to complete the transition. If it is Red, it indicates the module is in Non-Approved mode. The module will go to the same FIPS error state in case of errors during all non-power-up conditional tests except the firmware load test. If the firmware load test fails, the module will go into a temporary soft error state and run a self test. If the self test fails, the module will go into the FIPS error state. If it passes, the module will log the reason for the original failure and bring the module back into operable state. The CO may download the log file to find the reason for failure and/or retry. The module does not have any status output except for LEDs, so during the FIPS error state the Ethernet interface will still be up and will allow connecting to the HTTP error page. The following are the ways to power cycle the radio and run the power-up self-tests:

1. Authenticate as CO and Invoke the “Reset over TLS” service either through the GUI (Tools and Diagnostics -> Upgrade Firmware -> Reboot) or by calling the API “radio_reset”.
2. Invoke the unauthenticated reset service by toggling the MPS/Power Switch or calling the API “radio_reset” on HTTP port 50000 through a non-RF interface.

Table 22. Pre-Operational Self-Tests

module will power up and the LED will change from RED to GREEN. If the integrity test fails, the module will try a fallback image. If that fails too, the LED will stay RED, and the module will not power up (bricked).

will check the CRC- 32 checksum of the firmware image against the value stored in the firmware file header.

Table 23. Conditional Self-Tests Concerning the indicator, for all conditional tests with the power-up condition below, successful completion would cause the module to finish powering up, with the associated indicators for Approved/Non-Approved mode. A failure would put the module in FIPS error mode. Success will be given in the API log. Failure will result in a hard error state.

On demand self-tests can be invoked by powering cycling the module.

Initiation operations are listed in section 2.5 of this Security Policy.

The module is shipped ready to use in the FIPS Non-Approved mode. The CO needs to follow the instructions in Section 2.5 to configure the module into the FIPS Approved mode.

Please refer to Section 2.5 for the administrator guidance for configuring the module into the FIPS Approved mode.

Please refer to the Silvus User Manual for non-security related usage information.

The operator is required to use the “Zeroize over TLS” OR the “Zeroize” service to zeroize all the keys when the module reaches end of life.

No mitigation of other attacks is implemented by the module.