Entrust Cryptographic Module 6.0 FIPS 140-1 Validation Security Policy Author: Pierre Boucher Document Issue: Release 1.11 Issue Date: May 2003 Abstract: This document describes the Entrust Security Kernel 6.0 Cryptographic Module Security Policy submitted for validation, in accordance with the FIPS publication 140-1, level 2. Page 2 of 16 2003 Entrust. All rights reserved. This document may be copied without the author's permission provided that it is copied in its entirety without any modification. Entrust is a trademark or a registered trademark of Entrust, Inc. in certain countries. All Entrust product names and logos are trademarks or registered trademarks of Entrust, Inc. in certain countries. All other company and product names and logos are trademarks or registered trademarks of their respective owners in certain countries. Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 3 of 16 1 Contents 1 CONTENTS ...........................................................................................................................................3 2 CRYPTOGRAPHIC MODULE DEFINITION .................................................................................4 3 SECURITY POLICY............................................................................................................................7 3.1 AUTHENTICATION POLICY ................................................................................................................7 3.2 ACCESS CONTROL POLICY ...............................................................................................................7 3.3 OPERATIONAL ENVIRONMENT ........................................................................................................10 3.3.1 Level 2 Mode of Operation....................................................................................................10 3.3.1.1 Assumptions......................................................................................................................................10 3.3.1.2 Policy ................................................................................................................................................10 3.3.2 Level 1 Mode of Operation....................................................................................................11 3.3.2.1 Assumptions......................................................................................................................................11 3.3.2.2 Policy ................................................................................................................................................12 4 INSTALLATION GUIDANCE..........................................................................................................13 4.1 LEVEL 2 MODE OF OPERATION ......................................................................................................13 4.2 LEVEL 1 MODE OF OPERATION ......................................................................................................14 5 REFERENCES ....................................................................................................................................16 Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 4 of 16 2 Cryptographic Module Definition This document describes the Entrust Security Kernel 6.0 (Cryptographic Module) Security Policy submitted for validation, in accordance with the FIPS publication 140-1, level 2. The module consists of the following generic components: · A commercially available general-purpose hardware computing platform. A generic high-level block diagram for such a platform is provided in Figure 1. · A C2 TCSEC certified commercially available Operating System (OS) that runs on the above platform. · A software component, called the Entrust Cryptographic Kernel, that runs on the above platform and operating system. This component is custom designed and written by Entrust in the C and C++ computer languages, with some small performance-critical sections being written in assembly language. This component is identical, at the source code level, for all supported hardware platforms and operating systems. It is compiled into specific executable object code for each identified platform and linked with an ANSI C library. The cryptographic module was tested on the following hardware computing platform and operating system: 1. A Compaq Proliant 7000 Server with: · 4 Intel Pentium II 400 MHz processors, · 256 MB system RAM (DIMM), · 2 serial ports, 1 parallel port and 2 PS/2 ports, · a 18.2 GB hard drive, and · a Netelligent Dual 10/100 TX PCI Ethernet card. 2. Windows NT 4.0 service pack 6a operating system. The hardware computing platform and operating system were installed and configured to be C2 compliant, as specified at Chapter 4 of Ref [5]. A detailed technical description of the Compaq Proliant 7000 Server platform is included at Ref [4]. Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 5 of 16 The Entrust cryptographic kernel 6.0 has been validated on the above platform to FIPS 140-1 level 2. The implementation of the module is also suitable for FIPS 140-1 level 1 on any general purpose computers from the same or other manufacturers, based on compatible processors with equivalent or greater system resources and equivalent or later Operating System versions, including Windows 95/98, Windows NT 3.5 and 3.51, Windows NT 4.0 SP3, 4 and 5, and Windows 2000 provided that: Figure 1 Cryptographic module block diagram for software (top) and hardware (bottom) User Interface Application Software Kernel Interface Cryptographic Kernel Cryptoki API Optional Cryptoki library Cryptographic Boundary Video Display Video System Display Bus Driver Keyboard Micro- Keyboard processor Interface Mouse System Mouse Memory Interface Disk Drive Unallocated Network Files and Network other s/w space and OS Interface components swapped data Serial Optional Hardware Port Optional Crypto Token Serial PC/Card Interface Interface Parallel External Port Power Source Parallel Power Interface Supply Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 6 of 16 1. The general purpose computer uses the specified single user operating system/mode specified on the validation certificate, or another compatible single user operating system, and 2. The software of the cryptomodule does not require modification when ported (platform specific modifications are excluded). Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 7 of 16 3 Security Policy This section describes the security policy for the module, as defined in FIPS PUB 140-1 and the companion Test Requirements document. The FIPS 140-1 cryptographic module is defined to be the module identified earlier in section 2 of this document. 3.1 Authentication Policy The cryptographic module must perform authentication of the operator before it can deliver any cryptographic services. Authenticated operators are authorized to assume one or a set of the following supported roles: public user, private user or cryptographic officer. Operators authenticate themselves in the public user role by presenting a valid MAC; the MAC is stored in the entrust.ini file and is the same for all authorized Entrust users1. Authentication to the private user and cryptographic officer roles is performed by presenting a valid user password; the password is unique to each individual user. The functions that allow users to login into the private user and cryptographic officer roles are only available from the public user role; an operator must be already authenticated in the public user role before he/she can authenticate in the private user and cryptographic officer roles. 3.2 Access Control Policy The cryptographic module supports three roles: public user, private user and crypto-officer. An operator accesses services available from the public user role after being successfully authenticated with a valid MAC, and accesses services available from both private user and cryptographic officer roles after being successfully authenticated with a valid password. An operator performing a service within any role can read and write security-relevant data items only through the invocation of a service by means of the cryptographic module API. The type of services corresponding to each of the supported roles is described in Table 1 Roles and Services. 1 Under normal operations, Entrust software automatically reads the MAC from the entrust.ini file and presents it to the cryptographic module on behalf of the user. The cryptographic module will not initialize unless a valid MAC is provided. Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 8 of 16 Table 1 Roles and Services Role Services Public User Authentication, symmetric key generation, key destruction, symmetric encryption/decryption, hashing, MAC generation/verification, self-test, login Private User Key pair generation, asymmetric encryption/decryption (sign/verify), password change Cryptographic Officer Configuration of cryptographic services (e.g. set/generate initialization vector) The whole set of cryptographic services is available to operators that are authenticated into the private user and cryptographic officer roles. Only those services that do not require access to an operator asymmetric private key, and services that modify the configuration of the cryptographic module, can be accessed from the public role. The following FIPS approved basic services are provided by the cryptographic module: 1. Cryptographic data hashing using FIPS PUB 180-1 SHA-1 (and MD2, MD5, RIPEMD-160, HMAC-MD5, HMAC-SHA1 and HMAC- RMD160)1. 2. Bulk data encryption, decryption, and MAC calculation using FIPS PUB 46-3 DES and 3-DES, and FIPS PUB 197 AES (and CAST, CAST3, CAST5, RC2, IDEA and cipher stream RC4)1. 3. Signing and signature verification using FIPS PUB 186-2 DSA and RSA, and PKCS#1 RSA (and ECDSA) 1. The Entrust cryptographic module also provides the following services: 1. Key wrapping and unwrapping using RSA. 2. Key agreement using Diffie-Hellman and Ephemeral-Static Diffie- Hellman2. 3. User authentication (as described above). 1 Algorithms in parenthesis have not been FIPS-approved yet; therefore, the kernel is not operating in accordance with FIPS 140-1 when these algorithms are selected. 2 As specified in RFC 2631 Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 9 of 16 4. Random number generation using an ANSI X9.17-compliant software- based algorithm, or a hardware token-based generator. The FIPS 140-1 related Security Relevant Data Items (SRDI) include DES keys, 3-DES keys, AES keys, DSA and RSA private keys, and DSA parameters.3 When the cryptographic module is initialized into the FIPS 140-1 compliant mode (this is done by passing TRUE to the initialization function), the following restrictions take effect: 1. During the generation of random symmetric, asymmetric, and generic keys in software, the random numbers must come from the software- based random number generator and not from any hardware token. 2. Asymmetric private and generic keys cannot be input to or output from the module via the kernel API in plaintext form. They may, however, be input or output in wrapped (encrypted) or hashed form. 3. Symmetric keys (except for 3-DES keys) cannot be input to the module via the kernel API in plaintext form. Symmetric keys (including 3-DES keys) cannot be output from the module in plaintext form. They may, however, be input or output in wrapped (encrypted) or hashed form. 4. Symmetric, asymmetric private and generic keys cannot be input to or output from the module via the Cryptoki interface in plaintext form. They may, however, be input or output in wrapped (encrypted) form. 5. Software authentication must be performed after initialization of the module and before any cryptographic operation is attempted. 6. User authentication must be performed after initialization of the module and before any cryptographic operations are attempted, as described above in section 3.1. 7. In non-FIPS mode, software authentication and user authentication is optional. 8. Only DES can be used in the X9.17 random number generator. 3 IVs are either loaded externally, in which case the length is verified to be 64 bits (only CBC mode is used), or are generated internally using the internal RNG, which is FIPS approved. Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 10 of 16 3.3 Operational Environment 3.3.1 Level 2 Mode of Operation 3.3.1.1 Assumptions The following assumptions are made about the operating environment of the cryptomodule in Level 2 mode of operation: 1. The module is initialized to the FIPS 140-1 mode of operation. 2. Tamper-evident seals are applied as indicated at Figure 2. To these ends, the following operational rules must be followed by a user or integrator of the module. 3.3.1.2 Policy 1. The Entrust Cryptographic Module has been validated to be used with: ! one or more applications, as a shared Windows DLL, or ! single application, as a statically linked library. 2. The cryptographic module must execute on a C2 or equivalent certified operating system. The Entrust cryptographic module has been validated for use on Windows NT 4.0 SP6a, which requires installation and configuration as specified at Ref [5]. 3. The security permissions of the application file that contains the cryptographic module (e.g. etfile32.dll or etsesn32.dll) must be configured so that: ! only authorized Entrust users can execute the application; ! only the cryptographic officer can delete, replace or modify the application. 4. The security permissions of the files that contain user security sensitive data (e.g. user profile) must be configured so that: ! only authorized Entrust users have access to their own security sensitive data. Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 11 of 16 5. The security permissions of the file that contains configuration and initialization information (i.e. entrust.ini) must be configured so that: ! only authorized Entrust users can read the file; ! only the cryptographic officer can modify the file. 6. All public keys entered into the module must be verified as being legitimate and belonging to the correct entity by the software running on the same platform as the cryptomodule. 7. Virtual memory that exist on the platform where the cryptomodule runs must be configured to reside on a local, not a networked, drive. 8. The hardware computing platform that hosts the cryptographic module must be protected via tamper-evident labels. It must not be possible to open covers or doors without breaking or removing a label, or replacing a label without leaving detectable signs. 9. The above conditions must be upheld at all times in order to ensure continued system security after initial setup of the validated configuration. If the module is removed from the above environment, it is assumed to not be operational in the level 2 validated mode until such time as it has been returned to the above environment and re-initialized by the user to the validated condition. 3.3.2 Level 1 Mode of Operation 3.3.2.1 Assumptions The following assumptions are made about the operating environment of the cryptomodule in Level 1 mode of operation: 1. Unauthorized reading, writing, or modification of the module's memory space (code and data) by an intruder (human, program or otherwise) is not feasible. 2. Replacement or modification of the legitimate module code by an intruder (human, program or otherwise) is not feasible. 3. The module is initialized to the FIPS 140-1 mode of operation. Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 12 of 16 3.3.2.2 Policy 1. The Entrust Cryptographic Module has been validated to be used with: ! one or more applications, as a shared Windows DLL, or ! single application, as a statically linked library. 2. The module is to be used by only one human operator at a time and must not be actively shared among operators at any period during its lifetime. Also, there must be only one instance of the cryptographic module loaded in RAM at any given time on a given machine. 3. All public keys entered into the module must be verified as being legitimate and belonging to the correct entity by software running on the same platform as the cryptomodule. 4. Virtual memory that exists on the platform where the cryptomodule runs must be configured to reside on a local, not a networked, drive. 5. The above conditions must be upheld at all times in order to ensure continued system security after initial setup of the validated configuration. If the module is removed from the above environment, it is assumed to not be operational in the validated mode until such time as it has been returned to the above environment and re-initialized by the user to the validated condition. Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 13 of 16 4 Installation Guidance 4.1 Level 2 Mode of Operation 1. The Entrust cryptographic module must be installed on a C2 evaluated computing platform. The computing platform described in Section 2 satisfies the FIPS 140-1 level 2 requirements for Operating System Security. 2. Entrust files shall be configured using access permissions as indicated in Table 1: Table 2 Entrust Files Access Permissions (Windows NT 4.0) File User Permission Application that .dll (e.g. All Entrust Execute (X) contains the module winnt\system32\etfile32.dll) operators .exe (e.g. \etmaster.exe) Administrator Change (RWXD) User Profile .epf file (e.g. \entrust profile\*.epf) Entrust Full Control (All) operator (own) Entrust No Access operator (other's) Administrator No Access Initialization and .ini (e.g. \winnt\entrust.ini) All Entrust Read (R) operation data operators Administrator Change (RWXD) 3. To operate the Entrust cryptographic module in FIPS mode, the FipsMode entry in the FIPS Mode section of the Entrust initialization (entrust.ini) file must be set to 1. For example, [FIPS Mode] FIPS=1 Etfile32Name=etfile32 Etfile32Auth=DES-MAC,64, F404A ... Etsesn32Name=etsesn32 Etsesn32Auth=DES-MAC,64, E23B1 ... Setting FIPS=0 (zero) prevents the module from operating in FIPS mode. 4. Tamper-evident labels must be applied to the computing platform so that it is not possible to open/remove any removable covers or panels without leaving detectable signs such as broken label or detection of label residue on the enclosure. Administrators (or security officers) must apply labels to all openings and removable covers, as indicated at Figure 24. The storage and distribution of the labels should remain under the auspices of an administrator (or security officer). 4 The adhesive must be allowed twenty-four hours to set-up properly. Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 14 of 16 Figure 2 Location of Tamper-Evident Seals SECURITY LABEL SECURITY LABEL 4.2 Level 1 Mode of Operation 1. To operate the Entrust cryptographic module in FIPS mode, the FipsMode entry in the FIPS Mode section of the Entrust initialization (entrust.ini) file must be set to 1. For example, [FIPS Mode] FIPS=1 Etfile32Name=etfile32 Etfile32Auth=DES-MAC,64, F404A ... Etsesn32Name=etsesn32 Etsesn32Auth=DES-MAC,64, E23B1 ... Setting FipsMode to 0 (zero) prevents the module from operating in FIPS mode. 2. The operating system should be configured to operate securely and to prevent remote login. Reference [5] provides guidance on securing Windows NT. 3. To operate the Entrust cryptographic module in level 2 Physical Security mode, tamper-evident labels must be applied to the computing platform so that it is not possible to open/remove any removable covers or panels without Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 15 of 16 leaving detectable signs such as broken label or detection of label residue on the enclosure. Administrators or security officers should apply approved labels as indicated at Figure 2. The storage and distribution of the labels should remain under the auspices of an administrator or security officer. Release 1.11 Entrust Cryptographic Module Validation Security Policy Page 16 of 16 5 References [1] FIPS PUB 140-1: Security Requirements for Cryptographic Modules. National Institute of Standards and Technology, 11 January 1994. [2] Derived Test Requirements for FIPS PUB 140-1, Security Requirements for Cryptographic Modules, National Institute of Standards and Technology, September 1994. [3] PKCS #1: RSA Cryptography Specifications, Version 2.0, RSA Laboratories, September 1998. [4] Compaq ProLiant 7000 Maintenance and Service Guide - Pentium II Xeon Processor-based Servers, first edition, July 1998. [5] C2 Administrator's and User's Security Guide, Microsoft Windows NT, version 4.0, December 1999. (see http://www.microsoft.com/security/issues/deployingc2.asp) Release 1.11 Entrust Cryptographic Module Validation Security Policy