Security Policy: IPCryptR2  Cryptographic module used in Motorola’s IPCryptR2 for Astro, Dimetra and WiMAX systems               Version: R01.00.10 Date: July 18, 2011 Non-Proprietary Security Policy: IPCryptR2 Page 1 of 24 Table of Contents 1.  INTRODUCTION ............................................................................................................................................................... 4  1.1.  SCOPE ............................................................................................................................................................................. 4  1.2.  DEFINITIONS ................................................................................................................................................................ 4  1.3.  OVERVIEW .................................................................................................................................................................... 4  1.4.  IPCRYPTR2 IMPLEMENTATION ............................................................................................................................. 4  1.5.  IPCRYPTR2 HARDWARE / FIRMWARE VERSION NUMBERS ......................................................................... 4  1.6.  IPCRYPTR2 CRYPTOGRAPHIC BOUNDARY ....................................................................................................... 5  1.7.  PORTS AND INTERFACES ......................................................................................................................................... 5  2.  FIPS 140-2 SECURITY LEVELS ...................................................................................................................................... 8  3.  FIPS 140-2 APPROVED OPERATIONAL MODES ....................................................................................................... 9  4.  CRYPTO OFFICER AND USER GUIDANCE.............................................................................................................. 11  4.1.  ADMINISTRATION OF THE IPCRYPTR2 IN A SECURE MANNER (CO) ...................................................... 11  4.2.  ASSUMPTIONS REGARDING USER BEHAVIOR (CO) ...................................................................................... 11  4.3.  APPROVED SECURITY FUNCTIONS, PORTS, AND INTERFACES AVAILABLE TO USERS ................... 11  4.4.  USER RESPONSIBILITIES NECESSARY FOR SECURE OPERATION ........................................................... 11  5.  SECURITY RULES .......................................................................................................................................................... 12  5.1.  FIPS 140-2 IMPOSED SECURITY RULES .............................................................................................................. 12  5.2.  MOTOROLA IMPOSED SECURITY RULES ......................................................................................................... 13  6.  IDENTIFICATION AND AUTHENTICATION POLICY ........................................................................................... 15  7.  PHYSICAL SECURITY POLICY................................................................................................................................... 17  8.  ACCESS CONTROL POLICY ........................................................................................................................................ 19  8.1.  IPCRYPTR2 SUPPORTED ROLES .......................................................................................................................... 19  8.2.  IPCRYPTR2 SERVICES AVAILABLE TO THE USER ROLE. ........................................................................... 19  8.3.  IPCRYPTR2 SERVICES AVAILABLE TO THE CRYPTO-OFFICER ROLE. .................................................. 19  8.4.  IPCRYPTR2 SERVICES AVAILABLE WITHOUT A ROLE. .............................................................................. 19  8.5.  CRITICAL SECURITY PARAMETERS (CSPS) AND PUBLIC KEYS ............................................................... 20  Non-Proprietary Security Policy: IPCryptR2 Page 2 of 24 8.6.  CSP ACCESS TYPES .................................................................................................................................................. 21  9.  MITIGATION OF OTHER ATTACKS POLICY ......................................................................................................... 24  Non-Proprietary Security Policy: IPCryptR2 Page 3 of 24 1. Introduction 1.1. Scope This Security Policy specifies the security rules under which the IPCryptR2 must operate. In addition to the security requirements derived from FIPS 140-2 are those imposed by Motorola. These rules, in total, define the interrelationship between the:  Module Operators,  Module Services, and  Critical Security Parameters (CSPs). 1.2. Definitions ALGID Algorithm Identifier CBC Cipher Block Chaining CFB Cipher Feedback CKR Common Key Reference CSP Critical Security Parameter DES Data Encryption Standard ECB Electronic Code Book ECDH Elliptic Curve Diffie-Hellman IKE Internet Key Exchange IPSec Internet Protocol security ISAKMP Internet Security Association and Key Management Protocol IV Initialization Vector KLK Key Loss Key KPK Key Protection Key KVL Key Variable Loader LED Light-emitting diode LFSR Linear Feedback Shift Register PEK Password Encryption Key RAM Random Access Memory RNG Random Number Generator 1.3. Overview The IPCryptR2 provides secure key management and data encryption in Astro, Dimetra and Broadband Systems. 1.4. IPCryptR2 Implementation The IPCryptR2 is implemented as a multi-chip standalone cryptographic module as defined by FIPS 140-2. 1.5. IPCryptR2 Hardware / Firmware Version Numbers The IPCryptR2 has the following FIPS validated hardware and firmware version numbers: Non-Proprietary Security Policy: IPCryptR2 Page 4 of 24 Table 1: FIPS Validated Version Numbers FIPS Validated Cryptographic FIPS Validated Cryptographic Module Hardware Kit Module Firmware Version Numbers Numbers BLN1306A R03.01.51 1.6. IPCryptR2 Cryptographic Boundary The IPCryptR2 cryptographic boundary is drawn around the entire product which includes the housing, various IC’s, FLASH, RAM, and Printed Circuit Board as shown below. Figure 1: IPCryptR2 Block Diagram 1.7. Ports and Interfaces The IPCryptR2 provides the following physical ports and logical interfaces: Table 2: Ports and Interfaces Logical Physical Qty Interface Description Port Definition Non-Proprietary Security Policy: IPCryptR2 Page 5 of 24 Logical Physical Qty Interface Description Port Definition This interface powers all circuitry. Power 1 Power Input This interface does not support input / output of CSPs. Provides an interface to the Key Variable Loader. KEKs and TEKs Key are entered in encrypted form over the KVL interface. Data Input Variable Data Output Loader 1 The hash of the boot block is output over the KVL interface if the Control Input (KVL) Firmware Integrity Test is successful on power up. Status Output Interface This interface does not support output of CSPs. Key Variable Loader 1 N/A This interface is not used by the module. (KVL) Auxiliary Interface Provides an interface for factory programming and execution of RS- Control Input RS-232 232 shell commands. 1 Status Output Interface Data Output This interface does not support output of CSPs. Mini- Universal Control Input Provides an interface for execution of RS-232 shell commands. Serial Bus 1 Status Output (mini-USB) Data Output This interface does not support output of CSPs. Interface This interface routes packets between subnets. The IP stack of this interface will use the subnet information to determine how to route packets between physical network interfaces. Data Input Ethernet Data Output 1 Only the public key from the ECDH pair is output over the Ethernet Interface Control Input port. Status Output This interface does not support any other input / output of CSPs. This interface is used for OTAR. Erase This interface is used for zeroization of KEKs, TEKs, KPK, ECDH 1 Control Input Switch private/public key pair, and IPSec Session keys. Reset 1 Control Input This interface forces a reset of the module. Switch The Alarm LED turns red to indicate a critical error has been Alarm LED 1 Status Output detected and flashing red to indicate a security condition has been detected that requires operator intervention. The Power LED turns steady green after power is applied and Power LED 1 Status Output flashing green to indicate a low or dead battery. The Ready LED turns steady green to indicate an Ethernet link has Ready LED 2 Status Output been established and is flashing green when there is activity on the Non-Proprietary Security Policy: IPCryptR2 Page 6 of 24 Logical Physical Qty Interface Description Port Definition link. TX Clear The TX Clear LED is not used and remains off other than during 1 Status Output LED power up self-test when the LED turns green. The Status LED is steady green when an IPSec tunnel has been established; steady red when no TEK has been loaded; and off when Status LED 1 Status Output a TEK has been loaded but an IPSec tunnel has not been established. Non-Proprietary Security Policy: IPCryptR2 Page 7 of 24 2. FIPS 140-2 Security Levels The IPCryptR2 can be configured to operate at FIPS 140-2 overall Security Level 2. The table below shows the FIPS 140-2 Level of security met for each of the eleven areas specified within the FIPS 140-2 security requirements. Table 3: IPCryptR2 Security Levels FIPS 140-2 Security Requirements Validated Level at Section overall Security Level 2 Cryptographic Module Specification 2 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 3 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks N/A Non-Proprietary Security Policy: IPCryptR2 Page 8 of 24 3. FIPS 140-2 Approved Operational Modes The IPCryptR2 can be configured to operate in a FIPS 140-2 Approved mode of operation and a non-FIPS Approved mode of operation. Documented below are the configuration settings that are required for the module to be used in a FIPS 140-2 Approved mode of operation at overall Security Level 2. 1. Enable FIPS mode. When FIPS mode is enabled, the module will not allow keys to be entered in plaintext form; all keys entered into the module must be encrypted. The Configure IPCryptR2 service is used to configure this parameter in the module via the ‘fips enable’ shell command. 2. Only Approved and Allowed algorithms installed. The module supports the following Approved algorithms:  AES-256 ECB (Cert. #1424)  AES-256 8-bit CFB (Cert. #1424) – for symmetric encryption / decryption of keys and parameters stored in the internal database.  AES-256 OFB (Cert. #1424) – for symmetric decryption of keys entered via the KVL interface.  AES-256 CBC (Cert. #1424) – for use with IKE and OTAR.  AES-256 GCM (Cert. #1425) – for high-speed encryption and authentication in the GCM mode.  SHA-384 (Cert. #1292) – used for password hashing for internal password storage, used for digital signature verification during firmware integrity test and firmware load test, and used as data origin authentication and integrity verification mechanisms for IKE.  ANSI x9.31 RNG (Cert. #778) – used for IV and KPK generation  ECDSA-384 (FIPS 186-3, vendor affirmed) – used for digital signature verification during firmware integrity test and firmware load test The following non-Approved algorithms and protocols are allowed within the Approved mode of operation:  AES MAC (AES Cert. #1424, vendor affirmed; P25 AES OTAR);  AES (Cert. #1424, key wrapping; key establishment methodology provides 256 bits of encryption strength)  EC Diffie-Hellman (vendor affirmed, key agreement; key establishment methodology provides 192 bits of encryption strength) – Asymmetric algorithms used for establishing secure private communication between two parties.  SNMPv3 (Cryptographic functionality does not meet FIPS requirements and is considered plaintext).  Maximal length 64-bit LFSR  Non-deterministic Hardware Random Number Generator – used to provide random numbers used as Initialization Vectors (IV) and the seeds for the Approved RNG The module maintains FIPS mode status and will provide this upon operator request. All functions that are available in FIPS Approved mode are also available in non-FIPS Approved mode. CSPs are not shared between FIPS Approved mode and non-FIPS Non-Proprietary Security Policy: IPCryptR2 Page 9 of 24 Approved mode. The transition from a FIPS Approved mode to a non-FIPS Approved mode causes all CSPs to be zeroized. Non-Proprietary Security Policy: IPCryptR2 Page 10 of 24 4. Crypto Officer and User Guidance 4.1. Administration of the IPCryptR2 in a secure manner (CO) The IPCryptR2 requires no special administration for secure use after it is set up for use in a FIPS Approved manner. To do this, configure the module as described in section 3 of this document. Note that all keys will be zeroized after the Program Update service has completed. 4.2. Assumptions regarding User Behavior (CO) The IPCryptR2 has been designed in such a way that no special assumptions regarding User Behavior have been made that are relevant to the secure operation of the unit. 4.3. Approved Security Functions, Ports, and Interfaces available to Users IPCryptR2 services available to the User role are listed in section 8.2. 4.4. User Responsibilities necessary for Secure Operation No special responsibilities are required of the User for secure operation of the IPCryptR2. Non-Proprietary Security Policy: IPCryptR2 Page 11 of 24 5. Security Rules The IPCryptR2 enforces the following security rules. These rules are separated into those imposed by FIPS 140-2 and those imposed by Motorola. 5.1. FIPS 140-2 Imposed Security Rules 1. The IPCryptR2 inhibits all data output via the data output interface whenever an error state exists and during self-tests. 2. The IPCryptR2 logically disconnects the output data path from the circuitry and processes when performing key generation or key zeroization. 3. Authentication data is not output during entry. 4. Secret cryptographic keys are entered in encrypted form over a physically separate port. 5. The IPCryptR2 enforces Role-Based authentication. Multiple concurrent operators are not supported. 6. The IPCryptR2 supports a User role and a Crypto-Officer role. The module will verify the authorization of the operator to assume each role. 7. The IPCryptR2 re-authenticates an operator when it is powered-up after being powered-off. 8. The IPCryptR2 implements all firmware using a high-level language, except the limited use of low-level languages to enhance performance. 9. The IPCryptR2 protects secret keys and private keys from unauthorized disclosure, modification and substitution. 10. The IPCryptR2 provides a means to ensure that a key entered into or stored within the module is associated with the correct entities to which the key is assigned. Each key in the IPCryptR2 is entered encrypted and stored with the following information:  Key Identifier – 16 bit identifier  Algorithm Identifier – 8 bit identifier  Key Type – Traffic Encryption Key or Key Encryption Key  Physical ID, Common Key Reference (CKR) number, and Keyset number – Identifiers indicating storage locations. Along with the encrypted key data, this information is stored in a key record that includes a CRC over all fields to protect against data corruption. When used or deleted the keys are referenced by CKR / Key ID / Algid, Key ID / Algid, Physical ID, or CKR / Keyset. 11. The IPCryptR2 denies access to plaintext secret and private keys contained within the module. 12. The IPCryptR2 provides the capability to zeroize all plaintext cryptographic keys and other unprotected critical security parameters within the module. 1. To completely initialize and zeroize the module: i. Utilize the Program Update service, and reset the module, to zeroize all module plaintext CSPs. 13. The IPCryptR2 conforms to FCC 47 Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B requirements. 14. The IPCryptR2 performs the following self-tests. Powering the module off then on or Non-Proprietary Security Policy: IPCryptR2 Page 12 of 24 resetting the module using the Reset service will initiate the power up self-tests.  Power up and on-demand tests - Cryptographic algorithm test: Each algorithm (SHA-384, and AES-256 in OFB, GCM, CBC, and 8-bit CFB modes) is tested by using a known key, known data, and if required a known IV. The data is then encrypted and compared with known encrypted data; the test passes if the final data matches the known data, otherwise it fails. The encrypted data is then decrypted and compared with the original plaintext; the test passes if the decrypted data matches the original plaintext, otherwise it fails. - RNG KAT test: the RNG is initialized with a known answer seed, DT counter and Triple-DES key. The RNG is run and the result compared to known answer data. The test passes if the generated data matches the known answer data, otherwise the test fails. - Firmware integrity test: A digital signature is generated over the code when it is built using SHA-384 and ECDSA-384 and is stored with the code upon download into the module. When the module is powered up the digital signature is verified. If the digital signature matches, then the test passes, otherwise it fails. - External indicators test: Upon every power up, the module will assert and de- assert each signal connected to an external indicator, so that the User may verify that the indicators are functioning and controlled by the module.  Conditional tests - Firmware load test: A digital signature is generated over the code when it is built using SHA-384 and ECDSA-384. Upon download into the module, the digital signature is verified. If the digital signature matches, then the test passes, otherwise it fails. - Continuous Random Number Generator test: The continuous random number generator test is performed on all RNGs supported by the module. For each RNG, an initial value is generated and stored upon power up. This value is not used for anything other than to initialize comparison data. A successive call to any one of the RNGs generates a new set of data, which is compared to the comparison data. If a match is detected, this test fails; otherwise the new data is stored as the comparison data and returned to the caller. 15. The IPCryptR2 enters the Critical Error state if the Cryptographic Algorithm Test, Continuous Random Number Generator Test, or RNG KAT fails. An error indicator is output by turning the Alarm LED red while in the Critical Error state. The Critical Error state may be exited by powering the module off then on. 16. The IPCryptR2 enters the Signature Validation Failure state if the Firmware Integrity test or Firmware Load test fails. A status message indicating success is not output over the status interface to indicate the Firmware Integrity test or Firmware Load test failed. While in this state the module will wait to be programmed and will not perform any other operations. 17. If all power up self-tests pass, the Alarm LED output will be clear. 18. The IPCryptR2 does not perform any cryptographic functions while in an error state. 5.2. Motorola Imposed Security Rules Non-Proprietary Security Policy: IPCryptR2 Page 13 of 24 1. The IPCryptR2 does not support multiple concurrent operators. 2. The module does not support the output of plaintext or encrypted secret or private keys. Non-Proprietary Security Policy: IPCryptR2 Page 14 of 24 6. Identification and Authentication Policy The IPCryptR2 supports a User role and a Crypto-Officer role. The Crypto-Officer role is authenticated by a digital signature during the Program Update service and a password for the remaining Crypto-Officer services. The Crypto-Officer password is initialized to a default value during manufacturing and is sent in encrypted form to the module for authentication. After authenticating, the Crypto-Officer password may be changed at any time. After a configurable number of consecutive invalid authentication attempts the KPK is zeroized, a new KPK is generated, all KEKs and TEKs are invalidated (key status is marked invalid), the password is reset to the factory default, and the module enters an error state that can only be cleared by power cycling the module. The User role is authenticated by a 256-bit AES key for the Transfer Key Variable and OTAR services and the ECDH public / private key pair for the Negotiate IPSec Session, Encrypt, and Decrypt services. Table 4: Roles and Authentication Role Authentication Authentication Strength of Authentication Type Mechanism Crypto- Role-Based ECDSA-384 digital The probability of a successful random Officer signature (192 bits of attempt is 1 in 2 ^ 192 or less than 1 in encryption strength) for 6e+57. Program Update service As the Program Update service requires more than one minute to complete, the random attempt success rate during a one minute period cannot be lowered to less than 1 in 100,000. Crypto- Role-Based 14-32 character ASCII Since the minimum password length is Officer password for all 14 ASCII printable characters and there Crypto-Officer services are 95 ASCII printable characters, the except Program probability of a successful random Update attempt is 1 in 95 ^ 14 or 1 in 4,876,749,791,155,298,590,087,890,62 5. The module limits the number of authentication attempts in one minute to 60. The probability of a successful random attempt during a one-minute period is 60 in 95 ^ 14 or 1 in 81,279,163,185,921,643,168,131,510. User Role-Based 256-bit AES Black The probability of a successful random Keyloading Key for attempt is 1 in 2 ^ 256 or less than 1 in Transfer Key Variable 1e+77. Non-Proprietary Security Policy: IPCryptR2 Page 15 of 24 Role Authentication Authentication Strength of Authentication Type Mechanism service Since it takes at least 1 sec per keyload, the probability of a successful random attempt during a one-minute period is 60 in 2 ^ 256 or less than 1 in 1.9e+75. User Role-Based 256-bit AES KEK for The probability of a successful random the OTAR service attempt is 1 in 2 ^ 256 or less than 1 in 1e+77. Since it takes at least 1 sec per OTAR operation, the probability of a successful random attempt during a one-minute period is 60 in 2 ^ 256 or less than 1 in 1.9e+75. User Role-Based 256-bit TEK for the The probability of a successful random Negotiate IPSec attempt is 1 in 2 ^ 256 or less than Session, Encrypt, and 1e+77.. Decrypt services Since it takes at least 1 sec to negotiate an IPSec session, the probability of a successful random attempt during a one-minute period is 60 in 2 ^ 256 or less than 1 in 1.9e+75. Non-Proprietary Security Policy: IPCryptR2 Page 16 of 24 7. Physical Security Policy The IPCryptR2 is a production grade, multi-chip standalone cryptographic module as defined by FIPS 140-2 and is designed to meet level 2 physical security requirements. The IPCryptR2 is entirely contained within a hard plastic production-grade removable enclosure. The IPCryptR2 enclosure is opaque within the visible spectrum. The removable cover is protected with tamper-evident tape. The tamper-evident tape is visible on both side of the enclosure exterior. Two tamper labels are installed during manufacturing and should be checked periodically by the user for signs of tamper. No maintenance access interface is available. Figure 2: IPCryptR2 (Top/Front/Right) Figure 3: IPCryptR2 (Underside/Rear/Left) Non-Proprietary Security Policy: IPCryptR2 Page 17 of 24 Figure 4: Right Side Tamper Seal Placement Figure 5: Left Side Tamper Seal Placement Non-Proprietary Security Policy: IPCryptR2 Page 18 of 24 8. Access Control Policy 8.1. IPCryptR2 Supported Roles The IPCryptR2 supports two (2) roles. These roles are defined to be the:  User Role and,  Crypto-Officer Role. 8.2. IPCryptR2 Services Available to the User Role.  Transfer Key Variable: Transfer key variables (KEKs and TEKs) to the key database via the KVL interface.  Negotiate IPSec session: establish an IPSec tunnel via the Ethernet port.  Encrypt: Encrypt plaintext data received over the Ethernet port.  Decrypt: Decrypt ciphertext data received over the Ethernet port.  OTAR: Modify, query, and zeroize the Key Database via OTAR Key Management Messages. 8.3. IPCryptR2 Services Available to the Crypto-Officer Role.  Program Update: Update the module firmware via the KVL interface. Firmware upgrades are authenticated using a digital signature. All keys and CSPs are zeroized on initiating Program Update.  Validate Crypto-Officer Password: Validate the current Crypto-Officer password used to identify and authenticate the Crypto-Officer role via the shell. Successful authentication will allow entrance to the shell command interface and access to the shell command services.  Change Crypto-Officer Password: Modify the current password used to identify and authenticate the Crypto-Officer Role via a shell command.  Configure IPCryptR2: Set ISAKMP, IKE, and general configuration parameters via a shell command.  Extract Error Log: Status request via a shell command. Provides detailed history of error events.  Tunnel config: Provides the configuration for IKE via a shell command.  Version Query: Provides module firmware and hardware version numbers via a shell command.  Shell Help: Shell command to get help on the format of other shell commands.  Exit Shell: Exits the shell command interface and logs out of the Crypto-Officer role. 8.4. IPCryptR2 Services Available Without a Role.  DHCP: Used for automation of network parameters. This service does not access any CSPs or other security relevant functionality.  Key Check: Obtain status information about a specific KEK or TEK via the KVL interface.  Reset Crypto Module: Toggle the Reset input or a transition from power off to power on state.  Initiate Self-Tests: Performs module self-tests comprised of cryptographic algorithms test and firmware test. Initiated by module reset or transition from power off state to power on Non-Proprietary Security Policy: IPCryptR2 Page 19 of 24 state.  Invalidate Keys Via KVL: Invalidate KEKs and TEKs from the key database via the KVL interface.  Zeroize All Keys: Invalidate KEKs and TEKs and zeroizes KPK, ECDH private/public key pair, and IPSec Session keys via the Erase switch. 8.5. Critical Security Parameters (CSPs) and Public Keys Table 5: CSP Definition CSP Identifier Description ANSI X9.31 seed A 64-bit seed value used within the ANSI X9.31 RNG. The seed is not stored but temporarily exists in volatile memory and is zeroized by power cycling the module. The seed is not entered into or output from the module. ANSI X9.31 seed key This is a 128 bit TDES Key used to seed the ANSI X9.31 RNG during initialization. The seed key is not stored but temporarily exists in volatile memory and is zeroized by power cycling the module. The seed key is not entered into or output from the module. Black Keyloading Key 256 bit AES Key used for decrypting keys entered into the (BKK) module via a KVL. Stored in plaintext in non-volatile memory and zeroized through the Program Update service. The BKK is entered using the Program Update service and is not output from the module. Image Decryption Key A 256-bit AES key used to decrypt downloaded images. (IDK) Stored in plaintext in non-volatile memory and zeroized through the Program Update service. The IDK is entered using the Program Update service and is not output from the module. Traffic Encryption Key 256 bit IKE Pre-Shared Keys used for IKE authentication and OTAR. TEKs are entered in encrypted form via the KVL and (TEK) via OTAR. TEKs entered via the KVL are wrapped with the BKK; TEKs received via OTAR are encrypted on a KEK. Stored in plaintext in RAM and encrypted by the KPK in flash. TEKs are not output from the module. Key Encryption Keys 256 bit AES Keys used for encryption of keys in OTAR. KEKs (KEKs) are entered in encrypted form via the KVL and via OTAR. KEKs entered via the KVL are wrapped with the BKK; KEKs received via OTAR are encrypted on another KEK. Stored in plaintext in RAM and encrypted by the KPK in flash. KEKs are not output from the module. Randomly generated internally by IKE. Used in elliptic curve Elliptic Curve Diffie- public-private key pair, to establish a shared secret over an Hellman Private value insecure channel. Stored in volatile memory. The Elliptic Curve Diffie-Hellman Private value is not entered into or output from the module. 256 bit AES-GCM Key generated internally by IKE and used for IPSec Session Keys data encryption. Stored in volatile memory. The IPSec Session Non-Proprietary Security Policy: IPCryptR2 Page 20 of 24 CSP Identifier Description Keys are not entered into or output from the module. Key Protection Key (KPK) 256 bit AES key used to encrypt TEKs and KEKs for storage in non-volatile memory. Generated internally by the ANSI X9.31 RNG. Stored in battery-backed RAM. The KPK is not entered into or output from the module. Password Encryption Key 256 bit AES Key used for decrypting passwords during (PEK) password validation. Loaded via the Program Update service. Stored in plaintext in non-volatile memory and zeroized through the Program Update service. The PEK is entered using the Program Update service and is not output from the module. Crypto-Officer Password The Crypto-Officer password (14-32 ASCII printable characters in length) is entered encrypted on the PEK. After decryption the plaintext password is not stored but temporarily exists in volatile memory. The SHA-384 hash of the decrypted password is compared with the hash value stored in non- volatile memory during password validation. The Crypto- Officer Password is entered encrypted with the PEK and is not output from the module. Table 6: Public Keys Key Description Public Programmed 384 bit ECDSA key used to validate the signature of the Signature Key firmware image being loaded before it is allowed to be executed. Stored in non-volatile memory. Loaded during manufacturing and as part of the boot image during a Program Update service. The Public Programmed Signature Key is not output from the module. Elliptic Curve Diffie-Hellman Randomly generated Internally by IKE. Used in elliptic curve public-private key pair, to establish a shared secret over an Public value insecure channel. Stored in volatile memory. The Elliptic Curve Diffie-Hellman Public value is generated internally and is output as part of the Diffie-Hellman key agreement protocol. 8.6. CSP Access Types Table 7: CSP Access Types CSP Access Type Description c – Check CSP Checks status and key identifier information of key. D – Decrypt CSP Decrypts KEKs and TEKs retrieved from volatile memory using the KPK. Decrypts KEKs and TEKs entered via the KVL using the Black Keyloading Key. Non-Proprietary Security Policy: IPCryptR2 Page 21 of 24 CSP Access Type Description Decrypts KEKs entered via OTAR using other KEKs. Decrypts entered password with PEK during password validation. E – Encrypt CSP Encrypts KEKs and TEKs with KPK prior to storage in volatile memory. G – Generate CSP Generates KPK, ANSI X9.31 seed, ANSI X9.31 seed key, IPSec Session keys, or Elliptic Curve Diffie-Hellman private key. I – Invalidate CSP Marks encrypted KEKs and TEKs stored in volatile memory as invalid. KEKs and TEKs marked invalid can then be over- written when new KEKs and/or TEKs are stored. S – Store CSP Stores KPK in volatile memory. Stores encrypted KEKs and TEKs in non-volatile memory, over- writing any previously invalidated KEK or TEK in that location. Stores plaintext Private/Public Elliptic Curve Diffie-Hellman values and IPSec Session Keys in volatile memory. Stores plaintext BKK, PEK, or IDK in non-volatile memory. U – Use CSP Uses CSP internally for encryption / decryption services. Z – Zeroize CSP Zeroizes CSP. Non-Proprietary Security Policy: IPCryptR2 Page 22 of 24 Table 8: CSP versus CSP Access CSP Role PEK (Password Encryption Key TEK (Traffic Encryption Keys) ECDH Private / Public key BKK (Black Keyloading Key) IDK (Image Decryption Key) KEK (Key Encryption Keys) KPK (Key Protection Key) Crypto-Officer Password ANSI X9.31 seed key IPSec Session Keys Crypto-Officer Role No Role Required ANSI X9.31 seed Service User Role pair u, 1. Program Update z z z z z z,s z, s √ z, s 2. Validate Crypto- z, i i u g, s d, u, z √ Officer Password z, 3. Change Crypto- i i u √ g, s Officer Password d, u, z 4. Configure √ IPCryptR2 √ 5. Extract Error Log √ 6. Tunnel config √ 7. Version Query √ 8. Shell Help √ 9. Exit Shell d, i, d, i, 10. Transfer Key e, e, u u √ Variable z, s z, s g, 11. Negotiate IPSec g, s √ s, u sessions d u u √ 12. Encrypt d u u √ 13. Decrypt d, d, 14. OTAR u, i, u, i, u u √ e, e, z, s z, s √ √ √ 15. DHCP c c √ 16. Key Check √ √ 17. Reset Crypto g, g, u, g, s √ √ √ u, z z Module √ √ √ 18. Perform Self-Tests 19. Invalidate Keys Via i i KVL √ √ √ z, 20. Zeroize All Keys i i z z g, s √ √ √ Non-Proprietary Security Policy: IPCryptR2 Page 23 of 24 9. Mitigation of Other Attacks Policy The IPCryptR2 is not designed to mitigate any specific attacks outside of those required by FIPS 140-2, including but not limited to power consumption, timing, fault induction, or TEMPEST attacks. Non-Proprietary Security Policy: IPCryptR2 Page 24 of 24