Hughes Network Systems, LLC
HT Satellite Terminals
Hardware Version: HT2010
Firmware Version: 7.4.1.19
FIPS 140-2 Non-Proprietary Security Policy
FIPS Security Level: 1
Document Version: 1.4
Prepared for: Prepared by:
Hughes Network Systems, LLC Corsec Security, Inc.
11717 Exploration Lane 13921 Park Center Road, Suite 460
Germantown, MD 20876 Herndon, VA 20171
United States of America United States of America
Phone: +1 301 428 5500 Phone: +1 703 267 6050
www.hughes.com/ www.corsec.com
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 2 of 29
Table of Contents
1. Introduction ..........................................................................................................................................4
1.1 Purpose.....................................................................................................................................................4
1.2 References................................................................................................................................................4
1.3 Document Organization ...........................................................................................................................4
2. Hughes HT Satellite Terminal..................................................................................................................5
2.1 Overview...................................................................................................................................................5
2.2 Module Specification................................................................................................................................6
2.2.1 Modes of Operation ....................................................................................................................9
2.3 Module Interfaces ................................................................................................................................. 10
2.4 Roles, Services, and Authentication...................................................................................................... 12
2.4.1 Authorized Roles ...................................................................................................................... 12
2.4.2 Operator Services..................................................................................................................... 12
2.4.3 Additional Services ................................................................................................................... 15
2.4.4 Non-Approved Services............................................................................................................ 16
2.4.5 Authentication.......................................................................................................................... 16
2.5 Physical Security.................................................................................................................................... 17
2.6 Operational Environment...................................................................................................................... 17
2.7 Cryptographic Key Management........................................................................................................... 18
2.8 EMI / EMC.............................................................................................................................................. 21
2.9 Self-Tests ............................................................................................................................................... 21
2.9.1 Power-Up Self-Tests ................................................................................................................. 21
2.9.2 Conditional Self-Tests............................................................................................................... 21
2.9.3 Critical Function Self-Tests ....................................................................................................... 22
2.9.4 Self-Test Failures ...................................................................................................................... 22
2.10 Mitigation of Other Attacks................................................................................................................... 22
3. Secure Operation.................................................................................................................................23
3.1 Installation and Setup............................................................................................................................ 23
3.1.1 Initial Setup and Configuration................................................................................................. 23
3.2 Crypto Officer Guidance........................................................................................................................ 23
3.2.1 Management ............................................................................................................................ 23
3.2.2 Load IPSec Key Files.................................................................................................................. 24
3.2.3 On-Demand Self-Tests.............................................................................................................. 24
3.2.4 Zeroization................................................................................................................................ 24
3.2.5 Decommission .......................................................................................................................... 24
3.2.6 Monitoring Status..................................................................................................................... 25
3.3 User Guidance ....................................................................................................................................... 25
3.4 Additional Guidance and Usage Policies ............................................................................................... 25
4. Appendix.............................................................................................................................................26
4.1 Acronyms............................................................................................................................................... 26
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 3 of 29
List of Tables
Table 1 – Security Level per FIPS 140-2 Section.........................................................................................................6
Table 2 – Cryptographic Algorithm Providers ............................................................................................................7
Table 3 – Algorithm Certificate Numbers (Hughes HT Satellite Terminal OpenSSL Crypto Library 1.0)....................7
Table 4 – Algorithm Certificate Numbers (Hughes HT Satellite Terminal SWP Hardware Crypto Library 1.0 ).........8
Table 5 – Algorithm Certificate Numbers (Hughes HT Satellite Terminal UPP Hardware Crypto Library 1.0 )..........9
Table 6 – Algorithm Certificate Numbers (Hughes HT Satellite Terminal DPP Hardware Crypto Library 1.0 )..........9
Table 7 – Algorithm Certificate Numbers (Hughes HT Satellite Terminal IKEv2 Protocol Library 1.0) ......................9
Table 8 – Allowed Algorithm Implementations..........................................................................................................9
Table 9 – FIPS 140-2 Logical Interface Mappings.................................................................................................... 10
Table 10 – LEDs and Status Indications ................................................................................................................... 11
Table 11 – Mapping of Authenticated Module Services to Roles, CSPs, and Type of Access................................. 13
Table 12 – Mapping of Unauthenticated Module Services to Roles, CSPs, and Type of Access............................. 14
Table 13 – Additional Services................................................................................................................................. 15
Table 14 – Non-Approved Services ......................................................................................................................... 16
Table 15 – Cryptographic Keys, Cryptographic Key Components, and CSPs........................................................... 18
Table 16 – Acronyms ............................................................................................................................................... 26
List of Figures
Figure 1 – Terminal within the Jupiter System...........................................................................................................5
Figure 2 – HT2010 Front View................................................................................................................................. 12
Figure 3 – HT2010 Rear View .................................................................................................................................. 12
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 4 of 29
1. Introduction
1.1 Purpose
This is a non-proprietary Cryptographic Module Security Policy for the HT Satellite Terminal from Hughes Network
Systems, LLC, hereafter referred to as “Hughes”. This Security Policy describes how the HT Satellite Terminal meets
the security requirements of Federal Information Processing Standards (FIPS) Publication 140-2, which details the
U.S.1
and Canadian government requirements for cryptographic modules. More information about the FIPS 140-
2 standard and validation program is available on the National Institute of Standards and Technology (NIST) and
the Communications Security Establishment (CSE) Cryptographic Module Validation Program (CMVP) website at
http://csrc.nist.gov/groups/STM/cmvp.
This document also describes how to run the module in a secure FIPS-Approved mode of operation. This policy
was prepared as part of the Level 1 FIPS 140-2 validation of the module. The HT Satellite Terminal are referred to
collectively in this document as Terminal, crypto module, or the module.
1.2 References
This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2
cryptographic module security policy. More information is available on the module from the following sources:
• The Hughes website (https://www.Hughes.com) contains information on the full line of products from
Hughes.
• The search page on the CMVP website (https://csrc.nist.gov/Projects/cryptographic-module-validation-
program/Validated-Modules/Search) can be used to locate and obtain vendor contact information for
technical or sales-related questions about the module.
1.3 Document Organization
The Security Policy document is organized into two primary sections. Section 2 provides an overview of the
validated module. This includes a general description of the capabilities and the use of cryptography, as well as a
presentation of the validation level achieved in each applicable functional area of the FIPS standard. It also
provides high-level descriptions of how the module meets FIPS requirements in each functional area. Section 3
documents the guidance needed for the secure use of the module, including initial setup instructions and
management methods and policies.
This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc.
under contract to Hughes. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Submission
Package is proprietary to Hughes and is releasable only under appropriate non-disclosure agreements. For access
to these documents, please contact Hughes.
1 U.S. – United States
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 5 of 29
2. Hughes HT Satellite Terminal
2.1 Overview
Hughes is a global leader in broadband satellite technology and managed network services for home and office.
Hughes’ broadband satellite systems enable operators and enterprises to deliver a comprehensive range of
services including broadband Internet access, cellular backhaul, communications on the move, and VoIP 2
telephony.
The Hughes’ Jupiter System is a broadband satellite system designed to support high-throughput satellite
communications and offers a range of operations for optimized traffic capacity, terminal performance, Gateway
(GW) design, and network management. It consists of satellite Terminal, single rack or multi rack Jupiter GWs
(facilities used to host the equipment providing uplink and downlink connectivity to the satellite), and the
capabilities to manage these devices over the network.
The Hughes Terminal is the indoor unit (IU), which connects the operator workstation to the outdoor unit (ODU)
over an inter-facility link (IFL). Figure 1 below shows the Terminal integration within the Hughes Jupiter System.
Figure 1 – Terminal within the Jupiter System
The Hughes HT Satellite Terminal, model HT2010, offers the following market-leading, next-generation functions:
2 VoIP – Voice Over Internet Protocol
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 6 of 29
• Forward channel wideband DVB-S2X support
• Return channel Low Density Parity Coding (LDPC) with Adaptive In-route Selection (AIS)
• Provides 200 Mbps3
throughput support
The Terminal provides an embedded web-based GUI4
. The GUI provides easy access to status monitoring,
troubleshooting, and diagnostics.
The Terminal ensures secure transfer of data across the network through cryptography provided by the Hughes
OpenSSL Crypto Library v1.0, which is based on the OpenSSL FOM5
2.0.16 (with OpenSSL 1.0.1p). Random number
generation is provided by an SP800-90A Hash DRBG, which receives entropy from an SP800-90B compliant entropy
source. The module supports SNMP and IKE through protocol-specific cryptographic libraries. An Acadia ASIC6
provides AES-NI encryption acceleration.
The Terminal cryptographic module is validated at the FIPS 140-2 Section levels shown in Table 1.
Table 1 – Security Level per FIPS 140-2 Section
Section Section Title Level
1 Cryptographic Module Specification 1
2 Cryptographic Module Ports and Interfaces 1
3 Roles, Services, and Authentication 2
4 Finite State Model 1
5 Physical Security 1
6 Operational Environment N/A7
7 Cryptographic Key Management 1
8 EMI/EMC8 1
9 Self-tests 1
10 Design Assurance 1
11 Mitigation of Other Attacks N/A
2.2 Module Specification
The Terminal is a hardware module with a multiple-chip standalone embodiment. The overall security level of the
module is 1. The cryptographic boundary is defined by the physical enclosure of the Terminal and includes all
internal hardware as well as the v7.4.1.19 application firmware. The module includes an Acadia ASIC with an ARM
Cortex-A9 Quad Core 720 MHz9
processor.
3
Mbps – Megabits per second
4 GUI – Graphical User Interface
5 FOM – FIPS Object Module
6 ASIC – Application Specific Integrated Circuit
7 N/A – Not Applicable
8
EMI/EMC – Electromagnetic Interference / Electromagnetic Compatibility
9 MHz – Mega Hertz
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 7 of 29
The module includes the cryptographic algorithm providers listed in Table 2 below.
Table 2 – Cryptographic Algorithm Providers
Certificate
Number
Implementation Name and Version Use
A1460 Hughes HT Satellite Terminal OpenSSL Crypto Library 1.0 Firmware-based cryptographic primitives (based on
OpenSSL FOM 2.0.16 with OpenSSL 1.0.2S)
A1437 Hughes HT Satellite Terminal SWP Hardware Crypto Library 1.0 Hardware-based cryptographic primitives
A1435 Hughes HT Satellite Terminal UPP Hardware Crypto Library 1.0 Hardware-based cryptographic primitives
A1436 Hughes HT Satellite Terminal DPP Hardware Crypto Library 1.0 Hardware-based cryptographic primitives
A1461 Hughes HT Satellite Terminal IKEv2 Protocol Library 1.0 IKE KDF (based on a Hughes proprietary IKE library)
The FIPS-Approved algorithms listed in Table 3 are implemented in the Hughes Terminal OpenSSL Crypto Library.
Table 3 – Algorithm Certificate Numbers (Hughes HT Satellite Terminal OpenSSL Crypto Library 1.0)
Certificate
Number
Algorithm Standard Mode / Method
Key Lengths / Curves
/ Moduli
Use
A1460 AES10 FIPS PUB 197 CBC11, CTR12 128, 256 Encryption/decryption
Vendor
Affirmed
CKG13 NIST SP 800-133rev2 - - Cryptographic key
generation
A1460 DRBG14 NIST SP 800-90Arev1 Hash-based SHA15-256 Deterministic random bit
generation
A1460 DSA16 FIPS PUB 186-4 PKCS17 v1.5 2048 (SHA2-256) Digital signature verification
N/A ENT (NP)18 NIST SP 800-90B - - Non-deterministic random
bit generation
A1460 HMAC19 FIPS PUB 198-1 SHA-1, SHA2-256-128,
SHA2-256
- Message authentication
A1460 KAS-SSC20 NIST SP 800-56Arev3 FFC21 DH22 Primitive Key establishment
methodology
provides 112 or 150
bits of encryption
strength
(MODP-2048 and
MODP-4096)
Shared secret computation
10 AES – Advanced Encryption Standard
11 CBC – Cipher Blocker Chaining
12
CTR – Counter
13 CKG – Cryptographic Key Generation
14 DRBG – Deterministic Random Bit Generator
15 SHA – Secure Hash Algorithm
16
DSA – Digital Signature Algorithm
17 PKCS – Public Key Cryptography Standard
18 ENT - Entropy
19 HMAC – (keyed-) Hashed Message Authentication Code
20 KAS-SSC – Key Agreement Scheme Shared Secret Computation
21
FFC – Finite Field Cryptography
22 DH – Diffie-Hellman
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 8 of 29
Certificate
Number
Algorithm Standard Mode / Method
Key Lengths / Curves
/ Moduli
Use
A1460 RSA23 FIPS PUB 186-4 PKCS v1.5 SigGen 2048 (SHA2-256) Digital signature generation
PKCS v1.5 SigVer 2048 (SHA2-256) Digital signature verification
A1460 Safe Primes
Key
Generation
NIST SP 800-56Arev3 Safe Prime Groups:
MODP-2048
MODP-4096
2048, 4096 Diffie-Hellman key
agreement
A1460 SHS24 FIPS PUB 180-4 SHA2-256-128, SHA2-256 - Message digest
The cryptographic library
supports the truncation of
HMAC SHA-2 to 128 bits
according to NIST SP 800-
107rev1.
The module includes the following vendor-affirmed security methods in the Hughes Terminal OpenSSL Crypto
Library v1.0:
• Cryptographic key generation – As per NIST SP 800-133rev2, the module uses the FIPS-Approved Hash-
based DRBG specified in NIST SP 800-90Arev1 to generate random seeds. The resulting generated seeds
are unmodified output from the DRBG. According FIPS 140-2 Implementation Guidance D.12, a
component key generation (CKG) using the unmodified output of an approved DRBG can be used to
generate seed for the asymmetric key generation. This method is valid per option 1 from section "4. Using
the Output of a Random Bit Generator" of FIPS SP 800-133rev2. Based on Additional Comments #1 of FIPS
IG D.12, this statement is enough and it is not necessary that the vendor justifies the equivalency between
this operation and XORing U and V with V as a string of zeros.
The FIPS-Approved algorithms listed in Table 4, Table 5, and Table 6 below are implemented in the module
hardware.
Table 4 – Algorithm Certificate Numbers (Hughes HT Satellite Terminal SWP Hardware Crypto Library 1.0 )
Certificate
Number
Algorithm Standard Mode / Method
Key Lengths /
Curves / Moduli
Use
A1437 AES FIPS PUB 197 CBC 256 Encryption/decryption
A1437 HMAC FIPS PUB 198-1 SHA2-256 - Message authentication
A1437 SHS FIPS PUB 180-4 SHA2-256 - Message digest
23
RSA – Rivest Shamir Adleman
24 SHS – Secure Hash Standard
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 9 of 29
Table 5 – Algorithm Certificate Numbers (Hughes HT Satellite Terminal UPP Hardware Crypto Library 1.0 )
Certificate
Number
Algorithm Standard Mode / Method
Key Lengths /
Curves / Moduli
Use
A1435 AES FIPS PUB 197 CTR25 256 Encryption/decryption
Table 6 – Algorithm Certificate Numbers (Hughes HT Satellite Terminal DPP Hardware Crypto Library 1.0 )
Certificate
Number
Algorithm Standard Mode / Method
Key Lengths /
Curves / Moduli
Use
A1436 AES FIPS PUB 197 CTR 256 Encryption/decryption
The FIPS-Approved algorithms listed in Table 7 below are implemented in the Hughes Terminal IKEv2 Protocol
Crypto Library.
Table 7 – Algorithm Certificate Numbers (Hughes HT Satellite Terminal IKEv2 Protocol Library 1.0)
Certificate
Number
Algorithm Specification
Mode /
Method
Key Lengths /
Curves / Moduli
Use
A1461 CVL NIST SP 800-135rev1 IKEv2 -
Key derivation function
No parts of the IKE protocol, other than the KDFs,
have been tested by the CAVP or CMVP.
The algorithm implementations shown in Table 8 below are allowed for use in a FIPS-Approved mode of operation:
Table 8 – Allowed Algorithm Implementations
Algorithm Caveat Use
AES26 (Cert. A1437) - Key unwrapping
The module implements the non-Approved algorithms listed below (these algorithms shall not be used in the
Approved mode of operation):
• SNMPv227
KDF (non-compliant)
2.2.1 Modes of Operation
The module supports two modes of operation: Approved and Non-approved. The module will be in FIPS-Approved
25 CTR - Counter
26 MD5 – Message Digest
27 SNMP – Simple Network Management Protocol
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 10 of 29
mode when all power up self-tests have completed successfully, and only Approved or Allowed algorithms are
invoked. See Table 3, Table 4, Table 5, Table 6, Table 7, and Table 8 for a list of the Approved and Allowed
algorithms.
The module can alternate service-by-service between Approved and non-Approved modes of operation. The
module will switch to the non-Approved mode upon execution of a non-Approved service. The module will switch
back to the Approved mode upon execution of an Approved service.
The services available in the non-Approved mode of operation are listed in section 2.4 below.
2.3 Module Interfaces
The module’s design separates the physical ports into four logically distinct and isolated categories. They are:
• Data Input Interface
• Data Output Interface
• Control Input Interface
• Status Output Interface
The cryptographic boundary is defined as the outer casing of the Terminal. The physical access points on the
appliance are the interfaces for the module. Table 9 below specifies the physical ports and manual controls
employed by the module and provides a mapping from the physical interfaces to logical interfaces as defined by
FIPS 140-2.
Table 9 – FIPS 140-2 Logical Interface Mappings
Physical Port/Interface
Quantity
Description
FIPS 140-2 Logical
Interface
HT2010
Satellite 1 IFL28-Type coaxial
connector
• Data Input
• Data Output
Ethernet Port 1 10/100/1000Base-T RJ-45
Ethernet LAN port
• Data Input
• Data Output
• Control Input
• Status Output
Power Connector 1 HT2010 – 4-pin Molex
Connector
• Power supply
Reset/Rescue Button 1 Button to turn power to
the modem on/off
• Control Input
The module has a USB29
port. This port is disabled. All data input and output are inhibited through this port.
28
IFL – Interfacility Dual Coaxial
29 USB – Universal Serial Bus
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 11 of 29
The module uses LEDs30
to provide status indications for the state and health of the modem. Table 10 below lists
each LED and its meaning.
Table 10 – LEDs and Status Indications
LED Type Description
FIPS 140-2 Logical
Interface
Ethernet LAN LED
• OFF: no connection
• ON: modem is connected to a computer network card or Ethernet
• BLINKING: transmitting and/or receiving data
Status output
Transmit LED
• OFF: condition preventing transmission
• ON: transmit path is operational
• BLINKING – FAST: transmitting data
• BLINKING – SLOW: the Terminal is measuring the distance to the
satellite to calibrate transmit timing and transmit power
Status output
Receiver LED
• OFF: condition preventing receipt of data
• ON: receive path is operational
• BLINKING: receiving data
Status output
System LED
• OFF: condition preventing full operation
• ON: connection established
• BLINKING: error state
Status output
Power supply LED
• OFF: no power
• ON – WHITE: power is on and the Terminal is functioning normally
• ON – RED: error condition
• BLINKING: operating with fallback-bin (backup) version of software
Status output
30 LED – Light Emitting Diode
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 12 of 29
Figure 2 – HT2010 Front View Figure 3 – HT2010 Rear View
2.4 Roles, Services, and Authentication
The sections below describe the module’s roles and services and define any authentication methods employed.
2.4.1 Authorized Roles
As required by FIPS 140-2, the module supports two roles that operators may assume: Crypto Officer (CO) role
and User role. The CO role has access to all module services, while the User has access to a subset of services.
Operators implicitly assume the set of both CO and User roles upon invocation of the services specified in Table
11 and Table 12 below, note that the services in Table 11 require authentication in order for the operator to invoke.
The module supports multiple concurrent operators.
2.4.2 Operator Services
Descriptions of the services available to the CO role and User role are provided in Table 11 below. Please note that
the keys and Critical Security Parameters (CSPs) listed in the table indicate the type of access required using the
following notation:
• R – Read: The CSP is read.
• W – Write: The CSP is established, generated, or modified.
• X – Execute: The CSP is used within an Approved or Allowed security function or authentication
mechanism.
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 13 of 29
• Z – Zeroize: The CSP is zeroized.
Table 11 below specifies the services which require authentication to the module.
Table 11 – Mapping of Authenticated Module Services to Roles, CSPs, and Type of Access
Service
Operator
Description Input Output CSP and Type of Access
CO User
Load Firmware ✓ ✓ Load new firmware
into the module
while in a FIPS-
approved mode of
operation
Command and
parameters
Status Output Firmware Verification Key – R/X
NMS-Terminal SDL Protocol – R/X
Upload SBC Config
file
✓ Upload new or
replacement SBC
Config file
Command and
parameters
Command
response
SBC Config file Verification Key – R/X
NMS-Terminal SDL Protocol – R/X
Decommission ✓ ✓ Decommissions the
module
Command Command
response
All ephemeral keys – ZIKE/IPsec
Authentication Certificate - Z
IKE/IPsec Authentication RSA Private Key
– Z
Zeroize ✓ ✓ Zeroize keys and
CSPs
Command Command
response
All ephemeral keys – Z
IKE/IPsec Authentication CA Certificate –
Z
IKE/IPsec Authentication Certificate – Z
IKE/IPsec Authentication RSA Private Key
– Z
Table 12 below specifies the services which do not require authentication to the module.
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 14 of 29
Table 12 – Mapping of Unauthenticated Module Services to Roles, CSPs, and Type of Access
Service
Operator
Description Input Output CSP and Type of Access
CO User
Decrypt keys ✓ ✓ Decrypt effective
master key;
decrypt session key
Command Status output TMK31 – R/X
EEMK32 – R/X
EMK33 – W/R/X
EUSK34 – R/X
USK35 –W
EMSK36 – R/X
MSK37 – W
EISK38 – R/X
ISK39 – W
Perform terminal
key request
✓ Request updated
session keys from
the KMS40
Command Command
response
EMK – R/X
EUSK41 – R/X
USK42 –W
EMSK43 – R/X
MSK44 – W
EISK45 – R/X
ISK46 – W
Encrypt/decrypt link
layer traffic
✓ ✓ Secure unicast,
multi-cast, and in-
route traffic
Command and
parameters
Command
response
USK – R/X
MSK – R/X
ISK – R/X
31 TMK – Terminal Master Key
32
EEMK – Encrypted Effective Master Key
33
EMK – Effective Master Key
34 EUSK – Encrypted Unicast Session Key
35 USK – Unicast Session Key
36
EMSK – Encrypted Multicast Session Key
37 MSK – Multicast Session Key
38 EISK – Encrypted In-route Session Key
39 ISK – In-route Session Key
40
KMS – Key Management Server
41 EUSK – Encrypted Unicast Session Key
42 USK – Unicast Session Key
43 EMSK – Encrypted Multicast Session Key
44 MSK – Multicast Session Key
45
EISK – Encrypted In-route Session Key
46 ISK – In-route Session Key
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 15 of 29
Service
Operator
Description Input Output CSP and Type of Access
CO User
Establish IKE/IPsec
session
✓ ✓ Establish IKE/IPsec
session for secure
data transmission
Command and
parameters
Command
response
IKE/IPsec Authentication CA47 Certificate
– R/X
IKE/IPsec Authentication Certificate –
R/X
IKE/IPsec Authentication RSA Private Key
– R/X
DH Public Key (DH public key
component)- R/W/X
DH Secret Key (DH private Key
component) – R/W/X
IKE Shared Secret – W/X
IKE Session Key – W/X
IKE Authentication Key – W/X
IPsec Shared Secret – W/X
IPsec Session Key – W/X
IPsec Authentication Key – W/X
DRBG Entropy – R/X
DRBG Seed – R/W/X
DRBG 'V' Value – R/W/X
DRBG 'C' Value – R/W/X
Perform self-tests
on demand
✓ ✓ Perform self-tests
on demand by
rebooting or
power-cycling the
module
Command Status output FW Verification Key – R/X
All ephemeral keys – Z
2.4.3 Additional Services
The module provides a limited number of services for which the operator is not required to authenticate or
assume an authorized role. Table 13 lists the services for which the operator is not required to assume an
authorized role. None of these services disclose or substitute cryptographic keys and CSPs or otherwise affect the
security of the module.
Table 13 – Additional Services
Service Description Input Output CSP and Type of Access
Authenticate to
the module
Authenticate to the module
Command and
parameters
Status output
Authentication password –
R/W/X
Show status View system status Command Status output None
Display status and
statistics
View current VSAT status and statistics,
including IKE/IPSEC
Command
Command
response
None
47 CA – Certificate Authority
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 16 of 29
Service Description Input Output CSP and Type of Access
Display result of
built-in self-test
Display results of non-cryptographic self-
tests to confirm the health of the system
Command Status output None
Access help
Link to Jupiter Worldwide Enterprise to
access help information for
troubleshooting and operating the system
Command Status output None
Reboot Manually reboot the module
Power-cycle;
reset button
Status output All ephemeral keys – Z
2.4.4 Non-Approved Services
The module performs service-by-service switching between FIPS-Approved and non-FIPS Approved mode. Table
14 below lists the services available in the non-Approved mode of operation.
Table 14 – Non-Approved Services
Service
Operator
Security Function(s)
CO User
Get VSAT statistics via SNMPv2   None
Send/Receive SNMPv2 traps   SNMPv2 KDF (non-compliant)
2.4.5 Authentication
The module supports role-based authentication. The VSAT provides access to Limited Advanced page locally only,
via a PC connected to the VSAT LAN port. Certain links on the Limited Advanced page are password protected.
A successful authentication grants access to services that require authentication, the module does not offer a
method to change roles. Once an operator logs out, then re-authentication is required to again access module
services.
Operator passwords shall be constructed using uppercase and lowercase letters, digits, and special characters,
and will follow the password complexity policies found in section 3.4 of this document. The minimum length of
the password is eight characters, with 90 different case-sensitive alphanumeric characters and symbols possible
for usage. The probability that of a random attempt will succeed or a false acceptance will occur is 1 per 908
possible passwords, or 1 per 4.3x1015
attempts, which is a lesser probability than 1 per 1,000,000 required by FIPS
140-2.
The fastest network connection supported by the module is 1000 Mbps. At most (1x109
bits/second × 60 seconds)
= 6x1010
= 60,000,000,000 bits of data can be transmitted in one minute. The minimum password is 64 bits (8 bits
per character x 8 characters), meaning 9.375x108
passwords can be passed to the module (assuming there is no
overhead). This equates to a 1:4,591,650 chance of a random attempt will succeed, or a false acceptance will occur
in a one-minute period, which is a lesser probability than 1 per 100,000 required by FIPS 140-2.
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 17 of 29
2.5 Physical Security
The Terminal is a multiple-chip standalone cryptographic module. The contents of the module, including hardware
components, firmware, and data are all protected by the module enclosure. The module enclosure is opaque
within the visible spectrum and consists of a hard production-grade plastic case that completely encloses all
internal components. The enclosure has a removable cover that is secured with screws.
In addition, all internal components of the module are production-grade and coated with commercial-standard
passivation.
2.6 Operational Environment
The module does not provide a general-purpose OS to the user. The module has an Acadia ASIC processor which
runs the MontaVista Linux (kernel 3.10.53). The module offers no mechanisms for the operator to modify
software/firmware components of the operating system, nor does it offer a way to load and execute software or
firmware that was not included as part of the module validation. Only the signed image installed on each module
can be executed.
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 18 of 29
2.7 Cryptographic Key Management
The module supports the CSPs listed below in Table 15.
Table 15 – Cryptographic Keys, Cryptographic Key Components, and CSPs
Key Key Type Generation / Input Output Storage Zeroization Use
Firmware Verification Key 2048-bit RSA public key Generated externally and
installed at the factory
Never exits the module Plaintext in non-volatile
memory
N/A Used in firmware integrity
check and firmware load
test
SBC Config file
Verification Key
2048-bit RSA public key Generated externally and
installed at the factory
Never exits the module Plaintext in non-volatile
memory
N/A Used in SBC config file
integrity check
NMS-Terminal SDL
Protocol Key
2048-bit DSA public key Generated externally and
installed during initial
configuration
Never exits the module Plaintext in non-volatile
memory
N/A Authentication of packets
sent from the NMS to the
module
TMK 256-bit AES-CBC key Generated externally and
installed at the factory
Never exists the module Plaintext in non-volatile
memory
Decommission Encryption/decryption –
decrypts EEMK
EEMK 256-bit AES-CTR key Generated externally and
installed during initial
configuration
Never exists the module Encrypted in non-volatile
memory
Decommission Decrypted with TMK to
generate the EMK
EMK 256-bit AES-CTR key Generated internally by
decrypting the EEMK
Never exits the module Plaintext in volatile
memory
Decommission, reboot,
power cycle, or session
termination
Decrypts the session keys
EUSK 256-bit AES-CTR key Generated externally and
entered encrypted via
SDL protocol
Never exits the module Encrypted in non-volatile
memory
Decommission Decrypted with EMK to
generate the USK
USK 256-bit AES-CTR key Generated internally by
decrypting the EUSK
Never exits the module Plaintext in volatile
memory
Decommission, reboot,
power cycle, or session
termination
Secure session traffic
EMSK 256-bit AES-CTR key Generated externally and
entered encrypted via
SDL protocol
Never exits the module Encrypted in non-volatile
memory
Decommission Decrypted with EMK to
generate the MSK
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 19 of 29
Key Key Type Generation / Input Output Storage Zeroization Use
MSK 256-bit AES-CTR key Generated internally by
decrypting the EMSK
Never exits the module Plaintext in volatile
memory
Decommission, reboot,
power cycle, or session
termination
Secure session traffic
EISK 256-bit AES-CTR key Generated externally and
entered encrypted via
SDL protocol
Never exits the module Encrypted in non-volatile
memory
Decommission Decrypted with EMK to
generate the ISK
ISK 256-bit AES-CTR key Generated internally by
decrypting the EISK
Never exits the module Plaintext in volatile
memory
Decommission, reboot,
power cycle, or session
termination
Secure session traffic
Authentication Password SHA-256 hash value Generated externally and
hashed during initial
configuration
Never exits the module Obfuscated in non-volatile
memory
Decommission Used for authentication
IKE/IPsec Authentication
CA Certificate
2048-bit RSA public key Generated externally and
installed during initial
configuration
Never exits the module Plaintext in configuration
file in non-volatile memory
Decommission, deletion
of configuration file
Authentication during
IKE/IPsec session
negotiation
IKE/IPsec Authentication
Certificate
2048-bit RSA public key Generated externally and
installed during initial
configuration
Never exits the module Plaintext in configuration
file in non-volatile memory
Decommission, deletion
of configuration file
Authentication during
IKE/IPsec session
negotiation
IKE/IPsec Authentication
RSA Private Key
2048-bit RSA private key Generated externally and
installed during initial
configuration
Never exits the module Plaintext in configuration
file in non-volatile memory
Decommission, deletion
of configuration file
Authentication during
IKE/IPsec session
negotiation
DH Public Key
(DH public key
component)
2048 and 4096-bit DH
public key
Internally generated
based on SafePrime key
generation method
Exits the module in
plaintext
Plaintext in volatile
memory
Decommission, reboot;
power cycle;
session termination
Derivation of the
IKE/IPsec Session Keys
and IKE/IPsec
Authentication Keys
DH Secret Key
(DH private key
component)
2048 and 4096-bit DH
public key
Internally generated
based on SafePrime key
generation method
Never exits the module Plaintext in volatile
memory
Decommission, reboot;
power cycle;
session termination
Derivation of the
IKE/IPsec Session Keys
and IKE/IPsec
Authentication Keys
IKE Shared Secret Shared Secret Derived internally via DH
shared secret
computation
Never exits the module Plaintext in volatile
memory
Decommission, reboot;
remove power;
session termination
Derivation of the IKE
Session Key and IKE
Authentication Key
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 20 of 29
Key Key Type Generation / Input Output Storage Zeroization Use
IKE Session Key 256-bit AES key Derived internally via IKE
KDF
Never exits the module Plaintext in volatile
memory
Decommission, reboot;
power cycle;
session termination
Encryption and
decryption of IKE session
packets
IKE Authentication Key 256-bit
HMAC key
Derived internally via IKE
KDF
Never exits the module Plaintext in volatile
memory
Decommission, reboot;
power cycle;
session termination
Authentication of IKE
session packets
IPsec Shared Secret Shared Secret Derived internally via DH
shared secret
computation
Never exits the module Plaintext in volatile
memory
Decommission, reboot;
remove power;
session termination
Derivation of the IPsec
Session Key and IPsec
Authentication Key
IPsec Session Key 256-bit AES key Derived internally via IKE
KDF
Never exits the module Plaintext in volatile
memory
Decommission, reboot;
power cycle;
session termination
Encryption and
decryption of IPsec
session packets
IPsec Authentication Key 256-bit
HMAC key
Derived internally via IKE
KDF
Never exits the module Plaintext in volatile
memory
Decommission, reboot;
power cycle;
session termination
Authentication of IPsec
session packets
DRBG Seed Hash based DRBG
440-bit value
Generated internally Never exits the module Plaintext in volatile
memory
Decommission, reboot;
power cycle
Seed material for NIST SP
800-90A Hash DRBG
DRBG Entropy Hash based DRBG
256-bit value
Generated internally Never exits the module Plaintext in volatile
memory
Decommission, reboot;
power cycle
Entropy material for NIST
SP 800-90A Hash DRBG
DRBG ‘V’ Value Internal state value Generated internally Never exits the module Plaintext in volatile
memory
Decommission, reboot;
power cycle
Used for NIST SP 800-90A
Hash DRBG
DRBG ‘C’ Value Internal state value Generated internally Never exits the module Plaintext in volatile
memory
Decommission, reboot;
power cycle
Used for NIST SP 800-90A
Hash DRBG
Notes: The module does not generate RSA keys. All RSA keys are generated externally and loaded into the module.
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 21 of 29
2.8 EMI / EMC
The Terminal were tested and found conformant to the EMI/EMC requirements specified by 47 Code of Federal
Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class A (business use).
2.9 Self-Tests
Cryptographic self-tests are performed automatically by the module when the module is first powered up and
loaded into memory as well as conditionally. The following sections list the self-tests performed by the module,
their expected error status, and the error resolutions.
2.9.1 Power-Up Self-Tests
The Terminal performs the following self-tests at power-up:
• Firmware
o Firmware integrity test (RSA 2048-bit with SHA256)
o Hughes HT Satellite Terminal OpenSSL Crypto Library 1.0
▪ AES encrypt and decrypt KATs48
(ECB-mode)
▪ DRBG KAT (NIST SP800-90A Hash DRBG)
▪ HMAC KAT with SHA-1 (160-bit) and SHA2-2 (256-bit)
▪ DSA pairwise consistency test
▪ RSA KAT
▪ DH Primitive “Z” Computation KAT (MODP-2048 and MODP-4096)
NOTE: A separate test for SHA-1 and SHA-2 is not needed as these algorithms are tested in the HMAC KAT.
• Hardware
o Hughes HT Satellite Terminal SWP Hardware Crypto Library 1.0
▪ AES encrypt and decrypt KATs (CBC-mode)
▪ HMAC KAT using SHA2-256
▪ SHA2-256 KAT
o Hughes HT Satellite Terminal UPP Hardware Crypto Library 1.0
▪ AES encrypt and decrypt KATs (CTR-mode)
o Hughes HT Satellite Terminal DPP Hardware Crypto Library 1.0
▪ AES encrypt and decrypt KATs (CTR-mode)
2.9.2 Conditional Self-Tests
The Terminal performs the following conditional self-tests:
• Firmware:
▪ Hughes HT Satellite Terminal OpenSSL Crypto Library 1.0
• Firmware Load Test (2048-bit RSA with SHA2-256)
48 KAT – Known Answer Test
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 22 of 29
• Continuous Health Tests on the entropy source:
o Stuck test on entropy source
o Adaptive Proportion Test on entropy source
o Repetition Count Test on entropy source
o Lag predictor test
The entropy source are also performed on 1024 consecutives noise source samples at module power-up.
The module performs all applicable assurances for its key agreement scheme as specified in section 9 of NIST SP
800-56Arev3.
2.9.3 Critical Function Self-Tests
The module performs health checks for the DRBG’s Generate, Instantiate, and Reseed functions as specified in
section 11.3 of NIST SP 800-90Arev1. These tests are performed at module power-up.
2.9.4 Self-Test Failures
If the module enters the critical error state due to a failure of the firmware integrity test, the fallback firmware is
loaded, and the error message will be logged in the /var/log/sig.log file. The error condition is considered to have
been cleared if the module successfully passes the integrity test and then all subsequent power-up self-tests. If
the module continues to return to a halted state, the module is considered to be malfunctioning or compromised,
and Hughes Customer Support must be contacted.
If the module enters the critical error state due to a failure of any of the remaining power-up self-tests, or if a
conditional self-test fails (other than the firmware load test), all cryptographic functions and data output services
are inhibited and an error message will be logged in the /fl0/fipskat_result.txt log file and is also visible on the GUI.
The CO must contact Hughes Customer Support if this error persists.
If the firmware load test fails, the firmware load process is aborted and no firmware is loaded; however, no module
halts or restarts are required to clear the error state. This is a transient error state; once the module sends a status
message of the error, then the error state is automatically cleared, and the module returns to a fully operational
state.
The module outputs status on both success and failure of the power-up self-tests, check /fl0/fipskat_result.txt for
the results of self-tests.
2.10 Mitigation of Other Attacks
This section is not applicable. The module does not claim to mitigate any attacks beyond the FIPS 140-2 Level 2
requirements for this validation.
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 23 of 29
3. Secure Operation
The sections below describe how to place and keep the module in the FIPS-approved mode of operation. Any
operation of the module without following the guidance provided below will result in non-compliant use and
is outside the scope of this Security Policy.
3.1 Installation and Setup
The CO is responsible for receiving the module, verifying package contents, and ensuring the site is prepared for
initial setup and configuration. Prior to beginning this process, the CO must review the appropriate User Guide
and Install Manual provided by Hughes. The following section provides guidance for initial setup and configuration
that must be performed before the module’s first use.
3.1.1 Initial Setup and Configuration
For installation instructions, the CO shall refer to the User Guide and Install Guide for the appropriate model of
the module. During the initial setup process the following steps will be performed:
1. The CO will power up the module, install the outdoor antenna, connect the cables and execute the
terminal installation and registration procedure. As part of this procedure, will register with the system
and the configuration files will automatically be downloaded from NMS. [Note: The terminal is NOT in
FIPS-Approved mode when coming out of factory].
2. The SDL DSA Public key for SDL signature validation is downloaded from NMS
3. Configuration files are downloaded via SDL protocol. IPSec Keys are downloaded as a part of these
configuration files
4. The module will check to confirm “FIPS_Mode = Enabled” in the configuration files. If enabled, the module
will automatically reboot. Upon reboot, the firmware integrity check and power-up self-tests will be
performed
The CO will validate that the module is operating in a FIPS-Approved mode by verifying status on the Web UI49
.
3.2 Crypto Officer Guidance
The CO is responsible for ensuring that the module is operating in the FIPS-Approved mode of operation.
3.2.1 Management
Once installed and configured, the CO is responsible for maintaining and monitoring the status of the module to
ensure that it is running in its FIPS-Approved mode. Please refer to sections 3.1, 3.2, and 3.4 for guidance that the
CO must follow to ensure that the module is operating in a FIPS-Approved manner.
49 UI – User Interface
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 24 of 29
3.2.2 Load IPSec Key Files
The CO must follow the procedure below to load the key file, and only after this is done can the module be
operated in the FIPS Approved mode. This process can be repeated whenever the module is in a FIPS-Approved
mode of operation to update keys. The following steps are performed to load the key file:
1. The CO loads new keys into NMS
2. The SDL protocol automatically informs the Terminal that updated keys are available
3. The Terminal automatically executes the SDL protocol with the NMS and downloads the updated key
files
4. The Terminal automatically deletes the existing keys and loads the new key file into non-volatile
memory
3.2.3 On-Demand Self-Tests
Although power-up self-tests are performed automatically during module power up, they can also be manually
launched on demand. Self-tests can be executed by power-cycling the module, using the reset button on the
platform (if applicable), or via the Web UI in “Self-Test” submenu.
3.2.4 Zeroization
There are many CSPs within the module’s cryptographic boundary including symmetric keys, private keys, public
keys, and passphrases. CSPs reside in multiple storage media including the RAM50
and system memory. All
ephemeral keys are zeroized on module reboot, power removal, or session termination. Before taking the module
out of FIPS-Approved mode, the CO must zeroize all unprotected secret and private keys by performing the
following steps:
1. Authenticate to the Web UI and navigate to Advanced Menu -> Installation -> Advanced -> Delete Key
Files
2. Select the Delete Key Files button
3. A “Delete All Key Files successfully” message will appear when all keys are deleted
4. Verify all key files are deleted by navigating to Advanced Menu -> Installation -> Advanced -> Display Key
Files. A message of “No Key File found” will be displayed.
3.2.5 Decommission
To decommission the VSAT modules, the CO must do the following:
1. Authenticate to the Web UI and navigate to Advanced Menu -> Installation -> Install
2. Select the Reinstall button
3. A confirmation message will be displayed
4. Click OK to confirm. The VSAT will perform the decommission process and reboot automatically.
50 RAM – Random Access Memory
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 25 of 29
3.2.6 Monitoring Status
The CO shall be responsible for regularly monitoring the module’s status for the FIPS-Approved mode of operation.
The CO confirms the module status via the dashboard of the Web UI.
3.3 User Guidance
While the CO is responsible for ensuring that the module’s physical security mechanisms are in place and that the
module is running in a FIPS-Approved mode of operation, Users should also monitor appliance status. Any changes
in the status of the module should immediately be reported to the CO.
3.4 Additional Guidance and Usage Policies
The notes below provide additional guidance and policies that must be followed by module operators:
• For services requiring authentication the module shall be administered locally.
• To execute the module’s power-up self-tests on-demand, the module’s host device can be rebooted or
power-cycled using the reboot command from the WebGUI or the reset button.
• All passwords are created and updated through the Hughes internal systems as hash values. Even though
the Hughes internal system is outside the scope of this validation, it is the responsibility of all operators
to ensure that the following password restrictions followed:
o Password must be eight (8) characters long
o At least one lowercase letter
o At least one uppercase letter
o At least one digit
o At least one special character (~, `, !, @, #, $, %, ^, &, *, -, _, =, +, {, }, [, ], |, \, :, <, >, /, ., ,,
", ")
• The SDL service monitors the system for new firmware. When new firmware is available, it is automatically
loaded into the module. Before loading the new firmware, a Firmware Load Test is performed. If the
Firmware Load Test passes, the new firmware is loaded into flash and will replace the existing firmware
when the module is rebooted. If the Firmware Load Test fails, the firmware is discarded, an error is logged,
and the module returns to normal operation.
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 26 of 29
4. Appendix
4.1 Acronyms
Table 16 provides definitions for the acronyms used in this document.
Table 16 – Acronyms
Acronym Definition
AES Advanced Encryption Standard
AIS Adaptive In-route Selection
API Application Programming Interface
ASIC Application Specific Integrated Circuit
CA Certificate Authority
CAVP Cryptographic Algorithm Validation Program
CBC Cipher Block Chaining
CCCS Canadian Centre for Cyber Security
CKG Cryptographic Key Generation
CMVP Cryptographic Module Validation Program
CO Crypto Officer
CPU Central Processing Unit
CRC Cyclic Redundancy Check
CSP Critical Security Parameter
CTR Counter
CVL Component Validation List
DH Diffie-Hellman
DRBG Deterministic Random Bit Generator
DSA Digital Signature Algorithm
DVB-S2X Digital Video Broadcasting – Satellite – Second Generation (Extension)
EC Elliptic Curve
ECC CDH Elliptic Curve Cryptography Cofactor Diffie Hellman
EEMK Encrypted Effective Master Key
EMI/EMC Electromagnetic Interference/Electromagnetic Compatibility
EMK Effective Master Key
FFC Finite Field Cryptography
FIPS Federal Information Processing Standard
FOM FIPS Object Module
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 27 of 29
Acronym Definition
GCM Galois Counter Mode
GUI Graphical User Interface
GW Gateway
HMAC (keyed-) Hash Message Authentication Code
IFL Inter-Facility Link
IKE Internet Key Exchange
IP Internet Protocol
IPsec Internet Protocol Security
ISK In-Route Session Key
IU Indoor Unit
IV Initialization Vector
KAS Key Agreement Scheme
KAS-SSC Key Agreement Scheme – Shared Secret Computation
KAT Known Answer Test
KDF Key Derivation Function
KMS Key Management Server
KPG Key Pair Generation
LAN Local Area Network
LDPC Low Density Parity Coding
LED Light-Emitting Diode
Mbps Megabits Per Second
MBX Multiplexed Block Exchange
MHz Mega Hertz
MSK Multi-Cast Session Key
N/A Not Applicable
NIST National Institute of Standards and Technology
NMS Network Management Server
ODU Outdoor Unit
OS Operating System
PCT Pairwise Consistency Test
PKCS Public Key Cryptography Standard
PUB Publication
RAM Random Access Memory
RNG Random Number Generator
RSA Rivest Shamir Adleman
SATA Serial Advanced Technology Attachment
FIPS 140-2 Non-Proprietary Security Policy, Version 1.4 July 24, 2023
HT Satellite Terminal
©2023 Hughes Network Systems, LLC
This document may be freely reproduced and distributed whole and intact including this copyright notice.
Page 28 of 29
Acronym Definition
SBC Satellite Based Commissioning
SCSI Small Computer System Interface
SDL Software Download
SHA Secure Hash Algorithm
SHS Secure Hash Standard
SNMP Simple Network Management Protocol
SP Special Publication
SSH Secure Shell
SSL Secure Socket Layer
TLS Transport Layer Security
TMK Terminal Master Key
UI User interface
U.S. United States
USB Universal Serial Bus
USK Unicast Session key
VoIP Voice Over Internet Protocol
VSAT Very Small Aperture Terminal
Prepared by:
Corsec Security, Inc.
13921 Park Center Road, Suite 460
Herndon, VA 20171
United States of America
Phone: +1 703 267 6050
Email: info@corsec.com
http://www.corsec.com