Open Text Cryptographic Module Version 14.0.0.0 FIPS 140-2 Non-Proprietary Security Policy version 2.0 April 29, 2010 This document may be freely reproduced and distributed whole and intact including this Notice. Open Text Cryptographic Module Security Policy v2.0 Revision History Rev. Number Author Date Details 1 Glen Matthews Sept 28, 2009 Initial Version (Open Text Corp.) 2 Glen Matthews April 29, 2010 Clarifications related to review 4/29/10 Page 2 of 17 Open Text Cryptographic Module Security Policy v2.0 Table of Contents 1. Introduction ..................................................................................................................... 4  1.1 Overview ................................................................................................................... 4  1.2 Terminology.............................................................................................................. 4  2. Module Specification ...................................................................................................... 4  2.1 Overview ................................................................................................................... 4  2.2 Cryptographic Boundary ........................................................................................... 5  2.3 Non-Approved Cryptographic Algorithms ............................................................... 6  2.4 Approved Mode of Operation ................................................................................... 7  3. Ports and Interfaces ......................................................................................................... 8  4. Roles and Services .......................................................................................................... 9  5. Operational Environment .............................................................................................. 11  5.1 Operating System Platform ..................................................................................... 11  5.2 Hardware ................................................................................................................. 11  6. Key and CSP Management ........................................................................................... 11  6.1 Critical Security Parameters (CSPs) ....................................................................... 11  6.2 Key Generation ....................................................................................................... 12  6.3 Key Entry and Output ............................................................................................. 12  6.4 Storage of Keys and CSPs ...................................................................................... 12  6.5 Destruction of CSPs ................................................................................................ 12  7. Self-Tests ...................................................................................................................... 13  7.1 Power-Up Tests ....................................................................................................... 13  7.2 Conditional Tests .................................................................................................... 14  8. Design Assurance.......................................................................................................... 14  8.1 Source Code Control ............................................................................................... 14  8.2 Setup and Initialization ........................................................................................... 15  9. Rules of Operation ....................................................................................................... 15  10. Mitigation of Other Attacks ........................................................................................ 16  11. Physical Security ......................................................................................................... 16  12. References ................................................................................................................... 16  4/29/10 Page 3 of 17 Open Text Cryptographic Module Security Policy v2.0 1. Introduction 1.1 Overview This document is the non-proprietary FIPS 140-2 security policy for the Open Text Cryptographic Module which meets the FIPS 140-2 level 1 requirements. This document is a required part of the FIPS 140-2 validation process. This Security Policy details the secure operation of the Open Text Cryptographic Module as required in Federal Information Processing Standards Publication 140-2 (FIPS 140-2) as published by the National Institute of Standards and Technology (NIST) of the United States Department of Commerce. This Security Policy addresses technical aspects as required for the validation of a FIPS 140-2 cryptographic module, including the required operations and capabilities as required by FIPS 140-2. It is available online at the NIST Cryptographic Module Validation website, csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf .  The Open Text Corporation website (www.Open Text.com) contains information on the products available from Open Text Corporation.  Refer to the NIST Validated Modules website (csrc.nist.gov/groups/STM/cmvp/validation.html) for contact information regarding sales or technical information. 1.2 Terminology Hereafter the Open Text Cryptographic Module will simply be referred to as the Cryptographic Module or the Module. This document will be referred to as the Security Policy. 2. Module Specification 2.1 Overview The Open Text Cryptographic Module is a shared library in the form of a DLL that is used in Open Text’s Connectivity Product Line. The name of this module is: HUMLIBEAY32F.DLL. The Module supports Connectivity Software such as FTP for Windows, HostExplorer, Exceed, and Connectivity Secure Shell. The cryptographic capabilities of the library are used to implement encryption and decryption services, as well as protocols such as SSL and SSH. 4/29/10 Page 4 of 17 Open Text Cryptographic Module Security Policy v2.0 Exceed (the Windows-based X11 server software) can use Connectivity Secure Shell as a secure transport. FTP for Windows supports SSL sessions as well as SSH transport. HostExplorer supports SSL and SSH as well. Note that although not FIPS compliant, these applications also support Kerberized connections. For the purposes of FIPS- 140- 2 validation the Module is classified as a multi-chip stand-alone Module. 2.2 Cryptographic Boundary The logical cryptographic boundary for the Module is the library itself. An in-core memory cryptographic digest (HMAC-SHA-1) is computed on the Cryptographic Module memory image and compared to a pre-computed digest value inserted in the Module at build time in order to verify that it has not been altered, as part of the power up self test. Figure 1 : Block Diagram of the Cryptographic Module Central Logical Main Memory Cryptographic Processing Boundary Unit Open Text Cryptographic Module v14.0.0.0 Control Unit Arithmetic I/O Devices Logical Unit Secondary Other Storage: Peripherals Disk Registers System Physical Cryptographic Boundary Ethernet 4/29/10 Page 5 of 17 Open Text Cryptographic Module Security Policy v2.0 The physical cryptographic boundary is the computer hardware itself, including the CPU, memory, system bus and all peripherals: network devices, keyboards, and display console. The Cryptographic Module only communicates with the application program that calls it – it creates no files and does not communicate with other processes, either via inter-process or network communication. This is shown in Figure 1 : Block Diagram of the Cryptographic Module. The Cryptographic Module provides: confidentiality, integrity, key establishment, and message digest services via the algorithms in Table 1a: Approved Cryptographic Algorithms Available in FIPS Mode of Operation . Algorithm Standard FIPS Validation Certificate # RSA (key wrapping, key establishment PKCS#1 methodology provides between 80 and 541 version 1.5 150 bits of encryption strength). DSA FIPS 186-2 371 Triple DES - CBC, CFB8, CFB64, FIPS 46-3 829 ECB, OFB modes (2 and 3 key) AES - CBC, CFB8, CFB128, ECB, FIPS 197 1143 OFB each with 128, 192, or 256 bit keys HMAC-SHA-1 HMAC-SHA-224 FIPS 198 650 HMAC-SHA-256 HMAC-SHA-384 HMAC-SHA-512 SHA-1, SHA-224 , SHA-256, SHA-384, FIPS 180-2 1061 SHA-512 Diffie-Hellman (key agreement, key PKCS#3 N/A establishment provides between 80 and 256 bits of encryption strength) RNG ANSI X9.31 633 Appendix 2.4 RNG Table 1a: Approved Cryptographic Algorithms Available in FIPS Mode of Operation 2.3 Non-Approved Cryptographic Algorithms When running in FIPS mode, all non-FIPS algorithms (see Table 1b : Non-FIPS- Approved Algorithms) in the Cryptographic Module are disabled. RSA and Diffie- 4/29/10 Page 6 of 17 Open Text Cryptographic Module Security Policy v2.0 Hellman methodology is used for key agreement key wrapping (these are non-approved but allowed). Diffie-Hellman provides between 80 bits and 256 bits of encryption strength, while RSA provides between 80 and 150 bits of encryption strength. The module supports key sizes from 1024 to 4096 bits for RSA, and key sizes from 1024 to 15360 for Diffie-Hellman. Table 1b : Non-FIPS-Approved Algorithms Cipher Type Algorithm Symmetric DES, Blowfish, CAST, RC2, RC4, RC5 Public Key ECC (Elliptic Curve Cryptography) Authentication Codes and Hash Functions MD2, MD4, MD5, MDC2, RIPEMD Random Number Generation Message-digest based PRNG 2.4 Approved Mode of Operation The Cryptographic Module is built as a dynamic link library (DLL) under Microsoft Windows. It loads into memory at a fixed location. Address resolution is performed by the loader at application startup – the routines are not linked dynamically. When the Module is loaded into memory, it is by default not initialized and is in non- FIPS mode, with an internal global flag FIPS_mode set to false. In this un-initialized state all cryptographic algorithms are enabled. To initialize the Module and to enter FIPS mode, a single call to FIPS_mode_set() needs to be made by the application program that loaded the Cryptographic Module. This call will calculate an HMAC-SHA-1 digest of the FIPS object code and compare it to a value that was calculated and stored into the DLL when the Cryptographic Module was linked. If this integrity test fails, then the Module fails to initialize in FIPS mode. If this integrity test succeeds, then the power-up self test is performed. If any component of the power-up self test fails, then the Cryptographic Module fails to initialize in FIPS mode (a global error flag is set to FIPS_selftest_fail and the FIPS_mode flag is set to FALSE, and then the Module transitions to the error state). If all self-tests are successful, then the FIPS_mode flag is set to TRUE. If the FIPS_mode flag is TRUE, then FIPS_mode_set() returns 1; otherwise, it returns 0. 4/29/10 Page 7 of 17 Open Text Cryptographic Module Security Policy v2.0 At this point, when the FIPS_mode flag is TRUE, the Cryptographic Module is now in FIPS mode and only FIPS-approved cryptographic routines are available. The Cryptographic Module performs ANSI X9.31 compliant pseudo-random number generation. There are two modes of operation for the Cryptographic Module: FIPS mode and non- FIPS mode (which is the default at startup time). Although there are a number of other non-FIPS cryptographic functions implemented in the Cryptographic Module (shown in Table 1b : Non-FIPS-Approved Algorithms ), when FIPS mode is started these functions are actively disabled. Note that DES is not supported in FIPS mode, although it is available in non-FIPS mode. 3. Ports and Interfaces The physical ports of the Cryptographic Module are those of the computer upon which it executes. The logical interface of the Cryptographic Module is an Application Programming Interface (API). This logical interface exposes services that applications may utilize directly or extend to add support for new data sources or protocols. The API provides functions that may be called by the referencing application. The API interface provided by the Cryptographic Module is mapped onto the FIPS 140- 2 logical interfaces: data input, data output, control input, and status output. Table 2 : Relationship of Cryptographic Module Interfaces to FIPS 140-2 Logical Interfaces FIPS 140-2 Logical Interface Physical Interface Interface Data Input Input parameters to all functions that Ethernet/Network Port, interface accept input from Crypto-Officer or USB Port, Parallel Port User entities Data Output Output parameters from all functions Ethernet/Network Port, interface that return values from Crypto-Officer USB Port, Parallel Port or User entities Control Input All API functions that are input into the Keyboard and Mouse interface Module by the Crypto-Officer and User entities Status Output Information returned via exceptions Monitor interface (return / exit codes) to Crypto-Officer or User entities Power Interface Initialization Function Power Supply 4/29/10 Page 8 of 17 Open Text Cryptographic Module Security Policy v2.0 4. Roles and Services The Cryptographic Modules meets all of the FIPS 140-2 requirements for services and roles, implementing the User and Crypto Officer roles. No authentication is performed for these roles, as allowed by FIPS 140-2. Table 3 : Summary of Services summarizes the services provided by the Cryptographic Module. Note that except for Module Installation and Initialization (which can only be performed by the Crypto Officer) all services can be performed by either role. Both of these roles are implicitly assumed by the entity that accesses services from the Cryptographic Module. Table 3 : Summary of Services Roles Service Critical Algorithm Access Security Parameters User, Symmetric symmetric AES, Read Crypto Encryption/ key Triple DES Write Officer Decryption Execute User, Asymmetric public/private RSA, Read Crypto Digital keys DSA Write Officer Signatures Execute User, Message none SHA-1, Read Crypto Digest SHA-224, Write Officer SHA-256, Execute SHA-384, SHA-512 User, Symmetric Symmetric key AES, Read Crypto Key Triple DES Write Officer Generation Execute User, Asymmetric Asymmetric RSA, DSA Read Crypto Key key Write Officer Generation Execute 4/29/10 Page 9 of 17 Open Text Cryptographic Module Security Policy v2.0 Roles Service Critical Algorithm Access Security Parameters User, HMAC none HMAC- Read Crypto SHA-1, Write Officer HMAC- Execute SHA-224, HMAC- SHA-256, HMAC- SHA-384, HMAC- SHA-512 User, Random seed key ANSI X9.31 Read Crypto Number Write Officer Generation Execute User, Show Status none N/A Execute Crypto Officer User, Crypto Zeroization Keys N/A Write, Officer Execute Crypto Module none N/A Read Officer Initialization Execute User, Self Test HMAC-Key N/A Execute Crypto (includes Officer integrity, known answer, and pair-wise consistency tests) User, Key Diffie- Diffie- Read Crypto Establishment Hellman , Hellman, Write Officer RSA RSA Execute 4/29/10 Page 10 of 17 Open Text Cryptographic Module Security Policy v2.0 5. Operational Environment 5.1 Operating System Platform The Cryptographic Module has been tested on 1. 32 bit Microsoft Windows Vista SP 1 installed. 2. 64 bit Microsoft Windows Vista SP 1 installed. The software Module maintains compliance when running on other versions of 32 or 64 bit Microsoft Windows. 5.2 Hardware Table 4 : Test Machine Specifications Component Type Processor Intel Core 2 Duo (2.40GHz) RAM 2 GB Hard Disk Size 75 GB Ethernet Controller Intel Pro/1000 CT Network Connection DVD Drive HT-DT-ST DVD-ROM GDR8163B Power Supply standard 300 watt PC power supply 6. Key and CSP Management 6.1 Critical Security Parameters (CSPs) Table 5 : Critical Security Parameters describes all of the CSP’s that may reside within the Module. The Module does not permanently store keys as it is up to the application to manage these. The Rules of Operation section define how keys and CSP’s must be managed to maintain FIPS approved mode of operation. 4/29/10 Page 11 of 17 Open Text Cryptographic Module Security Policy v2.0 Table 5 : Critical Security Parameters Key Key Type Storage Use Role Symmetric Keys Triple-DES, Not Stored data encryption and User, AES decryption. CO Asymmetric Keys RSA, DSA Not Stored Signature Generation and User verification CO Wrapping Keys RSA Not Stored Key transport and key CO establishment User Diffie-Hellman Keys Diffie-Hellman Not Stored Key establishment User, CO RNG Key AES 128 Not Stored Used as part of the ANSI User, X9.31 key generation CO HMAC Key HMAC Integrity test key Used for module integrity User, is stored in check CO module, otherwise not stored 6.2 Key Generation The Cryptographic Module uses the ANSI X9.31 Appendix 2.4 RNG for generating all keys. 6.3 Key Entry and Output All keys that are input or output by an application from within the physical boundary must be encrypted with a FIPS Approved algorithm of the appropriate strength. Secret keys used for key establishment must be wrapped with RSA before being output by the application using the Cryptographic Module to perform cryptographic operations. 6.4 Storage of Keys and CSPs The Cryptographic Module does not store any critical security parameters (CSPs) in persistent media (with the sole exception being the HMAC Key, which is employed by the module integrity test and which is contained within the module’s sole DLL file); while the Cryptographic Module is initialized any CSPs reside temporarily in RAM and are destroyed at the end of the session. Any keys or other CSPs otherwise stored in persistent media must be protected using a FIPS Approved algorithm. 6.5 Destruction of CSPs When no longer needed, CSPs contained within the application must be zeroized by overwriting in a way that will make them unrecoverable. The fips_rand_bytes() function 4/29/10 Page 12 of 17 Open Text Cryptographic Module Security Policy v2.0 in the Cryptographic Module can be used to generate random data to overwrite the storage location of a CSP. 6.6 Zeroization of CSPs Keys within the Cryptographic Module process space are protected by the operating system from unauthorized access. API function calls carry out zeroization of internal ephemeral sensitive data, and the invoking process can zeroize its own data on demand by using the same API function calls. Key data is not stored on persistent media by the Cryptographic Module. 7. Self-Tests At startup (when loaded by the calling application) the Cryptographic Module performs a number of power-up and conditional self-tests to ensure operational integrity and correct operation. Power up tests may be performed at any time by calling FIPS_selftest() – if it returns TRUE then the Cryptographic Module is in FIPS mode. No FIPS mode cryptographic capability will be available until all power-up self-tests have completed successfully. Failure of any self-test causes the Cryptographic Module to enter the Error state. This will cause the Module to exit, and thus will cause the application process to terminate. The integrity test consists of computing an HMAC-SHA-1 digest of the Cryptographic Module in memory and comparing it to the value calculated and stored into the Cryptographic Module when it was linked. If it is identical, then the test passes. 7.1 Power-Up Tests The power-up self-tests for the following algorithms use a known answer test (KAT) as shown in Table 6. Table 6 : Power-Up Known Answer Tests Algorithm Known Answer Test AES encryption and decryption with 128 bit key Triple DES encryption and decryption SHS SHA-1, SHA-224, SHA-384, SHA-256, SHA-512 4/29/10 Page 13 of 17 Open Text Cryptographic Module Security Policy v2.0 Algorithm Known Answer Test pair-wise consistency test (signing and signature verification) – allowed DSA by FIPS 140-2 in lieu of a KAT for DSA pair-wise consistency test with a 1024 bit key and a KAT with a 1024 bit RSA key HMAC-SHA-1 HMAC-SHA-224 HMAC-SHA-256 HMAC-SHA-384 HMAC HMAC-SHA-512 RNG random number generation KAT from known IV 7.2 Conditional Tests In addition to the power - up tests, the Module performs several conditional tests including pair-wise consistency tests on newly generated public and private key pairs, as shown in Table 7 : Conditional Tests. Conditional tests are performed automatically as necessary and cannot be turned off. All conditional tests relate to services available only to users. Thus, conditional and critical function tests are not performed at any time in response to Crypto-Officer actions. Table 7 : Conditional Tests Algorithm Conditional Test DSA pair-wise consistency test (signing and signature verification) RSA pair-wise consistency test (public encryption and private decryption) RNG Continuous RNG test to compare generated output with previously generated output 8. Design Assurance 8.1 Source Code Control Source control for the Cryptographic Module is maintained in a version control repository, which allows for version control, change control, and problem tracking. This version control system assigns a unique numerical ID that tracks every change in the source code repository. The Cryptographic Module is designed using a high level programming language (C/C++). 4/29/10 Page 14 of 17 Open Text Cryptographic Module Security Policy v2.0 Documentation is maintained in Microsoft Word format, with change tracking enabled. Every significant change results in a new second level version number, displayed on the title page and every page header. The supporting documentation consists of the Security Policy, and the Vendor Evidence document, the diagram of the Finite State Machine. Both source code and documentation are maintained in a Subversion repository, which is an Open Source revision control system (http://subversion.tigris.org/). 8.2 Setup and Initialization The Cryptographic Module is installed under the Windows operating system using the Windows Installer. After installation, no further initialization of the Cryptographic Module is required, other than the initialization performed by the operating system at Module load time (relocation of addresses, etc. as may be required). The Module is started in non-FIPS mode and must enter FIPS mode via a call from the loading application program. 9. Rules of Operation 1) The Cryptographic Module is initialized in the FIPS mode of operation using the FIPS_mode_set() function call. 2) The replacement or modification of the Cryptographic Module by unauthorized intruders is prohibited. 3) The Operating System enforces authentication method(s) to prevent unauthorized access to Cryptographic Module services 4) All Critical Security Parameters are verified as correct and are securely generated, stored, and destroyed. 5) All host system components that can contain sensitive cryptographic data (main memory, system bus, disk storage) must be located in a secure environment. 6) The referencing application accessing the Cryptographic Module runs in a separate virtual address space with a separate copy of the executable code. 7) The unauthorized reading, writing, or modification of the address space of the Cryptographic Module is prohibited. 8) The writable memory areas of the Cryptographic Module (data and stack segments) are accessible only by a single application so that the Cryptographic Module is in single-user mode, i.e. only the one application has access to that instance of the Cryptographic Module. 9) The operating system is responsible for multitasking operations so that other processes cannot access the address space of the process containing the Cryptographic Module. Secret or private keys that are input or output from an application must be input or output in encrypted form using a FIPS Approved algorithm. 4/29/10 Page 15 of 17 Open Text Cryptographic Module Security Policy v2.0 10. Mitigation of Other Attacks No mitigation of other attacks is performed. 11. Physical Security As the Cryptographic Module is software-only, no physical security is claimed. 12. References 1. FIPS PUB 140-2, Security Requirements for Cryptographic Modules , May 2001, National Institute of Standards and Technology 2. Derived Test Requirements for FIPS PUB 140-2, Security Requirements for Cryptographic Modules , March 24, 2004 (draft), National Institute of Standards and Technology 3. Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program , August 4, 2009, National Institute of Standards and Technology 4. FIPS PUB 197, Advanced Encryption Standard (AES), 26 November 2001, National Institute of Standards and Technology 5. FIPS PUB 46-3, Data Encryption Standard (DES), 25 October 25 1999, National Institute of Standards and Technology 6. FIPS PUB 81, DES Modes of Operation, 2 December 1980, National Institute of Standards and Technology 7. The Advanced Encryption Standard Algorithm Validation Suite (AESAVS) , 15 November 2002, National Institute of Standards and Technology 8. NIST Special Publication 800-20, Modes of Operation Validation System for the Triple Data Encryption Algorithm (TMOVS): Requirements and Procedures, April 2000, National Institute of Standards and Technology 9. NIST Special Publication 800-17, Modes of Operation Validation System (MOVS): Requirements and Procedures, February 1998, National Institute of Standards and Technology 10. FIPS 180-1, Secure Hash Standard (SHS), 17 April 1995, National Institute of Standards and Technology 4/29/10 Page 16 of 17 Open Text Cryptographic Module Security Policy v2.0 11. Network Security with OpenSSL, John Viega et. al., 15 June 2002, O'Reilly & Associates 12. FIPS 171, National Institute of Standards and Technology, 27 April 1992, http: //csrc.nist.gov/publications/fips/fips171/fips171.txt 13. RFC 2246, The TLS Protocol, T. Dierks, C. Allen, January 1999, http: //www.ietf.org/ rfc /rfc2246.txt . 15. Handbook of Applied Cryptography, Alfred Menezes, October 1996, CRC Press. The relevant page describing a RNG implementation is available online at http: //www.cacr.math.uwaterloo.ca /hac/about/chap5.pdf . 16. X9.31- 1988, Digital Signatures using Reversible Public Key Cryptography for the Financial Services Industry (rDSA) , September 9, 1998, American National Standards Institute. 4/29/10 Page 17 of 17