Security Policy: Key Variable  Loader (KVL) 4000 PIKE  Cryptographic module used in Motorola’s Key Variable Loader (KVL) 4000  keyloader.                  Version: R01.00.03 Date: August 2, 2010 Non-Proprietary Security Policy: KVL 4000 PIKE Page 1 of 23 Table of Contents 1. INTRODUCTION ............................................................................................................................................................... 3 1.1. SCOPE ............................................................................................................................................................................. 3 1.2. DEFINITIONS ................................................................................................................................................................ 3 1.3. OVERVIEW .................................................................................................................................................................... 4 1.4. KVL 4000 PIKE IMPLEMENTATION ....................................................................................................................... 4 1.5. KVL 4000 PIKE HARDWARE / FIRMWARE VERSION NUMBERS ................................................................... 4 1.6. KVL 4000 PIKE CRYPTOGRAPHIC BOUNDARY.................................................................................................. 4 1.7. PORTS AND INTERFACES ......................................................................................................................................... 5 2. FIPS 140-2 SECURITY LEVELS ...................................................................................................................................... 7 3. FIPS 140-2 APPROVED OPERATIONAL MODES ....................................................................................................... 8 3.1. CONFIGURATION SETTINGS FOR OPERATION AT FIPS 140-2 OVERALL SECURITY LEVEL 2........... 8 3.2. NON APPROVED MODE OF OPERATION.............................................................................................................. 8 4. CRYPTO OFFICER AND USER GUIDANCE.............................................................................................................. 10 4.1. ADMINISTRATION OF THE KVL 4000 PIKE IN A SECURE MANNER (CO) ................................................ 10 4.2. ASSUMPTIONS REGARDING USER BEHAVIOR (CO) ...................................................................................... 10 4.3. APPROVED SECURITY FUNCTIONS, PORTS, AND INTERFACES AVAILABLE TO USERS ................... 10 4.4. USER RESPONSIBILITIES NECESSARY FOR SECURE OPERATION ........................................................... 10 5. SECURITY RULES .......................................................................................................................................................... 11 5.1. FIPS 140-2 IMPOSED SECURITY RULES .............................................................................................................. 11 5.2. MOTOROLA IMPOSED SECURITY RULES ......................................................................................................... 13 6. IDENTIFICATION AND AUTHENTICATION POLICY ........................................................................................... 14 7. PHYSICAL SECURITY POLICY................................................................................................................................... 15 8. ACCESS CONTROL POLICY ........................................................................................................................................ 16 8.1. KVL 4000 PIKE SUPPORTED ROLES..................................................................................................................... 16 8.2. KVL 4000 PIKE SERVICES ....................................................................................................................................... 16 8.3. KEY MANAGEMENT ................................................................................................................................................. 17 8.4. CSP ACCESS TYPES .................................................................................................................................................. 19 9. MITIGATION OF OTHER ATTACKS POLICY ......................................................................................................... 23 Non-Proprietary Security Policy: KVL 4000 PIKE Page 2 of 23 1. Introduction 1.1. Scope This Security Policy specifies the security rules under which the Key Variable Loader (KVL) 4000 PIKE must operate. Included in these rules are those derived from the security requirements of FIPS 140-2 and those imposed additionally by Motorola. These rules, in total, define the interrelationship between the: 1. Module Operators, 2. Module Services, and 3. Critical Security Parameters (CSPs). 1.2. Definitions AES Advanced Encryption Standard CBC Cipher Block Chaining CFB Cipher Feedback CKR Common Key Reference CO Cryptographic Officer or Crypto-Officer CSP Critical Security Parameter DES Data Encryption Standard ECB Electronic Code Book ECDSA Elliptic Curve Digital Signature Algorithm FCK FIPS Cipher Key IC Integrated Circuit IV Initialization Vector KEK Key Encryption Key KPK Key Protection Key KPKEK KPK Encryption Key KVL Key Variable Loader MAC Message Authentication Code USB Universal Serial Bus OFB Output Feedback OTAR Over The Air Rekeying PDA Personal Digital Assistant RNG Random Number Generator SHA Secure Hash Algorithm TEK Traffic Encryption Key Non-Proprietary Security Policy: KVL 4000 PIKE Page 3 of 23 1.3. Overview The KVL 4000 PIKE provides security services for the KVL 4000. The KVL 4000 is a portable key distribution device that consists of a Personal Digital Assistant (PDA) and Security Adapter that connects to the PDA. The PIKE IC is embedded in the Security Adapter. Encryption keys can be transferred from a key management facility through its RS- 232 interface. These keys can then be distributed to various secure communications equipment such as mobile and portable radios, base stations, zone controllers, data controllers, and other fixed network devices. 1.4. KVL 4000 PIKE Implementation The KVL 4000 PIKE is implemented as a single-chip cryptographic module as defined by FIPS 140-2. 1.5. KVL 4000 PIKE Hardware / Firmware Version Numbers FIPS Validated Cryptographic FIPS Validated Cryptographic Module Hardware Kit Module Firmware Version Numbers Numbers 5175330H04 R01.00.00 The KVL 4000 PIKE supports the following FIPS Approved algorithms which may be installed separately from KVL 4000 PIKE firmware using the Program Update service. While the installation of AES may be done separately, for the purposes of this validation the module includes this firmware. Certificate Firmware Version Approved Algorithm Part Number Number Number AES-256 (ECB, CBC, OFB, 1401 5175330H04 R01.00.00 CFB-8) 1.6. KVL 4000 PIKE Cryptographic Boundary The KVL 4000 PIKE Cryptographic Boundary is drawn around the PIKE IC as shown below. Non-Proprietary Security Policy: KVL 4000 PIKE Page 4 of 23 Crypto Boundary Keyload MX Port 1.8 V Power RS- RS-232 KVL 4000 PIKE RS-232 Clock Port Clock PDA USB Port EBI Port GPIO Port Status External LED Flash Figure 1: The KVL 4000 PIKE in the block diagram above provides data security services required by the KVL 4000 key loader. The module is a single PIKE processor with the set of interfaces shown in the diagram above. The Crypto Boundary is drawn around the PIKE IC. 1.7. Ports and Interfaces The KVL 4000 PIKE provides the following physical ports and logical interfaces: Table 1: Ports and Interfaces Physical Port Qty Logical interface definition Description  Power 1 This interface powers all circuitry. Power Input  Data Input This is the interface to the PDA host software. Universal Serial  Data Output Bus (USB) 1  All CSPs exchanged over this interface are Control Input Interface always encrypted.  Status Output This is the interface to external devices.  Data Input  Keyload (MX) Data Output 1 All CSPs input over this interface are encrypted.  Interface Control Input The TEK and KEK can be output in either  Status Output plaintext or encrypted form. Provides an interface for factory programming  Data Input and execution of RS-232 shell commands.  Data Output RS-232 1  Interface All CSPs input over this interface are encrypted. Control Input The TEK and KEK can be output in either  Status Output plaintext or encrypted form. Non-Proprietary Security Policy: KVL 4000 PIKE Page 5 of 23 Physical Port Qty Logical interface definition Description The LED output turns flashing amber during self-tests and momentary solid green after self- tests are completed successfully.  LED Output 1 Status Output The LED output turns solid red upon entering a fatal error state.  IRQ/FIQ 3 External interrupts. Control Input  Clock 1 Clock Input. Control Input This is the interface to the external flash  Data Input memory on the KVL 4000 Security Adapter.  Data Output EBI Interface 1  Control Input All CSPs exchanged over this interface are  Status Output encrypted. Non-Proprietary Security Policy: KVL 4000 PIKE Page 6 of 23 2. FIPS 140-2 Security Levels The KVL 4000 PIKE 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 2: KVL 4000 PIKE Security Levels FIPS 140-2 Security Requirements Validated Level at Section overall Security Level 2 Cryptographic Module Specification 3 Module Ports and Interfaces 2 Roles, Services, and Authentication 3 Finite State Model 2 Physical Security 3 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: KVL 4000 PIKE Page 7 of 23 3. FIPS 140-2 Approved Operational Modes The KVL 4000 PIKE can be configured to operate in a FIPS 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. At any given time, the FIPS Status service can be used to determine whether the module is operating at overall Security Level 2 or in a non-FIPS Approved mode. 3.1. Configuration Settings for operation at FIPS 140-2 overall Security Level 2 Documented below are the actions and configuration settings required to enable FIPS 140-2 overall Security Level 2. 1. Enable User and Crypto-Officer passwords. 2. Enable FIPS 140-2 overall Security Level 2 by selecting Level 2 in the settings menu of the PDA graphical user interface. 3. Only Approved and Allowed algorithms installed. The module supports the following Approved algorithms:  AES-256 (Cert. #1401) –Used for encryption and decryption in the following Approved modes: OFB, ECB, CBC, and 8-bit CFB.  SHA-256 (Cert. #1272) – used for password hashing for internal password storage.  SHA-384 (Cert. #1272) – used for digital signature verification during software/firmware integrity test and software/firmware load test.  ECDSA-384 (FIPS 186-3, vendor affirmed) – used for digital signature verification during software/firmware integrity test and software/firmware load test  ANSI x9.31 RNG (Cert. #768) – used for IV and KPK generation The module supports the following Allowed algorithms:  AES MAC (Cert. #1401) – Used to provide authentication within APCO OTAR. AES MAC as used within APCO OTAR has been vendor affirmed and is allowed when used for Project 25 APCO OTAR.  AES Key Wrap (Cert. #1401) – Used for inner layer encryption within APCO OTAR. AES Key Wrap as used within APCO OTAR has been vendor affirmed and is allowed when used for Project 25 APCO OTAR.  Non-deterministic Hardware Random Number Generator – used to provide random numbers used as Initialization Vectors (IV) and the seeds for the Approved RNG 3.2. Non Approved Mode of Operation A non-FIPS Approved mode of operation is transitioned to when any of the following is true: 1. User and Crypto-Officer password have not been enabled. 2. FIPS 140-2 overall Security Level 2 has not been enabled. 3. The following non-Approved algorithms are installed:  DES-XL  DVP-XL Non-Proprietary Security Policy: KVL 4000 PIKE Page 8 of 23  DVI-XL  ADP  DES (OFB, ECB, and CBC modes) 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 Approved mode. The transition from a FIPS Approved mode to a non-FIPS Approved mode causes all CSP to be zeroized. Non-Proprietary Security Policy: KVL 4000 PIKE Page 9 of 23 4. Crypto Officer and User Guidance 4.1. Administration of the KVL 4000 PIKE in a secure manner (CO) The KVL 4000 PIKE 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 KVL 4000 PIKE 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 KVL 4000 PIKE services available to the User role are listed in section 8.2. No Physical Ports or Logical Interfaces are directly available to the KVL 4000 PIKE User, only indirectly through the KVL 4000 in which the module is installed. 4.4. User Responsibilities necessary for Secure Operation No special responsibilities are required of the User for secure operation of the KVL 4000 PIKE. Non-Proprietary Security Policy: KVL 4000 PIKE Page 10 of 23 5. Security Rules The KVL 4000 PIKE 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 KVL 4000 PIKE inhibits all data output via the data output interface whenever an error state exists and during self-tests. 2. The KVL 4000 PIKE logically disconnects the output data path from the circuitry and processes when performing key generation or key zeroization. 3. Authentication data (e.g. passwords) are entered in encrypted form. Authentication data is not output during entry. 4. The KVL 4000 PIKE enforces Identity-Based authentication. 5. The KVL 4000 PIKE supports a User role and a Crypto-Officer role. Authenticated operators are authorized to assume either supported role. 6. The KVL 4000 PIKE re-authenticates an operator when it is powered-up after being powered-off. The module also re-authenticates an operator upon expiration of the inactivity timer. The inactivity timer is user-configurable to 1, 3, or 5 minutes. 7. The KVL 4000 PIKE prevents brute-force attacks on its User and Crypto-Officer passwords by using a password that is a minimum of 15 ASCII printable characters in length. The probability of a successful random attempt is one in 463,291,230,159,753,366,058,349,609,375.  There are 95 ASCII printable characters; password is a minimum of 15 characters.  95 ^ 15 = 463,291,230,159,753,366,058,349,609,375 It would require 4,632,912,301,597,533,660,583,496 attempts in one minute to lower the random attempt success rate to less than 1 in 100,000. Each attempt takes at least 500 milliseconds. Therefore, a maximum of 120 attempts are possible during any one minute period. 8. The KVL 4000 PIKE uses ECDSA-384 to prevent brute-force attacks on the digital signature used to verify software/firmware integrity during a Program Update. 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. 9. Authentication data is not output during entry. 10. The KVL 4000 PIKE provides the following services requiring a role:  Program Update  Validate Crypto-Officer Password  Change Crypto-Officer password  Validate User Password  Change User password  Configure KVL  Extract Action Log  Version & Algorithm List Query  Logout  Transfer Key Variable Non-Proprietary Security Policy: KVL 4000 PIKE Page 11 of 23  Receive Key Variable  Generate Key Variable  Delete Key Variable  Edit Key Variable  Key Check  Zeroize Keys  Encrypt  Decrypt  Store & Forward  Reset Crypto Module Software 11. The KVL 4000 PIKE provides the following services not requiring a role:  FIPS Status  Perform Self Tests 12. The KVL 4000 PIKE implements all software using a high-level language, except the limited use of low-level languages to enhance performance. 13. The KVL 4000 PIKE protects secret keys and private keys from unauthorized disclosure, modification, and substitution. 14. The KVL 4000 PIKE 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 KVL 4000 PIKE is entered 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 of the fields to detect data corruption. 15. The KVL 4000 PIKE denies access to plaintext secret and private keys contained within the module. 16. The KVL 4000 PIKE provides the capability to zeroize all plaintext cryptographic keys and other unprotected critical security parameters within the module. 17. The KVL 4000 PIKE provides the following non-FIPS Approved Random Number Generators to provide random numbers used as Initialization Vectors (IV) and the seeds for the Approved RNG. - Non-deterministic Hardware Random Number Generator 18. The KVL 4000 PIKE conforms to FCC 47 Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class B requirements. 19. The KVL 4000 PIKE performs the following self-tests:  Power up and on-demand tests - Cryptographic algorithm test: Each algorithm (SHA-256, SHA-384, AES-256 in the OFB, CBC, ECB, 8-bit CFB, and Key Wrap 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. Non-Proprietary Security Policy: KVL 4000 PIKE Page 12 of 23 - 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. - Software/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 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 properly. Powering the module off then on will initiate the power-up and on-demand self tests.  Conditional tests - Software/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 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. 20. The KVL 4000 PIKE enters an error state if the Cryptographic Algorithm Test, Continuous Random Number Generator Test, or RNG KAT fails. This error state may be exited by powering the module off then on. 21. The KVL 4000 PIKE enters an error state if the Software/Firmware Integrity test fails. As soon as an error indicator is output via the status interface, the module transitions from the error state to a state that only allows new software to be loaded. 22. The KVL 4000 PIKE enters an error state if the Software/Firmware Load test fails. This error state may be exited by powering the module off then on which will start the download and validation process over. 23. The KVL 4000 PIKE outputs a status indicator via the LED Output interface to indicate all self-tests passed or when an error state is entered due to a failed self- test. 24. The KVL 4000 PIKE does not perform any cryptographic functions while in an error state. 5.2. Motorola Imposed Security Rules 1. The KVL 4000 PIKE does not support multiple concurrent operators. 2. All cryptographic module services are suspended during key loading. Non-Proprietary Security Policy: KVL 4000 PIKE Page 13 of 23 6. Identification and Authentication Policy The KVL 4000 PIKE supports a User and a Crypto-Officer role. The Crypto-Officer role is authenticated by a digital signature during the Program Update service and a password which is a minimum of 15 and maximum of 30 ASCII printable characters in length for the remaining Crypto-Officer services. The User role is authenticated by a password that is a minimum of 15 and a maximum of 30 ASCII printable characters in length. Both Crypto-Officer and User ID’s and passwords are initialized to a default value during manufacturing and are sent in encrypted form to the module for authentication. Role Authentication Type Authentication Data Required User Identity-Based User ID and 15-30 character ASCII Password Crypto-Officer Identity-Based ECDSA-384 digital signature for Program Update service; Crypto-Officer ID and 15-30 character ASCII Password for all other services Non-Proprietary Security Policy: KVL 4000 PIKE Page 14 of 23 7. Physical Security Policy The KVL 4000 PIKE is a production grade, single-chip cryptographic module as defined by FIPS 140-2 and is designed to meet Level 3 physical security requirements. The KVL 4000 PIKE is covered with a hard opaque epoxy coating that provides evidence of attempts to tamper with the module. The KVL 4000 PIKE does not contain any doors, removable covers, or ventilation holes or slits. No maintenance access interface is available. No special procedures are required to maintain physical security of the module while delivering to operators. Based on FIPS 140-2 Implementation Guidance (IG) 5.4, the security provided from the hardness of the module's epoxy encapsulate is claimed at ambient temperature (20 to 25 degrees Celsius) only. No assurance of the epoxy hardness is claimed for this physical security mechanism outside of this range. Non-Proprietary Security Policy: KVL 4000 PIKE Page 15 of 23 8. Access Control Policy 8.1. KVL 4000 PIKE Supported Roles The KVL 4000 PIKE supports two (2) roles. These roles are defined to be the:  User role and,  Cryptographic Officer (Crypto-Officer or CO) role. 8.2. KVL 4000 PIKE Services  Program Update: Update the module software. Software upgrades are authenticated using a digital signature. The Public Signature Validation Key (a 384 bit public ECDSA key) is used to validate the signature of the firmware image being loaded before it is allowed to be executed. All keys and CSPs are zeroized during a Program Update. To maintain validation, only validated software should be loaded. Loading non-validated software will invalidate the modules validation. Available to CO role.  Validate Crypto-Officer Password: Validate the current Crypto-Officer password used to identify and authenticate the Crypto-Officer role via the USB interface. Available to CO role.  Change Crypto-Officer Password: Modify the current password used to identify and authenticate the CO Role via USB interface. Available to CO role.  Validate User Password: Validate the current User password used to identify and authenticate the User role via the USB interface. Available to User role.  Change User Password: Modify the current password used to identify and authenticate the User Role via USB interface. Available to User and CO roles.  Configure KVL: Set configuration parameters used in Store and Forward protocols and other module-specific parameters over the USB interface. Available to User and CO roles.  Extract Action Log: Exports a history of actions over the RS-232 interface. Available to User and CO roles.  Version and Algorithm List Query: Provides module firmware version number and list of algorithms over the USB interface. Available to User and CO roles.  Logout: Logs out the operator. Available to User and CO roles.  Transfer Key Variable: Transfer key variables (KEKs, TEKs) to the target devices over the Keyload (MX) and RS-232 interfaces. Available to User and CO roles.  Receive Key Variable: Receive key variables (KEKs, TEKs) over the USB, Keyload (MX), and RS-232 interfaces. Available to User and CO roles.  Generate Key Variable: Auto-generate Keys (KEKs, TEKs) and KPK within the module. Available to CO role.  Delete Key Variable: Delete Keys (KEKs, TEKs) managed by the module. Available to CO role.  Edit Key Variable: Edit Keys (KEKs, TEKs) managed by the module. Available to CO role.  Key Check: Validate the correctness of a Key based on algorithm properties. Available to User and CO roles.  Zeroize Keys: Zeroize Keys in the KVL and target devices over the Keyload (MX) and RS-232 interfaces. Available to User and CO roles. Non-Proprietary Security Policy: KVL 4000 PIKE Page 16 of 23  Encrypt: Encrypt plaintext data to be transferred over the USB, Keyload (MX), RS-232, and EBI interfaces. Available to User and CO roles.  Decrypt: Decrypt ciphertext data received over the USB, Keyload (MX), RS-232, EBI interfaces. Available to User and CO roles.  Store and Forward (SAF): Modify and query the Key, SAF, and TTU Databases via SAF Key Management Messages. Available to User and CO roles.  Reset Crypto Module Software: Reset the databases and module parameters to system defaults via a command over the USB interface. Available to User and CO roles.  Perform 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 state. Available without a role.  FIPS Status: Provides current FIPS status about whether the module is operating at overall Security Level 2, or in a non-Approved mode of operation. Available without a role. 8.3. Key Management CSPs: The following table provides a list and description of all CSPs managed by the module. Table 3: 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 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 A 256-bit AES key used for encrypting keys output over (BKK) the MX and RS-232 ports. 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. FIPS Cipher Key (FCK) A 256-bit AES key used for decrypting keys and passwords entered into the module over the USB port. Stored in plaintext in non-volatile memory and zeroized through the Program Update service. The FCK is entered using the Program Update service and is not output from the module. Non-Proprietary Security Policy: KVL 4000 PIKE Page 17 of 23 CSP Identifier Description KPK Encryption Key A 256-bit AES key used to encrypt the KPK. Stored in (KPKEK) plaintext in non-volatile memory and zeroized through the Program Update service. The KPKEK 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. Key Encryption Keys 256-bit AES key used for encryption of keys in the Store (KEKs ) and Forward, and Transfer Key Variable services. KEKs are entered in encrypted form via the USB interface (encrypted with the FCK) and the Store and Forward service (encrypted with other TEKs and KEKs), and can also be generated internally. Stored in plaintext in RAM. At FIPS 140-2 overall Security Level 2 KEKs are output over the MX and RS-232 ports in plaintext form. KEKs output over the EBI and USB ports are encrypted with the KPK. Key Protection Key 256-bit AES key used to encrypt TEKs and KEKs output (KPK) over the EBI and USB ports. The KPK is generated internally by the ANSI X9.31 RNG and is not output from the module. Store in plaintext in volatile memory and encrypted with the KPKEK in non-volatile memory. Zeroized through the Program Update service. Crypto-Officer Password A minimum 15-character ASCII password entered encrypted on the FCK and used to authenticate the Crypto-Officer role. After decryption the plaintext password is not stored but temporarily exists in volatile memory. The SHA-256 hash of the decrypted password is compared with the hash value stored in non-volatile memory during password validation. The password is not output from the module. User Password A minimum 15-character ASCII password entered encrypted on the FCK and used to authenticate the User role. After decryption the plaintext password is not stored but temporarily exists in volatile memory. The SHA-256 hash of the decrypted password is compared with the hash value stored in non-volatile memory during password validation. The password is not output from the module. Non-Proprietary Security Policy: KVL 4000 PIKE Page 18 of 23 CSP Identifier Description Traffic Encryption Keys 256 bit AES key used for enabling secure communication (TEKs) in target devices. TEKs are entered in encrypted form via the USB interface (encrypted with the FCK) and the Store and Forward service (encrypted with other TEKs and KEKs), and can also be generated internally. TEKs are stored in plaintext in RAM. At FIPS 140-2 overall Security Level 2 TEKs are output over the MX and RS-232 ports in plaintext form. TEKs output over the EBI and USB ports are encrypted with the KPK. Public Keys: The following table lists and describes all Public Keys managed by the module. Table 4: Public Key Definition Public Key Name Description Public Signature 384-bit ECDSA key used to validate the signature of the Validation Key firmware image being programmed before it is allowed to be executed and is also used for authentication of the Crypto-Officer role. Loaded during manufacturing. The Public Signature Validation Key is not output from the module. 8.4. CSP Access Types Table 5: CSP Access Types CSP Access Type Description c - Check CSP Checks status of the CSP. d - Decrypt CSP Decrypts KEKs and TEKs retrieved over the EBI port using the KPK. Decrypts KEKs and TEKs retrieved over RS-232 using other KEKs and TEKs. Decrypts entered password & KEKs and TEKs using the FCK during CSP entry over the USB interface. e - Encrypt CSP Encrypts KEKs and TEKs prior to output over the EBI interface using the KPK. Encrypts KEKs, TEKs, and SEKs prior to output over the RS-232 interface using another KEK and SEK. g - Generate CSP Generates KPK, ANSI X9.31 seed, or ANSI X9.31 seed key. i - Invalidate CSP Marks encrypted TEKs or KEKs stored in non-volatile memory as invalid. TEKs or KEKs marked invalid can then be over-written when new TEKs or KEKs are stored. Non-Proprietary Security Policy: KVL 4000 PIKE Page 19 of 23 s - Store CSP Stores KPK in volatile and non-volatile memory. Stores plaintext BKK, FCK, or IDK in volatile and non- volatile memory. u - Use CSP Uses CSP internally for encryption / decryption services. z - Zeroize CSP Zeroizes CSP. Non-Proprietary Security Policy: KVL 4000 PIKE Page 20 of 23 Table 6: CSP versus CSP Access CSP Role Service BKK (Black Keyloading Key) IDK (Image Decryption Key) TEK (Traffic Encryption Key) KPKEK (Key Protection Key KPK (Key Protection Key) KEK (Key Encryption Key) Crypto-Officer Password FCK (FIPS Cipher Key) ANSI X9.31 seed key Crypto-Officer Role ANSI X9.31 seed No Role Required Encryption Key) User Password User Role u, 1. Program Update z,s z,s z z z,s z, s z √ z, s z 2. Validate Crypto-Officer d,g, d, s Password u, z √ d, 3. Change Crypto-Officer u, z, √ Password s d,g, d,u, 4. Validate User Password s z √ d,u, 5. Change User Password √ √ z,s c,d, c,d, c,d, c,d, 6. Configure KVL e,s, e,s, e,s, e,s, √ √ u,z u,z u,z u,z √ √ 7. Extract Action Log 8. Version & Algorithm List Query √ √ √ √ 9. Logout d,e, d,e, 10. Transfer Key Variable u u √ √ u u d,e, d,e, 11. Receive Key Variable u √ √ s,u s,u e,g, e,g, 12. Generate Key Variable u √ s s z z √ 13. Delete Key Variable d,s d,s u √ 14. Edit Key Variable c c √ √ 15. Key Check 16. Zeroize Keys (in target devices) √ √ u u u u u u u √ √ 17. Encrypt u u u u u u √ √ 18. Decrypt Non-Proprietary Security Policy: KVL 4000 PIKE Page 21 of 23 d,e, 19. Store & Forward s,u, d,u u √ √ z 20. Reset Crypto Module g, g, z,g, z z √ √ u, z u, z s software √ 21. Perform Self-Tests 22. FIPS Status √ Non-Proprietary Security Policy: KVL 4000 PIKE Page 22 of 23 9. Mitigation of Other Attacks Policy The KVL 4000 PIKE 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: KVL 4000 PIKE Page 23 of 23