| Standard | FIPS 140-3 |
|---|---|
| Overall level | 2 |
| Module type | Hardware |
| Embodiment | Multi-Chip Stand Alone |
| Status | Active |
| Sunset date | 1/5/2027 |
| Caveat | Interim validation. When operated in approved mode. |
| Vendor | Silvus Technologies, Inc. |
| Algorithm | ACVP Cert |
|---|---|
| AES-CTR | A3422 |
| AES-ECB | A3420 |
| AES-ECB | A3421 |
| AES-GCM | A3420 |
| AES-GCM | A3421 |
| AES-GCM | A3422 |
| Counter DRBG | A3422 |
| ECDSA KeyGen (FIPS186-4) | A3422 |
| ECDSA KeyVer (FIPS186-4) | A3422 |
| ECDSA SigGen (FIPS186-4) | A3422 |
| ECDSA SigVer (FIPS186-4) | A3422 |
| HMAC-SHA2-256 | A3422 |
| HMAC-SHA2-384 | A3422 |
| KAS-ECC-SSC Sp800-56Ar3 | A3422 |
| KDA HKDF Sp800-56Cr1 | A3422 |
| KDA OneStep Sp800-56Cr1 | A3422 |
| SHA2-256 | A3422 |
| SHA2-384 | A3422 |
| SHA3-256 | A3225 |
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;Silvus Technologies, Inc. SC4000 Series Mesh Radio
| # | Section | Page |
|---|
This document defines the Security Policy for the Silvus Technologies SC4000 Series Mesh Radio, hereafter denoted the Module.
ISO/IEC 24759 Section 6. FIPS 140-3 Section Title Security Level
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
requires a separate FIPS 140-3 validation. Table 1 shows the configurations that have been tested.
Modes List and Description: Table
ii. Set the login passwords for “basic”, “advanced” and “admin” to a new password that passes the following checks:
} 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. Degraded Mode Description: The module does not implement a degraded mode of operation.
Table 6. Approved Algorithms CAVP Algorithm Mode/Method Description/Key Use/Function Cert and Size(s)/Key Standard Strength(s) SL4200 & SM4200 Only A3420 AES ECB Encrypt 256 bits Encrypt SP 80038A A3420 AES GCM Encrypt, 256 bits Encrypt/Decrypt SP 800- Decrypt 38D SC4200 & SC4400 Only A3421 AES ECB Encrypt 256 bits Encrypt SP 80038A A3421 AES GCM Encrypt, 256 bits Encrypt/Decrypt SP 800- Decrypt 38D All Models
A3422 AES CTR Encrypt, 256 bits Encrypt/Decrypt SP 800- Decrypt 38A A3422 AES GCM Encrypt, 256 bits Encrypt/Decrypt SP 800- Decrypt 38D A3422 DRBG CTR with DF AES-256 Deterministic Random SP 800- Number Generation 90Ar1 A3422 ECDSA KeyGen P-256, P-384, P- KeyGen for KAS-ECCFIPS 186-4 521 SSC A3422 ECDSA KeyVer P-256, P-384, P- KeyVer for KAS-ECCFIPS 186-4 521 SSC for RF link only. A3422 ECDSA SigGen P-256, P-384, P- SigGen for TLS v1.3 FIPS 186-4 521 with SHAA3422 ECDSA SigVer P-256, P-384, P- SigVer for TLS v1.3 and FIPS 186-4 521 with SHA- Firmware Load Test. 384. P-521 with SHA-256. E25 ENT(NP) N/A 512 bits from Used to seed SP 800SP 800- entropy source. 90A DRBG. Entropy 90B Full entropy. source provides 1 bit of entropy per bit output. Entropy source provides at least 256 bits of security. A3422 HMAC HMAC-SHA2-256, Key size: 256-bit Message Authentication, FIPS 198-1 HMAC-SHA2-384 KDF Primitive. A3422 KAS-ECC- Ephemeral Unified P-256, P-384, P- Key agreement for TLS SSC 56Ar3 Responder/Initiator 521 and RF Link. Key establishment methodology provides between 128 and 256 bits of encryption strength. A3422 KDA One Fixed Info: SHA2-256 Key derivation after KASStep SP- uPartyInfo || ECC-SSC for RF link.
A3422 KDA Fixed Info: HMAC SHA2-256 TLS v1.3 HKDF uPartyInfo || 56Cr1 vPartyInfo, A3422 KTS AES-GCM 256-bit Key Wrapping / SP 800- Unwrapping 38F A3422 SHS SHA2-256, SHA2- N/A Message Digest FIPS 180-4 384 Generation, Password Obfuscation. A3225 SHS SHA3-256 N/A Vetted conditioner FIPS 202
Table
FIPS 140-3 requirements. The algorithm does not access or share CSPs used during an approved service. The SHS algorithm is not intended to be used as a security function as the module already satisfies the firmware integrity test requirements using 32-bit CRC. The use of this algorithm is unambiguous and cannot be easily confused for a security function. AES [2363] No security claimed For AES-CBC 256-bit firmware decryption by Secure boot. Validated by chip manufacturer but not on this OE. The AES algorithm is not used whatsoever to meet FIPS 140-3 requirements. The algorithm does not access or share CSPs used during an approved service. The AES algorithm is not intended to be used as a security function, FIPS 140-3 does not require encrypted firmware at rest. As such, the firmware is being treated as plaintext and the module already satisfies the firmware integrity test requirements using 32-bit CRC. The use of this algorithm is unambiguous and cannot be easily confused for a security function. HMAC [1465] No security claimed For HMAC-SHA-256 firmware authentication by Secure boot. Validated by chip manufacturer but not on this OE. The HMAC algorithm is not used whatsoever to meet FIPS 140-3 requirements. The algorithm does not access or share CSPs used during an approved service. The HMAC algorithm is not intended to be used as a security function as the module already satisfies the firmware integrity test requirements using 32-bit CRC. The use of this algorithm is unambiguous and cannot be easily confused for a security function. Table 9. Non-Approved, Not Allowed Algorithms Algorithm Use/Function DES-ECB DES block encryption of RF data packets in the non-Approved mode. Also used for SNMP in non-Approved mode. AES-ECB AES block encryption of RF data packets in the non-Approved mode. MD5 Used for SNMP in non-Approved mode. SNMP KDF Used for SNMP in non-Approved mode. SSH KAS - ECDHE P-521 SSH key agreement. SSH KDF
Table 10. Security Function Implementations Name Type Description SF Algorithms Algorithm Properties Properties KAS SSC (TLS) KAS SSP Provides KAS-SSC P-256 Establishment between [A3422] P-384 for TLS 128 and P-521
encryption strength. KAS SSC (RF) KAS SSP Provides KAS-SSC P-521 Establishment 256 bits of [A3422] for RF Link encryption strength. KTS KTS TLS Key Provides AES-GCM 256-bit Transport 256 bits of [A3422] encryption strength.
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. RF Wireless Link: 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
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
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:
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
Physical Port Logical Interface Data that passes over the port/interface SC4200 Battery (Qty
RF (Qty.
LED (Qty.
With USB-Serial adapter or GPS: User data encapsulated as RS232 serial data. With USB-Storage: Silvus signed license files to perform unauthenticated zeroize. USB 2 - OTG (Qty 1): Data Operates like USB1 in Host I/O, Control Input. Mode. With USB-RNDIS Host and USB 2 in Client Mode: User data and module configuration encapsulated as IEEE 802.3 Ethernet frames. In this mode, the module will not do power output (VBUS). USB-PD (Qty 1): Power N/A Input, Control Input. DC Power Input (Qty 1). N/A LED (Qty.
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.
Table 13. Authentication Methods Name Description Mechanism Strength Each Strength Per Attempt Minute Password Passwords are SHA-384 hash 62 different Three login minimum 8 verification. values per attempts in a alphanumeric character. minute are characters (a-z, Probability of allowed before A-Z, 0-9). guessing the the module locks password in a out the user for single attempt is 1 minute, so the 1/(62^8). strength per minute is 3/(62^8). Cookie Cookies are HMAC-SHA-384 1/(2^256) Due to CPU authenticated hash verification. limitations, the using HMAC- module can SHA-384 with perform 20 the 256-bit authentications Cookie-Key. per second, or
So the strength per minute is 1200/(2^256).
API Key The API is HMAC-SHA-256 1/(2^256) Due to CPU authenticated hash verification. limitations, the using HMAC- module can SHA-256 with perform 20 the 256-bit API- authentications Key. per second, or
So the strength per minute is 1200/(2^256). RF Link The KAS HMAC-SHA-256 1/(2^256) Due to CPU messages are hash verification. limitations, the authenticated module can using HMAC- perform 20 SHA-256 with authentications the 256-bit RF- per second, or Auth-Key. 1200 per minute. So, the strength per minute is 1200/(2^256).
The module supports role-based authentication with four distinct operator roles, Cryptographic Officer (Admin), Advanced, Basic and Mesh Node. The cryptographic module enforces the 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 Name Type Operator Type Authentication Methods Basic Role Owner Password, Cookie, API Key Advanced Role Owner Password, Cookie, API Key Admin Role CO Password, Cookie, API Key Mesh Node Role Other RF Link
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 Name Description Indicato Input Output Security Function Roles Roles SSP r Implementation Access Configure Advanced non- API/ API/Web KAS SSC (TLS), Advance Cookie-Key, APIAdvanced security relevant Web Respons KTS d, Admin Key, DRBG-*, Settings over configuration Input e Passwords-*, Log TLS TLS-Host-Priv, messag TLS-Host-Pub e (AU, CO-E) Rest of TLS-* (AU, CO-G, E) Configure Basic non-security API/ API/Web KAS SSC (TLS), Basic, Cookie-Key, APIBasic relevant configuration Web Respons KTS Advance Key, DRBG-*, Settings over Input e d, Admin Passwords-*, TLS Log TLS-Host-Priv, messag TLS-Host-Pub e (BU, AU, CO-E) Rest of TLS-* (BU, AU, CO-G, E) Configure Security relevant API/ API/Web KAS SSC (TLS), Admin Cookie-Key, Security configuration, Web Respons KTS DRBG-* (CO-E) Settings over including uploading Input e API-Key (CO-E, TLS license and settings I, G, O) files, and factory Passwords-* reset. (CO-I, E) Log TLS-Host-Priv, messag TLS-Host-Pub e (CO-G, I, E, O) Rest of TLS-* (CO-G, E) RF-Auth-Key, RF-SK (CO-G, I, O) Diagnostics Initiation of Serial Comman None Basic, Log Over Serial diagnostics like ping, Shell d Advance Passwords-* messag tcpdump, iperf, etc. Com Respons d, Admin (AU, CO, BU-E) e mand e Diagnostics Initiation of API/ API/Web KAS SSC (TLS), Basic, Cookie-Key, APIover TLS diagnostics like iperf, Web Respons KTS Advance Key, DRBG-*, etc. Input e d, Admin Passwords-*, Log TLS-Host-Priv, messag TLS-Host-Pub e (BU, AU, CO-E) Rest of TLS-* (BU, AU, CO-G, E) Reset over Reset by navigating to Implicit API/ API/Web KAS SSC (TLS), Admin Cookie-Key, APITLS Web interface ->
> Reboot or via API TLS-Host-Pub “radio_reset”. (CO-E) Rest of TLS-* (CO-G, E) RF Wireless Establish and transmit None None KAS SSC (RF) Mesh RF-Auth-Key, Link data with another Node DRBG-*, RF-SK module. Log (MN-E) messag ECDH-Sharede Secret, ECDHshowing KDF, RF-DHservice Priv, RF-DHstart. Pub, RF-TDK, RF-TEK (MN-G, E) Status Over Retrieve module API/ API/Web KAS SSC (TLS), Basic, Cookie-Key, APITLS status through the Web Respons KTS Advance Key, DRBG-*, Web interface. Input e d, Admin Passwords-*, Log TLS-Host-Priv, messag TLS-Host-Pub e (BU, AU, CO-E) Rest of TLS-* (BU, AU, CO-G, E) Update Upload new firmware Firm None KAS SSC (TLS), Admin Cookie-Key, APIImplicit Firmware image through the ware KTS Key, DRBG-*,
Error State Zeroize The user may call 1) 1)
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 HTTP instead of TLS, and SNMP, SSH for diagnostics. Table 15B. Non-Approved Services in Non-Approved Mode Name Description Indicato Input Output Security Function Roles Roles SSP r Implementation Access Configure Advanced non- API/ API/Web KAS SSC (TLS), Advance Cookie-Key, APIAdvanced security relevant Web Respons KTS d, Admin Key, DRBG-*, Settings over configuration Input e Passwords-*, Log HTTP/TLS TLS-Host-Priv, messag TLS-Host-Pub e (AU, CO-E) Rest of TLS-* (AU, CO-G, E) Configure Basic non-security API/ API/Web KAS SSC (TLS), Basic, Cookie-Key, APIBasic relevant configuration Web Respons KTS Advance Key, DRBG-*, Settings over Input e d, Admin Passwords-*, HTTP/TLS Log TLS-Host-Priv, messag TLS-Host-Pub e (BU, AU, CO-E) Rest of TLS-* (BU, AU, CO-G, E) Configure Security relevant API/ API/Web KAS SSC (TLS), Admin Cookie-Key, Security configuration, Web Respons KTS DRBG-* (CO-E) Settings over including uploading Input e API-Key (CO-E, HTTP/TLS license and settings I, G, O) files, and factory Passwords-* reset. (CO-I, E) Log TLS-Host-Priv, messag TLS-Host-Pub e (CO-G, I, E, O) Rest of TLS-* (CO-G, E) RF-Auth-Key, RF-SK (CO-G, I, O) Diagnostics Initiation of Serial Comman None Basic, Log Over Serial diagnostics like ping, Shell d Advance Passwords-* messag tcpdump, iperf, etc. Com Respons d, Admin (AU, CO, BU-E) e mand e Diagnostics Initiation of API/ API/Web KAS SSC (TLS), Basic, Cookie-Key, APIover diagnostics like iperf, Web Respons KTS Advance Key, DRBG-*, HTTP/TLS etc. Input e d, Admin Passwords-*, Log TLS-Host-Priv, messag TLS-Host-Pub e (BU, AU, CO-E) Rest of TLS-* (BU, AU, CO-G, E) Diagnostics Initiation of SSH Comman None Basic, Log Over SSH diagnostics like ping, Shell d Advance Passwords-* messag tcpdump, iperf, etc. Com Respons d, Admin (AU, CO, BU-E) e mand e Diagnostics Network monitoring SNM Comman None Unauthe over SNMP using SNMP. Log P d nticated messag com Respons None e mand e s Reset over Reset by navigating to API/ API/Web KAS SSC (TLS), Admin Cookie-Key, APIImplicit HTTP/TLS Web interface -> Web Respons KTS Key, DRBG-*,
> Reboot or via API cycle of TLS-Host-Priv, “radio_reset”. module. TLS-Host-Pub (CO-E) Rest of TLS-* (CO-G, E) RF Wireless Establish and transmit None None KAS SSC (RF) Mesh RF-Auth-Key, Link data with another Node DRBG-*, RF-SK module. Log (MN-E) messag ECDH-Sharede Secret, ECDHshowing KDF, RF-DHservice Priv, RF-DHstart. Pub, RF-TDK, RF-TEK (MN-G, E) RF Wireless Establish and transmit None None None Mesh Link data with another Node Log (Legacy) module. This service messag uses non-approved e DES-ECB and AES- RF-SK (MN-E) showing ECB. Note that only service the LSB 0-63 of the start. RF-SK are used for DES-ECB. Status Over Retrieve module API/ API/Web KAS SSC (TLS), Basic, Cookie-Key, APIHTTP/TLS status through the Web Respons KTS Advance Key, DRBG-*, Web interface. Input e d, Admin Passwords-*, Log TLS-Host-Priv, messag TLS-Host-Pub e (BU, AU, CO-E) Rest of TLS-* (BU, AU, CO-G, E) Update Upload new firmware Firm None KAS SSC (TLS), Admin Cookie-Key, APIImplicit Firmware image through the ware KTS Key, DRBG-*,
connecting to the cycle of module over its non- module RF interfaces on after HTTP port 50000 and complet send the API ion. command “radio_reset”. Status Retrieve module None None LED None Unauthe None status through LEDs, Status, nticated unauthenticated Web. FIPS Error State Zeroize The user may call 1) 1)
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:
Tamper evident seals are applied at Manufacturing. Table 16. Mechanisms and Actions Required Physical Security Mechanism Recommended Frequency of Inspection/Test Guidance Inspection/Test Details Tamper evident seals. Every 12 months. If the module shows any signs of tamper, the CO should zeroize the module and contact the manufacturer.
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 Name Description Persistence Type RAM Volatile system memory. Dynamic NAND Non-volatile system memory. Static EFUSE Non-volatile e-fuse memory. Static
Table 18. SSP Input-Output Methods Name From To Format Distribution Entry Type SFI or Type Type Algorithm API User, App Module Encrypted Automated Electronic AES-GCM Input API Module User, Encrypted Automated Electronic AES-GCM Output App Pre- Manufacturer Module Plaintext N/A N/A N/A Loaded RF KAS Module Peer Plaintext Automated Electronic KAS-ECCOutput Module (Public Key) SSC 56Ar3 TLS Module TLS Plaintext Automated Electronic KAS-ECCKAS Client (Public Key) SSC 56Ar3 Output 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
the local (nonRF) interfaces. Memory Cleanse Zeroize for temporary N/A. Not initiated by and ephemeral SSPs operator. by overwriting with zeroes to the memory location.
Table 20. SSPs - Part 1 Name Description Size Strengt Type Generate Establishe h d By d By Cookie- Used to sign 256 bits 256 bits HMAC-SHA- DRBG N/A Key authenticatio 384 Key (Internal) n cookies using HMAC-SHAAPI-Key Used to 256 bits 256 bits HMAC-SHA- DRBG N/A verify API 256 (Internal) requests or see input FW- Used to 256 bits 256 bits HMAC-SHA- N/A N/A HMAC- authenticate 256 Key firmware load file. DRBG-EI DRBG N/A 256 bits AES CTR Silvus N/A entropy DRBG with 256 Clock input. bits of security. Jitter Entropy Module (Internal) DRBG- DRBG Seed 256 bits 256 bits AES CTR input DRBG N/A Seed key, 128 seed (key, IV) (Internal) bits IV.
DRBG- Internal 256 bits 256 bits AES CTR DRBG N/A State DRBG State K, 128 DRBG internal (Internal)
generated 800 after ECDH- 56Cr1 KDF for (Internal) decrypting data on RF
Wireless Link. RF-TEK AES-GCM 256 bits 256 bits AES GCM 256 KDA One N/A
generated 800 after ECDH- 56Cr1 KDF for (Internal) encrypting data on RF Wireless Link. RF-SK AES-GCM 256 bits 256 bits AES GCM 256 DRBG N/A
used to or see encrypt and input decrypt data on RF Wireless Link. TLS-DH- TLS ECDH 256, 384, 128, P-256, P-384, ECDSA N/A Priv (ephemeral) 521 bits. 192, P-521 private KeyGen private key. 256 key. (Internal) bits. TLS-Host- TLS server 256, 384, 128, P-256, P-384, N/A N/A Priv host 521 bits 192, P-521 private certificate 256 key. private key. bits. TLS-PMS TLS pre- 256, 384, 128, P-256, P-384, N/A KAS-ECCmaster 521 bits. 192, P-521 primitive SSC secret. 256 Z computation. 56Ar3 bits. TLS-MS TLS master- 384 bits. 256 bits TLS PRF N/A KDA secret. computation. HKDF TLS-KDF 56Cr1 256 bits 256 bits 56Cr1 KDA KDA Two N/A compliant HKDF Step SPKDA HKDF 800 to generate 56Cr1 TLS-MS, (Internal) TLS-SENC, TLS-SMAC. TLS-SENC TLS session 256 bits. 256 AES GCM 256 N/A KDA encryption bits. bit key. HKDF key. TLS- TLS session 256 bits. 256 HMAC-SHA- N/A KDA SMAC authenticatio bits. 384 256 bit key. HKDF n key. RF-DH- P-521 ECDH 521 bits 256 bits SP-800 56A ECDSA N/A Pub ephemeral compliant P- KeyGen public key. 521 private key. (Internal)
TLS-Host- TLS server 256, 384, 128, P-256, P-384, ECDSA N/A Pub host 521 bits 192, P-521 public Keygen certificate 256 bits key. (Internal) public key. Or see input TLS-DH- TLS ECDH 256, 384, 128, P-256, P-384, ECDSA N/A Pub (ephemeral) 521 bits. 192, P-521 public KeyGen public key. 256 bits key. (Internal) Table 21. SSPs
TDK, RF-TEK RF-Auth- HMAC, API Input, NAND N/A API CSP RF-DHKey SHS API Output Zeroize Pub ECDH- KDA One N/A RAM RF Link KAS API CSP RF-DHShared- Step handshake < Zeroize, Pub, Secret 1s. Memory RF-DHCleanse Priv, ECDHKDF, RF-TEK, RF-TDK ECDH- KDA One N/A RAM RF Link KAS API CSP RF-DHKDF Step handshake < Zeroize, Pub, 1s. Memory RF-DHCleanse Priv, ECDHSharedSecret, RFTDK, RF-TEK RF-TDK AES N/A RAM Duration of API CSP RF-DHGCM power to Zeroize, Pub, module. Memory RF-DHCleanse Priv, ECDHSharedSecret, ECDHKDF, RF-TEK RF-TEK AES N/A RAM Duration of API CSP RF-DHGCM power to Zeroize, Pub, module. Memory RF-DHCleanse Priv, ECDHSharedSecret, ECDHKDF, RF-TDK RF-SK AES API Input, NAND N/A API CSP None GCM API Output Zeroize TLS-DH- KAS- N/A RAM TLS API CSP TLSPriv ECC- Handshake < Zeroize, DH-Pub, SSC 1s. Memory TLSCleanse PMS, TLSMS,
TLSKDF, TLSSENC, TLSSMAC TLS-Host- ECDSA API Input, NAND N/A API CSP TLSPriv SigGen, API Output Zeroize HostSigVer Pub TLS-PMS KDA N/A RAM TLS API CSP TLSHKDF Handshake < Zeroize, DH-Pub, 56Cr1 1s. Memory TLSCleanse DH-Priv, TLSMS, TLSSENC, TLSSMAC TLS-MS KDA N/A RAM TLS API CSP TLSHKDF Handshake < Zeroize, DH-Pub, 56Cr1 1s. Memory TLSCleanse DH-Priv, TLSPMS, TLSSENC, TLSSMAC, TLSKDF TLS-KDF KDA N/A RAM TLS API CSP TLSHKDF Handshake < Zeroize, DH-Pub, 56Cr1 1s. Memory TLSCleanse DH-Priv, TLSPMS, TLSMS, TLSSENC, TLSSMAC TLS- AES N/A RAM TLS session API CSP TLSSENC GCM duration. Zeroize, DH-Pub, Memory TLSCleanse DH-Priv, TLSPMS, TLS-
MS, TLSKDF, TLSSMAC TLS- HMAC, N/A RAM TLS session API CSP TLSSMAC SHS duration. Zeroize, DH-Pub, Memory TLSCleanse DH-Priv, TLSPMS, TLSMS, TLSKDF, TLSSENC RF-DH- KAS- RF KAS RAM RF Link KAS API PSP RF-DHPub ECC- Output handshake < Zeroize, Priv, SSC 1s. Memory ECDHCleanse SharedSecret, ECDHKDF, RFTDK, RF-TEK TLS-Host- ECDSA API Input, NAND N/A API PSP TLSPub SigGen, API Output Zeroize HostSigVer Priv TLS-DH- KAS- TLS KAS RAM TLS API PSP TLSPub ECC- Output Handshake < Zeroize, DH-Priv, SSC 1s. Memory TLSCleanse PMS, TLSMS, TLSSENC, TLSSMAC 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:
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:
Table 22. Pre-Operational Self-Tests Algorithm Implementation Test Test Method Type Indicator Details Properties CRC-32 CRC-32 CRC-32 CRC-32 FW Upon The Uchecksum checksum checksum Integrity success, Boot comparison comparison comparison. the bootloader
module will check will power the CRCup and 32 the LED checksum will of the change firmware from RED image to against GREEN. the value If the stored in integrity the test fails, firmware the file module header. will try a fallback image. If that fails too, the LED will stay RED, and the module will not power up (bricked).
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. Algorithm Implementa Test Test Type Indicat Details Condition tion Propert Method or ies DRBG A3422 SP-800 Health Healt Listed Power-Up 90A Check h above Health Chec table Tests k (1) ENT (NP) E25 SP-800 Repetition Healt Listed Health Power-Up 90B Count Test, h above Check Health Stuck Test, Chec table Tests Adaptive k (1)
Proportion Test, Lag Predictor Test. AES CTR A3422 256-bit KAT CAST Listed Encrypt/De Power-Up above crypt table (1) AES GCM A3422 256-bit KAT CAST Listed Encrypt/De Power-Up above crypt table (1) AES ECB A3422 256-bit KAT CAST Listed Encrypt/De Power-Up above crypt table (1) SHA2 A3422 1, 256, KAT CAST Listed Hash Power-Up 384, above
(1) SHA3 A3425 256 KAT CAST Listed Hash Power-Up above table (1) HMAC- A3422 1, 256, KAT CAST Listed MAC Power-Up SHA 384 above table (1) KAS-SSC A3422 P-521 KAT CAST Listed Z Power-Up above computatio table n (1) ECDSA A3422 P-521, SigGen, CAST Listed Sign and Power-Up SHA- SigVer KAT above Verify
(1) DRBG A3422 AES KAT CAST Listed RBG Power-Up CTR- above DRBG table (1) TLS A3422 V1.3 KAT CAST Listed KDF Power-Up HKDF above table (1) 56C KDF A3422 1-Step KAT CAST Listed KDF Power-Up SHA- above
(1) AES ECB A3420 or 256-bit KAT CAST Listed Encrypt Power-Up A3421 above
table (1) AES GCM A3420 or 256-bit KAT CAST Listed Encrypt/De Power-Up A3421 above crypt table (1) DRBG A3422 SP-800 Health Healt Listed Health Performed 90A Check h above Check when a Health Chec table random Tests k (2) value is requested from the entropy source as per SP 800-90B. ECDSA A3422 P-256 PCT PCT Listed Signature Key P-384 above Generation, Generatio P-521 table Signature n (2) Verification, Key Verification Firmware A3422 HMAC- Compare Firm Listed MAC Performed Load SHA- hash ware above Verification upon a
(2) load request. Entropy E25 SP-800 Repetition Healt Listed Health Performed Source 90B Count Test, h above Check when a Health Stuck Test, Chec table random Tests Adaptive k (2) value is Proportion requested Test, Lag from the Predictor entropy Test. source as per SP 800-90B. SP 800- A3422 SP PCT PCT Listed Public Key Performed 56Ar3 800- above Validation conditiona Assuranc 56Ar3 table Private Key lly per es Assura (2) Validation Section nces ECCDH 5.5.2, PCT: Key 5.6.2 Pair and/or Computatio 5.6.3. n
On demand self-tests can be invoked by powering cycling the module.
Table
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.