McAfee, Inc.  McAfee Endpoint Encryption  Disk Driver Cryptographic Module 1.0    FIPS 140‐2 Non‐Proprietary   Security Policy    Level 1 Validation    Document revision 012, 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  .................................................................................................................... 4  . 2  McAfee Endpoint Encryption Disk Driver ................................................................................................ 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  ................................................................................................................... 7  . 2.2.4  Cryptographic Algorithms .......................................................................................................... 7  2.2.5  Components excluded from the security requirements of the standard ................................. 8  2.3  Physical ports and logical interfaces ................................................................................................. 8  2.4  Roles, Services and Authentication ................................................................................................... 9  2.4.1  Roles ........................................................................................................................................... 9  2.4.2  Services ...................................................................................................................................... 9  2.4.3  Authentication ......................................................................................................................... 11  2.5  Physical Security .............................................................................................................................. 11  2.6  Operational Environment  ............................................................................................................... 12  . 2.7  Cryptographic Key Management .................................................................................................... 12  2.7.1  Random Number Generators .................................................................................................. 12  2.7.2  Key Generation ........................................................................................................................ 12  2.7.3  Key Table .................................................................................................................................. 12  2.7.4  Key Destruction ........................................................................................................................ 13  2.7.5  Access to Key Material ............................................................................................................. 13  2.8  Self‐Tests ......................................................................................................................................... 14  2.8.1  Power‐up self‐tests .................................................................................................................. 14  2.8.2  Conditional self‐tests ............................................................................................................... 14  2.9  Design Assurance ............................................................................................................................ 14  2.10  Mitigation of Other Attacks ......................................................................................................... 15  3  FIPS Mode of Operation  ........................................................................................................................ 15  . 3.1  Deploying in FIPS mode ................................................................................................................... 16    Figures  Figure 1 Block Diagram of the Cryptographic Boundary ................................................................................. 6  Figure 2 Security Level specification per individual areas of FIPS 140‐2 ......................................................... 7  Figure 3 Approved Algorithms ......................................................................................................................... 7  Figure 4 Module Interfaces .............................................................................................................................. 8  Figure 5 Roles ................................................................................................................................................... 9      2 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  Figure 6 User Services .................................................................................................................................... 11  Figure 7 Crypto Officer Services  .................................................................................................................... 11  . Figure 8 Key Table .......................................................................................................................................... 13  Figure 9 Access to keys by services ................................................................................................................ 14  Figure 10 Power‐up self‐tests ........................................................................................................................ 14        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    Disk Driver 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 Disk Driver  Cryptographic Module, also referred to as “the module” within this document. This Security Policy details  the secure operation of McAfee Endpoint Encryption Disk Driver 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.  1.5 Document Terminology  TERM  DESCRIPTION  AES  Advanced Encryption Standard  AES‐NI  Advanced Encryption Standard New Instructions. Seven instructions for      4 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  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)  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 Disk Driver  This section provides the details of how the module meets the FIPS 140‐2 requirements.  2.1 Overview  The module provides AES encryption services to the 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 Microsoft Windows kernel mode device driver.      5 © 2011 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 1).    It is packaged as a binary image:     FILE NAME  OPERATING ENVIRONMENT  MfeEEAlg.sys  Microsoft Windows    There are two distinct, though functionally identical versions of the module, one for 32‐bit operating  environments and the other for 64‐bit operating environments.   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 1. The module is a software module running in the 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.        Figure 1 Block Diagram of the Cryptographic Boundary      6 © 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 2 Security Level specification per individual areas of FIPS 140‐2    2.2.4 Cryptographic Algorithms  The following approved algorithms are included within the module:    ALGORITHM TYPE  ALGORITHM  CAVP CERTIFICATE  USE  Hashing  SHA‐256  #1654  Used in the module integrity test. Message authentication  HMAC  #1125  Module integrity testing.  code  Symmetric key  AES‐256 – CBC and  #1882  Service provided to encrypt and  CFB8. Encrypt and  decrypt block of data.  decrypt      Figure 3 Approved Algorithms    Note: The AES‐256 algorithm 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.          7 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  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)   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 all 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 may 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 4 Module Interfaces      8 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  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 5 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  Key  epe_aesfips_init_key_context  Initialises an AES key  Key and key  Status, either  expansion with the  context  success (zero) or  given key data.  failure (non‐zero  return code).    epe_aesfips_reset_key_context Resets the given key  Key context  Status, either  context.  success (zero) or  failure (non‐zero  return code).    epe_aesfips_generate_key  In this version of the  N/A  N/A  module, this  function does  nothing. It is a  placeholder  reserved for future  use.  Symmetric  epe_aesfips_crypt_bytes  Encrypts or decrypts  Encryption:  Encryption:  encryption  some data.  plaintext data,  encrypted data.  key context    and IV.            9 © 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  Decryption:  Decryption:  encrypted  plaintext data.  data, key  context and IV    epe_aesfips_crypt_blocks  Encrypts or decrypts  Encryption:  Encryption:  data in blocks with  plaintext data,  encrypted data.  the given key  key context    (context).  and IV.        Decryption:  Decryption:  encrypted  plaintext data.  data, key  context and IV    epe_aesfips_get_info  Gets the  None  Information about  information about  the encryption  the algorithm.  algorithm.  Self‐tests  N/A  The power‐up  None  If integrity test  software integrity  passes, the  test and AES Known  module writes the  answer test are run  string “Pass” to  automatically when  the module  the module is  IntegrityStatus  loaded and started.  registry key,  otherwise writes  the string “Fail” to  this registry key  and initiates a  stop error.    If the algorithm  self‐tests pass,  the module is  initialised and the  entry function  returns SUCCESS.  If the algorithm  self‐tests fail, the  module returns  an error and is  not loaded.  Show Status  N/A  Status is returned in  None  Module Status  response to      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  individual service  API calls and at the  completion of the  self‐tests.    Figure 6 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  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 storage and  then remove the endpoint  software, including the  cryptographic module  software.  Key Zeroization  N/A  Keys are zeroized using the  None  All keys zeroized.  zeroization procedure. This  is described in section  2.7.4.    Figure 7 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.          11 © 2011 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 operating systems:     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.    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 does not contain any random number generators.  2.7.2 Key Generation  The module does not generate keys.  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  System Key  HMAC‐SHA‐256 Integrity Key  PURPOSE  To encrypt all user data written  A fixed key used in the module  to the hard disk and decrypt all  integrity checking power‐up self‐     12 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  user data read from it.  test  KEY LENGTH/STRENGTH  AES 256 bit  256 bits  GENERATION/ESTABLISHMENT  N/A  Fixed key  STORAGE LOCATION  Not persistently stored.  Hard coded  ENCRYPTED/PLAINTEXT  Plaintext  Plaintext  ENTRY/OUTPUT  Entered into module via user  N/A  service API. Not output.  DESTRUCTION  Zeroized using the key  Zeroized using the key  zeroization service.  zeroization service.    Figure 8 Key Table    2.7.4 Key Destruction  All key material managed by the module can be zeroized using the 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.  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 SYSTEM KEY      SERVICE  User Services    Key  W  Symmetric encryption  RWU Self‐tests    Show Status    Crypto Office Services    Installation  U      13 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  KEY SYSTEM KEY      SERVICE  Uninstallation  U  Key Zeroization  W    Figure 9 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.    2.8 Self‐Tests  The module implements the self‐tests required by FIPS 140‐2. The following two sections outline the tests  that are performed.  2.8.1 Power‐up self‐tests    OBJECT  TEST  AES‐256  Known answer test  Module software  HMAC SHA‐256 Integrity Check    Figure 10 Power‐up self‐tests    2.8.2 Conditional self‐tests  There are no conditional tests that are run by the module.  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  module is stored with a label corresponding to the version of the module and that the module and all of      14 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  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  HKEY_LOCAL_MACHINE\  FipsMode  DWORD  0 = Not in FIPS mode  System\    CurrentControlSet\  Any non‐zero value indicates FIPS  Services\MfeEEAlg\Fips  mode operation.    When the module is not in FIPS mode the power‐up integrity checks are not performed.    When the module is in FIPS mode the power‐up integrity checks are performed.    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.        15 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.  www.mcafee.com  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.              16 © 2011 McAfee, Inc.  This document may be freely reproduced and distributed whole and intact including this copyright notice.