Entrust, Inc. Cryptographic Module Security Policy Entrust Authority Security Toolkit for Java 6.1 Author: Chris Wood Date: Wednesday June 12, 2002 Feature: ENTOT00046991 ­ FIPS Mode Support Version: 1.2 This document may be copied without the author's permission provided that it is copied in it's 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. Cryptographic Module Security Policy Issued by: Chris Wood Revision: 1.2 June 12, 2002 Table of Contents 1 Revision History................................................................................... 1 2 References............................................................................................ 1 3 Target Audience ................................................................................... 1 4 Introduction .......................................................................................... 2 4.1 Purpose of the Security Policy ......................................................................2 4.2 Cryptographic Module Definition ..................................................................2 4.3 Cryptographic Module Description ...............................................................4 5 Specification of the Security Policy ................................................... 4 5.1 Identification and Authentication Policy ......................................................4 5.2 Access Control Policy....................................................................................5 5.3 Physical Security Policy.................................................................................7 5.4 Operational Environment ...............................................................................7 5.4.1 Assumptions ........................................................................................................... 7 5.4.2 Installation and Initialization .................................................................................. 7 5.4.3 Policy........................................................................................................................ 7 5.5 Mitigation of Other Attacks Policy ................................................................8 Entrust, Inc. - ii - Cryptographic Module Security Policy Issued by: Chris Wood Revision: 1.2 June 12, 2002 1 Revision History Authors Date Version Comment Chris Wood June 12, 2002 1.0 First Version Chris Wood October 15, 2002 1.1 Comments from DOMUS Chris Wood March 19, 2003 1.2 Comments from NIST Contributors Topics Marc Laroche Suggestions, guidance 2 References Author Title NIST [1] FIPS PUB 140-2: Security Requirements For Cryptographic Modules, May 2001 NIST [2] Derived Test Requirements for FIPS PUB 140-2, November 2001 NIST [3] Implementation Guidance for FIPS PUB 140-1 and the Cryptographic Module Validation Program, July 2001 Entrust [4] Security Toolkit for Java 6.1 - Programmer's Guide, 2002 Entrust [CMC] Cryptographic Module Classes for the Security Toolkit for Java 6.1, June 2002 Entrust [CR] Cryptographic Module Validation Cross-Reference for the Security Toolkit fro Java 6.1, June 2002 Entrust [DD] Cryptographic Module Design Description for the Security Toolkit for Java 6.1, June 2002 Entrust [FD] Cryptographic Module Functional Description for the Security Toolkit for Java 6.1, June 2002 Dell [SM] Dell OptiPlex GXa Systems Service Manual, Dell Computer Corporation, 1997 (http://docs.us.dell.com/docs/systems/dfuj/51555bk0.pdf). Dell [RIG] Dell OptiPlex GXa Mini Tower Systems with Enhanced Manageability (EM) Reference and Installation Guide, Dell Computer Corporation, 1997 (http://docs.us.dell.com/docs/systems/dfuj/88763.pdf). 3 Target Audience This document is intended to be part of the package of documents that are sent for FIPS validation. It is intended for the following people: · NIST and the FIPS validation group · Developers working on the release · Product Verification · Documentation · Product and Development Managers · Security Assurance Entrust, Inc. -1- Cryptographic Module Security Policy Issued by: Chris Wood Revision: 1.2 June 12, 2002 4 Introduction This document contains a description of the Entrust AuthorityTM Security Toolkit for JavaTM(JTK) Cryptographic Module Security Policy. It contains a specification of the rules under which the JTK cryptographic module must operate. These security rules were derived from the requirements of FIPS 140-2 validation [1]. 4.1 Purpose of the Security Policy There are three major reasons that a security policy is defined for and must be followed by the cryptographic module: · It is required for FIPS 140-2 validation. · It allows individuals and organizations to determine whether the cryptographic module, as implemented, satisfies the stated security policy. · It describes the capabilities, protection, and access rights provided by the cryptographic module, allowing individuals and organizations to determine whether it will meet their security requirements. 4.2 Cryptographic Module Definition This section defines the cryptographic module that is being submitted for validation to FIPS PUB 140-2, level 1. The module 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 1. 2. A commercially available Operating System (OS) that runs on the above platform. 3. The Java Runtime Environment. 4. A software component, the JTK (set of `.class' files) that runs on the above platform, operating system, and Java runtime environment. This component is custom designed and written by Entrust in the Java computer language and is identical, at the source code level, for all identified hardware platforms and operating systems. The source code (see [FD] for list of classes) is compiled into Java byte-code for interpretation by the Java Virtual Machine on the above OS or Browser. An Application Programming Interface (API) is defined as the interface to the cryptographic module. The cryptographic module contains the following hardware computing platform and operating system: 1. A Dell OptiPlex GXa Midsize Personal Computer system with: · An Intel Pentium II 300MHz processor, · 128MB system RAM (DIMM), · 2 serial ports and 1 parallel port, · 4.3GB hard drive, · A 3COM 3C509 Ethernet card, 2. Operating Systems: · Microsoft Windows NT 4.0 SP6a · Microsoft Windows 2000 SP3 · Microsoft Windows ME · Microsoft Windows XP SP1a 3. Java Runtime Environment: · Sun JRE 1.2.2 · Sun JRE 1.3.1 Entrust, Inc. -2- Cryptographic Module Security Policy Issued by: Chris Wood Revision: 1.2 June 12, 2002 · Sun JRE 1.4.0 · IBM JRE 1.3 A detailed technical description of the Dell OptiPlex GXa platform is included in [SM] and [RIG]. The JTK cryptographic module is also suitable for platforms from the same or other manufacturers, based on compatible processors with equivalent or greater system resources, equivalent or later Operating System versions, and equivalent or later Java Runtime Environment versions. Also, the JTK cryptographic module used on all Microsoft Operating Systems is identical. Cryptographic Boundary Video Video System Display Display Bus Driver Display info Micro- Keyboard processor Interface Keyboard Data and control Operator commands System Mouse Mouse Memory Interface Data Operator commands Network Disk Interface Drive Network Serial Optional Hardware Port Optional Crypto Token Serial PC/Card Interface Interface Parallel Data and parameters Port Parallel Power Interface Supply External Power Source Note: All arrows indicate data flow, however; only bold arrows indicate data (plaintext and encrypted) flows into and out of the Cryptographic Module Figure 1: Cryptographic module block diagram for hardware. Entrust, Inc. -3- Cryptographic Module Security Policy Issued by: Chris Wood Revision: 1.2 June 12, 2002 Application Software Entrust Authority Toolkit for Java Module Interface Crytpgraphic Boundary Crytpgraphic Module Cryptoki API Optional Cryptoki Library Note: Bold arrows indicate data (plaintext and encrypted) flows into and out of the Cryptographic Module Figure 2: Cryptographic module block diagram for software. 4.3 Cryptographic Module Description The cryptographic module consists of a defined subset of Java .class files from the JTK. These classes are listed and described in the Cryptographic Module Classes [CMC] companion document. The cryptographic module provides a set of functions (API) that allows developers to integrate the cryptographic module security features into the applications they design. The cryptographic module API is described in detail in the Cryptographic Module Functional Description [FD] companion document. The purpose of the cryptographic module is to provide application developers with the access to cryptographic algorithms, and the ability to integrate security into the applications they design. The types of cryptographic algorithms provided include: · Symmetric Ciphers (encryption/decryption/key generation) · Asymmetric Ciphers (encryption/decryption/key generation) · Message Digests (hashing) · Signatures (signing/verification) · Message Authentication Codes (creation) · Random Number/Seed Generation · Key Agreement 5 Specification of the Security Policy 5.1 Identification and Authentication Policy The Cryptographic Module does not identify nor authenticate any user (in any role) that is accessing the Cryptographic Module. This is only acceptable for FIPS 140-2 level 1 validation. Role Type of Authentication Data Authentication User None N/A Cryptographic Officer None N/A Entrust, Inc. -4- Cryptographic Module Security Policy Issued by: Chris Wood Revision: 1.2 June 12, 2002 Table 1: Roles and Required Identification and Authentication Authentication Strength of Mechanism Mechanism None N/A Table 2: Strengths of Authentication Mechanisms 5.2 Access Control Policy The Cryptographic Module supports two roles: User and Cryptographic Officer. An operator performing a service within any role can read/write cryptographic keys and critical security parameters (CSP) only through the invocation of a service by use of the Cryptographic Module API. Thus, that user can read/write the cryptographic keys and CSPs that the given API call allows. The type of services corresponding to each of the supported roles is described in the table below: Role Authorized Services User · Symmetric Encryption/Decryption - AES - CAST-128 - IDEA - RC2 - RC4 - Rijndael(256-bit block size) - Triple-DES · Asymmetric Encryption/Decryption - RSA · Digital Signature Generation/Verification - DSA - ECDSA - RSA · Hash Generation - MD2 - MD5 - SHA-1 · MAC Generation - CAST-128 MAC - DES MAC - HMAC-MD5 - HMAC-SHA1 - IDEA MAC - Triple-DES MAC · Key Agreement - Diffie-Hellman - SPEKE · Random Number/Seed Generation - ANS1 X9.31-AES - ANS1 X9.31-DES Entrust, Inc. -5- Cryptographic Module Security Policy Issued by: Chris Wood Revision: 1.2 June 12, 2002 Cryptographic Officer Initialization of the Cryptographic Module Key Input/Output - AES - CAST-128 - Diffie-Hellman - DSA - ECDSA - IDEA - RC2 - RC4 - Rijndael - RSA - SPEKE - Triple-DES CSP Input/Output - State of Cryptographic Module All Services of the User role Table 3: Services Authorized for Roles An operator is explicitly in the User or Cryptographic Officer role based upon the services chosen. If any of the User specific services are called, then the operator is in the User role; otherwise the operator is in the Cryptographic Officer role. Each service within each role can only access the cryptographic keys and CSPs that the service's API defines. The following cases exist: · A cryptographic key or CSP is provided to an API as an input parameter; this indicates read/write access to that cryptographic key or CSP. · A cryptographic key or CSP is returned from an API as a return value; this indicates read access to that cryptographic key or CSP. Service Cryptographic Keys Types of and CSPs Access Symmetric Symmetric Key Read/Write Encryption/Decryption Asymmetric Asymmetric Key Pair Read/Write Encryption/Decryption Digital Signature Asymmetric Key Pair Read/Write Generation/Verification Hash Generation None N/A MAC Generation Symmetric Key Read/Write Key Agreement Asymmetric Key Pair Read/Write Random Number Seed N/A Generation Initialization of the None N/A Cryptographic Module Key Input/Output Key Read/Write CSP Input/Output CSP Read/Write Table 4: Access Rights within Services Entrust, Inc. -6- Cryptographic Module Security Policy Issued by: Chris Wood Revision: 1.2 June 12, 2002 Detailed information on which Cryptographic Module APIs belong to each role can be found in the Cryptographic Module Functional Description[FD]. This document specifies a role for each API call, and the CSPs involved in the call. 5.3 Physical Security Policy The physical security of the cryptographic module is provided by the PC that it is being used on. For more detailed information on the physical security please refer to [SM] and [RIG]. 5.4 Operational Environment 5.4.1 Assumptions The following assumptions are made about the operating environment of the cryptographic module: · Unauthorized reading, writing, or modification of the module's memory space (code and data) by an intruder (human or machine) is not possible; this is prevented by the process memory management of the Operating System. · Replacement or modification of the legitimate cryptographic module code by an intruder (human or machine) is not feasible · The module is initialized to the FIPS 140-2 mode of operation 5.4.2 Installation and Initialization The following steps must be performed to install and initialize the JTK cryptographic module for operating in a FIPS 140-2 compliant manner: · The operating system must be configured to operate securely and to prevent remote login. · The operating system must be configured to allow only a single user. · All the jar files shipped with the JTK must be copied to the machine on which the JTK is being used. · The Java runtime environment must be configured to recognize the JTK jar files either by setting the CLASSPATH environment variable or by using the JTK as an installed extension. · To operate the JTK in a FIPS 140-2 compliant the cryptographic module must be initialized to operate in OPERATIONAL_FIPS mode; this is done by calling SecurityEngine.initialize( true ). 5.4.3 Policy The following policy must always be followed in order to achieve a FIPS 140-2 mode of operation: · The cryptographic module must only be used by one human operator at a time, and must not be actively shared among operators at any time. Also, there must be only one instance of the cryptographic module loaded into RAM at any give time on any given machine. · All keys entered into the cryptographic module must be verified as being legitimate and belonging to the correct entity by software running on the same machine as the cryptographic module. · Virtual memory that exists on the machine when the cryptographic module runs must be configured to reside on a local, not a networked, drive. · 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. Entrust, Inc. -7- Cryptographic Module Security Policy Issued by: Chris Wood Revision: 1.2 June 12, 2002 5.5 Mitigation of Other Attacks Policy The cryptographic module is not designed to mitigate any specific attacks. Other Attacks Mitigation Specific Limitations Mechanism None N/A N/A Table 5: Mitigation of Other Attacks Entrust, Inc. -8-