Symantec Corporation Symantec Cross-Platform Cryptographic Module SW Version: 1.0 FIPS 140-2 Non-Proprietary Security Policy FIPS Security Level: 1 Document Version: 1.0 Prepared for: Prepared by: Symantec Corporation Corsec Security, Inc. 350 Ellis Street 13135 Lee Jackson Memorial Hwy, Suit 220 Mountain View, CA 94043 Fairfax, VA 22033 United States of America United States of America Phone: +1 (650) 527-8000 Phone: +1 (703) 267-6050 http://www.symantec.com http://www.corsec.com Security Policy, Version 1.0 August 24, 2011 Table of Contents 1 INTRODUCTION ................................................................................................................... 4 1.1 PURPOSE ................................................................................................................................................................ 4 1.2 REFERENCES .......................................................................................................................................................... 4 1.3 DOCUMENT ORGANIZATION ............................................................................................................................ 4 2 SYMCPM .................................................................................................................................. 5 2.1 OVERVIEW ............................................................................................................................................................. 5 2.1.1 Symantec Security Information Manager .......................................................................................................5 2.1.2 Symantec Cross-Platform Cryptographic Module Security ........................................................................7 2.2 MODULE SPECIFICATION ..................................................................................................................................... 7 2.2.1 Physical Cryptographic Boundary ......................................................................................................................8 2.2.2 Logical Cryptographic Boundary ........................................................................................................................8 2.3 MODULE INTERFACES .......................................................................................................................................... 9 2.4 ROLES AND SERVICES .........................................................................................................................................10 2.4.1 Crypto Officer Role ............................................................................................................................................. 11 2.4.2 User Role ................................................................................................................................................................ 11 2.5 PHYSICAL SECURITY ...........................................................................................................................................15 2.6 OPERATIONAL ENVIRONMENT.........................................................................................................................15 2.7 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................................................15 2.7.1 Key Generation..................................................................................................................................................... 17 2.7.2 Key Entry and Output ........................................................................................................................................ 18 2.7.3 Key/CSP Storage and Zeroization.................................................................................................................. 18 2.8 EMI/EMC ............................................................................................................................................................18 2.9 SELF-TESTS ..........................................................................................................................................................18 2.9.1 Power-Up Self-Tests ............................................................................................................................................ 18 2.9.2 Conditional Self-Tests ......................................................................................................................................... 19 2.10 MITIGATION OF OTHER ATTACKS ..................................................................................................................19 3 SECURE OPERATION ......................................................................................................... 20 3.1 INITIAL SETUP......................................................................................................................................................20 3.2 CRYPTO–OFFICER GUIDANCE .........................................................................................................................20 3.3 USER GUIDANCE ................................................................................................................................................20 4 ACRONYMS .......................................................................................................................... 21 Table of Figures FIGURE 1 – SYMANTEC SECURITY INFORMATION MANAGER WORKFLOW......................................................................5 FIGURE 2 – SSIM ARCHITECTURE OVERVIEW .......................................................................................................................6 FIGURE 3 – STANDARD GPC BLOCK DIAGRAM ...................................................................................................................8 FIGURE 4 – LOGICAL BLOCK DIAGRAM AND CRYPTOGRAPHIC BOUNDARY ..................................................................9 List of Tables TABLE 1 – SECURITY LEVEL PER FIPS 140-2 SECTION .........................................................................................................7 TABLE 2 – FIPS 140-2 INTERFACE MAPPINGS .......................................................................................................................9 TABLE 3 – CRYPTO OFFICER SERVICES ................................................................................................................................ 11 TABLE 4 – USER SERVICES FOR SLOT AND TOKEN MANAGEMENT ................................................................................. 11 TABLE 5 – USER SERVICES FOR SESSION MANAGEMENT ................................................................................................... 12 TABLE 6 – USER SERVICES FOR OBJECT MANAGEMENT .................................................................................................... 12 TABLE 7 – USER SERVICES FOR CRYPTOGRAPHIC SERVICES ............................................................................................. 13 TABLE 8 – LEGACY USER SERVICES ...................................................................................................................................... 15 TABLE 9 – FIPS-APPROVED ALGORITHM IMPLEMENTATIONS .......................................................................................... 16 Symantec Cross-Platform Cryptographic Module Page 2 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 TABLE 10 – LIST OF CRYPTOGRAPHIC KEYS, KEY COMPONENTS, AND CSPS .............................................................. 16 TABLE 11 – ACRONYMS ........................................................................................................................................................ 21 Symantec Cross-Platform Cryptographic Module Page 3 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the Symantec Cross-Platform Cryptographic Module from Symantec Corporation. This Security Policy describes how the Symantec Cross-Platform Cryptographic Module meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-2, which 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) and the Communications Security Establishment Canada (CSEC) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/groups/STM/cmvp. This document also describes how to run the module in a secure FIPS-Approved mode of operation. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. The Symantec Cross- Platform Cryptographic Module is referred to in this document as SymCPM, the cryptographic module, or the module. 1.2 References This document deals only with 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 Symantec website (http://www.symantec.com) contains information on the full line of products from Symantec. • The CMVP website (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm) contains contact information for individuals to answer 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 Document • Finite State Model • Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to Symantec. With the exception of this Non-Proprietary Security Policy, the FIPS 140- 2 Submission Package is proprietary to Symantec and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact Symantec. Symantec Cross-Platform Cryptographic Module Page 4 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 2 SymCPM This section describes the Symantec Cross-Platform Cryptographic Module from Symantec Corporation. 2.1 Overview As one of the world’s largest software companies, Symantec offers a comprehensive portfolio of security, storage, and systems management solutions. Symantec has a customer base that includes 99% of Fortune 1000 companies. It also has a broad range of product offerings that range from consumer virus protection to enterprise class Security Operation Centers (SOCs) that are staffed 24/7. Through their software and services, they help consumers and organizations protect information and infrastructure against more risks at more points, more completely and efficiently than any other company. With an arsenal that includes engineering centers, global patents, and cutting-edge research, customers can have what only a global leader like Symantec can provide - confidence in a connected world. 2.1.1 Symantec Security Information Manager The first Symantec solution to take advantage of SymCPM is the Symantec Security Information Manager. SSIM is a high availability enterprise class software solution, whose primary purpose is to preempt or detect security incidents while providing the framework to both respond and demonstrate compliance. SSIM accomplishes this through its integrated log management, distributed architecture, and automated updates from Symantec’s Global Information Network (GIN), which offers real-time intelligence on the latest vulnerabilities and threats from around the world. SSIM collects security information, called events, from a broad range of applications, services, and security products. It then converts that information into actionable intelligence by using its built-in asset management function for prioritization, and then applying its sophisticated rule-based correlation engine on a normalized event stream. Event data is easily managed and quickly retrieved using SSIM’s specialized form of event detail storage, which uses proprietary indexing and compression. Large amounts of diverse event data can be centralized in online or archived event stores using direct-attached storage (DAS), network-attached storage (NAS) or storage area network (SAN). SSIM also embeds a high performance relational database to store both summarized events and data pertaining to incidents, tickets, assets, rules, vulnerabilities, workflow, and reports. This allows for trend reporting and custom SQL1 queries, with drill down capability into the appropriate event archives. Figure 1 – Symantec Security Information Manager Workflow 1 SQL – Structured Query Language Symantec Cross-Platform Cryptographic Module Page 5 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 The SSIM solution consists of the following major components: • Information Manager – comprises the core functionality of a SSIM deployment. It installs on a standard server platform that supports RHEL (Red Had Enterprise Linux). It aggregates and processes event data for correlation, incident management, and archival. It also consists of a comprehensive report engine and an embedded LDAP (Lightweight Directory Access Protocol) directory for centralized access control and multi-domain management. The various roles of the Information Manager (Collection, Correlation, Archival, and Service Provider) can be distributed in local clusters and then federated for fail safety, higher scalability, and global deployments. • Event Collector – gathers and filters events from event sources. Collectors are installed directly on a security point product or in strategic locations with access to security events. They use application specific sensors that retrieve events from a file, database, or syslog. SSIM provides multi-vendor support with over 200 predefined collectors for popular products. It also has universal collectors that can be customized for unique event sources. • Event Agent – handles the communication path between event collectors and the Information Manager. It is a Java-based application that is installed alongside each collector. The agent forwards both raw event data and events that have been filtered and aggregated. • Information Manager Console – provides a bidirectional administrative GUI2 to the Information Manager. It is a Java-based application used by administrators, analysts, and service desk systems to perform security monitoring functions, such as incident management, reports, and rule definition. It presents both high-level and detailed views of critical security information. • Web Configuration Interface and OpenSSH – provide administrative access to the Information Manager server via a web browser or a remote secure shell (SSH) connection. Figure 2 – SSIM Architecture Overview 2 GUI – Graphical User Interface Symantec Cross-Platform Cryptographic Module Page 6 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 2.1.2 Symantec Cross-Platform Cryptographic Module Security The Symantec Cross-Platform Cryptographic Module, SymCPM, is a general-purpose cryptographic library that resides on various Symantec application components, including SSIM’s Event Agent and the Information Manager server and console. It provides the cryptographic services required by TLS3 for secure communication between SSIM components. The module includes implementations of the following FIPS-Approved algorithms: • Advanced Encryption Standard (AES) • Triple Data Encryption Algorithm (TDEA or Triple-DES4) • Secure Hash Algorithm (SHA) • (Keyed-) Hash Message Authentication Code (HMAC) • Digital Signature Algorithm (DSA) • RSA5 signature generation and verification • SP 800-90 Deterministic Random Bit Generator (DRBG) The Symantec Cross-Platform Cryptographic Module operates in either a FIPS Approved or non-FIPS Approved mode of operation. It 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 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 6 8 EMI/EMC 1 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A 2.2 Module Specification The Symantec Cross-Platform Cryptographic Module is a software module with a multi-chip standalone embodiment. The overall security level of the module is 1. SymCPM is implemented in the C programming language and consists of shared libraries that are linked with SSIM application components. It is designed to execute on a host system with a General Purpose Computer (GPC) hardware platform. The following sections define the physical and logical boundary of the SymCPM module. 3 TLS – Transport Layer Security 4 DES – Data Encryption Standard 5 RSA – Rivest, Shamir, Adleman 6 EMI/EMC – Electromagnetic Interference / Electromagnetic Compatibility Symantec Cross-Platform Cryptographic Module Page 7 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 2.2.1 Physical Cryptographic Boundary As a software cryptographic module, there are no physical protection mechanisms implemented. Therefore, the module must rely on the physical characteristics of the host system. The physical boundary of the cryptographic module is defined by the hard enclosure around the host system on which it runs. The module supports the physical interfaces of a GPC, including the integrated circuits of the system board, the CPU, network adapters, RAM, hard disk, device case, power supply, and fans. Other devices may be attached to the GPC, such as a display monitor, keyboard, mouse, printer, or storage media. See Figure 3 below for a standard GPC block diagram. Figure 3 – Standard GPC Block Diagram 2.2.2 Logical Cryptographic Boundary Figure 4 shows a logical block diagram of the module executing in memory and its interactions with surrounding software components, as well as the module’s logical cryptographic boundary. The module’s services are designed to be called by other Symantec software components. SymCPM v1.0 is composed of 3 files for the Windows and RHEL operating systems, and 5 files for the Solaris operating system. Symantec Cross-Platform Cryptographic Module Page 8 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 Figure 4 – Logical Block Diagram and Cryptographic Boundary 2.3 Module Interfaces The module’s logical interfaces exist at a low level in the software as an Application Programming Interface (API). Both the API and physical interfaces can be categorized into following interfaces defined by FIPS 140-2: Data Input, Data Output, Control Input, and Status Output. A mapping of the FIPS 140-2 logical interfaces, the physical interfaces, and the module interfaces can be found in Table 2 below. Table 2 – FIPS 140-2 Interface Mappings FIPS Interface Physical Interface Module Interface (API) Data Input USB ports (keyboard, Arguments for library functions that specify plaintext mouse, data), network data, ciphertext, digital signatures, cryptographic keys ports, serial ports, (plaintext or encrypted), initialization vectors, and SCSI/SATA ports, DVD passwords that are to be input to and processed by the drive cryptographic module. Data examples: • pointers (to contexts, structures, variables, data locations, session handles, object handles, signatures, plaintext, ciphertext, message digests, object templates, etc.) • sizes of various data (encrypted data, recovered plaintext, RSA modulus ,signature, MAC, shared secret, digests, blocks) • type values (user, slot, mechanism) • slot IDs • flag values Symantec Cross-Platform Cryptographic Module Page 9 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 FIPS Interface Physical Interface Module Interface (API) Data Output Monitor, USB ports, Arguments for library functions that receive plaintext network ports, serial ports, data, ciphertext data, digital signatures, cryptographic SCSI/SATA ports, audio keys (plaintext or encrypted), and initialization vectors ports, DVD drive from the cryptographic module. Data examples: • pointers (to contexts, structures, variables, data locations, signatures, plaintext, ciphertext, message digests, etc.) • keys • random strings • token, object, slot, or mechanism information Control Input USB ports (keyboard, Arguments for library functions that initiate and control mouse), network ports, the operation of the module, such as arguments that serial ports, power switch specify commands and control data (e.g., algorithms, algorithm modes, digest type, or module settings). Status Output Monitor, network ports, Function return codes, error codes, or output serial ports arguments that receive status information used to indicate the status of the cryptographic module. Status information may be: • integer values that indicates success or failure • a NULL value that indicates success or failure • flag values Power Input Power Interface N/A 2.4 Roles and Services The Symantec Cross-Platform Cryptographic Module supports the following two roles for operators, as required by FIPS 140-2: Crypto-Officer (CO) role and User role. Both roles are implicitly assumed when services that do not require a login are executed. Although the module employs authentication mechanisms, it should be noted that the module only claims Security Level 1 for this section. SymCPM uses role-based authentication to control access to services that require access to sensitive CSPs. To perform these sensitive services, an operator must log into the module by authenticating with a password. The password is initialized by the CO as part of module initialization. When performing any service that requires login, an operator must explicitly request to assume the appropriate role by authenticating to the module using a password. The logical interface of SymCPM consists of the PKCS #11API, also called Cryptoki or the “cryptographic token interface”. The module implements three PKCS #11 tokens: two tokens for the non-FIPS Approved mode of operation, and one token for the FIPS Approved mode of operation. The FIPS token is designed specifically for FIPS 140-2, and allows applications using the module to operate using only FIPS Approved functions. The services listed in the following tables correspond to the functions available in PKCS #11. Note 1: Table 3 through Table 8 use the following definitions for “CSP7 and Type of Access”. R – Read: The plaintext CSP is read by the service. W – Write: The CSP is established, generated, modified, or zeroized by the service. X – Execute: The CSP is used within an Approved (or allowed) security function or authentication mechanism. Z – Zerioze: The CSP is zeroized with an Approved security function 7 CSP – Critical Security Parameter Symantec Cross-Platform Cryptographic Module Page 10 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 Note 2: The “Input” and “Output” columns are with respect to the module’s logical boundary. 2.4.1 Crypto Officer Role The operator in the Crypto Officer role installs, uninstalls, and administers the module via the host platform’s OS interfaces. An operator assumes the CO role by invoking one of the following services: Table 3 – Crypto Officer Services Service Description Input Output CSP Access FC_GetFunctionList Return a list of PKCS#11 function API call Status None pointers for FIPS mode services parameters C_InitToken Initialize or reinitialize a token by API call Status All – W clearing the key database and parameters removing the password C_InitPIN Set a user’s initial password. Password, API Status Password – WZ Login required. call parameters C_Initialize Load and initialize the module, API call Status None perform power-up self-tests – parameters enter FIPS mode C_Finalize Shutdown and unload the module API call Status All – WZ library – leave FIPS mode parameters C_GetInfo Obtain general information about API call Data, None module library parameters status 2.4.2 User Role The operator in the User role is a consumer of the module’s security services. All cryptographic and general-purpose services are available to the User except those that perform an installation function. The role is assumed by invoking a service listed in the tables below. Table 4 – User Services for Slot and Token Management Service Description Input Output CSP Access C_GetSlotList Obtain a list of available slots API call Data, status None parameters C_GetSlotInfo Obtain information about a API call Data, status None particular slot parameters C_GetTokenInfo Obtain information (show API call Data, status None status) about a token parameters C_GetMechanismList Obtain a list of crypto API call Data, status None algorithms (mechanisms) parameters supported by a token C_GetMechanismInfo Obtain information about a API call Data, status None mechanism parameters C_SetPIN Change a user’s password. Old password, New password, Password – WX Login required. API call status parameters Symantec Cross-Platform Cryptographic Module Page 11 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 Table 5 – User Services for Session Management Service Description Input Output CSP Access C_OpenSession Open a session between an API call Status None application and a token parameters C_CloseSession Close a session API call Status All keys – WZ parameters C_CloseAllSessions Close all sessions with a token API call Status All keys – WZ parameters C_GetSessionInfo Obtain information (show API call Status None status) about a session parameters C_GetOperationState Save the state of a session’s API call Data, None digest operation parameters status C_SetOperationState Restore the state of a API call Status None session’s digest operation parameters C_Login Log into a token Password, API Status Password – X call parameters C_Logout Log out from a token. Login API call Status None required. parameters Table 6 – User Services for Object Management Service Description Input Output CSP Access C_CreateObject Create an object. Login API call Data, key, All keys – W required. parameters status C_CopyObject Create a copy of an object. Key, API call Data, key, All keys – RW Login required. parameters status C_DestroyObject Destroy an object. Login Key, API call Status All keys – WZ required. parameters C_GetObjectSize Obtain the size of an object Key, API call Data, All keys – R in bytes. Login required. parameters status C_GetAttributeValue Obtain an attribute value of Key, API call Data, All keys – R an object. Login required. parameters status C_SetAttributeValue Modify an object’s attribute Key, API call Data, key, All keys – W value. Login required. parameters status C_FindObjectsInit Initialize an object search API call Status None operation. Login required. parameters C_FindObjects Continue an object search Key, API call Data, key, All keys – R operation. Login required. parameters status C_FindObjectsFinal Finish an object search API call Status None operation. Login required. parameters Symantec Cross-Platform Cryptographic Module Page 12 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 Table 7 – User Services for Cryptographic Services Service Description Input Output CSP Access C_EncryptInit Initialize an encryption Key, API call Status AES key – R operation. Login required. parameters TDES key – R C_Encrypt Encrypt single-part data. Plaintext, API Status, AES key – X Login required. call parameters ciphertext TDES key – X C_EncryptUpdate Continue a multi-part Plaintext, API Status, AES key – X encryption. Login required. call parameters ciphertext TDES key – X C_EncryptFinal Finish a multi-part Plaintext, API Status, AES key – X encryption. Login required. call parameters ciphertext TDES key – X C_DecryptInit Initialize a decryption Key, API call Status AES key – R operation. Login required. parameters TDES key – R C_Decrypt Decrypt single-part data. Ciphertext, API Status, AES key – X Login required. call parameters plaintext TDES key – X C_DecryptUpdate Continue a multi-part Ciphertext, API Status, AES key – X decryption. Login required. call parameters plaintext TDES key – X C_DecryptFinal Finish a multi-part Ciphertext, API Status, AES key – X decryption. Login required. call parameters plaintext TDES key – X C_DigestInit Initialize a message-digest API call Status None operation using SHS8 parameters C_Digest Digest single-part data Message, API Status None call parameters C_DigestUpdate Continue a multi-part digest Message, API Status None call parameters C_DigestKey Continue a multi-part digest Key, API call Status AES key – R by digesting the value of a parameters TDES key – R secret key. Login required. HMAC key – R C_DigestFinal Finish a multi-part digest API call Status, None parameters digest C_SignInit Initialize a signature or MAC Key, API call Status RSA private – R operation. Login required. parameters DSA private – R HMAC key – R C_Sign Sign or MAC single-part data. Message, API Status HMAC key – X Login required. call parameters C_SignUpdate Continue a multi-part MAC Message, API Status HMAC key – X or signature. Login required. call parameters C_SignFinal Finish a multi-part MAC or API call Status, RSA private – X signature. Login required. parameters MAC, DSA private – X signature HMAC key – X C_SignRecoverInit Initialize a signature Key, API call Status RSA private – R operation with digest parameters DSA private – R recovery. Login required. 8 SHS – Secure Hash Standard Symantec Cross-Platform Cryptographic Module Page 13 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 Service Description Input Output CSP Access C_SignRecover Sign single-part data with Message, API Status, RSA private – X digest recovery. Login call parameters signature DSA private – X required. C_VerifyInit Initialize a verification Key, API call Status RSA public – R operation. Login required. parameters DSA public – R HMAC key – R C_Verify Verify a signature on single- MAC, API call Status RSA public – X part data. Login required. parameters, DSA public – X signature HMAC key – X C_VerifyUpdate MAC, API call Status RSA public – X Continue a multi-part verification. Login required. parameters, DSA public – X signature HMAC key – X C_VerifyFinal MAC, API call Status RSA public – X Finish a multi-part verification. Login required. parameters, DSA public – X signature HMAC key – X C_VerifyRecoverInit Initialize a verification Key, API call Status RSA public – R parameters DSA public – R operation with digest recovery. Login required. C_VerifyRecover Verify a signature on single- API call Status, RSA public – X parameters digest DSA public – X part data with digest recovery. Login required. C_DigestEncryptUpdate Continue a multi-part digest Digest, API call Status, AES key – X and encryption. Login parameters ciphertext TDES key – X required. C_DecryptDigestUpdate Continue a multi-part Ciphertext, API Status, AES key – X decryption and digest. Login call parameters digest TDES key – X required. C_SignEncryptUpdate Message, API Status, AES key – X Continue a multi-part signature and encryption. call parameters ciphertext, TDES key – X signature RSA public – X Login required. DSA public – X HMAC key – X C_DecryptVerifyUpdate Ciphertext, API Status, AES key – X Continue a multi-part call parameters, message TDES key – X decryption and verification. Login required. signature RSA public – X DSA public – X HMAC key – X C_GenerateKey Generate a secret key. Login API call Status, key AES key – W required. parameters TDES key – W HMAC key – W C_GenerateKeyPair Generate an asymmetric key API call Status, key RSA key pair – W pair. Login required. parameters pair DSA key pair – W C_WrapKey Wrap (encrypt) a key. Login Key, API call Status, AES key – R required. parameters ciphertext TDES key – R RSA public – X Symantec Cross-Platform Cryptographic Module Page 14 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 Service Description Input Output CSP Access C_UnwrapKey Unwrap (decrypt) a key. Ciphertext, API Status, key AES key – R Login required. call parameters TDES key – R RSA private – X Status, key DH9 – W C_DeriveKey Derive a key from a base API call key. Login required. parameters TLS master secret RNG10 seed C_SeedRandom Mix in additional seed API call Status material to the random parameters number generator C_GenerateRandom Generate random data API call Status, None parameters random data Table 8 – Legacy User Services Service Description Input Output CSP Access C_GetFunctionStatus Legacy function, which simply API call Status None returns the value parameters 0x00000051 C_CancelFunction Legacy function, which simply API call Status None returns the value parameters 0x00000051 2.5 Physical Security The Symantec Cross-Platform Cryptographic Module is a software module and does not include physical security mechanisms. Thus, the FIPS 140-2 requirements for physical security are not applicable. 2.6 Operational Environment The module was tested and found to be compliant with FIPS 140-2 requirements on the following platforms: • GPC running Windows 2003 Server 32-bit • GPC running RHEL 5 32-bit • GPC running Solaris 10 Symantec affirms that the module also executes in its FIPS-Approved manner (as described in this Security Policy) on other operating systems that are binary-compatible to those on which the module was tested. All cryptographic keys and CSPs are under the control of the operating system, which protects the CSPs against unauthorized disclosure, modification, and substitution. The module only allows access to CSPs through its well-defined API. 2.7 Cryptographic Key Management The module implements the following FIPS-Approved algorithms: 9 DH – Diffie-Hellman 10 RNG – Random Number Generator Symantec Cross-Platform Cryptographic Module Page 15 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 Table 9 – FIPS-Approved Algorithm Implementations Algorithm Certificate Number 11 AES in ECB , CBC modes with 128, 192, and 256 bit keys 1614 Triple-DES in ECB, CBC modes with 112 and 168 bit keys 1055 12 RSA (PKCS #1.5) sign/verify with 1024, 1536, 2048, 3072, 792 4096 bit keys DSA sign/verify and key generation with 1024 bit keys 502 SHA-1, SHA-256, SHA-384, SHA-512 1423 HMAC-SHA-1, HMAC-SHA-256, HMAC- SHA-384, 946 HMAC-SHA-512 SP 800-90 Hash_DRBG 83 The module utilizes the following non-Approved algorithms, which are allowed for use in a FIPS- Approved mode of operation: • RSA key wrapping (1024- to 8192-bit keys) o Key establishment methodology provides between 80 and 192 bits of encryption strength • Diffie-Hellman key agreement (1024- to 2236-bit keys) o Key establishment methodology provides between 80 and 112 bits of security • Message Digest 5 (MD5) o Message authentication for use within the TLS Key Derivation Function (KDF) Additionally, the module implements the following non-Approved algorithms, which are only available in a non-Approved mode of operation: • DES • Camellia • SEED • RC2 (Rivest Cipher 2) • RC4 (Rivest Cipher 4) • MD2 The CSPs supported by the module are shown in Table 10 below. Note: The “Input” and “Output” columns in Table 10 are in reference to the module’s logical boundary. Keys that enter and exit the module via an API call parameter can be in plaintext or ciphertext. Table 10 – List of Cryptographic Keys, Key Components, and CSPs CSP/Key Type CSP/Key Input Output Storage Zeroization Use AES key AES128-, 192-, API call parameter API call Plaintext By API call, Encryption, 256-bit key or internally parameter in volatile power cycle Decryption generated memory TDES key TDES 112-, 168- API call parameter API call Plaintext By API call, Encryption, bit key or internally parameter in volatile power cycle decryption generated memory 11 ECB – Electronic Codebook 12 PKCS – Public-Key Cryptography Standards Symantec Cross-Platform Cryptographic Module Page 16 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 CSP/Key Type CSP/Key Input Output Storage Zeroization Use HMAC key HMAC key API call parameter API call Plaintext By API call, Message or internally parameter in volatile power cycle Authentication generated memory with SHA-1 and SHA-2s RSA private RSA 1024-, 1536-, API call parameter API call Plaintext By API call, Signature key 2048-, 3072-, or internally parameter in volatile power cycle generation 4096-bit key generated memory RSA public RSA 1024-, 1536-, API call parameter API call Plaintext By API call, Signature key 2048-, 3072-, or internally parameter in volatile power cycle verification 4096-bit key generated memory DSA DSA 1024-bit key API call parameter API call Plaintext By API call, Signature private key or internally parameter in volatile power cycle generation generated memory DSA public DSA 1024-bit key API call parameter API call Plaintext By API call, Signature key or internally parameter in volatile power cycle verification generated memory DH public DH 1024-bit key API call parameter API call Plaintext By API call, Encryption, key or internally parameter in volatile power cycle Decryption generated memory DH private DH 1024-bit key API call parameter API call Plaintext By API call, Encryption, key or internally parameter in volatile power cycle Decryption generated memory DRBG seed 880-bit random Internally Never Plaintext By API call, Seed input to value generated in volatile power cycle SP 800-90 memory Hash_DRBG Hash Internal hash Internally Never Plaintext By API call, Used for SP DRBG V DRBG state value generated in volatile power cycle 800-90 value memory Hash_DRBG Hash Internal hash Internally Never Plaintext By API call, Used for SP DRBG C DRBG state value generated in volatile power cycle 800-90 value memory Hash_DRBG User password API call parameter API call Plaintext By API call, User password password parameter in volatile power cycle is used to log memory into the token Software DSA1024-bit Never Never Plaintext Memory Used to verify Integrity public in .chk file zeroization module key or volatile only by API integrity memory call 2.7.1 Key Generation Symmetric cryptographic keys are generated using the SP 800-90 Hash_DRBG. Asymmetric key pairs are generated using the methods specified in the PKCS #1 RSA Encryption Standard and in FIPS 186-2 (Digital Signature Standard) with Change Notice 1. Symantec Cross-Platform Cryptographic Module Page 17 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 2.7.2 Key Entry and Output The cryptographic module itself does not support key entry or key output from its physical boundary. However, keys are passed to the module as parameters from the applications resident on the host platform via the exposed APIs. Similarly, keys and CSPs exit the module in plaintext or ciphertext via the well- defined exported APIs. 2.7.3 Key/CSP Storage and Zeroization The module stores keys and CSPs in volatile memory, but does not persistently store any keys or CSPs on disk. Plaintext secret or private keys are zeroized when passed to the C_DestroyObject, C_CloseSession, or C_CloseAllSessions functions. All plaintext secret and private keys are automatically zeroized by the functions C_Finalize or C_InitToken. These services are the only services available to zeroize plaintext secret and private keys. All zeroization is performed by storing the value 0 into every byte of the memory region previously occupied by the plaintext secret key, private key, or password. 2.8 EMI/EMC SymCPM is a software module. Therefore, the only electromagnetic interference produced is that of the host platform on which SymCPM resides and executes. FIPS 140-2 requires that the host systems on which FIPS 140-2 testing is performed meet the Federal Communications Commission (FCC) EMI and EMC requirements for business use as defined in Subpart B, Class A of FCC 47 Code of Federal Regulations Part 15. However, all systems sold in the United States must meet these applicable FCC requirements. 2.9 Self-Tests The cryptographic module performs power-up and conditional self-tests listed in the sections below. If a self-test fails, the module will enter an error state. While in an error state, the module inhibits all data output and does not provide any cryptographic functionality until the error state is cleared. 2.9.1 Power-Up Self-Tests The Symantec Cross-Platform Cryptographic Module performs the following self-tests at power-up: • Software integrity test with DSA – A signature of the library is created using a DSA private key. The signature and public key are stored until the integrity test is executed. The public key is then used to create a new signature and verify it against the stored signature. The module will not initialize if any files have been modified. • Known Answer Tests (KATs) o SHS o HMAC-SHA1 o HMAC-SHA-256 o HMAC-SHA-384 o HMAC-SHA-512 o Triple-DES-CBC encrypt/decrypt o Triple-DES-ECB encrypt/decrypt o AES-CBC encrypt/decrypt o AES-ECB encrypt/decrypt o Hash_DRBG o RSA for signature generation and verification o RSA for encrypt/decrypt o DSA for signature generation and verification Symantec Cross-Platform Cryptographic Module Page 18 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 Upon successful completion of the power-up self-tests the module will return the CKR_OK status to the operator. Any error in the power-up self-tests will result in the CKR_DEVICE_ERROR status to be passed to the operator and the module will not be initialized. 2.9.2 Conditional Self-Tests The Symantec Cross-Platform Cryptographic Module performs the following conditional self-tests: • Continuous RNG test • RSA pairwise consistency for sign/verify and encrypt/decrypt • DSA pairwise consistency Upon successful completion of the conditional self-tests the module will return the CKR_OK status to the operator. Any error in the conditional self-tests will result in the CKR_DEVICE_ERROR or CKR_GENERAL_ERROR status to be passed to the operator. Module operation will be inhibited. 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. Symantec Cross-Platform Cryptographic Module Page 19 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 3 Secure Operation The Symantec Cross-Platform Cryptographic Module meets Level 1 requirements for FIPS 140-2. The sections below describe how to place and keep the module in FIPS-approved mode of operation. 3.1 Initial Setup The shared libraries and the associated .chk files should be installed in a directory on the shared library search path. SymCPM requires the Netscape Portable Runtime (NSPR) libraries which should also be installed in a directory on the shared library search path. The default mode of operation for the module is non-FIPS. To place the module in FIPS Approved mode, the SSIM software application must call FC_GetFunctionList to obtain the list of FIPS function pointers. The C_Initialize call initializes the module and performs power-up self-tests, including an integrity test using a DSA signature. If the module passes all self-tests, the module is in a FIPS-Approved mode of operation, and subsequent calls to the module’s API using the obtained function pointer list will select the FIPS Approved mode of operation 3.2 Crypto–Officer Guidance FIPS 140-2 mandates that a software cryptographic module at Security Level 1 be restricted to a single operator mode of operation. Prior to installing the module, the Crypto-Officer must ensure the host system OS is configured for single-user mode. To configure the Windows OS for single-user mode, the Crypto-Officer must ensure that all remote guest accounts are disabled in order to ensure that only one 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 The following explains how to configure a RHEL system for single-user mode. • Remove all login accounts except “root” (the superuser). • Disable NIS and other name services for users and groups. • Turn off all remote login, remote command execution, and file transfer daemons. In order to configure Solaris for single-user mode, the Crypto-Officer must type boot –s at the OK prompt or edit /boot/grub/menu.lst to set the single-user mode boot option. Self-tests can be performed by the function calls C_Finalize followed by C_Initialize. This sequence executes the same power-up self-tests as when the module library for the FIPS Approved mode. 3.3 User Guidance The SymCPM module is designed for use by Symantec software applications. SymCPM does not input, output, or persistently store CSPs with respect to the physical boundary. The User (Symantec software component, in this case) is responsible for providing persistent storage of the cryptographic keys and CSPs, and to ensure that keys are transmitted outside the physical cryptographic boundary in a secure manner only using FIPS-Approved algorithms like RSA. Symantec Cross-Platform Cryptographic Module Page 20 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 4 Acronyms Table 11 – Acronyms Acronym Definition AES Advanced Encryption Standard API Application Programming Interface BIOS Basic Input/Output System CBC Cipher Block Chaining CMVP Cryptographic Module Validation Program CO Crypto Officer CPU Central Processing Unit CSEC Communications Security Establishment Canada CSP Critical Security Parameter DAS Direct-Attached Storage DES Data Encryption Standard DH Diffie-Hellman DRBG Deterministic Random Bit Generator DSA Digital Signature Algorithm DVD Digital Video Disc ECB Electronic Code Book EMC Electromagnetic Compatibility EMI Electromagnetic Interference FCC Federal Communications Commission FIPS Federal Information Processing Standard GIN Global Information Network GPC General Purpose Computer GUI Graphical User Interface HDD Hard Disk Drive HMAC (Keyed-) Hash Message Authentication Code IDS Intrusion Detection System IPS Intrusion Prevention System KAT Known Answer Test KDF Key Derivation Function LDAP Lightweight Directory Access Protocol MAC Message Authentication Code Symantec Cross-Platform Cryptographic Module Page 21 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 August 24, 2011 Acronym Definition MD Message Digest NAS Network-Attached Storage NIST National Institute of Standards and Technology NSPR Netscape Portable Runtime NSS Network Security Services NVLAP National Voluntary Laboratory Accreditation Program OS Operating System PCI Peripheral Component Interconnect PCIe Peripheral Component Interconnect Express PKCS Public-Key Cryptography Standards PRNG Pseudo Random Number Generator RAM Random Access Memory RC Rivest Cipher RHEL Red Hat Enterprise Linux RNG Random Number Generator RSA Rivest, Shamir, and Adleman SAN Storage Area Network SATA Serial Advanced Technology Attachment SCSI Small Computer System Interface SHA Secure Hash Algorithm SHS Secure Hash Standard SOC Security Operations Center SP Special Publication SQL Structured Query Language SSH Secure Shell SSIM Symantec Security Information Manager TDEA Triple Data Encryption Algorithm TLS Transport Layer Security USB Universal Serial Bus Symantec Cross-Platform Cryptographic Module Page 22 of 23 © 2011 Symantec Corporation This document may be freely reproduced and distributed whole and intact including this copyright notice. Prepared by: Corsec Security, Inc. 13135 Lee Jackson Memorial Hwy, Suite 220 Fairfax, VA 22033 United States of America Phone: +1 (703) 267-6050 Email: info@corsec.com http://www.corsec.com