Palo Alto Networks 3000 Tannery Way Santa Clara, CA 95054 www.paloaltonetworks.com Revision Date: June 5, 2019 www.paloaltonetworks.com © 2019 Palo Alto Networks. Non‐proprietary security policy may be reproduced only in its original entirety (without revision). Palo Alto Networks, PAN‐OS, and Panorama are trademarks of Palo Alto Networks, Inc. All other trademarks are the property of their respective owners. Palo Alto Networks VM‐Series FIPS 140‐2 Non‐Proprietary Security Policy Palo Alto Networks VM Series Security Policy Page 2 of 26 Change Record Date Author Description of Change 12/12/2018 Amir Shahhosseini Initial authoring for PAN‐OS 8.1 6/5/2019 Amir Shahhosseini Updates to address CMVP comments Palo Alto Networks VM Series Security Policy Page 3 of 26 Contents Module Overview............................................................................................................................................... 5 1 Security Level ............................................................................................................................................. 6 2 Modes of Operation................................................................................................................................... 7 2.1 FIPS Approved Mode of Operation............................................................................................................. 7 2.2 Approved and Allowed Algorithms............................................................................................................. 8 2.3 Non‐Approved, Non‐Allowed Algorithms................................................................................................. 11 3 Ports and Interfaces................................................................................................................................. 12 4 Identification and Authentication Policy ................................................................................................. 12 4.1 Assumption of Roles................................................................................................................................. 12 5 Access Control Policy ............................................................................................................................... 14 5.1 Roles and Services.................................................................................................................................... 14 5.2 Unauthenticated Services ........................................................................................................................ 16 5.3 Definition of Critical Security Parameters (CSPs) ..................................................................................... 16 5.4 Definition of Public Keys........................................................................................................................... 18 5.5 Definition of CSPs Modes of Access.......................................................................................................... 19 6 Physical Security Policy ............................................................................................................................ 20 7 Operational Environment ........................................................................................................................ 21 8 Security Rules........................................................................................................................................... 22 9 Mitigation of Other Attacks Policy........................................................................................................... 24 10 References ............................................................................................................................................... 24 11 Definitions and Acronyms........................................................................................................................ 25 Palo Alto Networks VM Series Security Policy Page 4 of 26 Tables Table 1 ‐ Module Files ........................................................................................................................................ 5 Table 2 ‐ Module Security Level Specification ................................................................................................... 6 Table 3 ‐ FIPS Approved Algorithms Used in Current Module........................................................................... 8 Table 4 ‐ FIPS Allowed Algorithms Used in Current Module............................................................................ 11 Table 5 ‐ Supported Protocols in FIPS Approved Mode................................................................................... 11 Table 6 ‐ Non‐Approved, Non‐Allowed Algorithms Used in Current Module.................................................. 11 Table 7 ‐ Module Ports and Interfaces............................................................................................................. 12 Table 8 ‐ Roles and Required Identification and Authentication..................................................................... 13 Table 9 ‐ Strengths of Authentication Mechanisms......................................................................................... 14 Table 10 ‐ Authenticated Service Descriptions ................................................................................................ 15 Table 11 ‐ Authenticated Service Access ......................................................................................................... 15 Table 12 ‐ Unauthenticated Services ............................................................................................................... 16 Table 13 ‐ Private Keys and CSPs...................................................................................................................... 16 Table 14 ‐ Public Keys....................................................................................................................................... 18 Table 15 ‐ CSP and Public Key Access Rights within Roles & Services ............................................................. 20 Figures Figure 1 – Cryptographic Boundary ................................................................................................................... 6 Palo Alto Networks VM Series Security Policy Page 5 of 26 Module Overview The Palo Alto Networks VM‐Series module is available in multiple capacity options (e.g., VM‐50, VM‐100, VM‐200, VM‐300, VM‐500, VM‐700, and VM‐1000‐HV; note that these are sets of configuration options rather than actual module variants). All models can be deployed as guest virtual machines on VMware ESXi, Hyper‐V 2012 R2 and Linux server that is running the KVM (Kernel‐based Virtual Machine) using a common base image distributed in a compatible hypervisor format. Table 1 ‐ Module Files Operational Environment PA‐VM Release Software Version VMware ESXi v5.5 8.1.3 or 8.1.6 KVM on CentOS 7.2 8.1.3 or 8.1.6 Microsoft Hyper‐V 2012R2 8.1.3 or 8.1.6 Amazon AWS* 8.1.3 or 8.1.6 Microsoft Azure* 8.1.3 or 8.1.6 Google Cloud* 8.1.6 Please see Section 7 of this document for this listing of tested configurations of these module files. The Palo Alto Networks VM Series is a software cryptographic module and requires an underlying general purpose computer (GPC) environment. The module is comprised of a GPC (multi‐chip standalone embodiment) and the Logical Cryptographic Module (LCM) boundary. The LCM boundary includes all of the logical software components of the module. The physical cryptographic module (PCM) boundary is defined by the enclosure around the host GPC on which it runs. Figure 1 depicts the logical diagram for the LCM boundary and illustrates the hardware components of a GPC. *Note: These operational environments are Vendor Affirmed. See Section 8 in this Security Policy for operator porting rules. Palo Alto Networks VM Series Security Policy Page 6 of 26 Figure 1 – Cryptographic Boundary 1 Security Level The cryptographic module meets the overall requirements applicable to Level 1 security of FIPS 140‐2. Table 2 ‐ Module Security Level Specification Security Requirements Section Level Cryptographic Module Specification 1 Module Ports and Interfaces 1 Roles, Services and Authentication 3 Finite State Model 1 Physical Security N/A Operational Environment 1 Cryptographic Key Management 1 EMI/EMC 1 Self‐Tests 1 Design Assurance 3 Mitigation of Other Attacks N/A Palo Alto Networks VM Series Security Policy Page 7 of 26 2 Modes of Operation 2.1 FIPS Approved Mode of Operation The modules support both a FIPS‐CC mode and a non‐FIPS‐CC mode. The following procedure will put the modules into the FIPS‐approved mode of operation:  During initial boot up, break the boot sequence via the console port connection (by entering “maint”) to access the main menu.  Select “Continue.”  Select the “Set FIPS‐CC Mode” option to enter FIPS‐CC mode.  Select “Enable FIPS‐CC Mode”.  When prompted, select “Reboot” and the module will re‐initialize and continue into FIPS‐CC mode (FIPS mode).  The module will reboot.  In FIPS‐CC mode, the console port is available only as a status output port. The module will automatically indicate the FIPS Approved mode of operation in the following manner:  Status output interface will indicate “**** FIPS‐CC MODE ENABLED ****” via the CLI session.  Status output interface will indicate “FIPS‐CC mode enabled successfully” via the console port.  The module will display “FIPS‐CC” at all times in the status bar at the bottom of the web interface. Should one or more power‐up self‐tests fail, the FIPS Approved mode of operation will not be achieved. Feedback will consist of:  The module will reboot and enter a state in which the reason for the reboot can be determined.  The module will output “FIPS‐CC failure.”  To determine which self‐test caused the system to reboot into the error state, connect the console cable and follow the on‐screen instructions to view the self‐test output. 2.2 Non‐Approved Mode of Operation The following procedure will put the modules into the FIPS‐approved mode of operation:  Access the module’s CLI via SSH, and command the module to enter maintenance mode; the module will reboot o Note: Establish a serial connection to the console port  After reboot, select “Continue.”  Select the “Set FIPS‐CC” option, and press enter.  Select “Disable FIPS‐CC Mode”, and press enter. Palo Alto Networks VM Series Security Policy Page 8 of 26  The module will disable FIPS‐CC mode, and perform a factory reset (zeroization)  Once complete, the module will provide the following status output: o “Set FIPS‐CC Mode Status: Success” 2.3 Approved and Allowed Algorithms The cryptographic modules support the following FIPS Approved algorithms. Table 3 ‐ FIPS Approved Algorithms Used in Current Module FIPS Approved Algorithm CAVP Cert. # AES [FIPS 197, SP800‐38A]: ‐ ECB, CBC, CTR modes; Encrypt/Decrypt; 128, 192 and 256‐bit ‐ CFB128 mode; Encrypt/Decrypt; 128 bit Note: AES‐OFB, AES‐CFB1, AES‐CFB8 and AES‐CFB128 (192, 256 bit) were also tested but are not available for use 5902 AES‐CCM [SP800‐38C]: Encrypt and Decrypt, 128‐bit 5902 AES‐GCM [SP800‐38D]: Encrypt and Decrypt, 128 and 256‐bit Note 1: GCM IV handling is compliant with FIPS IG A.5 and SP800‐38D.* Note 2: GCM 192‐bit was tested but is not used by the module. 5902 CKG [SP800‐133]: Function: Key Generation Method 1: Asymmetric Key Generation; SP800‐133 §6, seed results from an unmodified DRBG output Method 2: Symmetric Key Generation; SP800‐133 §7.1 (symmetric key results from an unmodified DRBG output), §7.2, and §7.3 Vendor Affirmed CVL: Elliptic Curve Diffie‐Hellman Exchange [SP800‐56A] ‐ ECC CDH primitive (§5.7.1.2) Curves: P‐256, P‐384, P‐521 ‐ KAS‐ECC all except KDF Curves: P‐256, P‐384, P‐521 2128 CVL: Diffie‐Hellman Exchange [SP800‐56A] ‐ KAS‐FFC all except KDF Parameter Sets: FB and FC 2128 CVL: ECDSA Signature Generation  P‐256 SHA: SHA‐224, SHA‐256, SHA‐384, SHA‐512  P‐384 SHA: SHA‐224, SHA‐256, SHA‐384, SHA‐512 Note: P‐521 was tested, but not used by the module 2129 CVL: KDF, Application Specific [SP800‐135] ‐ TLSv1.0/1.1/1.2 KDF 2130 Palo Alto Networks VM Series Security Policy Page 9 of 26 FIPS Approved Algorithm CAVP Cert. # ‐ SNMPv3 KDF ‐ SSHv2 KDF ‐ IKE v1/v2 KDF CVL: RSA [SP800‐56B] ‐ RSADP 2131 DRBG [SP800‐90A]: CTR DRBG with AES‐256, one instantiation per plane Derivation function enabled 2464 DSA [FIPS 186‐4] ‐Key Generation: 2048 bits 1497 ECDSA [FIPS 186‐4] ‐ Key Pair Generation P‐256, P‐384 and P‐521 ‐ Public Key Validation P‐256, P‐384, P‐521 ‐ Signature Generation P‐256, P‐384, and P‐521; with all SHA‐2 sizes+ ‐ Signature Verification P‐256, P‐384, and P‐521; with SHA‐1 and all SHA‐2 sizes+ Note: P‐224 was tested, but not used by the module + Does not include the “short SHA‐512” sizes SHA‐512/224 or SHA‐512/256 1575 HMAC [FIPS 198] ‐ HMAC‐SHA‐1 with λ=96, 160 ‐ HMAC‐SHA‐256 with λ=256 ‐ HMAC‐SHA‐384 with λ=384 ‐ HMAC‐SHA‐512 with λ=512 3882 KAS: SP 800‐56A Rev.2 Elliptic Curve Diffie‐Hellman Exchange (CVL Certs. #2128 and #2130, vendor affirmed; key agreement; key establishment methodology provides between 128 and 256 bits of encryption strength) Vendor Affirmed KAS: SP 800‐56A Rev.2 Diffie‐Hellman Exchange (CVL Certs. #2128 and #2130, vendor affirmed; key agreement; key establishment methodology provides 112 bits of encryption strength) Vendor Affirmed KTS [SP800‐38F §3.1]: AES‐CBC (128/192/256 bit) plus HMAC AES‐CTR (128/192/256 bit) plus HMAC (Key wrapping; key establishment methodology provides between 128 and 256 bits of encryption strength) AES 5902 HMAC 3882 KTS [SP800‐38F §3.1]: AES‐GCM (Key wrapping; key establishment methodology provides between 128 and 256 bits of encryption strength) AES 5902 Palo Alto Networks VM Series Security Policy Page 10 of 26 FIPS Approved Algorithm CAVP Cert. # FIPS 186‐4 RSA [FIPS 186‐4]: ‐ Key Pair Generation: 2048 and 3072 ‐ Signature Generation (ANSI X9.31, RSASSA‐PKCS1_v1‐5, RSASSA‐PSS): 2048, 3072, and 4096‐bit with hashes (SHA‐1+ /256/384/512) ‐ Signature Verification (ANSI X9.31, RSASSA‐PKCS1_v1‐5, RSASSA‐PSS): 1024++ , 2048, 3072, 4096‐bit (per IG A.14) with hashes (SHA‐1/224+++ /256/384/512) +: Only used for signature generation in SSH in the Approved Mode ++: This size is not supported for RSASSA‐PKCS1_v1‐5 +++: This Hash algorithm is not supported for ANSI X9.31 3090 SHA‐1 and SHA‐2 [FIPS 180‐4]: ‐ Hashes: SHA‐1, SHA‐256, SHA‐384, SHA‐512 ‐ Usage: Digital Signature Generation & Verification, Non‐Digital Signature Applications (e.g., component of HMAC) (Note: SHA‐224 was tested, but not used in the module) 4658 * The module is compliant to IG A.5: GCM is used in the context of TLS, IPsec/IKEv2, SSH, and IPsec/IKEv1:  For TLS, The GCM implementation meets Option 1 of IG A.5: it is used in a manner compliant with SP 800‐52 and in accordance with Section 4 of RFC 5288 for TLS key establishment. (From this RFC, the GCM cipher suites in use are TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, and TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.) During operational testing, the module was tested against an independent version of TLS and found to behave correctly.  For IPsec/IKEv2, The GCM implementation meets Option 1 of IG A.5: it is used in a manner compliant with RFCs 4106 and 7296 (RFC 5282 is not applicable, as the module does not use GCM within IKEv2 itself). During operational testing, the module was tested against an independent version of IPsec with IKEv2 and found to behave correctly.  For SSH, the module meets Option 4 of IG A.5. The fixed field is 32 bits in length and is derived using the SSH KDF; this ensures the fixed field is unique for any given GCM session. The invocation field is 64 bits in length and is incremented for each invocation of GCM; this prevents the IV from repeating until the entire invocation field space of 264 is exhausted. (It would take hundreds of years for this to occur.)  For IPsec/IKEv1, the module meets Option 4 of IG A.5. The behavior is the same as the above description for SSH, except the fixed field is derived using the IKEv1 KDF instead of the SSH KDF. In all of the above cases, the nonce_explicit is always generated deterministically. AES GCM keys are zeroized when the module is power‐cycled. For each new TLS or SSH session, a new AES GCM keys is established. The cryptographic modules support the following non‐FIPS Approved algorithms that are allowed for use in FIPS‐CC mode. Palo Alto Networks VM Series Security Policy Page 11 of 26 Table 4 ‐ FIPS Allowed Algorithms Used in Current Module FIPS Allowed Algorithms Diffie‐Hellman, non‐compliant to SP800‐56A [safe primes: L=2048, N=2047] (key agreement; key establishment methodology provides 112 bits of encryption strength) CMAC – A self‐test is performed for this algorithm, but it is not used by the module MD5 (within TLS) NDRNGs (used to seed SP800‐90A DRBG): one NDRNG per plane. These NDRNG provide a minimum of 128 bits of entropy depending on the operational environment. RSA wrap and unwrap, non‐compliant to SP800‐56B RSA (CVL Cert. #2131, key wrapping; key establishment methodology provides 112 or 128 bits of encryption strength) Table 5 ‐ Supported Protocols in FIPS Approved Mode Supported Protocols* TLS v1.01 , v1.1 and 1.2 SSHv2 IPSec, IKEv1 and V2 SNMPv3 *Note: These protocols have not been tested or reviewed by the CMVP or the CAVP. 2.4 Non‐Approved, Non‐Allowed Algorithms The cryptographic modules support the following non‐Approved algorithms in the non‐Approved mode of operation. No security claim is made in the current modules for any of the following non‐ Approved algorithms. Table 6 ‐ Non‐Approved, Non‐Allowed Algorithms Used in Current Module Non‐Approved Algorithms in Non‐FIPS mode Digital Signatures (non‐Approved strengths, non‐compliant): RSA Key Generation: 512, 1024, 4096 RSA signature generation: Modulus bit length less than 2048 or greater than 4096 bits; up to 16384 bits RSA signature verification: Modulus bit length less than 1024 or greater than 4096 bits; up to 16384 bits 1 See vendor imposed security rule #1.a in Section 8 Palo Alto Networks VM Series Security Policy Page 12 of 26 Non‐Approved Algorithms in Non‐FIPS mode ECDSA: B, K, P curves not equal to P‐256, P‐384 or P‐521 DSA: 768 to 4096 bits Encrypt/Decrypt: Camellia, SEED, Triple‐DES(non‐compliant), Blowfish, CAST, RC4, DES Hashing: RIPEMD, MD5 Firmware Integrity Check: HMAC‐SHA‐256 Key Exchange (non‐Approved strengths): Elliptic Curve Diffie‐Hellman: B, K, P curves not equal to P‐256, P‐384 or P‐521 Diffie‐Hellman: 768, 1024 and 1536 bit modulus RSA: Less than 2048 bit modulus Message Authentication: UMAC, HMAC‐MD5, HMAC‐RIPEMD 3 Ports and Interfaces The module is a software only module that operates on a general purpose computing (GPC) platform. The physical ports and logical interfaces are consistent with a GPC operating environment. The module supports the following FIPS 140‐2 logical interfaces: Table 7 ‐ Module Ports and Interfaces Type FIPS 140‐2 Designation GPC Peripheral Ports and Network Interfaces Management/ Ethernet Data Input, Data Output, Control Input, Status Output Ethernet Console Status Output Ethernet, GPC I/O Power Power Power The module’s physical and electrical characteristics, manual controls, and physical indicators are provided by the host GPC; the hypervisors provide virtualized ports and interfaces which map to the GPCs’ physical ports and interfaces (i.e., network interfaces and GPC inputs/outputs). 4 Identification and Authentication Policy 4.1 Assumption of Roles The modules support four distinct operator roles, User and Cryptographic Officer (CO), Remote Access VPN, and Site‐to‐site VPN. The cryptographic modules enforce the separation of roles using unique authentication credentials associated with operator accounts. The modules do not provide a maintenance role or bypass capability. Palo Alto Networks VM Series Security Policy Page 13 of 26 Table 8 ‐ Roles and Required Identification and Authentication Role Description Authentication Type Authentication Data CO This role has access to all configurations, show status and update services offered by the module. Within the PAN‐OS software, this role maps to the “Superuser” administrator role. Identity‐based operator authentication Username/password and/or public‐ key/certificate based authentication User This role has limited access to services offered by the modules. This role does not have access to modify or view the passwords associated with other administrator accounts The User may not view or alter CSPs of any type stored on the module. The User may change their own password. Within the PAN‐OS software, this role maps to the “Superuser (read‐only)” administrator role (also referred to as “Superreader”). Identity‐based operator authentication Username/password and/or public‐ key/certificate based authentication Remote Access VPN (RA VPN) Remote user accessing the network via VPN. Identity‐based operator authentication Username/password and/or certificate based authentication Site‐to‐site VPN (S‐S VPN) Remote VPN device establishing a VPN session to facilitate access to the network. Identity‐based operator authentication IKE/IPSec Pre‐shared keys ‐ Identification with the IP Address and authentication with the Pre‐Shared Key or certificate based authentication Palo Alto Networks VM Series Security Policy Page 14 of 26 Table 9 ‐ Strengths of Authentication Mechanisms Authentication Mechanism Strength of Mechanism Username and Password Minimum length is six (6) characters (95 possible characters). The probability that a random attempt will succeed or a false acceptance will occur is 1/(956 ) which is less than 1/1,000,000. The probability of successfully authenticating to the module within one (1) minute is 10/(956 ), which is less than 1/100,000. The firewall’s configuration supports at most ten attempts to authenticate in a one‐minute period. Public‐Key/Certificate based authentication The security modules support public‐key based authentication using RSA 2048 and certificate‐based authentication using RSA 2048, RSA 3072, RSA 4096, ECDSA P‐256, P‐384, or P‐521. The minimum equivalent strength supported is 112 bits. The probability that a random attempt will succeed is 1/(2112 ) which is less than 1/1,000,000. The probability of successfully authenticating to the module within a one minute period is 3,600,000/(2112 ), which is less than 1/100,000. The firewall supports at most 60,000 new sessions per second to authenticate in a one‐minute period. IKE/IPSec pre‐shared keys The pre‐shared key authentication method has a minimum security strength of 2112 . The probability of successfully authenticating to the module is 1/(2112 ), which is less than 1/1,000,000. The number of authentication attempts is limited by the number of new connections per second supported (120,000) on the fastest platform of the Palo Alto Networks firewalls. The probability of successfully authenticating to the module within a one minute period is 7,200,000/(2112 ), which is less than 1/100,000. 5 Access Control Policy 5.1 Roles and Services The Approved and non‐Approved mode of operation provide identical services. While in the Approved mode of operation, all CO and User services are accessed via SSH or TLS sessions. Approved and allowed algorithms, relevant CSPs and public keys related to these protocols are accessed to support the following services. CSP access by services is further described in the following tables. Palo Alto Networks VM Series Security Policy Page 15 of 26 The services listed below are also available in the non‐Approved mode. In the Non‐Approved mode SSH, TLS and VPN processes will use non‐Approved Algorithms and Approved algorithms with non‐ approved strength. Table 10 ‐ Authenticated Service Descriptions Service Description Security Configuration Management Configuring and managing cryptographic parameters and setting/modifying security policy, including creating User accounts and additional CO accounts. Other Configuration Networking parameter configuration, logging configuration, and other non‐ security relevant configuration. View Other Configuration Read‐only of non‐security relevant configuration (see above). Check Status View status via the web interface, command line interface or VPN session VPN Provide network access for remote users or site‐to‐site connections. Software Update Provides a method to update the software on the firewall. Note: Additional information on the configuration options the module provides can be found at https://www.paloaltonetworks.com/documentation.html Table 11 ‐ Authenticated Service Access Service Crypto Officer User RA VPN S‐S VPN Security Configuration Management Y Y* N N Other Configuration Y N N N View Other Configuration Y Y N N Check Status Y Y Y Y VPN N N Y Y Software Update Y N N N Palo Alto Networks VM Series Security Policy Page 16 of 26 *Note: The User role has use of this service only to change their own password. 5.2 Unauthenticated Services The cryptographic module supports the following unauthenticated services: Table 12 ‐ Unauthenticated Services Service Description Zeroize The device will overwrite all CSPs. Self‐Tests Run power up self‐tests on demand by power cycling the module. Show Status (Hypervisor) View status of the module via hypervisor. The zeroization procedure is invoked when the operator exits FIPS‐CC mode. The operator must be in control of the module during the entire procedure to ensure that it has successfully completed. During the zeroization procedure, no other services are available. 5.3 Definition of Critical Security Parameters (CSPs) The modules contain the following CSPs: Table 13 ‐ Private Keys and CSPs CSP # Key Name Type Description 1 RSA Private Keys RSA RSA Private key for generation of signatures, authentication and key establishment (RSA 2048, 3072, or 4096 bits) 2 ECDSA Private Keys ECDSA ECDSA Private key for generation of signatures and authentication (P‐256, P‐384 or P‐521) 3 TLS Pre‐Master Secret TLS Secret Secret value used to derive the TLS Master Secret along with client and server random nonces 4 TLS Master Secret TLS Secret Secret value used to derive the TLS session keys Palo Alto Networks VM Series Security Policy Page 17 of 26 CSP # Key Name Type Description 5 TLS DHE Private Components DH, ECDH Diffie‐Hellman private FFC or EC component (DHE 2048, ECDHE P‐256, P‐384, P‐521) 6 TLS HMAC Keys HMAC TLS integrity and authentication session keys (SHA‐1, SHA‐256 and SHA‐384) 7 TLS Encryption Keys AES TLS encryption session keys (128 and 256 CBC or GCM) 8 SSH Session Authentication Keys HMAC Authentication keys used in all SSH connections to the security module’s command line interface. (HMAC‐SHA‐1, HMAC‐SHA2‐256, HMAC‐SHA2‐512) 9 SSH Session Encryption Keys AES Used in all SSH connections to the security module’s command line interface. (128, 192, and 256 bits: CBC or CTR) (128 or 256 bits: GCM) 10 SSH DH Private Components DH Diffie Hellman private component used in key establishment (DHE 2048, ECDHE P‐256, P‐384, P‐521). 11 S‐S VPN IPSec/IKE Authentication Keys HMAC Used to authenticate the peer in an IKE/IPSec tunnel connection. (SHA‐1, SHA‐256, SHA‐384 or SHA‐512 ) 12 S‐S VPN IPSec/IKE Session Keys AES Used to encrypt IKE/IPSec data. These are AES (128, 192, or 256 CBC) IKE keys and (128, 192 or 256 CBC, 128 CCM, 128 or 256 GCM) IPSec keys 13 S‐S VPN IPSec/IKE Diffie Hellman Private Components DH, ECDH Diffie Hellman private component used in key establishment (DHE 2048, ECDHE P‐256, P‐384) 14 S‐S VPN IPSec Pre‐Shared Keys Part of HMAC Manually distributed by an administrator in the CO role. Used in authentication. 15 RA VPN IPSec Session Keys AES Used to encrypt remote access sessions utilizing IPSec. (128‐CBC, 128/256‐GCM) Palo Alto Networks VM Series Security Policy Page 18 of 26 CSP # Key Name Type Description 16 RA VPN IPSec Authentication HMAC HMAC Used in authentication of remote access IPSec data. (SHA‐1) 17 CO, User, RA VPN Password Password Used to authenticate operator 18 DRBG Seed and State DRBG DRBG seed coming from the NDRNG and AES 256 CTR DRBG state (V and Key) used in the generation of a random values 19 SNMPv3 Secrets SNMPv3 Secrets SNMPv3 Authentication Secret and Privacy Secret 20 SNMPv3 Keys SNMPv3 Keys AES CFB Privacy key and HMAC‐SHA‐1 Authentication keys 21 Protocol secrets Password Secret used by RADIUS or TACACS+ (minimum length of six (6) characters) Note: Transient CSPs are zeroized by an overwrite with a pseudo random pattern followed by read‐ verify. Intermediate plaintext key material (CSP) is zeroized when it is copied from one to another memory location. All keys (CSPs) are zeroized when they expire. Session keys (CSPs) are zeroized as soon as the associated session has ended/timed out/ or been closed. Private keys (CSPs) are zeroized when their corresponding public keys (certificates) expire. 5.4 Definition of Public Keys The modules contain the following public keys: Table 14 ‐ Public Keys Key Name Description A CA certificates RSA and/or ECDSA keys used to extend trust for certificates B ECDSA public keys / certificates ECDSA public keys managed as certificates for the verification of signatures, establishment of TLS, operator authentication and peer authentication. (ECDSA P‐256, P‐384, or P‐521) Palo Alto Networks VM Series Security Policy Page 19 of 26 Key Name Description C RSA public keys / certificates RSA public keys managed as certificates for the verification of signatures, establishment of TLS, operator authentication and peer authentication. (RSA 2048, 3072, or 4096 bits) D TLS DH public components Used in key agreement (DHE 2048, ECDHE P‐256, P‐384 and P‐521) E SSH DH public components Used in key agreement (DHE 2048, ECDHE P‐256, P‐384, P‐521) F SSH Host public key SSH Host Public Key (RSA 2048, RSA 3072, RSA 4096, ECDSA P‐256, P‐384, or P‐521) (The matching private key is among the RSA Private Keys or ECDSA Private Keys, in Table 13.) G SSH Client public key SSH client RSA public key (RSA 2048, 3072 or 4096 bit) H S‐S VPN ‐ IPSec/IKE Diffie Hellman public component Used in key agreement (DHE 2048, ECDHE P‐256, P‐384) I Public key for software content load test Used to authenticate software and content to be installed on the firewall (RSA 2048 with SHA‐256) J Software integrity verification key Public key used to validate software integrity at power‐up (ECDSA P‐256) 5.5 Definition of CSPs Modes of Access Table 15 defines the relationship between access to CSPs and the different module services. The modes of access shown in the table are defined as:  R = Read: The module reads the CSP. The read access is performed when a CSP is either exported from the module or executed by a security function.  W = Write: The module writes the CSP. The write access is typically performed after a CSP is imported into the module, or the module generates a CSP, or the module overwrites an existing CSP.  Z = Zeroize: The module zeroizes the CSP. Palo Alto Networks VM Series Security Policy Page 20 of 26 Table 15 ‐ CSP and Public Key Access Rights within Roles & Services Role Authorized Service Mode Cryptographic Key or CSP (Tables 13 & 14) CO Security Configuration Management RW 1, 2, 3, 4, 5, 6, 7, 8, 9,10, 17, 18, 19, 20, 21 A, B, C, D, E, F, G, I CO Other Configuration RW 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, A, B, C, D, E, F, G User, CO View Other Configurations R 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 18, A, B, C, D, E, F, G (operator’s own password) User Security Configuration Management RW 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, A, B, C, D, E, F, G(operator’s own password) User, CO Show Status R 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, A, B, C, D, E, F, G S‐S VPN VPN R 11, 12, 13, 14, B, C, H RA VPN VPN R 1, 2, 3, 4, 5, 6, 7, 15, 16, 18, A, B, C, D CO Software Update RW 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 17, A, B, C, D, E, F, G Unauthenticated Self‐Tests R J Unauthenticated Show Status N/A N/A Unauthenticated Zeroize Z All CSPs are zeroized. 6 Physical Security Policy There are no applicable FIPS 140‐2 physical security requirements. Palo Alto Networks VM Series Security Policy Page 21 of 26 7 Operational Environment The hypervisor environment provides an isolated operating environment and is the single operator of the virtual machine. The module was tested on the following environments operating on a general‐purpose computing platform. 1. Vmware ESXi v5.5 running on a Dell PowerEdge R730 with Intel Xeon E5‐2640 CPU 2. Vmware ESXi v5.5 running on a PacStar 451 with Intel Xeon E3‐1258 CPU 3. KVM on CentOS 7.2 running on a Dell PowerEdge R730 with Intel Xeon E5‐2630 CPU 4. Microsoft Hyper‐V 2012 R2 running on a Dell PowerEdge R730 with Intel Xeon E5‐2640 CPU 5. Amazon AWS M4.Xlarge EC2 instance* 6. Microsoft Azure Standard D4 v2* 7. Google Cloud n1‐standard‐4* The tested operating environments isolate virtual systems into separate isolated process spaces. Each process space is logically separated from all other processes by the operating environments software and hardware. The module functions entirely within the process space of the isolated system as managed by the single operational environment. This implicitly meets the FIPS 140‐2 requirement that only one (1) entity at a time can use the cryptographic module. To install, download either PanOS_vm‐8.1.3 or PanOS_vm‐8.1.6 file from the support site (https://support.paloaltonetworks.com/Support/Index) and ensure the checksum (SHA‐256) is correct: o 8.1.3: 650371e71b2622476bed8c84630b460a81e0382476b2d0f057df2182394e55cc o 8.1.6: 7538c25b884b25efcffeed023b982ae3b46122048ae481db22dfea005a8a20da Note that Operational environments indexed with * are Vendor Affirmed. The software module provides a Software Update service. The module’s validation to FIPS 140‐2 is no longer valid once a non‐validated software is loaded. Operator porting rules: The CMVP allows user porting of a validated software module to an operational environment which was not included as part of the validation testing. An operator may install and run a VM‐series firewall on any general purpose computer (GPC) or platform using the specified hypervisor and operating system on the validation certificate or other compatible operating and/or hypervisor system and affirm the modules continued FIPS 140‐2 validation compliance. The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when ported and executed in an operational environment not listed on the validation certificate. Reference: FIPS 140‐2 Implementation Guidance G.5 Palo Alto Networks VM Series Security Policy Page 22 of 26 8 Security Rules The module design corresponds to the module security rules. This section documents the security rules enforced by the cryptographic module to implement the security requirements of this FIPS 140‐2 Level 1 module. 1. The cryptographic module provides four distinct operator roles. These are the User role, Remote Access VPN role, Site‐to‐site VPN role, and the Cryptographic Officer role. 2. The cryptographic module provides identity‐based authentication. 3. The cryptographic module clears previous authentications on power cycle. 4. If the cryptographic module remains inactive in any valid role for the administrator specified time interval, the module will automatically log out the operator. The CO will configure the period of inactivity. 5. When configured, the module enforces a timed access protection mechanism that supports at most ten authentication attempts per minute. After the administrator specified number of consecutive unsuccessful password validation attempts have occurred, the cryptographic module shall enforce a wait period of at least one (1) minute before any more login attempts can be attempted. This wait period shall be enforced even if the module power is momentarily removed. 6. When the module has not been placed in a valid role, the operator does not have access to any cryptographic services. 7. The module supports the generation of key material with the approved DRBG. The entropy provided must be equal to or greater than the security strength of the key being generated. The approved DRBG requests a minimum of 256 bits of entropy per every 384 bits of seed input. 8. The cryptographic module performs the following tests A. Power up Self‐Tests 1. Cryptographic algorithm tests a. AES Encrypt Known Answer Test b. AES Decrypt Known Answer Test c. AES CMAC Known Answer Test d. AES GCM Encrypt Known Answer Test e. AES GCM Decrypt Known Answer Test f. AES CCM Encrypt Known Answer Test g. AES CCM Decrypt Known Answer Test h. RSA Sign Known Answer Test i. RSA Verify Known Answer Test Palo Alto Networks VM Series Security Policy Page 23 of 26 j. RSA Encrypt Known Answer Test k. RSA Decrypt Known Answer Test l. ECDSA Sign Known Answer Test m. ECDSA Verify Known Answer Test n. HMAC‐SHA‐1 Known Answer Test o. HMAC‐SHA‐256 Known Answer Test p. HMAC‐SHA‐384 Known Answer Test q. HMAC‐SHA‐512 Known Answer Test r. SHA‐1 Known Answer Test s. SHA‐256 Known Answer Test t. SHA‐384 Known Answer Test u. SHA‐512 Known Answer Test v. DRBG SP800‐90A Known Answer Tests w. SP 800‐90A Section 11.3 Health Tests x. DH Known Answer Test y. ECDH Known Answer Test Per IG 9.6 B. Software Integrity Test –verified with HMAC‐SHA‐256 and ECDSA P‐256. C. Critical Functions Tests 1. N/A D. Conditional Self‐Tests 1. Continuous Random Number Generator (RNG) test – performed on NDRNG and DRBG 2. RSA Pairwise Consistency Test 3. ECDSA Pairwise Consistency Test 4. Software Load Test – Verify RSA 2048 with SHA‐256 signature on software at time of load 5. If any conditional test fails, the module will output description of the error. 9. The operator can command the module to perform the power‐up self‐test by cycling power of the module. 10. Power‐up self‐tests do not require any operator action. 11. Data output is inhibited during power‐up self‐tests, zeroization, and error states. 12. Status information does not contain CSPs or sensitive data that if misused could lead to a compromise of the module. 13. There are no restrictions on which keys or CSPs are zeroized by the zeroization service. Palo Alto Networks VM Series Security Policy Page 24 of 26 14. The module does not support a maintenance interface or role. 15. The module does not have any external input/output devices used for entry/output of data. 16. The module does not enter or output plaintext CSPs. 17. The module does not output intermediate key generation values. Vendor imposed security rules: 1. In FIPS‐CC mode, the following rules shall apply: a. The operator should not enable TLSv1.0; it is disabled by default. Note that TLSv1.0 can be used in an Approved mode of operation (Approved TLS KDF algorithm); however, TLSv1.0 protocol is no longer considered as secure because of the Cipher Block Chaining IV attack, a client of the module could use a vulnerable implementation. b. Pre‐shared keys used for IKE/IPsec must be at least 14 bytes in length. c. If using RADIUS, it must be configured using TLS. In all other cases, the module shall be configured in non‐Approved mode of operation. d. If using TACACS+, configure the service route via an IPSec tunnel, and ensure the TACACS+ server is configured for a minimum password length of six (6) characters (to match Table 17 of this document), or greater. In all other cases, the module shall be configured in non‐Approved mode of operation. e. The operator shall not generate 4096‐bit RSA key in FIPS‐CC mode. If the operator wants to generate 4096‐bit RSA key, the module shall be configured in non‐Approved mode of operation. 9 Mitigation of Other Attacks Policy The module has not been designed to mitigate any specific attacks outside of the scope of FIPS 140‐ 2, so these requirements are not applicable. 10 References [FIPS 140‐2] FIPS Publication 140‐2 Security Requirements for Cryptographic Modules Palo Alto Networks VM Series Security Policy Page 25 of 26 11 Definitions and Acronyms AES – Advanced Encryption Standard CA – Certificate authority CBC – Cipher Block Chaining CC – Common Criteria CCM – Counter with CBC MAC CO – Cryptographic Officer CSP – Critical Security Parameter DHE – Diffie‐Hellman Ephemeral DRBG – Deterministic Random bit generator ECDHE – Elliptic Curve Diffie‐Hellman Ephemeral ECDSA – Elliptic Curve Digital Signature Algorithm FIPS – Federal Information Processing Standard GCM – Galois Counter Mode HMAC – Hashed Message authentication IKE – Internet Key Exchange IP – Internet Protocol IPSec – Internet Protocol Security CPU – Central Processing Unit RAM – Random Access Memory HDD – Hard Disk Drive LED – Light Emitting Diode MAC – Message Authentication Code NDRNG – Non‐deterministic Random Number Generator OVF – Open Virtualization Format PAN‐OS – Palo Alto Networks’ Operating System RA VPN – Remote Access Virtual Private Network SNMP – Simple Network Management Protocol S‐S VPN – Site to site Virtual Private Network SSH – Secure Shell SSL – Secure Sockets Layer Palo Alto Networks VM Series Security Policy Page 26 of 26 TLS – Transport Layer Security VM – Virtual Machine VPN – Virtual Private Network