3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy 3e Technologies International, Inc. FIPS 140-2 Non-Proprietary Security Policy Level 2 Validation 3e-636M CyberFence Cryptographic Module HW Version (1.0) FW Version (5.1) Security Policy Version 4.0 July 2014 Copyright ©2014 by 3e Technologies International. This document may freely be reproduced and distributed in its entirety. i 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy Revision History Date Document Description Author(s) Version 14-May-2013 1.0 For External Release Chris Guo 31-Oct-2013 2.0 Revision Chris Guo 25-Apr-2014 3.0 Revision Chris Guo 13-June-2014 4.0 Revision Chris Guo ii 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy Table of Contents Revision History ............................................................................................................................. ii Table of Contents ........................................................................................................................... iii 1. Introduction ............................................................................................................................. 1 1.1 Cryptographic Module Definition ................................................................................................. 1 1.2 Cryptographic Module Validation ................................................................................................. 2 2. Ports & Interfaces ................................................................................................................... 2 3. Roles & services ..................................................................................................................... 3 3.1 End User role ............................................................................................................................... 4 3.2 Crypto Officer and Administrator Roles ....................................................................................... 4 4. Operational Environment ........................................................................................................ 6 5. Cryptographic Algorithms ...................................................................................................... 6 6. Cryptographic Keys and SRDIs .............................................................................................. 7 7. Self-Tests .............................................................................................................................. 10 8. Tamper Evidence .................................................................................................................. 11 9. Secure Rules & Configuration .............................................................................................. 12 10. Design Assurance.............................................................................................................. 13 11. Mitigation of Other Attack................................................................................................ 13 iii 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy 1. Introduction This is a non-proprietary Cryptographic Module Security Policy for the 3e-636M CyberFence Cryptographic Module from 3e Technologies International. This Security Policy describes how the 3e-636M meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-2, which details the U.S. and Canadian Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) and the Communications Security Establishment Canada (CSEC) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/groups/STM/cmvp 1.1 Cryptographic Module Definition The 3e-636M Crypto Module primarily acts as a boundary protection device. Using IPSec based VPN technology; it sets up secured channel between a local area network and the wider network. Furthermore, it employs firewall and packet inspection to provide defense-in-depth capabilities to prevent malicious attacks. The crypto module includes one FreeScale PowQUICC 8378E processor as a multi-function host processor, network processor, and cryptographic processor. The cryptographic module consists of electronic hardware, embedded firmware and enclosure. It is a multiple-chip embedded module for the purposes of FIPS 140-2. Figure 1 below shows the picture of the 3e-636M Crypto Module: Figure 1 – 3e-636M Crypto Module The critical circuits of the 3e-636M Crypto Module are enclosed in a tamper-resistant opaque metal enclosure, protected by tamper evidence tape intended to provide physical security. There is only one operational mode for the device which is FIPS mode. The module’s cryptographic boundary is the metal enclosure. The components attached to the underside of the PCB and the 1 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy components (RTC, reset delay chip, logic gates, and resistors, underside of chip pads, impedance beads and capacitors) which reside outside of the protective “can” of the module are excluded from FIPS requirements. 1.2 Cryptographic Module Validation The module is validated at the FIPS 140-2 Section levels listed in Table 1 below. The overall security level of the module is 2. Section Section Title Level Cryptographic Module 1 2 Specification Cryptographic Module Ports and 2 2 Interfaces Roles, Services, and 3 3 Authentication Finite State Model 4 2 Physical Security 5 2 Operational Environment 6 N/A Cryptographic Key Management 7 2 EMI/EMC11 8 2 Self-tests 9 2 Design Assurance 10 3 Mitigation of Other Attacks 11 N/A Table 1: Module Security Level 2. Ports & Interfaces The 3e-636M Crypto Module contains a simple set of interfaces, as shown in the Figure 2 below: 2 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy RGMII G-bit Enet PHY Configuration EEPROM Ethernet SGMII Interface Real Time RGMII Header G-bit Enet Clock PHY Random SGMII Noise Generator Freescale MPC8378E Local Bus GPIO Flash Memory Power Input & Power DDR2 SDRAM I/O Header NVRAM CRYPTO BOUNDARY ENCLOSED IN METAL SHEILD Figure 2 – 3e-636M Crypto Module High Level Block Diagram The logical ports: a. Status output: Ethernet port pins and GPIO (LED) connector pins b. Data output: Ethernet port pins c. Data input: Ethernet port pins d. Control input: Ethernet port pins and RESET pin e. Power input pin 3. Roles & services The module supports three separate roles. There are two operator roles and one end user role. The set of services available to each role is defined in this section. The following table identifies the strength of authentication for each authentication mechanism supported: 3 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy Role Authentication Mechanism Strength of Mechanism Crypto Officer Username and password (8-30 chars) Minimum 8 characters => 1:94^8 = 1.641E-16 Administrator Username and password (8-30 chars) Minimum 8 characters => 1:94^8 = 1.641E-16 End User RSA/ ECDSA certificate 2048 and 4096 bits key(RSA), 256/384/521 bits key for ECDSA Table 2: Identity Based Authentication & Strength of Authentication The module halts (introduces a delay) for one second after each unsuccessful authentication attempt by Crypto Officer or Administrator. The highest rate of authentication attempts to the module is one attempt per second. This translates to 60 attempts per minute. Therefore the probability for multiple attempts to use the module's authentication mechanism during a one- minute period is 60/(94^8), or less than (9.84E-15). 3.1 End User role The end user of the device can set up VPN tunnel using IKE v2 to the module and send or receive data to and from the module. End user can only use the cryptographic service but can’t configure the device. The End User is authenticated via its digital certificate and its knowledge of the corresponding private key. Using conservative estimates and equating a 2048 bit RSA key to a 112 bit symmetric key, or 256 bit ECDSA key equating 128 bit symmetric key, the probability for a random attempt to succeed is 1:2112. The fastest network connection supported by the module is 1 Gbps. Hence at most (1 ×109 × 60 = 6 × 1010) 60,000,000,000 bits of data can be transmitted in one minute. The number of possible attacks per minutes is 6 × 1010/112. Therefore, the probability that a random attempt will succeed or a false acceptance will occur in one minute is less than 1: (2112 x112/ 60×109), which is less than 100,000 as required by FIPS 140-2. When the device is in End User role, authentication of the End User is performed via digital certificate and its knowledge of the private key. Per packet integrity check can be optionally turned on by using SHS, AES_CCM or AES_GCM in the IPSec ESP cipher suite. 3.2 Crypto Officer and Administrator Roles When a Crypto Officer or Administrator logs into the module using a username and a password through HTTP over TLS secure channel the device assumes the role of a Crypto Officer or Administrator. The Crypto Officer is responsible for performing all cryptographic configurations for the module which include loading digital certificate and private keys for IPSec, configuration of 801.1X supplicant, setting Firewall and deep package inspection policies, managing Administrator users, uploading new firmware and bootloader, setting the password policy and performing self-tests on demand, and performing key zeroization. The Administrator user can configure non-security related parameter of the system such as host name and IP address, view status, and reset the module to factory default settings. 4 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy The following table describes the 3e-636M services, including purpose and functions, and the details about the service: Table 3: Services and User Access Service and Details Crypto Officer Administrator End User Purpose Input of Keys IKE v2 digital X certificate private key, 802.1X supplicant private key, device HTTPS private keys, authentication key with RADIUS server SNMPv3 encryption key Create and manage Support up to 5 X Administrator user administrator users Change password Administrator X X change his own password only Show system status View traffic status X X and systems log excluding security audit log Key zeroization via X X reboot Factory default Delete all X configurations and set device back to factory default state Perform Self Test Run algorithm KAT X X Load New Firmware Upload 3eTI digital X signed firmware SNMP Management All SNMP setting X X including SNMPv3 encryption key HTTPS Management Load HTTPS server X certificate, private key IPSec data X encryption & decryption The table below shows the services and their access rights to the Critical Security Parameters (CSPs) Table 4- CSPs and Access by Services Service and Purpose CSPs Access Input of Keys IKE v2 digital certificate private Write key, 802.1X supplicant private key, device HTTPS private keys, authentication key with RADIUS server 5 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy Create and manage Administrator Administrator Password Read and Write user Change password Crypto Officer, Administrator or Read and Write NetUser password Show system status None None Key zeroization via reboot All Write Factory default Delete all configurations and set Write device back to factory default state Perform Self Test None None IPSec data encryption & IPSec ESP session keys Execute decryption Load new firmware Firmware signing public key Read SNMP management SNMP 90 bit AES key Read SNMP Community Name HTTPS management HTTPS server certificate, private Read key 4. Operational Environment The crypto module firmware runs on FreeScale PowQUICC 8378E processor. The firmware is embedded within and it is non-modifiable. In that an operator cannot reconfigure the internal firmware to add/delete/modify functionality. 3eTI allows a single case in which firmware can ever be modified: an upload image can be loaded if a bug is found or an enhancement to the 3e- 636M needs to be added. The current version of the firmware is 5.0. The module uses digital signature to validate the upload firmware. Invalidated firmware will result in invalidated module. 5. Cryptographic Algorithms The product supports the following FIPS-approved cryptographic algorithms. The algorithms are listed below, along with their corresponding CAVP certificate numbers. 3e Technologies International Inc. 3eTI OpenSSL Algorithm Implementation 1.0.1-a Triple-DES #1327 AES #2060 SHS #1801 #1072, 1278(1) RSA HMAC #1253 #303, 415(2) ECDSA sign and verify with P256, P384 and P512 curve RNG #1076 Component Test (TLS 1.0/1.1/1.2 with SHA-256/SHA-384) #22 Component Test (ECCDH) #87 6 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy Component Test (IKEv2) #169 The TLS and IKEv2 KDF are CAVP validated, however the TLS and IKEv2 protocol are neither reviewed nor tested by CMVP or CAVP. Note 1: RSA signature generation 1024 bit or 1536 bit keys, or with SHA-1, is non-approved according to NIST SP 800-131A. Note2: ECDSA signature generation with SHA-1 is non-approved according to NIST SP 800- 131A. 3e Technologies International Inc. 3e-520 Accelerated Crypto Core 1.0 Triple-DES #1329 AES (CCM, CMAC) #2078 SHS #1807 HMAC #1259 AES_GCM #2105 The product supports the following non-Approved cryptographic algorithms: • MD5 • NDRNG • RSA (key wrapping; key establishment methodology between 112 and 150 bits of encryption strength; non-compliant less than 112 bits of encryption strength) • Triple-DES (Cert. #1327, key wrapping; key establishment methodology provides 112 bits of encryption strength; non-compliant less than 112 bits of encryption strength) • AES (Cert. #2060, key wrapping; key establishment methodology provides between 128 and 256 bits of encryption strength) • Diffie-Hellman (CVL Cert. #169, key agreement; key establishment methodology provides 112 bits of encryption strength; non-compliant less than 112 bits of encryption strength) • EC Diffie-Hellman (CVL Cert. #87, key agreement; key establishment methodology provides between 128 and 256 bits of encryption strength) 6. Cryptographic Keys and SRDIs All keys are entered encrypted using HTTP over TLS through the Module Web interface. Below is the Cryptographic Key and Security Relevant Data Item (SRDI) table: Table 5: SRDI Table Non-Protocol Keys/CSPs Key/CSP Type Generation/ Output Storage Zeroization Use Input Operator ASCII string Input Not output PKCS5 hash Zeroized Used to passwords encrypted in flash when reset to authenticate (using TLS factory CO and 7 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy session key) settings. Admin role operators Firmware ECDSA Embedded in Not output Plaintext in Zeroized Used for verification public key firmware at flash when firmware key (256 biys) compile time. firmware is digital Firmware upgraded. signature upgrade is verification through encrypted (using TLS session key) SNMP packet HMAC key Input Not output Ciphertext in Zeroized Use for authentication (ASCII string, encrypted flash, when reset to SNMP keys, 128-256 bits) (using TLS encrypted factory message username session key) with “system settings. authentication config AES key” system config AES key Hardcoded in Not output Plaintext in Zeroized Used to AES key (256 (HEX string) FLASH FLASH when encrypt the bit) firmware is configuration upgraded. file RNG Keys/CSPs Key/CSP Type Generation/ Output Storage Zeroization Use Input FIPS ANSI 16-byte value 512 bytes Not output Plaintext in Zeroized Used to X9.31RNG from RAM every time a initialize FIPS Seed Key /dev/urandom new random RNG file, then number is hashed by generated HMAC- using the SHA256. FIPS PRNG /dev/urandom after it is is populated used. by hardware noise generator RNG Seed 16-byte value 512 bytes Not output Plaintext in Zeroized Used as seed from RAM every time a for FIPS /dev/urandom new random RNG. file, then number is hashed by generated HMAC- using the SHA256. FIPS PRNG /dev/urandom after it is is populated used. by hardware noise generator IPSec Protocol Keys/CSPs Key/CSP Type Generation/ Output Storage Zeroization Use Input DH Private 1024, 1536, Generated None plaintext in Zeroized IKE v2 SA Key1 2048 bits RAM when no setup private key longer used ECCDH 256,384,521 Generated None Plaintext in Zeroized IKE v2 SA Private Key bits RAM when no setup longer used IPSec SA RSA Input Not output Plaintext in Flash copy At IKE v2 SA authentication (2048,4096) encrypted RAM and factory default authentication 8 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy certificate ECDSA (using TLS encrypted in RAM copy private key (256,384,512) session key) FLASH zeroized when not in use IPSec SA Text string Input Not output Plaintext in At factory Encrypt the private key encrypted RAM and default IPSec SA password (using TLS encrypted in certificate session key) FLASH private key IPSec SA Derived from Not input Not output Plaintext in Zeroized Encrypt and session key DH/ECCDH RAM when no authenticate key exchange longer used SA_Auth messages of IKE v2 IPSec ESP AES, Not input Not output Plaintext in Zeroized Encrypt IPSec symmetric AES_CCM, (derived from RAM when child SA ESP data Data AES_GCM SA setup) lifetime encryption (128,192,256) expired key 3eTI Security Server Keys/CSPs (When Module is configured as 802.1X authenticator) Key/CSP Type Generation/ Output Storage Zeroization Use Input Security HMAC key Input Not output Ciphertext in Zeroized at Authenticate Server (ASCII string) encrypted flash, factory default module to password (using TLS encrypted reset Security session key) with “system Server in config AES support of key”, plain IPSec SA text in RAM EAP-TLS authentication Backend HMAC key Input Not output Ciphertext in Zeroized at Authenticate password (ASCII string, encrypted flash, factory default messages 128-256 bits) (using TLS encrypted reset between session key) with “system module and config AES security server key” in support of IPSec SA EAP-TLS 3eTI 802.1X Supplicant Keys/CSPs (when Module is configured as 802.1X supplicant) Key/CSP Type Generation/ Output Storage Zeroization Use Input 802.1X RSA Input Not output Ciphertext in Zeroized at Used to Supplicant (1024,2048,40 encrypted flash, factory default authenticate private key2 96) (using TLS encrypted reset with ECDSA session key) with “system Authentication (256,384,512) config AES Server key” 802.1X Text string Input Not output Ciphertext in Zeroized at Used to Supplicant encrypted flash, factory default encrypt the private key (using TLS encrypted reset private key password session key) with “system config AES key” RFC 2818 HTTPS Keys/CSPs Key/CSP Type Generation/ Output Storage Zeroization Use Input RSA private RSA Not input Not output Plaintext in Zeroized Used to key (2048/3072/40 (installed at flash when new support CO 96) (key factory) private key is and Admin wrapping; key uploaded HTTPS establishment interfaces. 9 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy methodology provides 112- 150 bits of encryption strength) TLS session Triple-DES Not input, Not output Plaintext in Zeroized Used to key for (192) derived using RAM when a page protect encryption AES TLS protocol of the web HTTPS (128/192/256) GUI is served session. after it is used. Public Security Parameter D During TLS HTTPS Public RSA Input Plaintext in Zeroized Used to setup certificate (2048/3072/40 encrypted session setup flash when new TLS session 96) (using TLS certificate is for HTTPS session key) loaded HTTPS root RSA Input Not output Plaintext in Zeroized Used to setup certificate (2048/3072/40 encrypted flash when new root TLS session 96) (using TLS certificate is for HTTPS session key) loaded IPSec Public RSA Input During IPSec Plaintext in Zeroized Used for certificate (2048,4096) encrypted SA flash when new mutual negotiation D ECDSA (using TLS certificate is authentication (256,384,512) session key) loaded of the IPSec SA IPSec Root RSA Input Not output Plaintext in Zeroized Used for certificate (2048,4096) encrypted flash when new root mutual ECDSA (using TLS certificate is authentication (256,384,512) session key) loaded of the IPSec SA D During 802.1X RSA Input Plaintext in Zeroized authentication supplicant (1024,2048,40 encrypted EAP-TLS flash when new of the EAP- public 96) (using TLS session setup certificate is TLS certificate2 session key) loaded 802.1X RSA Input Plaintext in Zeroized authentication supplicant (1024,2048,40 encrypted flash when new root of the EAP- root 96) (using TLS certificate is TLS certificate2 session key) loaded Note1: DH with public keys < 2048 or private keys <224 bits is not allowed per NIST SP 800- 131A. Note2: RSA key is used for digital signature verification, it’s for legacy use per NIST SP 800- 131A 7. Self-Tests The 3e-636M Accelerated Crypto Module performs the following power-on self-tests: Firmware Integrity Test • Bootloader Integrity Test • Firmware Integrity Test FreeScale PowerQUICC Crypto Engine Power-on self-tests: • AES ECB encrypt KAT • AES ECB decrypt KAT • Triple-DES CBC encrypt KAT 10 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy Triple-DES CBC decrypt KAT • Triple-DES ECB encrypt KAT • Triple-DES ECB decrypt KAT • AES_CCM encrypt KAT • AES_CCM decrypt KAT • AES_GCM encrypt KAT • AES_GCM decrypt KAT • AES_CMAC KAT • SHA-1, SHA224, SHA256, SHA384, SHA512 KAT • HMAC SHA-1, SHA224, SHA256, SHA384, SHA512 KAT • 3eTI OpenSSL library Power-on self-tests: AES ECB encrypt KAT • AES ECB decrypt KAT • Triple-DES CBC encrypt KAT • Triple-DES CBC decrypt KAT • HMAC SHA-1, SHA224, SHA256, SHA384, SHA512 KAT • SHA-1, SHA224, SHA256, SHA384, SHA512 KAT • ANSI X9.31 RNG KAT • RSA sign KAT • RSA verify KAT • ECDSA sign KAT • ECDSA verify KAT • ECCCDH KAT • After device is powered on, the first thing done by bootloader is to check its own integrity. If the integrity is broken, firmware won’t boot. Firmware integrity is performed at firmware boot up. Both firmware and bootloader are digitally signed with ECDSA. As for firmware upgrade via Web GUI, the firmware’s digital signature is verified via ECDSA prior to its acceptance. If the ECDSA verification fails, the firmware upload will be rejected. Conditional self-tests: • Continuous Random Number Generator Test (CRNGT) on Approved RNG • Continuous Number Generator Test (CRNGT) on NDRNG • DH/ECCDH pair-wise consistency test • Firmware load test Upon self-tests or conditional tests failure, the system will halt and the module will not be operable. The status output LED GPIO pins will be set high to indicate the system halt condition. 8. Tamper Evidence The cryptographic boundary is protected by two self-destructive tamper evidence tapes, as shown in the figure below. 11 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy Figure 3 – 3e-636M Crypto Module Tamper Evidence Tape Tamper evidence tapes are applied to the module at manufacturing time. Crypto Officer is responsible for checking tamper evidence tapes. Checking for Tamper Evidence Tamper evidence tapes should be checked for nicks and scratches that make the metal case visible through the nicked or scratched seal. Tamper evidence tapes may show any of the following as evidence of tampering or removal: Tape is not preset in the positions prescribed (as shown above) • Tape has been cut • Tape is not stuck down well, or loose • Self destruction of the tape (broken bits or shreds) present as from an attempt of removal. • Tracking numbers do not match those recorded • In case of notification of tamper evidence, Crypto Officer shall not power on this module and shall contact 3eTI for factory repair. 9. Secure Rules & Configuration Security Rules The following product security rules must be followed by the operator in order to ensure secure operation: 1. The Crypto Officer shall not share any key, or SRDI used by the product with any other operator or entity. 2. The Crypto officer is responsible for inspecting the tamper evidence tapes. Other signs of tamper include wrinkles, tears and marks on or around the tape. 12 3e Technologies International (3eTI) FIPS 140-2 Non-Proprietary Security Policy 3. The Crypto Officer shall change the default password when configuring the product for the first time. The default password shall not be used. The module firmware also enforces the password change upon Crypto Officer’s first log in. 4. The Crypto Officer shall login to make sure CSPs and keys are configured and applied in the device. 5. The Crypto Officer shall make sure the key size is larger or equal to 2048 bits if the RSA services are used. Security Configuration The module operates in Approved Mode only at all times. The Crypto Officer shall properly configure the module following the steps listed below: 1. Log in the module over HTTPS and change the default password (If this is the first time of use). 2. Configure the Management VPN tunnel with proper CSPs, such as certificate, private key, trust anchor and key expiration time. 3. Configure the Data VPN tunnel with proper CSPs, such as certificate, private key, trust anchor and key expiration time. 4. Configure the 802.1X supplication with proper CSPs, such as certificate, private key and trust anchor. (Optional) After configuration of the above items, reboot the device and the device will come back operate in full approved mode of operation. 10. Design Assurance All source code and design documentation for this module are stored in version control system CVS. The module is coded in C with module’s components directly corresponding to the security policy’s rules of operation. Functional Specification is also provided. 11. Mitigation of Other Attack The module does not mitigate other attack. 13