SafeNet ProtectDrive Cryptographic Engine FIPS 140-2 Level 1 Non-Proprietary Security Policy DOCUMENT NUMBER: 002-010820-001 AUTHOR: Chris Brych DEPARTMENT: Enterprise Engineering LOCATION OF ISSUE: Ottawa and Belcamp DATE ORIGINATED: May 24, 2012 REVISION LEVEL: E REVISION DATE: September 5, 2013 SUPERSESSION DATA: D SECURITY LEVEL: Non-Proprietary © Copyright 2013 SafeNet, Inc. All rights reserved. www.safenet-inc.com 002-010784-001 Revision E This document may be freely reproduced and distributed whole and intact including this copyright notice. SafeNet, Inc. reserves the right to make changes in the product or its specifications mentioned in this publication without notice. Accordingly, the reader is cautioned to verify that information in this publication is current before placing orders. The information furnished by SafeNet, Inc. in this document is believed to be accurate and reliable. However, no responsibility is assumed by SafeNet, Inc. for its use, or for any infringements of patents or other rights of third parties resulting from its use. No part of this publication may be copied or reproduced in any form or by any means, or transferred to any third party without prior written consent of SafeNet, Inc. 002-010820-001 Revision E SPCE Security Policy TABLE OF CONTENTS Section Title Page 1.  INTRODUCTION ..................................................................................................................................... 1  1.1  Purpose ............................................................................................................................................ 1  1.2  References ....................................................................................................................................... 1  1.3  Terminology...................................................................................................................................... 1  2.  THE APPLICATION ................................................................................................................................ 2  2.1  Functional Overview ......................................................................................................................... 2  2.2  Cryptographic Engines ..................................................................................................................... 2  3.  CRYPTOGRAPHIC MODULE SPECIFICATION ................................................................................... 4  3.1  FIPS 140-2 Security Levels .............................................................................................................. 4  4.  CRYPTOGRAPHIC MODULE PORTS AND INTERFACES .................................................................. 5  4.1  Interfaces .......................................................................................................................................... 5  5.  ROLES, SERVICES AND AUTHENTICATION ...................................................................................... 5  5.1  Identification and Authentication ...................................................................................................... 5  5.2  Strength of Authentication ................................................................................................................ 6  5.3  Roles ................................................................................................................................................ 6  5.3.1  Administrator / Cryptographic Officer ........................................................................................... 6  5.3.2  User .............................................................................................................................................. 6  5.4  Services for Authorized Roles and Access Control ......................................................................... 6  6.  PHYSICAL ENVIRONMENT ................................................................................................................... 7  7.  OPERATIONAL ENVIRONMENT ........................................................................................................... 7  8.  CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................................. 7  8.1  Key Generation ................................................................................................................................ 7  8.2  Key Input / Output ............................................................................................................................ 7  8.3  Key Zeroization ................................................................................................................................ 7  8.4  Algorithms ........................................................................................................................................ 7  8.5  Security Functions, Cryptographic Keys and CSPs ....................................................................... 10  9.  SELF-TESTS ......................................................................................................................................... 11  9.1  Power-On Self-Tests (POST) ......................................................................................................... 11  9.2  Conditional Self-Tests .................................................................................................................... 11  9.3  Mitigation of Other Attacks ............................................................................................................. 12  10.  FIPS APPROVED MODE OF OPERATION ..................................................................................... 12  10.1  Description .................................................................................................................................. 12  Document is Uncontrolled When Printed. Page i of ii 002-010820-001 Revision E SPCE Security Policy 10.2  Invoking Approved Mode of Operation ....................................................................................... 12  10.3  Mode of Operation Indicator ....................................................................................................... 13  10.4  Non-FIPS mode of Operation ..................................................................................................... 13  11.  GLOSSARY OF ACRONYMS, TERMS AND ABBREVIATIONS .................................................... 14  LIST OF TABLES Table Title Page Table 1 – FIPS 140-2 Security Levels ...........................................................................................................4  Table 2 – FIPS 140-2 Logical Interfaces .......................................................................................................5  Table 3 – Roles and Required Identification and Authentication...................................................................5  Table 4 – Strength of Authentication Mechanism ..........................................................................................6  Table 5 – SPCE Services and Authorized Roles...........................................................................................7  Table 6 - VxBIOS FIPS Approved or Allowed Algorithms .............................................................................7  Table 7 - NetBSD INIT FIPS Approved or Allowed Algorithms .....................................................................8  Table 8 - CRYPdll FIPS Approved or Allowed Algorithms ............................................................................8  Table 9 - CGX FIPS Approved or Allowed Algorithms ..................................................................................9  Table 10 – CryptoAPI_NT.dll FIPS Approved or Allowed Algorithms ...........................................................9  Table 11 – Approved Security Functions, Cryptographic Keys and CSPs ..................................................10  Table 12 – Power-On Self-Tests .................................................................................................................11  Table 13 – Conditional Self-Tests ...............................................................................................................11  LIST OF FIGURES Figure 1 – Boot Environments and Cryptographic Engines ..........................................................................2 Document is Uncontrolled When Printed. Page ii of ii 002-010820-001 Revision E SPCE Security Policy 1. INTRODUCTION 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the SafeNet ProtectDrive Cryptographic Engine 1.0.1 as implemented in the SafeNet ProtectDrive application version 9.4.2. This security policy describes how the module meets the security requirements of FIPS 140-2 and how to operate the Application in a secure FIPS 140-2 mode. This policy was prepared as a part of the Level 2 FIPS 140-2 validation of the Application. 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 NIST website at http://csrc.nist.gov/cryptval. 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 Application and other SafeNet products from the following sources:  The SafeNet Internet site contains information on the full line of security products at http://www.safenet-inc.com/products.  For answers to technical or sales-related questions please refer to the contacts listed on the SafeNet Internet site at http://www.safenet-inc.com/company/contact.asp. SafeNet Contact Information: 4690 Millennium Drive SafeNet, Inc. (Corporate Headquarters) Belcamp, MD 21017 Telephone: 410-931-7500 TTY Users: 800-735-2258 Fax: 410-931-7524 SafeNet Sales: (800) 533-3958 U.S. (410) 931-7500 International SafeNet Technical Support: (800) 545-6608 U.S. (410) 931-7520 International SafeNet Customer Service: (866) 251-4269 U.S. +44 (0) 1276 60 80 00 EMEA 852 3157 7111 APAC 1.3 Terminology In this document, reference will be made to the “module” or “SPCE” when discussing SafeNet ProtectDrive Cryptographic Engine. Document is Uncontrolled When Printed. Page 1 of 13 002-010820-001 Revision E SPCE Security Policy 2. THE APPLICATION 2.1 Functional Overview ProtectDrive is a full-disk encryption software product that secures entire hard drives in laptops, workstations, servers and removable media. - Strong security ProtectDrive encrypts and decrypts data “on the fly” using FIPS Approved strong encryption algorithms. Security is further enhanced with password based pre-boot authentication or for more security sensitive organizations, by using multi-factor authentication products such as tokens and smart cards as part of the pre-boot authentication process.1 - Removable media protection ProtectDrive protects a wide range of removable media, including USB memory sticks and portable hard drives. Once a medium is protected, only authorized users within an organization can access the sensitive data stored on it. - Port management and control ProtectDrive lets administrators define port management and control policies for optical media plus serial connections. - Local management ProtectDrive permits local administration of policies and keys. ProtectDrive security features include: Unauthorized sign-on protection activation after a configurable number of failed pre-boot sign- - on attempts; Controlled access to device classes such as storage devices, printers, modems, digital - cameras and scanners etc. ProtectDrive may be deployed to multiple clients using a Windows Installer (MSI) package over a network or individual clients by personal installation. 2.2 Cryptographic Engines The SafeNet ProtectDrive Cryptographic Engine (SPCE) is comprised of the following components in a FIPS 140-2 Level 1 configuration: VxBIOS - NetBSD INIT - CRYPdll - SafeCGX.sys system driver for 32-bit Windows environments - Windows CNG.sys driver (FIPS Certificate #1328) - CryptoAPI_NT.dll - 1 Note: Cryptographic tokens and smart cards were not tested as part of the pre-boot authentication process. Document is Uncontrolled When Printed. Page 2 of 13 002-010820-001 Revision E SPCE Security Policy ProtectDrive Cryptographic Engine Hardware Pre-Boot Authentication Layer VXBIOS NetBSD INIT CRYPdll (Kernel Mode) SafeCGX.sys CNG.sys 32-bit Environments 64-bit Environments (User Mode) CryptoAPI_NT.dll Local Management Console Application Cryptographic Boundary Data Input Data Output Control Input Status Output Figure 1. – Boot Environments and Cryptographic Engines The NetBSD INIT components handle operator authentication at system startup. CRYPdll.sys Document is Uncontrolled When Printed. Page 3 of 13 002-010820-001 Revision E SPCE Security Policy handles initial decryption of the operating system kernel once successful authentication of an operator has taken place. Transfer of decryption operations then occurs when SafeCGX or CNG are decrypted and initialized. Either SafeCGX or Windows CNG takes over and decrypts the remainder of the kernel, operating system, and hard disk depending on whether the operating system is a 32 bit or 64 bit OS. The role of CryptoAPI_NT.dll is only to generate keys in 32-bit environments. When the module is installed on a 64 bit environment, CNG performs the key generation function. When running on a 64-bit Windows 7 platform, SPCE only operates in FIPS mode when: - Windows is booted normally, with Debug mode disabled and Driver Signing enforcement is enabled (for WINLOAD.EXE as per certificate #1326 and BootMgr as per certificate #1319) - one of the following DWORD registration values is set to 1 (for CNG.SYS as per FIPS certificate #1328) HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled o HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\Cryptography\Configuration\SelfTest o Algorithms 3. CRYPTOGRAPHIC MODULE SPECIFICATION From the point of view of FIPS 140-2, the SafeNet ProtectDrive Cryptographic Engine (SPCE) 1.0.1 is a multi-chip standalone cryptographic module whose cryptographic boundary is composed of a logical and a physical boundary. The logical boundary comprises the cryptographic implementation files and the physical boundary includes the hardware platform the module resides on. This document refers specifically to the SafeNet ProtectDrive Cryptographic Engine version 1.0.1. 3.1 FIPS 140-2 Security Levels The module meets overall Level 1 requirements for FIPS 140-2 as summarized in Table No components are excluded from the requirements of FIPS 140-2. Section Section Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and Interfaces 1 3 Roles, Services, and Authentication 3 4 Finite State Machine 1 5 Physical Security N/A 6 Operational Environment 1 7 Cryptographic Key Management 1 8 EMI / EMC 3 9 Self Tests 1 10 Design Assurance 3 11 Mitigation of Other Attacks N/A Table Error! Bookmark not defined. – FIPS 140-2 Security Levels Document is Uncontrolled When Printed. Page 4 of 13 002-010820-001 Revision E SPCE Security Policy 4. CRYPTOGRAPHIC MODULE PORTS AND INTERFACES The cryptographic module provides several interfaces for data input, data output, status output, and command input. 4.1 Interfaces All requests for services are sent to the ProtectDrive Cryptographic Engine via an API. The module’s physical interfaces are separated into the logical interfaces, defined by FIPS 140-2, and described below: FIPS 140-2 Interface Logical Interface Physical Interface Data Input Interface Data input parameters of API keyboard port, mouse port, function calls USB port, serial port Data Output Interface Data output parameters of VGA port, USB port, serial API function calls port Control Input Interface Control input parameters of keyboard port, mouse port API function calls that command the module Status Output Interface Status output parameters of VGA port API function calls that show the status of the module Power Interface Power connector Table 2. – FIPS 140-2 Logical Interfaces 5. ROLES, SERVICES AND AUTHENTICATION 5.1 Identification and Authentication SPCE supports identity-based authentication of one operator at a time. Operators are identified by a username and password The different roles and required authentication are shown in Table 3.3: Role Type of Authentication Authentication Data User Identity-based Username, Password, and Domain Name Cryptographic Officer Identity-based Username, Password, and Domain Name Table 3. – Roles and Required Identification and Authentication The module supports two distinct operator roles: User and Cryptographic Officer/Administrator. The OS enforces the separation of roles using identity-based operator authentication. To log in, an operator must enter a username, domain name and password. The username is an alphanumeric string of one or more characters. The password is a string of one or more characters (eight or more are recommended) chosen by the operator from the 95 printable and human- readable characters. Upon successful authentication, the role is assumed based on the identity of the operator as a Windows Domain credential. Document is Uncontrolled When Printed. Page 5 of 13 002-010820-001 Revision E SPCE Security Policy 5.2 Strength of Authentication Authentication Mechanism Strength of Mechanism Operator password The characters used in the password must be from the 95 printable and human-readable ASCII characters. - With an 8 character password, this yields a minimum of 958 (or 6,634,204,312,890,625) possible combinations; thus the possibility of correctly guessing a password is greater than 1 in 1,000,000. - By default, the module locks the login interface for 3 minutes after 3 consecutive failed login attempts, giving a possibility well under less than 1 to 100,000 to guess the password within 1 minute. Table 4. – Strength of Authentication Mechanism 5.3 Roles 5.3.1 Administrator / Cryptographic Officer This role is associated with Administrators / Cryptographic Officers (COs) who can administer the module and ProtectDrive locally using the Local Management Console (LMC). This role provides all services that are necessary for the secure management of the module. 5.3.2 User This role is associated with the User who logs into a system protected by ProtectDrive, with minimal access to module services as set by a Crypto-Officer. This role can access the LMC to view its settings, but cannot make changes. 5.4 Services for Authorized Roles and Access Control Table 5.4.1 shows the services that use or affect cryptographic keys or CSPs. For each service, the key or CSP is indicated along with the type of access. R - The item is read or referenced by the service. W - The item is written or updated by the service. X - The item is executed by the service. (The item is used as part of a cryptographic function.) Crypto-Officer: CO User: U Services Role Key/CSP Access Control Pre-Boot Authenticate CO, U Authentication Data W, X Self-Test CO, U None X Decrypt CO, U X UK, DK, VK Document is Uncontrolled When Printed. Page 6 of 13 002-010820-001 Revision E SPCE Security Policy Services Role Key/CSP Access Control Post-Boot Self-Test CO, U None X Generate Key CO DK, VK X Show Status CO, U None R Change Password CO, U Authentication Data W, X Change LMC R, W, X CO Authentication Data Settings Encrypt CO, U DK, VK X Zeroize CO, U All Keys and CSP’s W, X Set FIPS Mode CO None W, X Table 5. – SPCE Services and Authorized Roles None of the above services can be accessed until an operator successfully authenticates into one of the specified roles. 6. PHYSICAL ENVIRONMENT The SafeNet ProtectDrive Cryptographic Engine is implemented as a software component and thus the FIPS 140-2 physical security requirements are not applicable. 7. OPERATIONAL ENVIRONMENT For the purpose of FIPS 140-2 Level 1 validation, the SafeNet ProtectDrive Cryptographic Engine is classified as a multi-chip standalone module as defined by FIPS PUB 140-2. The module has been tested on a Dell E6400 running Windows XP SP3 , Dell E6400 running Windows 7 Ultimate Edition SP1 (X86 version) and Dell E6400 running Windows 7 Ultimate Edition SP1 (X64 version). 8. CRYPTOGRAPHIC KEY MANAGEMENT 8.1 Key Generation The module supports the generation of AES 128-bit, 192-bit and 256-bit keys. The module employs a ANSI X9.31 Appendix 2.4 specified PRNG for generating keys used in FIPS Approved mode of operation. 8.2 Key Input / Output Keys are not input or output from the cryptographic boundary. 8.3 Key Zeroization Keys are zeroized by uninstalling the ProtectDrive application and performing a low level format of the hard disk drive. 8.4 Algorithms Tables 6 to 10 list the module approved algorithms. In the FIPS mode of operation only these Approved algorithms are available. Document is Uncontrolled When Printed. Page 7 of 13 002-010820-001 Revision E SPCE Security Policy The module implements the following FIPS Approved or Allowed algorithms for VxBIOS: Approved or Allowed Security Functions Certificate Secure Hash Standard (SHS) SHA-256 (Byte Only) 1754 Data Authentication Code HMAC-SHA-256 (KeySizes KS = BS) 1210 Password Based Key Derivation Function (PBKDF2) NIST SP 800-132 Section 5.4(2.a) (Vendor Affirmed2) Table 6. - VxBIOS FIPS Approved or Allowed Algorithms   The module implements the following FIPS Approved or Allowed algorithms for NetBSD INIT: Approved or Allowed Security Functions Certificate Symmetric Encryption/Decryption AES: (CBC, Mode; Encrypt/Decrypt; Key Size = 256) 1999 Secure Hash Standard (SHS) SHA-1 (Byte Only) 1752 Table 7. - NetBSD INIT FIPS Approved or Allowed Algorithms The module implements the following FIPS Approved or Allowed algorithms for CRYPdll: Approved or Allowed Security Functions Certificate Symmetric Encryption/Decryption AES: (CBC Modes; Encrypt/Decrypt; Key Size = 128; 192; 256) 1998 Table 8. - CRYPdll FIPS Approved or Allowed Algorithms The module implements the following FIPS Approved or Allowed algorithms for SafeCGX: Approved or Allowed Security Functions Certificate Symmetric Encryption/Decryption AES: (CBC Mode; Encrypt/Decrypt; Key Size = 128, 192, 256) 2000 Secure Hash Standard (SHS) SHA-1 (Byte Only) 1753 Data Authentication Code HMAC-SHA-1 (KS < BS) 1209 Non Approved Security Functions 2 Passwords sent to the PBKDF2 function shall be at minimum 8 characters. The probability of guessing the password at random is shown in Table 4. Document is Uncontrolled When Printed. Page 8 of 13 002-010820-001 Revision E SPCE Security Policy Approved or Allowed Security Functions Certificate RSA (Non-Compliant) Table 9. - CGX FIPS Approved or Allowed Algorithms The module implements the following FIPS Approved or Allowed algorithms for CryptoAPI_NT.dll: Approved or Allowed Security Functions Certificate Secure Hash Standard SHA-256 1751 Data Authentication Code HMAC-SHA-256 (Key Size KS = BS) 1208 Random Number Generation ANSI X9.31 Appendix A, para 2.4 [ AES-256 ] 1048 Non-Approved Security Functions DES Triple-DES (2-Key) IDEA Table 10. – CryptoAPI_NT.dll FIPS Approved or Allowed Algorithms Document is Uncontrolled When Printed. Page 9 of 13 002-010820-001 Revision E SPCE Security Policy 8.5 Security Functions, Cryptographic Keys and CSPs Table 11 lists the security functions by indicating each CSP, the type of key it is, and how it is used. CSP CSP Type Generation Input/Output Storage Destruction Use Mechanism Volume Key (VK) AES key ANSI X9.31 RNG Not Input/Output Plaintext in Embedded Format HDD Encryption/Decryption of 128/192/256-bit File System Data Volume Authentication Data String Derived Not Input/Output Plaintext in Volatile Format HDD Authentication Data Memory for duration of login and Plaintext in Non-Volatile Memory in Embedded File System User Key (UK) AES key 256-bit NIST SP 800-132 Not Input/Output Volatile Memory Power Cycling Wrap Disk Key stored in (PBKDF2)3 Embedded File System Disk Key (DK) AES key 256-bit ANSI X9.31 RNG Not Input/Output Encrypted by User Key Format HDD Encryption/Decryption (UK) in Embedded File operations on system System partitions. Seed Seed Input Generated from Not Input/Output Volatile Memory Power Cycling Input into generating entropy source random numbers RNG Seed Key AES key 256-bit Generated from Not Input/Output Volatile Memory Power Cycling Used in generating entropy source random numbers Table 11. – Approved Security Functions, Cryptographic Keys and CSPs 3 Keys derived from passwords, as shown in SP 800-132, shall only be used in storage applications. Document is Uncontrolled When Printed. Page 10 of 13 002-010820-001 Revision E SPCE Security Policy 9. SELF-TESTS The ProtectDrive Cryptographic Engine performs a number of power-up and conditional self-test to ensure proper operation. 9.1 Power-On Self-Tests (POST) When the SafeNet ProtectDrive Cryptographic Engine is initially powered-on, it executes a number of power-on self-tests. If any of these tests fail, the module will enter an error state and prohibit an operator from exercising the module’s cryptographic functionality. No data is output by the module while these tests are running. Table 12 lists the power-on self-tests: Test Function FIPS 140-2 Required Symmetric Cipher AES KAT Performs encrypt/decrypt known answer Yes tests for AES for NetBSD INIT, CRYPdll and SafeCGX4 SHA-1 KAT Performs known answer test for SHA-1 on Yes NetBSD INIT RNG KAT Performs known answer test for the RNG in Yes CryptoAPI_NT.dll HMAC-SHA-1 KAT Peforms separate known answer test for Yes HMAC-SHA-1 on SafeCGX. HMAC-SHA-256 KAT Performs known answer tests for HMAC- Yes SHA-256 on VxBIOS and CryptoAPI_NT.dll Software Integrity Test HMAC-SHA-256 for VxBIOS, NetBSD INIT, Yes and CRYPdll HMAC-SHA-256 for CryptoAPI_NT.dll HMAC-SHA-1 for SafeCGX5 Table 12. – Power-On Self-Tests 9.2 Conditional Self-Tests Test Function FIPS 140-2 Required Continuous RNG Performs the FIPS 140-2 required continuous Yes RNG check each time the module’s PRNG is used to produce random data Continuous Entropy Test Performs a continuous entropy test on the Yes seeding material for the RNG. The test checks that the previous seeding material is not the same as the current seed material Table 13. – Conditional Self-Tests 4 AES KATs are performed separately by CRYPdll, NetBSD INIT, and SafeCGX for their respective AES implementations 5 SafeCGX performs its own software integrity test separately from SPCE components Document is Uncontrolled When Printed. Page 11 of 13 002-010820-001 Revision E SPCE Security Policy 9.3 Mitigation of Other Attacks The FIPS 140-2 Mitigation of Other Attacks requirements are not applicable because the module is not designed to mitigate any specific attacks. 10. FIPS APPROVED MODE OF OPERATION 10.1 Description The module can be configured to operate in a FIPS Approved mode of operation by setting the Encryption Mode to Enable FIPS. Enabling FIPS Mode will disable all Non-FIPS Approved symmetric algorithms. 10.2 Invoking Approved Mode of Operation The FIPS Approved Mode of Operation can be invoked by performing the following steps: For 32-bit OS (Windows XP SP3 or Windows 7 32 bit): 1. The Crypto-Officer (Windows Administrator) must first authenticate to the workstation. The Crypto-Officer must then install the SafeNet ProtectDrive Application and set a Crypto-Officer password for ProtectDrive by changing the local System Administrator Windows account’s password. 2. The workstation must then be restarted 3. The Crypto-Officer must then reauthenticate 4. The Crypto-Officer will launch the Local Management Console and select the PD Users tab to create a User account 5. The Crypto-Officer will next select the Advanced Tab\Encryption Directory\Encryption Mode 6. In the “Encryption Mode”, the Crypto-Officer will then select “Enable FIPS” check box 7. The Crypto-Officer must next select the “Fixed Disk” directory and select an AES key size. 8. The Crypto-Officer must then Select the Status Tab and Encrypt the Disk. 9. Upon completion of encrypting the disk, the system must be restarted 10. After the User or Administrator successfully authenticates, they can go to the Advanced Tab\Encryption Directory\Encryption Mode to see that “FIPS Mode is enabled”. For 64-bit OS’s (Windows 7 SP1): 1. The Crypto-Officer (Windows Administrator) must first authenticate to the workstation. The DWORD registry value must be set to 1 in either: a. HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled; or b. HKLM\SYSTEM\CurrentControlSet\Policies\Microsoft\Cryptography\Configuration\SelfTest Algorithms (Requirement of Validation Certificate #1328) 2. Verify Windows debug mode is disabled and driver signing enforcement is enabled (Requirement of Certificate #1319 and #1326) Document is Uncontrolled When Printed. Page 12 of 13 002-010820-001 Revision E SPCE Security Policy 3. The Crypto-Officer must then install the SafeNet ProtectDrive Application and set a Crypto-Officer password for ProtectDrive by changing the local System Administrator Windows account’s password. 4. The workstation must then be restarted 5. The Crypto-Officer must then reauthenticate 6. The Crypto-Officer will launch the Local Management Console and select the PD Users tab to create a User account 7. The Crypto-Officer will next select the Advanced Tab\Encryption Directory\Encryption Mode 8. In the “Encryption Mode”, the Crypto-Officer will then select “Enable FIPS” check box 9. The Crypto-Officer must next select the “Fixed Disk” directory and select an AES key size. 10. The Crypto-Officer must then select the Status Tab and Encrypt the Disk. 11. Upon completion of encrypting the disk, the system must be restarted 12. After the User or Administrator successfully authenticates, they can go to the Advanced Tab\Encryption Directory\Encryption Mode to see that “FIPS Mode is enabled”. 10.3 Mode of Operation Indicator The module is in FIPS mode when the ‘Enable FIPS’ Encryption Mode setting in the LMC under the Encryption section of the Advanced Settings tab is set. 10.4 Non-FIPS mode of Operation In non-FIPS mode, the module also provides the following non-FIPS Approved algorithms:  DES  2-key Triple-DES  IDEA  RSA Document is Uncontrolled When Printed. Page 13 of 13 002-010820-001 Revision E SPCE Security Policy 11. GLOSSARY OF ACRONYMS, TERMS AND ABBREVIATIONS Term Definition AES Advanced Encryption Standard CO Cryptographic Officer CRC Cyclic Redundancy Check EFS Embedded File System DK Disk Key IDEA International Data Encryption Algorithm LMC Local Management Console PBKDF2 Password Based Key Derivation Function POST Power On Self Test RNG Random Number Generator Triple DES (EDE) Data Encryption Standard (Encrypt Decrypt Encrypt) UK User Key VK Volume Key Document is Uncontrolled When Printed. A1 – A1