FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)            FIPS 140‐2 Non‐Proprietary Security Policy      McAfee ePO Cryptographic Module (Version 1.0)              Document Version 1.4          July 19, 2011      Document Version 1.4  © McAfee  Page 1 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  Prepared For:  Prepared By:      McAfee, Inc.  Apex Assurance Group, LLC  2821 Mission College Blvd  530 Lytton Avenue, Ste. 200  Santa Clara, CA 95054  Palo Alto, CA 94301   www.mcafee.com  www.apexassurance.com        Abstract    This document provides a non‐proprietary FIPS 140‐2 Security Policy for the ePO Cryptographic Module  (Version 1.0).    Document Version 1.4  © McAfee  Page 2 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  Table of Contents  1  Introduction ................................................................................................................................................ 5  1.1  About FIPS 140  ................................................................................................................................................    . 5 1.2  About this Document .......................................................................................................................................    5 1.3  External Resources  ..........................................................................................................................................    . 5 1.4  Notices .............................................................................................................................................................    5 1.5  Acronyms .........................................................................................................................................................   6 2  McAfee ePO Cryptographic Module (Version 1.0) ......................................................................................... 7  2.1  Product Overview ............................................................................................................................................    7 2.2  Cryptographic Module Specification  ...............................................................................................................    . 7 2.3  Validation Level Detail .....................................................................................................................................    8 2.4  Cryptographic Algorithms  ...............................................................................................................................    . 8 2.4.1  Algorithm Implementation Certificates ...................................................................................................    8 2.4.2  Non‐Approved Algorithms .......................................................................................................................    9 2.5  Module Interfaces  .........................................................................................................................................  0  . 1 2.6  Roles, Services, and Authentication ...............................................................................................................  1  1 2.6.1  Operator Services and Descriptions .......................................................................................................  1  1 2.6.2  Operator Authentication ........................................................................................................................  5  1 2.7  Physical Security ............................................................................................................................................  6  1 2.8  Operational Environment ..............................................................................................................................  6  1 2.9  Cryptographic Key Management ...................................................................................................................  7  1 2.9.1  Key Generation ......................................................................................................................................  0  2 2.9.2  Key Entry, Output, and Protection .........................................................................................................  0  2 2.10  Self‐Tests......................................................................................................................................................  1  2 2.10.1  Power‐On Self‐Tests .............................................................................................................................  1  2 2.10.2  Conditional Self‐Tests  ..........................................................................................................................  2  . 2 2.11  Mitigation of Other Attacks .........................................................................................................................  2  2 3  Guidance and Secure Operation ..................................................................................................................  3  2 3.1  Crypto Officer and User Guidance .................................................................................................................  3  2 3.1.1  Software Packaging and OS Requirements ............................................................................................  3  2 3.1.2  Enabling FIPS Mode  ...............................................................................................................................  3  . 2 3.1.3  Additional Rules of Operation ................................................................................................................  4  2   Document Version 1.4  © McAfee  Page 3 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  List of Tables    Table 1 – Acronyms and Terms  .....................................................................................................................................    . 6 Table 2 – Validation Level by DTR Section .....................................................................................................................    8 Table 3 – FIPS‐Approved Algorithm Certificates Crypto J ..............................................................................................    9 Table 4 – FIPS‐Approved Algorithm Certificates Crypto C ME .......................................................................................    9 Table 5 – Logical Interface / Physical Interface Mapping ............................................................................................  1  1 Table 6 – Authenticated Module Services and Descriptions for Crypto J Implementation .........................................  3  1 Table 7 – Unauthenticated Module Services and Descriptions for Crypto J Implementation.....................................  3  1 Table 8 – Authenticated Module Services and Descriptions for Crypto C ME Implementation ..................................  5  1 Table 9 – Unauthenticated Module Services and Descriptions for Crypto C ME Implementation .............................  5  1 Table 10 – Module Keys/CSPs  .....................................................................................................................................  0  . 2 Table 11 – Module Power‐On Self‐Tests .....................................................................................................................  1  2 Table 12 – Module Conditional Self‐Tests ...................................................................................................................  2  2   List of Figures    Figure 1 – Module Interfaces Diagram ........................................................................................................................  0  1   Document Version 1.4  © McAfee  Page 4 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  1 Introduction  1.1 About FIPS 140  Federal Information Processing Standards Publication 140‐2 — Security Requirements for Cryptographic  Modules specifies requirements for cryptographic modules to be deployed in a Sensitive but  Unclassified environment. The National Institute of Standards and Technology (NIST) and  Communications Security Establishment of Canada (CSEC) Cryptographic Module Validation Program  (CMVP) runs the FIPS 140 program. The CMVP accredits independent testing labs to perform FIPS 140  testing; the CMVP also validates test reports for products meeting FIPS 140 validation. Validated is the  term given to a product that is documented and tested against the FIPS 140 criteria.  More information is available on the CMVP website at  http://csrc.nist.gov/groups/STM/cmvp/index.html.   1.2 About this Document  This non‐proprietary Cryptographic Module Security Policy for the ePO Cryptographic Module (Version  1.0) from McAfee provides an overview of the product and a high‐level description of how it meets the  security requirements of FIPS 140‐2. This document contains details on the module’s cryptographic keys  and critical security parameters. This Security Policy concludes with instructions and guidance on  running the module in a FIPS 140‐2 mode of operation.   The McAfee ePO Cryptographic Module (Version 1.0) may also be referred to as the “module” in this  document.   1.3 External Resources  The McAfee website (http://www.mcafee.com) contains information on the full line of products from  McAfee, including a detailed overview of the ePO Cryptographic Module (Version 1.0) solution. The  Cryptographic Module Validation Program website  (http://csrc.nist.gov/groups/STM/cmvp/documents/140‐1/1401val2011.htm) contains links to the FIPS  140‐2 certificate and McAfee contact information.  1.4 Notices  This document may be freely reproduced and distributed in its entirety without modification.  Document Version 1.4  © McAfee  Page 5 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  1.5 Acronyms  The following table defines acronyms found in this document:   Acronym  Term  AES  Advanced Encryption Standard  CBC  Cipher Block Chaining  CSEC  Communications Security  Establishment of Canada  CSP  Critical Security Parameter  DTR  Derived Testing Requirement  ePO  ePolicy Orchestrator  FIPS  Federal Information Processing  Standard  GPC  General Purpose Computer  GPOS  General Purpose Operating System  GUI  Graphical User Interface  HMAC  Hashed Message Authentication Code  KAT  Known Answer Test  NIST  National Institute of Standards and  Technology  RSA  Rivest Shamir Adelman  RSD  Remote Sensor Detection  SHA  Secure Hashing Algorithm  Table 1 – Acronyms and Terms    Document Version 1.4  © McAfee  Page 6 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  2 McAfee ePO Cryptographic Module (Version 1.0)  2.1 Product Overview  McAfee ePolicy Orchestrator is a scalable management framework for centralized policy management  and enforcement of McAfee’s security products and the systems on which they reside. ePO provides the  user interface for McAfee products and performs the following tasks:   Agent deployment   Security Management   Reporting    More information on ePO can be found at http://www.mcafee.com/us/products/epolicy‐ orchestrator.aspx.   2.2 Cryptographic Module Specification  The module is the McAfee ePO Cryptographic Module (Version 1.0), provides the ePO application with  cryptographic functionality. The module is a software‐only module installed on a multi‐chip standalone  device, such as a General Purpose Computer running a General Purpose Operating System and provides  cryptographic services to the McAfee ePO application.   The module is a uniquely identifiable set of libraries built into the ePO application. All operations of the  module occur via calls from the ePO application and its internal daemons, and all calls are authenticated  via digital signature. As such there are no untrusted services or daemons calling the services of the  module. No security functions outside the cryptographic module provide FIPS‐relevant functionality to  the module.   Once configured for FIPS mode of operation (see the Guidance and Secure Operation section), the  module cannot be placed into a non‐FIPS mode.   The boundary is composed of the following files:   ccme_base.dll   cryptocme2.dll   nmcomn32.dll   jsafeJCEFIPS.jar   orion‐core‐common.jar  This module contains two embedded, validated modules (see certificates 1047 and 1092). The module  operates with both embedded modules simultaneously. Nmcomn32.dll accepts calls for cryptographic  operations and performs the module integrity check over all files in the cryptographic boundary.   Document Version 1.4  © McAfee  Page 7 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)    2.3 Validation Level Detail  The following table lists the level of validation for each area in FIPS 140‐2:    FIPS 140‐2 Section Title  Validation Level  Cryptographic Module Specification  1  Cryptographic Module Ports and Interfaces  1  Roles, Services, and Authentication  2  Finite State Model  1  Physical Security  N/A  Operational Environment  1  Cryptographic Key Management  1  Electromagnetic Interference / Electromagnetic Compatibility  1  Self‐Tests  1  Design Assurance  3  Mitigation of Other Attacks  N/A  Table 2 – Validation Level by DTR Section  The “Mitigation of Other Attacks” section is not relevant as the module does not implement any  countermeasures towards special attacks.  2.4 Cryptographic Algorithms  2.4.1 Algorithm Implementation Certificates  The module’s cryptographic algorithm implementations1 have received the following certificate  numbers from the Cryptographic Algorithm Validation Program:  Algorithm  Algorithm  CAVP Certificate  Use  Type  Asymmetric  RSA 3072‐bit  312  Sign / verify operations  Key  Key establishment    Module integrity  Hashing  SHA‐1, SHA‐256  703  User password hashing  Digital signature generation and  validation (SHA‐256)  Symmetric Key  AES 128 in ECB mode  670  Data encryption/ decryption                                                               1  Please note that the standards for each algorithm are listed with the respective CAVP certificate.  Document Version 1.4  © McAfee  Page 8 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  Algorithm  Algorithm  CAVP Certificate  Use  Type  Random  FIPS 186‐2 PRNG  390  Random Number Generation  Number  (Change Notice 1‐with  Generation  and without the mod  q step)  Table 3 – FIPS‐Approved Algorithm Certificates Crypto J2    Algorithm  Algorithm  CAVP Certificate  Use  Type  Asymmetric  RSA 2048‐bit   412  Sign / verify operations  Key  RSA 3072‐bit     Module integrity    DSA 1024‐bit   311  Verification of legacy data   Hashing  SHA‐1, SHA‐256  855  Digital signature generation and  verification (SHA‐256)    Verification of legacy data (SHA‐ 1)    User password hashing  Symmetric Key  AES 128‐bit and 256‐ 860  Data encryption/ decryption  bit in CBC and ECB  mode  3DES mode CBC mode  707  Decryption of legacy data  Random  FIPS 186‐2 PRNG  492  Random Number Generation  Number  (Change Notice 1‐with  Generation  and without the mod  q step)  Table 4 – FIPS‐Approved Algorithm Certificates Crypto C ME3  2.4.2 Non­Approved Algorithms  The module implements the following non‐FIPS approved algorithms:   Software‐based random number generator  This RNG is used only as a seeding mechanism to the FIPS‐approved PRNG.  o                                                              2  Note this implementation has received FIPS 140‐2 Level 1 validation certificate #1047:  http://csrc.nist.gov/groups/STM/cmvp/documents/140‐1/1401val2008.htm#1047  3 Note this implementation has received FIPS 140‐2 Level 1 validation certificate #1092:  http://csrc.nist.gov/groups/STM/cmvp/documents/140‐1/1401val2009.htm#1092  Document Version 1.4  © McAfee  Page 9 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  2.5 Module Interfaces  The figure below shows the module’s physical and logical block diagram:    Figure 1 – Module Interfaces Diagram  The interfaces (ports) for the physical boundary include the computer keyboard port, CDROM drive,  floppy disk, mouse, network port, parallel port, USB ports, monitor port and power plug. When  operational, the module does not transmit any information across these physical ports because it is a  software cryptographic module. Therefore, the module’s interfaces are purely logical and are provided  through the Application Programming Interface (API) that a calling daemon can operate. The logical  interfaces expose services that applications directly call, and the API provides functions that may be  called by a referencing application (see Section 2.6 – Roles, Services, and Authentication for the list of  available functions).   The API provided by the module is mapped onto the FIPS 140‐ 2 logical interfaces: data input, data  output, control input, and status output. Each of the FIPS 140‐ 2 logical interfaces relates to the  module's callable interface, as follows:  FIPS 140‐2 Interface  Logical Interface  Module Physical Interface  Data Input   Input parameters of API function  Ethernet/Network port  calls  Data Output   Output parameters of API function  Ethernet/Network port  calls  Document Version 1.4  © McAfee  Page 10 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  FIPS 140‐2 Interface  Logical Interface  Module Physical Interface  Control Input   API function calls  Keyboard and mouse  Status Output   For FIPS mode, function calls  Monitor  returning status information and  return codes provided by API  function calls.   Power   None  Power supply/connector  Table 5 – Logical Interface / Physical Interface Mapping  The module’s logical interfaces are provided only through the Application Programming Interface (API)  that a calling daemon can operate. The module distinguishes between logical interfaces by logically  separating the information according to the defined API.  As shown in Figure 1 – Module Interfaces Diagram and Table 6 – Authenticated Module Services and  Descriptions , the output data path is provided by the data interfaces and is logically disconnected from  processes performing key generation or zeroization. No key information will be output through the data  output interface when the module zeroizes keys.  2.6 Roles, Services, and Authentication  The module supports a Crypto Officer and a User role as specified in the following section. The module  does not support a Maintenance role.  2.6.1 Operator Services and Descriptions  The services available to the User and Crypto Officer roles in the module are as follows:  Document Version 1.4  © McAfee  Page 11 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)    Key/CSP  Service  Description  Service Input/Output (API)  Roles  Access  com.mcafee.orion.core.security.FIPS14 Configure  Initializes the  RSA Integrity  User  0.init()  module for  and  FIPS mode of  Authentication  operation  Public Key  Sign /  Sign data or  CryptoJ classes which are subtypes of Java’s  RSA Public Key  User  Verify  Verify a     java.security.SignatureSpi abstract  signature  class.  RSA Private Key      Example Usage:  DSA Public Key  com.mcafee.orion.core.CertUtil.genera for verification  teSignedCert() of legacy data  com.mcafee.orion.core.ext.ExtensionSi   gnatureUtil  RSA Integrity  and  Authentication  Public Key  Encrypt /  Encrypts or  CryptoJ classes which are subtypes of Java’s  Session Key  User  Decrypt  Decrypts a    javax.crypto.CipherSpi abstract class.  block of data     TDES Legacy  Example Usage:  Key  com.mcafee.orion.core.cert.DefaultObf   uscator  RSA Integrity  and  Authentication  Public Key  Random  Generates  CryptoJ classes which are subtypes of Java’s  FIPS 186‐2  User  Number  random  PRNG Seed  java.security.SecureRandomSpi class.  Generation  numbers for       crypto  Example Usage:  FIPS 186‐2  com.mcafee.orion.core.cert.CertUtil operations  PRNG Seed Key  com.mcafee.orion.core.cert.DefaultObf   uscator RSA Integrity  org.apached.tomcat.util.net.jsse.JSSE and  14SocketFactory  Authentication  Public Key  com.mcafee.orion.core.RSASecurityProv Self Test  Performs self  RSA Integrity  User  iders tests on  and  critical  Authentication  runFIPS140SelfChecks() functions of  Public Key     module     com.rsa.jsafe.CryptoJ.getMode() Show  Shows status  RSA Integrity  User  com.rsa.jsafe.CryptoJ.getState() Status  of the module  and     and view audit  Authentication     information  Public Key  Document Version 1.4  © McAfee  Page 12 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  Key/CSP  Service  Description  Service Input/Output (API)  Roles  Access  com.rsa.jsafe.provider.SensitiveData. Zeroization  Zeroizes keys  RSA Integrity  User  clear() and     Authentication  Public Key  Table 6 – Authenticated Module Services and Descriptions for Crypto J Implementation    Key/CSP  Service  Description  Service Input/Output (API)  Roles  Access  Reboot  Restart  Restart module or application None  Crypto  module or  Officer  application  Procedural  Zeroize keys  RAM keys are zeroized when the Operating  All Keys  Crypto  Zeroization  stored on disk  System clears the process memory, static  Officer  in keystore   Keys stored on disk are zeroized according  to IG 7.9 by uninstalling the module and  formatting the disk  Table 7 – Unauthenticated Module Services and Descriptions for Crypto J Implementation    Key/CSP  Service  Description  Service Input/Output (API)  Roles  Access  R_FIPS140_library_init() Configure  Initializes the  RSA Integrity  User  PRODUCT_FIPS_140_MODE_RESOURCE_LIST() module for  and    R_FIPS140_get_default() FIPS mode of  R_FIPS140_get_mode() Authentication  operation  Public Key  R_FIPS140_get_info()  R_CR_sign() Sign  Sign data  RSA Private  User  Key    RSA Integrity  and  Authentication  Public Key  R_CR_verify() Verify  Verify a  RSA Public Key  User  signature    DSA Public Key  for verification  of legacy data    RSA Integrity  and  Authentication  Public Key  Document Version 1.4  © McAfee  Page 13 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  Key/CSP  Service  Description  Service Input/Output (API)  Roles  Access  R_CR_decrypt_final() Decrypt  Decrypts a  Session Key  User  R_CR_decrypt_init() block of data    R_CR_decrypt_update() Using AES  TDES Legacy  Key    RSA Integrity  and  Authentication  Public Key  R_CR_encrypt_final() Encrypt  Encrypts a  Session Key  User  R_CR_encrypt_init() block of data    R_CR_encrypt_update() Using AES  RSA Integrity  and  Authentication  Public Key  R_CR_random_bytes() Random  Generates  FIPS 186‐2  User  R_CR_random_seed() Number  random  PRNG Seed  Generation  numbers for    crypto  FIPS 186‐2  operations   PRNG Seed  Key    RSA Integrity  and  Authentication  Public Key  R_PKEY_from_public_key_binary() Generate  Generates an  RSA Public Key  User  R_PKEY_to_public_key_binary() Key   asymmetric    R_PKEY_from_binary() key   RSA Private  R_PKEY_to_binary() Key  R_CR_generate_key()   RSA Integrity  and  Authentication  Public Key  Performs self  comnutil_CheckTrustedModules() Self Test  RSA Integrity  User  tests on  and  critical  Authentication  functions of  Public Key  module  Show Status  Shows status  R_FIPS140_get_mode() RSA Integrity  User  of the  and  module and  Authentication  view audit  Public Key  information  Document Version 1.4  © McAfee  Page 14 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  Key/CSP  Service  Description  Service Input/Output (API)  Roles  Access  Zeroizes keys  R_PKEY_free() Zeroization  RSA Integrity  User    R_SKEY_free() and  Authentication  Public Key  Table 8 – Authenticated Module Services and Descriptions for Crypto C ME Implementation      Key/CSP  Service  Description  Service Input/Output (API)  Roles  Access  Reboot  Restart  Restart module or application None  Crypto  module or  Officer  application  Procedural  Zeroize keys  RAM keys are zeroized when the Operating  All Keys  Crypto  Zeroization  stored on disk  System clears the process memory, static  Officer  in keystore   Keys stored on disk are zeroized according  to IG 7.9 by uninstalling the module and  formatting the disk  Table 9 – Unauthenticated Module Services and Descriptions for Crypto C ME Implementation    2.6.2 Operator Authentication  The module supports Level 2 requirements for authentication, which defines role‐based authentication.  The module verifies the digital signatures of calling daemons prior to the allowing access to any module  services. The signature is RSA 2048‐bit key with SHA‐256 hash signature. Since this key has 112‐bits of  security strength the probability of a successful random attempt is 1/2112, which is less than  1/1,000,000. Assuming a scripted attack of 60 attempts in one minute, the probability of a success with  multiple consecutive attempts in a one‐minute period is 60/2112 which is less than 1/100,000.  The module contains User authentication data in the form of the public key but does not contain CO  authentication data. The User Services require authentication, which is performed by the module as  described above. The Crypto Officer services do not require authentication as they are not security  relevant functions. The Reboot and Procedural Zeroization services do not affect the security of the  module; these services do not create, disclose, or substitute cryptographic keys or CSPs, nor do they  utilize any Approved security functions.  The module does not permit an operator to change roles. The services described in Table 6 –  Authenticated Module Services and Descriptions for Crypto J Implementation and Table 8 –  Authenticated Module Services and Descriptions for Crypto C ME Implementation are only available to  the roles specified, and access to these services is protected via authentication mechanisms discussed  above.   Document Version 1.4  © McAfee  Page 15 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  2.7 Physical Security  This section of requirements does not apply to this module. The module is a software‐only module and  does not implement any physical security mechanisms.  2.8 Operational Environment  The module operates on a general‐purpose computer (GPC) running a general‐purpose operating  system (GPOS). The module was tested on the following:   Microsoft Windows XP Professional on Intel Core2 Duo  For FIPS purposes, the module is running on a platform in single user mode and does not require any  additional configuration to meet the FIPS requirements.  The GPC(s) used during testing met Federal Communications Commission (FCC) FCC Electromagnetic  Interference (EMI) and Electromagnetic Compatibility (EMC) requirements for business use as defined  by 47 Code of Federal Regulations, Part15, Subpart B. FIPS 140‐2 validation compliance is maintained  when the module is operated on other versions of the Microsoft Windows GPOS running in single user  mode, assuming that the requirements outlined in NIST IG G.5 are met.  Document Version 1.4  © McAfee  Page 16 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  2.9 Cryptographic Key Management  The table below provides a complete list of Critical Security Parameters used within the module:  Establishment /  Key/CSP Name  Description / Use  Generation  Storage  Interface  Privileges  Export  RSA Integrity and  Public 2048‐bit RSA  Generated at build  Storage: RAM, on‐disk  Agreement: NA  Module  CO  Authentication  certificate used to  time  in plaintext    Integrity  R W D   Public Key  verify binaries at    Entry: Electronic   check (verify)    startup (integrity test  Type: Ephemeral    User   and authentication)     Output: NA  R W D  Association: The system  is the one and only  owner. Relationship is  maintained by the  operating system via  protected memory.  RSA Public Key  RSA 2048‐bit or 3072‐ Generated via FIPS‐ Storage: RAM plaintext  Agreement: NA  Sign / verify  CO  bit public key for  approved PRNG      D  signature verification  Type: Ephemeral  Entry: NA          User   RSA 1024‐bit public  Association: The system  Output: NA  R W D  key for verification of  is the one and only  legacy signatures  owner. Relationship is  maintained by the  operating system via  protected memory.  Document Version 1.4  © McAfee  Page 17 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  Establishment /  Key/CSP Name  Description / Use  Generation  Storage  Interface  Privileges  Export  RSA Private Key  RSA 2048‐bit or 3072‐ Generated via FIPS‐ Storage: RAM plaintext  Agreement: NA  Sign / verify  CO  bit private key for  approved PRNG      D  signature generation  Type: Ephemeral  Entry: NA        User   Association: The system  Output: NA  R W D  is the one and only  owner. Relationship is  maintained by the  operating system via  protected memory.  Session Key  General purpose AES  Generated via FIPS‐ Storage: RAM plaintext  Agreement: NA  Encrypt /  CO  128‐bit ECB key for  approved PRNG      Decrypt  D  data encryption /  Type: Ephemeral  Entry: NA    decryption      User   Association: The system  Output: NA  R W D  is the one and only  owner. Relationship is  maintained by the  operating system via  protected memory.  TDES Legacy Key  General purpose TDES  Passed by calling  Storage: RAM plaintext  Agreement: NA  Decrypt  CO  key for data  process      D  decryption of legacy  Type: Ephemeral  Entry: Electronic by    data    calling application  User   Association: The system    R W D  is the one and only  Output: NA  owner. Relationship is  maintained by the  operating system via  protected memory.  Document Version 1.4  © McAfee  Page 18 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  Establishment /  Key/CSP Name  Description / Use  Generation  Storage  Interface  Privileges  Export  DSA Public Key  McAfee public  Generated at build  Storage: RAM, on‐disk  Agreement: NA  Verify  CO  repository DSA 1024‐ time  in plaintext     D  bit key for verifying    Entry: Electronic by    legacy signatures   Type: Static  calling application  User       R W D  Association: The system  Output: NA  is the one and only  owner. Relationship is  maintained by the  operating system via  protected memory.  FIPS 186‐2 PRNG  Seed value for  Internally  Storage: RAM plaintext   Agreement: NA  Random  CO  approved PRNG  generated      Number  D  Seed  Type: Ephemeral  Entry: NA  Generation        User   Association: The system  Output: NA  R W D  is the one and only  owner. Relationship is  maintained by the  operating system via  protected memory.  FIPS 186‐2 PRNG  Seed key for approved  Internally  Storage: RAM plaintext   Agreement: NA  Random  CO  PRNG  generated      Number  D  Seed Key  Type: Ephemeral  Entry: NA  Generation        User   Association: The system  Output: NA  R W D  is the one and only  owner. Relationship is  maintained by the  operating system via  protected memory.  Document Version 1.4  © McAfee  Page 19 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  Establishment /  Key/CSP Name  Description / Use  Generation  Storage  Interface  Privileges  Export  CO Password  Crypto Officer  No  Storage: on disk  Agreement: NA  Control Input  CO  password  plaintext     Physical  R W D    Entry: Electronic  Interface  Type: Static      Output: NA  Association: The system  is the one and only  owner. Relationship is  maintained by the  operating system via  protected memory.  R = Read    W = Write    D = Delete  Table 10 – Module Keys/CSPs  2.9.1 Key Generation  The module supports the generation of the asymmetric and symmetric keys via Federal Information processing Standard 186‐2, Digital Signature  Standard (FIPS 186‐2) Approved random number generator.  2.9.2 Key Entry, Output, and Protection  All keys and CSPs reside on memory internally allocated by the module and can only be output using the exposed APIs.  The module does not  support key entry or output from the physical boundary.  The operating system and runtime environment protect the memory and process  space from unauthorized access.  Document Version 1.4  © McAfee  Page 20 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  2.10 Self­Tests  The module includes an array of self‐tests that are run during startup and periodically during operations  to prevent any secure data from being released and to ensure all components are functioning correctly.  In the event of any self‐test failure, the module/ePO application will output an error to the audit log and  will shutdown. In addition to self‐test failures, successful loading of the module is also logged. To access  status of self‐tests, success or failure, the application provides access to the audit log. Status is viewable  via operating environment’s audit mechanism and by verifying proper loading and operation of the ePO  application. While the module is running self‐tests, the module will not output data. The ePO application  makes calls to the ePO Cryptographic Module (Version 1.0), and data will not be returned until the self‐ tests complete.   No keys or CSPs will be output when the module is in an error state. The module will halt and the  process will terminate; as such, no data will be output via the data output interface. Additionally, the  module does not support a bypass function, and the module does not allow plaintext cryptographic key  components or other unprotected CSPs to be output on physical ports. No external software or  firmware is allowed to be loaded in a FIPS mode of operation.   The following sections discuss the module’s self‐tests in more detail.  2.10.1 Power­On Self­Tests  Power‐on self‐tests are run upon every initialization of the module and if any of the tests fail, the  module will not initialize. The module will enter an error state and no services can be accessed by the  users. The module implements the following power‐on self‐tests:  Implementation  POST   Crypto J  RSA pairwise consistency (signing and signature verification)   SHA‐1 and SHA‐256 KAT   AES KAT (encryption and decryption)   KAT for Approved PRNG   KAT for non‐approved software RNG   Crypto C ME  RSA pairwise consistency (signing and signature verification)   DSA pairwise consistency (signing and signature verification)   SHA‐1 and SHA‐256 KAT   AES KAT (encryption and decryption)   TDES KAT (encryption and decryption)   KAT for Approved PRNG   KAT for non‐approved software RNG   ePO  Module integrity check via Crypto J implementation of RSA  Table 11 – Module Power‐On Self‐Tests  The module performs all power‐on self‐tests automatically when the module is initialized. All power‐on  self‐tests must be passed before a User/Crypto Officer can perform services. The Power‐on self‐tests can  Document Version 1.4  © McAfee  Page 21 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  be run on demand by reinitializing the module in FIPS approved Mode of Operation. Upon passing the  power‐on self‐tests, the module will log the success and will continue to boot normally; successful  loading of the ePO application will indicate that all self‐tests have passed. If a self‐test fails, the module  will not load, the ePO application will halt, and an error will be logged in the server.log file.   2.10.2 Conditional Self­Tests  Conditional self‐tests are on‐demand tests and tests run continuously during operation of the module. If  any of these tests fail, the module will enter an error state and no services can be accessed by the users.  The module can be re‐initialized to clear the error and resume FIPS mode of operation. The module  performs the following conditional self‐tests:  Implementation  Conditional Test   Crypto J  RSA pairwise consistency    Continuous RNG test run on output of Approved PRNG   Continuous test on output of Approved PRNG seed mechanism   Test to ensure Approved PRNG output and seed do not match   Crypto C ME  RSA pairwise consistency   DSA pairwise consistency    Continuous RNG test run on output of Approved PRNG   Continuous test on output of Approved PRNG seed mechanism   Test to ensure Approved PRNG output and seed do not match  Table 12 – Module Conditional Self‐Tests  The module will inhibit data output via the output interface when conditional tests are performed. Once  the tests have passed and the keys have been generated, the module will pass the key to the calling  daemon. If a self‐test fails, the module will halt, the ePO application will halt, and an error will be logged  in the server.log file.  2.11 Mitigation of Other Attacks  The module does not mitigate other attacks.      Document Version 1.4  © McAfee  Page 22 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  3 Guidance and Secure Operation  This section describes how to configure the module for FIPS‐approved mode of operation. Operating the  module without maintaining the following settings will remove the module from the FIPS‐approved  mode of operation.    3.1 Crypto Officer and User Guidance  3.1.1 Software Packaging and OS Requirements  The ePO Cryptographic Module (Version 1.0) can only be used by the ePO application, which is not being  validated under FIPS 140‐2. The ePO application must be installed on a Microsoft Windows Operating  System running in single user mode. To configure single‐user mode, the following must be disabled:   Remote registry and remote desktop services   Remote assistance   Guest accounts   Server and terminal services  Contact Microsoft support for configuration details; specific configuration steps are beyond the scope of  this document.  3.1.2 Enabling FIPS Mode  To meet the cryptographic security requirements, certain restrictions on the installation and use of ePO  must be followed. The steps below will ensure that the module implements all required self‐tests and  uses only approved algorithms. Please note that once the module is in FIPS‐approved mode, it cannot  transition to a non‐approved mode.   3.1.2.1 Installation  1. The installation must be a new install.  Upgrading from a previous version of ePO is not valid.  2. During the installation process, enter the following command at the CLI:  C:\> \setup.exe ENABLEFIPSMODE=1 3. After installation, edit \server\logs\log-config.xml. Change  the priority value parameter of the root logger level from warn to info.  Document Version 1.4  © McAfee  Page 23 of 24  FIPS 140‐2 Non‐Proprietary Security Policy: McAfee ePO Cryptographic Module (Version 1.0)  3.1.3 Additional Rules of Operation  1. All host system components that can contain sensitive cryptographic data (main memory,  system bus, disk storage) must be located in a secure environment.  2. The writable memory areas of the Module (data and stack segments) are accessible only by the  ePO application so that the Module is in "single user" mode, i.e. only the ePO application has  access to that instance of the Module.  3. Only 2048‐bit asymmetric keys should be used where available.  4. The operating system is responsible for multitasking operations so that other processes cannot  access the address space of the process containing the Module.    Document Version 1.4  © McAfee  Page 24 of 24