SUSK Security Module (Software Version: 1.1) FIPS 140-2 Non-Proprietary Security Policy Level 1 Validation Document Version 0.5 © 9/16/2008 Secured User, Inc. Page 1 Table of Contents 1 INTRODUCTION ...............................................................................................................................................3 1.1 PURPOSE ..........................................................................................................................................................3 2 SUSK SECURITY MODULE ............................................................................................................................4 2.1 PRODUCT OVERVIEW .......................................................................................................................................4 2.2 MODULE SPECIFICATION ..................................................................................................................................5 2.3 MODULE INTERFACES ......................................................................................................................................6 2.4 ROLES AND SERVICES ......................................................................................................................................7 2.4.1 Crypto-Officer Role ...............................................................................................................................7 2.4.2 User Role ...............................................................................................................................................7 2.5 PHYSICAL SECURITY ........................................................................................................................................8 2.6 OPERATIONAL ENVIRONMENT .........................................................................................................................9 2.7 CRYPTOGRAPHIC KEY MANAGEMENT .............................................................................................................9 2.8 SELF-TESTS ....................................................................................................................................................11 2.9 DESIGN ASSURANCE ......................................................................................................................................11 2.10 MITIGATION OF OTHER ATTACKS .............................................................................................................11 3 SECURE OPERATION....................................................................................................................................12 3.1 CRYPTO-OFFICER GUIDANCE .........................................................................................................................12 3.1.1 Initial Setup..........................................................................................................................................12 3.1.2 Management ........................................................................................................................................13 3.2 USER GUIDANCE ............................................................................................................................................13 4 ACRONYMS......................................................................................................................................................14 © 9/16/2008 Secured User, Inc. Page 2 Non Proprietary Security Policy, Version 0.5 9/16/2008 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the SUSK Security Module from Secured User, Inc. This Security Policy describes how the SUSK Security Module meets the security requirements of FIPS 140-2 and how to run the module in a secure FIPS 140-2 mode. This policy was prepared as part of the Level 1 FIPS 140- 2 validation of the module. The Secured User website (http://www.secured-services.com) contains information on the full line of products from Secured User. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 ­ Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) Cryptographic Module Validation Program (CMVP) website at: http://csrc.nist.gov/groups/STM/cmvp/index.html. The SUSK Security Module is also referred to in this document as the cryptographic module, the software module, or the module. © 9/16/2008 Secured User, Inc. Page 3 Non Proprietary Security Policy, Version 0.5 9/16/2008 2 SUSK Security Module 2.1 Product Overview Secured User provides products for centrally-administered security environments for enterprises running mainframe, client-server, and web-based applications. The company's application environment provides: · Complete Identity Life Cycle Management: Comprehensive identity administration, access control, and audit management functionality, built on a single, integrated platform. This makes for a unique cohesiveness in managing the entire life cycle of a digital identity. · A Single Identity, with True, Enterprise-Wide Reach: The realization of true single sign-on to all application types, whether Web-based, client/server, or legacy mainframe. · Ease of Deployment: Overcomes traditional barriers to identity management projects, deploying rapidly, non-disruptively, without changes to legacy code or directories, and with radically less risk and complexity than competing approaches. Secured User's product performs all of its work by transparently intercepting and transforming the data stream between entities. Figure 1 ­ Secured User's Application Deployment All of the cryptographic functionalities of the Secured User product are provided by a central shared library, SUSK Security Module. The cryptographic module offers Transport Layer Security (TLS) services along with bulk encryption and hashing services exclusively to Secured User application. This application is considered as host application to the module. © 9/16/2008 Secured User, Inc. Page 4 Non Proprietary Security Policy, Version 0.5 9/16/2008 2.2 Module Specification The SUSK Security Module is a software-based cryptographic module tested for use on a standard server running the Windows Server 2003, HP-UX and Linux Operating Systems (OS). The module's software is entirely encapsulated by the logical cryptographic boundary as shown in Figure 2 below. Operating System SUSK Security Host Module Application Cryptographic Boundary Plaintext (Data/Control/Status) Ciphertext (Data) Figure 2 - Logical Cryptographic Boundary In addition to the binaries, the physical device consists of the motherboard circuits, the central processing unit (CPU), random access memory (RAM), read-only memory (ROM), server case, expansion cards, and other hardware components included in the server such as hard disk, floppy disk, CD-ROM drive, power supply, and fans. The physical cryptographic boundary of the module is the hard opaque metal and plastic enclosure of the server. A physical block diagrams is shown below. © 9/16/2008 Secured User, Inc. Page 5 Non Proprietary Security Policy, Version 0.5 9/16/2008 Figure 3 - Standard Server Physical Block Diagram Per FIPS 140-2 terminology, the SUSK Security Module is a multi-chip standalone module that meets overall level 1 FIPS 140-2 requirements. The SUSK Security Module is validated at the following FIPS 140-2 Section levels: Table 1 - Security Level per FIPS 140-2 Section Section Section Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and 1 Interfaces 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 EMI/EMC 1 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A 2.3 Module Interfaces The module's logical interfaces exist in the software as an Application Programming Interface (API). Physically, ports and interfaces are considered to be those of the server. Both the API and physical interfaces can be categorized into following logical interfaces defined by FIPS 140-2: © 9/16/2008 Secured User, Inc. Page 6 Non Proprietary Security Policy, Version 0.5 9/16/2008 · Data Input Interface · Data Out Interface · Data Control Interface · Status Output Interface · Power Interface All of these logical interfaces are described in the following table: Table 2 - FIPS 140-2 Logical Interfaces FIPS 140-2 Logical SUSK Security Module Port/Interface Physical Port/Interface Interface Data Input Function calls that accept, as their Keyboard, mouse, CD-ROM, floppy arguments, data to be used or processed by disk, and serial/USB/parallel/network the module. ports Data Output Arguments for a function that specify where Floppy disk, monitor, and the result of the function is stored. serial/USB/parallel/network ports Control Input Function calls utilized to initiate the module Keyboard, CD-ROM, floppy disk, and the function calls used to control the mouse, and operation of the module. serial/USB/parallel/network port Status Output Return values for function calls Floppy disk, monitor, and serial/USB/parallel/network ports Power Interface Not applicable Power Interface 2.4 Roles and Services Two roles are supported by the module (as required by FIPS 140-2) that operators may assume: a Crypto-Officer (CO) role and a User role. The operator of the module must assume either of the roles based on their operation without any authentication. Both of the roles and their responsibilities are described below. 2.4.1 Crypto-Officer Role The Crypto-Officer (CO) is expected to install and configure the module in the FIPS mode of operation. The CO is also responsible for monitoring the module's configuration and operational status from the Windows event log. Please see the Secure Operation section for a complete list of the Crypto-Officer's responsibilities. Descriptions of the services available to the Crypto-Officer role are provided in the table below. Table 3 ­ Mapping of Crypto-Officer Role's Services to Inputs, Outputs, CSPs, and Type of Access Service Description Input Output CSP and Type of Access Installation Installing the Command Result of None software module installation Uninstall Uninstall the Command Module uninstalled None software module SUSK_SSL_library_init Enables the FIPS API call The module None mode of operation. executes in FIPS mode of operation SUSK_selftest Performs power-up API call Self-tests performed None self-tests 2.4.2 User Role The User role accesses the module's cryptographic services that include TLS operation, encryption/decryption, and hashing. The following table lists the services available to the User role. © 9/16/2008 Secured User, Inc. Page 7 Non Proprietary Security Policy, Version 0.5 9/16/2008 Table 4 ­ Mapping of User Role's Services to Inputs, Outputs, CSPs, and Type of Access Service Description Input Output CSP and Type of Access SUSK_TLS_connect Initiates the TLS API call TLS connection Diffie-Hellman handshake with a completed (DH) key pair ­ server Read RSA key pair ­ Read Session Key ­ Write SUSK_TLS_close Terminates a TLS API call TLS connection None connection terminated SUSK_get_error Obtains result code API call Status of TLS None for TLS operation connection SUSK_TLS_read Reads bytes from a API call with Data read from a Session Key ­ TLS connection input data TLS session Read SUSK_TLS_write Writes bytes to a API call Data sent over a Session Key ­ TLS connection TLS session Read SUSK_TLS_accept Accepts TLS API call TLS handshake DH key pair ­ handshake from a initiated Read client RSA key pair ­ Read Session Key ­ Write SUSK_keygen Generates a API call Key generated Pseudo Random random key Number Generator (PRNG) seed ­ Read/Write Symmetric Key ­ Write SUSK_encrypt AES cipher API call with a Data encrypted Symmetric key ­ operation symmetric key /decrypted Read and input data SUSK_hashinit Initiate hashing API call Hashing context None mechanism initializes SUSK_hashupdate Updates hashing API call with Hash value None digest input data updated SUSK_hashfinal Finalizes hash API call Returns digest None value SUSK_Rijndael_encrypt AES encryption API call with a Data encrypted Symmetric key ­ symmetric key Read and input data SUSK_Rijndael_decrypt AES decryption API call with a Data decrypted Symmetric key ­ symmetric key Read and input data Operator spaces on the module are separated by the Operating System. The OS must be configured for single user mode in FIPS-approved mode of operation. 2.5 Physical Security The physical security requirements do not apply to this module since it is a software module and does not implement any physical security mechanisms. © 9/16/2008 Secured User, Inc. Page 8 Non Proprietary Security Policy, Version 0.5 9/16/2008 Although the module consists entirely of software, the FIPS 140-2 tested platform is a standard server, which has been tested for and meets applicable Federal Communication Commission (FCC) Electromagnetic Interference (EMI) and Electromagnetic Compatibility (EMC) requirements for business use as defined in Subpart B of FCC Part 15. 2.6 Operational Environment SUSK module runs on the general purpose Windows Server 2003 and Linux Operating Systems. The module was tested on the following Operating Systems for FIPS 140-2 requirements: · Windows Server 2003 (32 and 64 bit) · Linux Red Hat 2.6, Fedora 6, and SuSe 10 · HP-UX 11.11 The OS must be configured for single user mode per NIST CMVP guidance for FIPS 140-2 compliance. Single user mode configuration instructions for the OS can be found in the Secure Operation section. 2.7 Cryptographic Key Management The SUSK Security Module implements the following FIPS-approved algorithms: · AES ECB/CBC mode ­ FIPS 197 (certificate #474 and #770) · SHA-1 ­ FIPS 180-2 (certificate #542) · HMAC SHA-1 ­ FIPS 198 (HMAC certificate #231, SHA-1 certificate #542) · Deterministic Random Number Generator (RNG) ­ Appendix A.2.4 of ANSI X9.31 (certificate #257) Additionally, the software module utilizes the following non-FIPS-approved algorithm 1 implementations: · Diffie-Hellman (key agreement, key establishment methodology provides 80-bits of encryption strength) · RSA (key wrapping, key establishment methodology provides 80-bits of encryption strength) 1 In order to operate in an Approved mode of operation compliant to FIPS 140-2, Diffie-Hellman and RSA keys of 1024-bits are used. © 9/16/2008 Secured User, Inc. Page 9 Non Proprietary Security Policy, Version 0.5 9/16/2008 The module supports the following critical security parameters: Table 5 - List of Cryptographic Keys, Cryptographic Key Components, and CSPs Key Key Type Generation / Input Output Storage Zeroization Use Diffie-Hellman Key Diffie-Hellman key Generated for TLS Never exit the Plaintext in volatile Zeroized after Used by the module pair pair (1024 bits) session module memory session is over or by in establishing a establishment power cycle session key during TLS handshake Session Key AES key (256 bits) Established during Exits the module in Plaintext in volatile Zeroized after Used to encrypt the TLS session plaintext memory session is over or by TLS session. establishment power cycle Symmetric Key AES key (128, 192, Generated internally Exits the module in Plaintext in volatile By power cycle Encrypts/decrypts 256 bits) or entered plaintext memory data electronically in plaintext Asymmetric Key RSA key pair (1024 Generated internally Exits the module in Plaintext in volatile By power cycle Used by the module bits) plaintext memory in establishing a session key during TLS handshake Software Integrity HMAC key (16 Hard coded into the Never exit the Stored on hard drive Uninstalling the Checks integrity of Test Key bytes) module module in plaintext module the software PRNG Seed 8 bytes of seed Prearranged value Never exit the Plaintext in volatile By power cycle Generate ANSI value module memory X9.31 A.2.4 PRNG © 9/16/2008 Secured User, Inc. Page 10 Non Proprietary Security Policy, Version 0.5 9/16/2008 2.8 Self-Tests In order to prevent any secure data from being released, it is important to test the cryptographic components of a security module to ensure that all components are functioning correctly. The module performs the following self- tests: · Power-Up Self-Tests: o Software integrity check using HMAC SHA-1 o Known Answer Tests (KATs) AES KATs SHA-1 KAT RSA Pairwise Consistency Test X9.31 PRNG KAT The SUSK Security Module performs the following conditional self-tests: · Continuous RNG for FIPS approved PRNG · RSA Pairwise Consistency Test · Diffie-Hellman Pairwise Consistency Test Status output of self-tests are logged in the Windows Event log file, unless the Crypto-Officer configures the module to record the status output into a local file. On Linux platforms, status output is always logged into a local file. 2.9 Design Assurance Configuration management for all of the Secured User's source code files and user manual is provided by Subversion. The source code revisions are maintained in a private Subversion repository with write access restricted to the core development team. 2.10 Mitigation of Other Attacks This section is not applicable. The module does not claim to mitigate any attacks beyond the FIPS 140-2 level 1 requirements for this validation. © 9/16/2008 Secured User, Inc. Page 11 Non Proprietary Security Policy, Version 0.5 9/16/2008 3 Secure Operation The SUSK Security Module meets Level 1 requirements for FIPS 140-2. The sections below describe how to configure and maintain the module in a FIPS-approved mode of operation. Operating the module without following this guidance will remove the module from the FIPS-approved mode of operation. 3.1 Crypto-Officer Guidance 3.1.1 Initial Setup The Crypto-Officer is responsible for installing/uninstalling, configuring, and managing the module. The SUSK Security Module is available on a Compact Disc (CD) to the Crypto-Officer from Secured User through shipping using a standard carrier (i.e. FedEx or UPS). The Crypto-Officer is responsible for inspecting the CD and its packaging upon receipt for signs of tampering. If evidence of tampering is found, the Crypto-Officer should contact Secured User immediately and should not use the module. The software module will be provided to users by Secured User for exclusive use in their products only. The module is installed during installation of the host application, Identiprise SecuredUser. With the delivered software, the Crypto-Officer also receives a complete documentation library, which includes the Installation Guidance for the host application. Before installing the module, the CO must configure the OS for single user mode as instructed below. To configure Windows Server 2003 for single user mode, the CO 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 are ­ · Server services · Terminal services · Remote registry service · Remote desktop and remote assistance service The specific procedures for each of the Linux variants are described below. 1. The CO has to 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 a star (*) 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" need to be set to "yes" for the following files: "rexec", "rlogin", "rsh", "rsync", "telnet", and "wu-ftpd". 5. The system has to reboot for the changes to take effect. The specific procedure for HP-UX is described below. 1. The CO has to 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 a star (*). 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/inetd.conf file, lines for remote login, remote command execution, and file transfer daemons such as telnetd, rlogind, remshd, rexecd, ftpd, and tftpd need to be removed. © 9/16/2008 Secured User, Inc. Page 12 Non Proprietary Security Policy, Version 0.5 9/16/2008 5. The system has to reboot for the changes to take effect. 3.1.2 Management The Crypto-Officer should monitor the module's status by regularly checking the event log file of the module. If any irregular activity is noticed or the module is consistently reporting errors, then Secured User customer support should be contacted. 3.2 User Guidance The User accesses the module's cryptographic functionalities only. Although the User does not have any ability to modify the configuration of the module, they should report to the Crypto-Officer if any irregular activity is noticed. © 9/16/2008 Secured User, Inc. Page 13 Non Proprietary Security Policy, Version 0.5 9/16/2008 4 Acronyms Table 6 - Acronyms Acronym Definition AES Advanced Encryption Standard API Application Programming Interface ANSI American National Standards Institution CD Compact Disk CMVP Cryptographic Module Validation Program CO Crypto-Officer CPU Central Processing Unit CRNGT Continuous Random Number Generator Test CSP Critical Security Parameter DH Diffie-Hellman EMC Electromagnetic Compatibility EMI Electromagnetic Interference FCC Federal Communication Commission FIPS Federal Information Processing Standard FSM Finite State Machine HMAC (Keyed-) Hash MAC KAT Known Answer Test LED Light Emitting Diode NIST National Institute of Standards and Technology NVLAP National Voluntary Laboratory Accreditation Program OS Operating System PRNG Pseudo Random Number Generator RAM Random Access Memory RNG Random Number Generator ROM Read Only Memory RSA Rivest, Shamir, and Adleman SHA Secure Hash Algorithm SUSK SecuredUser Security Kernel TLS Transport Layer Security USB Universal Serial Bus VSS Visual Source Safe © 9/16/2008 Secured User, Inc. Page 14