Sterling Commerce, Inc. Sterling Crypto-C Software Version: 1.5 FIPS 140-2 Non-Proprietary Security Policy Level 1 Validation Document Version 1.0 Prepared for: Prepared by: Sterling Commerce, Inc. Corsec Security, Inc. 4600 Lakehurst Court 10340 Democracy Lane, Suite 201 Dublin, Ohio 43016-2000 Fairfax, VA 22030-2518 Phone: (469) 524-2681 Phone: (703) 267-6050 Fax: (972) 953-2690 Fax: (703) 267-6810 http://www.sterlingcommerce.com http://www.corsec.com © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 Revision History Version Modification Date Modified By Description of Changes 1.0 2008-01-09 Xiaoyu Ruan Release version Sterling Crypto-C Page 2 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 Table of Contents 1 INTRODUCTION ...............................................................................................................................................6 1.1 PURPOSE .........................................................................................................................................................6 1.2 REFERENCES...................................................................................................................................................6 1.3 DOCUMENT ORGANIZATION ...........................................................................................................................6 2 STERLING CRYPTO-C.....................................................................................................................................7 2.1 OVERVIEW......................................................................................................................................................7 2.2 MODULE INTERFACES.....................................................................................................................................8 2.3 ROLES AND SERVICES ...................................................................................................................................11 2.3.1 Crypto Officer Role..............................................................................................................................11 2.3.2 User Role .............................................................................................................................................11 2.4 PHYSICAL SECURITY ....................................................................................................................................13 2.5 OPERATIONAL ENVIRONMENT ......................................................................................................................13 2.6 CRYPTOGRAPHIC KEY MANAGEMENT ..........................................................................................................13 2.6.1 Key Generation ....................................................................................................................................15 2.6.2 Key Input/Output .................................................................................................................................15 2.6.3 Key Storage..........................................................................................................................................15 2.6.4 Key Zeroization....................................................................................................................................15 2.7 SELF-TESTS ..................................................................................................................................................15 2.8 DESIGN ASSURANCE .....................................................................................................................................16 2.9 MITIGATION OF OTHER ATTACKS.................................................................................................................16 3 SECURE OPERATION....................................................................................................................................17 3.1 CRYPTO OFFICER GUIDANCE ........................................................................................................................17 3.1.1 Single User Configuration ...................................................................................................................17 3.1.2 Initialization.........................................................................................................................................19 3.1.3 Zeroization...........................................................................................................................................19 3.1.4 Management ........................................................................................................................................20 3.2 USER GUIDANCE ..........................................................................................................................................20 4 ACRONYMS......................................................................................................................................................21 Sterling Crypto-C Page 3 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 Table of Figures FIGURE 1 ­ LOGICAL CRYPTOGRAPHIC BOUNDARY .......................................................................................................8 FIGURE 2 ­ LOGICAL CRYPTOGRAPHIC BOUNDARY AND INTERACTIONS WITH SURROUNDING COMPONENTS ...............9 FIGURE 3 ­ PHYSICAL BLOCK DIAGRAM OF A SERVER .................................................................................................10 Sterling Crypto-C Page 4 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 Table of Tables TABLE 1 ­ BINARY FORMS OF THE MODULE ..................................................................................................................7 TABLE 2 ­ SECURITY LEVEL PER FIPS 140-2 SECTION...................................................................................................8 TABLE 3 ­ LOGICAL INTERFACE, PHYSICAL PORT, AND MODULE MAPPING ................................................................10 TABLE 4 ­ MODULE ROLES AND SERVICES ..................................................................................................................11 TABLE 5 ­ CRYPTO OFFICER SERVICES ........................................................................................................................11 TABLE 6 ­ USER SERVICES ...........................................................................................................................................11 TABLE 7 ­ LIST OF CRYPTOGRAPHIC KEYS AND CSPS .................................................................................................14 TABLE 8 ­ ACRONYMS .................................................................................................................................................21 Sterling Crypto-C Page 5 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 1 Introduction 1.1 Purpose This document is a non-proprietary Cryptographic Module Security Policy for the Sterling Crypto-C from Sterling Commerce, Inc. This Security Policy describes how Sterling Crypto-C meets the security requirements of FIPS 140-2 and how to run the module in a secure FIPS 140-2 mode of operation. This policy was prepared as part of the Level 1 FIPS 140-2 validation of Sterling Crypto-C. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 ­ Security Requirements for Cryptographic Modules) details the U.S. and Canadian 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/index.html. In this document, Sterling Crypto-C is referred to as "the module". The application represents Sterling Commerce's software products linked with the cryptographic libraries provided by Sterling Crypto-C. 1.2 References This document deals only with the 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 Sterling Commerce website (http://www.sterlingcommerce.com) contains information on the full line of products from Sterling Commerce. · The CMVP website (http://csrc.nist.gov/groups/STM/index.html) contains contact information for answers to technical or sales-related questions for the module. 1.3 Document Organization The Security Policy document is one document in a FIPS 140-2 submission package. In addition to this document, the Submission Package contains: · Vendor Evidence · Finite State Machine · Other supporting documentation as additional references This Security Policy and the other validation submission documentation have been produced by Corsec Security, Inc. under contract to Sterling Commerce. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Validation Documentation is proprietary to Sterling Commerce and is releasable only under appropriate non- disclosure agreements. For access to these documents, please contact Sterling Commerce. Sterling Crypto-C Page 6 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 2 Sterling Crypto-C 2.1 Overview Sterling Commerce is the world's leading provider of multi-enterprise collaboration solutions for the Global 5000. Their software and services help companies operate more profitably by giving them visibility and control over the processes they share with business and supply chain partners. Sterling Crypto-C is a cryptographic module implemented as two software dynamic link libraries (DLLs) on Windows or two Shared Objects (SO's) on Solaris, IBM AIX, and HP-UX. Sterling Crypto-C provides applications with an Application Programming Interface (API) of security-relevant functions and services such as Advanced Encryption Standard (AES), Triple Data Encryption Standard (TDES), Secure Hash Algorithm (SHA), Keyed-Hash Message Authentication Code (HMAC), Digital Signature Algorithm (DSA), Rivest, Shamir, and Adleman (RSA), etc. See Section 2.6 of this document for a complete list of supported algorithms. Sterling Crypto-C is a user space shared library. It does not modify or become part of the Operating System (OS) kernel. Sterling Crypto-C for the purpose of this FIPS validation has been tested and validated on the following platforms: 1. Windows Server 2003 on Intel Pentium, 2. Sun Solaris 10 on UltraSPARC II, 3. IBM AIX 5L 5.3 on PowerPC POWER5, 4. HP-UX 11i v2 on HP 9000/80 with PA-RISC1, 5. HP-UX 11i v2 on HP Integrity with Intel Itanium 2 (formally known as IA-64). Table 1 depicts platforms and corresponding file names of the module on these platforms. Table 1 ­ Binary Forms of the Module Operating System Binary File Names Windows Server 2003 libeay32.dll, ssleay32.dll Sun Solaris 10 libcrypto.so, libssl.so IBM AIX 5L 5.3 libcrypto.so, libssl.so HP-UX 11i v2 (on PA-RISC) libcrypto.sl, libssl.sl HP-UX 11i v2 (on HP Integrity) libcrypto.so, libssl.so When operating in the FIPS mode of operation, Sterling Crypto-C is validated at FIPS 140-2 section levels shown in Table 2. Note that in Table 2, EMI and EMC mean Electromagnetic Interference and Electromagnetic Compatibility, respectively, and N/A indicates "Not Applicable". 1 Reduced Instruction Set Computer Sterling Crypto-C Page 7 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 Table 2 ­ Security Level per FIPS 140-2 Section 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 EMI/EMC 1 9 Self-Tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A 2.2 Module Interfaces Sterling Crypto-C is a software module that meets overall level 1 of FIPS 140-2 requirements. The logical cryptographic boundary of the module consists of Sterling Crypto-C libraries, which run on several OS platforms. The module is composed of two binary files compiled on the OS. Table 1 summarizes the platforms and the binary files. Figure 1 shows the logical cryptographic boundary of the module. In the FIPS mode of operation, the module provides a set of cryptographic services (API calls) in eight areas such as Transport Layer Security (TLS), Random Number Generator (RNG), etc. Figure 1 ­ Logical Cryptographic Boundary Sterling Crypto-C Page 8 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 The module's interactions with surrounding components, including the Central Processing Unit (CPU), hard-disk, memory, application, and the OS are demonstrated in Figure 2. Figure 2 ­ Logical Cryptographic Boundary and Interactions with Surrounding Components The module is validated for use on the platforms listed in the first column of Table 1. In addition to the binaries, the physical device consists of the integrated circuits of the motherboard, the CPU, Random Access Memory (RAM), Read-Only Memory (ROM), computer case, keyboard, mouse, video interfaces, expansion cards, and other hardware components included in the computer such as hard disk, floppy disk, Compact Disc ROM (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 running the module. The block diagram for a server is shown in Figure 3. Note that in this figure, I/O means Input/Output, BIOS stands for Basic Input/Output System, PCI stands for Peripheral Component Interconnect, ISA stands for Instruction Set Architecture, and IDE represents Integrated Drive Electronics. Sterling Crypto-C Page 9 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 Figure 3 ­ Physical Block Diagram of a Server All of these physical ports are separated into logical interfaces defined by FIPS 140-2, as described in Table 3. Table 3 ­ Logical Interface, Physical Port, and Module Mapping Logical Physical Port Mapping Module Mapping Interface Data Hard Disk, keyboard, mouse, CD-ROM, Arguments for API calls that contain data to be used Input floppy disk, and serial/ Universal Serial or processed by the module Bus (USB)/parallel/network ports Data Hard Disk, floppy disk, monitor, and Arguments for API calls that contain module Output serial/USB/parallel/network ports response data to be used or processed by the caller Control Hard Disk, keyboard, CD-ROM, floppy API function calls Input disk, mouse, and serial/USB/parallel/network port Status Hard disk, floppy disk, monitor, and Arguments for API calls, function return value, error Output serial/USB/parallel/network ports message Sterling Crypto-C Page 10 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 Logical Physical Port Mapping Module Mapping Interface Power Power supply N/A 2.3 Roles and Services The operators of the module can assume two roles as required by FIPS 140-2: a Crypto Officer role and a User role. The operator of the module assumes either of the roles based on the operations performed without any authentication. Table 4 gives a brief description of the roles and their privileges. Table 4 ­ Module Roles and Services Role Name Role Services Crypto Officer 1. Installing/uninstalling the module on the specific platform. 2. Initiating power-up self-tests. User Calling cryptographic functions provided by the module. The following subsections detail both of the roles and their responsibilities. 2.3.1 Crypto Officer Role The Crypto Officer role has the ability to install and uninstall the module and run power-up self-tests. Descriptions of the services available to the Crypto Officer role are provided to Table 5, where CSP refers to Critical Security Parameter. Services available to the User role listed in Table 6 are also available to the Crypto Officer role. Table 5 ­ Crypto Officer Services CSP and Type Service Description Input Output of Access Install module Installs and configures the module according Command Success or None to the operating system failure Uninstall Remove the module from the operating Command Success or None module system failure Run power-up Power-up self-tests include: (1) software Call to Pass or failure None self-tests integrity test; (2) Known Answer Tests FIPS_mode_set(1) (KATs) for TDES, AES, RSA, HMAC, RNG; or FIPS_selftest() (3) pair-wise consistency test for DSA keys 2.3.2 User Role The User role accesses the module's cryptographic services that include encryption, decryption, and authentication functionality. Descriptions of the services available to the User role are provided in Table 6. Table 6 ­ User Services CSP and Type of Service Description Input Output Access TDES encryption Encrypt plaintext using Command, plaintext, Status, ciphertext TDES symmetric keys TDES keys - READ Sterling Crypto-C Page 11 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 CSP and Type of Service Description Input Output Access TDES decryption Decrypt TDES- Command, ciphertext, Status, plaintext TDES symmetric key encrypted ciphertext key - READ TDES key generation Generate TDES Command, key length Status, symmetric TDES symmetric keys symmetric keys keys - READ/WRITE AES encryption Encrypt plaintext using Command, plaintext, Status, ciphertext AES symmetric key AES key - READ AES decryption Decrypt AES-encrypted Command, ciphertext, Status, plaintext AES symmetric key ciphertext key - READ AES key generation Generate an AES Command, key length Status, symmetric AES symmetric key symmetric key and set key - READ/WRITE the key schedule RSA encryption Encrypt symmetric key Command, plaintext Status, encrypted RSA public key using RSA symmetric key, RSA symmetric key - READ public key Symmetric key - READ RSA decryption Decrypt RSA-encrypted Command, encrypted Status, decrypted RSA private key symmetric key symmetric key, RSA symmetric key - READ private key Symmetric key - WRITE RSA signature Sign data using RSA Command, data to be Status, digital RSA private key generation signed, RSA private signature - READ key RSA signature Verify an RSA signature Command, data and Status, RSA public key verification signature, RSA public acceptance/denial - READ key RSA key-pair Generate a RSA key- Command, key length Status, RSA private RSA private key and generation pair key and public key public key - WRITE DSA signature Sign data using DSA Command, data to be Status, digital DSA private key generation signed signature - READ DSA signature Verify an DSA signature Command, data and Status, DSA public key verification signature acceptance/denial - READ DSA key-pair Generate an DSA key- Command, key length Status, DSA private DSA private key and generation pair key and public key public key - WRITE SHA digest Generate a SHA digest Command, message Status, message None generation to be hashed digest HMAC-SHA key Generate a HMAC-SHA Command, key length Status, HMAC-SHA HMAC-SHA key generation symmetric key symmetric key - WRITE HMAC-SHA digest Generate a HMAC-SHA Command, message Status, HMAC-SHA HMAC-SHA key generation digest to be hashed, key message digest - READ Random number Generate a random Command, seed, Status, random Seed generation number length number - READ/WRITE TLS session Establish a new TLS Command Status, session ID Diffie-Hellman keys establishment session - READ Sterling Crypto-C Page 12 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 CSP and Type of Service Description Input Output Access TLS master secret Generate a TLS master Command Status, TLS master TLS master secret generation secret secret - WRITE Encrypted TDES key Import an encrypted Command Status TDES symmetric key import TDES key in a TLS - WRITE session Encrypted AES key Import an encrypted Command Status AES symmetric key import AES key in a TLS - WRITE session Encrypted TLS Import an encrypted Command Status TLS master secret master secret import TLS master secret in a - WRITE TLS session 2.4 Physical Security Sterling Crypto-C is a multi-chip standalone module. The physical security requirements do not apply to this module, since it is purely a software module and does not implement any physical security mechanisms. Although the module consists entirely of software, the FIPS 140-2 platform is a server that has been tested for and meets applicable Federal Communications Commission (FCC) EMI and EMC requirements for business use as defined in Subpart B of FCC Part 15. 2.5 Operational Environment The module was tested and validated on general-purpose Microsoft Windows Server 2003, Sun Solaris 10, IBM AIX 5L 5.3, and HP-UX 11i v2 operating systems. The module must be configured in single user mode as per the instructions provided in Section 3.1.1 of this document. Recommended configuration changes for the supported operating systems can also be found in section 3.1.1. 2.6 Cryptographic Key Management The module implements the following FIPS-approved algorithms in the FIPS mode of operation. · SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 (certificate #655) · HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 (certificate #312) · RSA PKCS2 #1 for signature generation/verification: 1024, 2048, and 4096 bits (certificate #280) · DSA for key generation and signature generation/verification: 1024 bits (certificate #235) · ANSI3 X9.31 RNG with 2-key TDES (certificate #403) · TDES: 112 and 168 bits, in Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB), and Output Feedback (OFB) modes (certificate #578) · AES: 128, 192, and 256 bits, in ECB, CBC, CFB, OFB, and counter modes (certificate #605) 2 Public Key Cryptography Standard 3 American National Standards Institute Sterling Crypto-C Page 13 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 The module implements the following non-Approved security functions in the FIPS mode of operation. · Diffie-Hellman (key agreement, key establishment) methodology provides between 80 and 256 bits of encryption strength. · RSA (key wrapping, key establishment) methodology provides between 80 and 150 bits of encryption strength. The module implements the following non-Approved algorithms in the non-FIPS mode of operation: DES, RC2, RC4, Blowfish, CAST, MD2, MD4, MD5, RIPEMD, and HMAC MD5. The module supports the following CSPs in the FIPS mode of operation: Table 7 ­ List of Cryptographic Keys and CSPs Key Key Type Generation / Input Output Storage Zeroization Use TDES keys Symmetric 1. Generated by ANSI Via TLS Plaintext in Zeroized after Encrypt key X9.31 RNG. sessions in volatile use plaintext, 2. Derived from TLS encrypted memory decrypt master secret. form. ciphertext 3. Input in plaintext form. AES key Symmetric 1. Generated by ANSI Via TLS Plaintext in Zeroized after Encrypt key X9.31 RNG. sessions in volatile use plaintext, 2. Derived from TLS encrypted memory decrypt master secret. form. ciphertext 3. Input in plaintext form. RSA Private key Generated by ANSI X9.31 In plaintext Plaintext in Zeroized after Decrypt secret private key RNG volatile use keys, sign memory messages RSA public Public key 1. Generated by ANSI In plaintext Plaintext in Zeroized after Encrypt secret key X9.31 RNG volatile use keys, verify 2. Input in plaintext form. memory signatures DSA Private key Generated by ANSI X9.31 In plaintext Plaintext in Zeroized after Sign messages private key RNG volatile use memory DSA public Public key 1. Generated by ANSI In plaintext Plaintext in Zeroized after Verify key X9.31 RNG volatile use signatures 2. Input in plaintext form. memory Diffie- Public keys 1. Generated by ANSI In plaintext Plaintext in Zeroized after Establish Hellman X9.31 RNG volatile use symmetric keys public keys 2. Input in plaintext form. memory p,g Diffie- Private key Generated by ANSI X9.31 Never output Plaintext in Zeroized after Establish Hellman RNG volatile use symmetric keys private memory keys a,b ANSI Date/Time Generated internally Never output Plaintext in Zeroized when Generate X9.31 value for volatile new Date/Time random RNG ANSI memory value is fed numbers Date/Time X9.31 value RNG Sterling Crypto-C Page 14 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 Key Key Type Generation / Input Output Storage Zeroization Use TLS TLS 1. Generated by ANSI Via TLS Plaintext in Zeroized when Derive keys in master master X9.31 RNG session in volatile TLS session is TLS sessions secret secret 2. Input via TLS sessions ciphertext memory over in encrypted form 2.6.1 Key Generation The module uses an ANSI X9.31 RNG with 2-key TDES to generate cryptographic keys. This RNG is a FIPS 140- 2 approved RNG as specified in Annex C to FIPS PUB 140-2. 2.6.2 Key Input/Output Keys can be input to and output from the module in either plaintext or encrypted form. 2.6.3 Key Storage All CSPs are stored in volatile memory in plaintext. 2.6.4 Key Zeroization All CSPs are stored in volatile memory in plaintext. All CSPs are zeroized when they are no longer used. i.e., CSPs are zeroized when the sessions in which they are used are closed. The zeroization of the keys is carried out by overwriting the memory location with zeros. See Section 3.1.3 of this document for details. 2.7 Self-Tests Sterling Crypto-C performs the following power-up self-tests when FIPS_mode_set(1) is called. A call to FIPS_mode_set(1) is necessary to set the module in the FIPS mode of operation. See Section 3.1.2 of this document for details. When needed, the power-up self-tests can also be initiated by a call to FIPS_selftest(). · Software integrity test using HMAC-SHA-1. · TDES KAT with 3 independent keys (56 bits each) in ECB mode. · TDES KAT with 2 independent keys (56 bits each) in ECB mode. · AES KAT with a 128-bit key in ECB mode. · HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 KATs. · RSA KAT with 1024-bit keys for signature generation/verification and encryption/decryption. · ANSI X9.31 RNG KAT. · Pair-wise consistency test for DSA. In the FIPS mode, the following three conditional self-test are performed by the module. · Pair-wise consistency test for RSA keys. This test is performed when a new RSA key-pair is generated. · Pair-wise consistency test for DSA keys. This test is performed when a new DSA key-pair is generated. · Continuous RNG Test. This test is performed when a new random number is generated. The new random number generated by the RNG is compared with the previous random number generated by the RNG. If the two numbers are equal, then the test fails. If the self-tests fail, an exception will be thrown on the failure. The application is then alerted that the self-tests failed, and the module will not load and will enter an error state. When in the error state, execution of the module is halted and data output from the module is inhibited. Sterling Crypto-C Page 15 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 2.8 Design Assurance Sterling Commerce uses the Concurrent Versions System (CVS) version 1.1.22 for configuration management of source code and documentation. See the CVS project website http://www.nongnu.org/cvs/ for more information. Additionally, Microsoft Visual SourceSafe (VSS) version 6.0 is used to provide configuration management for the Sterling Crypto-C's FIPS documentation. This software provides access control, versioning, and logging. 2.9 Mitigation of Other Attacks This section is not applicable. No claim is made that the module mitigates against any attacks beyond the FIPS 140- 2 level 1 requirements for this validation. Sterling Crypto-C Page 16 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 3 Secure Operation Sterling Crypto-C meets Level 1 requirements for FIPS 140-2. The sections below describe how to place and keep the module in the FIPS mode of operation. 3.1 Crypto Officer Guidance The Crypto Officer is responsible for installing, uninstalling, configuring, and managing the module and running the power-up self-tests. 3.1.1 Single User Configuration The user of the module is a software application. FIPS 140-2 mandates that a cryptographic module be limited to a single user at a time. To meet this requirement, a single instantiation of an application must only access a single instantiation of Sterling Crypto-C. For enhanced security, it is recommended that the Crypto Officer configure the OS to disallow remote login. See the following instructions for details. Windows Server 2003: To configure Windows Server 2003 to disallow remote login, the Crypto Officer should ensure that all remote guest accounts are disabled in order to ensure that only one human operator can log into the Windows OS at a time. The services that need to be turned off for Windows are · Fast-user switching (irrelevant if server is a domain member) · Terminal services · Remote registry service · Secondary logon service · Telnet service · Remote desktop and remote assistance service Once the Windows OS has been configured to disable remote login, the Crypto Officer can use the system "Administrator" account to install software, uninstall software, and administer the module. Sun Solaris: The specific procedure to configure Solaris to disable remote login is described below: 1. Login as the "root" user. 2. Edit the system files /etc/passwd and /etc/shadow and remove all the users except "root" and the pseudo- users (daemon users). Make sure the password fields in /etc/shadow for the pseudo-users are either a star (*) or double exclamation mark (!!). This prevents login as the pseudo-users. Also make sure the shell for daemon users is /dev/null, or something else that is not exploitable. 3. Edit the system file /etc/nsswitch.conf and make "files" the only option for "passwd", "group", and "shadow". This disables Network Information Service (NIS) and other name services for users and groups. 4. Edit the system file /etc/inet/inetd.conf, and comment out all unnecessary services (by prepending a hash ('#') sign to the beginning of each unnecessary service line). sadmind - Solstice network administration agent server rpc.ttdbserverd - Sun tool-talk server Sterling Crypto-C Page 17 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 kcms_server - Kodak Color Management System server fs.auto - Sun font server cachefsd - Network File System (NFS) cache service rquotad - remote disk quota server rpc.metad - Disksuite remote metaset service rpc.metamhd - Disksuite remote multihost service rpc.metamedd - Disksuite component service ocfserv - Smartcard service dtspcd - Part of the Common Desktop Environment (CDE) package rpc.cmsd - remote calendar server in.comsat - biff, mail notification server in.talkd - talk server gssd - Remote Procedure Call (RPC) application authentication in.tnamed - deprecated name server rpc.smserverd - removable media device sensor service (disabling requires manual CD mounting) dcs - remote dynamic configuration server ftpd - File Transfer Protocol server ktkt_warnd - Kerberos warning server chargen - deprecated network service daytime - deprecated network time time - legacy time service discard - deprecated network service echo - network 'echo' service ufsd - part of RPC in.uucpd - unix-to-unix copy server 5. Disable service startup scripts within /etc/rc2.d. Many additional services (not bound to inetd) are started by default. To disable startup scripts, files can be renamed to make sure they do not begin with a capital `S' (which denotes Startup). Disable startup scripts that are not pertinent to the setup. nscd - NIS-related snmpdx - Simple Network Management Protocol (SNMP) services cachefs.daemon - NFS-caching rpc - Remote Procedure Call services sendmail ­ Sendmail lp - line printer daemon pppd - Point-to-point Protocol services uucp - Unix-to-Unix copy daemon ldap - Lightweight Directory Access Protocol (LDAP) services 6. Reboot the system for the changes to take effect. Once the operating system has been configured to disable remote login, the Crypto Officer can use the system "root" account to install/uninstall software and administer the module. IBM AIX: The specific procedure to configure IBM AIX to disable remote login is described below: 1. Log in as the "root" user. 2. Edit the system file /etc/passwd and remove all the users except "root" and the pseudo-users. Make sure that for the pseudo-users, either the password fields are a star (*) or the login shell fields are empty. This prevents login as the pseudo-users. Sterling Crypto-C Page 18 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 3. Remove all lines that begin with a plus sign (+) or minus sign (-) from /etc/passwd and /etc/group. This disables NIS and other name services for users and groups. 4. Edit the system file /etc/inetd.conf. Remove or comment out the lines for remote login, remote command execution, and file transfer daemons such as telnetd, rlogind, krlogind, rshd, krshd, rexecd, ftpd, and tftpd. 5. Reboot the system for the changes to take effect. Once the operating system has been configured to disable remote login, the Crypto Officer can use the system "root" account to install/uninstall software and administer the module. HP-UX: The specific procedure to configure HP-UX to disable remote login is described below: 1. Log in as the "root" user. 2. Edit the system file /etc/passwd and remove all the users except "root" and the pseudo-users. Make sure the password fields for the pseudo-users are a star (*). This prevents login as the pseudo-users. 3. Edit the system file /etc/nsswitch.conf. Make sure that "files" is the only option for "passwd" and "group". This disables NIS and other name services for users and groups. 4. Edit the system file /etc/inetd.conf. Remove or comment out the lines for remote login, remote command execution, and file transfer daemons such as telnetd, rlogind, remshd, rexecd, ftpd, and tftpd. 5. Reboot the system for the changes to take effect. Once the operating system has been configured to disable remote login, the Crypto Officer can use the system "root" account to install/uninstall software and administer the module. 3.1.2 Initialization The Sterling Crypto-C software module itself is not an end-user product. It is provided to the end-users as part of the application. The module is installed during installation of the application. The installation procedure is described in the installation manual for the application. A single initialization call to FIPS_mode_set(1) is required to initialize the module for operation in the FIPS mode. The module is not in the FIPS mode until FIPS_mode_set(1) is successfully called. On AIX, Solaris, and HP-UX, before calling FIPS_mode_set(1), an environment variable, SCI_CRYPTOC_LIBPATH, must be set to the location of the libraries and the corresponding HMAC file. This variable should not need to be set on Windows. If it is, it will override the location determined using GetModuleFilePath(). The function call to FIPS_mode_set(1) must be made by the application to place the module in the FIPS mode of operation. Each time the application is executed, it must call FIPS_mode_set(1) if the application has been configured for the FIPS mode of operation. The Crypto Officer must include this specific call when he programs the application that uses the Sterling Crypto-C cryptographic module. Notice that DES is available in the FIPS mode of operation and must not be used in the FIPS mode. Use of DES will result in the module operating in a non-FIPS state. 3.1.3 Zeroization All CSPs are stored in volatile memory in plaintext. When no longer needed, CSPs contained within the module are deleted by overwriting the storage locations of CSPs with zeros. The Crypto Officer may manually invoke the zeroization by rebooting the computer on which the module is running. Sterling Crypto-C Page 19 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 3.1.4 Management The Crypto Officer does not perform any management of the module after installation and configuration. The management tasks are conducted by the application. 3.2 User Guidance The module's cryptographic functionality and security services are provided via the application. End-users are not supposed to utilize the module without an associated application. Only the algorithms listed in Section 2.6 should be invoked by the application. End-user instructions and guidance are provided in the user manual and technical support documents of the application software. Although end-users do not have privileges to modify configurations of the module, they should make sure that the FIPS mode of operation is enforced in the application and thereby proper cryptographic protection is provided. Sterling Crypto-C Page 20 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 4 Acronyms Table 8 ­ Acronyms Acronym Definition AES Advanced Encryption Standard ANSI American National Standards Institute API Application Programming Interface BIOS Basic Input/Output System CBC Cipher Block Chaining CD Compact Disc CDE Common Desktop Environment CFB Cipher Feedback CMVP Cryptographic Module Validation Program CPU Central Processing Unit CSP Critical Security Parameter CVS Concurrent Versions System DLL Dynamic Link Library ECB Electronic Codebook DES Data Encryption Standard DSA Digital Signature Algorithm EMC Electromagnetic Compatibility EMI Electromagnetic Interference FCC Federal Communications Commission FIPS Federal Information Processing Standard HMAC (Keyed-) Hash MAC IDE Integrated Drive Electronics ISA Instruction Set Architecture KAT Known Answer Test LDAP Lightweight Directory Access Protocol MAC Message Authentication Code N/A Not Applicable NFS Network File System NIS Network Information System NIST National Institute of Standards and Technology OFB Output Feedback OS Operating System PCI Peripheral Component Interconnect Sterling Crypto-C Page 21 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Non-Proprietary Security Policy, Version 1.0 January 9, 2008 Acronym Definition PKCS Public Key Cryptography Standard RAM Random Access Memory RISC Reduced Instruction Set Computer RNG Random Number Generator ROM Read Only Memory RPC Remote Procedure Call RSA Rivest, Shamir, and Adleman SHA Secure Hash Algorithm SNMP Simple Network Management Protocol SO Shared Object TDES Triple Data Encryption Standard TLS Transport Layer Security USB Universal Serial Bus VSS Visual SourceSafe Sterling Crypto-C Page 22 of 22 © 2008 Sterling Commerce, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice.