McAfee Inc. McAfee Linux Cryptographic Module Software Version: 1.0.1 FIPS 140-2 Non-Proprietary Security Policy FIPS Security Level: 1 Document Version: 1.3 Prepared for: Prepared by: McAfee Inc. Corsec Security, Inc. 2821 Mission College Blvd 13921 Park Center Road, Suite 460 Santa Clara, CA 95054 Herndon, VA 20171 United States of America United States of America Phone: +1 888 847 8766 Phone: +1 703 267-6050 Email: info@mcafee.com Email: info@corsec.com http://www.mcafee.com http://www.corsec.com Security Policy, Version 1.3 January 20, 2016 Table of Contents 1 INTRODUCTION ................................................................................................................... 3 1.1 PURPOSE ................................................................................................................................................................ 3 1.2 REFERENCES .......................................................................................................................................................... 3 1.3 DOCUMENT ORGANIZATION ............................................................................................................................ 3 2 MCAFEE LINUX CRYPTOGRAPHIC MODULE ................................................................. 4 2.1 OVERVIEW ............................................................................................................................................................. 4 2.2 MODULE SPECIFICATION..................................................................................................................................... 4 2.2.1 Physical Cryptographic Boundary ...................................................................................................................... 5 2.2.2 Logical Cryptographic Boundary ........................................................................................................................ 6 2.3 MODULE INTERFACES .......................................................................................................................................... 7 2.4 ROLES AND SERVICES ........................................................................................................................................... 8 2.4.1 Crypto Officer Role ................................................................................................................................................ 8 2.4.2 User Role ................................................................................................................................................................... 9 2.5 PHYSICAL SECURITY ...........................................................................................................................................10 2.6 OPERATIONAL ENVIRONMENT.........................................................................................................................10 2.7 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................................................10 2.8 SELF-TESTS ..........................................................................................................................................................16 2.8.1 Software Integrity Tests ..................................................................................................................................... 16 2.8.2 Power-Up Self-Tests ............................................................................................................................................ 16 2.8.3 Conditional Self-Tests ......................................................................................................................................... 16 2.9 MITIGATION OF OTHER ATTACKS ..................................................................................................................17 3 SECURE OPERATION ......................................................................................................... 18 3.1 CRYPTO OFFICER GUIDANCE ..........................................................................................................................18 3.1.1 Secure Installation ............................................................................................................................................... 18 3.1.2 FIPS Module Configuration ............................................................................................................................... 18 3.2 USER GUIDANCE ................................................................................................................................................18 4 ACRONYMS .......................................................................................................................... 19 Table of Figures FIGURE 1 – INTEL SR1530SH SERVER SYSTEM BLOCK DIAGRAM ......................................................................................5 FIGURE 2 – INTEL SR2625URLX SERVER SYSTEM BLOCK DIAGRAM ................................................................................6 FIGURE 3 – MCAFEE LINUX CRYPTOGRAPHIC MODULE LOGICAL BLOCK DIAGRAM ....................................................7 List of Tables TABLE 1 – SECURITY LEVEL PER FIPS 140-2 SECTION .........................................................................................................4 TABLE 2 – FIPS 140-2 LOGICAL INTERFACE MAPPINGS TO THE INTEL SR1530SH SERVER SYSTEM .............................8 TABLE 3 – FIPS 140-2 LOGICAL INTERFACE MAPPINGS TO THE INTEL SR2625URLX SERVER SYSTEM .......................8 TABLE 4 – CRYPTO OFFICER SERVICES ...................................................................................................................................9 TABLE 5 – USER SERVICES ........................................................................................................................................................9 TABLE 6 – OPENSSL FIPS-APPROVED ALGORITHM IMPLEMENTATIONS ........................................................................ 11 TABLE 7 – NETWORK PROTOCOL COMPONENT VALIDATION ...................................................................................... 12 TABLE 8 – CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS............................................... 13 TABLE 9 – ACRONYMS .......................................................................................................................................................... 19 McAfee Linux Cryptographic Module Page 2 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the McAfee Linux Cryptographic Module from McAfee Inc. This Security Policy describes how the McAfee Linux Cryptographic Module 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 (CSE) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/groups/STM/cmvp. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. The McAfee Linux Cryptographic Module may also be referred to in this document as the crypto-module or the module. 1.2 References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources:  The McAfee website (http://www.mcafee.com) contains information on the full line of products from McAfee.  The CMVP website (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm) contains contact information for individuals to answer technical or sales-related questions for the module. 1.3 Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains:  Vendor Evidence document  Finite State Model document  Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to McAfee. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Submission Package is proprietary to McAfee and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact McAfee. McAfee Linux Cryptographic Module Page 3 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 2 McAfee Linux Cryptographic Module 2.1 Overview The McAfee Linux Operating System (MLOS) v2.2.3 is a proprietary Operating System (OS) developed by McAfee in order to provide a single OS distribution that can be used across multiple McAfee products and appliances. Incorporated into MLOS 2.2.3 is the McAfee Linux Cryptographic Module, a software cryptographic library which will provide security services such as encryption, decryption, hashing, signature generation, and signature verification to McAfee software products which incorporate MLOS 2.2.3. The McAfee Linux Cryptographic Module is validated at the FIPS 140-2 Section levels shown in Table 1: Table 1 – Security Level Per FIPS 140-2 Section Section Section Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and Interfaces 1 3 Roles, Services, and Authentication 1 4 Finite State Model 1 5 Physical Security N/A 6 Operational Environment 1 7 Cryptographic Key Management 1 1 8 EMI/EMC 1 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A 2.2 Module Specification The McAfee Linux Cryptographic Module is a software cryptographic module (Software Version: 1.0.1) with a multichip standalone embodiment. The overall security level of the module is Level 1. The McAfee Linux Cryptographic Module is a shared cryptographic library providing symmetric and asymmetric encryption and decryption, hashing, message authentication, key generation, and digital signature generation and verification. The McAfee Linux Cryptographic Module consists of OpenSSL 1.0.1j and a “FIPS Controller Daemon” that controls the operational status of the module. The module was tested and found to be FIPS 140-2 compliant on three separate Intel Server Systems executing McAfee Linux Operating System v2.2.3. Section 2.6 provides the full list of operational environments on which the module was tested. Because the McAfee Linux Cryptographic Module is defined as a software cryptographic module, it possesses both a logical cryptographic boundary and a physical cryptographic boundary. The physical and logical boundaries are outlined in Section 2.2.1 and 2.2.2 respectively. EMI/EMC – Electromagnetic Interference / Electromagnetic Compatibility 1 McAfee Linux Cryptographic Module Page 4 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 2.2.1 Physical Cryptographic Boundary As a software cryptographic module, there are no physical protection mechanisms implemented. Therefore, the module must rely on the physical characteristics of the host system. The physical boundary of the cryptographic module is defined by the hard enclosure around the host system on which it runs. The module supports the physical interfaces an Intel Server System hardware appliance. These interfaces include the integrated circuits of the system board, processor, network adapters, RAM 2, hard disk, device case, power supply, and fans. Figure 1 and Figure 2 provide block diagram representations of each Intel Server System hardware appliance. DVD Network Hardware RAM Management Interface HDD Clock SCSI/SATA Generator Controller LEDs Serial CPU(s) I/O Hub Audio Cache PCI/PCIe Slots USB BIOS PS/2 Power Graphics PCI/PCIe Interface Controller Slots KEY: BIOS – Basic Input/Output System PCIe – PCI express CPU – Central Processing Unit HDD – Hard Disk Drive Plaintext data SATA – Serial Advanced Technology Attachment DVD – Digital Video Disc Encrypted data SCSI – Small Computer System Interface USB – Universal Serial Bus Control input PCI – Peripheral Component Interconnect RAM – Random Access Memory Status output LED – Light Emitting Diode PS/2 – Personal System 2 Crypto boundary I/O – Input/Output Figure 1 – Intel SR1530SH Server System Block Diagram RAM – Random Access Memory 2 McAfee Linux Cryptographic Module Page 5 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 DVD Network Hardware RAM Management Interface HDD Clock SCSI/SATA Generator Controller LEDs Serial CPU(s) I/O Hub Audio Cache PCI/PCIe Slots USB BIOS Power Graphics PCI/PCIe Interface Controller Slots KEY: BIOS – Basic Input/Output System PCIe – PCI express Plaintext data CPU – Central Processing Unit HDD – Hard Disk Drive Encrypted data SATA – Serial Advanced Technology Attachment DVD – Digital Video Disc Control input SCSI – Small Computer System Interface USB – Universal Serial Bus Status output PCI – Peripheral Component Interconnect RAM – Random Access Memory Crypto boundary LED – Light Emitting Diode I/O – Input/Output Figure 2 – Intel SR2625URLX Server System Block Diagram 2.2.2 Logical Cryptographic Boundary Figure 3 shows a logical block diagram of the module executing in memory and its interactions with surrounding software components, as well as the module’s logical cryptographic boundary. The cryptographic module consists of OpenSSL 1.0.1j and the FIPS Controller Daemon. These files are collectively shown as “McAfee Linux Cryptographic Module” in the diagram below. The module’s services are designed to be called by applications developed by McAfee. The module’s logical boundary is a contiguous perimeter that surrounds all memory-mapped functionality provided by the module when loaded and stored in the host platform’s memory McAfee Linux Cryptographic Module Page 6 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 McAfee Linux Cryptographic Calling Application Module McAfee Linux Operating System User Space Kernel Space CPU Memory Storage System Calls Control Input Data Input Data Output Status Output Logical Cryptographic Boundary Figure 3 – McAfee Linux Cryptographic Module Logical Block Diagram 2.3 Module Interfaces The module’s logical interfaces exist at a low level in the software as an Application Programming Interface (API). Both the API and physical interfaces can be categorized into the following interfaces defined by FIPS 140-2:  Data input  Data output  Control input  Status output  Power input As a software module, the module has no physical characteristics. Thus, the module’s manual controls, physical indicators, and physical and electrical characteristics are those of the Intel Server System. A mapping of the FIPS 140-2 logical interfaces, the physical interfaces, and the module interfaces while the module is executing on the Intel SR1530SH Server System can be found in Table 2 below. McAfee Linux Cryptographic Module Page 7 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 Table 2 – FIPS 140-2 Logical Interface Mappings to the Intel SR1530SH Server System FIPS Interface Physical Interface Module Interface (API) Data Input USB ports (3), network interfaces The API calls that accept input data for (2), serial ports (2), DVD drive (1) processing through their arguments. Data Output USB ports (3), network interfaces The API calls that return by means of their (2), serial ports (1), DVD drive (1) return codes or arguments generated or processed data back to the caller. Control Input USB ports (3), network interfaces The API calls that are used to initialize and (2), serial ports(1), PS/2 ports (2) control the operation of the module. Status Output LED (7), network interfaces (2), Return values for API calls. Values translated to serial ports (1), display port (1) either logical or physical status output. A mapping of the FIPS 140-2 logical interfaces, the physical interfaces, and the module interfaces while the module is executing on the Intel SR2625URLX Server Systems can be found in Table 3 below. Table 3 – FIPS 140-2 Logical Interface Mappings to the Intel SR2625URLX Server System FIPS Interface Physical Interface Module Interface (API) Data Input USB ports (5), network interfaces The API calls that accept input data for (2), serial ports (2), DVD drive (1) processing through their arguments. Data Output USB ports (5), network interfaces The API calls that return by means of their (2), serial ports (2), DVD drive (1) return codes or arguments generated or processed data back to the caller. Control Input USB ports (5), network interfaces The API calls that are used to initialize and (2), serial ports (2) control the operation of the module. Status Output LEDs (8), network interfaces (2), Return values for API calls. Values translated to serial ports (2), display port (1) either logical or physical status output. 2.4 Roles and Services The module supports role-based authentication. There are two roles in the module (as required by FIPS 140- 2) that operators may assume: a Crypto Officer (CO) role and a User role. Each role and their corresponding services are detailed in the sections below. Please note that the keys and Critical security Parameters (CSPs) listed in the tables below indicate the type of access required using the following notation:  R – Read: The CSP is read.  W – Write: The CSP is established, generated, modified, or zeroized.  X – Execute: The CSP is used within an Approved or Allowed security function or authentication mechanism. 2.4.1 Crypto Officer Role The CO has the ability to initialize the module for first use, run on-demand self-tests, manage operator passwords, and zeroize keys. Descriptions of the services available to the CO role are provided in Table 4 below. McAfee Linux Cryptographic Module Page 8 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 Table 4 – Crypto Officer Services Service Description CSP and Type of Access Initialize FIPS module configuration Sets the FIPS flag to “1”; Performs None integrity check and power-up self- tests. Run self-tests on demand Performs power-up self-tests None Zeroize key Zeroizes and de-allocates memory All Keys and CSPs – W containing sensitive data Show Status View the status of the module None 2.4.2 User Role The User role performs general security services, including cryptographic operations and other Approved security functions such as random number generation, encryption and decryption, message authentication, and signature generation and verification. Descriptions of the services available to the User role are provided in Table 5 below. Table 5 – User Services Service Description CSP and Type of Access DRBG3 Seed: WRX Generate random number Returns the specified number of random bits to calling application DRBG Entropy: RX Generate message digest (SHS4) Compute and return a message None digest using SHS algorithms HMAC5 key – RX Generate keyed hash Compute and return a message AES6 GCM7 Key – RX authentication code AES CMAC8 Key: WRX Triple-DES9 CMAC Key: WRX Generate Symmetric Key Generate keys and return the AES key – W specified symmetric key (Triple- AES GCM Key – W AES GCM IV10 – WRX DES or AES) XTS11,12,13-AES Key – W AES CMAC Key – W Triple-DES key – W Triple-DES CMAC Key – W DRBG – Deterministic Random Bit Generator 3 SHS – Secure Hash Standard 4 5 HMAC – (keyed-) Hash-based Message Authentication Code 6 AES – Advance Encryption Service 7 GCM – Galois Counter Mode 8 CMAC – Cipher-based Message Authentication Code 9 DES – Data Encryption Standard 10 IV – Initialization Vector 11 XTS - XEX-based tweaked-codebook mode with ciphertext stealing 12 XEX – XOR-Encrypt-XOR 13 XOR – Exclusive Or McAfee Linux Cryptographic Module Page 9 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 Service Description CSP and Type of Access Symmetric encryption Encrypt plaintext using supplied AES key – RX key and algorithm specification AES GCM Key – RX (Triple-DES or AES) AES GCM IV – RX XTS-AES Key – RX Triple-DES key – RX Symmetric decryption Decrypt ciphertext using supplied AES key – RX key and algorithm specification AES GCM Key – RX (Triple-DES or AES) AES GCM IV – RX XTS-AES Key – RX Triple-DES key – RX RSA14 private/public key – W Generate asymmetric Generate and return the specified DSA15 private/public key – W key pair type of asymmetric key pair (RSA or DSA) RSA encapsulation Encrypt plaintext using RSA public RSA public key – RX key (used for key transport) 2.5 Physical Security The McAfee Linux Cryptographic Module is a software module, which FIPS defines as a multi-chip standalone cryptographic module. As such, it does not include physical security mechanisms. Thus, the FIPS 140-2 requirements for physical security are not applicable. 2.6 Operational Environment The operational environment of the McAfee Linux Cryptographic Module consists of an Intel Server System hardware platform executing MLOS v2.2.3. The module was tested and found to be FIPS 140-2 compliant in the following operational environments:  MLOS v2.2.3 (64-bits) running on an Intel Celeron Processor operating on an Intel SR1530SH Server System hardware appliance  MLOS v2.2.3 (64-bits) running on an Intel Xeon Processor operating on an Intel SR2625URLX Server System hardware appliance  MLOS v2.2.3 (64-bits) on a VMware ESXi 5.0 hypervisor executing on an Intel SR2625URLX Server System hardware appliance using an Intel Xeon Processor All keys, intermediate values, and other CSPs remain in the process space of a single operator. The OS provides process isolation for all user-mode processes through private virtual address spaces (private per process page tables), execution context (registers, program counters), and security context (handle table and token). 2.7 Cryptographic Key Management The module implements the FIPS-Approved algorithms listed in Table 6 below. RSA – Rivest, Shamir, Adleman 14 DSA – Digital Signature Algorithm 15 McAfee Linux Cryptographic Module Page 10 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 Table 6 – OpenSSL FIPS-Approved Algorithm Implementations Certificate Certificate Number Number (Virtual Algorithm (Hardware Environment) Environment) Encryption and Decryption AES encryption/decryption in ECB , CBC , CTR19, CFB120, CFB8, CFB128, 16 17 18 3116 3117 and OFB21modes with 128-,192-, and 256-bit keys AES GCM22 encryption/decryption with 128-, 192-, and 256-bit keys 3116 3117 23 Triple-DES encryption/decryption in ECB, CBC, CFB1, CFB8, CFB64, and 1787 1788 OFB modes; 3-key Key Generation; Signature Generation and Verification 24 RSA Key-pair Generation (FIPS 186-4) of 2048- and 3072-bit keys 1587 1588 RSA (FIPS 186-4) ANSI25 X9.31, PKCS #1.5, PSS signature generation – 2048- 1587 1588 and 3072-bit RSA (FIPS 186-4) ANSI X9.31, PKCS #1.5, PSS signature verification – 1024-, 1587 1588 2048-, and 3072-bit (Legacy Use: 1024) RSA (FIPS 186-2) ANSI X9.31, PKCS #1.5, PSS signature verification – 1024-, 1587 1588 2048-, 3072-, and 4096-bit (Legacy Use: 1024) DSA26 Key-pair Generation of 2048- and 3072-bit keys 900 901 DSA Signature Generation (2048- and 3072-bits) and Verification (1024-, 900 901 2048-, 3072-bits) (Legacy Use for Verification: 1024) DSA PQG Generation (2048- and 3072-bits) and Verification (1024-, 2048-, 900 901 3072-bits) (Legacy Use for Verification: 1024) Hashing and Message Authentication 27 SHA -1, SHA-224, SHA-256, SHA-384, SHA-512 2572 2573 HMAC28 with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 1953 1954 29 30 AES CMAC and CCM Message Authentication with 128-, 192-, and 256-bit 3116 3117 keys AES – Advance Encryption Standard 16 ECB – Electronic Code Book 17 18 CBC – Cipher Block Chaining 19 CTR - Counter 20 CFB – Cipher Feedback 21 OFB – Output Feedback 22 GCM – Galois Counter Mode 23 DES – Data Encryption Standard 24 RSA – Rivest, Shamir, Adleman 25 ANSI – American National Standards Institute 26 DSA – Digital Signature Algorithm 27 SHA – Secure Hash Algorithm 28 HMAC – (keyed-) Hash-based Message Authentication Code 29 CMAC – Cipher-based Message Authentication Code 30 CCM – Counter with CBC-MAC McAfee Linux Cryptographic Module Page 11 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 Certificate Certificate Number Number (Virtual Algorithm (Hardware Environment) Environment) AES GCM (GMAC31) message authentication with 128-, 192-, and 256-bit 3116 3117 keys Triple-DES CMAC; 3-key 1787 1788 Random Number Generation SP32800-90A HASH, HMAC, and CTR DRBG 627 628 The cryptographic module implements the TLS and SSH secure networking protocols. Each protocol implements a Key Derivation Function (KDF) listed in NIST SP 800-135rev1 and has been validated by the CMVP. There certificate numbers are provided in Table 7. The complete protocol implementations have not been reviewed or tested by the CAVP 33 and CMVP. Outside the cryptographic module boundary the McAfee Linux Operating System employs a non-Approved Non-Deterministic Random Number Generator (NDRNG), which is used as an entropy source for seeding the Approved DRBGs listed in Table 6. Its use is allowed per FIPS 140-2 Implementation Guidance 7.11. Table 7 – Network Protocol Component Validation Certificate Certificate Number Number (Virtual Algorithm (Hardware Environment) Environment) TLS34 1.0/1.1 and TLS 1.2 KDF using SHA 256 and SHA 378 379 384 SSH KDF using SHA-256, -384, and -512 378 379 SNMP KDF using SHA-1 378 379 The module employs the following key establishment methodologies:  RSA (2048- and 3072-bit keys; key establishment methodology provides 112 or 128 bits of encryption strength).  Diffie-Hellman (2048- and 3072-bit keys; key agreement; key establishment methodology provides 112 or 128 bits of encryption strength) GMAC – Gallois Message Authentication Code 31 SP – Special Publication 32 33 CAVP – Cryptographic Algorithm Validation Program 34 TLS – Transport Layer Security McAfee Linux Cryptographic Module Page 12 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 The module supports the CSPs listed below in Table 8. Table 8 – Cryptographic Keys, Cryptographic Key Components, and CSPs CSP CSP Type Generation / Output Storage Zeroization Use Input AES key AES128-, 192-, 256- Internally generated Output in plaintext Keys are not Unload module; Encryption, via approved DRBG; via GPC35 INT bit key persistently stored API call; decryption Path36 or by the module Remove Power Input via API call parameter AES GCM Key AES 128- , 192-, or Internally generated Output in plaintext Keys are not Unload module; Encrypt and decrypt 256-bit key via approved DRBG; via GPC INT Path persistently stored API call; blocks of data; or by the module Remove Power Keyed Message Input via API call Authentication parameter Code AES GCM IV 96 bits of Random Internally Generated Never Keys are not Unload module; IV input to AES data via approved DRBG persistently stored API call; GCM function by the module Remove Power AES CMAC Key AES 128-, 192-, or Internally generated Output in plaintext Keys are not Unload module; Keyed Message 256-bit key via approved DRBG; via GPC INT Path persistently stored API call; Authentication or by the module Remove Power Code Input via API call parameter TDES key TDES 168 bit key Internally generated Output in plaintext Keys are not Unload module; Encryption, via approved DRBG; via GPC INT Path persistently stored API call; decryption or by the module Remove Power Input via API call parameter GPC – General Purpose Computer 35 36 GPC INT Path defined in Implementation Guidance (IG) 7.7 McAfee Linux Cryptographic Module Page 13 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 CSP CSP Type Generation / Output Storage Zeroization Use Input TDES CMAC Key TDES 168 bit key Internally generated Output in plaintext Keys are not Unload module; Keyed Message via approved DRBG; via GPC INT Path persistently stored API call; Authentication or by the module Remove Power Code Input via API call parameter HMAC key HMAC SHA-1, Internally generated Output in plaintext Keys are not Unload module; Message SHA-224, SHA-256, via approved DRBG; via GPC INT Path persistently stored API call; Authentication with SHA-384, or SHA- or by the module Remove Power SHS 512 key Input via API call parameter RSA private key RSA 2048- or 3072- Internally generated Output in plaintext Keys are not Unload module; Signature bit key via approved DRBG; via GPC INT Path persistently stored API call; generation, or by the module Remove Power decryption Input via API call parameter RSA public key RSA 1024-, 1536-, Internally generated Output in plaintext Keys are not Unload module; Signature 2048-, 3072-, or via approved DRBG; via GPC INT Path persistently stored API call; verification, 4096- bit key or by the module Remove Power encryption Input via API call parameter DSA private key DSA 2048- or 3072- Internally generated Output in plaintext Keys are not Unload module; Signature generation bit key via approved DRBG; via GPC INT Path persistently stored API call; or by the module Remove Power Input via API call parameter DSA public key DSA 1024, 2048, or Internally generated Output in plaintext Keys are not Unload module; Signature 3072 bit key via approved DRBG; via GPC INT Path persistently stored API call; verification or by the module Remove Power Input via API call parameter McAfee Linux Cryptographic Module Page 14 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 CSP CSP Type Generation / Output Storage Zeroization Use Input DH37 public Public components Internally generated Output in plaintext Keys are not Unload module; Used by host components of DH protocol via approved DRBG; via GPC INT Path persistently stored API call; application or by the module Remove Power Input via API call parameter DH private Private exponent of Internally generated Output in plaintext Keys are not Unload module; Used by host component DH protocol via approved DRBG; via GPC INT Path persistently stored API call; application or by the module Remove Power Input via API call parameter Random data38 DRBG Seed Internally Generated Never Keys are not Unload module; Seeding material for persistently stored API call; SP 800-90A DRBGs by the module Remove Power DRBG Entropy Random data Externally Never Plaintext in volatile Unload module; Entropy material for (75203 Bytes) Generated; memory API call; SP 800-90A DRBGs Input via API Remove Power DRBG ‘C’ Value Internal state value Internally Generated Never Plaintext in volatile Unload module; Used for memory API call; Hash_DRBG Remove Power DRBG ‘V’ Value Internal state value Internally Generated Never Plaintext in volatile Unload module; Used for memory API call; Hash_DRBG, Remove Power HMAC_DRBG, and CTR_DRBG DRBG ‘Key’ Value Internal state value Internally Generated Never Plaintext in volatile Unload module; Used for memory API call; HMAC_DRBG and Remove Power CTR_DRBG DH – Diffie-Hellman 37 38 Length of seed value is dependent on the implementation. Please refer to SP 800-90A DRBG specification. McAfee Linux Cryptographic Module Page 15 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 2.8 Self-Tests Cryptographic self-tests are performed by the module when the module is first powered up and loaded into memory as well as when a random number or asymmetric key pair is created. The following sections list the self-tests performed by the module, expected error status, and error resolution. 2.8.1 Software Integrity Tests The module performs an HMAC SHA-256 integrity test on itself, and then the entirety of MLOS. If either the module or MLOS integrity tests fail, the FIPS Controller Daemon will log the error and halt all system processes, ensuring that data output from the module is inhibited. In order to resolve a cryptographic self- test error, the FIPS Controller Daemon will reboot the OS. If the error persists, the module must be reinstalled. 2.8.2 Power-Up Self-Tests Power-up Self-tests are performed by the module when the module is first loaded into memory. The list of power-up self-tests may also be run on-demand when the CO reboots the Operating System. The module will perform the listed power-up self-tests to completion. During the execution of self-tests, data output from the module is inhibited. If any of the self-tests fail, the FIPS Controller Daemon will log the error and halt all system processes, ensuring that data output from the module is inhibited. In order to resolve a cryptographic self-test error, the FIPS Controller Daemon will reboot the OS. If the error persists, the module must be reinstalled. The McAfee Linux Cryptographic Module performs the following self-tests at power-up:  OpenSSL AES Encrypt KAT  OpenSSL AES Decrypt KAT  OpenSSL AES CMAC KAT  OpenSSL AES CCM Encrypt KAT  OpenSSL AES CCM Decrypt KAT  OpenSSL AES GCM Encrypt KAT  OpenSSL AES GCM Decrypt KAT  OpenSSL AES XTS Encrypt KAT  OpenSSL AES XTS Decrypt KAT  OpenSSL Triple-DES Encrypt KAT  OpenSSL Triple-DES Decrypt KAT  OpenSSL Triple-DES CMAC KAT  OpenSSL RSA Sign KAT  OpenSSL RSA Verify KAT  OpenSSL DSA PCT39  OpenSSL SHA-1 KAT  OpenSSL HMAC with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 KAT40  OpenSSL ANSI X9.31 KAT  OpenSSL SP 800-90A DRBG KAT 2.8.3 Conditional Self-Tests Conditional self-tests are performed by the module whenever a new random number is generated or when a new RSA or DSA key pair is generated. If any of the self-tests fail, the FIPS Controller Daemon will log the PCT – Pairwise Consistency Test 39 40 OpenSSL satisfies the SHA-224, SHA-256, SHA-384, SHA-512 KAT requirements by performing these HMAC KATs McAfee Linux Cryptographic Module Page 16 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 error and halt all system processes, ensuring that data output from the module is inhibited 41. In order to resolve a cryptographic self-test error, the FIPS Controller Daemon will reboot the OS. If the error persists, the module must be reinstalled. The McAfee Linux Cryptographic Module performs the following conditional self-tests:  OpenSSL SP 800-90A DRBG Continuous Random Number Generator Test (CRNGT)  OpenSSL SP 800-90A DRBG Reseed CRNGT  OpenSSL RSA Key Generation PCT  OpenSSL DSA Key Generation PCT 2.9 Mitigation of Other Attacks This section is not applicable. The modules do not claim to mitigate any attacks beyond the FIPS 140-2 Level 1 requirements for this validation. 41 The Continuous Random Number Generator Test in OpenSSL must fail twice in a row in order to produce this result. The second CRNGT is run immediately after the first CRNGT fails – no cryptographic processes are run in-between the first and second CRNGT and are not allowed to run again until the second CRNGT passes; All other cryptographic self- tests will only need to fail once. McAfee Linux Cryptographic Module Page 17 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 3 Secure Operation The McAfee Linux Cryptographic Module meets Level 1 requirements for FIPS 140-2. The sections below describe how to place and keep the module in operation. 3.1 Crypto Officer Guidance This section describes the steps the CO must take to place the module into operation. 3.1.1 Secure Installation The McAfee Linux Cryptographic Module is installed as part of the McAfee Linux Operating System installation. A CO shall use the following procedures to install the McAfee Linux Cryptographic Module: 1. Contact McAfee to obtain the MLOS version 2.2.3 build 5642 image. 2. Burn the image onto a blank DVD 3. Place the DVD into the disc drive of the device you would like to install MLOS 4. Reboot the device; specifying to boot from the disc drive 5. Follow the prompts provided by the installation wizard to successfully install the operating system 3.1.2 FIPS Module Configuration In order to place the McAfee Linux Cryptographic Module in operation, the CO must perform the following steps from the MLOS CLI42: 1. Install FIPS RPMs # yum install mlos-fipserror mlos-fipshook mlos-fipstest mlosfipscheck fipscheck-devel 2. Update OpenSSL and libgcrypt (to contain FIPS hooks) # yum update openssl libgcrypt 3. Re-write the grub.conf file # /lib/fips/fipsgrub 4. Create integrity hmac (checksums) # /lib/fips/fipshmac 5. Reboot # reboot 3.2 User Guidance The McAfee Linux Cryptographic Module does not input, output, or persistently store CSPs within its logical boundary. However, the module may store CSPs within the physical boundary of the host system on which it runs. Operators are responsible for providing persistent storage of the cryptographic keys and CSPs, and to ensure that keys are transmitted outside the physical cryptographic boundary in the appropriate manner. The McAfee Linux Cryptographic Module includes libgcrypt within its cryptographic boundary. However, the user of the McAfee Linux Cryptographic Module must only use the cryptographic services as documented within this Security Policy. CLI – Command Line Interface 42 McAfee Linux Cryptographic Module Page 18 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 4 Acronyms Table 9 provides definitions for the acronyms used in this document. Table 9 – Acronyms Acronym Definition AES Advanced Encryption Standard API Application Programming Interface ANSI American National Standards Institute BIOS Basic Input/Output System CAVP Cryptographic Algorithm Validation Program CBC Cipher Block Chaining CCM Counter with CBC-MAC CFB Cipher Feedback CLI Command Line Interface CMAC Cipher-based Message Authentication Code CMVP Cryptographic Module Validation Program CO Cryptographic Officer CPU Central Processing Unit CRNGT Continuous Random Number Generator Test CSE Communications Security Establishment CSP Critical Security Parameter CTR Counter DES Data Encryption Standard DH Diffie-Hellman DSA Digital Signature Algorithm DRBG Deterministic Random Bit Generator DVD Digital Video Disc ECB Electronic Code Book EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard GCM Gallois Counter Mode GPC General Purpose Computer HDD Hard Disk Drive HMAC (Keyed-) Hash Message Authentication Code McAfee Linux Cryptographic Module Page 19 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.3 January 20, 2016 Acronym Definition INT Internal IV Initialization Vector KAT Known Answer Test LCD Liquid Crystal Display LED Light Emitting Diode MLOS McAfee Linux Operating System NDRNG Non-Deterministic Random Number Generator NIST National Institute of Standards and Technology OFB Output Feedback OS Operating System PCI Peripheral Component Interconnect PCIe PCI express PCT Pairwise Consistency Test PKCS Public Key Cryptography Standard PRNG Pseudo-Random Number Generator PSS Probabilistic Signature Scheme RAM Random Access Memory RC Rivest Cipher RSA Rivest, Shamir, Adleman SATA Serial Advanced Technology Attachment SCSI Small Computer System Interface SHA Secure Hash Standard SHS Secure Hash Standard SP Special Publication TLS Transport Layer Security USB Universal Serial Bus VGA Video Graphics Array XEX XOR-Encrypt-XOR XOR Exclusive Or XTS XEX-based tweaked-codebook mode with ciphertext stealing McAfee Linux Cryptographic Module Page 20 of 21 © 2016 McAfee Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Prepared by: Corsec Security, Inc. 13921 Park Center Road Suite 460 Herndon, VA 20171 United States of America Phone: +1 (703) 267-6050 Email: info@corsec.com http://www.corsec.com