FIPS 140-2 Non-Proprietary Security Policy FortiMail-2000E/3000E FortiMail-2000E/3000E FIPS 140-2 Security Policy Document Version: 1.6 Publication Date: January 4, 2019 Description: Documents FIPS 140-2 Level 2 Security Policy issues, compliancy and requirements for FIPS compliant operation. Firmware Version: FortiMail v6.0, build108, 180731 Hardware Version: FortiMail-2000E (C1AD94) FortiMail-3000E (C1AD97) FORTINET DOCUMENT LIBRARY https://docs.fortinet.com FORTINET VIDEO GUIDE https://video.fortinet.com FORTINET KNOWLEDGE BASE http://kb.fortinet.com FORTINET BLOG https://blog.fortinet.com CUSTOMER SERVICE & SUPPORT https://support.fortinet.com FORTINET COOKBOOK http://cookbook.fortinet.com FORTINET NSE INSTITUTE (TRAINING) https://training.fortinet.com/ FORTIGUARD CENTER https://fortiguard.com FORTICAST http://forticast.fortinet.com END USER LICENSE AGREEMENT AND PRIVACY POLICY https://www.fortinet.com/doc/legal/EULA.pdf https://www.fortinet.com/corporate/about-us/privacy.html FEEDBACK Email: techdocs@fortinet.com Friday, January 4, 2019 FortiMail-2000E/3000E FIPS 140-2 Non-Proprietary Security Policy 06-602-508669-20180817 TABLE OF CONTENTS Overview 5 References 5 Introduction 6 Security Level Summary 7 Module Descriptions 8 Cryptographic Module Ports and Interfaces 8 FortiMail-2000E 10 FortiMail-3000E 11 Web-Based Manager 12 Command Line Interface 12 Roles, Services and Authentication 13 Roles 13 FIPS Approved Services 13 Non-FIPS Approved Services 15 Authentication 16 Physical Security 16 Operational Environment 18 Cryptographic Key Management 19 Random Number Generation 19 Entropy 19 Key Zeroization 19 Algorithms 19 Cryptographic Keys and Critical Security Parameters 21 Alternating Bypass Feature 24 Key Archiving 25 Mitigation of Other Attacks 25 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) 26 FIPS 140-2 Compliant Operation 27 Enabling FIPS-CC mode 28 Self-Tests 29 Startup and Initialization Self-tests 29 Conditional Self-tests 29 Critical Function Self-tests 30 Error State 30 Overview References Overview This document is a FIPS 140-2 Security Policy for Fortinet's FortiMail-2000E and 3000E message security appliances. This policy describes how the FortiMail-2000E and 3000E appliances (hereafter referred to as the ‘modules’) meet the FIPS 140-2 security requirements and how to operate the modules in a FIPS compliant manner. This policy was created as part of the Level 2 FIPS 140-2 validation of the modules. The Federal Information Processing Standards Publication 140-2 - Security Requirements for Cryptographic Modules (FIPS 140-2) details the United States Federal Government requirements for cryptographic modules. Detailed information about the FIPS 140-2 standard and validation program is available on the NIST (National Institute of Standards and Technology) website at http://csrc.nist.gov/groups/STM/cmvp/index.html. References This policy deals specifically with operation and implementation of the modules in the technical terms of the FIPS 140-2 standard and the associated validation program. Other Fortinet product manuals, guides and technical notes can be found at the Fortinet technical documentation website at http://docs.fortinet.com. Additional information on the entire Fortinet product line can be obtained from the following sources: l Find general product information in the product section of the Fortinet corporate website at http://www.fortinet.com/products. l Find on-line product support for registered products in the technical support section of the Fortinet corporate website at http://www.fortinet.com/support. l Find contact information for technical or sales related questions in the contacts section of the Fortinet corporate website at http://www.fortinet.com/contact. l Find security information and bulletins in the FortiGuard Center of the Fortinet corporate website at http://fortiguard.com. FIPS 140-2 Security Policy Fortinet Inc. 5 Introduction The FortiMail family of message security appliances provide an effective barrier against the ever-rising volume of spam, maximum protection against sophisticated messagebased attacks, and features designed to facilitate regulatory compliance. FortiMail 6.0 offers both inbound and outbound scanning, advanced antispam and antivirus filtering capabilities, IP address black/white listing functionality, and extensive quarantine and archiving capabilities. Three deployment modes offer maximum versatility: transparent mode for seamless integration into existing networks with no IP address changes, gateway mode as a proxy Mail Transfer Agent (MTA) for existing messaging gateways, or server mode to act as a mail server with functionality for small businesses (SMBs) and remote offices. Note: The server mode of operation is not a FIPS approved mode of operation. 6 FIPS 140-2 Security Policy Fortinet Inc. Security Level Summary The modules meet the overall requirements for a FIPS 140-2 Level 2 validation. Table 1: Summary of FIPS security requirements and compliance levels Security Requirement Compliance Level Cryptographic Module Specification 2 Cryptographic Module Ports and Interfaces 2 Roles, Services and Authentication 3 Finite State Model 2 Physical Security 2 Operational Environment N/A Cryptographic Key Management 2 EMI/EMC 2 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks N/A FIPS 140-2 Security Policy Fortinet Inc. 7 Cryptographic Module Ports and Interfaces Module Descriptions Module Descriptions The FortiMail-2000E and 3000E are multiple chip, standalone cryptographic modules consisting of production grade components contained in a physically protected enclosure in accordance with FIPS 140-2 Level 2 requirements. The modules have a similar appearance and both have 6 network interfaces with a status LED for each network interface (2x 1GB SFP, 4x 10/100/1000 Base-T). The FortiMail-2000E has one, 8 core, x86 compatible CPU and 8 removable hard drives.. The FortiMail-3000E has two, 8 core, x86 compatible CPUs and 12 removable hard drives. The modules are 2U rackmount devices. The FortiMail-2000E and 3000E use a Fortinet entropy token as the entropy source. Refer to the Cryptographic Key Management section for more information on entropy and entropy sources. The validated firmware version is FortiMail v6.0, build108, 180731. Any firmware version that is not shown on the module certificate is out of scope of this validation and requires a separate FIPS 140-2 validation. Figures 1 and 2 are representative of the modules tested. Note that the modules include a VGA port that is not supported by the validated firmware and therefore is not part of the evaluated configuration. Also note that the removable hard drives are used to store email, log and quarantine data only. No CSPs are stored on the removable hard drives. Cryptographic Module Ports and Interfaces All of the modules have status LEDs as described in the following table: Table 2: Module Status LEDs LED State Description Power Green The module is powered on. Off The module is powered off. Status Green The module is running normally. Flashing The module is starting up. Off The module is powered off. 8 FIPS 140-2 Security Policy Fortinet Inc. Module Descriptions Cryptographic Module Ports and Interfaces LED State Description HA Green HA is enabled. Off The unit is in standalone mode. Alarm Red The unit has a major alarm. Amber The unit has a minor alarm. Off The unit is operating normally. Ethernet Ports Link/ACT Green Port is connected. Flashing Port is sending/receiving data. Off No link established. Speed Green Connected at 1000 Mbps. Amber Connected at 100 Mbps Off Connected at 10 Mbps SFP Ports Green Port is connected. Flashing Port is sending/receiving data. Off No link established. SFP Ports (Bypass pair) Green Inline mode Amber Bypass mode FIPS 140-2 Security Policy Fortinet Inc. 9 Cryptographic Module Ports and Interfaces Module Descriptions FortiMail-2000E Figure 1 - FortiMail-2000 Front and Rear Panels Table 3: FortiMail-2000E Connectors and Ports Connector Type Speed Supported Logical Interfaces Description Ports 1-4 RJ-45 10/100/1000 Base-T Data input, data output, control input and status output Connection to 10/100/1000 networks. Ports 5-6 SFP 1 Gbps Data input, data output, control input and status output Fiber optic connection to gigabit optical networks. Console Port RJ-45 9600 bps Control input, status output Optional connection to the management computer. Provides access to the command line interface (CLI). USB Port USB A N/A Key loading and archiving, entropy input Optional USB token and entropy token. AC POWER N/A N/A Power 120/240VAC power connection. 10 FIPS 140-2 Security Policy Fortinet Inc. Module Descriptions Cryptographic Module Ports and Interfaces FortiMail-3000E Figure 2 - FortiMail-3000E Front and Rear Panels Table 4: FortiMail-3000E Connectors and Ports Connector Type Speed Supported Logical Interfaces Description Ports 1-4 RJ-45 10/100/1000 Base-T Data input, data output, control input, and status output Copper gigabit connection to 10/100/1000 copper networks. Ports 5-6 SFP 1 Gbps Data input, data output, control input and status output Fiber optic connection to gigabit optical networks. USB USB-A N/A Key loading and archiving, entropy input Optional USB token and entropy token. Console RJ-45 9600 bps Control input, status output Optional connection to the management computer. Provides access to the command line interface (CLI). AC POWER N/A N/A Power 120/240VAC power connection. FIPS 140-2 Security Policy Fortinet Inc. 11 Web-Based Manager Module Descriptions Web-Based Manager The FortiMaill web-based manager provides GUI based access to the modules and is the primary tool for configuring the modules. The manager requires a web browser on the management computer and an Ethernet connection between the FortiMail unit and the management computer. A web-browser that supports Transport Layer Security (TLS) 1.1 or 1.2 is required for remote access to the web- based manager when the module is operating in FIPS-CC mode. HTTP access to the web-based manager is not allowed in FIPS mode and is disabled. Figure 3 - The FortiMail web based manager Command Line Interface The FortiMail Command Line Interface (CLI) is a full-featured, text based management tool for the module. The CLI provides access to all of the possible services and configuration options in the module. The CLI uses a console connection or a network (Ethernet) connection between the FortiMail unit and the management computer. The console connection is a direct serial connection. Terminal emulation software is required on the management computer using either method. For network access, a Telnet or SSH client that supports the SSH v2.0 protocol is required (SSH v1.0 is not supported in FIPS mode). Telnet access to the CLI is not allowed in FIPS mode and is disabled. 12 FIPS 140-2 Security Policy Fortinet Inc. Module Descriptions Roles, Services and Authentication Roles, Services and Authentication Roles When configured in FIPS mode, the module provides the following roles: l Crypto Officer l User The Crypto Officer role is initially assigned to the default ‘admin’ operator account. The Crypto Officer role has read-write access to all of the module’s administrative services. The initial Crypto Officer can create additional operator accounts. These additional accounts are assigned the Crypto Officer role and can be assigned a range of read/write or read only access permissions including the ability to create operator accounts. The User role can make use of the encrypt/decrypt services, but cannot access the module for administrative purposes. The User role has access to the quarantine and email relay services as defined by a Crypto Officer. Operators can be logged in concurrently and separation is enforced via separate identities. The module does not provide a Maintenance role. FIPS Approved Services The following tables detail the types of FIPS approved services available to each role in each mode of operation, the types of access for each role and the Keys or CSPs they affect. The access types are abbreviated as follows: Read Access R Write Access W Execute Access E Table 5: Services available to Crypto Officers Service Access Key/CSP connect to module locally using the console port WE N/A FIPS 140-2 Security Policy Fortinet Inc. 13 Roles, Services and Authentication Module Descriptions Service Access Key/CSP connect to module remotely using TLS* WE Diffie-Hellman Key, EC Diffie Hellman Key, HTTPS/TLS Premaster Secret and Master Secret, HTTPS/TLS Server/Host Key, HTTPS/TLS Session Authentication Key, and HTTPS/TLS Session Encryption Key, DRBG v and key values, DRBG Output, DRBG Seed, NDRNG Output String connect to module remotely using SSH* WE Diffie-Hellman Key, SSH Server/Host Key, SSH Session Authentication Key, SSH Session Encryption Key, DRBG v and key values, DRBG Output, DRBG Seed, NDRNG Output String authenticate to module WE Crypto Officer Password show system status WE N/A show FIPS-CC mode enabled/disabled (console/CLI only) WE N/A enable FIPS-CC mode of operation (console only) WE Configuration Integrity Key key zeroization WE All Keys execute factory reset (disable FIPS-CC mode, console/CLI only) E All keys stored in Flash RAM execute FIPS-CC on-demand self-tests (console only) E Configuration Integrity Key, Firmware Integrity Key add/delete crypto officer and users WE Crypto Officer Password,User Password set/reset crypto officer and user passwords WE Crypto Officer Password, User Password modify user preferences RWE N/A backup/restore configuration file WE Configuration Encryption Key, Configuration Backup Key read/set/delete/modify module configuration RWE N/A 14 FIPS 140-2 Security Policy Fortinet Inc. Module Descriptions Roles, Services and Authentication Service Access Key/CSP execute firmware update E Firmware Update Key read log data R N/A delete log data (console/CLI only) WE N/A format log disk (console/CLI only) WE N/A enable/disable alternating bypass mode WE N/A read/set/modify HA configuration WE HA Password, HA Encryption Key Table 6: Services available to Users in FIPS-CC mode Service/CSP Access Key/CSP connect to module remotely using TLS* WE Diffie-Hellman Keys, EC Diffie-Hellman Keys, HTTPS/TLS Premaster Secret and Master Secret, HTTPS/TLS Server/Host Key, HTTPS/TLS Session Authentication Key, HTTPS/TLS Session Encryption Key, DRBG v and key values, DRBG Output, DRBG Seed, NDRNG Output String authenticate to module WE User Password access to quarantined email RE N/A modify user preferences E N/A Non-FIPS Approved Services The module also provides the following non-FIPS approved services: l Configuration backups using password protection l Services marked with an asterisk (*) in Tables 4 and 5 are considered non-approved when using the following algorithms: l Non-compliant-strength Diffie-Hellman l Non-compliant-strength RSA key wrapping The above services shall not be used in the FIPS approved mode of operation. FIPS 140-2 Security Policy Fortinet Inc. 15 Physical Security Module Descriptions Authentication The module uses identity based authentiction. By default, operators and users authenticate with a username and password combination to access the module. The username/password can be stored in the local database or in a remote LDAP database. Remote operator authentication is done over HTTPS (TLS) or SSH. Local operator authentication is done over the console connection. Remote user authentication is done over HTTPS (TLS). Password entry is obfuscated using asterisks. Note that operator authentication over HTTPS/SSH and user authentication over HTTPS are subject to a limit of 3 failed authentication attempts in 1 minute; thus, the maximum number of attempts in one minute is 3. Therefore the probability of a success with multiple consecutive attempts in a one-minute period is 3 in {(10)* (26^2)*(32)*(94^4)} which is less than 1/100,000. Operator authentication using the console is not subject to a failed authentication limit, but the number of authentication attempts per minute is limited by the bandwidth available over the serial connection which is a maximum of 115,200 bps which is 6,912,000 bits per minute. An 8 byte password would have 64 bits, so there would be no more than 108,000 passwords attempts per minute. Therefore the probability of success would be 1/({(10)*(26^2)*(32)*(94^4)} /108,000) which is less than 1/100,000. Note that the user’s username and password are not stored on the module. The module operates as a proxy for user authentication to a backend server (typically a mail server). User authentication is done over HTTPS, POP3S, or IMAPS. HTTPS, POP3S and IMAPS all use the underlying TLS protocol to protect user data between the client and the module and the module and the back end server during the authentication process. The minimum password length is 8 characters when in FIPS-CC mode (maximum password length is 32 characters) chosen from the set of ninety four (94) characters. New passwords are required to include 1 uppercase character, 1 lowercase character, 1 numeric character, and 1 special character. The odds of guessing a password are 1 in {(10)*(26^2)*(32)*(94^4)} which is significantly lower than one in a million. Physical Security The modules meet FIPS 140-2 Security Level 2 requirements by using production grade components and an opaque, sealed enclosure. Access to the enclosure is restricted through the use of tamper-evident seals to secure the overall enclosure. The tamper-evident seals shall be installed for the module to operate in a FIPS Approved mode of operation. All Networking devices need tamper-evident seals to meet the FIPS 140-2 Level 2 Physical Security requirements. The seals are red wax/plastic with black lettering that reads “Fortinet Security Seal”. The tamper seals are not applied at the factory prior to shipping. It is the responsibility of the Crypto Officer to apply the seals before use to ensure full FIPS 140-2 compliance. Once the seals have been applied, the Crypto Officer must develop an inspection schedule to verify that the external enclosure of the modules and the tamper seals have not been damaged or tampered with in any way. Upon viewing any signs of tampering, the Crypto Officer must assume that the device has been fully compromised. The Crypto Officer is required to zeroize the cryptographic module by following the steps in the Key Zeroization section of the SP. The Crypto Officer is responsible for securing and controlling any unused seals. The Crypto Office is also responsible for the direct control and observation of any changes to the modules such as reconfigurations where the tamper-evident seals are removed or installed to ensure the security of the module is maintained during such changes and ensuring the module is returned to a FIPS approved state. The surfaces should be cleaned with 99% Isopropyl alcohol to remove dirt and oil before applying the seals. Ensure the surface is completely clean and dry before applying the seals. If a seal needs to be re-applied, 16 FIPS 140-2 Security Policy Fortinet Inc. Module Descriptions Physical Security completely remove the old seal and clean the surface with an adhesive remover before following the instructions for applying a new seal. Allow 12 hours for the seals to fully cure. Additional seals can be requested through your Fortinet sales contact. Reference the ‘FIPS-SEAL-RED’ SKU when ordering. Specify the number of seals required based on the specific model as described below: The FortiMail-2000E and 3000E use two seals to secure the external enclosure as shown in the figures below. Figure 4 - External enclosure seal, left side Figure 5 - External enclosure seal, right side FIPS 140-2 Security Policy Fortinet Inc. 17 Operational Environment Module Descriptions Figure 6 - External enclosure seals, top view Operational Environment The modules consist of the combination of the FortiMail operating system and the FortiMail appliances. The FortiMail operating system can only be installed, and run, on a FortiGate appliance. The FortiMail operating system provides a proprietary and non-modifiable operating system. 18 FIPS 140-2 Security Policy Fortinet Inc. Module Descriptions Cryptographic Key Management Cryptographic Key Management Random Number Generation The modules use a firmware based, deterministic random bit generator (DRBG) that conforms to NIST Special Publication 800-90A. Entropy The module uses a Fortinet entropy token (part number FTR-ENT-1 or part number FTR-ENT-2) to seed the DRBG during the modules’ boot process and to periodically reseed the DRBG. The entropy token is not included in the boundary of the module and therefore no assurance can be made for the correct operation of the entropy token nor is there a guarantee of stated entropy. Entropy Strength The entropy loaded into the approved AES-256 bit DRBG is 256 bits. The entropy source is over-seeded and then an HMAC-SHA-256 post-conditioning component is applied. Reseed Period The RBG is seeded from the entropy token during the boot process and then reseeded periodically. The default reseed period is once every 24 hours (1440 minutes) and is configurable (1 to 1440 minutes). The entropy token must be installed to complete the boot process and to reseed the DRBG. Key Zeroization The zeroization process must be performed under the direct control of the operator. The operator must be present to observe that the zeroization method has completed successfully. All keys and CSPs are zeroized by erasing the module’s boot device and then power cycling the FortiMail unit. To erase the boot device, execute the following command from the CLI: execute erase-disk The boot device ID may vary depending on the FortiMail module. Executing the following command will output a list of the available internal disks: execute erase-disk ? Algorithms Table 7: FIPS approved algorithms Algorithm NIST Certificate Number AES in CBC mode (128-, 256-bits) 5321 FIPS 140-2 Security Policy Fortinet Inc. 19 Cryptographic Key Management Module Descriptions Algorithm NIST Certificate Number AES in GCM mode (128-, 256-bits) 5321 CTR DRBG (NIST SP 800-90A) with 256-bits 2050 CVL (SSH) - AES 128 bit-, AES 256 bit -CBC (using SHA-256) 1787 CVL (TLS 1.1 and 1.2) 1787 CVL(KAS) l FFC “dhEphem” (FC: SHA: SHA-256) l ECC “Ephemeral Unified” (EC: P-256 and ED: P-384) 1786 HMAC SHA-1 3517 HMAC SHA-256 3517 HMAC SHA-384 3517 RSA l Key Pair Generation: 2048 and 3072-bit (FIPS 186-4) l Signature Generation: 2048 and 3072-bit (PKCS1 v1.5) l Signature Verification: 1024, 2048 and 3072-bit (PKCS1 v1.5) l For legacy use, the module supports 1024-bit RSA keys and SHA- 1 for signature verification 2849 SHA-1 4271 SHA-256 4271 SHA-384 4271 KTS (AES Cert. #5321 and HMAC Cert. #3517; key establishment methodology provides 128 or 256 bits of encryption strength). In accordance with FIPS 140-2 IG D.12, the cryptographic module performs Cryptographic Key Generation (CKG) as per SP800-133 (vendor affirmed). The resulting generated symmetric key and the seed used in the asymmetric key generation are the unmodified output from SP800-90A DRBG. There are algorithms, modes, and keys that have been CAVs tested but are not available when the module is configured for FIPS compliant operation. Only the algorithms, modes/methods, and key lengths/curves/moduli shown in this table are supported by the module in the FIPS validated configuration. 20 FIPS 140-2 Security Policy Fortinet Inc. Module Descriptions Cryptographic Key Management Table 8: FIPS allowed algorithms Algorithm Diffie-Hellman (CVL Certs. #1786 and Cert. #1787, key agreement; key establishment methodology provides between 112 and 201 bits of encryption strength) EC Diffie-Hellman (CVL Certs. #1786 and Cert. #1787, key agreement; key establishment methodology provides between 128 and 256 bits of encryption strength) MD5 (used in the TLS protocol only) NDRNG (Entropy Token) RSA (key wrapping; key establishment methodology provides 112 or 128 bits of encryption strength) Table 9: Non-FIPS approved algorithms Algorithm Diffie-Hellman is non-compliant when keys less than 2048 bits are used, since such keys do not provide the minimum required 112 bits of encryption strength. RSA is non-compliant when keys less than 2048 bits are used, since such keys do not provide the minimum required 112 bits of encryption strength. Note that the SSH and TLS protocols, other than the KDF, have not been tested by the CMVP or CAVP as per FIPS 140-2 Implementation Guidance D.11. The module is compliant to IG A.5: GCM is used in the context of TLS. 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 RFC 5246 for TLS key establishment. The AES GCM IV generation is in compliance with RFC 5288 and shall only be used for the TLS protocol version 1.2 to be compliant with FIPS140-2 IG A.5, Option 1 (“TLS protocol IV generation”); thus, the module is compliant with [SP800-52]. During operational testing, the module was tested against an independent version of TLS and found to behave correctly. In case the module’s power is lost and then restored, the key used for the AES GCM encryption or decryption shall be re-distributed. Cryptographic Keys and Critical Security Parameters The following table lists all of the cryptographic keys and critical security parameters used by the modules. FIPS 140-2 Security Policy Fortinet Inc. 21 Cryptographic Key Management Module Descriptions Table 10: Cryptographic Keys and Critical Security Parameters used in FIPS-CC mode Key or CSP Generation Storage Usage Zeroization NDRNG output string Automatic Boot device Plain-text Input string for the entropy pool (5120- bits) By erasing the Boot device and power cycling the module DRBG seed Automatic Boot device Plain-text 256-bit seed used by the DRBG (output from NDRNG By erasing the Boot device and power cycling the module DRBG output Automatic Boot device Plain-text Random numbers used in cryptographic algorithms (256-bits) By erasing the Boot device and power cycling the module DRBG v and key values Automatic Boot device Plain-text Internal state values for the DRBG By erasing the Boot device and power cycling the module Diffie-Hellman Keys Automatic SDRAM Plain-text Key agreement and key establishment By erasing the boot device and power cycling the module EC Diffie-Hellman Keys Automatic SDRAM Plain- text Key agreement and key establishment (key pairs on the curves secp256r1, secp384r1 and secp521r1 By erasing the boot device and power cycling the module Firmware Update Key Preconfigured Boot device Plain-text Verification of firmware integrity when updating to new firmware versions using RSA public key (firmware load test, 2048-bit signature) By erasing the boot device and power cycling the module Firmware Integrity Key Preconfigured Boot device Plain-text Verification of firmware integrity in the firmware integrity test using RSA public key (firmware integrity test, 2048-bit signature) By erasing the boot device and power cycling the module HTTPS/TLS Server/Host Key Preconfigured Boot device Plain-text RSA private key used in the HTTPS/TLS protocols (key establishment, 2048- or 3072-bit) By erasing the boot device and power cycling the module 22 FIPS 140-2 Security Policy Fortinet Inc. Module Descriptions Cryptographic Key Management Key or CSP Generation Storage Usage Zeroization HTTPS/TLS Pre- Master Secret Automatic SDRAM Plain-text Generation of HTTPS/TLS Master Secret (384 bits) By erasing the boot device and power cycling the module HTTP/TLS Master Secret Automatic SDRAM Plain-text Generation of TLS Session Keys and TLS Authentication Key (384-bits) By erasing the boot device and power cycling the module HTTPS/TLS Session Authentication Key Automatic SDRAM Plain-text HMAC SHA-1, -256 or -384 key used for HTTPS/TLS session authentication By erasing the boot device and power cycling the module HTTPS/TLS Session Encryption Key Automatic SDRAM Plain-text AES key used for HTTPS/TLS session encryption By erasing the boot device and power cycling the module SSH Server/Host Key Preconfigured Boot device Plain-text RSA private key used in the SSH protocol (key establishment, 2048- or 3072-bit) By erasing the boot device and power cycling the module SSH Session Authentication Key Automatic SDRAM Plain-text HMAC SHA-1 or HMAC SHA-256 key used for SSH session authentication By erasing the boot device and power cycling the module SSH Session Encryption Key Automatic SDRAM Plain-text AES (128-, 256-bit) key used for SSH session encryption By erasing the boot device and power cycling the module Crypto Officer Password Manual Boot device SHA-1 hash Used to authenticate operator access to the module By erasing the boot device and power cycling the module Configuration Integrity Key Preconfigured Boot device Plain-text HMAC SHA-256 hash used for configuration integrity test By erasing the boot device and power cycling the module Configuration Encryption Key Preconfigured Boot device Plain-text AES 256-bit key used to encrypt CSPs on the Boot device and in the backup configuration file (except for crypto officer passwords in the backup configuration file) By erasing the boot device and power cycling the module FIPS 140-2 Security Policy Fortinet Inc. 23 Cryptographic Key Management Module Descriptions Key or CSP Generation Storage Usage Zeroization Configuration Backup Key Automatic Boot device Plain-text HMAC SHA-256 key used to hash crypto officer passwords in the backup configuration file By erasing the boot device and power cycling the unit User Password Manual Boot device SHA-256 hash Used to authenticate network access to the module By erasing the boot device and power cycling the unit HA Password Manual Boot device AES encrypted Used to authenticate FortiMail units in an HA cluster By erasing the boot device and power cycling the unit HA Encryption Key Manual Boot device AES encrypted Encryption of traffic between units in an HA cluster using AES 128-bit key By erasing the boot device and power cycling the unit The Generation column lists all of the keys/CSPs and their entry/generation methods. Manual entered keys are entered by the operator electronically (as defined by FIPS) using the console or a management computer. Pre-configured keys are set as part of the firmware (hardcoded) and are not operator modifiable. Automatic keys are generated as part of the associated protocol. Alternating Bypass Feature The primary cryptographic function of the module is encrypting/decrypting email messages sent/received using SMTP over TLS (SMTPS). The module can also send/receive plain-text email messages using SMTP. The module implements an alternating bypass feature based on the module’s configuration and the direction of traffic. If the traffic is sent/received using SMTPS, the module is operating in a non-bypass state. If the traffic is sent/received using SMTP, the module is operating in a bypass state. Incoming traffic is processed according to the protocol used and the domain configuration. An SMTPS message received by the module is decrypted before being processed. Once processed, if the specified domain is configured to use SMTPS, the message is encrypted before being sent to the mail server (non-bypass state). If the specified domain is configured to use SMTP, then the message is sent to the mail server in plain-text (bypass state). Outgoing traffic is processed according to the message delivery configuration. If the destination domain is configured to use SMTPS, then the message is encrypted before it is sent (non-bypass state). If the destination domain is configured to use SMTP, then the message is sent in plain-text (bypass state). Use of SMTPS for incoming traffic is enabled/disabled by checking/unchecking the “Use SMTPS” checkbox in the domain configuration. Use of SMTPS for outgoing traffic is enabled/disabled by creating a delivery policy with valid TLS and encryption profiles. 24 FIPS 140-2 Security Policy Fortinet Inc. Module Descriptions Key Archiving Key Archiving The module supports key archiving to a management computer as part of the module configuration file backup. Operator entered keys are archived as part of the module configuration file. The configuration file is stored in plain text, but keys in the configuration file are either AES encrypted using the Configuration Encryption Key or stored as a keyed hash using HMAC SHA-256 using the Configuration Backup Key. Mitigation of Other Attacks The module does not mitigate against any other attacks. FIPS 140-2 Security Policy Fortinet Inc. 25 Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) The modules comply with EMI/EMC requirements for Class A devices as specified by Part 15, Subpart B, of the FCC rules. The following table lists the specific lab and report information for the modules. FCC Report Information Module Lab Information FCC Report Number FortiMail-2000E Bay Area Compliance Laboratories Corp. 1274 Anvilwood Ave. Sunnyvale, CA 94086 (408)-732-9162 R1608171-20 FortiMail-3000E Bay Area Compliance Laboratories Corp. 1274 Anvilwood Ave. Sunnyvale, CA 94086 (408)-732-9162 R1605053-15 26 FIPS 140-2 Security Policy Fortinet Inc. FIPS 140-2 Compliant Operation The Fortinet hardware is shipped in a non-FIPS 140-2 compliant configuration. The following steps must be performed to put the module into a FIPS compliant configuration: 1. Download the model specific FIPS validated firmware image from the Fortinet Support site at https://support.fortinet.com/ 2. Verify the integrity of the firmware image 3. Install the FIPS validated firmware image 4. Install the entropy token 5. Enable the FIPS-CC mode of operation These steps are described in detail in the "add technote link" document that can be found on the Fortinet Technical Documentation website. In addition, FIPS 140-2 compliant operation requires both that you use the module in its FIPS-CC mode of operation and that you follow secure procedures for installation and operation of the FortiMail unit. You must ensure that: l The FortiMail unit is configured in the FIPS-CC mode of operation. l The FortiMail unit is installed in a secure physical location. l The tamper seals are applied as per the Physical Security instructions. l Physical access to the FortiMail unit is restricted to authorized operators. l The Fortinet entropy token is enabled. l The Fortinet entropy token remains in the USB port during operation. l Administrative passwords are at least 8 characters long. l Administrative passwords are changed regularly. l Administrator account passwords must have the following characteristics: l One (or more) characters must be capitalized l One (or more) chartacters must be lower case l One (or more) characters must be numeric l One (or more) characters must be non alpha-numeric (e.g. punctuation mark) l Administration of the module is permitted using only validated administrative methods. These are: l Console connection l Web-based manager via HTTPS l Command line interface (CLI) access via SSH l Diffie-Hellman groups of less than 2048 bits are not used. l Client side RSA certificates must use 2048 bit or greater key sizes. l Only approved and allowed algorithms are used. The module can be used in either the Gateway or Transparent modes of operation as described in the Introduction. Note that "mode of operation" in this context does not refer or have any impact on the FIPS approved mode of operation. The FIPS approved mode of operation is independent of the Gateway and Transparent modes of operation. The current operation mode is displayed on the web-based manager status page and in the output of the get system status CLI command. FIPS 140-2 Security Policy Fortinet Inc. 27 Enabling FIPS-CC mode FIPS 140-2 Compliant Operation Once the FIPS validated firmware has been installed and the module properly configured in the FIPS-CC mode of operation, the module is running in a FIPS compliant configuration. It is the responsibility of the CO to ensure the module only uses approved algorithms and services to maintain the module in a FIPS-CC Approved mode of operation. Using any of the non-approved algorithms and services switches the module to a non-FIPS mode of operation. Prior to switching between modes the CO should ensure all keys and CSPs are zeroized to prevent sharing of keys and CSPs between the FIPS Approved and non-FIPS mode of operation. Enabling FIPS-CC mode To enable the FIPS 140-2 compliant mode of operation, the operator must execute the following command from the Local Console: config system fips-cc set status enable end The Operator is required to supply a password for the admin account which will be assigned to the Crypto Officer role. The supplied password must be at least 8 characters long and correctly verified before the system will restart in FIPS-CC mode. Upon restart, the module will execute self-tests to ensure the correct initialization of the module’s cryptographic functions. After restarting, the Crypto Officer can confirm that the module is running in FIPS-CC mode by executing the following command from the CLI: get system status If the module is running in FIPS-CC mode, the system status output will display the line: FIPS-CC mode: enable 28 FIPS 140-2 Security Policy Fortinet Inc. Self-Tests Startup and Initialization Self-tests The module executes the following self-tests during startup and initialization: l Firmware integrity test using RSA 2048-bit signatures l Configuration bypass test using HMAC SHA-256 l AES, CBC mode, encrypt known answer test l AES, CBC mode, decrypt known answer test l AES, GCM mode, encrypt known answer test l AES, GCM mode, decrypt known answer test l HMAC SHA-1 known answer test l SHA-1 known answer test (tested as part of HMAC SHA-1 known answer test) l HMAC SHA-256 known answer test l SHA-256 known answer test (tested as part of HMAC SHA-256 known answer test) l HMAC SHA-384 known answer test l SHA-384 known answer test (tested as part of HMAC SHA-384 known answer test l RSA signature generation known answer test l RSA signature verification known answer test l DRBG known answer test The results of the startup self-tests are displayed on the console during the startup process. The startup self-tests can also be initiated on demand using the CLI command execute fips kat all(to initiate all self-tests) or execute fips kat (to initiate a specific self-test). When the self-tests are run, each implementation of an algorithm is tested - i.e. when the AES self-test is run, all AES implementations are tested. Conditional Self-tests The module executes the following conditional tests when the related service is invoked: l Continuous NDRNG test l Continuous DRBG test l RSA pairwise consistency test l Configuration integrity test using HMAC SHA-256 l Firmware load test using RSA signatures FIPS 140-2 Security Policy Fortinet Inc. 29 Critical Function Self-tests Self-Tests Critical Function Self-tests The module also performs the following critical function self-tests applicable to the DRBG, as per NIST SP 800- 90A Section 11: l Instantiate test l Generate test l Reseed test l Uninstantiate test Error State If any of the self-tests or conditional tests fail, the module enters an error state as shown by the console output below: Self-tests failed Entering error mode... The system is going down NOW !! The system is halted. All data output and cryptographic services are inhibited in the error state. 30 FIPS 140-2 Security Policy Fortinet Inc. Copyright© 2019 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate. Fortinet disclaims in full any covenants, representations,and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify, transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.