Symantec Corporation Symantec Enterprise Vault Cryptographic Module - NIST

Transcription

Symantec CorporationSymantec Enterprise Vault Cryptographic ModuleSW Version: 1.0FIPS 140–2 Non–Proprietary Security PolicyFIPS Security Level: 1Document Version: 1Prepared for:Prepared by:Symantec Corporation350 Ellis Street.Mountain View, CA 94043United States of AmericaCorsec Security, Inc.10340 Democracy Lane, Suite 201Fairfax, VA 22030United States of AmericaPhone: 1 (650) 527-8000http://www.symantec.comPhone: 1 (703) 267–6050http://www.corsec.com

Security Policy, Version 1May 4, 2011Table of Contents1INTRODUCTION . 41.1 PURPOSE . 41.2 REFERENCES . 41.3 DOCUMENT ORGANIZATION . 42EV CRYPTOGRAPHIC MODULE . 5THIS SECTION DESCRIBES THE SYMANTEC ENTERPRISE VAULT (EV) CRYPTOGRAPHIC MODULE FROMSYMANTEC CORPORATION. . 52.1 OVERVIEW . 52.1.1 Symantec Enterprise Vault .52.1.2 Enterprise Vault Cryptographic Module .72.2 MODULE SPECIFICATION . 82.2.1 Physical Cryptographic Boundary .82.2.2 Logical Cryptographic Boundary .92.3 MODULE INTERFACES .102.4 ROLES AND SERVICES .112.4.1 Crypto–Officer Role . 112.4.2 User Role . 122.5 PHYSICAL SECURITY .132.6 OPERATIONAL ENVIRONMENT.132.7 CRYPTOGRAPHIC KEY MANAGEMENT .132.7.1 Key Generation. 152.7.2 Key Entry and Output . 162.7.3 Key/CSP Storage and Zeroization. 162.8 EMI/EMC .162.9 SELF–TESTS.162.9.1 Power–Up Self–Tests . 162.9.2 Conditional Self–Tests . 172.10 MITIGATION OF OTHER ATTACKS .173SECURE OPERATION . 183.1 INITIAL SETUP.183.2 CRYPTO–OFFICER GUIDANCE .183.3 USER GUIDANCE .184ACRONYMS . 19Table of FiguresFIGURE 1 – SYMANTEC ENTERPRISE VAULT SYSTEM OVERVIEW .6FIGURE 2 – EV ARCHIVING PROCESS.6FIGURE 3 – USERS ACCESSING EV ARCHIVES .7FIGURE 4 – STANDARD GPC BLOCK DIAGRAM .9FIGURE 5 – LOGICAL BLOCK DIAGRAM AND CRYPTOGRAPHIC BOUNDARY . 10List of TablesTABLE 1 – SECURITY LEVEL PER FIPS 140–2 SECTION.7TABLE 2 – FIPS 140–2 INTERFACE MAPPINGS . 11TABLE 3 – CRYPTO–OFFICER SERVICES . 12TABLE 4 – USER SERVICES . 12TABLE 5 – FIPS–APPROVED ALGORITHM IMPLEMENTATIONS (WINDOWS SERVER 2003 SP2) . 13Symantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 2 of 21

Security Policy, Version 1May 4, 2011TABLE 6 – FIPS–APPROVED ALGORITHM IMPLEMENTATIONS (WINDOWS SERVER 2008 R2) . 14TABLE 7 – LIST OF CRYPTOGRAPHIC KEYS, KEY COMPONENTS, AND CSPS . 15TABLE 8 – ACRONYMS . 19Symantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 3 of 21

Security Policy, Version 11May 4, 2011Introduction1.1 PurposeThis is a non–proprietary Cryptographic Module Security Policy for the Symantec Enterprise Vault (EV)Cryptographic Module from Symantec Corporation. This Security Policy describes how the SymantecEnterprise Vault Cryptographic Module meets the security requirements of Federal Information ProcessingStandards (FIPS) Publication 140–2, which details the U.S. and Canadian Government requirements forcryptographic modules. More information about the FIPS 140–2 standard and validation program isavailable on the National Institute of Standards and Technology (NIST) and the Communications SecurityEstablishment Canada (CSEC) Cryptographic Module Validation Program (CMVP) website athttp://csrc.nist.gov/groups/STM/cmvp.The Symantec Enterprise Vault Cryptographic Module is referred to in this document as the EnterpriseVault Cryptographic Module, the cryptographic module, or the module. This policy was prepared as partof the Level 1 FIPS 140–2 validation of the module.1.2 ReferencesThis document deals only with operations and capabilities of the module in the technical terms of a FIPS140–2 cryptographic module security policy. More information is available on the module from thefollowing sources: The Symantec website (http://www.symantec.com) contains information on the full line ofproducts from Symantec. The CMVP website 0–1/140val–all.htm)contains contact information for individuals to answer technical or sales–related questions for themodule.1.3 Document OrganizationThe Security Policy document is one document in a FIPS 140–2 Submission Package. In addition to thisdocument, the Submission Package contains: Vendor Evidence Document Finite State Model Other supporting documentation as additional referencesThis 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 FIPS140–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 Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 4 of 21

Security Policy, Version 12May 4, 2011EV Cryptographic ModuleThis section describes the Symantec Enterprise Vault (EV) Cryptographic Module from SymantecCorporation.2.1 OverviewSymantec provides a broad range of Information Technology (IT) products and services that helporganizations to efficiently manage resources, maximize performance, and minimize security risks.Symantec’s product offerings are classified into the following product categories: Security; InformationRisk and Compliance; Storage; Infrastructure Operations; and Business Continuity. Symantec, one of thelargest makers of security and storage management software, has received recognition as a global leader bya number of research organizations including Gartner and Forrester.2.1.1 Symantec Enterprise VaultSymantec Enterprise Vault is a content archiving platform that enables automatic archival of less frequentlyaccessed information into centrally held archives. Using Enterprise Vault, organizations can archiveinfrequently accessed data from a wide variety of platforms including Exchange Servers; Domino MailServers; SharePoint Servers; Simple Mail Transfer Protocol (SMTP) message Servers; and file systems.Enterprise Vault also provides users with the ability to search and retrieve archived information. TheDiscovery and Compliance Accelerator components provided with Enterprise Vault enable compliancemonitoring and legal discovery activities.2.1.1.1Enterprise Vault Core ComponentsEnterprise Vault enables information archival and retrieval through the following core components whichare a part of the Enterprise Vault system as shown in Figure 1 below: The Enterprise Vault Server– includes services and tasks that perform the tasks of archiving itemsfrom target servers, creating indexes of archived items, storing items in the archives, and retrievingarchived information. The Enterprise Vault Administration Console – configures and manages services, tasks andarchives. Active Server Page (ASP) Web Access Components – enable users to search and retrieve items inarchives. SQL Databases – store information related to the Enterprise Vault archives. Services and tasksretrieve information, such as the location of a particular archive, from these databases. The variousdatabases installed as a part of Enterprise Vault include: Enterprise Vault directory database – Enterprise Vault holds configuration data andinformation about the archives in this database. Vault Store database – Enterprise Vault organizes archived items in entities called VaultStores. Each Vault Store has a Vault Store database associated with it. Vault Store Group Fingerprinting database – Enterprise Vault creates a fingerprint ofparts of an item, referred to as Single Instance Storage (SIS) parts, which are suitable forsharing across Vault Stores. For every SIS part, Enterprise Vault checks the fingerprintdatabase to determine if a fingerprint of the SIS part already exists. If a match is found,Enterprise Vault only references the stored SIS part instead of storing it again, allowingfor efficient storage and de–duplication of data. Monitoring and Reporting databases – Perform Enterprise Vault monitoring and reportingfunctions.Symantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 5 of 21

Security Policy, Version 1May 4, 2011Figure 1 – Symantec Enterprise Vault System OverviewThe core Enterprise Vault components can be installed on the same or different computers as required.2.1.1.2Enterprise Vault ArchivingIn order to archive information, Enterprise Vault archiving tasks check target servers at scheduled times.Relevant items are then stored in Enterprise Vault archives. In order to enable fast search and retrieval,Enterprise Vault creates an index of all the archived items. The Enterprise Vault (EV) archiving process isshown in Figure 2 below.Figure 2 – EV Archiving Process2.1.1.3Accessing Enterprise Vault ArchivesAny time a user wants to access an archived item, the web access component passes the user request on tothe Enterprise Vault services and tasks. Enterprise Vault services and tasks then look up the archives, andreturn the requested information to the user. Additionally, users may be allowed to restore archived itemsto their original location. If permitted, users can also delete archived items. The process of accessingEnterprise Vault archives is shown in Figure 3 below.Symantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 6 of 21

Security Policy, Version 1May 4, 2011Figure 3 – Users Accessing EV Archives2.1.2 Enterprise Vault Cryptographic ModuleSymantec Enterprise Vault Cryptographic Module is a multi–chip standalone physical embodiment. Themodule consists of a DLL1 which interfaces with the Microsoft Cryptographic API2 to provide the requiredcryptographic functionality.The Enterprise Vault Cryptographic Module may be used forencryption/decryption of Enterprise Vault passwords, hashing of indexes, and random number generation.When running on Windows Server 2003 SP2, the module includes implementations of the following FIPS–Approved algorithms: Advanced Encryption Standard (AES)Triple Data Encryption Algorithm (TDEA or Triple–DES3)Secure Hash Standard (SHS)(Keyed–) Hash Message Authentication Code (HMAC)RSA4 signature generationFIPS 186–2 General Purpose Pseudo Random Number Generator (PRNG)When running on Windows Server 2008 R2, the module includes implementations of the following FIPSApproved algorithms: Advanced Encryption Standard (AES)Triple Data Encryption Algorithm (TDEA or Triple–DES5)Secure Hash Algorithm (SHA)(Keyed–) Hash Message Authentication Code (HMAC)RSA6 signature generation and verificationSP7 800-90 AES-256 based counter mode Deterministic Random Bit Generator (DRBG)The Symantec Enterprise Vault Cryptographic Module is validated at the FIPS 140–2 Section levels shownin Table 1 below:Table 1 – Security Level Per FIPS 140–2 SectionSectionSection TitleLevel1Cryptographic Module SpecificationI2Cryptographic Module Ports and Interfaces13Roles, Services, and Authentication11DLL – Dynamic–Link LibraryAPI – Application Programming Interface3DES – Data Encryption Standard4RSA – Rivest, Shamir, Adleman5DES – Data Encryption Standard6RSA – Rivest, Shamir, Adleman7SP – Special Publication2Symantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 7 of 21

Security Policy, Version 1May 4, 2011SectionSection TitleLevel4Finite State Model15Physical Security6Operational Environment17Cryptographic Key Management18EMI/EMC819Self–tests110Design Assurance111Mitigation of Other AttacksN/AN/A2.2 Module SpecificationThe Symantec Enterprise Vault Cryptographic Module is a software module with a multi–chip standaloneembodiment. The overall security level of the module is 1. The physical and logical cryptographicboundaries of the Enterprise Vault Cryptographic Module are defined in the following sections.2.2.1 Physical Cryptographic BoundaryAs a software cryptographic module, the module must rely on the physical characteristics of the hostsystem. The physical boundary of the cryptographic module is defined by the hard enclosure around thehost system on which it runs. The module supports the physical interfaces of the host system, including theintegrated circuits of the system board, the CPU, network adapters, RAM, hard disk, device case, powersupply, and fans. Other devices may be attached to the General Purpose Computer (GPC), such as adisplay monitor, keyboard, mouse, printer, or storage media. See Figure 4 below for a standard host systemblock diagram.8EMI/EMC – Electromagnetic Interference / Electromagnetic CompatibilitySymantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 8 of 21

Security Policy, Version 1May 4, 2011Figure 4 – Standard GPC Block Diagram2.2.2 Logical Cryptographic BoundaryThe logical cryptographic boundary of the module executing in memory is shown in Figure 4. Themodule’s services can be called by the Symantec Enterprise Vault components. The module is utilized byevery component of Enterprise Vault that uses the encryption/decryption, hashing, and random numbergeneration functionality.Symantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 9 of 21

Security Policy, Version 1May 4, 2011Figure 5 – Logical Block Diagram and Cryptographic BoundaryThe cryptographic module was tested and found compliant on the following platforms: Windows Server 2003 SP2, 32–bitWindows Server 2008 R2, 64-bitAdditionally, the vendor affirms that the cryptographic module is also fully supported on the followingplatforms: Windows Server 2003 SP2, 64–bitWindows Server 2008, 32-bitWindows Server 2008, 64-bit2.3 Module InterfacesThe module’s logical interfaces exist in the software as an API. Physically, ports and interfaces are thoseof the host server. The API and physical interfaces can be categorized into following interfaces defined byFIPS 140–2: Data InputData OutputControl InputStatus OutputPower InputSymantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 10 of 21

Security Policy, Version 1May 4, 2011A mapping of the FIPS 140–2 logical interfaces, the physical interfaces, and the module can be found in thefollowing table:Table 2 – FIPS 140–2 Interface MappingsFIPS InterfacePhysical InterfaceLogical InterfaceData InputUSB ports, network ports,serial ports, SCSI/SATA ports,DVD/CD drive, audio portsArguments for API calls that containdata to be used or processed by themoduleData OutputDisplay port (e.g. VGA, HDMI, Arguments for API calls that contain orDVI, etc.),, USB ports, network point to where the result of the functionports, serial ports, SCSI/SATA is storedports, audio ports, DVD/CDdriveControl InputUSB ports, network ports,serial ports, power switchStatus OutputDisplay port (e.g. VGA, HDMI, Return values from API function callsDVI, etc.), serial ports, network and error messagesportsPower InputAC Power PortsAPI Function calls and parameters thatinitiate and control the operation of themoduleN/A2.4 Roles and ServicesSymantec Enterprise Vault Cryptographic Module is validated at FIPS 140–2 Level 1. Therefore, it doesnot perform authentication of any operators. The module supports the following two roles for operators, asrequired by FIPS 140–2: Crypto–Officer (CO) role and User role. Both roles are implicitly assumed whenthe services are utilized.Note 1: Table 3 and Table 4 use the following definitions for CSP9access.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 authenticationmechanism.Note 2: Input parameters of an API call that are not specifically a signature, hash, message, plaintext,ciphertext, or a key are NOT itemized in the “Input” column, since it is assumed that most API calls willhave such parameters.Note 3: The “Input” and “Output” columns are with respect to the module’s logical boundary.2.4.1 Crypto–Officer RoleThe operator in the Crypto–Officer role installs, uninstalls, and administers the module via the hostplatform’s Operating System (OS) interfaces.9CSP – Critical Security ParameterSymantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 11 of 21

Security Policy, Version 1May 4, 2011An operator assumes the CO role by invoking one of the following services:Table 3 – Crypto–Officer ServicesServiceInputOutputCSP and Type of AccessInitialize moduleAPI call parametersStatusNoneShow statusNoneStatusNoneRun self–tests ondemandNoneStatusNone2.4.2 User RoleThe operator in the User role is a consumer of the module’s security services. The role is assumed byinvoking one of the following cryptographic services:Table 4 – User ServicesServiceInputOutputCSP and Type of AccessGenerate randomAPI call parametersnumber (Windows Server2003 SP2 – FIPS 186–2)Status, random FIPS 186–2 RNG seed – RXbitsFIPS 186–2 seed key – RXGenerate randomAPI call parametersnumber (Windows Server2008 R2 – SP 800-90)Status, random SP 800-90 RNG seed – RXbitsGenerate message digest(SHS)API call parameters,messageStatus, hashNoneGenerate keyed hash(HMAC)API call parameters, key,messageStatus, hashHMAC key – RWXZeroize keyAPI call parametersStatusAES key – WTDES key – WHMAC key – WRSA private/public key – WSymmetric encryptionAPI call parameters, key,plaintextStatus,ciphertextAES key – RWXTDES key – RWXSymmetric decryptionAPI call parameters, key,ciphertextStatus,plaintextAES key – RWXTDES key – RWXGenerate asymmetric key API call parameterspairStatus, key pair RSA private/public key – WRSA encryptionAPI call parameters,plaintextStatus,ciphertextRSA public key – RWXRSA decryptionAPI call parameters,ciphertextStatus,plaintextRSA private key – RWXSignature GenerationAPI call parameters, key,messageStatus,signatureRSA private key – WXSignature VerificationAPI call parameters, key,signature, messageStatusRSA public key – WXSymantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 12 of 21

Security Policy, Version 1May 4, 20112.5 Physical SecurityThe Symantec Enterprise Vault Cryptographic Module is a software module, which FIPS defines as amulti–chip standalone cryptographic module. As such, it does not include physical security mechanisms.Thus, the FIPS 140–2 requirements for physical security are not applicable.2.6 Operational EnvironmentThe module was tested and found to be compliant with FIPS 140–2 requirements on the followingplatforms: GPC with an Intel Celeron processor running Windows Server 2003 SP2, 32–bitGPC with an Intel Core 2 Duo processor running Windows Server 2008 R2, 64-bitSymantec affirms that the module also executes in its FIPS–Approved manner (as described in this SecurityPolicy) on the following other Operating Systems: Windows Server 2003 SP2, 64–bitWindows Server 2008, 32-bitWindows Server 2008, 64-bitThe Crypto–Officer shall ensure that the Operating System (OS) is configured to a Single User mode ofoperation. All cryptographic keys and CSPs are under the control of the operating system, which protectsthe CSPs against unauthorized disclosure, modification, and substitution. The module only allows accessto CSPs through its well–defined API.2.7 Cryptographic Key ManagementWhen running on Windows Server 2003 SP2, the module implements the FIPS–Approvedalgorithms listed in Table 5 – FIPS–Approved Algorithm Implementations (Windows Server2003 SP2)below.Table 5 – FIPS–Approved Algorithm Implementations (Windows Server 2003 SP2)AlgorithmCertificate NumberAES in ECB , CBC modes with 128, 192, and 256 bit keys818Triple–DES in ECB, CBC modes with 112 and 168 bit keys691RSA (ANSI12 X9.31, PKCS13 #1.5, PSS) sign with 1024, 1536,2048, 3072, 4096 bit keys395SHA14–1, SHA–256, SHA–384, SHA–512816HMAC–SHA–1, HMAC–SHA–256, HMAC– SHA–384,HMAC–SHA–512452FIPS 186–2 General Purpose PRNG470101110ECB – Electronic CodebookCBC – Cipher Block Chaining12ANSI – American National Standards Institute13PKCS – Public–Key Cryptography Standards14SHA – Secure Hash Algorithm11Symantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 13 of 21

Security Policy, Version 1May 4, 2011When running on Windows Server 2008 R2, the module implements the FIPS–Approved algorithms listedin Table 6 above.Table 6 – FIPS–Approved Algorithm Implementations (Windows Server 2008 R2)Algorithm15Certificate NumberAES in ECB, CBC, CFB8 modes with 128, 192, and 256 bitkeys1168Triple–DES in ECB, CBC, CFB8 modes with 112 and 168 bitkeys846RSA (ANSI X9.31, PKCS #1.5) sign/verify with 1024, 1536,2048, 3072, 4096 bit keys568RSA (ANSI X9.31) key generation with 1024, 1536, 2048,3072, 4096 bit keys559SHA–1, SHA–256, SHA–384, SHA–5121081HMAC–SHA–1, HMAC–SHA–256, HMAC– SHA–384,HMAC–SHA–512687SP16 800-90 AES-256 based counter mode DRBG23The module implements the following non-Approved algorithm allowed in FIPS mode: RSA Key Transport (key establishment methodology provides between 80 and 150 bits ofencryption strength)When running on Windows Server 2003 SP2, the module supports the following non–FIPS approvedalgorithms which are only available in a non–FIPS mode of operation: ANSI X9.31RSA key-pair generationANSI X9.31 RSA signature verificationRC172RC4MD185MD2MD4DESWhen running on Windows Server 2008 R2, the module supports the following non–FIPS approvedalgorithms which are only available in a non–FIPS mode of operation: RC2 RC4 MD5 MD2 MD4 DES15CFB8 – Cipher Feedback (8-bit)SP – Special Publication17RC – Rivest Cipher18MD – Message Digest16Symantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be freely reproduced and distributed whole and intact including this copyright notice.Page 14 of 21

Security Policy, Version 1May 4, 2011The CSPs supported by the module are shown in Table 7 below. Please note that the “Input” and “Output”columns are in reference to the module’s logical boundary. Keys that enter and exit the module via an APIcall parameter are in plaintext.Table 7 – List of Cryptographic Keys, Key Components, and CSPsCSP/KeyInputOutputStorageZeroizationUseAES keyAPI callparameterNeverPlaintext involatilememoryBy API call,power cycleEncryption,decryptionTDES keyAPI callparameterNeverPlaintext involatilememoryBy API call,power cycleEncryption,decryptionHMAC keyAPI callparameterNeverPlaintext involatilememoryBy API call,power cycleMessageAuthenticationwith SHA–1 andSHA–2sRSA privatekeyAPI callparameterNeverPlaintext involatilememoryBy API call,power cycleSignaturegeneration,decryptionRSA publickeyAPI callparameterNeverPlaintext involatilememoryBy API call,power cycleSignatureverification,encryptionFIPS 186–2PRNG seed(WindowsServer 2003SP2)InternallygeneratedNeverPlaintext involatilememoryBy API call,power cycleGeneraterandom numberFIPS186–2PRNG seedkey(WindowsServer 2003SP2)InternallygeneratedNeverPlaintext involatilememoryBy API call,power cycleGeneraterandom numberSP 800-90DRBG seed(WindowsServer 2008R2)InternallygeneratedNeverPlaintext involatilememoryBy API call,power cycleGeneraterandom number2.7.1 Key GenerationWhen running on Windows Server 2003 SP2, the module uses a FIPS–Approved FIPS 186–2 GeneralPurpose PRNG implementation to generate cryptographic keys. When operating on Windows Server 2008R2, the module uses a FIPS-Approved SP 800-90 AES-256 based counter mode DRBG for the generationof cryptographic keys.Symantec Enterprise Vault Cryptographic Module 2011 Symantec CorporationThis document may be fre

Symantec Enterprise Vault is a content archiving platform that enables automatic archival of less frequently accessed information into centrally held archives. Using Enterprise Vault, organizations can archive infrequently accessed data from a wide variety of platforms including Exchange Servers; Domino Mail Servers; SharePoint Servers; Simple .