McAfee, Inc. McAfee Vulnerability Manager Cryptographic Module Software Version: 1.0 FIPS 140-2 Non-Proprietary Security Policy FIPS Security Level: 1 Document Version: 0.7 Prepared for: Prepared by: McAfee, Inc. Corsec Security, Inc. 2821 Mission College Blvd. 13135 Lee Jackson Memorial Hwy., Suite 220 Santa Clara, CA 95054 Fairfax, VA 22033 United States of America United States of America Phone: +1 (408) 988-3832 Phone: +1 (703) 267-6050 Email: info@mcafee.com Email: info@corsec.com http://www.mcafee.com http://www.corsec.com Security Policy, Version 0.7 April 10, 2014 Table of Contents 1 INTRODUCTION ................................................................................................................... 3 1.1 PURPOSE ................................................................................................................................................................ 3 1.2 REFERENCES .......................................................................................................................................................... 3 1.3 DOCUMENT ORGANIZATION ............................................................................................................................ 3 2 MCAFEE VMCM ...................................................................................................................... 4 2.1 OVERVIEW ............................................................................................................................................................. 4 2.1.1 Vulnerability Manager Architecture Overview ............................................................................................... 4 2.2 MODULE SPECIFICATION..................................................................................................................................... 5 2.2.1 Physical Cryptographic Boundary ...................................................................................................................... 6 2.2.2 Logical Cryptographic Boundary ........................................................................................................................ 7 2.3 MODULE INTERFACES .......................................................................................................................................... 8 2.4 ROLES AND SERVICES ........................................................................................................................................... 9 2.4.1 Crypto Officer Role ................................................................................................................................................ 9 2.4.2 User Role ................................................................................................................................................................ 10 2.4.3 Authentication ....................................................................................................................................................... 11 2.5 PHYSICAL SECURITY ...........................................................................................................................................11 2.6 OPERATIONAL ENVIRONMENT.........................................................................................................................11 2.7 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................................................11 2.7.1 Key Generation..................................................................................................................................................... 12 2.7.2 Key Entry and Output ........................................................................................................................................ 13 2.7.3 Key/CSP Storage and Zeroization .................................................................................................................. 13 2.8 EMI/EMC ............................................................................................................................................................13 2.9 SELF-TESTS ..........................................................................................................................................................13 2.9.1 Power-Up Self-Tests ............................................................................................................................................ 13 2.9.2 Conditional Self-Tests ......................................................................................................................................... 13 2.9.3 Self-Test Error Condition ................................................................................................................................... 14 2.10 MITIGATION OF OTHER ATTACKS ..................................................................................................................14 3 SECURE OPERATION ......................................................................................................... 15 3.1 SECURE MANAGEMENT .....................................................................................................................................15 3.1.1 Initialization ........................................................................................................................................................... 15 3.1.2 Management ........................................................................................................................................................ 15 3.1.3 Zeroization ............................................................................................................................................................ 15 3.2 USER GUIDANCE ................................................................................................................................................15 3.3 NON-APPROVED MODE OF OPERATION .......................................................................................................15 4 ACRONYMS .......................................................................................................................... 16 Table of Figures FIGURE 1 – GPC BLOCK DIAGRAM ........................................................................................................................................7 FIGURE 2 – MCAFEE VMCM LOGICAL CRYPTOGRAPHIC BOUNDARY .............................................................................8 List of Tables TABLE 1 – SECURITY LEVEL PER FIPS 140-2 SECTION .........................................................................................................5 TABLE 2 – FIPS-APPROVED ALGORITHM IMPLEMENTATIONS .............................................................................................6 TABLE 3 – FIPS 140-2 LOGICAL INTERFACE MAPPINGS ......................................................................................................8 TABLE 4 – CRYPTO OFFICER SERVICES ...................................................................................................................................9 TABLE 5 – USER SERVICES ..................................................................................................................................................... 10 TABLE 6 – CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS............................................... 11 TABLE 7 – ACRONYMS .......................................................................................................................................................... 16 McAfee Vulnerability Manager Cryptographic Module Page 2 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the McAfee Vulnerability Manager Cryptographic Module (Software Version: 1.0) from McAfee, Inc. This Security Policy describes how the McAfee Vulnerability Manager 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 Canada (CSEC) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/groups/STM/cmvp. This document also describes how to run the module in a secure FIPS-Approved mode of operation. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. The McAfee Vulnerability Manager Cryptographic Module is referred to in this document as VMCM, the cryptographic 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 Vulnerability Manager Cryptographic Module Page 3 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 2 McAfee VMCM 2.1 Overview McAfee® Vulnerability Manager (also called “VM”) is an agentless comprehensive asset-scanning solution capable of detecting security vulnerabilities and non-compliant configurations across millions of network- based assets. VM aggregates results from priority-based vulnerability scans into flexible reports that incorporate a patented FoundScore risk formulae to prioritize results based on vulnerability, asset criticality, and severity. VM includes up-to-date templates that assist large-scale enterprises in achieving compliance requirements such as SOX1, PCI-DSS2, HIPPA3, and FISMA4 by automating required vulnerability scans. The agent- less scans allow VM to detect new assets attached to the network and check for vulnerabilities without having to deploy or rely on preinstalled software. VM incorporates dozens of protocols in order to perform penetration testing, as well as authenticated and non-credentialed scans throughout the organization. Scans are conducted on operating system policies, database management systems, registry keys, file and drive permissions, running services, and more in order to identify threats to infrastructure security, data theft, malware and virus infestations, and more. The deployment of VM components in various ways allows organizations to centralize scanning resources at the core, or design multi-tiered, decentralized solutions allowing VM to gain awareness of every asset from servers and workstations, to printers, smartphones, and dynamic or portable assets across enclave boundaries. Additionally, VM fully integrates with other products from McAfee including ePolicy Orchestrator as well as McAfee Global Threat Intelligence servers in order to leverage the knowledge gained by McAfee Labs researchers from the aggregation of threats detected by millions of sensors around the world, providing VM with up-to-the-minute signatures and patterns for all types of vulnerabilities. 2.1.1 Vulnerability Manager Architecture Overview McAfee VM is a modular system comprised of many components that can be deployed in any number of configurations. Regardless of whether all components execute on a single platform or are distributed across many machines, they communicate using networking protocols. This design allows VM deployments to grow with an enterprise, and scale into very large, distributed networks. The software is divided into five major components which represent the distinct functionality of the VM Server:  Enterprise Manager – Uses Microsoft Internet Information Services (IIS) to provide authorized users with access to Vulnerability Manager 7.5 through their Web browsers. It allows them to manage and run Vulnerability Manager 7.5 from anywhere on the network. Access is protected by user identification and authentication. Secure Socket Layer (SSL) can be set up through the Web server to provide encrypted communications to browsers.  Database – Is the data repository for the Vulnerability Manager system. It uses Microsoft SQL Server to store everything from scan settings and results to user accounts and scan engine settings. It contains all of the information needed to track organizations and workgroups, manage users and groups, run scans, and generate reports.  API Server – Provides the communication between the enterprise manager and the database. SOX – Sarbanes-Oxley Act of 2002 1 PCI-DSS – Payment Card Industry – Data Security Standard 2 HIPAA – Health Insurance Portability and Accountability Act of 1996 3 FISMA – Federal Information Security Management Act of 2002 4 McAfee Vulnerability Manager Cryptographic Module Page 4 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014  Scan Controller – Provides the communication to the scan engines. One or more scan controller can control multiple scan engines.  Scan Engine – The server that scans the network. Depending on the logistics and size of the network, one or more scan engines may be required to scan the network. The components of version 7.5 of VM are designed to run on Windows Server 2008 R2, and all network communication between the various VM components takes place over encrypted channels created through the use of both a McAfee-proprietary cryptographic library called McAfee Vulnerability Manager Cryptographic Module as well as the collection of libraries made available by the Microsoft Cryptography API5: Next Generation (CNG). The McAfee VMCM software is written in C/C++, and compiled to run on Windows Server 2008 R2 (64- bit). The McAfee VMCM is validated at the following FIPS 140-2 Section levels listed in Table 1 below. 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 N/A6 5 Physical Security 6 Operational Environment 1 7 Cryptographic Key Management 1 EMI/EMC7 8 1 9 Self-tests 1 10 Design Assurance 3 11 Mitigation of Other Attacks N/A 2.2 Module Specification The McAfee Vulnerability Manager Cryptographic Module is a software module (Software Version: 1.0) with a multi-chip standalone embodiment. The overall security level of the module is 1. The cryptographic boundary of the module consists of McAfee VMCM library as shown by the red-colored dotted line in Figure 1 and blue-colored dotted line in Figure 2. It is designed to execute on a host General Purpose Computer (GPC) hardware platform running Windows Server 2008 R2. The module implements the FIPS-Approved algorithms listed in Table 2 below. API – Application Programming Interface 5 N/A – Not Applicable 6 EMI/EMC – Electromagnetic Interference / Electromagnetic Compatibility 7 McAfee Vulnerability Manager Cryptographic Module Page 5 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 Table 2 – FIPS-Approved Algorithm Implementations Algorithm Certificate Number Symmetric Key Algorithm AES8 – CBC9 mode (128/192/256 bits) 2176 10 11 Triple-DES – CBC mode (keying option 1 and 2 ) 1378 Asymmetric Key Algorithm RSA12 (ANSI13 X9.31) – key generation (3072 bits); signature 1122 verification (3072 bits) RSA (PKCS14 #1.5) – signature verification (3072 bits) 1122 RSA (PSS15) signature verification (3072 bits) 1122 Secure Hashing Algorithm (SHA) SHA-1, SHA-512 1888 Message Authentication Code (MAC) HMAC using SHA-1 and SHA-512 1332 Pseudo Random Number Generation (PRNG) ANSI X9.31 Appendix A.2.4 PRNG 1102 Key Establishment Method RSA encrypt/decrypt16 (3072 bits) Non-compliant (Allowed in FIPS mode for key transport17) NOTE: The following security functions have been deemed “deprecated”or “legacy-use” by NIST. Please refer to NIST Special Publication 800-131A for specific guidance on transitions to the use of stronger cryptographic keys and more robust algorithms.  ANSI X9.31 PRNG is deprecated through 2015, disallowed after 2015.  RSA signature verification with SHA-1 is legacy-use after 2010. The module also employs the following non-compliant algorithms:  1024-bit Diffie Hellman (DH) key agreement  3072-bit RSA signature generation using SHA-1 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 executes. AES – Advanced Encryption Standard 8 CBC – Cipher-Block Chaining 9 DES – Data Encryption Standard 10 11 To use the two-key Triple-DES algorithm to encrypt data in an Approved mode of operation, the module operator shall ensure that the same two-key Triple-DES key is not used for encrypting data with more than 2 20 blocks of plaintext data. RSA – Rivest Shamir Adleman 12 ANSI – American National Standards Institute 13 PKCS – Public-Key Cryptography Standards 14 PSS – Probabilistic Signature Scheme 15 16 Caveat: RSA (key wrapping; key establishment methodology provides 128 bits of encryption strength) 17 The module implements RSA encrypt/decrypt, which is non-Approved. However, a calling application may use this to implement a key transport scheme, which is allowed for use in FIPS mode. McAfee Vulnerability Manager Cryptographic Module Page 6 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 The module supports the physical interfaces of host system. These interfaces include the integrated circuits of the system board, processor, network adapters, memory, hard disk, device case, power supply, and fans. See Figure 1 for a standard GPC block diagram. Physical Cryptographic Boundary DVD Hardware RAM Network Management HDD Clock Generator SCSI/SATA Controller North Bridge Serial CPU(s) Audio South Bridge Cache PCI/PCIe Slots USB PCI/PCIe Power Graphics Slots Interface BIOS Controller External Power Supply KEY: BIOS – Basic Input/Output System PCIe – PCI express CPU – Central Processing Unit HDD – Hard Disk Drive SATA – Serial Advanced Technology Attachment DVD – Digital Video Disc SCSI – Small Computer System Interface RAM – Random Access Memory PCI – Peripheral Component Interconnect Figure 1 – GPC Block Diagram 2.2.2 Logical Cryptographic Boundary Figure 2 shows a logical block diagram of the module, where “Calling Application” represents any other McAfee-developed software/firmware component loaded on the appliance that employs the module’s services. The module’s logical cryptographic boundary (also illustrated in Figure 2) encompasses all functionality provided by the module as described in this document. McAfee Vulnerability Manager Cryptographic Module Page 7 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 Primary Storage CPU loads OS, client application, library into memory when needed Memory Module loaded at run-time Cryptographic Callling Application Module OS schedules OS translates CPU time for intermediate calling language into application machine code execution Operating System CPU runs machine code Plaintext data Encrypted data Control input Status output CPU Crypto boundary Figure 2 – McAfee VMCM Logical Cryptographic Boundary The cryptographic module is a shared library that provides cryptographic and secure communication services to the various McAfee-developed components of the Vulnerability Manager. In this document, those components will be referred as the calling application. The module is used by the calling application to provide encryption/decryption, hash verification, hashing, cryptographic key generation, random bit generation, and message authentication functions. 2.3 Module Interfaces The module’s physical ports can be categorized into the following logical interfaces defined by FIPS 140-2:  Data input  Data output  Control input  Status output As a software module, the module has no physical characteristics. The module’s physical and electrical characteristics, manual controls, and physical indicators are those of the host system. The mapping of the module’s logical interfaces in the software to FIPS 140-2 logical interfaces is described in Table 3 below. Table 3 – FIPS 140-2 Logical Interface Mappings FIPS 140-2 Interface Physical Interface Module Interface Data Input Network/Serial/USB port, DVD/CD, Function calls that accept, as their Keyboard, and Mouse arguments, data to be used or processed by the module McAfee Vulnerability Manager Cryptographic Module Page 8 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 FIPS 140-2 Interface Physical Interface Module Interface Data Output Network/Serial/USB port, DVD/CD, Arguments for a function that specify Graphics/Video port, and Audio where the result of the function is stored Control Input Network/Serial/USB port, Keyboard Function calls utilized to initiate the and Mouse, Power button module and the function calls used to control the operation of the module Status Output Network/Serial/USB port, Return values for function calls; Graphics/Video, LED indicators, and module-generated error messages Audio Power Input Power plug/adapter, Power Switch Not Applicable 2.4 Roles and Services There are two roles in the module that operators may assume: a Crypto Officer role and User role. The Crypto Officer is responsible for managing the module and monitoring the module’s status, while the User accesses the services implemented by the module. The available functions are utilized to provide or perform the cryptographic services. The various services offered by the module are described in Table 4 and Table 5. Together, these lists make up the entirety of services offered by the module when running in its Approved mode of operation. The Critical Security Parameters (CSPs) used by each service are also listed. Please note that the keys and CSPs listed in the tables use the following notation to indicate the type of access required:  R – Read: The keys and CSPs are read.  W – Write: The keys and CSPs are established, generated, modified, or zeroized.  X – Execute: The keys and CSPs are used within an Approved or Allowed security function or authentication mechanism. 2.4.1 Crypto Officer Role The Crypto Officer (CO) role is responsible for zeroizing keys and CSPs, executing self-tests, and monitoring status. Descriptions of the services available to the Crypto Officer role are provided in Table 4. Table 4 – Crypto Officer Services Service Description Input Output CSP and Type of Access Initialize module Performs integrity check API call Status Integrity check HMAC18 key – X and power-up self-tests parameters, mode Show status Returns the current API call Status None mode of the module parameters; Reboot command or cycling power Run self-tests on Performs power-up self- None Status Integrity check HMAC key – X demand tests Zeroize keys Zeroizes and de-allocates Reboot command None AES key – W memory containing or cycling power TDES19 key – W sensitive data HMAC key – W RSA private/public key – W DH components – W HMAC – (Keyed-) Hash Message Authentication Code 18 McAfee Vulnerability Manager Cryptographic Module Page 9 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 2.4.2 User Role The User role can utilize the module’s cryptographic functionalities. Descriptions of the services available to the User role are provided in Table 5. Table 5 – User Services Service Description Input Output CSP and Type of Access Generate random Returns the specified API call Status, ANSI X9.31 RNG seed – RX number (ANSI number of random bits to parameters random bits ANSI X9.31 RNG eed key – RX X9.31) calling application Generate Compute and return a API call Status, hash None message digest message digest using SHS parameters, (SHS20) algorithms message Generate keyed Compute and return a API call Status, hash HMAC key – RX hash (HMAC) message authentication code parameters, key, using HMAC SHA-1 message Symmetric Encrypt plaintext using API call Status, AES key – RX encryption supplied key and algorithm parameters, key, ciphertext TDES key – RX specification (Triple-DES or plaintext AES) Symmetric Decrypt ciphertext using API call Status, AES key – RX decryption supplied key and algorithm parameters, key, plaintext TDES key – RX specification (Triple-DES or ciphertext AES) Generate Generate and return the API call Status, key AES key – W symmetric specified type of symmetric parameters pair TDES key – W key key (Triple-DES or AES) Generate Generate and return the API call Status, key RSA private/public key – W asymmetric specified type of asymmetric parameters pair key pair key pair (RSA) Asymmetric Encrypt plaintext using RSA API call Status, RSA public key – RX encryption public key (used for key parameters, key, ciphertext transport) plaintext Asymmetric Decrypt ciphertext using API call Status, RSA private key – RX decryption RSA private key (used for parameters, key, plaintext key transport) ciphertext DH key Perform key agreement API call parameter Status, key DH components – W agreement using Diffie-Hellman components algorithm Signature Verify the signature on the API call Status RSA public key – RX Verification supplied message using the parameters, key, specified key and algorithm signature, message (RSA) TDES – Triple Data Encryption Standard 19 SHS – Secure Hash Standard 20 McAfee Vulnerability Manager Cryptographic Module Page 10 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 2.4.3 Authentication The module does not support any authentication mechanism. Operators of the module implicitly assume a role based on the service of the module being invoked. Since all services offered by the module can only be used by either the Crypto Officer or the User, the roles are mutually exclusive. Thus, when the operator invokes a Crypto Officer role service, he implicitly assumes the Crypto Officer role. When the operator invokes a User role service, he implicitly assumes the User role. 2.5 Physical Security Since this is a software module, the module relies on the target platform (a GPC appliance or customer- owned hardware platform) to provide the mechanisms necessary to meet FIPS 140-2 physical security requirements. All components of the target platform will be made of production-grade materials, and all integrated circuits coated with commercial standard passivation. 2.6 Operational Environment The McAfee VMCM was tested and found compliant with the applicable FIPS 140-2 requirements when running on the following operational environment:  Intel Xeon running 64-bit Windows Server 2008 R2 (when operating in single user mode) When compiled from the same unmodified source code, the module maintains its FIPS 140-2 compliance when running on the following supported operating platform:  Intel Celeron running 64-bit Windows Server 2008 R2 (when operating in single user mode) All cryptographic keys and CSPs are under the control of the operating system (OS), which protects the keys and CSPs against unauthorized disclosure, modification, and substitution. The module only allows access to keys and CSPs through its well-defined APIs. The module performs a Software Integrity Test using a FIPS-Approved message authentication code (HMAC SHA-1). 2.7 Cryptographic Key Management The module supports the critical security parameters listed below in Table 6. Please note that the “Input” and “Output” columns in Table 6 are in reference to the module’s logical boundary. Table 6 – Cryptographic Keys, Cryptographic Key Components, and CSPs CSP/Key CSP/Key Input Output Storage Zeroization Use Type AES key 128, 192, 256- Internally API call Plaintext in By power Encryption, bit AES key generated parameter volatile cycle or host decryption via ANSI memory reboot x9.31 PRNG TDES key 168-bit Triple- Internally API call Plaintext in By power Encryption, DES key generated parameter volatile cycle or host decryption via ANSI memory reboot x9.31 PRNG HMAC key HMAC key Internally API call Plaintext in By power Message generated parameter volatile cycle or host Authentication via ANSI memory reboot with SHS x9.31 PRNG McAfee Vulnerability Manager Cryptographic Module Page 11 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 CSP/Key CSP/Key Input Output Storage Zeroization Use Type RSA private 3072-bit RSA Input Never exits Plaintext in By power Decryption key key electronically the module volatile cycle or host in plaintext memory reboot Internally API call Used by generated parameter calling via ANSI application x9.31 PRNG RSA public key 3072-bit RSA Input Never exits Plaintext in By power Signature key electronically the module volatile cycle or host verification, in plaintext memory reboot encryption Internally API call Used by generated parameter calling via ANSI application X9.31 PRNG DH public Public Internally API call Plaintext in By power Used by components components of generated parameter volatile cycle or host calling DH protocol memory reboot application DH private Private Internally Never exits Plaintext in By power Used by component exponent of generated the module volatile cycle or host calling DH protocol memory reboot application ANSI X9.31 128-bit random Externally Never exits Plaintext in By power Generate PRNG seed value generated the module volatile cycle or host random using an memory reboot number NDRNG21 and input in plaintext ANSI X9.31 128-bit AES key Externally Never exits Plaintext in By power Generate PRNG seed generated the module volatile cycle or host random key using an memory reboot number NDRNG and input in plaintext 2.7.1 Key Generation The module uses an ANSI X9.31 Appendix A.2.4 PRNG implementation to generate cryptographic keys 22. This PRNG is FIPS-Approved (as shown in Annex C to FIPS PUB 140-2). The module also supports the generation of the RSA and Diffie-Hellman (DH) public/private keys using the RSA key generation function specified in ANSI X9.31. NDRNG – Non-Deterministic Random Number Generator 21 22 Caveat: The module generates cryptographic keys whose strengths are modified by available entropy (no assurance of the minimum strength of generated keys). McAfee Vulnerability Manager Cryptographic Module Page 12 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 2.7.2 Key Entry and Output The cryptographic module itself does not support key entry or key output. However, keys are passed to the module as parameters from the applications resident on the host platform via the exposed APIs. Keys that enter the module via an API call parameter are in plaintext. Similarly, keys and CSPs exit the module in plaintext via the APIs. 2.7.3 Key/CSP Storage and Zeroization As a software module, the module does not provide for the persistent storage of keys and CSPs. Keys and CSPs stored in RAM can be zeroized by a power cycle or a host platform reboot. Additionally, symmetric, asymmetric, and HMAC keys are either provided by or delivered to the calling process, and are subsequently destroyed by the module at the completion of the API call. The ANSI X9.31 PRNG seed and seed key are initialized by the module (externally generated and entered into the module in plaintext) at power-up and remain stored in RAM until the module is uninitialized by a host platform reboot or power cycle. The key zeroization techniques used for clearing volatile memory, once invoked, take effect immediately, and do not allow sufficient time to compromise any plaintext secret and private keys and CSPs stored by the module. 2.8 EMI/EMC The McAfee Vulnerability Manager Cryptographic Module is a software module. Therefore, the only electromagnetic interference produced is that of the host platform on which the module resides and executes. FIPS 140-2 requires that the host platforms on which FIPS 140-2 testing is performed meet the Federal Communications Commission (FCC) EMI and EMC requirements for business use as defined in Subpart B, Class A of FCC 47 Code of Federal Regulations Part 15. The host system meets these FCC requirements and the FCC certificate can be provided by the manufacturer of the hardware. 2.9 Self-Tests The McAfee Vulnerability Manager Cryptographic Module performs a set of self-tests upon power-up and conditionally during operation as required in FIPS 140-2. 2.9.1 Power-Up Self-Tests The McAfee VMCM performs the following self-tests at power-up:  Software integrity check using HMAC SHA-1  Known Answer Tests (KATs) for: o AES o Triple-DES o SHA-1 o HMAC SHA-1 o HMAC SHA-512 o RSA (sign/verify) o ANSI X9.31 RNG (Note: SHA-512 is tested as part of HMAC SHA-512 KAT.) 2.9.2 Conditional Self-Tests The module performs the following conditional self-tests:  Continuous RNG test McAfee Vulnerability Manager Cryptographic Module Page 13 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014  RSA Pairwise Consistency test 2.9.3 Self-Test Error Condition If any self-test fails, the module will enter a critical error state, during which cryptographic functionality and all data output is inhibited. To clear the error state, the CO must reboot the host platform. 2.10 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. McAfee Vulnerability Manager Cryptographic Module Page 14 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 3 Secure Operation The McAfee Vulnerability Manager Cryptographic Module meets Level 1 requirements for FIPS 140-2. The sections below describe how to place and keep the module in its FIPS-Approved mode of operation. Section 3.1 below provides guidance to the Crypto Officer for managing the module. 3.1 Secure Management The following sections provide the necessary guidance to ensure that the module is running in its Approved mode of operation. 3.1.1 Initialization When the module is installed and initialized, the module is considered to be running in its Approved mode of operation. This is achieved by calling a single initialization function FIPS_mode_set() with the parameter “1”, which is automatically invoked on the first call to SSL_library_init(). Upon initialization of the module, the module requires no set-up and runs its suite of power-up self-tests, which includes a software integrity test that checks the integrity of the module using an HMAC SHA-1 digest. If the integrity check succeeds, then the module performs cryptographic algorithm self-tests. If the module passes all the self-tests, the function will set an internal global variable and then return a value of “1” to the calling application to indicate that the module is in a Approved mode of operation or “0” to indicate test failure. 3.1.2 Management Since the Crypto Officer cannot directly interact with the module, no specific management activities are required to ensure that the module runs securely; the module only executes in an Approved mode of operation when operated according to this Security Policy. If any irregular activity is noticed or the module is consistently reporting errors, then McAfee, Inc. Customer Support should be contacted. Power-up self-tests can be performed on demand by cycling the power on the host platform, by calling the function FIPS_selftest(), or by reinitializing the module by using the FIPS_mode_set() function via SSL_library_init(). 3.1.3 Zeroization The module does not persistently store any key or CSPs. All ephemeral keys used by the module are zeroized upon session termination. All keys can be zeroized by power cycling or rebooting the host system. 3.2 User Guidance It is the responsibility of the calling application developer to ensure that only appropriate algorithms, key sizes, and key establishment techniques are applied. Users are responsible for using only the services that are listed in Table 5. Any use of the McAfee Vulnerability Manager Cryptographic Module with non- Approved cryptographic services or keys that provide less than 112 bits of encryption strength constitutes a departure from this Security Policy, and results in the module not being in its Approved mode of operation. Although the User does not have any ability to modify the configuration of the module, they should notify the Crypto Officer if any irregular activity is noticed. 3.3 Non-Approved Mode of Operation When installed, initialized, and configured according to the Crypto-Officer guidance in this Security Policy, the module does not support a non-Approved mode of operation. McAfee Vulnerability Manager Cryptographic Module Page 15 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 4 Acronyms Table 7 below defines the acronyms used in this document. Table 7 – Acronyms Acronym Definition AES Advanced Encryption Standard ANSI American National Standards Institute API Application Programming Interface CAPI Cryptography Application Programming Interface CAST Carlisle Adams and Stafford Tavares CBC Cipher Block Chaining CD Compact Disc CMVP Cryptographic Module Validation Program CNG CAPI: Next Generation CO Crypto Officer CPU Central Processing Unit CSEC Communications Security Establishment Canada CSP Critical Security Parameter DES Data Encryption Standard DH Diffie-Hellman DVD Digital Video Disc EMC Electromagnetic Compatibility EMI Electromagnetic Interference FCC Federal Communications Commission FIPS Federal Information Processing Standard FISMA Federal Information Security Management Act of 2002 GOST Gosudarstvennyy Standart (translates from German to “State Standard”) GPC General Purpose Computer HIPAA Health Insurance Portability and Accountability Act of 1996 HMAC (Keyed-) Hash Message Authentication Code IDEA International Data Encryption Algorithm IIS Internet Information Services KAS Key Agreement Scheme KAT Known Answer Test LED Light Emitting Diode McAfee Vulnerability Manager Cryptographic Module Page 16 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 0.7 April 10, 2014 Acronym Definition MAC Message Authentication Code MD Message Digest MDC Modification Detection Code N/A Not Applicable NDRNG Non-Deterministic Random Number Generator NIST National Institute of Standards and Technology OS Operating System PCI-DSS Payment Card Industry – Data Security Standard PKCS Public-Key Cryptography Standards PRNG Pseudo-Random Number Generator PSS Probabilistic Signature Scheme PUB Publication RAM Random Access Memory RC Rivest Cipher RNG Random Number Generator RSA Rivest Shamir Adleman SHA Secure Hash Algorithm SHS Secure Hash Standard SOX Sarbanes-Oxley Act of 2002 SP Special Publication SQL Structured Query Language SSL Secure Socket Layer TDES Triple Data Encryption Standard USB Universal Serial Bus VMCM Vulnerability Manager Cryptographic Module McAfee Vulnerability Manager Cryptographic Module Page 17 of 18 © 2014McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Prepared by: Corsec Security, Inc. 13135 Lee Jackson Memorial Highway, Suite 220 Fairfax, VA 22033 United States of America Phone: +1 (703) 267-6050 Email: info@corsec.com http://www.corsec.com