Motorola GGM 8000 Gateway  FIPS 140‐2 Cryptographic Module Non‐Proprietary Security Policy    Version: 1.18  Date: 3/16/2016                                  Page 1 of 25    Table of Contents 1  Introduction .................................................................................................................... 4  1.1  Hardware and Physical Cryptographic Boundary ........................................................................ 6  1.2  Modes of Operation  .................................................................................................................... 7  . 2  Cryptographic Functionality ............................................................................................ 8  2.1  Critical Security Parameters  ...................................................................................................... 10  . 2.2  Public Keys ................................................................................................................................. 12  3  Roles, Authentication and Services  ............................................................................... 13  . 3.1  Assumption of Roles .................................................................................................................. 13  3.2  Authentication Methods ............................................................................................................ 14  3.3  Services ...................................................................................................................................... 14  4  Self‐tests ....................................................................................................................... 17  5  Physical Security Policy.................................................................................................. 18  6  Operational Environment .............................................................................................. 19  7  Mitigation of Other Attacks Policy ................................................................................. 19  8  Security Rules and Guidance ......................................................................................... 19  9  References and Definitions  ........................................................................................... 21  . 10  GGM 8000 GATEWAY TAMPER EVIDENCE LABEL INSTALLATION INSTRUCTIONS ........... 22        Page 2 of 25    List of Tables Table 1 – Cryptographic Module Configurations ...................................................................................................... 4  Table 2 – Security Level of Security Requirements ................................................................................................... 4  Table 3 – Ports and Interfaces ................................................................................................................................... 6  Table 4 – Approved and CAVP Validated Cryptographic Functions .......................................................................... 8  Table 5 – Non‐Approved but Allowed Cryptographic Functions ............................................................................... 9  Table 6 – Protocols Allowed in FIPS Mode ................................................................................................................ 9  Table 7 – Critical Security Parameters (CSPs) .......................................................................................................... 10  Table 8 – Public Keys ............................................................................................................................................... 12  Table 9 – Roles Description ..................................................................................................................................... 13  Table 10 – Authenticated Services .......................................................................................................................... 14  Table 11 – Unauthenticated Services ...................................................................................................................... 15  Table 12 – CSP Access Rights within Services .......................................................................................................... 16  Table 13 – Power Up Self‐tests  ............................................................................................................................... 17  . Table 14 – Conditional Self‐tests ............................................................................................................................. 18  Table 15 – References ............................................................................................................................................. 21  Table 16 – Acronyms and Definitions ...................................................................................................................... 21    List of Figures Figure 1 – Motorola GGM 8000 Gateway with Ports ................................................................................................ 6  Figure 2 – Applying Tamper Evidence Labels 1, 2, and 3 to Secure the GGM 8000 Base Unit (Base Module and  Blank Filler Panel in Expansion Module Slot  ........................................................................................................... 23  .     Page 3 of 25    1 Introduction   This document defines the Security Policy for the Motorola GGM 8000 Gateway, hereafter denoted the Module.  The  Module  is  a  modular  purpose‐built  gateway  that  can  easily  be  configured  to  support  a  variety  of  public  safety network applications. The Module meets FIPS 140‐2 overall Level 2 requirements.   Table 1 – Cryptographic Module Configurations    Module  HW P/N and Version  FW Version  1  GGM  8000  Base  CLN1841E Rev AB  KS 16.8.1.06  Unit  N/A  2  GGM  8000  AC  CLN1850A Rev G  Power  Supply  option  N/A  3  GGM  8000  DC  CLN1849A Rev H  Power  Supply  option  N/A  4  FIPS Kit  CLN8787A, Rev. B    The  Module  is  intended  for  use  by  US  Federal  agencies  and  other  markets  that  require  FIPS  140‐2  validated  network  appliances.  The  Module  is  a  multi‐chip  standalone  embodiment;  the  cryptographic  boundary  is  the  gateway’s enclosure which includes all components, and one of the power supply options (AC or DC) identified  in Table 1.  The FIPS 140‐2 security levels for the Module are as follows:  Table 2 – Security Level of Security Requirements  Security Requirement  Security Level  Cryptographic Module Specification  2  Cryptographic 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      Page 4 of 25    The Module implementation is compliant with:    FIPS 140‐2   FIPS 197   SP 800‐38A   SP 800‐90A   FIPS 198‐1   SP 800‐135   FIPS 186‐4   FIPS 180‐4   SP 800‐20      Page 5 of 25    1.1 Hardware and Physical Cryptographic Boundary  The physical cryptographic boundary of the Module is depicted in Figure 1. In the photo, there is a slot that can  hold  an  optional  expansion  module  for  increased  device  connectivity.  The  optional  expansion  module  is  not  included within the Motorola GGM 8000 Gateway cryptographic boundary.      AC Power Plug or DC Power Entry Connectors on rear of chassis LEDs T1/E1 Ports Ethernet Ports Backplane Interface (supports Expansion Module – not part of cryptographic boundary) Console Port   Figure 1 – Motorola GGM 8000 Gateway with Ports    Table 3 – Ports and Interfaces  Port  Description  Logical Interface Type  LAN  ports  that  provide  Control in | Data in | Data out | Status out  Ethernet (Qty. 4)  connection  to  Ethernet  LANs using either 10BASE‐ T,  100BASE‐TX,  or  1  Gigabit Ethernet  T1/E1  interfaces  that  Control in | Data in | Data out | Status out  T1/E1 (Qty. 2)  support T1/E1 CSU/DSU  RS‐232 interface  Console (Qty. 1)  Control in | Status out  High‐speed  multifunction  Control in | Data in | Data out | Status out  Backplane interface  serial  interfaces  that  Supports  expansion  provide  connection  to  module  containing  industry‐standard  V.35,  optional interface cards  Data  Communications  (expansion  module  not  Equipment  (DCE)  or  Data  part  of  cryptographic  Terminal Equipment (DTE)  boundary)  serial devices  AC power plug    Power    Page 6 of 25    Port  Description  Logical Interface Type  ‐OR‐  DC  power  entry  External  AC  power  input  Power  connectors (Qty. 1 or 2)  port    ‐OR‐  External  DC  power input ports  Provide Module status for  Status out  LEDs (Qty. 7)  traffic and module power.      1.2 Modes of Operation  The module supports both an Approved and non‐Approved mode of operation. To enter FIPS mode, the Crypto‐ Officer must follow the procedure outlined in Table 4 below. For details on individual gateway commands, use  the  online  help  facility  or  review  the  Enterprise  OS  Software  User  Guide  and  the  Enterprise  OS  Software  Reference Guide.  Step  Description  1.   Check if FIPS mode is enabled using the show –SYS FIPS command. If FIPS = ON, go to next step. If FIPS = OFF,  issue SETD ‐SYS FIPS=ON command.  2.   Configure  the  parameters  for  the  IKE  negotiations  using  the  IKEProfile command.  For  FIPS  mode,  only  the  following  values  are  allowed:  Diffie‐Hellman  Group  (Group  14  required  for  112‐bit  key  strength),  Encryption  Algorithm (AES or Triple‐DES), Hash Algorithm (SHA), and Authentication Method (PreSharedKey).  3.   Electronically establish via the local console port the pre‐shared key (PSK) to be used for the IKE protocol using: ADD –CRYPTO FipsPreSharedKey     For FIPS mode, minimum key length is 14 bytes.  4.   If  IPsec  is  used,  configure  IPsec  transform  lists  using  the  ADD  –CRYPTO  TransformLIst  command.  For  FIPS  mode, only the following values are allowed: Encryption Transform (ESP‐TDES, or ESP‐AES) and Authentication  Transform (ESP‐SHA).  5.   If FRF.17 is used, configure FRF.17 transform lists using the ADD –CRYPTO TransformLIst command. For FIPS  mode, only the following values are allowed: Encryption Transform (FRF‐TDES, or FRF‐AES) and Authentication  Transform (FRF‐SHA).  6.   For each port for which encryption is required, bind a dynamic policy to the ports using:   ADD [!] –CRYPTO DynamicPOLicy       [] [] []  To be in FIPS mode, the selector list and transform list names must be defined as in previous steps.  7.   If PIM authentication is enabled, configure Manual Key set using the ADD –CRYPTO ManKeySet command. For  FIPS mode, minimum authentication key length is 14 bytes.  8.   If SNMPv3 is enabled, configure authentication and encryption passphrases for all SNMP users with AuthPriv  privileges. For FIPS mode, minimum authentication passphrase length is 14 bytes.  9.   If SSHv2 is enabled, generate RSA 2048 bit keys using GenSshKey RSA 2048. 10.   For each port for which encryption is required, enable encryption on that port using:  SETDefault [!] –CRYPTO CONTrol = Enabled    Page 7 of 25    Step  Description  11.   DSA keys must not be used in FIPS mode.  12.   Use  the  Show  –SYS  SwSignatureAlgorithm command  to  verify  that  firmware  signing  algorithm  is  set  to  SHA2withRSA2048.  If  not  use  the  SetD  –SYS  SwSignAlgorithm  =  SHA2withRSA2048  command  to  change  signing algorithm.  13.   FIPS‐140‐2 mode achieved.      2 Cryptographic Functionality   The Module implements the FIPS Approved and Non‐Approved but Allowed cryptographic functions listed in the  table(s) below.   Table 4 – Approved and CAVP Validated Cryptographic Functions   Algorithm  Description  Cert #  AES (Hardware  [FIPS 197, SP 800‐38A]   962  Implementation)  Functions: Encryption, Decryption    Modes: ECB, CBC, CTR  Key sizes: 128, 256 bits  AES (Firmware  [FIPS 197, SP 800‐38A]   3547  Implementation)  Functions: Encryption, Decryption  Modes: ECB, CBC, CFB128  Key sizes: 128, 192 (CBC only), 256 bits (CBC only)  DRBG   [SP 800‐90A]  903    Functions: Hash DRBG  Security Strengths: 128 bits   HMAC (Hardware  [FIPS 198‐1]  1487  Implementation)  Functions: Generation, Verification    SHA sizes: SHA‐1  Key Size: 160 bits  HMAC (Firmware  [FIPS 198‐1]  2265,  Implementation)  2266  Functions: Generation, Verification    SHA sizes: SHA‐1, SHA‐256  Key Size: minimum 112 bits  KDF, Existing  [SP 800‐135]  603, 604,  Application‐ 605  Functions: SSH KDF, SNMP KDF, IKE v1 KDF, IKEv2 KDF  Specific (CVL)      Page 8 of 25    Algorithm  Description  Cert #  RSA   [FIPS 186‐4, PKCS #1 v2.1 (PKCS1.5)]  1827    Functions: Key Generation, Signature Generation, Signature Verification  Key sizes: 1024 (RSA Verify only), 2048 bits  SHA (Hardware  [FIPS 180‐4]  933  Implementation)  Functions: Message Digest    SHA sizes: SHA‐1    SHA (Firmware  [FIPS 180‐4]  2926  Implementation)  Functions: Digital Signature Generation, Digital Signature Verification,    non‐Digital Signature Applications  SHA sizes: SHA‐1, SHA‐256  Triple‐DES (TDEA)  [SP 800‐20]   757  (Hardware  Functions: Encryption, Decryption  Implementation)  Modes: TCBC    Key sizes: 3‐key  Triple‐DES (TDEA)  [SP 800‐20]   1986  (Firmware  Functions: Encryption, Decryption  Implementation)  Modes: TCBC    Key sizes: 3‐key    Table 5 – Non‐Approved but Allowed Cryptographic Functions  Algorithm  Description  Non‐SP 800‐56A  [IG D.8]  Compliant DH  Diffie‐Hellman (key agreement; key establishment methodology provides 112 bits of  encryption strength)  NDRNG  [Annex C]   Hardware  Non‐Deterministic  RNG;  minimum  of  256  bits  per  access.  The  NDRNG  output is used to seed the FIPS Approved DRBG.    Table 6 – Protocols Allowed in FIPS Mode  Protocol  Description  IKE v1  [IG D.8 and SP 800‐135]    Cipher Suites: Oakley Group 1,2, 5 and 14 DH key agreement with PreSharedKey  authentication, AES or Triple‐DES CBC encryption, SHA‐1 hashing, and HMAC PRF    Page 9 of 25    Protocol  Description  IKE v2  [IG D.8 and SP 800‐135]    Cipher Suites: Oakley Group 1,2,5 and 14 DH key agreement with PreSharedKey  authentication, AES or Triple‐DES CBC encryption, HMAC‐SHA‐1 integrity and PRF  SNMPv3  [IG D.8 and SP 800‐135]  Allowed only with the SP 800‐135 SNMP KDF and AES encryption/decryption  SSH v2  [IG D.8 and SP 800‐135]    Cipher Suites: RSA 2048 DH group 14 SHA‐1 key transport, AES CBC encryption,  HMAC‐SHA‐1 MAC  Note: these protocols have not been reviewed or tested by CMVP or CAVP  Non‐Approved Cryptographic Functions for use in non‐Approved mode only:    DES   Triple‐DES (2‐Key)   FIPS 186‐2 RSA Signature Generation: 4096 bit keys with SHA‐2   MD5   HMAC‐MD5   HMAC‐SHA‐1‐96   DSA 1024‐bit – for public/private key pair generation and digital signatures (non‐compliant)   RSA 1024 – for key transport within SSH v2   Non approved SW RNG: Provides random numbers for networking functions (non‐compliant)   Diffie‐Hellman Group 1, 2 and 5    2.1 Critical Security Parameters  All CSPs used by the Module are described in this section. All usage of these CSPs by the Module (including all  CSP lifecycle states) is described in the services detailed in Section 4.   Table 7 – Critical Security Parameters (CSPs)  CSP  Description / Usage  This  is  the  master  key  that  encrypts  persistent  CSPs  stored  within  the  KEK   module.   KEK‐protected keys include PSK and passwords.  Encryption of keys uses AES128ECB  IKE Preshared Keys  Used to authenticate peer to peer during IKE session  HMAC‐SHA‐1  (minimum  112  bit  key),  used  in  IKE  to  provide  for  SKEYID  authentication of peer router.  Generated  for  IKE  Phase  1  by  hashing  preshared  keys  with  responder/receiver nonce  SKEYID_d  Phase 1 key used to derive keying material for IKE SAs    Page 10 of 25    CSP  Description / Usage  SKEYID_a  Key used for integrity and authentication of the phase 1 exchange  SKEYID_e  Key used for Triple‐DES or AES data encryption of phase 1 exchange  SKEYSEED  Seed value is generated from initiator and responder nonce values and DH – pre‐shared key. Used in IKEv2 IKE_SA  SK_d  Key used to derive keying material for the CHILD_SAs established with IKEv2  IKE_SAs  Key used by initiator as a key to the integrity protection algorithm for  SK_ai  authenticating the component messages in IKEv2 IKE_SA  Key used by responder as a key to the integrity protection algorithm for  SK_ar  authenticating the component messages in IKEv2 IKE_SA  Key used by initiator for encrypting and decrypting all subsequent exchanges  SK_ei  in IKEv2 IKE_SA  SK_er  Key  used  by  responder  for  encrypting  and  decrypting  all  subsequent  exchanges in IKEv2 IKE_SA  SK_pi Key used by initiator when generating an AUTH payload in IKEv2 IKE_SA  SK_pr Key used by responder when generating an AUTH payload in IKEv2 IKE_SA  *Ephemeral DH Phase‐1  Generated for IKE Phase 1 key establishment   private key (a)  *Ephemeral DH Phase‐2  Phase 2 Diffie‐Hellman private keys used in PFS for key renewal  private key (a)  *IPsec Session Keys  128/192/256‐bit  AES‐CBC  and  168‐bit  Triple‐DES  keys  are  used  to  encrypt  and authenticate IPsec ESP packets  FRF.17 Session Keys  168‐bit  Triple‐DES‐CBC  and  128/192/256‐bit  AES‐CBC  keys  are  used  to  encrypt and authenticate FRF.17 Mode 2  *SSH‐RSA Private Key  Key used to authenticate oneself to peer   SSH Session Keys  128‐bit AES‐CBC keys are used to encrypt and authenticate SSH packets  *SSH DH Private Key  Generated for SSH key establishment   SNMPv3 Passphrases  Passphrases used in generation of SNMPv3 session keys  SNMPv3 Session Keys  128‐bit keys used to encrypt and authenticate SNMPv3 packets  RADIUS Secret  Used for authentication of packets sent/received to RADIUS Server, up to 32  characters.  Hash‐DRBG Seed  Initial seed for FIPS‐Approved DRBG  Hash‐DRBG Internal State  Internal  state/context  for  FIPS‐Approved  DRBG.  The  critical  security  parameters are the values V and C.    Page 11 of 25    CSP  Description / Usage  Passwords  7 (to 15) character password used to authenticate to the module   Crypto‐Officer  (Super User)   Network Manager   Admin   User    2.2 Public Keys  Table 8 – Public Keys  Key  Description / Usage  RSA Firmware Load Key   RSA 2048 bit key used for firmware authentication  SSH‐RSA Key  (RSA 2048‐bit) Distributed to peer, used for SSH authentication  SSH Known Host Keys  (RSA 1024 and 2048‐bit) Distributed to module, used to authenticate peer  IKE DH public key (g^a)  (2048‐bit) Generated for IKE Phase 1 key establishment  IKE  DH  phase‐2  public  (2048–bit) Phase 2 Diffie‐Hellman public keys used in PFS for key renewal (if  (g^a) key  configured)  SSH DH Key  (2048‐bit) Generated for SSH key establishment        Page 12 of 25    3 Roles, Authentication and Services   3.1 Assumption of Roles   The  module  supports  seven  distinct  operator  roles,  Cryptographic  Officer  (Super  User),  Admin,  Network  Manager,  User,  MotoAdmin,  MotoMaster,  and  MotoInformA/B.  The  cryptographic  module  enforces  the  separation of roles using Role‐based authentication.   Table  9  lists  all  operator  roles  supported  by  the  module.  The  Module  supports  concurrent  operators.  Each  operator  has  an  independent  session  with  the  gateway,  either  though  SSH  or  via  the  console.  Once  authenticated  to  a  role,  each  operator  can  access  only  those  services  for  that  role.  In  this  way,  separation  is  maintained between the role and services allowed for each operator.  Table 9 – Roles Description  Role ID  Role Description  Authentication Type  Authentication Data  Crypto‐Officer  The owner of the  Role‐based operator  Username and Password  (Super User)  cryptographic module with  authentication.  full access to services of  the module.   Network  An operator of the module  Role‐based operator  Username and Password  Manager (NM)  with almost full access to  authentication.  services of the module.  Admin  An assistant to the Crypto‐ Role‐based operator  Username and Password  Officer that has read only  authentication.  access to a subset of  module configuration and  status indications.  User  A user of the module that  Role‐based operator  Username and Password  has read only access to a  authentication.  subset of module  configuration and status  indications.  MotoAdmin  A SNMPv3 user who can  Role‐based operator  Passphrase  (MO)  issue any command from  authentication.  the SNMP V3 User  Manager menu.  MotoMaster  A SNMPv3 user who can  Role‐based operator  Passphrase  (MM)  change its own  authentication.  passphrases from the  SNMP V3 User Manager  menu.  MotoInformA/B  A SNMPv3 user who  Role‐based operator  Passphrase  (MI)  receives and transmits  authentication.  reliable messages over  SNMPv3.      Page 13 of 25      3.2 Authentication Methods   Username and Password  Passwords  are  alphanumeric  strings  consisting  of  7  to  15  characters  chosen  from  the  94  standard  keyboard  characters. The probability that a random attempt will succeed or a false acceptance will occur is 1/94^7 which  is less than 1/1,000,000. After three consecutive unsuccessful login attempts, an operator is locked out for two  minutes,  ensuring  that  that  the  probability  is  less  than  one  in  100,000  per  minute,  that  random  multiple  attempts will succeed or a false acceptance will occur.  Passphrase  Each  SNMPv3  user  has  its  own  pair  of  encryption  and  authentication  passphrases.  The  SNMPv3  user  authentication  or  encryption  passphrase  must  be  8‐64  characters  long  and  may  contain  uppercase  and  lowercase  alphabetic  characters  (A‐Z)  and  (a‐z);  numeric  characters  (0‐9);  and  any  of  the  following  special  characters (! “ % & ” ( ) * + , ‐ . /: ; < = > ?).  The probability that a random attempt will succeed or a false acceptance will occur is 1/81^8 which is less than  1/1,000,000. After three  consecutive  unsuccessful login attempts, the operator is locked  out for two  minutes.  The  resulting  probability  of  successfully  authenticating  to  the  module  within  one  minute  through  random  attempts is 3/81^8, which is less than 1/100,000.     3.3 Services  All services implemented by the Module are listed in the tables below. Each service description also describes all  usage of CSPs by the service.  Table 10 – Authenticated Services   Service  Description  CO  NM  Admin  User  MO  MM  MI  Firmware Update  Load  firmware  images  digitally  X  X            signed  by  RSA  (2048  bit)  algorithm  Key Entry  Enter Pre‐Shared Keys (PSK)  X  X            User  Add/Delete and manage operator  X  X            Management  passwords  Reboot  Force the module to power cycle  X  X            via a command  Zeroization  Actively destroy all plaintext CSPs  X  X            and keys  Crypto  Configure  IPsec  and  FRF.17  X  X            Configuration  services  IKE  Key  establishment  utilizing  the  X  X            IKE protocol  IPSec  Tunnel  IPsec protocol   X  X            Establishment    Page 14 of 25    Service  Description  CO  NM  Admin  User  MO  MM  MI  FRF.17  Tunnel  Frame Relay Privacy Protocol  X  X            Establishment  Alternating  Provide  some  services  with  X  X            Bypass  cryptographic  processing  and  some  services  without  cryptographic processing  SSHv2  For remote access to the gateway  X  X            Network  Configure networking capabilities  X  X            Configuration  SNMPv3  Network  management,  including  X  X      X  X  X  traps and configuration  Enable Ports  Apply a security policy to a port  X  X            File System  Access file system  X  X            Authenticated  Provide  status  to  an  X  X  X  X        Show Status  authenticated operator  Access Control  Provide access control for Crypto‐ X  X  X  X        Officer,  Network  Manager,  Admin, and User    Table 11 – Unauthenticated Services  Service  Description  Unauthenticated  Show  Provide  the  status  of  the  cryptographic  module  –  the  status  is  shown  using  Status  the LEDs on the front panel  Power‐up Self‐tests  Execute the suite of self‐tests required by FIPS 140‐2 during power‐up    All Services available in FIPS Approved mode are also available in FIPS Non‐Approved mode. The Approved mode  is defined by the correct configuration.  Table  12  defines  the  relationship  between  access  to  CSPs  and  the  different  module  services.  The  modes  of  access shown in the table are defined as:   G = Generate: The module generates the CSP.   R = Read: The module reads the CSP. The read access is typically performed before the module uses the  CSP.   E = Execute: The module executes using the CSP.   W = Write: The module writes the CSP. The write access is typically performed after a CSP is imported  into the module, when the module generates a CSP, or when the module overwrites an existing CSP.    Z = Zeroize: The module zeroizes the CSP.    Page 15 of 25    Table 12 – CSP Access Rights within Services  tunnel tunnel Show Network Configuration  Crypto Configuration  Alternating Bypass  User Management  Firmware Update  Access Control  Authenticated  establishment  establishment  Enable Ports  File System  Zeroization  Key entry  SNMPv3  Reboot  FRF.17  Status  SSHv2  IPsec  CSP  IKE   ‐ ‐ KEK  ‐  ‐  E  ‐  ‐  ‐  E  Z  GE  ‐  ‐  ‐  ‐  ‐  ‐  ‐ ‐ ‐  W  ‐  E  ‐  ‐  ‐  Z  RW  ‐  ‐  ‐  EW  E  ‐  IKE Pre‐shared Key  ‐ ‐ ‐  ‐  ‐  EG  ‐  ‐  Z  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SKEYID  ‐ ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SKEYID_d  ‐ ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SKEYID_a  ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SKEYID_e  ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  Z  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SKEYSEED  ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SK_d  ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SK_ai  ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SK_ar  ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SK_ei  ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SK_er  ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SK_pi  ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SK_pr  ‐ Ephemeral DH Phase‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  1 private key (a)  ‐ Ephemeral DH Phase‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  2 private key (a)  ‐ ‐  ‐  ‐  EG  E  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  IPsec Session Keys    Page 16 of 25    ‐ ‐  ‐  ‐  EG  ‐  E  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  FRF.17 Session Keys  ‐ ‐  ‐  ‐  ‐  ‐  ‐  EG  ‐  Z  EG  ‐  ‐  ‐  ‐  ‐  ‐  SSH‐RSA Private Key  ‐ ‐  ‐  ‐  ‐  ‐  ‐  EG  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SSH Session Keys  ‐ ‐  ‐  ‐  ‐  ‐  ‐  EG  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SSH DH Private Key  ‐ ‐  ‐  EW  ‐  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  E  Passwords  ‐  ‐  ‐  ‐  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  EW  RADIUS Secret  ‐  ‐  ‐  EW  ‐  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SNMPv3 Passphrase  E  ‐  ‐  ‐  ‐  ‐  ‐  ‐  ‐  ‐  ‐  ‐  ‐  ‐  ‐  ‐  ‐  SNMPv3 Session Keys  EGZ  ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  DRBG Seed  ‐ ‐  ‐  ‐  EG  ‐  ‐  ‐  ‐  Z  ‐  ‐  ‐  ‐  ‐  ‐  ‐  DRBG Internal State    4 Self‐tests  Each time the Module is powered up it tests that the cryptographic algorithms still operate correctly and that  sensitive  data  have  not  been  damaged.  Power  up  self–tests  are  available  on  demand  by  power  cycling  the  module.  On  power  up  or  reset,  the  Module  performs  the  self‐tests  described  in  Table  13  below.  All  KATs  must  be  completed  successfully  prior  to  any  other  use  of  cryptography  by  the  Module.  If  one  of  the  KATs  fails,  the  Module enters the error state. KAT failure is indicated by the Encryption LED being unlit when test fails. Device is  not able to power up if self‐test fails.  Table 13 – Power Up Self‐tests  Test Target  Description  Firmware  16 bit CRC performed over all code in flash  Integrity  AES (Hardware  KATs: Encryption, Decryption  implementation)  Modes: CBC    Key sizes: 128 bits  AES (Firmware  KATs: Encryption, Decryption  implementation)  Modes: ECB, CBC  Key sizes: 128, 192, 256 bits  DRBG   KATs: HASH DRBG    Security Strengths: 256 bits   HMAC  KATs: Generation, Verification  (Hardware  SHA sizes: SHA‐1  implementation)  Includes hardware SHA‐1 KAT  HMAC  KATs: Generation, Verification  (Firmware  SHA sizes: SHA‐1  implementation)    Page 17 of 25    Test Target  Description  RSA   KATs: Signature Generation, Signature Verification    Key sizes: 2048 bits  SHA   KATs: SHA‐1, SHA‐256  Triple‐DES  KATs: Encryption, Decryption  (Hardware  Modes: TCBC,   implementation)  Key sizes: 3‐key    Triple‐DES  KATs: Encryption, Decryption  (Firmware  Modes: TCBC,   implementation)  Key sizes: 3‐key      Table 14 – Conditional Self‐tests  Test Target  Description  NDRNG  NDRNG  Continuous  Test  performed  when  a  random  value  is  requested  from  the  NDRNG.  DRBG  DRBG Continuous Test performed when a random value is requested from the DRBG.  Firmware Load  RSA 2048 signature verification performed when firmware is loaded.  RSA Pairwise  Pair‐wise consistency test for public and private key generation (RSA)  Consistency  DRBG Health  Performed conditionally per SP 800‐90 Section 11.3. Required per IG C.1.  Checks  Bypass Test  Bypass Test performed when the service Alternating Bypass is called.    5 Physical Security Policy   The  Motorola  GGM  8000  Gateway  is  composed  of  industry  standard  production‐grade  components.  To  meet  FIPS 140‐2 Level 2 requirements, the Motorola GGM 8000 Gateway must have the three (there is a 4th seal that  is optional) tamper‐evident seals applied as described in Section 10. It is the responsibility of the Crypto‐Officer  to maintain the tamper seals. The seals should be inspected for evidence of tamper every three (3) months. If  evidence of tamper has been identified, the module should be considered compromised and Customer Service  should  be  contacted  for  further  instructions.  The  tamper  evident  seals  shall  be  installed  for  the  module  to  operate in a FIPS Approved mode of operation. Please see Section 10 for specific instructions on installation of  the tamper labels.    Note:  A FIPS label kit can be ordered by using part number CLN8787A, Rev. B.      Page 18 of 25    6 Operational Environment  The  Module is designated  as a limited  operational environment  under  the  FIPS 140‐2 definitions. The  Module  includes a firmware load service to support necessary updates. New firmware versions within the scope of this  validation must be validated through the FIPS 140‐2 CMVP. Any other firmware loaded into this module is out of  the scope of this validation and require a separate FIPS 140‐2 validation.    7 Mitigation of Other Attacks Policy  The Motorola GGM 8000 Gateway has not been designed to mitigate against other attacks outside the scope of  FIPS 140‐2.    8 Security Rules and Guidance  The  Module  design  corresponds  to  the  Module  security  rules.  This  section  documents  the  security  rules  enforced  by  the  cryptographic  module  to  implement  the  security  requirements  of  this  FIPS  140‐2  Level  2  module.  1. The  Motorola  GGM  8000  Gateway  provides  seven  distinct  operator  roles:  Crypto‐Officer  (Super  User),  Admin,  Network  Manager,  User,  MotoAdmin,  MotoMaster,  and  MotoInformA/B.  The  Crypto‐Officer  role  uses the Super User account.  2. The module shall provide role‐based authentication.  3. The module shall clear previous authentications on power cycle.   4. When  the  module  has  not  been  placed  in  a  valid  role,  the  operator  shall  not  have  access  to  any  cryptographic services.  5. The  operator  shall  be  capable  of  commanding  the  module  to  perform  the  power  up  self‐tests  by  cycling  power or resetting the module.   6. Power up self‐tests do not require any operator action.  7. Data output shall be inhibited during key generation, self‐tests, zeroization, and error states.  8. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the  module.  9. There are no restrictions on which keys or CSPs are zeroized by the zeroization service.  10. The module does not support a maintenance interface or role.  11. The module does not support manual key entry.  12. The module does not have any external input/output devices used for entry/output of data.  13. The module does not enter or output plaintext CSPs.  14. The module does not output intermediate key values.    The module is distributed to authorized operators wrapped in plastic with instructions on how to securely install  the module. On initial installation, perform the following steps:    Page 19 of 25    1. Power on the module and verify successful completion of power up self‐tests from console port or  inspection of log file. The following message will appear on the console interface:  “power‐on self‐tests  passed”.  2. Authenticate to the module using the default operator acting as the Crypto‐Officer with the default  password and username.  3. Verify that the Hardware and Firmware P/Ns and version numbers of the module are the FIPS Approved  versions.   4. Change the Crypto‐Officer and User passwords using the SysPassWord command.  5. Initialize the Key Encryption Key (KEK) with the KEKGenerate command. Account passwords and certain  keys are persistent across reboots and are encrypted with the Key Encryption Key (KEK). This key can be  reinitialized at any time.  6. Configure the module as described in Section 1.2.    The module supports a minimum password length of 7 characters and a maximum length of 15 characters. The  Crypto‐Officer  controls  the  minimum  password  length  through  the  PwMinLength  parameter:  SETDefault  ‐SYS  PwMinLength = , where  specifies the minimum length.  The Zeroization Service should also be invoked to zeroize all CSPs prior to removing a gateway from service for  repair.        Page 20 of 25    9 References and Definitions  The following standards are referred to in this Security Policy.  Table 15 – References  Abbreviation  Full Specification Name  [FIPS140‐2]  Security Requirements for Cryptographic Modules, May 25, 2001  [SP800‐131A]  Transitions: Recommendation for Transitioning the Use of Cryptographic Algorithms  and Key Lengths, January 2011    Table 16 – Acronyms and Definitions  Acronym  Definition  Advanced Encryption Standard  AES  CBC   Cipher Block Chaining  CLI  Command Line Interface  CSP  Critical Security Parameter  DRBG  Deterministic Random Bit Generator  DH  Diffie‐Hellman  FRF  Frame Relay Forum  FRF.17  Frame Relay Privacy Implementation Agreement  FRPP  Frame Relay Privacy Protocol  HMAC  Hash Message Authentication Code  Internet Key Exchange  IKE  IP  Internet Protocol  IPsec   Internet Protocol Security   KAT  Known Answer Test  KDF  Key Derivation Function  KEK  Key Encrypting Key  MNR  Motorola Network Router  OSPF  Open Shortest Path First  PFS  Perfect Forward Secrecy  PIM  Protocol Independent Multicast  RNG  Random Number Generator  SHA   Secure Hash Algorithm    Page 21 of 25    Acronym  Definition  Secure Shell  SSH  SNMP  Simple Network Management Protocol  Tanapa   The part number that is built and stocked for customer orders      10 GGM 8000 GATEWAY TAMPER EVIDENCE LABEL INSTALLATION INSTRUCTIONS      Follow these steps to install tamper evidence labels on the GGM 8000 gateway:    The  surface  to  which  the  labels  will  be  attached  must  be  at  a  temperature  of  at  least  +10°C  (+50°F),  and  the  surface must be clean and dry. Clean any grease, dirt, oil, or adhesive residue from the areas to which the labels  are to be attached before applying the tamper evidence labels. If you are replacing tamper evidence labels (after  a repair, for example), remove the old labels and any adhesive residue with isopropyl alcohol (99% concentration)  prior to applying the new labels.  Wipe the surface clean with isopropyl alcohol (99% concentration) to remove surface  1. contaminants. Please note that using a solution with an isopropyl alcohol concentration less than  99% is not acceptable.  Do not allow excess alcohol to air dry. Use a clean paper towel or cotton cloth to completely  2. remove any excess alcohol, thereby removing any residual contaminants.  Apply tamper evidence labels 1, 2, and 3 (optional) to secure the GGM 8000 base module and  3. blank filler panel on the front of the chassis.    Do not push labels 1, 2, and 3 all the way up under the top cover overhang or tuck the labels into the  gap between the front panel and the top cover overhang. As shown in Detail A in Figure 2 the labels  should come out at approximately a 45 degree angle from where they are affixed to the front panel  to where they wrap around and over the top cover.  Remove the Kraft liner from the back of label 1 and attach the label as illustrated in Figure  a. 2 (GGM 8000 base unit (base module and blank filler panel)) Center the silver portion of  the label between the rightmost cooling hole and the Encrypt, Run, Load, and Test LEDs,  with the Motorola logo on the label lined up with the top of the Load LED. Starting from  the short edge of the label that is positioned on the front panel, affix the label by applying  pressure while pushing the label up the front panel and onto the top cover.    Remove the Kraft liner from the back of label 2 and attach the label as illustrated in Figure  b. 2 (GGM 8000 base unit (base module and blank filler panel)). Position the Motorola logo  edge of the label directly above the top edge of connector “5B” with the left edge of the  clear portion of the label aligned with the edge of the thumbscrew. Starting from the short  edge of the label that is positioned on the front panel, affix the label by applying pressure  while pushing the label up the front panel and onto the top cover.    Note: Label 3 is optional and is not required for a FIPS‐approved configuration. The  additional tamper evidence label provides additional tamper evidence beyond the  module cryptographic boundary.    Remove the Kraft liner from the back of label 3 and attach the label as illustrated in  c.   Page 22 of 25    Figure 2.      Position  the  label  approximately  in  the  middle  of  the  blank  panel  with  the  perforation  between  the “T”  and the “O” aligned  with the edge of the top  cover.  Starting  from  the  short  edge of  the label  that  is positioned on  the  front panel, affix the label by applying  pressure while pushing the label up the front panel and onto the top cover.    Rub the labels on the front and top of the chassis for two (2) seconds to ensure that the  d. labels have adhered.    Figure 2 – Applying Tamper Evidence Labels 1, 2, and 3 to Secure the GGM 8000 Base Unit  (Base Module and Blank Filler Panel in Expansion Module Slot    If labels 1, 2, and 3 are applied correctly, the perforation between the “T” and the “O” aligns with the edge of the cover                                             See DET AIL A See DETAIL A   Do NOT tuck the label under the top cover overhang           DETAIL A   Page 23 of 25          Edge of silver portion Label 2 Label 3 Label 2 Label 1 of label               Edge of label aligns with with     of label aligns   top edge of connector “5B”   Edge of clear portion   top edge of connector "5B"   of label Edge of clear Edge of label portion of label aligns with edge of thumbscrew   Page 24 of 25      Apply tamper evidence label 4 to secure the GGM 8000 power supply module on the rear of the  4. chassis.  Note: These instructions apply to a GGM 8000 equipped with either an AC or a DC power supply  module.    Remove the Kraft liner from the back of the label and position the label as illustrated  a. in Figure 2.    Note: Figure 2 illustrates the label placement for the AC power supply module. The label  placement for the DC power supply module is the same.    Position the Motorola logo edge of  the label directly above the  mounting  screw, with  the right edge of the silver portion of the label aligned with the right edge of the power  supply module. Starting from the short edge of the label that is positioned on the rear  panel, affix the label by applying pressure while pushing the label up the rear panel and  onto the top cover.    Rub the label on the top and rear of the chassis for 2 seconds to ensure that the label  b. has adhered.    Secure the unit in a restricted area.  5.   Allow the applied labels to cure for at least 4 hours; do not touch the labels during this time.  6.     If you need to re‐apply the tamper evidence labels to the GGM 8000, repeat steps 1‐6.        Page 25 of 25