Aviat Networks   Eclipse  Cryptographic Module     FIPS 140‐2 Non‐Proprietary   Security Policy    Level 2 Validation    Document revision 035, July 2014              Prepared for Aviat Networks by      Aviat Networks, Inc.    5200 Great America Parkway    Santa Clara, CA 95054    408.567.7000      www.aviatnetworks.com      Rycombe Consulting Limited    http://www.rycombe.com    +44 1273 476366        © 2014 Aviat Networks, Inc. This document may be reproduced only in its original entirety [without revision]. The information in this document is provided only for educational purposes and for the convenience of the customers of Aviat Networks. The information contained herein is subject to change without notice, and is provided “as is” without guarantee or warranty as to the accuracy or applicability of the information to any specific situation or circumstance. www.aviatnetworks.com  Contents    1  Introduction ............................................................................................................................................. 4  1.1  Identification ..................................................................................................................................... 4  1.2  Purpose ............................................................................................................................................. 4  . 1.3  References ......................................................................................................................................... 4  1.4  Document Organization .................................................................................................................... 4  1.5  Document Terminology  .................................................................................................................... 5  . 2  Aviat Networks Eclipse  ............................................................................................................................ 6  . 2.1  Overview ........................................................................................................................................... 6  2.2  Module Specification  ........................................................................................................................ 6  . 2.2.1  Hardware and Firmware Components ...................................................................................... 6  2.2.2  Cryptographic Boundary .......................................................................................................... 10  2.2.3  Scope of Validation .................................................................................................................. 11  2.2.4  Cryptographic Algorithms ........................................................................................................ 11  2.2.5  Components Excluded From the Security Requirements of the Standard  ............................. 13  . 2.3  Physical Ports and Logical Interfaces .............................................................................................. 14  2.4  Roles, Services and Authentication ................................................................................................. 15  2.4.1  Roles ......................................................................................................................................... 15  2.4.2  Services .................................................................................................................................... 15  2.4.3  Authentication ......................................................................................................................... 18  2.5  Physical Security .............................................................................................................................. 19  2.6  Operational Environment  ............................................................................................................... 25  . 2.7  Cryptographic Key Management .................................................................................................... 26  2.7.1  Random Number Generators .................................................................................................. 26  2.7.2  Key Generation ........................................................................................................................ 26  2.7.3  Key Table .................................................................................................................................. 26  2.7.4  CSP Destruction  ....................................................................................................................... 30  . 2.7.5  Access to Key Material ............................................................................................................. 31  2.8  Self‐Tests ......................................................................................................................................... 32  2.8.1  Power‐up Self‐tests .................................................................................................................. 33  2.8.2  Conditional Self‐tests ............................................................................................................... 33  2.9  Design Assurance ............................................................................................................................ 34  2.10  Mitigation of Other Attacks ......................................................................................................... 34  3  FIPS Mode of Operation  ........................................................................................................................ 35  .       2 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  Figures  Figure 1 Example INUe ..................................................................................................................................... 7  Figure 2 Module Hardware Variant Locations for INUe .................................................................................. 7  Figure 3 Baseline Components and Security Relevant Cards .......................................................................... 8  Figure 4 Non‐ Security Relevant Module Hardware Components .................................................................. 9  Figure 5 Block Diagram of the Cryptographic Boundary ............................................................................... 10  Figure 6 Security Level Specification Per Individual Areas of FIPS 140‐2 ...................................................... 11  Figure 7 Approved Algorithms ....................................................................................................................... 12  Figure 8 Module Interfaces ............................................................................................................................ 14  Figure 9 LED Status Indicators ....................................................................................................................... 14  Figure 10 Roles ............................................................................................................................................... 15  Figure 11 User Services .................................................................................................................................. 15  Figure 12 Crypto Officer Services .................................................................................................................. 17  . Figure 13 Other Services ................................................................................................................................ 17  Figure 14 Location of Fan Air Filter in INUe ................................................................................................... 18  Figure 15 INUe Enclosure ............................................................................................................................... 19  Figure 16 Louvers ........................................................................................................................................... 20  Figure 17 Left Hand Louver ............................................................................................................................ 21  Figure 18 Fitting the Left Hand Louver ‐ 1 ..................................................................................................... 21  Figure 19 Fitting the Left Hand Louver – 2 and Position of “Top” Tamper Evident Labels ........................... 22  Figure 20 Right Hand Louver  ......................................................................................................................... 23  . Figure 21 Fitting the Right Hand Louver ‐ 1 ................................................................................................... 23  Figure 22 Fitting the Right Hand Louver – 2 .................................................................................................. 24  Figure 23 Location of Security Labels Over Louver Panel .............................................................................. 24  Figure 24 Tamper Evident Label Positions ..................................................................................................... 25  Figure 25 Module Cryptographic Keys and CSPs ........................................................................................... 26  Figure 26 Module Public Keys ........................................................................................................................ 27  Figure 27 Key Table Part 1 ............................................................................................................................. 28  Figure 28 Key Table Part 2 ............................................................................................................................. 29  Figure 29 Public Key Table Part 1  .................................................................................................................. 30  . Figure 30 Public Key Table Part 2  .................................................................................................................. 30  . Figure 31 Access to Keys by Services ............................................................................................................. 32  Figure 32 Power‐up Self‐tests ........................................................................................................................ 33  Figure 33 Conditional self‐tests ..................................................................................................................... 34        3 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  1 Introduction  This section identifies the cryptographic module; describes the purpose of this document; provides  external references for more information; and explains how the document is organized.  1.1 Identification  Module Name  Aviat Networks Eclipse Cryptographic Module          Module Hardware Version  NUe 2RU Chassis (P/N EXE‐002), Fan Card (P/N EXF‐101), Node Controller  Card (P/N EXN‐004), FIPS Installation Kit (P/N 179‐530153‐001),  Replacement Labels (P/N 007‐600331‐001), and at least one of: [RAC 6X  (P/N EXR‐600‐001), RAC 6XE (P/N EXR‐600‐002), RAC 60 (P/N EXR‐660‐ 001), or RAC 60E (P/N EXR‐660‐002)]. All remaining slots filled by one of  the components listed in Figure 4.      Firmware Version  07.07.10  1.2 Purpose  This is the non‐proprietary FIPS 140‐2 Security Policy for the Aviat Networks Eclipse Cryptographic  Module, also referred to as “the module” within this document. This Security Policy details the secure  operation of Aviat Networks Eclipse Cryptographic Module as required in Federal Information Processing  Standards Publication 140‐2 (FIPS 140‐2) as published by the National Institute of Standards and  Technology (NIST) of the United States Department of Commerce and the Communications Security  Establishment (CSE).  1.3 References  For more information on Aviat Networks Eclipse please visit:  http://www.aviatnetworks.com/products/dual‐hybrid‐packet‐microwave/.   For more information on NIST and the Cryptographic Module Validation Program (CMVP), please visit  http://csrc.nist.gov/groups/STM/cmvp/index.html.   1.4 Document Organization  This Security Policy document is one part of the FIPS 140‐2 Submission Package. This document outlines  the functionality provided by the module and gives high‐level details on the means by which the module  satisfies FIPS 140‐2 requirements. With the exception of this Non‐Proprietary Security Policy, the FIPS  140‐2 submission documentation may be Aviat Networks proprietary or otherwise controlled and  releasable only under appropriate non‐disclosure agreements. For access to these documents, please  contact Aviat Networks.    The various sections of this document map directly onto the sections of the FIPS 140‐2 standard and  describe how the module satisfies the requirements of that standard.      4 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  1.5 Document Terminology  TERM  DESCRIPTION  ACM  Adaptive Coding and Modulation  AES  Advanced Encryption Standard  API  Application Programming Interface  ASIC  Application Specific Integrated Circuit  CAVP  Cryptographic Algorithm Validation Program  CMVP   Cryptographic Module Validation Program  CSP  Critical Security Parameters  DAC  Digital Access Card  DRBG  Deterministic Random Bit Generator  DSA  Digital Signature Algorithm  FIPS   Federal Information Processing Standard  GUI  Graphical User Interface  INU  Intelligent Node Unit  IRU  Indoor Radio Unit  NCC  Node Control Card  NMS  Network Management System  NPC  Node Protection Card  ODU  Outdoor Unit  OS  Operating System  RAC  Radio Access Card  RSA  An algorithm for public‐key cryptography. Named after Rivest, Shamir and  Adleman who first publicly described it.  SHA  Secure Hash Algorithm  SNMP  Simple Network Management Protocol  SP   Security Policy  Storage Media  Any media for which Cryptographic Module protection in the form of data  encryption is required. Storage Media include internal and external hard  drives, memory sticks and floppy disks.  TCP/IP   Transmission Control Protocol/Internet Protocol  TDM  Time‐Division Multiplexing  TLS  Transport Layer Security  XPIC  Cross Polarization Interference Cancellation        5 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  2 Aviat Networks Eclipse  This section provides the details of how the module meets the FIPS 140‐2 requirements.  2.1 Overview  Aviat Networks' Eclipse is an all‐in‐one next generation dual hybrid and packet microwave radio. Eclipse  provides superior networking features to address cost‐optimized mobile backhaul, public, and private  networking applications, along with high performance RF and Carrier Ethernet capabilities.     Aviat Eclipse delivers a "complete" set of microwave nodal networking capabilities. Eclipse delivers multi‐ directional integrated microwave switching within a single system, supporting up to 6 RF or up to 45  Ethernet radios in a single rack unit.    Eclipse also supports both native TDM and Ethernet services and provides fully integrated Ethernet  switching and IP networking, eliminating the need for external TDM grooming or Ethernet aggregation  devices.    Additionally, Eclipse can deliver greater than 2Gbps wireless transport with intelligent and fully integrated  bandwidth optimization features like XPIC, ACM, and data compression.    The cryptographic module is housed within the Eclipse Intelligent Node Unit (INUe) chassis.    The Eclipse INUe supports hardware redundancy to maintain data traffic by protecting a link with a  backup card that takes over in the event of hardware failure. It is possible to have up to 6 non‐protected  links or:   1 protected/diversity and 4 non‐protected links   2 protected/diversity and 2 non‐protected links   3 protected/diversity links    The module provides data security by encrypting the payload traffic on the microwave link between up to  three radios. It also provides the Strong Encryption Suite for secure module management and uses AES  encryption to secure SNMP v3 management traffic.   2.2 Module Specification  2.2.1 Hardware and Firmware Components  The module runs on proprietary hardware. The hardware consists of a number of plug‐in cards housed in  a proprietary chassis in 2RU format.    The module consists of an Eclipse Node Control Card (NCC), one or more Radio access card (RAC) and a  number of other plug‐in cards in combination.  Only the NCC and RAC cards are involved with  cryptography.  The remaining cards provide physical security via tamper evidence but do not provide any  other security relevant functionality.        6 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    Figure 1 Example INUe      Slot 1  Slot 2  Slot 3  F  Slot 4  Slot 5  Slot 6  A  Slot 7  Slot 8  Slot 9  N       NCC only    Slot 10  S  Figure 2 Module Hardware Variant Locations for INUe       Any of the Slots 1 through 10 may be covered with a blank panel. They shall not be left  unpopulated and shall have tamper labels applied per Section 2.5 below.   Slots 1, 2, 3, 4, 5, 6 are universal. Any RAC, DAC, NCM or AUX plug‐in card.   Slots 7, 8, 9 are restricted: any DAC, NCM or AUX, except DAV 155oM/eM where NMS is required.   Slot 10 is for NPC option only   NCC and FAN slots are dedicated – the INUe is supplied as standard with a single 2RU FAN,  although it accepts two 1RU FANs.   RAC/RAC or RAC/DAC 155oM/eM protected pairings must be installed in paired slots (Slot 1 and  Slot 4, Slot 2 and Slot 5, or Slot 3 and Slot 6).   For protected DACs or NCMs, the protection partners can be installed in Slots 1 through 9, except  for the case of DAC 155oM/eM where NMS access is needed, which is restricted to Slots 1 through  6.    NCC: Node control card  FAN: Fan card (cooling)  RAC: Radio access card (supports the ODU/IRU)  DAC: Digital access card (user interfaces)  AUX: Auxiliary card (auxiliary data and alarm I/O)  NPC: Node protection card (NCC protection)  PCC: Power Converter Card  NCM: Node Convergence Module    Interface traffic options include:   Ethernet, E1/DS1, E3/DS3, STM1/OC3   Auxiliary data and alarm I/O        7 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  The minimum module configuration requires baseline components, an NCC card, and at least one suitable  security relevant RAC card to be installed in order to support the Payload Encryption and Payload  Decryption services (see Figure 3).    ITEM  PART NUMBER  FIRMWARE/FPGA VERSION INFORMATION  QUANTITY IN   CRYPTOGRAPHIC  FUNCTIONALITY  AND REVISION  MODULE      BASELINE CONFIGURATION      INUe 2RU  EXE‐002  N/A  1  Yes  Chassis   Node  EXN‐004  Firmware: 07.07.10  1  Yes  Controller  FPGA_NCCV2_E1_DS1_004.bit  Card  FPGA_NCCV2_STM1_006.bit  Fan Card  EXF‐101  N/A  1  No  FIPS  179‐530153‐ N/A  1  No  Installation Kit  001  Replacement  007‐600331‐ N/A  1  No  Labels  001  And at least one of the following:  RAC 6X  EXR‐600‐001  FPGA_RAC6X_PDH_ACM‐14.19.52.bit  0‐6  Yes  FPGA_RAC6X_SDH‐2.3.1.bit  RAC 6XE  EXR‐600‐002  FPGA_RAC6X_PDH_ACM‐ 0‐6  Yes  14.19.52.bit  FPGA_RAC6X_SDH‐2.3.1.bit  RAC 60  EXR‐660‐001  FPGA_RAC6X_PDH_ACM‐ 0‐6  Yes  14.19.52.bit  FPGA_RAC6X_SDH‐2.3.1.bit  RAC 60E  EXR‐660‐002  FPGA_RAC6X_PDH_ACM‐ 0‐6  Yes  14.19.52.bit  FPGA_RAC6X_SDH‐2.3.1.bit  Figure 3 Required Baseline Components Cards    If a suitable card is not installed, then the Payload Encryption and Payload Decryption services are not  available.        8 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  All other cards that can be installed in the 2RU chassis are interchangeable (see Figure 4).  No slot shall be  left unpopulated.    ITEM  PART NUMBER  FIRMWARE/FPGA VERSION INFORMATION  QUANTITY IN   CRYPTOGRAPHIC  FUNCTIONALITY  AND REVISION  MODULE  Aux  EXA‐001  FPGA_AUX_132.bit  0‐5  No  DAC 4x  EXD‐040‐001  FPGA_DAC_4E1_DS1‐15.1.4.bit  0‐5  No  FPGA_DAC_4E1_WAYSIDE‐15.1.4.bit  DAC 155o  EXD‐152‐001  FPGA_DAC_155_MUXV2‐2.1.3.bit  0‐5  No  DAC 155oM  EXD‐153‐001  FPGA_DAC_155_MUX_001.bit  0‐5  No  (long)  DAC 155oM  EXD‐156‐001  FPGA_DAC_155_MUXV2‐2.1.3.bit  0‐5  No  (short)  DAC 16x  EXD‐160‐001  FPGA_DAC_16E1_DS1‐15.1.4.bit  0‐5  No  DAC ES  EXD‐171‐001  FPGA_DAC_ES_018.bit  0‐5  No  DAC 16xV2  EXD‐161‐001  FPGA_DAC16V2_E1_DS1‐3.1.4.bit  0‐5  No  DAC GE3  EXD‐181‐002  FPGA_DAC_E3_DS3_NOMUX_002.bit 0‐5  No  DAC GE3  EXD‐181‐001  FPGA_DAC_E3_MUX_132.bit  0‐5  No  DAC GE v2  EXD‐180‐002  N/A  0‐5  No  DAC GE v2 no  EXD‐180‐102  N/A  0‐5  No  SFP  DAC 2x155o  EXD‐252‐001  FPGA_DAC_2STM1_020.bit  0‐5  No  DAC 3xE3M  EXD‐331‐001  N/A  0‐5  No  NCM  EXD‐400‐002  FPGA_NCM‐1.1.112.bit  0‐5  No  FPGA_NCM_CES‐1.1.417.bit  FPGA_NCM_CES1‐1.1.443.bit  FPGA_NCM_HSF‐1.0.133.bit  FPGA_NCM_HSF_FIX‐1.1.152.bit  RAC 30v3  EXR‐999‐003  FPGA_RAC30_E3_DS3_002.bit  0‐6  No  RAC LL  EXR‐910‐001  FPGA_RACLL_IFC‐3.1.8.bit  0‐6  No  DAC LL  EXD‐180‐005  N/A  0‐5  No  NPC, high  EXS‐002  N/A  0‐1  No  output  NPC  EXS‐001  N/A  0‐1  No  24V card  EXP‐024  N/A  0‐1  No  Blank panel  EXX‐001  N/A  0‐10  No  Fan filter kit,  131‐501768‐ N/A  0‐1  No  2RU  001  Figure 4 Hardware Components      9 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  2.2.2 Cryptographic Boundary  The cryptographic boundary of the module is the hardware chassis. The module is a hardware module  with firmware running on the NCC card within the chassis.    The processor of this platform executes all firmware. All firmware components of the module are  persistently stored within the device and, while executing, are stored in the device local RAM.    Optionally, an ASIC on the RAC card provides the necessary functionality to support the Payload  Encryption and Payload Decryption services.      Figure 5 Block Diagram of the Cryptographic Boundary      10 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    2.2.3 Scope of Validation  The cryptographic module meets the overall requirements applicable to Level 2 security of FIPS 140‐2,  with Cryptographic Module Specification at Level 3 and Design Assurance at Level 3.    SECURITY REQUIREMENTS SECTION  LEVEL  Cryptographic Module Specification  3  Module Ports and Interfaces  2  Roles, Services and Authentication  2  Finite State Model  2  Physical Security  2  Operational Environment  N/A  Cryptographic Key Management  2  EMI/EMC  2  Self‐Tests  2  Design Assurance  3  Mitigation of Other Attacks  N/A  Figure 6 Security Level Specification Per Individual Areas of FIPS 140‐2  2.2.4 Cryptographic Algorithms  2.2.4.1 Approved algorithms  The following table provides details of the approved algorithms that are included within the module:    ALGORITHM TYPE  ALGORITHM  CAVP CERTIFICATE  USE  Authentication  HMAC‐SHA‐1  #1503  Within TLS  Hashing  SHA‐1  #2075  Used by SNMPv3 to obfuscate    authentication messages.      SHA‐256  Firmware load test  Asymmetric key  RSA  #1250  Firmware load test  TLS cipher suite  Deterministic Random  SP 800‐90 Hash‐based  #323  Key generation  Bit Generator  DRBG  Symmetric key  AES‐256 – CBC and  #2260  Two implementations:   CFB128. Encrypt and  #2418  1. Payload Encryption  decrypt. Also AES‐128‐ 2. Strong Security Suite and      11 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  ALGORITHM TYPE  ALGORITHM  CAVP CERTIFICATE  USE  CCM, AES‐128‐CBC,  Encryption of SNMPv3  AES‐192‐CCM and AES‐ sessions  256‐CCM  Symmetric key  Three key Triple‐DES  #1506  Strong Security Suite  SP800‐135 component  Section 4.2, TLS  #73  Within TLS  Figure 7 Approved Algorithms  2.2.4.2 Algorithms allowed in Approved mode   RSA (key wrapping; key establishment methodology provides 112 bits of encryption strength)‐ used to establish AES keys via TLS.   MD5 (only available within TLS)    The entropy used to seed the random number generator is an NDRNG that is a non‐ Approved algorithm used in FIPS mode. This is the /dev/random driver in the Linux kernel.  This has had to be modified to make use of bus accesses (instead of mouse and keyboard  activity, which is unavailable to the module). The time delta between bus accesses using the  PPC timebase register which has a granularity of 160 microseconds is used to increase  randomness. OpenSSL provides a callback that is used to feed the entropy to the DRBG on  demand.    This is reseeded once every 2^24 calls.    For Hash based DRBG, reseed required every <= 2^48 requests (SP800‐90A section 10.1).    Data from the entropy source has been collected and analyzed using a number of tools.    Dieharder: http://www.phy.duke.edu/~rgb/General/dieharder.php    and ENT: http://www.fourmilab.ch/random/    ENT output:    Entropy = 7.999992 bits per byte.    Optimum compression would reduce the size of this 24154464 byte file by 0 percent.    Chi square distribution for 24154464 samples is 277.48, and randomly would exceed this  value 15.94 percent of the times.    Arithmetic mean value of data bytes is 127.5082 (127.5 = random).  Monte Carlo value for Pi is 3.140555386 (error 0.03 percent).  Serial correlation coefficient is 0.000116 (totally uncorrelated = 0.0).      12 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com      2.2.4.3 Non‐approved algorithms  The following algorithms are also included within the module but are only available within the module  services in a non‐FIPS mode of operation:   Diffie‐Hellman (key agreement; key establishment methodology provides 112 bits of encryption  strength)     DES    DES is used by two of the SSL ciphers for the management interface (Portal). Diffie‐Hellman is used for  Payload Encryption key exchange.      The module uses MD5 to hash firmware components to check integrity. At startup, each component is  hashed, giving a 128‐bit value that is then checked against a stored value. If this fails, then the integrity  test fails.  2.2.5 Components Excluded From the Security Requirements of the Standard  The following observable, non‐security relevant components are excluded from FIPS 140‐2 requirements:   The components of all cards listed in Figure 4 except the faceplates. Since tamper evident seals are  applied  and  necessary  for  physical  security  protection,  the  faceplates  are  security  relevant  and  cannot  be  excluded.  All  other  card  components  are  excluded  from  FIPS  requirements  because  they are non‐security relevant.    Components along both left and right sides of the RAC cards with the exception of U42 on cards  RAC 6X, RAC 6XE, RAC 60, and RAC 60E. (Please see Appendix A for a complete list of excluded RAC  card components.)      13 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    2.3 Physical Ports and Logical Interfaces  The module is classified as a multi‐chip standalone module for FIPS 140‐2 purposes. The module’s physical  boundary is that of the INUe chassis.    The module provides its logical interfaces via the physical interfaces provided in the chassis. This logical  interface exposes the services (described in section 2.4.2) provided by the module.    The logical interfaces provided by the module are mapped onto the FIPS 140‐2 logical interfaces: data  input, data output, control input, and status output as follows:    FIPS 140‐2 LOGICAL  MODULE MAPPING  INTERFACE  Data Input  INUe Front panel sockets. The NCC component has four NMS connectors,  providing Ethernet access for Portal or ProVision  (http://www.aviatnetworks.com/products/network‐ managementoss/provision/). Pin assignments represent industry‐standard  LAN cable assembly for a 10/100Base‐T, RJ‐45 connector. It also has a V.24  connector providing serial data access for Portal.  Data enter and leave RAC adapters via a single RJ‐45 Ethernet socket. There is  an RF socket to connect the RAC to a radio transceiver so that the data can be  snet and received on a microwave link.  Data Output  INUe Front panel sockets (see above)  Control Input  INUe Front panel sockets (see above)  Status Output  INUe Front panel sockets (see above) and LEDs  Power Interface  NCC power interface and optional NPC. Power input limits are ‐40.5 to ‐60 V  DC. The power connector is a D‐Sub M/F 2W2. The positive DC return pin is  connected to chassis ground.  Figure 8 Module Interfaces    LED status indicators:      NCC STATUS LED  NCC TEST LED  RAC ON‐LINE  RAC STATUS LED  LED  FIPS Power‐up self‐tests in  Flashing orange  Flashing  N/A  Solid red  progress  orange  Power‐up self‐test failure  Solid red  Off  N/A  Solid red  Solid green Solid green N/A Solid green Self‐tests pass/FIPS  (Approved) mode enabled Figure 9 LED Status Indicators  When the three indicated LEDs are green, the module is in the Approved mode of operation.  The use of the Approved mode locks out the use of non‐approved algorithms.      14 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  2.4 Roles, Services and Authentication  2.4.1 Roles  The Cryptographic Module implements both a Crypto Officer role and a User role. Roles are assumed  explicitly using the authentication mechanisms described below. Section 2.4.2 summarizes the services  available to each role.    ROLE  DESCRIPTION  Crypto Officer  Mapping to a combination of the Eclipse’s “Crypto”, “Engineer” and “Admin”  users. Crypto Officer is able to configure security settings and payload  encryption and manage user accounts.  User  Mapping on to the Eclipse “Read‐only” user. A User is able to view the  configuration for a specific link.  Maintenance  This role supports the capability for users to add or remove plug‐in cards to  the module to provide extra bandwidth or different data formats. It also  allows for the insertion and removal of an optional fan air filter. Crypto  Officer support is required to perform Maintenance services.  Figure 10 Roles  2.4.2 Services  2.4.2.1 User Services  The following services may only be performed by an operator with “User” access permissions who has  been successfully authenticated to the module.    SERVICE  SERVICE INPUT  SERVICE OUTPUT  DESCRIPTION  RADIUS Authentication Success/fail  User authentication using  request, username RADIUS. Successful  and password authentication permits the  identified User access to  Craft Tool User Services.  Craft Tool  Authentication  Success/fail  User authenticated locally  Authentication  request, username  by module. Successful  and password  authentication permits the  identified User access to  Craft Tool User Services  View Configuration  View Configuration Event log entry  Provides a user with  Request configuration information as  an event log  Figure 11 User Services      15 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  2.4.2.2 Crypto Officer Services  The following services may only be performed by an operator with “Crypto Officer” access permissions  who has been successfully authenticated to the module.    SERVICE  SERVICE INPUT  SERVICE OUTPUT  DESCRIPTION  Enable Payload  Request to switch  Success/Fail  Although only a Crypto Officer may  Encryption  on payload  configure a secure data link, a User may  encryption for a  enable and disable encryption on a  specific link  specific microwave radio link.  Disable Payload  Request to switch  Success/Fail  Although only a Crypto Officer may  Encryption  off payload  configure a secure data link, a User may  encryption for a  enable and disable encryption on a  specific link  specific microwave radio link.  Craft Tool  Authentication  Success/fail  Crypto Officer authenticated locally by  Authentication  request, username  module. Successful authentication  and password  permits the identified Crypto Officer  access to Craft Tool Services.  Firmware Upgrade  Upgrade request  Success/fail  Successfully upgrading the firmware  and firmware  loads the new image into module and  image  reboots the module to allow the new  firmware to become operational. If the  firmware upgrade fails, then the new  image is not loaded and the module  rolls back to the original firmware and  this remains operational.  Zeroize  Zeroize request  Success/fail  Zeroizes all plaintext secret and private  cryptographic keys and CSPs within the  module, specifically those listed in  section 2.7.3.  Event log entry  Generates a new key for the selected Key Management  Link ID. Service  link.  (Payload Encryption)  accessed via Craft  indicates  tool GUI  success/failure  Key Management  Enable strong  Event log entry  Enabling strong security is a  (Secure  security via GUI  indicates  requirement of the FIPS mode of  Management)  success/failure  operation. Once enabled, the key  management is automatic. Keys are  established as required and used to  secure the appropriate services.  Module  Craft tool GUI   Confirmation of  The Craft tool is used to configure the  Configuration  parameters and  “strong security suite” within the  actions  module.  SNMP v3  Secure SNMP  Secure SNMP  The module adds an extra layer of  session request  session  security to SNMP v3 by encrypting      16 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  SERVICE  SERVICE INPUT  SERVICE OUTPUT  DESCRIPTION  SNMP traffic using AES. SNMPv3 keys  are manually entered. There is no  internal key derivation.  RADIUS  Authentication  Success/fail  Crypto Officer authentication using  request, username  RADIUS. Successful authentication  and password  permits the identified Crypto Officer  access to Craft Tool Services.  View Status View Status Event log entry  Provides a user with status information  Request  Request as an event log.  Figure 12 Crypto Officer Services  2.4.2.3 Unauthenticated Services  SERVICE  SERVICE INPUT  SERVICE OUTPUT  DESCRIPTION  Payload Encryption  Plaintext payload  Encrypted payload  Once a microwave link is  data  data  configured and keys are  established, any data sent  on the link will be  encrypted  Payload Decryption  Encrypted payload  Plaintext payload  Decrypts payload data  data  data  received on a secure  microwave link.  Perform Self‐Tests  Power‐up module  Self‐test status  Self‐tests are performed  automatically at startup. If  the self‐tests fail, the  module enters an error  state. If they succeed, the  module becomes  operational.  View Status indicators  N/A  LED indicators  LED indicators provide  information about the state  of the payload encryption  service and the self‐test  results.   Figure 13 Other Services    Firmware integrity checking allows an operator to perform the RSA signature generation and verification.    2.4.2.4 Maintenance  Maintenance consists of inserting, removing or replacing plug‐in cards and the fan air filter. The Crypto  Officer must perform the zeroize service and then power down the module. The module must remain      17 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  powered down during maintenance and then the Crypto Officer must power up the module and perform  the zeroize service to complete the maintenance.    Plug‐in Cards  To remove a plug‐in card or blank, remove its tamper evident labels, loosen its front‐panel fastening  screws and pull it towards you. Inserting a card may require the removal of a blank to access the card slot.  To insert a plug‐in card, push it into the appropriate slot. Ensure its backplane connector is correctly  engaged before applying sufficient pressure to bring the plug‐in panel flush with the front panel. Secure  the card using its fastening screws.    Fan Air Filter  For the INUe, a fan air filter kit is supplied, comprising a filter frame, filter element, and fastening screw. It  is installed in the INUe to the right side of the FAN module, as illustrated below.    Remove the FAN module and slide the air filter into the chassis so that it locates to the right side of the  FAN module backplane connector, and up against the chassis side. FAN module removal and replacement  does not affect traffic.    Installation instructions are included with the fan filter kit.      Figure 14 Location of Fan Air Filter in INUe    Renewing Physical Security Following a Maintenance Task  The physical security measures must be checked and renewed as appropriate following any module  maintenance. When replacing a tamper evident label, any residue from a previous label must be removed  before a new label is applied.  2.4.3 Authentication  The module uses role‐based and identity‐based user authentication. RADIUS may be used for user  authentication and RADIUS is authenticated to the module using a shared secret.        18 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  User and Crypto Officers are authenticated by presenting a username and password to the module for  authentication. This is either done locally by the module using its own list of local users and their  credentials or remotely using a RADIUS server and a centrally held database of users and credentials. If  the user identity and password match stored values then authentication is successful.    In order to meet the requirement that the probability shall be less than one in 1,000,000 that a random  attempt will succeed or a false acceptance will occur, certain restrictions are placed upon operator  passwords.    For locally defined users passwords must be between 8 and 32 characters and be comprised of at least  one letter and one number. Users defined on RADIUS servers are outside of the module’s control, but for  the module to operate in FIPS mode, such users must have a password of similar strength and as an  absolute minimum, must have at least 5 characters. Even with a 5 character lower case alphabetic  password, that still gives a random chance of guessing the correct password in a single attempt of 1 in  11,881,376. Real‐world passwords will normally be more complex than this. The module locks out user  logon attempts for one minute after three consecutive logon failures. Assuming the weakest password  and the ability of an attacker to make 3 logon attempts in a minute, this still gives the random chance of  successfully guessing correctly a password given multiple attempts in a minute at 1 in 3,960,458.6, which  is greater than the 1 in 100,000 required.  2.5 Physical Security  The module is entirely encased by a thick steel chassis. The back of the chassis is completely closed off  and internally has a backplane into which plug‐in cards may be inserted. The front of the chassis, where  plug‐in cards are inserted, must be sealed in a commissioned module. The sides of the chassis have vent  holes to allow air to flow across components within the module to provide cooling and prevent  overheating.    The INUe enclosure (Figure 15) has an NCC card and ten expansion slots, each of which must either  contain a plug‐in card or be covered by a blanking plate.      Figure 15 INUe Enclosure    The module is supplied with a set of tamper evident labels. Once a module is commissioned, the labels  must be applied to the NCC, plug‐in cards and blanking plates, such that for each item that borders that  chassis, there is a label joining the item to the chassis. For each item that does not border the chassis,  there is a label linking it to its neighbor.       19 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    Opacity: The module enclosure has vent holes at the sides. The vent holes are covered by louvers that  provide no line of sight view of any internal components. Four (4) tamper evident labels are fitted to each  louver.    Two (2) sizes of tamper evident labels are used in the module and must be fitted correctly to satisfy the  physical security requirements for the module. The wider labels must be used for the louvers and the  narrower labels must be used on the top front and on the front panel. Fitting instructions are provided  below.     Figure 16 Louvers      The tamper evident labels and louvers/filters shall be installed for the module to operate in a FIPS  Approved mode of operation.    The Crypto Officer is responsible for the application and maintenance of the physical security policy:    To fit the louvers:    All surfaces must be clean and dry prior to installation. Wipe the side of the INUe surfaces with isopropyl  alcohol and let dry. Place the INUe shelf on flat surface and install the louver panels as shown below.    Left Hand Side (as viewed from the front)   Locate the louver panel and remove the paper backing from the double sided pressure sensitive  adhesive (PSA) foam tape.      20 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    Figure 17 Left Hand Louver     Align the front edge of the louver panel with the edge of the radius near the front mounting ear.   Align the bottom edge of the louver panel with the bottom edge of the INUe shelf.    Figure 18 Fitting the Left Hand Louver ‐ 1     Apply strong pressure to the side of the louver panel to bond the PSA to the INUe shelf.      21 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    Figure 19 Fitting the Left Hand Louver – 2 and Position of “Top” Tamper Evident Labels     Let the louver panel PSA cure for at least 5 minutes before proceeding to install the right hand side.      22 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    Right Hand Side (as viewed from the front)   Locate the louver panel and remove the paper backing from the double sided PSA foam tape.    Figure 20 Right Hand Louver     Align the front edge of the louver panel with the edge of the radius near the front mounting ear.   Align the bottom edge of the louver panel with the bottom edge of the INUe shelf.    Figure 21 Fitting the Right Hand Louver ‐ 1     Apply strong pressure to the side of the louver panel to bond PSA to the INUe shelf.      23 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    Figure 22 Fitting the Right Hand Louver – 2     Let the louver panel PSA cure for at least 5 minutes then proceed to installing the security labels.    Apply security LABELS over louver panels:  Left hand side (as viewed from the front)   Apply the wider security label over louver panel and across INUe chassis. Use caution to avoid  touching the adhesive with fingerprints to avoid damaging the labels. Allow the label adhesive at  least 60 minutes to cure.  Right hand side (as viewed from the front)   Apply the wider security label over louver panel and across INUe chassis. Use caution to avoid  touching the adhesive with fingerprints to avoid damaging the labels. Allow the label adhesive at  least 60 minutes to cure.   Figure 23 Location of Security Labels Over Louver Panel   (Left Hand Side Shown – Right Hand Side is Mirror Image)      24 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    Immediately before the INUe is installed into its rack/cabinet, apply the narrower tamper evident labels  as shown in Figure 19 with a label over each of the three (3) top‐front screw heads, and apply the four (4)  wider labels per side as indicated in Figure 23.   Clean the areas where the labels are to be applied as appropriate using alcohol‐based cleaning  pads or a rag moistened with isopropyl alcohol, and let dry.   When peeling and placing the labels avoid finger contact with the label backing to prevent damage  to the label. The use of tweezers applied on the edge of the label is recommended.    Ensure the labels are not damaged when installing the INUe into its rack/cabinet.    To install the tamper evident labels on front panel:   Verify that the front panel is contiguous   For slots that do not contain plug‐in cards, fit a blank panel (HW P/N EXX‐001 per Figure 4)   Remove excessive grease, dirt, or oil from the cover if appropriate by using alcohol‐based cleaning  pads before applying the tamper evident labels. The chassis temperature should be above 10° C  (50° F).   Affix (12) narrower tamper evident labels as indicated in Figure 24 below such that it is not  possible to remove either a single card or a group of cards without also removing a label and  leaving tamper evidence.   Install the INUe shelf into the rack and apply security label over front of the cards in the chassis as  shown. Use caution to avoid touching the adhesive with fingerprints to avoid damaging the labels.  Allow the label adhesive at least 60 minutes to cure.   The tamper evident labels should be replaced whenever components are added or removed from  the module. Replacement labels can be ordered from Aviat Networks, part number 007‐600331‐ 001   Tamper evident labels should be inspected for integrity at least once every six (6) months      Figure 24 Tamper Evident Label Positions  2.6 Operational Environment  The module operational environment is derived from a version of embedded Linux. This has been  adapted such that there is no general purpose operating system functionality available to an operator.     The only firmware that can be loaded is the module firmware. The module firmware can be updated using  the “Firmware Upgrade” service. This requires the verification of a digital signature.        25 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  The Operating Environment of the module is a limited operational environment and so the Section 6  Operational Environment requirements are not applicable.    2.7 Cryptographic Key Management  2.7.1 Random Number Generators  The module contains an approved SP 800‐90 Hash‐based DRBG.  2.7.2 Key Generation  Keys generated internally are generated by the SP 800‐90 DRBG seeded by system entropy. Checks are  made to ensure that the quantity of the entropy remains high enough to be used to seed the DRBG. The  module uses the Hash‐based DRBG to generate symmetric AES keys and Asymmetric RSA key pairs.  2.7.3 Key Table  The following tables list all of the keys and CSPs within the module, describe their purpose, and describe  how each key is generated, entered and output, stored and destroyed.    KEY  PURPOSE  TLS Private key  Establish TLS tunnel for HTTPS and WMTS ports for  managing remote radio.  TLS tunnel key  Encrypt TLS session for the Craft tool and web server.  Symmetrical key AES‐128, AES‐256 or Triple‐DES  RADIUS shared secret  Used for MD5 hashing of RADIUS passwords  SNMPv3 privacy password  Used for encrypting SNMPv3 packets  SNMPv3 authentication  Used for encrypting SNMPv3 packets  password  Payload Encryption RSA Private  Used to establish payload encryption TLS tunnel key   key  Payload Encryption TLS tunnel  Used to encrypt the AES tunnel established using TLS  key  Payload encryption key  Used for to encrypt payload. Only 128, 192 or 256 bits are  used for payload encryption.  Hash DRBG C and V  These are variables used internally by the Hash DRBG that  are required by Implementation Guidance 14.5 to be listed  in the Cryptographic Module Security Policy document.   User Password  Used to authenticate User to Craft Tool  Crypto Officer Password  Used to authenticate Crypto Officer to Craft Tool  Figure 25 Module Cryptographic Keys and CSPs      26 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    KEY  PURPOSE  TLS Certificate  Self‐generated and self‐signed certificate used to establish  TLS tunnel for HTTPS and WMTS ports for managing  remote radio.     Can use any of the following cipher suites to establish  tunnel:  TLS_RSA_WITH_AES_256_CBC_SHA  TLS_RSA_WITH_AES_128_CBC_SHA  TLS_RSA_WITH_Triple‐DES_EDE_CBC_SHA  Payload Encryption Certificate  Self‐generated and self‐signed certificate used to generate  payload encryption tunnel key.    The mechanism for exchanging the Payload Encryption key  is to create a TLS tunnel first and then transmit the  generated AES key to the remote end. For this we are  using a different self‐signed TLS certificate and secret key  from the HTTPS and WMTS TLS tunnel. The  TLS_RSA_WITH_AES_256_CBC_SHA cipher suite is used.  Integrity key  A fixed and hard coded key used in the firmware load  conditional self‐test  Figure 26 Module Public Keys        27 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    KEY  KEY  GENERATION/ESTABLISHMENT  STORAGE LOCATION  LENGTH/STRENGTH  TLS Private key  2048 bits RSA key  Generated by module  Non‐volatile memory  TLS tunnel key  128 or 256 bit  Key is generated by approved  RAM  depending on TLS  DRBG and then established using  cipher suite used  TLS  RADIUS shared  128 bits  Entered by Crypto Officer  RAM, Non‐volatile  secret  memory  SNMPv3 privacy  128 bits  Entered by Crypto Officer  RAM, Non‐volatile  password  memory  SNMPv3  128 bits  Entered by Crypto Officer  RAM, Non‐volatile  authentication  memory  password  Payload Encryption  2048 bits RSA key  Generated in module  Non‐volatile memory  RSA Private key  Payload Encryption  256 bits  Established using TLS. Generated  RAM  TLS tunnel key  Symmetric key   by module.  Payload encryption  up to 256 bits  Generated by module.  RAM  key  Hash DRBG “V” CSP  440 bits  Hash of entropy bits, nonce bits,  RAM  and personalization string  Hash DRBG “C” CSP  440 bits  Hash of “V”   RAM  User Password  5+ characters  N/A  Not persistently stored,  held in RAM until  authentication is  completed  Crypto Officer  5+ characters  N/A  Not persistently stored,  Password  held in RAM until  authentication is  completed  Figure 27 Key Table Part 1      28 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    KEY  ARE KEYS SUPPLIED  ENTRY/OUTPUT  DESTRUCTION  ENCRYPTED OR  PLAINTEXT?  TLS Private key  Plaintext  Generated in module,  Key is zeroized  not entered.  TLS tunnel key  Encrypted  Established using TLS  Key is zeroized  RADIUS shared secret  Encrypted  Entered by crypto officer  Key is overwritten. When the  through Craft tool  key is updated using portal,  the new key is transmitted  over TLS to the INU. The INU  zeroizes the existing key in  the encrypted key object.  The INU then stores the new  key in the encrypted key  object. This key is used in all  future requests to the  RADIUS server.  Encryption of the key is done  using AES‐128.  SNMPv3 privacy  Plaintext  Entered by crypto officer  Key is overwritten  password  through Craft tool  SNMPv3  Plaintext  Entered by crypto officer  Key is overwritten  authentication  through Craft tool  password  Payload Encryption  Plaintext  N/A  Key is overwritten  RSA Private key  Payload Encryption  Encrypted  Established using TLS  Key is zeroized  TLS tunnel key  Payload Encryption  Encrypted  Exchanged with peer  Key is zeroized  key  module using existing  TLS tunnel  Hash DRBG “V” CSP  Plaintext  N/A  Key is zeroized  Hash DRBG “C” CSP  Plaintext  N/A  Key is zeroized  User Password  N/A  Entered by User during  Not persistently stored.  Craft Tool operator  Zeroized once authentication  authentication  is complete  Crypto Officer  N/A  Entered by Crypto  Not persistently stored.  Password  Officer during Craft Tool  Zeroized once authentication  operator authentication  is complete  Figure 28 Key Table Part 2        29 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    KEY  KEY  GENERATION/ESTABLISHMENT  STORAGE LOCATION  LENGTH/STRENGTH  TLS Certificate  2048 bits RSA key  Generated by module  Non‐volatile memory.  Signed by MD5 with RSA  Payload Encryption  2048 bits RSA key  Derived from secret key  RAM  Certificate  Integrity key  2048 bit RSA key  Fixed key  Public integrity key will be  stored within the module.  The private key will not.  Figure 29 Public Key Table Part 1    KEY  ARE KEYS SUPPLIED  ENTRY/OUTPUT  DESTRUCTION  ENCRYPTED OR  PLAINTEXT?  TLS Certificate  Signed by RSA  Generated in module,  Key is not destroyed.  with SHA‐256  not entered.  Payload Encryption  Plaintext  Generated in module,  Key is overwritten  Certificate  not entered.  Integrity key  Plaintext  Fixed  Key is not destroyed  Figure 30 Public Key Table Part 2      2.7.4 CSP Destruction  All secret and private key material managed by the module can be zeroized using the key zeroization  service. This is a Crypto Officer service requiring Crypto Officer authentication. CSP zeroization is  performed procedurally and requires the Crypto Officer to enter zero values for the manually entered  CSPs (SNMPv3 passwords and RADIUS shared secret) and also perform the key zeroization service to  zeroize the other secret and private keys. A reboot of the module is required to complete the CSP  zeroization and the Crypto Office should remain in control of the module until the module self‐tests have  completed following the reboot.      30 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    2.7.5 Access to Key Material  The following table shows the access that an operator has to specific keys or other critical security  parameters when performing each of the services relevant to his/her role.    KEY  PAYLOAD ENCRYPTION RSA  SECRET KEY  SNMPV3 AUTHENTICATION PASSWORD  PAYLOAD ENCRYPTION SHARED SECRET    PAYLOAD ENCRYPTION CERTIFICATE      SNMPV3 PRIVACY PASSWORD  CRYPTO OFFICER PASSWORD    FIRMWARE INTEGRITY KEY  RADIUS SHARED SECRET    HASH DRBG “V” CSP  HASH DRBG “C” CSP    USER PASSWORD    TLS CERTIFICATE  TLS TUNNEL KEY  TLS SECRET  KEY  CA CERTIFICATE  CA PUBLIC KEY         User Services                                  View R  R  R                R            Configuration  Craft Tool R  R  R                R        X    Authentication  Crypto Officer                                  Services  Disable Payload  R  R  R                R            Encryption  Enable Payload  R  R  R                R            Encryption  Craft Tool  R  R  R                R          X  authentication  Firmware Upgrade                       r          Zeroize      W  W  W     W  W  W  W    W  W      Key Management            R R  R  R  W      X  X      (Payload  Encryption)  Key Management  R  R  R                R            (Secure  Management)  Module  R  R  R                            Configuration  SNMP v3        R,  R,W                        W      31 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  KEY  PAYLOAD ENCRYPTION RSA  SECRET KEY  SNMPV3 AUTHENTICATION PASSWORD  PAYLOAD ENCRYPTION SHARED SECRET    PAYLOAD ENCRYPTION CERTIFICATE      SNMPV3 PRIVACY PASSWORD  CRYPTO OFFICER PASSWORD    FIRMWARE INTEGRITY KEY  RADIUS SHARED SECRET    HASH DRBG “V” CSP  HASH DRBG “C” CSP    USER PASSWORD    TLS CERTIFICATE  TLS TUNNEL KEY  TLS SECRET  KEY  CA CERTIFICATE  CA PUBLIC KEY         RADIUS      R,                            W  View Status  R  R  R                R            Request  Unauthenticated                     X              Services  Payload                    X              Encryption  Payload                                  Decryption  Perform Self‐Tests                                  View Status                                  indicators  Figure 31 Access to Keys by Services  Access Rights    Blank  Not Applicable  R  Read  W  Write  X  Execute    Note: Key zeroization zeroizes all keys and CSPs; this is a “write” operation in that all keys are overwritten  with zeroes.  2.8 Self‐Tests  The module implements both power‐up and conditional self‐tests as required by FIPS 140‐2. The  following two sections outline the tests that are performed.      32 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com    2.8.1 Power‐up Self‐tests  OBJECT  TEST  SHA‐1  Known answer test  AES  Encrypt Known answer test   Decrypt Known answer test  (AES #2418)  AES  Encrypt Known answer test AES (Cert. #2260)  Triple‐DES  Encrypt Known answer test  Decrypt Known answer test  RSA  Known answer test (signature generation)  Known answer test (signature verification)  DRBG  SP800‐90 Hash‐based DRBG Known answer  test  Module firmware  Firmware Integrity Check using MD5 hash of  components  HMAC‐SHA‐1  Known answer test  SHA‐256  Known answer test  Figure 32 Power‐up Self‐tests  2.8.2 Conditional Self‐tests  EVENT  TEST  CONSEQUENCE OF FAILURE  Module requests a random  A continuous random number  Random number is not  number from the FIPS  generator test  generated and module enters  Approved SP800‐90 DRBG  an error state.  Entropy is supplied to the FIPS  A continuous random number  Entropy is not added and  approved SP800‐90 Hash‐ generator test on the entropy  module enters an error state  based DRBG  NDRNG  Firmware upgrade  Firmware load test – Approved  Firmware upgrade fails.  integrity technique using SHA‐ 256 and RSA.  Manual key entry test  Duplicate entries  Key not loaded  Asymmetric key pair  RSA Pairwise Consistency test  Key rejected and module enters  generated  an error state  RAC enters switches between  Exclusive Bypass test – two  RAC is disabled and no data is  a bypass mode and  independent actions are  passed.  cryptographic mode of  required to change mode  operation  (encrypted to bypass and vice  versa) and test the correct  operation of the services  providing cryptographic  processing when the switch      33 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  occurs  Figure 33 Conditional self‐tests    2.9 Design Assurance  Aviat Networks employ industry standard best practices in the design, development, production and  maintenance of the Aviat Networks Eclipse product, including the FIPS 140‐2 module.    Aviat Networks has an ISO 9001 Quality Management System.    This includes the use of an industry standard configuration management system that is operated in  accordance with the requirements of FIPS 140‐2, such that each configuration item that forms part of the  module is stored with a label corresponding to the version of the module and that the module and all of  its associated documentation can be regenerated from the configuration management system with  reference to the relevant version number.    Design documentation for the module is maintained to provide clear and consistent information within  the document hierarchy to enable transparent traceability between corresponding areas throughout the  document hierarchy, for instance, between elements of this Cryptographic Module Security Policy (CMSP)  and the design documentation.    Guidance appropriate to an operator’s Role is provided with the module and provides all of the necessary  assistance to enable the secure operation of the module by an operator, including the Approved security  functions of the module.    Delivery of the Cryptographic Module to customers from the vendor is via third party couriers. The  parcels are sealed in tamper evident packaging and each parcel is tracked from vendor to customer. Once  on site, the customer must follow vendor guidance to securely install and configure the module.  2.10 Mitigation of Other Attacks  The module does not mitigate any other attacks.        34 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  3 FIPS Mode of Operation  Once the module has been commissioned, the front panel of the module should be sealed, with no visible  gaps and tamper evident seals applied as described in section 2.5 above.    The module is set into FIPS mode as follows:    1.  Install FIPS capable NCC with CF card containing FIPS validated firmware  2.  Power up NCC  3.  Connect to NCC with Portal  4.  Install S/W license containing Strong Security, FIPS compliance, and optional Payload Encryption  5.  Set security mode to “FIPS”   6.  Select “Yes” when Portal asks for confirmation  7.  NCC reboots  8.  Connect to NCC using Portal  9.  Log in to NCC using a default Crypto Officer  10.  Configure desired security settings and add local users and/or RADIUS servers as required  11.  By default Payload Encryption is disabled, Bypass warning alarm raised against RAC  12.  Log in as a user with Crypto Officer permissions  13.  Perform other RAC and Payload Encryption configuration and enable Payload Encryption    The use of the Approved mode locks out the use of non‐approved algorithms.    For more details, please see the Eclipse User Manual Addendum for FIPS 140‐2.        35 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  Appendix A‐ RAC 60E/6XE Excluded Components  None of these components process plaintext CSPs or represent a threat of the unit being compromised  should they fail.  View 1    (Along Top of RAC Card) Ref    Part Number  Part Description Circuit J6    Connector (not fitted) FPGA 1/2 (SCH Sheet 8) ‐ Test Header  J4    Connector (not fitted) Master Modem 2/3 (SCH Sheet 12) ‐ Debug  Connector  R211    Resistor  Master Modem 2/3 (SCH Sheet 12) ‐ Debug  pull‐up  J5    Connector (not fitted) Master Modem 2/3 (SCH Sheet 12) ‐  BDM/JTAG Connector  U20  084‐397128‐001  IC, CPLD XC9572XL‐10VQ64I CPLD & JTAG Interface (SCH Sheet 5) ‐ Logic U40  083‐845385‐001  IC, BUFFER / LINE DRIVER CPLD & JTAG Interface (SCH Sheet 5) ‐ JTAG  Buffer  J7    Connector  CPLD & JTAG Interface (SCH Sheet 5) ‐ JTAG  Connector  C404    Capacitor  Master Modem 1/3 (SCH Sheet 11) ‐ 1.2V  Regulator  C405    Capacitor  Master Modem 1/3 (SCH Sheet 11) ‐ 1.2V  Regulator  U16  080‐417105‐001  IC, REGULATOR 1.2V, 800MA Master Modem 1/3 (SCH Sheet 11) ‐ 1.2V  Regulator  U26  080‐417089‐001  IC, 500 MA, 3.3 V, REGULATOR Master Modem 1/3 (SCH Sheet 11) ‐ 3.3V  Regulator  C39    Capacitor  Master Modem 1/3 (SCH Sheet 11) ‐ 3.3V  Regulator  C35    Capacitor  Master Modem 1/3 (SCH Sheet 11) ‐ 3.3V  Regulator  R192    Resistor  Master Modem 2/3 (SCH Sheet 12) ‐ Sys Clk  pull‐down  R195    Resistor  Master Modem 2/3 (SCH Sheet 12) ‐ Sys Clk  pull‐up  C49    Capacitor  Master IF Transceiver (SCH Sheet 17) ‐ 3.3V  Regulator  FB17  063‐501118‐001  6A BEAD INDUCTOR Master IF Transceiver (SCH Sheet 17) ‐ 3.3V  Regulator  U30  080‐417089‐001  IC, 500 MA, 3.3 VDC, Master IF Transceiver (SCH Sheet 17) ‐ 3.3V  REGULATOR  Regulator  C360    Capacitor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  R420    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  R422    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  R423    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  R425    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  R426    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF      36 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  Power R427    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  U35  081‐306311‐003  DUAL OPAMP LM2904 N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  R415    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  R416    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  R418    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  R419    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  R421    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  R424    Resistor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  C350    Capacitor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  L28  063‐312470‐720  IND,CHIP 47NH 2% 1008 N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  C353    Capacitor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  C354    Capacitor  N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  Power  U12  082‐433001‐001  IC, 2.5GHZ PWR DETECT N‐Plexer / ODU INTF (SCH Sheet 20) ‐ Tx IF  AD8361  Power  FL4  075‐501032‐001  N‐PLEXER, DC SURGE ARREST N‐Plexer / ODU INTF (SCH Sheet 20) ‐ N‐Plexer   View 2    (Along Bottom of RAC Card) Ref    Part Number  Part Description Circuit F1  027‐386008‐001  FUSE, 5A, SMT 125VAC/DC, FAST Power Regulation (SCH Sheet 3) ‐ ODU Power R7    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R8    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R30    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R31    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R32    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R33    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R34    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power C67    Capacitor  Power Regulation (SCH Sheet 3) ‐ ODU Power U33  081‐306311‐003  DUAL OPAMP LM2904 Power Regulation (SCH Sheet 3) ‐ ODU Power Amux and Telemetry (SCH Sheet 6) ‐ 48V  Monitor  R121    Resistor  Amux and Telemetry (SCH Sheet 6) ‐ 48V  Monitor  R10    Resistor  Amux and Telemetry (SCH Sheet 6) ‐ 48V  Monitor  R123    Resistor  Amux and Telemetry (SCH Sheet 6) ‐ 48V  Monitor  CR8  077‐313988‐001  D'L SWIT'G 70V/.25A BAV99  Amux and Telemetry (SCH Sheet 6) ‐ 48V  S023  Monitor      37 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.aviatnetworks.com  C27    Capacitor  Power Regulation (SCH Sheet 3) ‐ 1.2V  Regulator  C394    Capacitor  Power Regulation (SCH Sheet 3) ‐ 1.2V  Regulator  C396    Capacitor  Power Regulation (SCH Sheet 3) ‐ 1.2V  Regulator  C398    Capacitor  Power Regulation (SCH Sheet 3) ‐ 1.2V  Regulator  C399    Capacitor  Power Regulation (SCH Sheet 3) ‐ 1.2V  Regulator  FL2  075‐316592‐003  FILTER 6800PF 110V/10A SMT Power Regulation (SCH Sheet 3) ‐ 1.2V  Regulator  U18  080‐417118‐001  IC, 8A 4MHZ STEP‐DOWN REG Power Regulation (SCH Sheet 3) ‐ 1.2V  Regulator  C393    Capacitor  Power Regulation (SCH Sheet 3) ‐ 1.2V  Regulator  C401    Capacitor  Power Regulation (SCH Sheet 3) ‐ 1.2V  Regulator  U15  083‐845422‐002  IC, QAM XPIC MODEM,  Slave Modem (SCH Sheets 14 & 15) ‐ Modem PVG610X  U3  081‐302321‐001  DUAL OPAMP LMC6482 Master IF Transceiver (SCH Sheet 17) ‐ AGC Slave RX IF (SCH Sheet 18) ‐ AGC  U34    DUAL OPAMP  Slave RX IF (SCH Sheet 18) ‐ VCM  Slave RX IF (SCH Sheet 18) ‐ XPOL Alarm  C414    Capacitor  Slave RX IF (SCH Sheet 18) ‐ AGC  C415    Capacitor  Slave RX IF (SCH Sheet 18) ‐ AGC  R15    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R16    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R17    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R18    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R37    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power Q3  078‐362091‐002  XSTR GP PNP (2N)5401 Power Regulation (SCH Sheet 3) ‐ ODU Power Q11  078‐381091‐001  XSTR GP NPN (2N)5550 Power Regulation (SCH Sheet 3) ‐ ODU Power R38    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R39    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R40    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R41    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power C4    Capacitor  Power Regulation (SCH Sheet 3) ‐ ODU Power C63    Capacitor  Power Regulation (SCH Sheet 3) ‐ ODU Power C402    Capacitor  Power Regulation (SCH Sheet 3) ‐ ODU Power U8  081‐399558‐001  IC, ‐48V/2.5A HOT SWAP  Power Regulation (SCH Sheet 3) ‐ ODU Power CNTRLR  R14    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R44    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R45    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power R46    Resistor  Power Regulation (SCH Sheet 3) ‐ ODU Power Q2  078‐396196‐001  XSTR FET N‐CH IRF540NS,  Power Regulation (SCH Sheet 3) ‐ ODU Power D2PAK        38 © 2014 Aviat Networks, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.