Blue Coat Systems, Inc. Blue Coat Systems, Software Cryptographic Module SW Version: 1.0 FIPS 140-2 Non-Proprietary Security Policy FIPS Security Level: 1 Document Version: 1.8 Prepared for: Prepared by: Blue Coat Systems, Inc. Corsec Security, Inc. 420 N. Mary Avenue 13135 Lee Jackson Memorial Hwy Sunnyvale, CA 94085 Suite 220 United States of America Fairfax, VA 22033 Phone: +1 (801) 545-4100 Phone: +1 (703) 267-6050 Email: info@soleranetworks.com Email: info@corsec.com http://www.soleranetworks.com http://www.corsec.com Security Policy, Version 1.8 October 23, 2013 Table of Contents 1 INTRODUCTION ................................................................................................................... 4 1.1 PURPOSE ................................................................................................................................................................ 4 1.2 REFERENCES .......................................................................................................................................................... 4 1.3 DOCUMENT ORGANIZATION ............................................................................................................................ 4 2 BLUE COAT SYSTEMS, SOFTWARE CRYPTOGRAPHIC MODULE .............................. 5 2.1 OVERVIEW ............................................................................................................................................................. 5 2.1.1 Software Cryptographic Module ........................................................................................................................ 6 2.2 MODULE SPECIFICATION..................................................................................................................................... 7 2.2.1 Physical Cryptographic Boundary ...................................................................................................................... 7 2.2.2 Logical Cryptographic Boundary ........................................................................................................................ 8 2.3 MODULE INTERFACES ........................................................................................................................................10 2.4 ROLES AND SERVICES .........................................................................................................................................11 2.4.1 Crypto-Officer Role.............................................................................................................................................. 11 2.4.2 User Role ................................................................................................................................................................ 12 2.4.3 Non-Approved Services ...................................................................................................................................... 13 2.5 PHYSICAL SECURITY ...........................................................................................................................................14 2.6 OPERATIONAL ENVIRONMENT.........................................................................................................................14 2.7 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................................................14 2.7.1 Key Generation..................................................................................................................................................... 17 2.7.2 Key Entry and Output ........................................................................................................................................ 17 2.7.3 Key/CSP Storage and Zeroization .................................................................................................................. 17 2.8 EMI/EMC ............................................................................................................................................................18 2.9 SELF-TESTS ..........................................................................................................................................................18 2.9.1 Power-Up Self-Tests ............................................................................................................................................ 18 2.9.2 Conditional Self-Tests ......................................................................................................................................... 18 2.10 MITIGATION OF OTHER ATTACKS ..................................................................................................................19 3 SECURE OPERATION ......................................................................................................... 20 3.1 INITIAL SETUP......................................................................................................................................................20 3.2 SECURE MANAGEMENT .....................................................................................................................................20 3.2.1 Initialization ........................................................................................................................................................... 20 3.2.2 Management ........................................................................................................................................................ 20 3.2.3 Zeroization ............................................................................................................................................................ 20 3.2.4 User Guidance ...................................................................................................................................................... 20 4 ACRONYMS .......................................................................................................................... 21 Table of Figures FIGURE 1 – TYPICAL DEPLOYMENT CONFIGURATION OF SOLERA DEEPSEE SOFTWARE................................................6 FIGURE 2 – DELL R720 BLOCK DIAGRAM .............................................................................................................................8 FIGURE 3 – LOGICAL BLOCK DIAGRAM AND CRYPTOGRAPHIC BOUNDARY FOR HARDWARE CONFIGURATION ....9 FIGURE 4 – LOGICAL BLOCK DIAGRAM AND CRYPTOGRAPHIC BOUNDARY FOR VIRTUAL CONFIGURATION ....... 10 List of Tables TABLE 1 – SECURITY LEVEL PER FIPS 140-2 SECTION ..........................................................................................................6 TABLE 2 – FIPS 140-2 LOGICAL INTERFACE MAPPINGS ................................................................................................... 10 TABLE 3 – CRYPTO-OFFICER SERVICES ............................................................................................................................... 11 TABLE 4 – USER SERVICES ..................................................................................................................................................... 12 TABLE 5 – NON-APPROVED SERVICES ................................................................................................................................ 13 TABLE 6 – FIPS-APPROVED ALGORITHM IMPLEMENTATIONS .......................................................................................... 14 Blue Coat Systems, Software Cryptographic Module Page 2 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 TABLE 7 – LIST OF CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS................................. 15 TABLE 8 – ACRONYMS .......................................................................................................................................................... 21 Blue Coat Systems, Software Cryptographic Module Page 3 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the Blue Coat Systems, Software Cryptographic Module from Blue Coat Systems, Inc.. This Security Policy describes how the Blue Coat Systems, Software 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 Blue Coat Systems, Software Cryptographic Module is referred to in this document as the Software Cryptographic Module, 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 Solera Networks, a Blue Coat company website (http://www.soleranetworks.com) contains information on the full line of products from Solera Networks, a Blue Coat company.  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 document  Submission Summary  Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to Blue Coat. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Submission Package is proprietary to Blue Coat and is releasable only under appropriate non- disclosure agreements. For access to these documents, please contact Blue Coat. Blue Coat Systems, Software Cryptographic Module Page 4 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 2 Blue Coat Systems, Software Cryptographic Module 2.1 Overview Blue Coat develops tools that combine security intelligence and big data analytics to help organizations battle Advanced Persistent Threats (APTs) and Advanced Targeted Attacks (ATAs). This is accomplished through a combination of data collection, correlation, and enrichment that is made available to security analysts to help them stay ahead of today’s evolving threat landscape. The Solera Networks DeepSee platform captures packets, indexes flows, and extracts files, from Layer 2 through Layer 7 data. This provides near real-time and retrospective visibility into security relevant network events. The Software Cryptographic Module is incorporated in Solera DeepSee Software. Solera DeepSee Software acts as an unobtrusive network traffic recorder. Data crossing the network is captured and saved to storage. Once in storage, data can be played back to analysis applications, or can be sent to any other location on the network or to multiple applications and locations. It creates a complete record of network traffic (including both packet headers and payloads), facilitating regeneration, filtering, and playback for later analysis. Filtering and analysis tools can be applied during data capture or playback. The major features of the Solera DeepSee Software are:  Improved network security – Network administrators have comprehensive evidence to better protect against intruders, data leakage, and internal misuse.  Flexible Deployment Technology – Solera DeepSee Software provides the flexibility to be deployed on any hardware platform allowing organizations of all sizes to benefit from deep packet capture and analysis to improve network performance and security.  Increased network tool options – Solera DeepSee Software works with many management, analysis, and forensic tools (commercial, custom, and open source) to monitor, manage, and secure the network. Figure 1 below shows the details of the typical deployment configuration of the Solera DeepSee Software. The following previously undefined acronyms appear in Figure 1:  API – Application Programming Interface  GBPS – Gigabits per second  PCAP – Packet Capture Blue Coat Systems, Software Cryptographic Module Page 5 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 Figure 1 – Typical Deployment Configuration of Solera DeepSee Software 2.1.1 Software Cryptographic Module The Blue Coat Systems, Software Cryptographic Module is a software shared library that is included with Solera DeepSee Software v6.5.0. It provides the primitive cryptographic services required by TLS 1 for secure communications. The module includes implementations of the following FIPS-Approved algorithms:  Advanced Encryption Standard (AES)  Triple Data Encryption Algorithm (TDES)  Secure Hash Algorithm (SHA)  Keyed-Hash Message Authentication Code (HMAC)  Digital Signature Algorithm (DSA)  RSA2 signature generation and verification  ANSI3 X9.31 Pseudo Random Number Generator (PRNG) The Software Cryptographic Module operates in a FIPS-Approved mode of operation when configured according to the Crypto-Officer guidance in this Security Policy and does not support a non-Approved mode of operation. It is validated at the FIPS 140-2 Section levels as indicated in Table 1 below. 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 1 TLS – Transport Layer Security 2 RSA – Rivest, Shamir, Adleman 3 ANSI - American National Standards Institute Blue Coat Systems, Software Cryptographic Module Page 6 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 Section Section Title Level 6 Operational Environment 1 7 Cryptographic Key Management 1 8 1 EMI/EMC4 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A 2.2 Module Specification The Software Cryptographic Module is a software module with a multi-chip standalone embodiment. The overall security level of the module is 1. The Software Cryptographic Module is implemented in the C programming language and consists of a shared library that links to Solera DeepSee Software application components. The Solera DeepSee Software includes Solera Operating Environment v6.5.0 as its operating system. It is designed to execute on a host platform with a General Purpose Computer (GPC) hardware platform. The Blue Coat Systems, Software Cryptographic Module can also be installed on a supported virtual machine hypervisor. The cryptographic module was tested and found compliant on the VMware ESXi Server 5.0 on a Dell PowerEdge R720 and on a Dell PowerEdge R720 with dual Intel Xeon processors. The following sections define the physical and logical boundary of the Software Cryptographic Module. While no claim can be made as to the correct operation of the module or the security strengths of the generated keys when ported to an operational environment which is not listed on the validation certificate, the vendor affirms that the module remains FIPS-complaint when executed on any of the supported platforms and environments:  Dell model R620  Dell model MD1200  VMware Workstation  VMware Player 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 platform. The physical boundary of the cryptographic module, whether running on a virtual hypervisor or on Dell R720 hardware, is defined by the hard enclosure around the host platform on which it runs. The module supports the physical interfaces of on the host platform. These interfaces include the integrated circuits of the system board, the CPU5, network adapters, RAM6, hard disk, device case, power supply, and fans. See Figure 2 for a Dell R720 block diagram. 4 EMI/EMC – Electromagnetic Interference / Electromagnetic Compatibility 5 CPU – Central Processing Unit 6 RAM – Random Access Memory Blue Coat Systems, Software Cryptographic Module Page 7 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 Figure 2 – Dell R720 Block Diagram 2.2.2 Logical Cryptographic Boundary Figure 3 shows a logical block diagram of the module executing in memory and its interactions with surrounding software components when in the hardware configuration. Figure 3 also shows the module’s logical cryptographic boundary. The module’s services are designed to be called by other Solera software components. Blue Coat Systems, Software Cryptographic Module Page 8 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 Figure 3 – Logical Block Diagram and Cryptographic Boundary for Hardware Configuration Figure 4 shows a logical block diagram of the module executing in memory and its interactions with surrounding software components when in the virtual configuration. Figure 4 also shows the module’s logical cryptographic boundary in the virtual configuration. The module’s services are designed to be called by other Solera software components. Blue Coat Systems, Software Cryptographic Module Page 9 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 Figure 4 – Logical Block Diagram and Cryptographic Boundary for Virtual Configuration 2.3 Module Interfaces The module’s logical interfaces exist at a low level in the software as an API. Both the API and physical interfaces can be categorized into the 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 Logical Interface Mappings FIPS Interface Physical Interface Module Interface (API) Data Input USB ports (keyboard, mouse, Arguments for API calls that contain data), network ports, serial data to be used or processed by the ports, SCSI/SATA ports module. Blue Coat Systems, Software Cryptographic Module Page 10 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 FIPS Interface Physical Interface Module Interface (API) Data Output Monitor, USB ports, network Arguments for API calls that contain or ports, serial ports, point to where the result of the function SCSI/SATA ports is stored. Control Input USB ports (keyboard, API Function calls and parameters that mouse), network ports, initiate and control the operation of the serial ports, power switch module. Status Output Monitor, network ports, Return values from API function calls and serial ports error messages. Power Input Power Interface N/A 2.4 Roles and Services The Software Cryptographic Module supports the following two roles for operators, as required by FIPS 140-2: Crypto-Officer (CO) role and User role. As allowed by FIPS 140-2, the module does not perform authentication of any operators. Both roles are implicitly assumed when services are executed. Note 1: Table 3 and Table 4 use the following definitions for entries in the “CSP7 and Type of Access” column. 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. 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 will have such parameters. Note 3: 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 Solera DeepSee Software interfaces. An operator assumes the CO role by invoking one of the following services: Table 3 – Crypto-Officer Services CSP and Type of Service Description Input Output Access Initialize FIPS Performs integrity checks and API call Status Integrity check mode power-up self-tests. Sets the parameters HMAC key, ANSI FIPS mode flag to on. X9.31 PRNG seed, ANSI X9.31 PRNG seed key Show status Returns the current mode of None Status None the module (FIPS or non-FIPS). 7 CSP – Critical Security Parameter Blue Coat Systems, Software Cryptographic Module Page 11 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 CSP and Type of Service Description Input Output Access Run self-tests on Performs power-up self-tests. None Status Integrity check demand HMAC key 2.4.2 User Role The operator in the User role is a consumer of the module’s security services. The role is assumed by invoking one of the following cryptographic services: Table 4 – User Services Service Description Input Output CSP and Type of Access ANSI X9.31 RNG8 Generate random Returns the specified number API call Status, number (ANSI of random bits to calling parameters random bits seed – RWX X9.31) application. ANSI X9.31 seed key – RX Generate a Generate and return a API call Status, key ANSI X9.31 RNG symmetric key symmetric key (AES, TDES). parameters, seed – RX ANSI X9.31, ANSI X9.31 seed key RNG seed – RX AES – R,W TDES – R, W Generate message Compute and return a API call Status, hash None digest (SHS9) message digest using SHS parameters, algorithms. message Generate keyed Compute and return a API call Status, hash HMAC key – RX hash (HMAC) message authentication code parameters, using HMAC-SHAx. key, message Zeroize key Zeroizes and de-allocates Reboot or Status AES key – W memory containing sensitive power cycle TDES key – W data. HMAC key – W RSA private/public key – W DSA private/public key – W DH10 components – W RNG seed – W Symmetric Encrypt plaintext using API call Status, AES key – RX encryption supplied key and algorithm parameters, ciphertext TDES key – RX specification (TDES or AES) key, plaintext 8 RNG – Random Number Generator 9 SHS – Secure Hash Standard 10 DH – Diffie-Hellman Blue Coat Systems, Software Cryptographic Module Page 12 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 Service Description Input Output CSP and Type of Access Symmetric Decrypt ciphertext using API call Status, AES key – RX decryption supplied key and algorithm parameters, plaintext TDES key – RX specification (TDES or AES) key, ciphertext Generate Generate and return the API call Status, key RSA private/public asymmetric specified type of asymmetric parameters pair key – W key pair key pair (RSA or DSA) DSA private/public key – W RSA key wrapping Wrap plaintext using RSA API call Status, RSA public key – RX public key (used for key parameters, ciphertext transport) key, plaintext RSA key Unwrap ciphertext using RSA API call Status, RSA private key – RX unwrapping private key (used for key parameters, plaintext transport) key, ciphertext Diffie-Hellman Perform Diffie-Hellman API call Status, key DH components – W primitive primitive implementation parameter components implementation* Signature Generate a signature for the API call Status, RSA private key – RX, Generation supplied message using the parameters, signature DSA private key – RX specified key and algorithm key, message (RSA or DSA) Signature Verify the signature on the API call Status RSA public key – RX Verification supplied message using the parameters, DSA public key – RX specified key and algorithm key, (RSA or DSA) signature, message *Diffie-Hellman primitive is implemented to perform in accordance with scenario 6 in section D.8 of FIPS 140-2 Implementation Guidance. This service is provided for calling process use and is not used to establish keys into the module. 2.4.3 Non-Approved Services The following cryptographic services listed in Table 5 are not allowed in FIPS-Approved mode. Table 5 – Non-Approved Services Service Cryptographic Function Symmetric encryption/decryption AES CFB1 Key establishment Elliptic Curve Diffie-Hellman Signature generation and verification Elliptic Curve DSA Blue Coat Systems, Software Cryptographic Module Page 13 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 2.5 Physical Security The Blue Coat Systems, Software Cryptographic Module is a software module, which FIPS defines as a multi-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 Environment The module was tested and found complaint on Solera Operating Environment v6.5.0, which is a proprietary OS and a Dell PowerEdge model R720 with dual Intel Xeon processors. The module was also tested and found complaint on Solera Operating Environment v6.5.0 running on VMware ESXi v5.0 on a Dell PowerEdge model R720 with dual Intel Xeon processors. 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. The tested operating system segregates user processes into separate process spaces. Each process space is an independent virtual memory area that is logically separated from all other processes. The Module functions entirely within the process space of the process that invokes it, and thus satisfies the FIPS 140-2 requirement for a single user mode of operation. 2.7 Cryptographic Key Management The module implements the FIPS-Approved algorithms listed in Table 6 below. Table 6 – FIPS-Approved Algorithm Implementations Algorithm Certificate Number Symmetric Key Algorithm AES in ECB11, CBC12, CFB813, CFB128 and OFB14 modes (128-,192-, 256-bits) 2153 Triple-DES in ECB, CBC, CFB8, CFB64, and OFB modes with 168-bit keys 1364 Asymmetric Key Algorithm RSA (ANSI X9.31) key generation (1024-, 1536-, 2048-, 3072-, 4096-bit keys) and signature generation/verification (1024-, 1536-, 2048-, 3072-, 4096-bit 1108 keys) RSA (PKCS15 #1.5) signature generation/verification (1024-, 1536-, 2048-, 1108 3072-, 4096-bit keys) RSA (PSS16) signature generation/verification (1024-, 1536-, 2048-, 3072-, 1108 4096-bit keys) DSA signature generation/verification and key generation 1024-bit key 669 Secure Hashing Algorithm (SHA) SHA-1, SHA-224, SHA-256, SHA-384, SHA-512 1873 Message Authentication Code (MAC) HMAC- SHA-1, -SHA-224, -SHA-256, -SHA-384, -SHA-512 1318 Pseudo Random Number Generation (PRNG) ECB – Electronic Codebook 11 CBC – Cipher-Block Chaining 12 CFB – Cipher Feedback 13 OFB – Output Feedback 14 PKCS – Public-Key Cryptography Standards 15 PSS – Probabilistic Signature Scheme 16 Blue Coat Systems, Software Cryptographic Module Page 14 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 Algorithm Certificate Number ANSI X9.31 Appendix A.2.4 PRNG with AES 128-, 192-, and 256-bit keys 1101 NOTE: The following security functions have been deemed “deprecated” or “restricted” by NIST. Please refer to NIST Special Publication 800-131A for further details.  two-key Triple DES for encryption  ANSI X9.31 PRNG  key lengths providing no more than 80 bits of security strength for digital signature generation The module provides the following non-FIPS-Approved algorithms that are allowed in the FIPS-Approved mode:  RSA key wrapping; key establishment methodology provides between 80 and 150 bits of encryption strength  Diffie-Hellman primitive implementation provides between 80 and 219 bits of encryption strength The module provides the following algorithms that are not allowed in the FIPS-Approved mode:  Elliptic Curve Diffie-Hellman  Elliptic Curve DSA  AES CFB1 The module supports the CSPs listed below in Table 7. Table 7 – List of Cryptographic Keys, Cryptographic Key Components, and CSPs Generation / Key Key Type Output Storage Zeroization Use Input RSA Private 1024-, 1536-, Internally API call Plaintext in By API call, Key exchange key 2048-, 3072-, generated parameter volatile power cycle, 4096-bit memory or host private keys reboot API call Never exits Plaintext in By API call, Signature parameter the module volatile power cycle, generation, memory or host key unwrapping1 reboot RSA Public 1024-, 1536-, Internally API call Plaintext in By API call, Key exchange Key 2048-, 3072-, generated parameter volatile power cycle, 4096-bit memory or host public keys reboot API call Never exits Plaintext in By API call, Signature parameter the module volatile power cycle, verification, memory or host key wrapping reboot Session Key AES 128-, API call Never exits Plaintext in By API call, Encryption, 192-, or 256- parameter the module volatile power cycle, decryption bit key in memory or host CBC, OFB, reboot Blue Coat Systems, Software Cryptographic Module Page 15 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 Generation / Key Key Type Output Storage Zeroization Use Input CFB, and Internally API call Plaintext in By API call, Encryption, ECB modes generated parameter volatile power cycle, decryption in memory or host Triple DES encrypted reboot 168-bit key in form CBC, ECB, CFB, and OFB mode Keying Option 1 (Three-key) ANSI X9.31 128 bits of Initialized by Never exits Plaintext in By API call, Generate a PRNG seed Random the module the module volatile power cycle, random value2 from an memory or host number external reboot NDRNG17 ANSI X9.31 AES 128-, Initialized by Never exits Plaintext in By API call, Generate a PRNG seed 192-, 256-bit the module the module volatile power cycle, random key value key from an memory or host number external reboot NDRNG HMAC Key 160-, 224-, API call Never exits Plaintext in By API call, Message 256-, 384-, parameter the module volatile power cycle, Authentication and 512-bit memory or host with SHA-1, - keys reboot 224, -256, - 384, -512 DSA public DSA 1024-bit API call Never exits Plaintext in By API call, Signature key key parameter the module volatile power cycle, Verification memory or host reboot DSA private DSA 160-bit API call Never exits Plaintext in By API call, Signature key key parameter the module volatile power cycle, Generation memory or host reboot DH public public key Internally API call Plaintext in By API call, Key exchange key generated parameter volatile power cycle, memory host reboot DH private private key Internally API call Plaintext in By API call, Key exchange key generated parameter volatile power cycle, memory host reboot 1 RSA key wrapping provides between 80 and 150 bits of encryption strength. 2 The entropy used by the FIPS-Approved ANSI X9.31 PRNG is acquired using an external, non-Approved NDRNG. 17 NDRNG – Non-Deterministic Random Number Generator Blue Coat Systems, Software Cryptographic Module Page 16 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 2.7.1 Key Generation The module uses an ANSI X9.31 Appendix A.2.4 PRNG implementation to generate cryptographic keys. This PRNG is FIPS-Approved as shown in Annex C to FIPS PUB 140-2 and complies with scenario one of IG 7.8. The ANSI X9.31 RNG is seeded using a seed key and seed gathered from a random pool filled with 48 bytes (estimated entropy strength on the tested system is 94 bits) of system data and internal resources such as time, user activity, and system activity. As the module’s ANSI X9.31 RNG implementation generates random values of size 128 bits, it would take multiple calls to form a 256-bit key. Since no reseeding operation occurs, the total estimated strength for the two calls required to form a 256-bit key is 94 bits of entropy. Caveat: The module generates cryptographic keys whose strengths are modified by available entropy – 94 bits. 2.7.2 Key Entry and Output The cryptographic module itself does not support key entry or key output from its physical boundary. 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 via the well-defined exported APIs. 2.7.3 Key/CSP Storage and Zeroization Symmetric, asymmetric, and HMAC keys are either provided by or delivered to the calling process, and are subsequently destroyed by the module at the completion of the API call. Keys and CSPs stored in RAM can be zeroized by a power cycle or a host platform reboot. The X9.31 PRNG seed and seed key are initialized by the module at power-up and remain stored in RAM until the module is uninitialized by a host platform reboot or power cycle. The HMAC key that is used to verify the integrity of the module is hard- coded within the module binary. Blue Coat Systems, Software Cryptographic Module Page 17 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 2.8 EMI/EMC The Software Cryptographic Module is a software module. Therefore, the only electromagnetic interference produced is that of the host platform on which the Software Cryptographic Module resides and executes. FIPS 140-2 requires that the host platforms 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 modules implement two types of self-tests: power-up self-tests and conditional self-tests. Upon any self-test failure, the module reboots. Power-up self-tests can also be performed on demand by cycling the power on the host platform, calling the function FIPS_selftest(), or by reinitializing the module using the FIPS_mode_set() function. 2.9.1 Power-Up Self-Tests The Software Cryptographic Module performs the following self-tests at power-up:  Software integrity check o This test calculates an HMAC SHA-1 digest of the module and compares it to the pre- calculated digest stored in the module’s associated digest file.  Known Answer Tests (KAT)s o AES KAT for encryption o AES KAT for decryption o Triple-DES KAT for encryption o Triple-DES KAT for decryption o RSA KAT for signature generation o RSA KAT for signature verification o SHA-1 KAT o HMAC SHA-1 KAT o HMAC SHA-224 KAT o HMAC SHA-256 KAT o HMAC SHA-384 KAT o HMAC SHA-512 KAT o ANSI X9.31 PRNG KAT  DSA pairwise consistency check SHA-224, SHA-256, SHA-384, and SHA-512 do not have individual KATs, but are tested as part of their respective HMAC KATs. The RSA KAT test is a single function call that performs tests of both signature generation and signature verification. The DSA pairwise consistency check also is a single function that tests both signature generation and signature verification. 2.9.2 Conditional Self-Tests The Software Cryptographic Module performs the following conditional self-tests:  Continuous RNG test  RSA pairwise consistency check for sign/verify and encrypt/decrypt  DSA pairwise consistency check If a conditional self-test fails, the module will enter an error state, during which cryptographic functionality and all data output is inhibited. To clear the error state, the CO must reinitialize the module. Blue Coat Blue Coat Systems, Software Cryptographic Module Page 18 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 2.10 Mitigation of Other Attacks This section is not applicable. The modules do not claim to mitigate any attacks beyond the FIPS 140-2 Level 1 requirements for this validation. Blue Coat Blue Coat Systems, Software Cryptographic Module Page 19 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 3 Secure Operation The Blue Coat Systems, Software 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 FIPS 140-2 mandates that a software cryptographic module at Security Level 1 be restricted to a single operator mode of operation. Solera DeepSee Software, by default configures the Solera Operating Environment for single-user mode. The Software Cryptographic Module is installed as part of the installation of Solera DeepSee Software. The CO should follow the installation procedures found in the Solera Networks DeepSee Administration Guide Chapter 1: Installation and Configuration. 3.2 Secure Management The following paragraphs describe the steps necessary to ensure that the Software Cryptographic Module is running in a FIPS-Approved manner. 3.2.1 Initialization The Solera Software applications provided in Solera DeepSee Software v6.5.0 will ensure the module is configured in the FIPS-Approved mode prior use. An integrity check is performed for the module automatically when FIPS mode is set. This is achieved by calling a single initialization function FIPS_mode_set(). Upon initialization of the module, the module requires no set-up and runs its power-up self-tests automatically without operator interference. The power-up self-tests include a software integrity test that checks the integrity of the module using an HMAC SHA-1 digest. If the integrity check succeeds, then the module performs the remaining power-up self-tests. If the module passes all self-tests the function returns a value of “1”, which indicates that the module is in a FIPS-Approved mode of operation. If the function returns “0” that indicates failure of the tests. 3.2.2 Management The Crypto-Officer can call verify that the module is operating in a FIPS-Approved mode of operation with the fips_mode flag. Self-tests can be performed on demand by cycling the power on the host platform, or by the function call FIPS_selftest(). 3.2.3 Zeroization The module does not persistently store any key or CSPs. All ephemeral keys used by the module are zeroized upon session termination. All keys can be zeroized by power cycling or rebooting the host platform. 3.2.4 User Guidance The Software Cryptographic Module is designed for use by Solera DeepSee Software applications. The module does not input, output, or persistently store CSPs with respect to the physical boundary. As the module allows access to cryptographic services that are not FIPS-Approved or that provide less than the minimum NIST-recommended encryption strength, it is the responsibility of the calling application developer to ensure that only appropriate algorithms, key sizes, and key establishment techniques are applied. Users are responsible for using only the services that are listed in Table 4. Any use of the Blue Coat Systems, Software Cryptographic Module with non-FIPS-Approved cryptographic services or keys that provide less than 112 bits of encryption strength constitutes a departure from this Security Policy, and results in the module not being in its Approved mode of operation. Blue Coat Blue Coat Systems, Software Cryptographic Module Page 20 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 4 Acronyms This section describes the acronyms. Table 8 – Acronyms Acronym Definition AES Advanced Encryption Standard ANSI American National Standards Institute API Application Programming Interface APT Advanced Persistent Threats ATA Advanced Targeted Attacks BIOS Basic Input/Output System CAST Carlisle Adams and Stafford Tavares CBC Cipher Block Chaining CFB Cipher Feedback CMVP Cryptographic Module Validation Program CO Crypto-Officer CPU Central Processing Unit CSEC Communications Security Establishment Canada CSP Critical Security Parameter DES Data Encryption Standard DH Diffie-Hellman DSA Digital Signature Algorithm DVD Digital Video Disc ECB Electronic Codebook EMC Electromagnetic Compatibility EMI Electromagnetic Interference FCC Federal Communications Commission FIPS Federal Information Processing Standard GBPS Gigabits per Second GPC General Purpose Computer HDD Hard Disk Drive HMAC Hash Message Authentication Code IDEA International Data Encryption Algorithm IT Information Technology KAT Known Answer Test Blue Coat Blue Coat Systems, Software Cryptographic Module Page 21 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.8 October 23, 2013 Acronym Definition KDF Key Derivation Function MD Message Digest MDC Modification Detection Code NDRNG Non-Deterministic Random Number Generator NIST National Institute of Standards and Technology OFB Output Feedback OS Operating System PCAP Packet Capture PCI Peripheral Component Interconnect PICe PCI express PKCS Public-Key Cryptography Standard PRNG Psuedo Random Number Generator PSS Probabilistic Signature Scheme RACE Research and Development in Advanced Communications Technologies in Eurpoe RAM Random Access Memory RC Rivest Cipher RipeMD RACE Integrity Primitives Evaluation Message Digest RNG Random Number Generator RSA Rivest, Shamir, and Adleman SATA Serial Advanced Technology Attachment SCSI Small Computer System Inteface SHA Secure Hash Algorithm SHS Secure Hash Standard TDES Triple Data Encryption Standard TLS Transport Layer Security USB Universal Serial Bus Blue Coat Blue Coat Systems, Software Cryptographic Module Page 22 of 23 © 2013 Blue Coat Systems, Inc. This document may be freely reproduced and distributed whole and intact including this copyright notice. Prepared by: Corsec Security, Inc. 13135 Lee Jackson Memorial Highway Suite 220 Fairfax, VA 22033 Phone: +1 (703) 267-6050 Email: info@corsec.com http://www.corsec.com