McAfee, Inc.  McAfee Endpoint Encryption  Client Windows Cryptographic Module 1.0    and McAfee Endpoint Encryption  Client Preboot Cryptographic Module 1.0    FIPS 140‐2 Non‐Proprietary   Security Policy    Level 1 Validation    Document revision 020, January 2012            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        © 2012 McAfee, Inc. This document may be reproduced only in its original entirety [without revision]. The information in this document is provided only for educational purposes and for the convenience of McAfee’s customers. The information contained herein is subject to change without notice, and is provided “as is” without guarantee or warranty as to the accuracy or applicability of the information to any specific situation or circumstance. McAfee, Avert, and Avert Labs are trademarks or registered trademarks of McAfee, Inc. in the United States and other countries. All other names and brands may be the property of others. 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  .................................................................................................................... 5  . 2  McAfee Endpoint Encryption Client ........................................................................................................ 5  . 2.1  Overview ........................................................................................................................................... 6  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  ............................................................................................................... 14  . 2.7  Cryptographic Key Management .................................................................................................... 15  2.7.1  Random Number Generators .................................................................................................. 15  2.7.2  Key Generation ........................................................................................................................ 15  2.7.3  Key Table .................................................................................................................................. 15  2.7.4  Key Destruction ........................................................................................................................ 17  2.7.5  Access to Key Material ............................................................................................................. 18  2.8  Self‐Tests ......................................................................................................................................... 19  2.8.1  Power‐up self‐tests .................................................................................................................. 19  2.8.2  Conditional self‐tests ............................................................................................................... 19  2.9  Design Assurance ............................................................................................................................ 19  2.10  Mitigation of Other Attacks ......................................................................................................... 20  3  FIPS Mode of Operation  ........................................................................................................................ 20  . 3.1  Deploying in FIPS mode ................................................................................................................... 21    Figures  Figure 1 Block Diagram of the Cryptographic Boundary (Pre‐boot environment) .......................................... 7  Figure 2 Block Diagram of the Cryptographic Boundary (Windows environment) ......................................... 7  Figure 3 Security Level specification per individual areas of FIPS 140‐2 ......................................................... 8  Figure 4 Approved Algorithms ......................................................................................................................... 9  Figure 5 Module Interfaces ............................................................................................................................ 10      2 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  Figure 6 Roles ................................................................................................................................................. 10  Figure 7 User Services .................................................................................................................................... 13  Figure 8 Crypto Officer Services  .................................................................................................................... 14  . Figure 9 Module Cryptographic Keys and CSPs ............................................................................................. 15  Figure 10 Key Table part 1 ............................................................................................................................. 16  Figure 11 Key Table part 2 ............................................................................................................................. 17  Figure 12 Access to keys by services  ............................................................................................................. 18  . Figure 13 Power‐up self‐tests ........................................................................................................................ 19  Figure 14 Conditional self‐tests ..................................................................................................................... 19        3 © 2011 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 Endpoint Encryption Client Windows Cryptographic    Module      McAfee, Inc. McAfee Endpoint Encryption Client Preboot Cryptographic  Module    Module Version  1.0      Software Version  6.1.3    1.2 Purpose  This is the non‐proprietary FIPS 140‐2 Security Policy for the McAfee Endpoint Encryption Client  Cryptographic Module, also referred to as “the module” within this document. This Security Policy details  the secure operation of McAfee Endpoint Encryption Client Cryptographic Module 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 Endpoint Encryption please visit:  http://www.mcafee.com/us/products/data‐protection/endpoint‐encryption.aspx.   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.      4 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  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.  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  DSA  Digital Signature Algorithm  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 Endpoint Encryption  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    2 McAfee Endpoint Encryption Client  This section provides the details of how the module meets the FIPS 140‐2 requirements.      5 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  2.1 Overview  The module provides cryptographic services to McAfee Endpoint Encryption products. These endpoint  products are managed by McAfee Electronic Policy Orchestrator (ePO). Among other functions, ePO  deploys and manages the endpoint software, including the cryptographic module.    The module is packaged as a DLL when running under Microsoft Windows or as a DLM when operating in  the pre‐boot environment.   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 2).    It is packaged as two distinct binary images, depending on the operating environment in which it  operates:     FILE NAME  OPERATING ENVIRONMENT  MfeEpeCrypto.dll  Microsoft Windows  MfeEpeCrypto.dlm Pre‐boot environment    These two variants are based on a common core of functionality. The only differences in implementation  functionality relate to the collection of the entropy used to seed the SP800‐90 compliant DRBG and one  AES implementation.     The pre‐boot module uses entropy derived from user generated inputs such as mouse movements and  keyboard key presses, whereas the Windows module uses entropy derived from network activity.    The low‐level disk handler AES implementation is only applicable to the Windows environment.    As these two packages are independent of one another, they are effectively different modules. To clearly  discriminate between the two variants, the Windows (DLL) variant is known as the McAfee Endpoint  Encryption Client Windows Cryptographic Module 1.0, and the Preboot (DLM) variant is known as the  McAfee Endpoint Encryption Client Preboot Cryptographic Module 1.0. However, except in the distinct  areas clearly described above, the two modules are identical and in those cases, the term “the module”  applies equally to either 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 2. The module is a software module running in a pre‐boot or Windows 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 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com    Figure 1 Block Diagram of the Cryptographic Boundary (Pre‐boot environment)      Figure 2 Block Diagram of the Cryptographic Boundary (Windows environment)      7 © 2011 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 3 Security Level specification per individual areas of FIPS 140‐2  2.2.4 Cryptographic 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  #1653 (SHA‐1  SHA‐1 is not used in the FIPS    and SHA‐256)  mode of operation. It is a    #1654 (SHA‐256  constituent of the non‐approved    only)  PKCS#5 algorithm.      SHA‐256  Constituent of DRBG and also  used in the module integrity test.  Message authentication  HMAC  #1124  Module integrity testing and in  code  #1125  the random number generator.  Random number  HMAC SHA256 DRBG  #156  Symmetric and Asymmetric key  generation  generation  Symmetric key  AES‐256 – CBC and  #1881  Service provided to encrypt and  CFB128. Encrypt and  #1882  decrypt blocks of data.  decrypt  #1883 (Windows    only)  As it is a user service and so may  also be used to encrypt private      8 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  ALGORITHM TYPE  ALGORITHM  CAVP CERTIFICATE  USE  keys to provide key wrapping  (cert #1881 only).    Figure 4 Approved Algorithms      Notes:    There are three implementations of AES‐256 in the module, one to support each of the following:   MFEi_crypto_sym_encryptor service   EPEi_crypto_disk_algs service interface “get_interface”, a copy of the MfeEEAlg module  algorithms – this can run on processors with or without AES‐NI capability. However, it will only use  AES‐NI instructions if run on AES‐NI enabled processors.   EPEi_crypto_disk_algs service interface “get_hook_code”, a copy of the algorithm code to support  the cryptographic algorithm requirements of the INT 13 handler (Windows only)    RSA encrypt/decrypt is used for key transport 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 algorithm  used in FIPS mode.    The following non‐approved algorithms are included within the module but are not used when the  module is operating in FIPS mode:   RC5 (RC5‐12 and RC5‐18).   PKCS#5 (a password hashing algorithm using SHA‐1), offered as a non‐approved service to users of  the module.   A non‐FIPS AES implementation.  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.    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:      9 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com      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 5 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 6 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  MFEi_crypto_asym_e Provides RSA encryption  Encryption:  Encryption:  encryption  ncryptor  and decryption.  Public key and  Encrypted data  plaintext data  passed out.  passed in.        Decryption:  Decryption:  Private key and  Plaintext data  encrypted data  passed out.      10 © 2011 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  passed in.      Service can also  output  algorithm status  information.    MFEi_crypto_asym_e Provides RSA encryption  Encryption:  Encryption:  ncryptor_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  MFEi_crypto_asym_k Provides RSA key  None  Service  generation  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.    MFEi_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.    MFEi_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      number of    Entropy data is used to  entropy bytes:        11 © 2011 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  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  MFEi_crypto_enc_da Utility class to hold  Data buffer, size  Data buffer, size  encryption  ta  encrypted data returned  of data and  of data, and  by the symmetric  algorithm type ID  algorithm type  encryptor.  ID     MFEi_crypto_sym_en Provides symmetric  Encryption:  Encryption:  cryptor  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    EPEi_crypto_disk_alg Provides access to a copy  None  Status:  s  of the MfeEEAlg    symmetric disk encryption  Results of Disk  algorithms (statically  Driver  linked into this, the  encryption  MfeEpeCrypto module).  algorithm self‐ Supports only FIPS AES  tests.  256 when the module is    operated in FIPS mode.  Interface  The RC5 legacy algorithm  pointer  (both 12 round and 18  providing  round) is supported when  access to Disk  not operating in FIPS  Driver  mode, as is a non‐FIPS  encryption  compliant AES  algorithms.  implementation.  Hashing  MFEi_crypto_digest_ Allows hashing of arbitrary  Data and  Digest of the  gen  data. Supports SHA1 and  algorithm  data.  SHA256.  Self‐tests  MFEi_crypto_self_tes Runs all the KATs on the  None  Service outputs  ts  algorithms exported by  a Boolean result  MfeCryptoLib library.  code, TRUE if all  of the self‐tests      12 © 2011 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  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  IntegrityStatus  started.  “MfeEpeCrypto.   Dll” registry  The continuous random  key, otherwise  number generator test is  writes the string  also run automatically.  “Failed” to this  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 7 User Services    SERVICE  API  DESCRIPTION  SERVICE INPUT  SERVICE OUTPUT  Installation  N/A  At some point after the  None  Installed module  installation process, the  product is activated once  suitable policy has been  received from ePO. The  module is deployed to the  client PC from ePO. User  services are then used to  generate keys and encrypt  the endpoint GPC storage.  Uninstallation  N/A  Prior to the uninstallation  None  Uninstalled  product, user services are  module  used to decrypt the  endpoint GPC services and  then remove the endpoint  software, including the  cryptographic module  software.  Key Zeroization  N/A  Keys are zeroized using the  None  All keys zeroized.      13 © 2011 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  zeroization procedure. This  is descried in section 2.7.4.    Figure 8 Crypto Officer Services  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.      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 operating systems:     McAfee Endpoint Encryption Preboot OS running on Intel Core i3 without AES‐NI   McAfee Endpoint Encryption Preboot OS running on Intel Core i5 with AES‐NI   McAfee Endpoint Encryption Preboot OS running on Intel Core i7 with AES‐NI   Windows XP 32‐bit running on Intel Core i3 without AES‐NI   Windows 7 64‐bit running on Intel Core i3 without AES‐NI   Windows Vista 32‐bit running on Intel Core i5 with AES‐NI   Windows Vista 64‐bit running on Intel Core i7 with AES‐NI   Windows 7 32‐bit running on Intel Core i5 with AES‐NI   Windows 7 64‐bit running on Intel Core i7 with AES‐NI    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    The cryptographic module runs in its own operating system threads. This provides it with protection from  all other processes, preventing access to all keys, intermediate key generation values, and other CSPs.    The task scheduler and architecture of the operating system maintain the integrity of the cryptographic  module.        14 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  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 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 using one of the asymmetric encryption  services.  Private Key  To decrypt data previously encrypted by the Public Key.  HMAC DRBG CSPs: Key, V, seed  These are variables used internally by the HMAC DRBG that are  and entropy  required by 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 used in FIPS mode.  HMAC‐SHA‐256 Integrity Key  A fixed and hard coded key used in the module integrity  checking power‐up self‐test    Figure 9 Module Cryptographic Keys and CSPs    KEY  KEY  GENERATION/ESTABLISHMENT  STORAGE LOCATION  LENGTH/STRENGTH  Data Key  AES 256 bit  Generated using Key generation  Not stored within the module.  service  Public Key  RSA 2048 bit  Generated using Key generation  Not stored within the module.      15 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  service  Private Key  RSA 2048 bit  As per Public Key   Not stored within the module.  HMAC DRBG  512 bits  Initial value of 64 bytes all set to  Not stored within the module.  “Key” CSP  “0x00”  HMAC DRBG  512 bits  Initial value of 64 bytes all set to  Not stored within the module.  “V” CSP  “0x01”  HMAC DRBG  2048 bits  non‐approved NDRNG  Not stored within the module.  seed and  entropy CSPs  HMAC‐SHA‐256  256 bits  Fixed key  Not stored within the module.  Integrity Key    Figure 10 Key Table part 1      16 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com    KEY  ARE KEYS SUPPLIED  ENTRY/OUTPUT  DESTRUCTION  ENCRYPTED OR PLAINTEXT?  Data Key  Plaintext  Used as key in symmetric encryption  Zeroized using the  service.  key zeroization  service.  Public Key  Plaintext  Passed as a parameter to  Zeroized using the  asymmetric encryption service.  key zeroization  service.  Private Key  Plaintext  Passed as a parameter to  Zeroized using the  asymmetric encryption service.  key zeroization  service.  HMAC DRBG “Key”  N/A  N/A  Zeroized using the  CSP  key zeroization  service.  HMAC DRBG “V”  N/A  N/A  Zeroized using the  CSP  key zeroization  service.  HMAC DRBG seed  N/A  N/A  Zeroized using the  and entropy CSPs  key zeroization  service.  HMAC‐SHA‐256  N/A  N/A  Zeroized using the  Integrity Key  key zeroization  service.    Figure 11 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.     In this way all key material and CSPs are zeroized. There are no user‐accessible plaintext keys or CSPs in  the module.      17 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com    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 HMAC DRBG KEY  INTEGRITY KEY  HMAC DRBG V  PRIVATE KEY  PUBLIC KEY  DATA KEY  User Services              Asymmetric encryption    WU WU       Key generation  R  R  R  U  U    Symmetric encryption  RWU           Hashing              Self‐tests            U  Show Status              Crypto Office Services              Installation  U            Uninstallation  U            Key Zeroization  W  W  W  W  W  W    Figure 12 Access to keys by services  Access Rights    Blank  Not Applicable  R  Read  W  Write  U  Use    Note: Key zeroization zeroes all keys and CSPs, this is a “write” operation in that all keys are overwritten  with zeroes.      18 © 2011 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 test  SHA‐256  Known answer test  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    Figure 13 Power‐up self‐tests    Note: A known answer test for HMAC is not required because the module performs an HMAC‐SHA‐256‐ DRBG known answer test. The module performs a separate known answer test for each of its two SHA‐ 256 implementations.  2.8.2 Conditional self‐tests  EVENT  TEST  CONSEQUENCE OF FAILURE  Module requests a random  A continuous random number  Random number is not  number from the FIPS  generator test  generated and module enters  Approved SP800‐90 DRBG  an error state.  Entropy is supplied to the FIPS  A continuous random number  Entropy is not added and  approved SP800‐90 DRBG  generator test on the entropy  module enters an error state  NDRNG  RSA key pair generation  Pairwise consistency test  Key is not generated and  module enters an error state.    Figure 14 Conditional self‐tests    2.9 Design Assurance  McAfee, Inc. employ industry standard best practices in the design, development, production and  maintenance of the McAfee Endpoint Encryption product, 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      19 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  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.    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.    3 FIPS Mode of Operation  The module is set into FIPS mode by setting the FipsMode registry key to a non‐zero value.    PATH  NAME  TYPE  VALUE  32‐bit Windows:  FipsMode  DWORD  0 = Not in FIPS mode      HKEY_LOCAL_MACHINE\  Any non‐zero value indicates FIPS  Software\  mode operation.  McAfee Endpoint Encryption\  Fips    64‐bit Windows:    HKEY_LOCAL_MACHINE\  Software\Wow6432Node\  McAfee Endpoint Encryption\  Fips    When the module is not in FIPS mode:   The power‐up integrity checks are not performed.      20 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com   Seeding of the DRBG by a non‐approved NDRNG is not required.   The RC5 legacy algorithm can be used.   The PKCS#5 algorithm may be used.   RSA encryption may be used    When the module is in FIPS mode:   The power‐up integrity checks are performed.   The DRBG is seeded by an internal non‐approved NDRNG.   Additional checks are made on the entropy.   The RC5 legacy algorithm cannot be used.   The PKCS#5 algorithm may not be used.   RSA may only be used for key wrapping.    For the module to operate in FIPS mode, if the Asymmetric encryption service is used, this must be used  with 2048 bit RSA keys.     The writable memory areas of the Module (data and stack segments) are accessible only by the Endpoint  Encryption application so that the Module is in "single user" mode, i.e. only the application has access to  that instance of the Module.  3.1 Deploying in FIPS mode  When the module is deployed by ePO, it is possible to set it into a FIPS mode or non‐FIPS mode of  operation automatically using the ePO product deployment wizard, by adding “FIPS” to the command line  of the deployment task for Endpoint Encryption.        21 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com        22 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.