VMware Inc. ACE Encryption Engine (Software Version: 1.0) FIPS 140-2 Non-Proprietary Security Policy Level 1 Validation Document Version 0.4 Prepared for: Prepared by: VMware Inc. Corsec Security, Inc. 3145 Porter Drive 10340 Democracy Lane, Suite 201 Palo Alto, CA 94304 Fairfax, VA 22030 Phone: (650) 475-5000 Phone: (703) 267-6050 Fax: (650) 475 5005 Fax: (703) 267-6810 http://www.VMware.com http://www.corsec.com © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 Revision History Version Modification Date Modified By Description of Changes 0.1 2007-01-19 Rumman Mahmud Initial draft. 0.2 2007-04-03 Rumman Mahmud Modified "Cryptographic Key Management" section. 0.3 2007-04-19 Rumman Mahmud Inserted Algorithm Certificate numbers 0.4 2007-09-04 Darryl Johnson Updated to address CMVP comments. VMware ACE Encryption Engine Page 2 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 Table of Contents 1 INTRODUCTION ...............................................................................................................................................4 1.1 PURPOSE .....................................................................................................................................................4 1.2 REFERENCES ...............................................................................................................................................4 1.3 DOCUMENT ORGANIZATION ........................................................................................................................4 2 ACE ENCRYPTION ENGINE ..........................................................................................................................5 2.1 OVERVIEW ..................................................................................................................................................5 2.2 MODULE INTERFACES .................................................................................................................................6 2.3 ROLES AND SERVICES .................................................................................................................................7 2.3.1 Crypto Officer Role........................................................................................................................7 2.3.2 User Role .......................................................................................................................................7 2.4 PHYSICAL SECURITY ...................................................................................................................................9 2.5 OPERATIONAL ENVIRONMENT ....................................................................................................................9 2.6 CRYPTOGRAPHIC KEY MANAGEMENT ........................................................................................................9 2.7 SELF-TESTS ...............................................................................................................................................11 2.8 DESIGN ASSURANCE .................................................................................................................................12 2.9 MITIGATION OF OTHER ATTACKS .............................................................................................................12 3 SECURE OPERATION....................................................................................................................................13 3.1 CRYPTO OFFICER GUIDANCE ....................................................................................................................13 3.1.1 Initial Setup..................................................................................................................................13 3.1.2 Management.................................................................................................................................13 3.1.3 Zeroization ...................................................................................................................................13 3.2 USER GUIDANCE .......................................................................................................................................13 4 ACRONYMS......................................................................................................................................................15 Table of Figures FIGURE 1 ­ DEPLOYING VMWARE .................................................................................................................................5 FIGURE 2 ­ LOGICAL BOUNDARY OF THE ACE ENCRYPTION ENGINE ............................................................................6 FIGURE 3 ­ STANDARD PC PHYSICAL BLOCK DIAGRAM ................................................................................................7 Table of Tables TABLE 1 ­ SECURITY LEVEL PER FIPS 140-2 SECTION ..................................................................................................6 TABLE 2 ­ MAPPING OF LOGICAL TO PHYSICAL INTERFACES .........................................................................................7 TABLE 3 ­ MAPPING OF CRYPTO OFFICER ROLE'S SERVICES TO INPUTS, OUTPUTS, CSPS, AND TYPE OF ACCESS ........7 TABLE 4 ­ MAPPING OF USER ROLE'S SERVICES TO INPUTS, OUTPUTS, CSPS, AND TYPE OF ACCESS ...........................7 TABLE 5 ­ LIST OF CRYPTOGRAPHIC KEYS, KEY COMPONENTS, AND CSPS PRESENT IN LIBEAY.DLL .........................10 TABLE 6 ­ LIST OF CRYPTOGRAPHIC KEYS, KEY COMPONENTS, AND CSPS PRESENT IN VMCRYPTOLIB.DLL .............11 TABLE 7 ­ ACRONYMS .................................................................................................................................................15 VMware ACE Encryption Engine Page 3 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 1 Introduction 1.1 Purpose This document is a non-proprietary Cryptographic Module Security Policy for the ACE Encryption Engine from VMware Inc. This Security Policy describes how the ACE Encryption Engine meets the security requirements of FIPS 140-2 (Federal Information Processing Standards Publication 140-2 ­ Security Requirements for Cryptographic Modules) and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 ­ Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) website at: http://csrc.nist.gov/cryptval/ The ACE Encryption Engine is referred to in this document as the cryptographic module or the module. 1.2 References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources: · The VMware website (www.VMware.com) contains information on the full line of products from VMware. · The CMVP website (http://csrc.nist.gov/cryptval/) contains contact information for answers to technical or sales-related questions for the module. 1.3 Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: · Vendor Evidence document · Finite State Machine · Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to VMware. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to VMware and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact VMware. VMware ACE Encryption Engine Page 4 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 2 ACE Encryption Engine 2.1 Overview VMware Inc. was founded in 1998 to bring virtual machine technology to industry-standard computers. VMware delivered its first product in 1999. Today, more than 4 million users and 20,000 corporate customers of all types and sizes use VMware software, including 99 of the Fortune 100 companies. The ACE Encryption Engine was created by VMware Inc. in 2004 to extend the capabilities of virtual infrastructure technology to the enterprise desktop. The ACE Encryption Engine allows virtual machines to be encapsulated into files which can be saved, copied, and provisioned into a virtual machine. The virtual machine allows for fully configured applications, operating systems, BIOS, and virtual hardware, which can be moved from one physical computer to another without needing downtime or maintainance. VMware's ACE 2.0 is a software solution that delivers enhanced management, security, and usability to standard desktop virtualization products. Using ACE 2.0, an organization can rapidly provision a standardized, secure general purpose computer (GPC) environment -- an ACE -- to any device in the extended enterprise, regardless of whether it is managed by the ACE administrator. An ACE is a policy-protected virtual machine containing an operating system, applications, and data. Through virtual rights management technology, ACE 2.0 enables desktop administrators to control ACE lifecycles, protect data, and ensure compliance with IT policies including software lifecycle management and access to data and applications. Unlike other products, ACE 2.0 is a hardware-independent solution that can be provisioned to any GPC and works either connected or disconnected from the enterprise network. ACE 2.0 is used across an organization to · Ensure secure, controlled access to enterprise resources from a standardized PC environment called an ACE · Provide a simplified end-user interface designed specifically for nontechnical Users · Provide policy-based controls including access, network, and device rights VMware's ACE allows security administrators to package an entire system with an operating system, applications, and policies, and deploy it to an unmanaged GPC. Once VMware ACE is installed, it offers complete control of the hardware configuration and networking capabilities of the GPC. The VMware ACE application itself is a virtual machine that runs on top of a physical hardware such as a GPC, and simulates the operation of the virtualized system it mimicks. Figure 1 ­ Deploying VMware The VMware ACE Encryption Engine is the kernel of the VMware ACE 2.0 application, and it runs on a GPC. The ACE Encryption Engine contains all the cryptographic software files that enable the VMware ACE application to VMware ACE Encryption Engine Page 5 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 perform its cryptographic functions such as hashing, encryption, digital signing, etc. The ACE Encryption Engine is composed of three dynamic-link library (DLL) files: vmcryptolib.dll, ssleay32.dll, and libeay32.dll. The ACE Encryption Engine's logical boundary is shown below in Figure 2. Operating System ACE Encryption Engine Signature File VMware ACE Vmcryptolib.dll application Ssleay32.dll Libeay32.dll Cryptographic Boundary Figure 2 ­ Logical Boundary of the ACE Encryption Engine The ACE Encryption Engine is validated at the following FIPS 140-2 Section levels: Table 1 ­ Security Level Per FIPS 140-2 Section Section Section Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and Interfaces 1 3 Roles, Services, and Authentication 1 4 Finite State Model 1 5 Physical Security N/A 6 Operational Environment 1 7 Cryptographic Key Management 1 8 EMI/EMC 1 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A 2.2 Module Interfaces The ACE Encryption Engine is a multi-chip stand-alone module that meets overall level 1 FIPS 140-2 requirements. The logical cryptographic boundary of the ACE Encryption Engine is defined by the blue broken line that surrounds the vmcryptolib.dll, libeay32.dll and ssleay32.dll files in Figure 2 Error! Reference source not found.. VMware ACE Encryption Engine Page 6 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 The module is evaluated for use on a GPC. In addition to the binaries, the physical device consists of the integrated circuits of the motherboard, the central processing unit (CPU), random access memory (RAM), read-only memory (ROM), computer case, keyboard, mouse, video interfaces, expansion cards, and other hardware components included in the computer such as hard disk, floppy disk, CD-ROM drive, power supply, and fans. The physical cryptographic boundary of the module is the hard opaque metal and plastic enclosure of the computer . The block diagram for a standard personal computer (PC) is shown below in Figure 3. Standard PC Monitor Block Diagram Crypto Boundary Integrated Memory Graphics Central System Clock driver/ Graphics Networking Processing Unit Audio (optional) Controller Generator (optional) (optional) (CPU) PCI Bus Floppy Drive Cache CD-ROM Drive PCI/ISA/IDE Hard Drive Accelerator (HDD) Universal Serial Bus (USB) IEEE 1394 ISA Bus ("Firewire"/ "iLink") Keyboard/ Infrared (IR) Power Supply BIOS Super I/O Mouse (optional) Mouse Port Controller UART/Data I/O (Serial/Parallel Keyboard Port Ports) Figure 3 ­ Standard PC Physical Block Diagram All of these physical interfaces are separated into logical interfaces defined by FIPS 140-2. Each of these locial interfaces are mapped to the corresponding physical interfaces in Table 2. Table 2 ­ Mapping of Logical to Physical Interfaces Physical Interface Mapping Logical Interface Module Mapping (Standard PC) Data Input Interface Keyboard, mouse, CD-ROM, floppy Arguments for a function that specify the data drive, and to be operated upon by that function. serial/USB/parallel/network ports Data Output Interface Floppy drive, monitor, and Arguments for a function that specify where the serial/USB/parallel/network ports result of the function is stored. Control Input Interface Keyboard, CD-ROM, floppy drive, Function calls utilized to initialize the module mouse, and and the function calls used to control the VMware ACE Encryption Engine Page 7 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 Physical Interface Mapping Logical Interface Module Mapping (Standard PC) serial/USB/parallel/network port operation of the module. Status Output Interface Floppy drive, monitor, and Return values for function calls serial/USB/parallel/network ports Power Interface Power Switch Not Applicable 2.3 Roles and Services There are two roles in the module (as required by FIPS 140-2) that operators may assume: a Crypto Officer (CO) role and a User role. The operator of the module assumes either of the roles based on the operations performed without any authentication. Both of the roles and their responsibilities are described below. 2.3.1 Crypto Officer Role The Crypto Officer role has the ability to install, uninstall and manage the the ACE Encryption Engine module. The Crypto Officer monitors the ACE Encryption Engine by tracking the event log of the PC's operating system. Descriptions of the services available to the Crypto Officer role are provided in the table below. Table 3 ­ Mapping of Crypto Officer Role's Services to Inputs, Outputs, CSPs, and Type of Access CSP and Type of Service Description Input Output Access Installation Installing the ACE Command Module installed None encryption engine module Uninstallation Uninstalling the ACE Command Module uninstalled None encryption engine module Management Monitoring, managing Command Status output None and troubleshooting the event log of the operating system 2.3.2 User Role The User role has the ability to utilize the API's available from the ACE Encryption Engine cryptographic services such as hashing, message authentication, encryption, pseudo-random number generation and disk sector encryption. Also, the module provides TLS services to Users. Descriptions of the services available to the User role are provided in the table below. Table 4 ­ Mapping of User Role's Services to Inputs, Outputs, CSPs, and Type of Access CSP and Type of Service Description Input Output Access Hashing Hashing operation API call with input Status output, data None parameters hashed Message Message API call with input Status output, HMAC key ­ Read authentication authentication services parameters message authentication code (MAC) created Cipher operation Cipher operation API call with input Status output, data Symmetric key ­ parameters encrypted or Read/Write decrypted VMware ACE Encryption Engine Page 8 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 CSP and Type of Service Description Input Output Access Digital Signing Digital sign and verify API call with input Status output, RSA key pair ­ Read operation parameters Signature Data conversion Convert entered data API call with input Status output, data None into another structure parameters reformatted Pseudo-random Generates random API call with input Status output, random Seed ­ Read Number Generation numbers parameters number generated TLS services Establish TLS channel API call with input TLS connection RSA key pair ­ parameters Read/Write Symmetric key ­ Read/Write Disk Sector Encryption of disk API call with input Status output, disk AES disk sector Encryption sector parameters sector encrypted encryption key ­ Read 2.4 Physical Security The ACE Encryption Engine is a multi-chip standalone module, which is purely a software module and thus physical security requirements do not apply. 2.5 Operational Environment The module was tested for FIPS 140-2 validation on Windows XP Professional with SP2 and Windows Vista Ultimate operating systems (OS). VMware affirms that the module is binarily compatible for the general purpose Windows 2000 OS and later editions. The OS must be configured for single user mode, per NIST CMVP guidance for FIPS 140-2 compliance. Single user mode configuration instructions for the OS can be found in the "Secure Operation" section of this document. 2.6 Cryptographic Key Management The ACE Encryption Engine implements the following FIPS-approved algorithms: In Libeay.dll: · PRNG Appendix A.2.4 of ANSI X9.31 using 2-key Triple-DES ­ (certificate #306) · AES encrypt/decrypt (ECB, CBC mode 128/256 bit) ­ (certificate #533) · DSA signature generation and verification (1024 bit) ­ (certificate #220) · HMAC SHA-1, HMAC SHA-224, HMAC SHA-256, HMAC SHA-384, HMAC SHA-512 (certificate #280) · RSA sign/verify (1024, 2048, and 4096 bits)­ (certificate #241) · SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (certificate #603) · TDES encrypt/decrypt (ECB, CBC mode KO 1,2,3) ­ (certificate #536) In VMCryptolib.dll: · PRNG ­ FIPS 186-2 General Purpose ­ (certificate #307) · AES encrypt/decrypt (ECB, CBC, CTR mode 128/256 bit) ­ (certificate #534) · HMAC SHA-1, HMAC SHA-256 (certificate #281) · SHA-1, SHA-256 (certificate #604) VMware ACE Encryption Engine Page 9 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 Additionally, the module utilizes the following non-FIPS approved algorithm implementation: In Libeay.dll: · Non-approved FIPS RNG used for seeding the FIPS approved deterministic RNG · RSA (encrypt/decrypt 1024, 2048, and 4096 bits) (key transport methodology provides between 80-bits and 150-bits of encryption strength) · DH (Key agreement 1024 bits) (key agreement methodology provides between 80-bits and 150-bits of encryption strength) · RSA (sign/verify 512 bits) · MD5 In VMCryptolib.dll: · Non-approved FIPS RNG used for seeding the FIPS approved deterministic RNG All secret keys and Critical Security Parameters (CSP) are protected against unauthorized disclosure, modification, and substitution. The module only allows access to CSPs through the module's well-defined commands in the API. The module supports the following cryptographic keys and critical security parameters: Table 5 ­ List of Cryptographic Keys, Key Components, and CSPs Present in Libeay.dll Key Key Type Generation/Input Output Storage Zeroization Use 1024, 2048, Generated internally Exits the Held in volatile Erased when Used for RSA and 4096 bit or enters the module module in memory in session is encryption (key public key public key in plaintext plaintext plaintext. closed or on transport) and reset signature verification 1024, 2048, Generated internally Exits the Held in volatile Erased when Used for RSA and 4096 bits or enters the module module in memory in session is decryption (key private key private key in plaintext plaintext plaintext. closed or on transport) and reset signing AES 128 and 256 Generated internally Exits the Held in volatile Erased when Used to perform Symmetric bits ECB, or enters the module module in memory in session is cipher operation key CBC key in plaintext or in plaintext plaintext. closed or on on data for TLS encrypted form reset channel TDES TDES ECB, Generated internally Exits the Held in volatile Erased when Used to perform Symmetric CBC 1, 2, or or enters the module module in memory in session is cipher operation key 3 key in encrypted form plaintext plaintext. closed or on on data for TLS reset channel HMAC key HMAC key Generated internally Exits the Held in volatile Erased when Used for or enters the module module in memory in session is message in plaintext plaintext plaintext. closed or on authentication reset and integrity for TLS channel PRNG 8 bytes of Generated internally Never exits the Held in volatile Erased when Used to seed seed value module memory only in session is generate plaintext closed or on pseudo-random reset number PRNG 16 bytes of Generated internally Never exits the Held in volatile Erased when Used to seed key key module memory only in session is generate plaintext closed or on pseudo-random reset number VMware ACE Encryption Engine Page 10 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 Key Key Type Generation/Input Output Storage Zeroization Use DSA 1024 bit Hardcoded in source Never exits the Stored in non- Erased when Used for power- public key public key code module volatile module is up software memory in uninstalled integrity test plaintext The module generates an HMAC keys internally or enters in plaintext during Transport Layer Security (TLS) handshaking; an Advanced Encryption Standard (AES) or Triple Data Encryption Standard (TDES) Symmetric key is generated internally using FIPS approved PRNG (ANSI X9.31 Appendix A.2.4) during TLS handshaking. Both the ephemeral keys are zeroized when the session is closed or the module is reset/reloaded. The Pseudorandom Number Generator (PRNG) seed and seed key are generated internally and are zeroized when the session is closed or the module is reset or reloaded. The Rivest Shamir and Adleman (RSA) public/private key is generated when the caller provides the certificate containing the key and is zeroized when the TLS context is destroyed. The DSA public key is hardcoded in the source code and is zeroized when the module is uninstalled. Table 6 ­ List of Cryptographic Keys, Key Components, and CSPs Present in VMCryptolib.dll Key Key Type Generation/Input Output Storage Zeroization Use AES Disk 128/256 bits Generated internally Exits the Held in non- Erased when Used to perform Sector ECB, CBC, or enters the module module in volatile session is cipher operation Encryption CTR key in plaintext plaintext memory in closed or on on data key plaintext. reset HMAC key HMAC key Generated internally Exits the Held in volatile Erased when Used for or enters the module module in memory in session is message in plaintext plaintext plaintext. closed or on authentication reset and integrity validation PRNG 20 bytes of Generated internally Never exits the Held in volatile Erased when Used to seed seed value module memory only in session is generate plaintext closed or on pseudo-random reset number HMAC keys enter into the module in plaintext. These keys are used for message authentication and integrity checking. VMCryptolib.dll generates an AES Symmetric key internally using FIPS 186-2 Appendix 3.1 PRNG in order to encrypt information stored on the workstation. The AES Disk Sector Encryption key resides only in volatile memory and is zeroized after session is over or on reset. The Pseudorandom Number Generator (PRNG) seed is generated internally and is zeroized when the session is closed or the module is reset or reloaded. 2.7 Self-Tests The ACE Encryption Engine performs the following self-tests at power-up: For VMCryptolib.dll: · Software integrity check (using DSA) · Known Answer Tests (KATs) o AES KAT (ECB, CBC, CTR modes 128/256 bit) o HMAC SHA-1 KAT o HMAC SHA-256 KAT o PRNG KAT (FIPS 186-2) For Libeay.dll: · Software integrity check (using DSA) VMware ACE Encryption Engine Page 11 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 · Know Answer Tests (KATs) o AES KAT (ECB, CBC, modes 128/256 bit) o HMAC SHA-1, HMAC SHA-224, HMAC SHA-256, HMAC SHA-384, and HMAC SHA-512 KATs o PRNG KAT ­ Appendix A.2.4 of ANSI X9.31 o RSA KAT (encrypt/decrypt and sign/verify) o SHA-1 KAT o TDES KAT (ECB mode) The ACE Encryption Engine performs the following conditional self-tests: For VMCryptolib.dll: · CRNGT for FIPS 186-2 Appendix 3.1 PRNG · CRNGT for entropy gathering for FIPS 186-2 Appendix 3.1 PRNG For Libeay.dll: · CRNGT for ANSI X9.31 Appedix A.2.4 PRNG · CRNGT for entropy gathering for ANSI X9.31 Appendix A.2.4 PRNG · RSA pairwise Consistency Test The Status Output from the self-tests is stored in RAM1 (unless the Crypto Officer configures the module to record the Status Output into a local file), and it can be accessed whenever the CO needs to troubleshoot a startup failure. 2.8 Design Assurance Microsoft Visual SourceSafe (VSS) version 6.0 is used to provide configuration management for the ACE Encryption Engine's FIPS documentation. This software provides access control, versioning, and logging. VSS also maintains an internal revision history of each of the module's files and uniquely labels these revisions. The VMware source code is maintained in Perforce, which maintains an internal revision history of the module's source files. The Perforce server manages the master file repository that contains every revision of every file under Perforce control. The server maintains a database to track change logs, user permissions, and which users have which files checked out at any time. 2.9 Mitigation of Other Attacks This section is not applicable. The module does not claim to mitigate any attacks beyond the FIPS 140-2 level 1 requirements for this validation. 1 RAM ­ random access memory VMware ACE Encryption Engine Page 12 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 3 Secure Operation The ACE Encryption Engine meets Level 1 requirements for FIPS 140-2. The section below describes how to place and keep the module in FIPS-approved mode of operation. 3.1 Crypto Officer Guidance 3.1.1 Initial Setup The Crypto Officer is responsible for installing/uninstalling, configuring, and managing the module. The ACE Encryption Engine is available on a Compact Disc (CD) to the Crypto Officer using a standard carrier (i.e. FedEx or UPS). The Crypto Officer is responsible for inspecting the CD and its packaging upon receipt for signs of tampering. If evidence of tampering is found, the Crypto Officer should contact the vendor immediately and should not use the module. The software module will be provided to the Crypto Officer by VMware Inc. and its marketing affiliates. The module becomes installed during the process of installing the host application, VMware ACE. With the delivered software, the Crypto Officer also receives detailed documentation on installing, uninstalling and configuring VMware ACE. Before installing the module, the CO must configure the PC for single user mode as instructed below: To configure the Windows platforms for single user mode, the CO must ensure that all remote guest accounts are disabled in order to ensure that only one operator can log into the OS at a time. Guest accounts can be disabled via the Users and Passwords selection on the Control Panel window. Services that should be disabled are: · Server services · Terminal services · Remote registry service · Remote desktop and remote assistance service For specific information regarding the Microsoft operating system security and administration procedures, please refer to Microsoft's online technical and product information repository at http://technet.microsoft.com/en- us/default.aspx. 3.1.2 Management The Crypto Officer should monitor the module's status by regularly checking the Windows Event log. If any irregular activity is noticed or the module is consistently reporting errors, then VMware's customer support should be contacted. The CO is also responsible to monitor that FIPS mode of operation is maintained by using only FIPS approved functions. The module should not be used for any FIPS non-approved functions, such as MD5 or DH. 3.1.3 Zeroization The RSA key pair is erased when the TLS session is terminated. The AES key, TDES key, HMAC keys, and PRNG seed are erased when the session is closed or when the module is reset. The DSA public key is erased when the module is uninstalled. 3.2 User Guidance The User accesses the module's cryptographic functionalities only. Although the User does not have any ability to modify the configuration of the module, they should check that the host application is enabled and providing cryptographic protection. The module offers `Data conversion' service to the Users via the following APIs: VMware ACE Encryption Engine Page 13 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 CryptoPass2key_FromString CryptoPass2key_ToString CryptoPass2key_Compute CryptoPass2key_Makekey Crypto_PasswordWrapData Crypto_PasswordUnwrapData Crypto_GetPassword Crypto_ManglePassphrase Crypto_EncryptPassword Crypto_DecryptPassword Crypto_ClearEncryptedPassword Crypto_InitializeEncryptedPassword The keys derived from the APIs mentioned above are not to be used for data encryption/decryption. Otherwise, the resultant values will be considered as plaintext in FIPS mode of operation. VMware ACE Encryption Engine Page 14 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 0.4 September 4, 2007 4 Acronyms Table 7 ­ Acronyms Acronym Definition AES Advanced Encryption Standard CD Compact Disc CD-ROM Compact Disc Read-Only Memory CMVP Cryptographic Module Validation Program CO Crypto Officer CSP Critical Security Parameter DLL Dynamic-Link Library DSA Digital Signature Algorithm EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard HMAC (Keyed-) Hash Message Authentication Code KAT Known Answer Test NIST National Institute of Standards and Technology OS Operating System PC Personal Computer PRNG Pseudorandom Number Generator RAM Random Access Memory RNG Random Number Generator ROM Read Only Memory RSA Rivest Shamir and Adleman SHA Secure Hash Algorithm TLS Transport Layer Security USB Universal Serial Bus VSS Visual SourceSafe VMware ACE Encryption Engine Page 15 of 15 © 2007 VMware Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice.