McAfee, Inc. McAfee Core Cryptographic Module (user) 1.0 FIPS 140-2 Non-Proprietary Security Policy Level 1 Validation Document revision 015, August 2014 Prepared for McAfee, Inc. by McAfee, Inc. 2821 Mission College Blvd. Santa Clara, CA 95054 888.847.8766 www.mcafee.com Rycombe Consulting Limited http://www.rycombe.com +44 1273 476366 © 2014 McAfee, Inc. This document may be reproduced only in its original entirety [without revision]. www.mcafee.com Contents 1 Introduction ............................................................................................................................................. 4 1.1 Identification ..................................................................................................................................... 4 1.2 Purpose.............................................................................................................................................. 4 1.3 References ......................................................................................................................................... 4 1.4 Document Organization .................................................................................................................... 4 1.5 Document Terminology..................................................................................................................... 4 2 McAfee Core Cryptographic Module (user)............................................................................................. 5 2.1 Overview ........................................................................................................................................... 5 2.2 Module Specification......................................................................................................................... 6 2.2.1 Hardware, Software and Firmware components ...................................................................... 6 2.2.2 Cryptographic Boundary ............................................................................................................ 6 2.2.3 Scope of Evaluation.................................................................................................................... 8 2.2.4 Cryptographic Algorithms .......................................................................................................... 8 2.2.5 Components excluded from the security requirements of the standard ................................. 9 2.3 Physical ports and logical interfaces ................................................................................................. 9 2.4 Roles, Services and Authentication ................................................................................................. 10 2.4.1 Roles ......................................................................................................................................... 10 2.4.2 Services .................................................................................................................................... 10 2.4.3 Authentication ......................................................................................................................... 14 2.5 Physical Security .............................................................................................................................. 14 2.6 Operational Environment................................................................................................................ 15 2.7 Cryptographic Key Management .................................................................................................... 17 2.7.1 Random Number Generators .................................................................................................. 17 2.7.2 Key Generation ........................................................................................................................ 17 2.7.3 Key Table .................................................................................................................................. 17 2.7.4 Key Destruction ........................................................................................................................ 18 2.7.5 Access to Key Material ............................................................................................................. 19 2.8 Self-Tests ......................................................................................................................................... 20 2.8.1 Power-up self-tests .................................................................................................................. 20 2.8.2 Conditional self-tests ............................................................................................................... 20 2.9 Design Assurance ............................................................................................................................ 20 2.10 Mitigation of Other Attacks ......................................................................................................... 21 Figures Figure 1 Document terminology ...................................................................................................................... 5 Figure 2 Module binary image ......................................................................................................................... 6 Figure 3 Block Diagram of the Cryptographic Boundary (Pre-boot environment) .......................................... 7 Figure 4 Block Diagram of the Cryptographic Boundary (Windows / MacOS environments) ........................ 7 Figure 5 Security Level specification per individual areas of FIPS 140-2 ......................................................... 8 Figure 6 Approved Algorithms ......................................................................................................................... 8 Figure 7 Module Interfaces ............................................................................................................................ 10 2 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com Figure 8 Roles ................................................................................................................................................. 10 Figure 9 User Services .................................................................................................................................... 13 Figure 10 Crypto Officer Services................................................................................................................... 13 3 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com 1 Introduction This section identifies the cryptographic module; describes the purpose of this document; provides external references for more information; and explains how the document is organized. 1.1 Identification Module Name McAfee, Inc. McAfee Core Cryptographic Module (user) Module Version 1.0 Software Version 1.0 1.2 Purpose This is the non-proprietary FIPS 140-2 Security Policy for the McAfee Core Cryptographic Module (user), also referred to as “the module” within this document. This Security Policy details the secure operation of McAfee Core Cryptographic Module (user) as required in Federal Information Processing Standards Publication 140-2 (FIPS 140-2) as published by the National Institute of Standards and Technology (NIST) of the United States Department of Commerce. 1.3 References For more information on McAfee products please visit: http://www.mcafee.com. For more information on NIST and the Cryptographic Module Validation Program (CMVP), please visit http://csrc.nist.gov/groups/STM/cmvp/index.html. 1.4 Document Organization This Security Policy document is one part of the FIPS 140-2 Submission Package. This document outlines the functionality provided by the module and gives high-level details on the means by which the module satisfies FIPS 140-2 requirements. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Submission documentation may be McAfee, Inc. proprietary or otherwise controlled and releasable only under appropriate non-disclosure agreements. For access to these documents, please contact McAfee, Inc. The various sections of this document map directly onto the sections of the FIPS 140-2 standard and describe how the module satisfies the requirements of that standard. 1.5 Document Terminology TERM DESCRIPTION AES Advanced Encryption Standard AES-NI Advanced Encryption Standard New Instructions. Seven instructions for accelerating different sub-steps of the AES algorithm included in some Intel and AMD microprocessors. 4 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com API Application Programming Interface CAVP Cryptographic Algorithm Validation Program CMVP Cryptographic Module Validation Program CSP Critical Security Parameters DLL Dynamic Link Library DLM Dynamic Link Module (a type of DLL used in the Pre-boot environment) DRBG Deterministic Random Bit Generator FIPS Federal Information Processing Standard GPC General Purpose Computer GUI Graphical User Interface IPC Inter-process communication MBR Master Boot Record McAfee ePO McAfee ePolicy Orchestrator: A McAfee software installation to allow configuration and management of a McAfee product deployment OS Operating System Pre-boot The operating environment of a GPC before the operating system is loaded environment RSA An algorithm for public-key cryptography. Named after Rivest, Shamir and Adleman who first publicly described it. SHA Secure Hash Algorithm SP Security Policy Storage Media Any media for which Cryptographic Module protection in the form of data encryption is required. Storage Media include internal and external hard drives, memory sticks and floppy disks. TCP/IP Transmission Control Protocol/Internet Protocol TLS Transport Layer Security XML Extensible Markup Language Figure 1 Document terminology 2 McAfee Core Cryptographic Module (user) This section provides the details of how the module meets the FIPS 140-2 requirements. 2.1 Overview The module provides cryptographic services to McAfee, Inc. products. The module is packaged differently depending on its operational environment. 5 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com 2.2 Module Specification 2.2.1 Hardware, Software and Firmware components There are no specific hardware or firmware requirements for the module. The module is a software-only module which resides on a General Purpose Computer (see Figure 4). It is packaged as five distinct binary images, one for each of the following operating environments: FILE NAME OPERATING ENVIRONMENT MFECCF[32|64]aa.dll Microsoft Windows MFECCF[32|64]aa.dlm PC BIOS Pre-boot environment MFECCF[32|64]aa.dylink Apple MacOS MFECCF[32|64]aa.efi UEFI (PC Pre-boot environment) MFECCF[32|64]aa.efi EFI (Apple Mac Pre-boot environment) Figure 2 Module binary image Note: aa are alphanumeric product identifiers, such as MFECCF64DE.dll for Drive Encryption and MFECCF32FF.dll for Files and Folders. Although there is a common core of functionality between these five images, within this group there are distinct variants. The differences in implementation relate to: 1. The collection of the entropy used to seed the SP800-90 compliant DRBG 2. An AES implementation that is not present in the pre-boot builds. 3. The Macintosh variants do not support the Symmetric Encryption service MCCi_crypto_disk_algs API All variants use the Intel RdRand instruction to seed the SP800-90 compliant DRBG if this functionality is available on the CPU. If it is not available, then the pre-boot variant uses entropy derived from user- generated inputs such as mouse movements and keyboard key presses, whereas the Windows/MacOS variant uses entropy derived from network activity. The low-level disk handler AES implementation is only applicable to the non-preboot environment. Except for in the distinct areas clearly described above, the various modules are identical and in those cases, the term “the module” applies equally to each variant. 2.2.2 Cryptographic Boundary The cryptographic boundary of the module is the case of the General Purpose Computer (GPC) on which it is installed. See Figure 4. The module is a software module running in a pre-boot, Windows, or Mac OS operating environment on a general-purpose computer. The processor of this platform executes all software. All software components of the module are persistently stored within the device and, while executing, are stored in the device local RAM. 6 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com Figure 3 Block Diagram of the Cryptographic Boundary (Pre-boot environment) Figure 4 Block Diagram of the Cryptographic Boundary (Windows / MacOS environments) 7 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com 2.2.3 Scope of Evaluation The cryptographic module meets the overall requirements applicable to Level 1 security of FIPS 140-2, with Design Assurance at Level 3. SECURITY REQUIREMENTS SECTION LEVEL Cryptographic Module Specification 1 Module Ports and Interfaces 1 Roles, Services and Authentication 1 Finite State Model 1 Physical Security N/A Operational Environment 1 Cryptographic Key Management 1 EMI/EMC 1 Self-Tests 1 Design Assurance 3 Mitigation of Other Attacks N/A Figure 5 Security Level specification per individual areas of FIPS 140-2 2.2.4 Cryptographic Algorithms 2.2.4.1 Approved algorithms The following table provides details of the approved algorithms that are included within the module: ALGORITHM TYPE ALGORITHM CAVP CERTIFICATE USE Hashing SHA-1 #2181 (SHA-1 SHA-1 is a constituent of the non- and SHA-256) approved PKCS#5 algorithm. SHA-256 #2287 (SHA-256) SHA-256 is part of the DRBG and also used in the module integrity test. Message HMAC #1604 Module integrity testing and in the authentication code #1605 random number generator. Random number HMAC SHA256 #394 Symmetric and Asymmetric key generation DRBG generation Symmetric key AES-256 – ECB, #2591 Service provided to encrypt and decrypt CBC, CFB8 and #2592 blocks of data. CFB128. Encrypt #2593 and decrypt #2755 As it is a user service and so may also be used to encrypt private keys to provide key wrapping (cert #2591 only). Figure 6 Approved Algorithms 8 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com Notes: There are four implementations of AES-256 in the module, one to support each of the following: • MCCi_crypto_sym_encryptor service • MCCi_crypto_disk_algs service interface “get_interface”, a copy of the MFECCFaa module algorithms – this can run on processors with or without AES-NI capability. However, it will use AES- NI instructions if run on AES-NI enabled processors. • MCCi_crypto_disk_algs service interface “get_hook_code”, a copy of the algorithm code to support the cryptographic algorithm requirements of the low-level disk handler (INT 13 disk hook, Windows only). • MCCi_crypto_disk_algs service interface “secure_crypt_blocks”, an implementation where the data key is stored in model-specific registers (MSRs) rather than in RAM. This interface is only applicable when these registers are present on the processor. 2.2.4.2 Non-approved algorithms allowed in approved mode RSA encrypt/decrypt is used for key wrapping giving 112 bits of security strength. This service is non- approved but allowed. The entropy used to seed the random number generator is an NDRNG that is a non-Approved but allowed algorithm. 2.2.4.3 Non-approved algorithms The following non-approved algorithms are included within the module: • PKCS#5 (a password hashing algorithm using SHA-1), offered as a non-approved service to users of the module. During operation, the module can switch service by service between an Approved mode of operation and a non-Approved mode of operation. The module will transition to the non-Approved mode of operation when the above non-Approved security functions is utilized in lieu of an Approved one. The module can transition back to the Approved mode of operation by utilizing an Approved security function. PKCS#5 is not allowed for use in the FIPS Approved mode of operation. When this algorithm is used, the module is not operating in the FIPS Approved mode of operation. CSPs shall not be shared between the Approved and non-Approved modes of operation. 2.2.5 Components excluded from the security requirements of the standard There are no components excluded from the security requirements of the standard. 2.3 Physical ports and logical interfaces The module is classified as a multi-chip standalone module for FIPS 140-2 purposes. The module’s physical boundary is that of the device on which it is installed. The device shall be running a supported operating system (OS) and supporting all standard interfaces, including keys, buttons and switches, and data ports. 9 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com The module provides its logical interfaces via Application Programming Interface (API) calls. This logical interface exposes services (described in section 2.4.2) that the User and operating system utilize directly. The logical interfaces provided by the module are mapped onto the FIPS 140-2 logical interfaces: data input, data output, control input, and status output as follows: FIPS 140-2 LOGICAL MODULE MAPPING INTERFACE Data Input Parameters passed to the module via API calls Data Output Data returned from the module via API calls Control Input API Calls and/or parameters passed to API calls Status Output Information received in response to API calls Power Interface There is no separate power or maintenance access interface beyond the power interface provided by the GPC itself Figure 7 Module Interfaces 2.4 Roles, Services and Authentication 2.4.1 Roles The Cryptographic Module implements both a Crypto Officer role and a User role. Roles are assumed implicitly upon accessing the associated services. Section 2.4.2 summarizes the services available to each role. ROLE DESCRIPTION Crypto Officer The administrator of the module having full configuration and key management privileges. User General User of the module Figure 8 Roles 2.4.2 Services Most of the services provided by the module are provided via access to API calls using interfaces exposed by the module. However, some of the services, such as power-up module integrity testing are performed automatically and so have no function API, but do provide status output. SERVICE API DESCRIPTION SERVICE INPUT SERVICE OUTPUT Asymmetric MCCi_crypto_asym_ Provides RSA encryption Encryption: Encryption: encryption/ encryptor and decryption. Public key and Encrypted data decryption plaintext data passed out. Note: The asymmetric passed in. encryption service shall not be used for Decryption: Decryption: 10 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com SERVICE API DESCRIPTION SERVICE INPUT SERVICE OUTPUT encrypting/decrypting Private key and Plaintext data bulk data. It shall only be encrypted data passed out. used specifically to wrap passed in. cryptographic keys using RSA. Service can also output algorithm status information. MCCi_crypto_asym_ Provides RSA encryption Encryption: Encryption: encryptor_var_pad but allows the padding to Public key and Encrypted data be specified. plaintext data passed out. passed in. Decryption: Decryption: Private key and Plaintext data encrypted data passed out. passed in. Service can also output algorithm status information. Key generation MCCi_crypto_asym_k Provides RSA key None Service ey_gen generation. The RSA keys methods exist are calculated from large to generate a numbers generated by the key pair and to FIPS approved DRBG separately seeded by a non-approved output the NDRNG. public key and the private key. MCCi_crypto_asym_k Provides RSA key Format required Service ey_gen2 generation but allows the for keys methods exist keys to be encoded in to generate a various formats. The RSA key pair and to keys are calculated from separately large numbers generated output the by the FIPS approved public key and DRBG seeded by a non- the private key. approved NDRNG. MCCi_rand_source Generates symmetric keys For seeding: For Seeding: and accepts seed data to Entropy data and None. add to the random pool. a count of the 11 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com SERVICE API DESCRIPTION SERVICE INPUT SERVICE OUTPUT number of Entropy data is used to entropy bytes: seed the DRBG which is used to generate the For generation: For generation: symmetric keys. A count of the A block of number of bytes random data. required. Symmetric MCCi_crypto_enc_da Utility class to hold Data buffer, size Data buffer, size encryption/ ta encrypted data returned of data and of data, and decryption by the symmetric algorithm type ID algorithm type encryptor. ID MCCi_crypto_sym_e Provides symmetric Encryption: Encryption: ncryptor algorithm encryption and Algorithm ID, key, Encrypted data decryption. Supports plaintext data, AES256 (CBC and CFB128 Initial Value (IV) Decryption: modes). Decrypted data Decryption: Key, encrypted Status: data, Initial Value Algorithm (IV) information and key size MCCi_crypto_disk_al Provides access to a copy None Status: gs (Not supported by of the MFECCFaa Macintosh variants) symmetric disk encryption Results of Disk algorithms (statically Driver linked into this, the encryption MFECCF[32|64]aa algorithm self- module). Supports only tests. FIPS AES 256. Interface pointer providing access to Disk Driver encryption algorithms. Hashing MCCi_crypto_digest_ Allows hashing of arbitrary Data and Digest of the gen data. Supports SHA1 and algorithm data. SHA256. 12 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com SERVICE API DESCRIPTION SERVICE INPUT SERVICE OUTPUT Self-tests MCCi_crypto_self_te Runs all the KATs on the None Service outputs sts algorithms exported by a Boolean result MfeCryptoLib library. code, TRUE if all of the self-tests passed, otherwise FALSE. N/A The power-up software None If passes, writes integrity test is run the string automatically when the “Passed” to the module is loaded and Integrity Status started. registry key, otherwise The continuous random writes the string number generator test is “Failed” to this also run automatically. registry key and initiates a stop error. Show Status N/A Status is returned in None Module status. response to individual service API calls and at the completion of the self- tests. Figure 9 User Services SERVICE API DESCRIPTION SERVICE INPUT SERVICE OUTPUT Installation N/A The module is deployed as None Installed part of a McAfee, Inc. module product installation. Uninstallation N/A The module is uninstalled None Uninstalled during the uninstallation module of the product that deployed the module. Key Zeroization N/A Keys are zeroized using None All keys the zeroization procedure. zeroized. This is described in section 2.7.4. Figure 10 Crypto Officer Services SERVICE API DESCRIPTION SERVICE INPUT SERVICE OUTPUT PKCS#5 MCCi_crypto_ Allows hashing of a Password Digest of the pkcs5_hash_gen password password Figure 11 Non-Approved Services 13 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com 2.4.3 Authentication The module has been evaluated at FIPS 140-2 level 1 and no claims are made for authentication. 2.5 Physical Security The Cryptographic Module is a software-only cryptographic module and therefore the physical security requirements of FIPS 140-2 do not apply. 14 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com 2.6 Operational Environment The Cryptographic Module has been tested on and found to be conformant with the requirements of FIPS 140-2 overall Level 1 on the following GPC platforms: RDRAND1 AES-NI2 PLATFORM CPU OPERATING SYSTEM AES REGISTER IMPLEMENTATION3 (ALL TESTED IN SINGLE-USER MODE) Dell E5510 Intel Core i3 N/A McAfee Endpoint Encryption Preboot OS Dell E6320 Intel Core i5 N/A X McAfee Endpoint Encryption Preboot OS Dell E6410 Intel Core i7 N/A X McAfee Endpoint Encryption Preboot OS Dell Inspiron Intel Core i3 X Windows 8 running in 64-bit 3520 UEFI mode Lenovo W530 Intel Core i5 X X Windows 8 running in 64-bit UEFI mode Lenovo Yoga Intel Core i7 X X Windows 8 running in 64-bit UEFI mode Samsung Intel Core i5 Windows 8 running in 32-bit 700T UEFI mode Dell Latitude Intel Atom Windows 8 running in 32-bit 10 UEFI mode MacBook Intel Core 2 Macintosh running EFI Duo Preboot MacPro Intel Xeon Macintosh running EFI Preboot MacBook Air Intel Core i3 X X Macintosh running EFI Preboot Mac Mini Intel Core i5 X X Macintosh running EFI Preboot MacBook Pro Intel Core i7 X X Macintosh running EFI Preboot Dell E5510 Intel Core i3 Windows XP 32-bit Dell E5510 Intel Core i3 Windows 7 64-bit Lenovo Yoga Intel Core i7 X X Windows 7 64-bit Lenovo Yoga Intel Core i7 X X Windows 8 64-bit Dell Latitude Intel Atom Windows 8 32-bit 10 MacBook Intel Core 2 MacOS X Lion v10.7 Duo MacPro Intel Xeon MacOS X Mountain Lion v10.8 MacBook Air Intel Core i3 X X MacOS X Mountain Lion v10.8 15 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com RDRAND1 AES-NI2 PLATFORM CPU OPERATING SYSTEM AES REGISTER (ALL TESTED IN SINGLE-USER MODE) IMPLEMENTATION3 Mac Mini Intel Core i5 X X MacOS X Lion v10.7 MacBook Pro Intel Core i7 X X MacOS X Mountain Lion v10.8 Dell E6320 Intel Core i5 X Windows Vista 32-bit Dell E6410 Intel Core i7 X Windows Vista 64-bit Dell E6320 Intel Core i5 X Windows 7 32-bit Lenovo W530 Intel Core i5 X X Windows 8 32-bit Lenovo W530 Intel Core i5 X X Windows 8 64-bit Intel Intel Core i5 X X Windows 8 64-bit X UBHB2SISQ Lenovo Intel Atom Windows 8 32-bit X Thinkpad 2 Intel Intel Core i5 X X Windows 8 running in 64-bit X UBHB2SISQ UEFI mode Lenovo Intel Atom Windows 8 running in 32-bit X Thinkpad 2 UEFI mode Figure 12 Operating Platforms The module is also capable of running on the following platforms but has not been tested during this evaluation and no compliance is being claimed on these platforms: • Windows Server 2008 (32-bit and 64-bit) with SP1 • Windows Server 2008 R2 (64-bit only) • Windows 2003 Server (32-bit only) with SP2 • Windows 2003 Server R2 (32-bit only) with SP2 Notes: 1. RdRand is an instruction for returning random numbers from a random number generator built into the microprocessor. See section 2.2.1 for details on how this is used in the module. 2. AES-NI (the Intel Advanced Encryption Standard (AES) New Instructions (AES-NI)) is an extension to the x86 instruction set architecture for microprocessors from Intel and AMD. The purpose of the instruction set is to improve the speed of applications performing encryption and decryption using AES. 3. AES Register Implementation: The module can use MSRs (model-specific registers) to store the AES System key so that it is stored within the processor and not in system RAM. The decision to use the MSRs in this way is made by the application using the module and it is this application that is responsible for loading the key into the MSRs. The cryptographic module runs in the thread context of the calling application. This provides it with protection from all other processes, preventing access to all keys, intermediate key generation values, and other CSPs. 16 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com The task scheduler and architecture of the operating system maintain the integrity of the cryptographic module. The module supports only one single user and only one operator can have access to the device that contains the module at a time. 2.7 Cryptographic Key Management 2.7.1 Random Number Generators The module contains an approved HMAC SHA256 SP800-90 approved DRBG. 2.7.2 Key Generation Keys generated internally are generated by the HMAC SHA256 DRBG seeded by system entropy. Checks are made to ensure that the quality of the entropy remains high enough to be used to seed the DRBG. The entropy comes from a promiscuous socket. This is used to provide sampling points for discrete high speed counters in the Mac OS, Windows and Preboot environments. Only the least significant bits of these counters are sampled and statistical tests produce results showing that this provides random data of sufficient entropy. 2.7.3 Key Table The following tables list all of the keys and CSPs within the module, describe their purpose, and describe how each key is generated, entered and output, stored and destroyed. KEY PURPOSE Data Key To encrypt and decrypt data using the symmetric encryption services. Public Key To encrypt data or keys using one of the asymmetric encryption services. Private Key To decrypt data or keys previously encrypted by the Public Key. HMAC DRBG CSPs: Key, These are variables used internally by the HMAC DRBG that are required by V, seed and entropy Implementation Guidance 14.5 to be listed in the Cryptographic Module Security Policy document. There is no initial seed, but the algorithm is reseeded from a non-approved NDRNG. Figure 13 Module Cryptographic Keys and CSPs 17 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com KEY KEY GENERATION/ESTABLISHMENT STORAGE LOCATION LENGTH/STRENGTH Data Key AES 256 bit Generated using Key Not stored within the generation service module. Public Key RSA 2048 bit Generated using Key Not stored within the generation service module. Private Key RSA 2048 bit As per Public Key Not stored within the module. HMAC DRBG “Key” 512 bits Initial value of 64 bytes all set Not stored within the CSP to “0x00” module. HMAC DRBG “V” 512 bits Initial value of 64 bytes all set Not stored within the CSP to “0x01” module. HMAC DRBG seed 2048 bits non-approved NDRNG Not stored within the and entropy CSPs module. Figure 14 Key Table part 1 KEY ARE KEYS SUPPLIED ENTRY/OUTPUT DESTRUCTION ENCRYPTED OR PLAINTEXT? Data Key Plaintext Used as key in symmetric Zeroized using the key encryption service. zeroization service. Public Key Plaintext Passed as a parameter to Zeroized using the key asymmetric encryption service. zeroization service. Private Key Plaintext Passed as a parameter to Zeroized using the key asymmetric encryption service. zeroization service. HMAC DRBG “Key” N/A N/A Zeroized using the key CSP zeroization service. HMAC DRBG “V” N/A N/A Zeroized using the key CSP zeroization service. HMAC DRBG seed N/A N/A Zeroized using the key and entropy CSPs zeroization service. Figure 15 Key Table part 2 2.7.4 Key Destruction All key material managed by the module can be zeroized using the key zeroization procedure. This requires uninstallation of the cryptographic module and reformatting the hard drive on which it was installed. The CO should uninstall the module and then reformat the hard drive on which it was installed and overwrite it at least once. The operator should remain present during this process. This process meets the requirements of IG 7.9 for key zeroization. Reformatting the hard drive will remove any encrypted or public keys from the hard disk. 18 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com In this way all key material and CSPs are zeroized. There are no user-accessible plaintext keys or CSPs in the module. 2.7.5 Access to Key Material The following table shows the access that an operator has to specific keys or other critical security parameters when performing each of the services relevant to his/her role. KEY Access Rights HMAC DRBG KEY HMAC DRBG V Blank N/A PRIVATE KEY PUBLIC KEY DATA KEY R Read W Write U Use User Services Asymmetric encryption WU WU Key generation R R R U U Symmetric encryption RWU Hashing Self-tests Show Status Crypto Office Services Installation U Uninstallation U Key Zeroization W W W W W Figure 16 Access to keys by services Note: Key zeroization zeroes all keys and CSPs, this is a “write” operation in that all keys are overwritten with zeroes. 19 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com 2.8 Self-Tests The module implements both power-up and conditional self-tests as required by FIPS 140-2. The following two sections outline the tests that are performed. 2.8.1 Power-up self-tests OBJECT TEST SHA-1 Known answer tests SHA-256 Known answer tests HMAC-SHA-256 Known answer tests AES-256 A separate encryption and decryption known answer test for each of the AES implementations within the module HMAC DRBG Known answer test Module software HMAC SHA-256 Integrity Check RSA Known answer test Figure 17 Power-up self-tests Note: The module performs a separate known answer test for each of its SHA implementations. 2.8.2 Conditional self-tests EVENT TEST CONSEQUENCE OF FAILURE Module requests a random A continuous random number Random number is not generated number from the FIPS Approved generator test and module enters an error state. SP800-90 DRBG Entropy is supplied to the FIPS A continuous random number Entropy is not added and module approved SP800-90 DRBG generator test on the entropy enters an error state NDRNG RSA key pair generation Pairwise consistency test Key is not generated and module enters an error state. Figure 18 Conditional self-tests The following error message is returned in the event of a self-test error: MCC_exception("Cryptographic module is in an error state and cannot be accessed", E_MCC_GEN_SELF_TEST_FAILED). 2.9 Design Assurance McAfee, Inc. employ industry standard best practices in the design, development, production and maintenance of all of its products, including the FIPS 140-2 module. This includes the use of an industry standard configuration management system that is operated in accordance with the requirements of FIPS 140-2, such that each configuration item that forms part of the module is stored with a label corresponding to the version of the module and that the module and all of its associated documentation can be regenerated from the configuration management system with reference to the relevant version number. 20 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. www.mcafee.com Design documentation for the module is maintained to provide clear and consistent information within the document hierarchy to enable transparent traceability between corresponding areas throughout the document hierarchy, for instance, between elements of this Cryptographic Module Security Policy (CMSP) and the design documentation. Guidance appropriate to an operator’s Role is provided with the module and provides all of the necessary assistance to enable the secure operation of the module by an operator, including the Approved security functions of the module. Delivery of the Cryptographic Module to customers from the vendor is via the internet. When a customer purchases a license to use the Cryptographic Module software, they are issued with a grant number as part of the sales process. This is then used as a password to allow them to download the software that they have purchased. The delivery channel is protected using secured sockets. Once the Cryptographic Officer has downloaded the cryptographic module, it is his responsibility to ensure its secure delivery to the users that he is responsible for. 2.10 Mitigation of Other Attacks The module does not mitigate any other attacks. 21 © 2014 McAfee, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice.