FIPS 140-2 Non-Proprietary Security Policy Symantec Control . - NIST

Transcription

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0FIPS 140-2 Non-Proprietary Security PolicySymantec Control Center Cryptographic Module Version 1.0Document Version 1.2July 19, 2012Document Version 1.2 SymantecPage 1 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0Prepared For:Prepared By:Symantec CorporationApex Assurance Group, LLC350 Ellis Street530 Lytton Avenue, Ste. 200Mountain View, CA 94043Palo Alto, CA This document provides a non-proprietary FIPS 140-2 Security Policy for the Control CenterCryptographic Module Version 1.0.Document Version 1.2 SymantecPage 2 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0Table of Contents1Introduction . 51.1 About FIPS 140.51.2 About this Document .51.3 External Resources.51.4 Notices .51.5 Acronyms .52Symantec Control Center Cryptographic Module Version 1.0 . 82.1 Solution Overview .82.2 Cryptographic Module Specification.82.2.1 Validation Level Detail .82.2.2 Approved Cryptographic Algorithms.92.2.3 Non-Approved Cryptographic Algorithms.92.3 Module Interfaces.102.4 Roles, Services, and Authentication .122.4.1 Operator Services and Descriptions .122.4.2 Operator Authentication .142.5 Physical Security .142.6 Operational Environment .142.7 Cryptographic Key Management .162.7.1 Key Generation .172.7.2 Key Entry, Output, and Protection .172.7.3 Key/CSP Storage and Zeroization .172.8 Self-Tests.192.8.1 Power-On Self-Tests .192.8.2 Conditional Self-Tests.192.8.3 Critical Functions Tests.202.9 Mitigation of Other Attacks .203Guidance and Secure Operation . 213.1 Initial Setup.213.2 Crypto Officer Guidance . 213.2.1 Software Packaging and OS Requirements .213.2.2 Enabling FIPS Mode.223.2.3 Management Procedures.223.2.4 Additional Rules of Operation .223.3 User Guidance .223.3.1 General Guidance.223.4 Role Changes .233.5 Bound Module Modes of Operation .233.6 Bound Module Random Number Generator .25Document Version 1.2 SymantecPage 3 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0List of TablesTable 1 – Acronyms and Terms.7Table 2 – Validation Level by FIPS 140-2 Section.9Table 3 – FIPS-Approved Algorithm Certificates .9Table 4 – Logical Interface / Physical Interface Mapping .12Table 5 – Module Services .14Table 6 – Module Keys/CSPs.17Table 7 – Power-On Self-Tests .19Table 8 – Conditional Self-Tests.20Table 9 – Critical Functions Tests.20Table 10 – Module Mode Descriptions.24List of FiguresFigure 1 – Module Boundary and Interfaces Diagram .11Document Version 1.2 SymantecPage 4 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.01 Introduction1.1 About FIPS 140Federal Information Processing Standards Publication 140-2 — Security Requirements for CryptographicModules specifies requirements for cryptographic modules to be deployed in a Sensitive butUnclassified environment. The National Institute and Technology (NIST) and Communications SecurityEstablishment of Canada (CSEC) jointly run the Cryptographic Module Validation Program (CMVP). TheNational Institute of Standards and Technology, National Voluntary Laboratory Accreditation Program(NVLAP) accredits independent testing labs to perform FIPS 140-2 testing; the CMVP validates testreports for modules meeting FIPS 140-2 validation. Validation is the term given to a cryptographicmodule that is documented and tested against the FIPS 140-2 Security Requirements for CryptographicModules.More information is available on the CMVP website at csrc.nist.gov/groups/STM/cmvp/index.html.1.2 About this DocumentThis non-proprietary Cryptographic Module Security Policy for the Control Center Cryptographic ModuleVersion 1.0 from Symantec provides an overview of the product and a high-level description of how itmeets the security requirements of FIPS 140-2. This document contains details on the module’scryptographic keys and critical security parameters. This Security Policy concludes with instructions andguidance on running the module in a FIPS 140-2 mode of operation.The Symantec Control Center Cryptographic Module Version 1.0 may also be referred to as the“module” in this document.1.3 External ResourcesThe Symantec website (http://www.symantec.com) contains information on Symantec products. TheCryptographic Module Validation Program website val2012.htm) contains links to the FIPS 140-2 certificate and Symantec contact information.1.4 NoticesThis document may be freely reproduced and distributed in its entirety without modification.1.5 AcronymsThe following table defines acronyms found in this document:Document Version 1.2 SymantecPage 5 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version IFCCFIPSFTPGCMGPCGUIHMACHPHTTPHTTPSDocument Version 1.2TermAdvanced Encryption StandardAdvanced Interactive eXecutiveAmerican National Standards InstituteApplication Programming InterfaceCipher Block ChainingCounter with CBC-MACCipher FeedbackCryptographic Module Validation ProgramCrypto OfficerCommunications Security Establishment CanadaCritical Security ParameterCounterData Encryption StandardData Encryption Standard XORedDiffie-HellmanDemilitarized ZoneDeterministic Random Bit GeneratorDigital Signature AlgorithmElliptic CurveElectronic Code BookElliptic Curve CryptographyElliptic Curve Diffie-HellmanElliptic Curve Deterministic Random Bit GeneratorElliptic Curve Digital Signature AlgorithmElliptic Curve Integrated Encryption SystemElectromagnetic CompatibilityElectromagnetic InterferenceFederal Communications CommissionFederal Information Processing StandardFile Transfer ProtocolGalois/Counter ModeGeneral Purpose ComputerGraphical User Interface(Keyed-) Hash Message Authentication CodeHewlett-PackardHypertext Transfer ProtocolSecure Hypertext Transfer Protocol SymantecPage 6 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version TLSUSBInternational Business MachineJava ArchiveJava Runtime EnvironmentJava Virtual MachineKnown Answer TestLocal Area NetworkMessage Authentication CodeMessage DigestMail Transfer AgentNetwork Information ServiceNational Institute of Standards and TechnologyOptimal Asymmetric Encryption PaddingOutput FeedbackOperating SystemPassword Based EncryptionPublic-Key Cryptography StandardsPseudo Random Number GeneratorProbabilistic Signature SchemeRivest CipherResearch and Development in AdvancedCommunications Technologies in EuropeRACE Integrity Primitives Evaluation Message DigestRandom Number GeneratorRivest, Shamir, and AdlemanSecure Hash AlgorithmSymantec Messaging GatewaySimple Mail Transfer ProtocolSpecial PublicationSecure Sockets LayerTriple Data Encryption AlgorithmTriple Data Encryption AlgorithmTransport Layer SecurityUniversal Serial BusTable 1 – Acronyms and TermsDocument Version 1.2 SymantecPage 7 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.02 Symantec Control Center Cryptographic Module Version 1.02.1 Solution OverviewThe Symantec Control Center Cryptographic Module Version 1.0 has been implemented as part of theSymantec Messaging Gateway, a secure email gateway offering.The Control Center provides management services, such as centralized administration, reporting, andmonitoring. These management services are conducted via a Console, which runs within a Web Browserof a workstation connected to the module.2.2 Cryptographic Module SpecificationThe module, the Symantec Control Center Cryptographic Module Version 1.0, is a software sharedlibrary that provides cryptographic services required by the Control Center component of the SymantecMessaging Gateway. The module is a software-only module installed on a General Purpose Computerrunning Windows XP SP2.The module is comprised of two components:1. The Symantec cryptographic module wrapper fully initializes and manages FIPS mode. Thisincludes performing an integrity check, verifying the provider is configured, invoking theprovider self tests, and reporting status.2. An bound validated module (see certificate number 1048) provides cryptographic functions.All operations of the module occur via calls from the Symantec applications and their respective internaldaemons/processes. As such there are no untrusted services calling the services of the module, as APIsare not exposed.2.2.1 Validation Level DetailThe following table lists the level of validation for each area in FIPS 140-2:FIPS 140-2 Section TitleCryptographic Module SpecificationCryptographic Module Ports and InterfacesRoles, Services, and AuthenticationFinite State ModelPhysical SecurityOperational EnvironmentCryptographic Key ManagementElectromagnetic Interference / Electromagnetic CompatibilityDocument Version 1.2 SymantecValidation Level1111N/A111Page 8 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0FIPS 140-2 Section TitleValidation Level111Self-TestsDesign AssuranceMitigation of Other AttacksTable 2 – Validation Level by FIPS 140-2 Section2.2.2 Approved Cryptographic AlgorithmsThe module’s cryptographic algorithm implementations have received the following certificate numbersfrom the Cryptographic Algorithm Validation Program:AlgorithmAES – ECB, CBC, OFB-128, CFB-128 bit mode for 128, 192,and 256 bit key sizesAES CCMAES CTRDSAECDRBGECDSA, ECDSA-SHA1FIPS 186-2 PRNG (Change Notice 1 – with and without themod q step)HMAC DRBGHMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMACSHA-384, HMAC-SHA-512RSA X9.31, PKCS#1 v1.5, PKCS#1 v2.1 (SHA256 – PSS)SHA-1, SHA-224, SHA-256, SHA-384, SHA-512TDES – ECB, CBC, CFB-64, OFB-64 modeX9.82 Dual ECDRBGTable 3 – FIPS-Approved Algorithm CertificatesCAVP Certificate669669669251Vendor Affirmed: SP 800-9072389Vendor Affirmed: SP 800-90353311702614Vendor Affirmed: SP 800-9012.2.3 Non-Approved Cryptographic AlgorithmsThe module does not implement any non-approved algorithms in FIPS mode. The module utilizes thefollowing non-FIPS-approved algorithm implementations that are only allowed in a non-Approved modeof operation: DES DESX Diffie-Hellman, EC-Diffie-Hellman, EC- Random Number Generators (ANSI X9.31,MD5Random, and SHA1Random) RC2 block cipher1Note this implementation has received FIPS 140-2 Level 1 validation s/140-1/1401val2008.htm#1048Document Version 1.2 SymantecPage 9 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0Diffie-Hellman with Cofactor (Bit lengthsfor the Diffie-Hellman key agreement mustbe between 1024 and 2048 bits. DiffieHellman shared secret provides between80 bits and 112 bits of encryptionstrength) RC4 stream cipher RC5 block cipher PBE with SHA1 and Triple-DES RSA encrypt/decrypt (allowed for keytransport) RSA OAEP for key transport Raw RSA encryption and decryption RSA Keypair Generation MultiPrime (twoor three primes) ECAES AES-GCM ECIES MD2 MD5 RIPEMD160 PBE HMAC-MD52.3 Module InterfacesThe figure below shows the module’s physical and logical block diagram:Document Version 1.2 SymantecPage 10 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0Figure 1 – Module Boundary and Interfaces DiagramThe interfaces (ports) for the physical boundary include the computer keyboard port, CDROM drive,floppy disk, mouse, network port, parallel port, USB ports, monitor port and power plug. Whenoperational, the module does not transmit any information across these physical ports because it is asoftware cryptographic module. Therefore, the module’s interfaces are purely logical and are providedthrough the Application Programming Interface (API) that a calling daemon can operate. The logicalinterfaces expose services that applications directly call, and the API provides functions that may becalled by a referencing application (see Section 2.4 – Roles, Services, and Authentication for the list ofavailable functions). The module distinguishes between logical interfaces by logically separating theinformation according to the defined API.The API provided by the module is mapped onto the FIPS 140- 2 logical interfaces: data input, dataoutput, control input, and status output. Each of the FIPS 140- 2 logical interfaces relates to themodule's callable interface, as follows:FIPS 140-2 InterfaceData InputData OutputControl InputDocument Version 1.2Logical InterfaceInput parameters of API functioncallsOutput parameters of API functioncallsAPI function calls SymantecModule Physical InterfaceNetwork interfaceNetwork interfaceKeyboard interface, MouseInterfacePage 11 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0FIPS 140-2 InterfaceStatus OutputPowerLogical InterfaceFor FIPS mode, function callsreturning status information andreturn codes provided by APIfunction calls.NoneModule Physical InterfaceDisplay controllerPower supplyTable 4 – Logical Interface / Physical Interface MappingAs shown in Figure 1 – Module Boundary and Interfaces Diagram and Table 5 – Module Services, theoutput data path is provided by the data interfaces and is logically disconnected from processesperforming key generation or zeroization. No key information will be output through the data outputinterface when the module zeroizes keys.2.4 Roles, Services, and AuthenticationThe module supports a Crypto Officer and a User role. The module does not support a Maintenancerole.2.4.1 Operator Services and DescriptionsThe services available to the User and Crypto Officer roles in the module are as follows:Document Version 1.2 SymantecPage 12 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0ServiceOn Demand SelftestRolesCryptoOfficerNoneOutputStatusNoneGet FIPS140ContextGet seederUserNoneStatusNoneUserNoneNoneGet DefaultRandom NumberGeneratorCheck FIPS 140-2ComplianceGet StateGet ModeSet ModeGet RoleSet RoleCheck Latest SelfTest ResultsCheck ModeConfigure CRNGDisable libraryVerify serNoneNoneAPI call parameterNoneAPI call oneNoneNoneNoneNoneNoneUserUserUserUserNoneAPI call parameterAPI call parameterAPI call ecryptionUserDigital SignatureGenerationUserAPI call parameters,key, plaintextAPI call parameters,key, ciphertextAPI call parameters,key, natureDigital SignatureVerificationUserAPI call parameters,key, signature,messageStatusKey EstablishmentPrimitivesUserAPI call parameters,keyStatus,keyAES KeyTDES KeyAES KeyTDES KeyRSA Private KeyRSA Public KeyDSA Private KeyDSA Public KeyRSA Private KeyRSA Public KeyDSA Private KeyDSA Public KeyRSA Private KeyRSA Public KeyDH KeyECDH KeyDocument Version 1.2Input SymantecKey/CSP AccessNoneNonePage 13 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0ServiceKey GenerationRolesUserMACUserHashingUserRandom putAPI call parametersOutputStatus,key/keypairAPI call parameterskey, messageAPI call parameters,messageAPI call PI call parametersStatusKey/CSP AccessAES KeyTDES KeyDSA Private KeyDSA Public KeyRSA Private KeyRSA Public KeyDH KeyHMAC DRBG KeyHMAC with SHA-1 and SHA-2 KeysHMAC DRBG KeyHMAC with SHA-1 and SHA-2 KeysNoneFIPS 186-2 PRNG SeedFIPS 186-2 PRNG Seed KeyEC DRBG EntropyEC DRBG S Value (Seed Length)EC DRBG init seedHMAC DRBG EntropyHMAC DRBG V Value (SeedLength)HMAC DRBG KeyHMAC DRBG init seedAllTable 5 – Module Services2.4.2 Operator AuthenticationAs required by FIPS 140-2, there are two roles (a Crypto Officer role and User role) in the module thatoperators may assume. As allowed by Level 1, the module does not support authentication to accessservices.2.5 Physical SecurityThis section of requirements does not apply to this module. The module is a software-only module anddoes not implement any physical security mechanisms.2.6 Operational EnvironmentThe module operates on a general purpose computer (GPC) running on a modern version of MicrosoftWindows as a general purpose operating system (GPOS). For FIPS purposes, the module is running onDocument Version 1.2 SymantecPage 14 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0Microsoft Windows in single user mode and does not require any additional configuration to meet theFIPS requirements.The module was tested on the following platforms: Microsoft Windows XP SP2 (32-bit) with Sun JRE 1.4.2 Microsoft Windows XP SP2 (32-bit) with Sun JRE 1.5 Microsoft Windows XP SP2 (32-bit) with Sun JRE 1.6.The GPC(s) used during testing met Federal Communications Commission (FCC) FCC ElectromagneticInterference (EMI) and Electromagnetic Compatibility (EMC) requirements for business use as definedby 47 Code of Federal Regulations, Part15, Subpart B. FIPS 140-2 validation compliance is maintainedwhen the module is operated on other versions of the Microsoft Windows GPOS running in single usermode, assuming that the requirements outlined in NIST IG G.5 are met.Document Version 1.2 SymantecPage 15 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.02.7 Cryptographic Key ManagementThe table below provides a complete list of Critical Security Parameters used within the module:Keys and CSPsStorageLocationsAES KeyRAMTDES KeyHMAC with SHA(1, 224, 256,384, 512)ECDH KeyDH Private KeyDH Public KeyRSA IntegrityCheck KeyRSA Private KeyRSA Public KeyDSA Private KeyDSA Public KeyFIPS 186-2PRNG SeedFIPS 186-2PRNG Seed aintextInputMethodAPI itiveData.clear()API callparameterNoneAPI a.clear()API callparametersensitiveData.clear()API callparametersensitiveData.clear()API callparametersensitiveData.clear()API callparameterNonesensitiveData.clear()API callparameterNoneNoneNoneAPI callparameterU: RWDCO: RWDpower cycleAPI callparameterNoneU: RWDCO: RWDpower cyclesensitiveData.clear()NoneCO: RWDpower cycleU: RWDCO: RWDpower cycleU: RWDCO: RWDpower cycleU: RWDCO: RWDpower cycleU: RWDCO: RWDpower cycleU: RWDCO: RWDpower cyclesensitiveData.clear()U: RWDCO: RWDpower cycleNonesensitiveData.clear()U: RWDCO: RWDpower cycleAPI callparameterNoneNoneNonesensitiveData.clear()U: RWDCO: RWDpower cyclesensitiveData.clear()U: RWDCO: RWDpower cycleRAMPlaintextNoneNonesensitiveData.clear()U: RWDCO: RWDpower cycleU: RWDDocument Version 1.2 SymantecPage 16 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0Keys and CSPsStorageLocationsEC DRBGEntropyRAMEC DRBG SValue (SeedLength)EC DRBGinit oizationAccesssensitiveData.clear()CO: RWDpower cyclePlaintextNoneNonesensitiveData.clear()U: RWDCO: RWDpower cycleRAMPlaintextNoneNonesensitiveData.clear()U: RWDCO: RWDpower cycleHMAC DRBGEntropyRAMHMAC DRBG VValue (SeedLength)HMAC DRBGKeyRAMHMAC DRBGinit ear()U: RWDCO: RWDpower cyclePlaintextNoneNonesensitiveData.clear()U: RWDCO: RWDpower cycleRAMPlaintextNoneNonesensitiveData.clear()U: RWDCO: RWDpower cycleRAMPlaintextNoneNonesensitiveData.clear()U: RWDCO: RWDpower cycleU: RWDR Read W Write D DeleteTable 6 – Module Keys/CSPs2.7.1 Key GenerationThe module supports the generation of the DSA, RSA, and Diffie-Hellman (DH) and ECC public andPrivate Keys. The module also uses a Federal Information processing Standard 186-2, Digital SignatureStandard (FIPS 186-2) Approved random number generator and a FIPS Approved Dual Elliptic CurveDeterministic Random Bit Generator (ECDRBG SP 800-90) for generating asymmetric and symmetrickeys.2.7.2 Key Entry, Output, and ProtectionAll keys and CSPs reside on memory internally allocated by the module and can only be output using theexposed APIs. The module does not support key entry or output from the physical boundary. Theoperating system and the JRE protect the memory and process space from unauthorized access.2.7.3 Key/CSP Storage and ZeroizationThe module does not provide long-term cryptographic key storage. Storage of keys is the responsibilityof the user of the module. All keys and CSPs are automatically zeroized by the module at the end of theirDocument Version 1.2 SymantecPage 17 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0lifetime. The user can ensure destruction of sensitive data by calling sensitiveData.clear().Powercycling the module will also zeroize keys.Document Version 1.2 SymantecPage 18 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.02.8 Self-TestsThe module performs power-up and conditional self-tests to ensure proper operation. If a power-upself- test fails, the module is disabled and throws a SecurityException. The module can only leavethe disabled state by restarting the Java Virtual Machine. If a conditional self-test fails, the modulethrows a SecurityException and aborts the operation. A conditional self-test failure does notdisable the module.In event of a self-test failure, the module provides the following message: Could not initializeclass com.rsa.jsafe.provider.JsafeJCE.The following sections discuss the module’s self-tests in more detail.2.8.1 Power-On Self-TestsThe module implements the following power-on self-tests:TYPESoftware Integrity CheckKnown Answer TestsPair-wise Consistency TestsDETAILRSA Digital Signature Verification AES DES ECDRBG ECDSA FIPS186 PRNG HMAC DRBG HMAC SHA-1 HMAC SHA-224 HMAC SHA-256 HMAC SHA-384 HMAC SHA-512 SHA-1 SHA-224 SHA-256 SHA-384 SHA-512 TDES DSA ECDSA RSATable 7 – Power-On Self-TestsPower-on self-tests are executed automatically when the module is loaded into memory.2.8.2 Conditional Self-TestsThe module implements the following conditional self-tests:Document Version 1.2 SymantecPage 19 of 25

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0TYPEPair-wise Consistency TestsContinuous RNG TestsDETAIL DSA ECDSA RSAPerformed on all approved RNGsTable 8 – Conditional Self-Tests2.8.3 Critical Functions TestsThe module implements the following critical functions tests:TYPEKnown AnswerTests DETAILMD5 and HMAC-MD5 when operating in FIPS140 SSL MODETable 9 – Critical Functions Tests2.9 Mitigation of Other AttacksAs a defense against timing attacks, RSA key operations implement blinding by default. By using theblinding method, it is ensured that the decryption time is not correlated to the input ciphertext; as aconsequence, attempts of timing attacks are thwarted. Blinding is implemented through blinding modeswith the following available options: Blinding mode off Blinding mode with no update (the blinding value is squared for each operation) Blinding mode with full upd

FIPS 140-2 Non-Proprietary Security Policy: Symantec Control Center Cryptographic Module Version 1.0 Document Version 1.2 Symantec Page 1 of 25