Hughes Network Systems Hughes Crypto Kernel (Software Version 1.2 on Windows Server 2003; Firmware Version 1.2 on VxWorks 5.4) FIPS 140-2 Non-Proprietary Security Policy Level 1 Validation Document Version 1.0 Prepared for: Prepared by: Hughes Network Systems Corsec Security, Inc. 11717 Exploration Lane 10340 Democracy Lane, Suite 201 Germantown, MD 20876 Fairfax, VA 22030 Phone: (301) 428-5500 Phone: (703) 267-6050 Fax: (301) 428-1868 Fax: (703) 267-6810 http://www.hughes.com http://www.corsec.com © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 Revision History Version Modification Date Modified By Description of Changes 1.0 2008-01-22 Xiaoyu Ruan Release. Hughes Crypto Kernel Page 2 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 Table of Contents 1 INTRODUCTION ...............................................................................................................................................4 1.1 PURPOSE ......................................................................................................................................................4 1.2 REFERENCES ................................................................................................................................................4 1.3 DOCUMENT ORGANIZATION .........................................................................................................................4 2 HUGHES CRYPTO KERNEL MODULE........................................................................................................5 2.1 OVERVIEW ...................................................................................................................................................5 2.2 MODULE SPECIFICATION ..............................................................................................................................5 2.3 MODULE INTERFACES ..................................................................................................................................8 2.4 ROLES AND SERVICES ..................................................................................................................................9 2.4.1 Crypto-Officer Role .......................................................................................................................9 2.4.2 User Role .....................................................................................................................................10 2.5 PHYSICAL SECURITY ..................................................................................................................................11 2.6 OPERATIONAL ENVIRONMENT....................................................................................................................11 2.7 CRYPTOGRAPHIC KEY MANAGEMENT........................................................................................................11 2.8 SELF-TESTS ................................................................................................................................................12 2.9 MITIGATION OF OTHER ATTACKS ..............................................................................................................12 3 SECURE OPERATION....................................................................................................................................13 3.1 INITIAL SETUP ............................................................................................................................................13 3.2 CRYPTO-OFFICER GUIDANCE .....................................................................................................................13 3.2.1 Initialization.................................................................................................................................13 3.2.2 Management.................................................................................................................................14 3.2.3 Zeroization ...................................................................................................................................14 3.3 USER GUIDANCE ........................................................................................................................................14 Table of Figures FIGURE 1 ­ HUGHES VSAT SATELLITE ROUTER ............................................................................................................5 FIGURE 2 ­ STANDARD GPC PHYSICAL BLOCK DIAGRAM .............................................................................................6 FIGURE 3 ­ HUGHES VSAT SATELLITE ROUTER PHYSICAL BLOCK DIAGRAM ...............................................................6 FIGURE 4 ­ LOGICAL CRYPTOGRAPHIC BOUNDARY .......................................................................................................7 List of Tables TABLE 1 ­ SECURITY LEVEL PER FIPS 140-2 SECTION ..................................................................................................7 TABLE 2 ­ FIPS 140-2 LOGICAL INTERFACES (GPC PLATFORM) ...................................................................................8 TABLE 3 ­ FIPS 140-2 LOGICAL INTERFACES (VSAT PLATFORM) ................................................................................9 TABLE 4 ­ MAPPING OF CRYPTO-OFFICER ROLE'S SERVICES TO INPUTS, OUTPUTS, CSPS, AND TYPE OF ACCESS ........9 TABLE 5 ­ MAPPING OF USER ROLE'S SERVICES TO INPUTS, OUTPUTS, CSPS, AND TYPE OF ACCESS .........................10 TABLE 6 ­ LIST OF CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS.....................................12 TABLE 7 ­ ACRONYMS .................................................................................................................................................15 Hughes Crypto Kernel Page 3 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the Hughes Crypto Kernel (software version 1.2 on Windows Server 2003; firmware version 1.2 on VxWorks 5.4) from Hughes Network Systems. This Security Policy describes how the Hughes Crypto Kernel (HCK) meets the security requirements of FIPS 140-2 and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 ­ Security Requirements for Cryptographic Modules) details the US 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) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/groups/STM/index.html. The Hughes Crypto Kernel is also referred to in this document as HCK 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 Network Systems website (http://www.hughes.com/) contains information on the full line of products from Hughes. · The CMVP website (http://csrc.nist.gov/groups/STM/index.html) contains contact information for answers to technical or sales-related questions for the module. 1.3 Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: · Vendor Evidence document · Finite State Machine · Installation Guides · Other supporting documentation as additional references 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 Validation Documentation is proprietary to Hughes and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact Hughes. Hughes Crypto Kernel Page 4 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 2 Hughes Crypto Kernel Module 2.1 Overview The HCK is packaged as a dynamic library, libhck.a or hck.dll, implemented in two different products. libhck.a is implemented in the Very Small Aperture Terminal (VSAT) which is a satellite based router running VxWorks 5.4. hck.dll is implemented in the Virtual Private Network (VPN) Internet Protocol (IP) gateway running on a general purpose computer (GPC) running Microsoft Windows Server 2003. The library provides the following basic functionalities: · establish and teardown IP Security (IPsec) tunnels between two or more hosts · create dynamically generated shared session keys using Internet Key Exchange (IKE) · perform Advanced Encryption Standard (AES) 128-bit encryption on all data transfer within an IPsec tunnel · ensure message authentication and integrity using Keyed-Hash Message Authentication Code (HMAC)- Secure Hash Algorithm (SHA)-1 2.2 Module Specification The Hughes Crypto Kernel is a multi-chip standalone module that meets overall Level 1 FIPS 140-2 requirements. Based on the platform on which the HCK is running on, the module can be considered as either software or firmware, as detailed below. · When the HCK source is compiled for use on a GPC running the Windows Server 2003 Operating System (OS) in single-user mode, the HCK is a software module. The server is placed in single-user mode by disabling all remote guest accounts in order to ensure that only one operator can log into the OS at a time. The services that are disabled are server services, terminal services, remote registry services, and remote desktop and remote assistance service. See Section 3.2.1 for details. · When the HCK source is compiled for use on the Hughes Very Small Aperture Terminal (VSAT) satellite router (see Figure 1), the HCK is a firmware module. The VSAT satellite router is a custom hardware appliance running VxWorks 5.4 OS. Figure 1 ­ Hughes VSAT Satellite Router The module's physical cryptographic boundary on the GPC platform is defined by the metal enclosure over the GPC motherboard. The module supports the physical interfaces of a GPC. The physical ports include the computer keyboard port, optical drives, floppy-disk drive, mouse port, serial ports, parallel ports, networks ports, monitor port, and power plug (see Figure 2). Hughes Crypto Kernel Page 5 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 Figure 2 ­ Standard GPC Physical Block Diagram Figure 3 ­ Hughes VSAT Satellite Router Physical Block Diagram Hughes Crypto Kernel Page 6 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 The module's physical cryptographic boundary on the VSAT appliance is defined by the appliance's metal case, which physically encloses the complete set of hardware and firmware, including the operating system and the module. The module supports the following physical ports: Local Area Network (LAN), telephone, serial, power, and satellite in/out ports (see Figure 3). The module is entirely encapsulated by the logical cryptographic boundary as shown in Figure 4. The module's logical cryptographic boundary is shown by the broken-line block marked "HUGHES Crypto Kernel". Notice that in this figure, CCI stands for Common Cryptographic Interface and GMP is the GNU Multiple Precision arithmetic library. Figure 4 ­ Logical Cryptographic Boundary The Hughes Crypto Kernel is validated at the following FIPS 140-2 Section levels: Table 1 ­ Security Level Per FIPS 140-2 Section Section Section Title Level (Software) Level (Firmware) 1 Cryptographic Module Specification 1 1 Hughes Crypto Kernel Page 7 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 Section Section Title Level (Software) Level (Firmware) 2 Cryptographic Module Ports and Interfaces 1 1 3 Roles, Services, and Authentication 1 1 4 Finite State Model 1 1 5 Physical Security N/A 1 6 Operational Environment 1 N/A 7 Cryptographic Key Management 1 1 8 Electromagnetic Interference (EMI)/ 1 1 Electromagnetic Compatibility (EMC) 9 Self-tests 1 1 10 Design Assurance 1 1 11 Mitigation of Other Attacks N/A N/A 2.3 Module Interfaces The functional module interface exists in the software/firmware. Physically, ports are considered to be those of the enclosure. The module provides Application Programming Interface (API) functions to interact with the components. Both the APIs and physical ports can be categorized into following logical interfaces defined by FIPS 140-2: · Data Input Interface · Data Out Interface · Data Control Interface · Status Output Interface · Power Interface These logical interfaces (as defined by FIPS 140-2) map to the module's physical interfaces, as described in the following tables. The Debug port of the VSAT platform is disabled by not being linked to the firmware. Table 2 ­ FIPS 140-2 Logical Interfaces (GPC Platform) FIPS 140-2 Hughes Crypto Kernel Interface Physical Port Logical Interface Data Input Function input variables. It provides APIs to interact Network port with the module. Data Output The API to the HCK library is the interface for data Network port output. The data output can be in the form of function output variables or return values. Control Input The API to the HCK library provides control input to the Network port, serial port, module in the form of parameters to function calls. keyboard port, mouse port, PC power button Status Output Certain function calls and return values for function Light Emitting Diode (LED)s, calls are the interfaces for status output. Display monitor port, network port Power Not applicable Power interface Hughes Crypto Kernel Page 8 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 Table 3 ­ FIPS 140-2 Logical Interfaces (VSAT Platform) FIPS 140-2 Hughes Crypto Kernel Interface Physical Port Logical Interface Data Input Function input variables. It provides APIs to interact Satellite port with the module. Data Output The API to the HCK library is the interface for data Satellite port output. The data output can be in the form of function input/output variables or return values. Control Input The API to the HCK library provides control input to Network port, serial port, power the module in the form of parameters to function calls. interface, telephone port Status Output Certain function calls and return values for function Network port, serial port calls are the interfaces for status output. Power Not applicable Power interface -- Not applicable Debug port 2.4 Roles and Services There are two roles in the module (as required by FIPS 140-2) that operators may assume: a Crypto-Officer role and a User role. The operator of the module must assume either of the roles based on the service being executed without any authentication. When running on the Windows Server 2003 platform, operator spaces on the module are separated by the OS. The OS must be configured for single user mode in FIPS-approved mode of operation. See Section 3.2.1 of this document for details. Both of the operator roles and their associated responsibilities are described below. 2.4.1 Crypto-Officer Role The Crypto-Officer is expected to install and configure the module in the FIPS mode of operation. Please see Section 3, Secure Operation, for a complete list of the Crypto-Officer's responsibilities. Descriptions of the services available to the Crypto-Officer role, including the inputs, outputs, and Critical Security Parameters (CSPs), are provided in the table below. Table 4 ­ Mapping of Crypto-Officer Role's Services to Inputs, Outputs, CSPs, and Type of Access CSP, Keys, and Service Description Input Output Type of Access Installation Installing the software Command Result of None /firmware module installation Uninstall Uninstall the Command Module All CSPs ­ Delete software/firmware module uninstalled hck_init Validates input Module configuration, Parameter Integrity Test Key ­ parameters before module statistics, validation status Read performing power-on self- crypto environment indicator tests; Initializes functions configuration hck_zeroize_csp Zeroizes all CSPs except CSP to be zeroized, Zeroization AES Key, HMAC for the integrity test key CSP type status Key, Diffie-Hellman Key ­ Zeroize Hughes Crypto Kernel Page 9 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 CSP, Keys, and Service Description Input Output Type of Access hck_shutdown Shuts down all crypto API call None AES Key, HMAC functionality Key, Diffie-Hellman Key ­ Delete hck_do_self_tests Performs power-on self- API call Self-test status Integrity Test Key ­ tests indicator Read hck_get_status Retrieves the crypto API call Crypto module None module status status information hck_get_name_and_ver Retrieves the module API call None None sion name and version number hck_get_version Retrieves the module's API call None None major and minor version numbers hck_get_fips_mode Determines whether or API call Mode indicator None not FIPS mode has been enabled hck_print_status Prints module status API call none None variables and statistics to a display or log file hck_update_parms Sets configuration API call Module status AES Key, HMAC parameters based on indicator Key, Diffie-Hellman module's current mode of Key ­ Write, Read, operation Overwrite 2.4.2 User Role While operating in the FIPS approved mode of operation, the User will be able to utilize the encryption and authentication functionality of the module. Descriptions of the services available to the User role are provided in the table below. Table 5 ­ Mapping of User Role's Services to Inputs, Outputs, CSPs, and Type of Access CSP and Type of Service Description Input Output Access hck_process_ike_event Ensures that crypto IKE event, IKE peer Validation AES Key, HMAC module is active and status Key, Diffie-Hellman validates input indicator Key ­ Read parameters before processing a received IKE packet or provides a timer event to the IKE state machine hck_process_tx_pkt Ensures that crypto IPSec peer, ESP packet, Validation AES Key, HMAC module is active and number of bytes to add status Key, Diffie-Hellman validates input to ESP packet, indicator Key ­ Write, Read, parameters before authentication algorithm Delete processing IPsec transmission packet Hughes Crypto Kernel Page 10 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 CSP and Type of Service Description Input Output Access hck_process_rx_pkt Ensures that crypto IPSec peer, ESP packet, Validation AES Key, HMAC module is active and ESP sequence number status Key, Diffie-Hellman validates input replay check indicator, indicator Key ­ Write, Read, parameters before authentication algorithm, Delete processing IPsec received IP header validation packet mode hck_send_ike_msg Ensures that crypto IKE message type, IKE Validation AES Key, HMAC module is active and peer message recipient status Key, Diffie-Hellman validates input indicator Key ­ Read parameters before invoking IKE transmit function 2.5 Physical Security When the module is running on Windows Server 2003, the physical security requirements do not apply to the module since it is software and does not implement any physical security mechanisms. When the module is running on VxWorks 5.4 within the Hughes VSAT satellite router, it is firmware and the physical security requirements apply. The Hughes VSAT satellite router is a production-grade embodiment that includes a removable plastic case, which completely surrounds the module. Both FIPS 140-2 test platforms (see Section 2.2) have been tested for and meet applicable Federal Communications Commission (FCC) Electromagnetic Interference and Electromagnetic Compatibility requirements for business use as defined in Subpart B of FCC Part 15. 2.6 Operational Environment When the module is running on VxWorks 5.4 within the Hughes VSAT satellite router, it is firmware. The operational environment requirements do not apply since VxWorks 5.4 within the Hughes VSAT satellite router is a non-modifiable operating system. When the module is running on Windows Server 2003, it is software and the operational environment requirements apply. The module is installed as a shared library in its compiled form, hkc.dll. The operating system must be configured for single user mode per CMVP guidance for FIPS 140-2 compliance. All keys, intermediate values, and other CSPs remain in the process space of a single operator. The operating systems protect memory and process space from unauthorized access. 2.7 Cryptographic Key Management The module implements the following FIPS-approved algorithms: · AES - Cipher Block Chaining mode (AES CBC) ­ FIPS 197 (Certificate #616) · SHA-1 (Byte-Oriented) ­ FIPS 180-2 (Certificate #664) · HMAC-SHA-1 ­ FIPS 198 (Certificate #319) · Digital Signature Algorithm (DSA) ­ 1024 bits, FIPS 186-2 (Certificate #239) for integrity test. · Pseudo Random Number Generator (PRNG) ­ American National Standards Institute (ANSI) X9.31 Appendix A.2.4 with 128-bit AES (Certificate #351) The module also implements the following non-FIPS approved algorithm: Hughes Crypto Kernel Page 11 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 · Diffie-Hellman ­ 1024-bit key agreement and key establishment providing 80 bits of encryption strength. The module supports the following critical security parameters: Table 6 ­ List of Cryptographic Keys, Cryptographic Key Components, and CSPs Key Key Type Generation / Input Storage Use AES Key 128-bit AES CBC Generated using ANSI Plaintext in Encrypt or decrypt IPsec symmetric key X9.31 PRNG Random Access Encapsulating Security Memory (RAM) Payload (ESP) packets HMAC Key 160-bit HMAC Generated using ANSI Plaintext in RAM Authenticate IPsec ESP key X9.31 PRNG packets Diffie-Hellman key 1024-bit Diffie- Generated using ANSI Plaintext in RAM Establish key pairs for pair Hellman keys X9.31 PRNG internet key exchange Integrity Test Key 1024-bit DSA Externally generated, Stored in hard- Software/firmware integrity public key hard coded in the module drive in plaintext test with compiled software PRNG Seed 128-bit seed Continually polled from Plaintext in RAM Random number various system resources generation to accrue entropy PRNG Seed Key 128-bit seed key Continually polled from Plaintext in RAM Random number various system resources generation to accrue entropy All keys generated by the module are generated internally using a FIPS-approved PRNG, ANSI X9.31 Appendix A.2.4 PRNG. CSPs are never output from the module. All keys except the integrity test key are zeroized when the module enters an error state, upon reboot, or if the operator calls the hck_zeroize_csp function. The Integrity Test Key, which is a DSA public key used to verify the signature on the software/firmware image, is zeroized when the module is uninstalled. The PRNG seed is zeroized when new seed is generated. The zeroization of the CSPs is carried out by overwriting the storage area or memory location with zeros. 2.8 Self-Tests The module is started by the application calling the hck_init function. Power-up self tests are executed automatically when hck_init is called. If these self-tests fail, then the module enters an error state and prevents all cryptographic processing and functionality. The Hughes Crypto Kernel performs the following power-up self-tests: · Software/Firmware integrity test using a DSA public key · Known Answer Tests (KATs) o AES KAT (encryption and decryption) o SHA-1 KAT o HMAC-SHA-1 KAT o ANSI X9.31 PRNG KAT In addition, the module performs a conditional PRNG self-test to ensure that the 128-bit random result is not equivalent to the previous result. 2.9 Mitigation of Other Attacks The module does not mitigate any attacks beyond the FIPS 140-2 level 1 requirements for this validation. Hughes Crypto Kernel Page 12 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 3 Secure Operation The Hughes Crypto Kernel meets Level 1 requirements for FIPS 140-2. The sections below describe how to place and keep the module in FIPS-approved mode of operation. 3.1 Initial Setup The Crypto-Officer role is responsible for ensuring that the module is installed on a platform as indicated in Section 2.2 of this document. The HCK implements a software/firmware integrity test that consists of a DSA signature computed over the image that comprises the library. During the power-up self-tests phase, the signature is verified over the stored HCK instance. If the stored signature is verified, then the test is passed. Otherwise, the test is failed and the module enters an error state where no cryptographic functionality is allowed. 3.2 Crypto-Officer Guidance The Crypto-Officer is responsible for initialization, monitoring, and shutdown of the module. 3.2.1 Initialization The Crypto-Officer role is responsible for ensuring that the module is operating in the FIPS approved mode of operation. The FIPS mode of the module is enabled through a parameter (boolean fips_mode, which must be set to True) passed to function hck_init. Notice that hck_init has to be called by the application (the VPN IP gateway software on Windows or the firmware on Hughes VSAT satellite router) first before other functions of the module are called. If a function is called without first calling hck_init, then the module will return a fatal error and be unloaded. A call to function hck_get_fips_mode will return a Boolean value showing the current FIPS mode setting of the module. The functions exported by the module are not directly accessible by a Crypto-Officer. Instead, the API functions are invoked by the application using the module. On Windows Server 2003, the Crypto-Officer can place the module in the FIPS mode by configuring proper settings in the application. Please refer to the installation manuals of individual applications for details. For the VSAT satellite router, the FIPS mode configuration is performed by Hughes in factory and cannot be changed by end-users. Before purchasing the VSAT router, the Crypto-Officer must request that the product be configured to the FIPS mode. To verify the VSAT router is indeed working in the FIPS mode, the Crypto-Officer should check the "HCK Stats" tag under the "IPSec/IKE" menu in the web browser interface and ensure that FIPS mode is indicated as "Enabled" under "HCK Status". When operated in the FIPS mode, on startup, the KATs and Integrity Test are executed before any cryptographic services are offered by the module. If any of the tests fail, then the module will be placed in an error state, and no crypto services are offered. FIPS 140-2 mandates that a software cryptographic module at Security Level 1 shall be restricted to a single operator mode of operation. Prior to installing the module, the Crypto-Officer must ensure the GPC is actually running Windows Server 2003. To configure Windows Server 2003 for single user mode, the Crypto-Officer must ensure that all remote guest accounts are disabled in order to ensure that only one human operator can log into the Windows OS at a time. The services that need to be turned off for Windows are: · Fast-user switching (irrelevant if server is a domain member) · Terminal services · Remote registry service · Secondary logon service · Telnet service · Remote desktop and remote assistance service Hughes Crypto Kernel Page 13 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 On a Hughes VSAT satellite router running VxWorks 5.4, the module is installed as part of the firmware image. The Crypto-Officer is responsible for verifying the version of the module on the VSAT router before use. This can be done by accessing the router via a web browser and checking the "HCK About" tag under "IPsec/IKE". 3.2.2 Management The Crypto-Officer should monitor the module's status regularly. If any irregular activity is noticed or the module is consistently reporting errors, then Hughes Network Systems customer support should be contacted. 3.2.3 Zeroization All keys except the Integrity Test Key are zeroized when the module enters an error state, upon reboot, or if the Crypto-Officer calls the hck_zeroize_csp function. The Integrity Test Key, which is a DSA public key used to verify the signature on the software/firmware image, is zeroized when the module is uninstalled. See Section 2.7 of this document for details. 3.3 User Guidance Only the module's cryptographic functionalities are available to the User. Although the User does not have any ability to modify the configuration of the module, they should report to the Crypto-Officer if any irregular activity is noticed. The User must not modify the configuration of the module as established by the Crypto-Officer. Hughes Crypto Kernel Page 14 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 22, 2008 Acronyms Table 7 ­ Acronyms Acronym Definition AES Advanced Encryption Standard ANSI American National Standards Institute API Application Programming Interface CBC Cipher Block Chaining CCI Common Cryptographic Interface CMVP Cryptographic Module Validation Program CSP Critical Security Parameter CVS Concurrent Versions System DSA Digital Signature Algorithm EMC Electromagnetic Compatibility EMI Electromagnetic Interference ESP Encapsulating Security Payload FIPS Federal Information Processing Standard GMP GNU Multiple Precision GPC General Purpose Computer GUI Graphical User Interface HCK Hughes Crypto Kernel HMAC (Keyed-) Hash Message Authentication Code IKE Internet Key Exchange IP Internet Protocol IPsec IP security KAT Known Answer Test LAN Local Area Network LED Light Emitting Diode NIST National Institute of Standards and Technology NVLAP National Voluntary Laboratory Accreditation Program OS Operating System PRNG Pseudo Random Number Generator RAM Random Access Memory SHA Secure Hash Algorithm VPN Virtual Private Network VSAT Very Small Aperture Terminal Hughes Crypto Kernel Page 15 of 15 © 2008 Hughes Network Systems This document may be freely reproduced and distributed whole and intact including this copyright notice.