FIPS 140-2 Non-Proprietary Security Policy for Absolute Encryption Engine Level 1 Validation (Software Version: 1.2.0.46) Document Version 1.1 Date: December 15, 2011 www.absolute.com © 2011 Absolute Software Corporation This document is prepared for Absolute Software Corp. by Uptown Telecom Consulting Services, Ltd. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.1 December 15, 2011 Revision History Version Modification Date Modified By Description of Changes 0.0 February 24, 2010 Yvonne Chow First draft based on a common DLL for both client and server and Product Development (PD) inputs. 0.1 February 25, 2010 Yvonne Chow Updated draft based on review comments from PD. 0.2 February 26, 2010 Yvonne Chow Updated based on review comments from PD and CTO. 0.3 September 29, 2010 Yvonne Chow Updated as per July 8 and August 23, 2010 comments from EWA-Canada and revised implementation 0.4 December 3, 2010 Yvonne Chow Updated as per November 26, 2010 comments from EWA-Canada 1.0 July 13, 2011 Yvonne Chow Updated as per February 9, 2011 and June 10, 2011 and July 12, 2011 comments from EWA-Canada 1.1 December 15, 2011 Dale Quantz Updated as per comments from EWA-Canada November 2, 2011 Absolute Encryption Engine Page 2 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 Table of Contents 1 INTRODUCTION ...............................................................................................................................................5 1.1 PURPOSE ......................................................................................................................................................5 1.2 REFERENCES ................................................................................................................................................5 1.3 DOCUMENT ORGANIZATION .........................................................................................................................5 2 ABSOLUTE COMPUTRACE............................................................................................................................6 2.1 PRODUCT OVERVIEW ...................................................................................................................................6 2.1.1 Product Platforms ...........................................................................................................................7 2.2 APPLICABLE FIPS 140-2 SECTIONS ..............................................................................................................8 3 ABSOLUTE ENCRYPTION ENGINE .............................................................................................................9 3.1 CRYPTOGRAPHIC MODULE DEFINITION .......................................................................................................9 3.1.1 Physical Cryptographic Boundary ................................................................................................ 10 3.1.2 Logical Cryptographic Boundary ................................................................................................. 10 3.2 MODULE PORTS AND INTERFACES.............................................................................................................. 12 3.3 ROLES, SERVICES, AND AUTHENTICATION ................................................................................................. 13 3.3.1 Access Control Policy ................................................................................................................... 13 3.3.2 Roles and Services ........................................................................................................................ 14 3.3.3 Operator Authentication ............................................................................................................... 16 3.4 FINITE STATE MODEL ................................................................................................................................ 17 3.5 PHYSICAL SECURITY .................................................................................................................................. 17 3.6 OPERATIONAL ENVIRONMENT.................................................................................................................... 17 3.7 CRYPTOGRAPHIC KEY MANAGEMENT........................................................................................................ 17 3.8 ELECTROMAGNETIC INTERFERENCE/ ELECTROMAGNETIC COMPATIBILITY (EMI/EMC) ........................... 19 3.9 SELF-TESTS ................................................................................................................................................ 19 3.10 DESIGN ASSURANCE .................................................................................................................................. 20 3.10.1 Configuration Management .......................................................................................................... 20 3.10.2 Delivery and Operation................................................................................................................. 21 3.10.3 Installation .................................................................................................................................... 21 3.10.4 Configuring Single User Mode ..................................................................................................... 21 3.10.5 Management .................................................................................................................................. 22 3.10.6 Zeroization .................................................................................................................................... 22 3.10.7 Development ................................................................................................................................. 22 3.10.8 Crypto Officer and User Guidance ............................................................................................... 22 3.11 MITIGATION OF OTHER ATTACKS .............................................................................................................. 22 4 ABBREVIATIONS ............................................................................................................................................ 23 Table of Figures FIGURE 1 – TYPICAL COMPUTRACE SETUP .....................................................................................................................7 FIGURE 2 – STANDARD GPC BLOCK DIAGRAM ............................................................................................................ 10 FIGURE 3 – ABSOLUTE ENCRYPTION ENGINE LOGICAL CRYPTOGRAPHIC BOUNDARY ................................................. 12 List of Tables TABLE 1 – APPLICABLE FIPS 140-2 SECTIONS ...............................................................................................................8 TABLE 2 – FIPS 140-2 LOGICAL INTERFACES .............................................................................................................. 13 Absolute Encryption Engine Page 3 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 TABLE 3 – MAPPING OF THE CO ROLE’S SERVICES TO INPUTS, OUTPUTS, CSPS AND TYPE OF ACCESS ON THE SERVER ............................................................................................................................................................................. 14 TABLE 4 – MAPPING OF THE USER ROLE’S SERVICES TO INPUTS, OUTPUTS, CSPS AND TYPE OF ACCESS ON THE AGENT.................................................................................................................................................................. 15 TABLE 5 – ROLES AND REQUIRED IDENTIFICATION AND AUTHENTICATION ................................................................. 16 TABLE 6 – STRENGTHS OF AUTHENTICATION MECHANISMS ........................................................................................ 17 TABLE 7 – LIST OF CRYPTOGRAPHIC KEYS AND CSPS ................................................................................................. 18 TABLE 8 – ABBREVIATIONS .......................................................................................................................................... 23 Absolute Encryption Engine Page 4 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the Absolute Encryption Engine from Absolute Software Corporation. This Security Policy describes how the Absolute Encryption Engine meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-2, which details the U.S. Government requirements for cryptographic modules. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. The cryptographic module, Absolute Encryption Engine, is referred to as the DLL, the cryptographic module or the module throughout this document. 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 Absolute website (http://www.absolute.com/) contains information on the full line of products from Absolute. • The National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) website (http://csrc.nist.gov/groups/STM/cmvp/index.html) contains information about the FIPS 140-2 standard and validation program. It also lists contact information for answers to technical or sales-related questions for the module. 1.3 Document Organization This Security Policy document is one of the required documents in the FIPS 140-2 Submission Package. In addition to this document, the Submission Package also contains: • Finite State Machine document • Application Programming Interface (API) document • Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Uptown Telecom Consulting Services, Ltd. under contract to Absolute Software Corporation With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to Absolute and is releasable only under appropriate non- disclosure agreements. For access to these documents, please contact Absolute. Absolute Encryption Engine Page 5 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 2 Absolute Absolute Encryption Engine 2.1 Product Overview Absolute Software Corporation provides security products for the central management of all IT assets. The Absolute Encryption Engine is a dynamic-linked library (DLL) defined as the encryption module on the client and server callable by applications via an Application Programming Interface (API). The module is currently used by the Absolute Computrace product. Computrace by Absolute Software allows users to centrally manage all IT assets with a single interface. Users can locate any of their computers that have gone missing, enforce software policies, and maintain a fleet of optimally running devices. Absolute Encryption Engine monitors changes in asset information including user identification, physical location, and installation of software or hardware that may not comply with government and corporate regulations and provides advanced reporting capabilities. In the event of computer loss and theft, Absolute Encryption Engine can delete all sensitive information and generate reports to prove user compliance with government and corporate regulations. The process of locating a computer is done using either using the laptops global positioning device built into the laptop or by using IP information and determing the location on a more granular level. Computrace is based on a client-server architecture. The Computrace Agent is a client software platform that allows you to access Absolute Software services while CTSRV is the Computrace server. A typical Computrace setup diagram is shown in Figure 1 below. Absolute Encryption Engine Page 6 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 Figure 1 – Typical Computrace Setup Other Absolute products also include the Absolute Hard Disk Encryption and Virtual Encrypted Disk. They provide better data protection for improved product security. 2.1.1 Product Platforms The Absolute Computrace product currently supports the Microsoft Windows, Linux and Mac Operating Systems including the following: PC • Windows 7 (32 bit versions) • Windows Vista (32 & 64-bit versions) • Windows XP (32-bit only) • Windows Server 2008 Linux • Red Hat Enterprise Linux 6 Workstation (32 bit versions) Mac • Mac OS X 10.6.7 Other platforms supported and not tested are Mac OS X 10.3.x and higher. Absolute Encryption Engine Page 7 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 2.2 Applicable FIPS 140-2 Sections The cryptographic module is being submitted for validation to FIPS 140-2, Security Level 1. Table 1 – Applicable FIPS 140-2 Sections lists the sections applicable to the module. Table 1 – Applicable FIPS 140-2 Sections 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 Electromagnetic Interference / Electromagnetic Compatibility (EMI/EMC) 1 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A Absolute Encryption Engine Page 8 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 3 Absolute Encryption Engine 3.1 Cryptographic Module Definition This section defines the cryptographic module, the Absolute Encryption Engine which is being submitted for validation to FIPS 140-2, Security Level 1. The DLL is a multi-chip standalone cryptographic module in accordance with the FIPS 140-2 definition. The Absolute Encryption Engine is a software cryptographic module for use on a general purpose computing platform. The module’s software is within the logical cryptographic boundary as defined in Section 3.1.2. The module is tested on the following platform pursuant to the FIPS140-2 requirements: PC (Server) • Windows Server 2008 (64-bit version) PC (Agent) • Windows 7 (32-bit version) • Windows XP (32-bit version) • Windows Vista (32-bit version) • Windows Vista (64-bit version) Linux (Agent) • Red Hat Enterprise Linux 6 (32-bit version) Mac (Agent) • Mac OS X v10.6.7 (32-bit version) The module consists of a set of processes and functions running on the client and server in a client-server architecture that consists of the following generic components: 1. A commercially available general-purpose hardware computing platform. A generic high-level block diagram for such a platform is provided in Figure 2. 2. A commercially available Operating System (OS) that runs on the above platform. 3. A commercially available hard disk that operates on the above platform. 4. The Absolute cryptographic module that runs on the above platform and operating system. This module is custom designed and written by Absolute in the ‘C’ and ‘C++’ programming languages and is identical, at the source code level, for all identified hardware platforms and operating systems. An Application Programming Interface (API) is defined as the interface to the cryptographic module. Absolute Encryption Engine Page 9 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 Figure 2 – Standard GPC Block Diagram 3.1.1 Physical Cryptographic Boundary The module is considered as a multichip standalone module pursuant to the FIPS 140-2 definition. The physical cryptographic boundary contains the general purpose computing hardware of the system executing the application. The casing of the general purpose computer is a hard opaque metal and plastic enclosure. The system hardware includes the central processing unit(s), cache and main memory (RAM), system bus and peripherals including the disk drives and other permanent mass storage devices, network interface cards, keyboard, console and any terminal devices. Figure 2 illustrates the various components, connections, and information flows (the dashed line surrounding the various components makes up the module’s physical cryptographic boundary). 3.1.2 Logical Cryptographic Boundary The logical cryptographic boundary of the module is defined by the set of processes and functions residing on the client and server. The list of authorized services described in Table 3 defines the logical cryptographic boundary. The list of host operating systems being tested is in Section 3.1. Absolute Encryption Engine Page 10 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 The library on each platform is provided below: In Windows 7(32bit & 64bit), XP(32bit) and Vista(32bit & 64 bit): Library: eprvst.dll In Windows 2008 (64-bit): Library: eprvst64.dll In Mac: Library: eprvst.framework In Linux: Library: libwceprv.so Absolute Encryption Engine Page 11 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 Physical Boundary Application (Computrace Agent/CTSRV) Logical Cryptographic Boundary AEE Cryptographic Module Host Operating System Memory CPU Network Disk Legend Plaintext Ciphertext Data Flow Figure 3 – Absolute Encryption Engine Logical Cryptographic Boundary The red dashed box enclosing the “AEE Cryptographic Module” in Figure 3 above represents the logical cryptographic boundary. 3.2 Module Ports and Interfaces The cryptographic module provides a logical interface via an Application Programming Interface (API). The API provides functions that may be called directly by the referencing application. The API provided by the module is mapped onto the FIPS 140-2 logical interfaces: data input, data output, control input, and status output. Absolute Encryption Engine Page 12 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 All of the physical interfaces are separated into logical interfaces defined by FIPS 140-2, as described in the following table: Table 2 – FIPS 140-2 Logical Interfaces FIPS 140-2 Module Ports/Interfaces Physical Ports/Interfaces Logical Interface Data Input Module function calls Keyboard, mouse and Interface serial/USB/parallel/network ports Data Output Return values of module function calls Monitor and serial/USB/parallel/network ports Interface Control Input Module control function calls Keyboard, CD/DVD-ROM, mouse, and Interface serial/USB/parallel/network port Status Output Return values from module status Monitor and serial/USB/parallel/network ports Interface function calls Power Not applicable Power Interface • Data input: function calls that accept data to be used or processed by the module • Data output: output parameters from all functions that return data as return values • Control input: function calls used to control the operation of the module • Status output: module status provided by return values when invoked by the appropriate function calls 3.3 Roles, Services, and Authentication 3.3.1 Access Control Policy The Absolute Encryption Engine provides no authentication of operators. However, the operating system platforms on which the module operates do provide authentication, but this is outside of the cryptographic boundary hence outside the scope of the current FIPS validation. There are two roles in the cryptographic module that operators may assume: the Crypto Officer (CO) role and the User role. All services associated with the Computrace Server are assigned the Crypto Officer role and all Agent services are assigned the User role. Multiple concurrent operators are not allowed. Only a single user may access it at any given point in time. The CO role has access to all the services on the server. The User role can perform general security services on the agent. This role can also perform initialization, initiate self-tests on demand and check the status of the module. A Maintenance role is not supported. Absolute Encryption Engine Page 13 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 3.3.2 Roles and Services The module operates only in the FIPS-Approved mode of operation. Both the CO and User will be able to utilize the functionality of the module. Table 3 and Table 4 list the services available to the roles. Since the module is a dynamic-linked library, inputs to the services are provided in the form of function calls via the module’s Application Programming Interface (API) and outputs are in return values and/or operations performed by the module. The following abbreviations are used in Table 3 and Table 4 below: R – Read, CSP/Key is read by the service W – Write, CSP/Key is modified by the service CID – Context Identifier Table 3 – Mapping of the CO Role’s Services to Inputs, Outputs, CSPs and Type of Access on the Server Service Description Input Output CSP and Type of Access Initialize Load the module API Call Status SW Key; R SW IV; R PRNG Seed; W PRNG Key; W Perform self- Execute power-up self- API Call Status SW Key; R tests tests on demand SW IV; R PRNG Seed; W PRNG Key; W AES context Create a new AES API Call Status, PRNG Seed; W initialization context AES CID PRNG Key; R AES context de- Zeroize the AES API Call, Status AES Trans; W initialization transport key stored in AES CID the context and de- initialize the context RSA context Create a new RSA API Call Status, PRNG Seed; W initialization context RSA CID PRNG Key; R RSA private Zeroize the RSA private API Call, Status RSA Trans Private; W context de- key stored in the context RSA CID initialization and de-initialize the context GCM context Create a new GCM API Call Status, PRNG Seed; W initialization context GCM CID PRNG Key; R GCM context Zeroize the AES GCM API Call, Status GCM Key; W de-initialization key and IV stored in the GCM CID GCM IV; W context and de-initialize the context Import AES key Import plaintext AES key API Call, Status AES Trans; W AES CID, plaintext key Absolute Encryption Engine Page 14 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 Service Description Input Output CSP and Type of Access Import RSA Import encrypted RSA API Call, Status RSA Trans Private; W private key private key AES CID, RSA CID, encrypted key Import AES and Import plaintext AES key API Call, Status, PRNG Seed; W RSA keys and encrypted RSA RSA CID, AES CID PRNG Key; R private key plaintext AES Trans; W key, RSA Trans Private; W encrypted key Import GCM key Import encrypted AES API Call, Status RSA Trans Private; R and IV GCM key and IV RSA CID, GCM Key; W GCM CID, GCM IV; W encrypted key, encrypted IV Authenticated Encrypt plaintext using API Call, Status, GCM Key; R Encryption AES GCM and calculate GCM CID, ciphertext, GCM IV; W a GCM hash plaintext, hash AAD Authenticated Verify the GCM hash API Call, Status, GCM Key; R Decryption and decrypt ciphertext GCM CID, success or GCM IV; W using AES GCM ciphertext, failure hash, AAD indicator, plaintext Get Status Get current status of the API Call Status None module Table 4 – Mapping of the User Role’s Services to Inputs, Outputs, CSPs and Type of Access on the Agent Service Description Input Output CSP and Type of Access Initialize Load the module API Call Status SW Key; R SW IV; R PRNG Seed; W PRNG Key; W Perform self- Execute power-up self- API Call Status SW Key; R tests tests on demand SW IV; R PRNG Seed; W PRNG Key; W RSA context Create a new RSA API Call Status, PRNG Seed; W initialization context RSA CID PRNG Key; R RSA public Zeroize the RSA public API Call, Status RSA Trans Public; W context de- key stored in the context RSA CID initialization and de-initialize the context Absolute Encryption Engine Page 15 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 Service Description Input Output CSP and Type of Access GCM context Create a new GCM API Call Status, PRNG Seed; W initialization context GCM CID PRNG Key; R GCM context Zeroize the AES GCM API Call, Status GCM Key; W de-initialization key and IV stored in the GCM CID GCM IV; W context and de-initialize the context Import RSA Import plaintext RSA API Call, Status RSA Trans Public; W public key public key RSA CID, plaintext key Export GCM Export encrypted AES API Call, Status RSA Trans Private; R key and IV GCM key and IV RSA CID, GCM Key; W GCM CID, GCM IV; W encrypted key, encrypted IV Generate GCM Generate AES GCM key API Call, Status PRNG Seed; W key and IV and IV using PRNG, and RSA CID, PRNG Key; R export generated key GCM CID GCM Key; W and IV using RSA GCM IV; W RSA Trans Public; R Authenticated Encrypt plaintext using API Call, Status, GCM Key; R Encryption AES GCM and calculate GCM CID, ciphertext, GCM IV; W a GCM hash plaintext, hash AAD Authenticated Verify the GCM hash API Call, Status, GCM Key; R Decryption and decrypt ciphertext GCM CID, success or GCM IV; W using AES GCM ciphertext, failure hash, AAD indicator, plaintext Get Status Get current status of the API Call Status None module 3.3.3 Operator Authentication As a Level 1 cryptographic module, the module does not support identification or authentication mechanisms that would distinguish between the two supported roles. These roles are assumed implicitly. Table 5 – Roles and Required Identification and Authentication Role Type of Authentication Data Authentication Crypto Officer N/A N/A User N/A N/A Absolute Encryption Engine Page 16 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 Table 6 – Strengths of Authentication Mechanisms Authentication Strength of Mechanism Mechanism N/A N/A N/A N/A 3.4 Finite State Model Refer to the Finite State Model document. 3.5 Physical Security The cryptographic module is a software module and does not include physical security mechanisms. Therefore, the Physical Security requirements do not apply. 3.6 Operational Environment The cryptographic module operates on a general purpose computing platform. Please refer to 3.1 for a list of supported product platforms. All of the supported platforms are configured for single operator mode as per NIST guidance. Since the module is a dynamic-linked library, the operator is the application calling the module. No concurrent users are allowed. As such, all keys, intermediate values, and other CSPs remain only in the process space of the operator using the module. The operating systems use their native memory management mechanisms to ensure that outside processes cannot access the process space and memory used by the module. 3.7 Cryptographic Key Management The module implements the following FIPS-approved algorithms: • AES ECB (128-bit), AES GCM (128-bit) - (Certificate #1610) • Pseudo-Random Number Generator (ANSI X9.31) - (Certificate #864) As of January 2011, ANSI X9.31 RNG is deprecated. Please refer to NIST Special Publication 800-131A for more information. The module implements the following allowed non-Approved security function: RSA (key wrapping; key establishment methodology provides 128 bits of encryption strength.) RSA is implemented and used only for key transport. Absolute Encryption Engine Page 17 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 The module supports the following keys and critical security parameters: Table 7 – List of Cryptographic Keys and CSPs The following abbreviations are used in Table 7 below: ED – Electronic Distribution EE – Electronic Entry FIPS- Key/ Generation / Approved Owner Type Size Output Storage Zeroization CSP Input Establishment Usage Mechanism SW AES 128 Generated Never EE In binary Module is Server, Agent Key GCM bits outside the exits the uninstalled Software Key module/emb module integrity test edded when module is built SW IV AES 128 Generated Never EE In binary Module is Server, Agent GCM bits outside the exits the uninstalled Software IV module/emb module integrity test edded when module is built PRNG AES 128 Generated Never EE In RAM* as Module is Server, Agent Key Key bits internally exits the plaintext unloaded Random module while number module is generation running PRNG Seed 128 Generated Never EE In RAM* as Module is Server, Agent Seed value bits internally exits the plaintext unloaded Random module while number module is generation running RSA RSA 3072 Generated Never EE In RAM* as RSA Server Trans privat bits outside the exits the plaintext context is Import of AES Private e key module and module while RSA de- GCM Key and imported into context is initialized AES GCM IV the module active generated by a via API call client RSA RSA 3072 Generated Never EE In RAM* as RSA Agent Trans public bits outside the exits the plaintext context is Export of AES Public key module and module while RSA de- GCM Key and imported into context is initialized AES GCM IV the module active via API call Absolute Encryption Engine Page 18 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 FIPS- Key/ Generation / Owner Approved Type Size Output Storage Zeroization CSP Input Establishment Usage Mechanism AES AES 128 Generated Never EE In RAM* as AES Server Trans Key bits outside the exits the plaintext context is Import of Key module and module while AES de- encrypted RSA imported into context is initialized private key the module active via API call GCM AES 128 Generated Encrypte ED/EE In RAM* as AES GCM Server, Agent Key GCM bits internally by d plaintext context is Authenticated Key a client or while AES de- encryption and generated GCM initialized decryption outside the context is module and active imported into a server via API call GCM AES 128 Generated Encrypte ED/EE In RAM* as AES GCM Server, Agent IV GCM bits internally by d plaintext context is Authenticated IV a client or while AES de- encryption and generated GCM initialized decryption outside the context is module and active imported into a server via API call * Inside the module’s cryptographic boundary. 3.8 Electromagnetic Interference/ Electromagnetic Compatibility (EMI/EMC) The module conforms to the EMI/EMC requirements specified by 47 Code of Federal Regulations, Part 15, Subpart B, Unintentional Radiators, Digital Devices, Class A. The EMI/EMC requirements are met by the standard PC platform. 3.9 Self-Tests The module performs the following self-tests at power-up: • Software Integrity Test o A 128-bit hash is computed over the entire module using AES GCM and compared to a stored hard value to verify the integrity of the module. • Cryptographic Algorithm Test Absolute Encryption Engine Page 19 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 o A Known Answer Test (KAT) is performed for: AES encryption, AES decryption, AES GCM authenticated encryption using GHASH, AES GCM decryption using GHASH, and PRNG. Since the module is a dynamic-linked library, the power-up self-tests are initiated automatically when the module is loaded. If any of the self-tests fails, the module on the Windows platform will fail to load while the module on the Mac and Linux platforms will load but all cryptographic operations will fail. The module will enter the Error state. To recover from the error state, a new module must be installed. To show the status of the module, the user can perform a get status after the module has loaded successfully. Power-up self-tests can also be run on demand by the API call, DoFIPSTests. No other critical functions are tested so no critical functions test is performed. The module performs the following conditional self-test. • Continuous Random Number Generation Test o Each output block is compared with the previous output block to ensure they are not the same. Status is reported automatically at the completion of the conditional self-test execution. If the conditional self‐test fails, the module on the Windows platform will fail to load while the module on the Mac and Linux platforms will load but all cryptographic operations will fail. The module will enter the Error state. To recover from the error state, a new module must be installed. To show the status of the module, the user can perform a get status after the module has loaded successfully. Since the module does not generate any public or private keys, the pair-wise consistency test is not performed. No software or firmware components are externally loaded into the module; therefore, the software/firmware load test is not required. Since no cryptographic keys or key components are manually entered, manual key entry test is not applicable. The module does not support a bypass capability hence no bypass test is performed. 3.10 Design Assurance 3.10.1 Configuration Management Absolute uses the Visual Studio Team System (VSTS) Team Foundation Server (TFS), an automated configuration management system for work item tracking, source control and software version control. Code must be checked out to edit and then checked in to become part of the final source tree for the software build. This configuration management system also keeps track of the versions of files used for each build and release. Microsoft SharePoint is used as a document repository which provides document version control. Absolute Encryption Engine Page 20 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 3.10.2 Delivery and Operation The module has to be installed on one of the tested platforms, as specified in Section 3.1 of the Security Policy. The platform must be set up for single-user operation mode. The module is loaded by the application (the Computrace Agent on the client and the CTSRV server application on the server) after the application starts up. Please refer to the Agent Install Guide for installation details. 3.10.3 Installation Please refer to the Agent Install Guide for details. Chapters 2, 3 and 4 provide the installation procedures for the agent on the Windows, Mac and Linux platforms respectively. The Server installation and configuration are performed internally. No installation instructions are available. 3.10.4 Configuring Single User Mode This section describes how to configure the single user mode for the different operating system platforms supported by the module. 3.10.4.1 Microsoft Windows To configure the single user mode for systems running a Microsoft Windows 7 (32-bit version), Windows XP (32-bit version), Windows Vista (32-bit version), Windows Vista (64-bit version) and Windows Server 2008 (64-bit version), the user 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. The services that should be disabled include the following: • Server services • Terminal services • Remote registry service • Remote desktop and remote assistance service 3.10.4.2 Red Hat Linux To configure the single user mode for systems running Red Hat Enterprise Linux 6 (32-bit version), the user must follow the following procedures: 1. Log in as the “root” user. 2. All the users except “root” and the pseudo-users should be removed from the system files /etc/passwd and /etc/shadow. Password fields in /etc/shadow for the pseudo-users should be either an asterisk (*) or double exclamation mark (!!). This prevents login as the pseudo-users. 3. The system file /etc/nsswitch.conf needs to be edited such that “files” the only option for “passwd”, “group”, and “shadow”. This disables NIS and other name services for users and groups. 4. In the /etc/xinetd.d directory, the value of “disable” needs to be set to “yes” for the following files: “rexec”, “rlogin”, “rsh”, “rsync”, “telnet”, and “wu-ftpd”. Absolute Encryption Engine Page 21 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 5. The system has to be rebooted for the changes to take effect 3.10.4.3 Macintosh To configure the single user mode for systems running Mac OS X v10.6.7 (32-bit version), the user must follow the following procedures: 1. Boot (or reboot) with the command key (apple key) and the 'S' key held down. Follow the directions on the screen. This boots into a command line mode (no GUI) 2. Single User with GUI: 2. In System Preferences, select the Accounts preference. 3. In the Accounts preference, select the "Login Options" button (below the list of users). From the Login Options, ensure that "Show fast user switching menu as:" checkbox is unchecked. 4. In System Preferences, select the Sharing preference. 5. In the Sharing preference, ensure that "Remote Login" is unchecked 3.10.5 Management No specific management activities are required for the module. 3.10.6 Zeroization The software integrity key and Initialization Vector will remain until the module has been uninstalled. The PRNG seed and PRNG key will be zeroized when the module is unloaded. All other keys and CSPs are zeroized as soon as the associated context is de-initialized. 3.10.7 Development The design documents show the correspondence of the design to the Security Policy. 3.10.8 Crypto Officer and User Guidance Anyone who has access to the module must not attempt to modify the configuration of the module as designed or reveal any of the CSPs used by the module to other parties. 3.11 Mitigation of Other Attacks This section is not applicable. The vendor does not claim to mitigate any attacks beyond the FIPS 140-2 Level 1 requirements for this validation. Absolute Encryption Engine Page 22 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 4 Abbreviations Table 8 – Abbreviations Acronym Definition AAD Additional Authentication Data AEE Absolute Encryption Engine AES Advanced Encryption Standard CBC Cipher Block Chaining ANSI American National Standards Institute API Application Programming Interface BIOS Basic Input/Output System CD/ROM Compact Disk Read-Only Memory CMVP Cryptographic Module Validation Program CSP Critical Security Parameter CTSRV Computrace Server DLL Dynamic-Linked Library DMZ Demilitarized Zone DVD/ROM Digital Video Disc Read-Only Memory ED Electronic Distribution EE Electronic Entry (Input/Output) EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard GCM Galois Counter Mode GPC General Purpose Computer HDD Hard Disk Drive HTTP Hypertext Transfer Protocol IO Input/Output IP Internet Protocol IR Infrared IV Initialization Vector KAT Known Answer Test NIST National Institute of Standards and Technology NVLAP National Voluntary Lab Accredited Program OS Operating System PC Personal Computer PRNG Pseudo Random Number Generator RSA Rivest, Shamir and Adleman Absolute Encryption Engine Page 23 of 24 Non-Proprietary Security Policy, Version 1.1 December 15, 2011 Acronym Definition TFS Team Foundation Server URL Uniform Resource Locator USB Universal Serial Bus VSTS Visual Studio Team System Absolute Encryption Engine Page 24 of 24