Totemo AG Totemo Cryptographic Module (TCM) Software Version: 2.0 FIPS 140-2 Non-Proprietary Security Policy FIPS Security Level: 1 Document Version: 1.0 Prepared for: Prepared by: Totemo AG Corsec Security, Inc. Freihofstrasse 22 13135 Lee Jackson Memorial Hwy., Suite 220 CH-8700 Küsnacht Fairfax, VA 22033 Switzerland United States of America Phone: +41 (0)44 914 9900 Phone: +1 (703) 267-6050 Email: support@totemo.com Email: info@corsec.com http://www.totemo.com http://www.corsec.com Security Policy, Version 1.0 December 20, 2012 Table of Contents 1 INTRODUCTION ................................................................................................................... 3 1.1 PURPOSE ................................................................................................................................................................ 3 1.2 REFERENCES .......................................................................................................................................................... 3 1.3 DOCUMENT ORGANIZATION ............................................................................................................................ 3 2 TOTEMO CRYPTOGRAPHIC MODULE ............................................................................. 4 2.1 OVERVIEW ............................................................................................................................................................. 4 2.1.1 Totemo Product Overview ...................................................................................................................................4 2.1.2 Totemo Cryptographic Module Overview .......................................................................................................5 2.2 MODULE SPECIFICATION ..................................................................................................................................... 6 2.2.1 Physical Cryptographic Boundary ......................................................................................................................6 2.2.2 Logical Cryptographic Boundary ........................................................................................................................7 2.3 MODULE INTERFACES .......................................................................................................................................... 8 2.4 ROLES AND SERVICES ........................................................................................................................................... 9 2.4.1 Crypto Officer Role ................................................................................................................................................9 2.4.2 User Role ................................................................................................................................................................ 10 2.5 PHYSICAL SECURITY ...........................................................................................................................................11 2.6 OPERATIONAL ENVIRONMENT.........................................................................................................................11 2.7 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................................................12 2.8 EMC/EMI ............................................................................................................................................................17 2.9 SELF-TESTS ..........................................................................................................................................................17 2.9.1 Power-Up Self-Tests ............................................................................................................................................ 17 2.9.2 Conditional Self-Tests ......................................................................................................................................... 17 2.9.3 Critical Functions Self-Tests .............................................................................................................................. 18 2.10 MITIGATION OF OTHER ATTACKS ..................................................................................................................18 3 SECURE OPERATION ......................................................................................................... 19 3.1 CRYPTO OFFICER GUIDANCE ..........................................................................................................................19 3.1.1 Initial Setup ........................................................................................................................................................... 19 3.2 USER GUIDANCE ................................................................................................................................................19 4 ACRONYMS .......................................................................................................................... 20 Table of Figures FIGURE 1 – TOTEMO SECURITY PLATFORM ...........................................................................................................................4 FIGURE 2 – NSA 7110 HARDWARE APPLIANCE BLOCK DIAGRAM ...................................................................................7 FIGURE 3 – TOTEMO CRYPTOGRAPHIC MODULE LOGICAL BLOCK DIAGRAM AND CRYPTOGRAPHIC BOUNDARY .8 List of Tables TABLE 1 – SECURITY LEVEL PER FIPS 140-2 SECTION .........................................................................................................5 TABLE 2 – FIPS 140-2 LOGICAL INTERFACE MAPPINGS ......................................................................................................9 TABLE 3 – CRYPTO OFFICER SERVICES ................................................................................................................................ 10 TABLE 4 – USER SERVICES ..................................................................................................................................................... 10 TABLE 5 – FIPS-APPROVED ALGORITHM IMPLEMENTATIONS .......................................................................................... 12 TABLE 6 – LIST OF CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS ................................. 14 TABLE 7 – ACRONYMS .......................................................................................................................................................... 20 Totemo Cryptographic Module (TCM) Page 2 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the Totemo Cryptographic Module from Totemo AG. This Security Policy describes how the Totemo 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 Totemo Cryptographic Module is referred to in this document as Totemo TCM, crypto-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 Totemo website (http://www.totemo.ch) contains information on the full line of products from Totemo. • 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 • Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to Totemo. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Submission Package is proprietary to Totemo and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact Totemo. Totemo Cryptographic Module (TCM) Page 3 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 2 Totemo Cryptographic Module 2.1 Overview 2.1.1 Totemo Product Overview Totemo AG is a leading provider of secure email, file transfer, and mobile messaging solutions to enterprise customers and government agencies that need to securely exchange information Totemo information. develops applications that secure data transfers regardless of protocol or application; throughout entire systems and networks. Totemo products are designed to be easy to implement, simple to administer and Totemo’s ducts understand, and require minimal changes in existing network infrastructures. infrastructures At the core of each of Totemo’s products is the Totemo Security Platf ’s Platform (TSP). The TSP is a dynamic, expandable security architecture that is based on interoperable standards which protects all data in motion motion, as well as data at rest. The TSP provides security features such as encryption and decryption, authentication and authorization, certificate and key management, and centralized administration. The d administration TSP, a Java-based pluggable application is platform-independent, highly scalable, transparent to end users, application, independent, and aligned for future developments. TSP is the cryptographic key and digital certificate management developments c component of TrustMail®, TrustDEX, and Transcoder for BlackBerry®. , Figure 1 provides a high-level overview of the TSP and the services it provides as well as sample level he deployment environments. Figure 1 – Totemo Security Platform Secure email is provided by TrustMail, a Secure Messaging Gateway for enterprises and professionals e TrustMail, alike. TrustMail leverages the native encryption and digital signature features that exist in most mail clients in order to allow members of an organization to encrypt messages to recipients for which they do Totemo Cryptographic Module (TCM) Page 4 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 not possess a public key. TrustMail integrates with many mail servers, including Exchange, in order to provide temporary “proforma certificates” to the mail client as substitutes for these missing public keys. TrustDEX provides a solution to secure file transfer. Like TrustMail, TrustDEX utilizes the same centralized security management features of TSP in order to allow members of an organization to exchange large quantities of data without requiring them to become experts on encryption, file transmission protocols, or discretionary access control techniques. TrustDEX allows users to use virtually any file transmission protocol to upload and download data to the server, while centrally managing access to that data as well as replication and distribution of that data using complex, yet easy-to-configure, business process workflows. Totemo Transcoder for BlackBerry provides an additional layer of security by providing protection on not just emails, but data encryption on all traffic between a BlackBerry Enterprise Server and a BlackBerry device. It is easily integrated into existing system environments. As with the other products, the Transcoder leverages the security services and certificate management features of the TSP in order to provide the end-to-end encryption between BlackBerry Devices and BlackBerry Enterprise Server using public-key cryptography. 2.1.2 Totemo Cryptographic Module Overview The Totemo Cryptographic Module is a Java-based cryptographic library placed at the heart of the TSP, providing encryption, decryption, key production, signature generation and verification, and other cryptographic services to the TSP. TrustMail, TrustDEX, and Transcoder for Blackberry are also written in Java, each incorporating the security features provided by the TSP, which utilizes the Java Cryptography Architecture (JCA)/Java Cryptography Extension (JCE) framework in order to implement cryptographic functionality. By coding their products in Java, Totemo aims to make them platform-agnostic. The Totemo Cryptographic Module is a FIPS module evaluated for overall FIPS Security Level 1, as shown in Table 1. 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 EMI/EMC1 8 1 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A 1 EMI/EMC – Electromagnetic Interference / Electromagnetic Compatibility Totemo Cryptographic Module (TCM) Page 5 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 2.2 Module Specification The Totemo Cryptographic Module is a software module with a multi-chip standalone embodiment. The overall security level of the module is 1. The TCM is used by calling applications to provide symmetric/asymmetric cipher operation, signature generation/verification, hashing, cryptographic key generation, random number generation, and message authentication functions. The cryptographic boundary of the TCM consists of the shared Java library that is linked with the Totemo Security Platform. It is designed to execute in a Java Runtime Environment (JRE) installed on Totemo’s own Operating System (Totemo Appliance OS 2.0 v0711). The module was tested and found compliant on an Apligo NSA 7110 hardware appliance running Totemo Appliance OS2 2.0 v0711 and two Intel Xeon Quad-Core E5504 processors. The TCM is defined as a software cryptographic module and therefore has a logical boundary in addition to a physical boundary. The physical and logical boundaries are outlined in section 2.2.1 and 2.2.2 respectively. 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 appliance on which it runs. The module supports the physical interfaces of the NSA 7110. These interfaces include the integrated circuits of the system board, the CPU3, network adapters, RAM4, hard disk, device case, power supply, and fans. Other devices may be attached to the appliance, such as a display monitor, keyboard, mouse, printer, or storage media. Figure 2 is a block diagram representing the NSA 7110 hardware appliance. The physical cryptographic boundary is defined by the red dotted line. The TCM is stored on the HDD5 and is loaded into RAM by the OS for execution after the host system powers up. The module will reside in RAM while executing until the host system is powered off or until it is unloaded by the OS. 2 OS – Operating System 3 CPU – Central Processing Unit 4 RAM – Random Access Memory 5 HDD – Hard Disk Drive Totemo Cryptographic Module (TCM) Page 6 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 Figure 2 – NSA 7110 Hardware Appliance Block Diagram6 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, as well as the module’s logical cryptographic boundary. The module’s services are designed to be called by the Totemo Application Software, which define the module’s logical interfaces. 6 LED – Light Emitting Diode; LCD – Liquid Crystal Display; LAN – Local Area Network; USB – Universal Serial Bus Totemo Cryptographic Module (TCM) Page 7 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 Figure 3 – Totemo Cryptographic Module Logical Block Diagram and Cryptographic Boundary 2.3 Module Interfaces The module’s physical ports can be categorized into the following logical interfaces defined by FIPS 140-2: • Data input • Data output • Control input • Status output As a software module, the module doesn’t have any physical characteristics. The module’s physical and electrical characteristics, manual controls, and physical indicators are those of the host system. The mapping of the module’s logical interfaces in the software to the physical interfaces of the NSA 7110 is described in Table 2 below. Totemo Cryptographic Module (TCM) Page 8 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 Table 2 – FIPS 140-2 Logical Interface Mappings FIPS Interface Physical Interface Logical Interface Data Input USB ports(2), network Arguments for library functions ports(8), RJ45 console that specify plaintext data, port(1), management LAN ciphertext, digital signatures, port (1) cryptographic keys (plaintext or encrypted), initialization vectors, and passwords that are to be input to and processed by the cryptographic module. Data Output Network ports(8), RJ45 Arguments for library functions console port(1), that receive plaintext data, management LAN port (1) ciphertext data, digital signatures, cryptographic keys (plaintext or encrypted), and initialization vectors from the cryptographic module. Control Input USB ports(2), network Arguments for library functions ports(8), RJ45 console that initiate and control the port(1), management LAN operation of the module, such port (1) as arguments that specify commands and control data (e.g., algorithms, algorithm modes, digest type, or module settings). Status Output Network ports(8), RJ45 Function return codes, error console port(1), codes, or output arguments management LAN port that receive status information (1); LED(18) used to indicate the status of the cryptographic module. 2.4 Roles and Services There are two roles in the module (as required by FIPS 140-2) that operators may assume: a Crypto Officer role and a User role. The module does not allow multiple concurrent operators while in a FIPS-Approved mode of operation. Please note that the keys and Critical Security Parameters (CSPs) listed in the tables in the following sections indicate the type of access required using the following notation: • R – Read: The CSP is read. • W – Write: The CSP is established, generated, modified, or zeroized. • X – Execute: The CSP is used within an Approved or Allowed security function or authentication mechanism. 2.4.1 Crypto Officer Role The Crypto Officer role is in charge of installing and initializing the module for first use, checking the status of the module, and running self-tests on demand. Descriptions of the services available to the Crypto Officer role are provided in Table 3 below. Totemo Cryptographic Module (TCM) Page 9 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 Table 3 – Crypto Officer Services Service Description CSP and Type of Access Initialize module Performs integrity check and None power-up self-tests Show status Returns the current mode of the None module Run self-tests on demand Performs power-up self-tests None Zeroize keys Zeroizes and de-allocates memory AES key – W containing sensitive data AES CMAC Key –W Triple- DES key – W Triple-DES CMAC Key – W HMAC key – W RSA private/public key – W DSA private/public key – W ECDSA private/public key – W DH7 public/private components –W ECMQV public/private components – W DRBG Seed – W DRBG Entropy – W DRBG C value – W DRBG V value – W 2.4.2 User Role The User role has the ability to perform symmetric and asymmetric encryption and decryption, signature generation and verification, hashing, cryptographic key generation, random number generation, and message authentication, among other cryptographic services. Descriptions of the services available to the User role are provided in Table 4. Table 4 – User Services Service Description CSP and Type of Access Generate random number Returns the specified number of DRBG Seed – R,W,X random bits to calling application DRBG ‘C’ Value – R,W DRBG ‘V’ Value – R,W DRBG Entropy – R,W,X Generate message digest Compute and return a message None digest using SHS algorithms Generate keyed hash (HMAC) Compute and return a message HMAC key – RX authentication code Generate Cipher Hash (CMAC) Compute and return a cipher AES CMAC Key – RXTriple- message authentication code DES CMAC Key – RX 7 DH – Diffie-Hellman Totemo Cryptographic Module (TCM) Page 10 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 Service Description CSP and Type of Access Generate symmetric key Generate and return the specified AES key – W type of symmetric key (Triple-DES Triple-DES Key – W or AES) Symmetric encryption Encrypt plaintext using supplied AES key – RX key and algorithm specification Triple-DES key – RX (Triple-DES or AES) Symmetric decryption Decrypt ciphertext using supplied AES key – RX key and algorithm specification Triple-DES key – RX (Triple-DES or AES) Generate asymmetric Generate and return the specified RSA private/public key – W key pair type of asymmetric key pair (RSA, DSA private/public key – W DSA, or ECDSA) ECDSA private/public key – W Key Agreement Perform key agreement using DH, DH Public/Private components ECDH, and ECMQV – WRX ECDH Public/Private components – WRX ECMQV Public/Private components – RX Key Wrapping Perform key wrap with RSA public RSA public Key – RX key, AES key, or Triple-DES Key AES Key – RX Triple-DES Key – RX Key Unwrapping Perform key unwrap with RSA RSA private Key – RX private key, AES key, or Triple- AES Key – RX DES Key Triple-DES Key – RX Signature Generation Generate a signature for the RSA private key – RX supplied message using the DSA private key – RX specified key and algorithm (RSA, ECDSA private key – RX DSA, or ECDSA) Signature Verification Verify the signature on the RSA public key – RX supplied message using the DSA public key – RX specified key and algorithm (RSA, ECDSA public key – RX DSA, or ECDSA) 2.5 Physical Security The Totemo Cryptographic Module (TCM) 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 Totemo Cryptographic Module was tested and found to be compliant with FIPS 140-2 requirements on an Intel Xeon E5504 processor. The processor executes Totemo Appliance OS 2.0 v0711 on which JRE 7.0 is executing. The TCM and Totemo software applications using the TCM will be loaded into and executed by a Java Virtual Machine (JVM) provided by the JRE. Totemo Cryptographic Module (TCM) Page 11 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 2.7 Cryptographic Key Management The module implements the FIPS-Approved algorithms listed in Table 5 below. Table 5 – FIPS-Approved Algorithm Implementations Certificate Algorithm Number AES in ECB8, CBC9, CFB-12810, OFB11, CCM12, CMAC13, GCM14 2059 modes encrypt/decrypt with 128-, 192- and 256-bit keys Triple-DES in ECB, CBC, CFB-8, CFB-64, CMAC modes 1326 encrypt/decrypt; KO15 1, 2 RSA (FIPS 186-3) Key Generation with 2048- and 3072-bit key 1071 range RSA (PKCS #1 v1.5) Signature Generation and Verification 1071 16 RSA (PSS ) Signature Generation and Verification 1071 17 DSA (FIPS 186-3) Key Generation with 2048- and 3072-bit 652 keys DSA Signature Generation and Verification 652 18 ECDSA Key Generation with NIST Recommended Curves: P- 302 224, P-256, P-384, and P-521 ECDSA Signature Generation and Verification 302 19 SHA -1, SHA-224, SHA-256, SHA-384, SHA-512 hash 1800 HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC- 1252 SHA-512 keyed hash SP20 800-90A HASH_DRBG 206 The use of SHA-1 in the FIPS-Approved mode of operation shall be limited to random number generation and signature verification. The use of TDES Keying Option 2 is restricted to legacy use, for decryption only. The cryptographic module implements the following non-Approved key-establishment algorithms, which are allowed for use in a FIPS-Approved mode of operation: • RSA (2048- to 4096-bit keys; key wrapping; key establishment methodology provides 112 to 15021 bits of encryption strength) 8 ECB – Electronic Codebook 9 CBC – Cipher Block Chaining 10 CFB – Cipher Feedback 11 OFB – Output Feedback 12 CCM – Counter with CBC-MAC 13 CMAC – Cipher-based Message Authentication Code 14 GCM – Galois/Counter Mode 15 KO – Keying Option 16 PSS – Probabilistic Signature Scheme 17 DSA – Digital Signature Algorithm 18 ECDSA – Elliptic Curve DSA 19 SHA – Secure Hashing Algorithm 20 SP – Special Publication Totemo Cryptographic Module (TCM) Page 12 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 • Diffie-Hellman (key agreement; key establishment methodology provides 112 bits of encryption strength) ECDH22 (key agreement; key establishment methodology provides 112 bits of encryption • strength) ECMQV23 (key agreement; key establishment methodology provides 112 bits of encryption • strength) • AES (Cert# 2059, key wrapping; key establishment methodology provides 128 to 256 bits of encryption strength) • Triple-DES (Cert# 1326, key wrapping; key establishment methodology provides 80 or 112 bits of encryption strength) 21 Calculated using Equation 1 of FIPS 140-2 IG 7.5 22 ECDH – Elliptic Curve Diffie-Hellman 23 ECMQV – Elliptic Curve Menezes-Qu-Vanstone Totemo Cryptographic Module (TCM) Page 13 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 The module supports the critical security parameters (CSPs) listed below in Table 6. Internally generated keys and CSPs listed in Table 6 are generated with an Approved Random Number Generator. Table 6 – List of Cryptographic Keys, Cryptographic Key Components, and CSPs Key Key Type Generation / Input Output Storage Zeroization Use AES key AES128-, 192-, 256- API call parameter or Output via GPC Plaintext in volatile Unload module, Encryption, bit key internally generated internal path memory power cycle Decryption AES CMAC Key AES CMAC 128-, API call parameter Output via GPC Plaintext in volatile Unload module, Message 192-, 256-bit key internal path memory power cycle Authentication with AES AES GCM IV24 Random data Internally generated Never Keys are not Unload module; IV input to AES GCM persistently stored API call; function by the module Remove Power Triple-DES key25 Triple-DES 192-bit API call parameter or Output via GPC Plaintext in volatile Unload module, Encryption, key internally generated internal path memory power cycle decryption Triple-DES CMAC Triple-DES CMAC API call parameter Output via GPC Plaintext in volatile Unload module, Message Key 192-bit key internal path memory power cycle Authentication with Triple-DES HMAC key 128- to 512-bit API call parameter Output via GPC Plaintext in volatile Unload module, Message HMAC Key internal path memory power cycle Authentication with SHA-2 family RSA private key RSA 2048-, 3072-, API call parameter or Output via GPC Plaintext in volatile Unload module, Signature generation, 4096-bit key internally generated internal path memory power cycle decryption RSA public key RSA 2048-, 3072-, API call parameter or Output via GPC Plaintext in volatile Unload module, Signature verification, 4096-bit key internally generated internal path memory power cycle encryption DSA private key DSA 2048-, 3072-, API call parameter or Output via GPC Plaintext in volatile Unload module, Signature generation, 4096-bit key internally generated internal path memory power cycle decryption 24 The module was tested and validated with IVs in the range of 8 to 1024 bits. In the FIPS Mode of Operation, the IV length is restricted to 96 bits or greater. 25 The module was tested and validated with TDES Keying Options 1 (3-Key) and 2 (2-Key). Use of the 2-Key option shall be restricted to legacy use, for decryption only. Totemo Cryptographic Module (TCM) Page 14 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 Key Key Type Generation / Input Output Storage Zeroization Use DSA public key DSA 2048-, 3072-, API call parameter or Output via GPC Plaintext in volatile Unload module, Signature verification, 4096-bit key internally generated internal path memory power cycle encryption ECDSA private key ECDSA Key from API call parameter or Output via GPC Plaintext in volatile Unload module, Signature generation, NIST Recommended internally generated internal path memory power cycle decryption Curves: P-224, P- 256, P-384, and P- 521 ECDSA public key ECDSA Key from API call parameter or Output via GPC Plaintext in volatile Unload module, Signature verification, NIST Recommended internally generated internal path memory power cycle encryption Curves: P-224, P- 256, P-384, and P- 521 DH public Public components of API call parameter or Output via GPC Plaintext in volatile Unload module, Establish Secure SSH components DH protocol Internally generated internal path memory power cycle session DH private Private component API call parameter or Output via GPC Plaintext in volatile Unload module, Establish Secure SSH component of DH protocol Internally generated internal path memory power cycle session ECDH public Public components of API call parameter or Output via GPC Plaintext in volatile Unload module, Establish Secure SSH components ECDH protocol Internally generated internal path memory power cycle session ECDH private Private component API call parameter or Output via GPC Plaintext in volatile Unload module, Establish Secure SSH component of ECDH protocol Internally generated internal path memory power cycle session ECMQV public Public components of API call parameter or Output via GPC Plaintext in volatile Unload module, Key Agreement components ECDH protocol Internally generated internal path memory power cycle Key Establishment ECMQV private Private component API call parameter or Output via GPC Plaintext in volatile Unload module, Key Agreement component of ECDH protocol Internally generated internal path memory power cycle Key Establishment DRBG Seed 880-bit random value API call parameter or Never Plaintext in volatile Unload module, Seed input to SP Internally generated memory power cycle 800-90 Hash_DRBG DRBG Entropy 440-bit random value API call parameter or Never Plaintext in volatile Unload module, Entropy input to SP Internally generated memory power cycle 800-90 Hash_DRBG Totemo Cryptographic Module (TCM) Page 15 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 Key Key Type Generation / Input Output Storage Zeroization Use Hash DRBG V value Internal hash DRBG Internally generated Never Plaintext in volatile Unload module, Used for SP 800-90 state value memory power cycle Hash_DRBG Hash DRBG C value Internal hash DRBG Internally generated Never Plaintext in volatile Unload module, Used for SP 800-90 state value memory power cycle Hash_DRBG Totemo Cryptographic Module (TCM) Page 16 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 2.8 EMC/EMI The Totemo Cryptographic Module is a software module. Therefore, the only electromagnetic interference produced is that of the host platform on which the module 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 Totemo Cryptographic Module performs self-tests automatically each time the host appliance is powered on and a host application loads it into memory. Conditional self tests are performed each time the module needs to generate a new random number or a new asymmetric key pair. The module’s random bit generator will perform critical function tests as needed to assure its security. Should any self-test fail, the module’s data output interfaces will be inhibited. Only control input and status output commands will be allowed to execute. For errors encountered during conditional pairwise consistency checking, the module will enter a soft error state, which will clear any random bit or keying information and return to normal operation. For all other errors, the module will halt and must be reloaded into memory by either restarting the host application or rebooting the appliance. 2.9.1 Power-Up Self-Tests The Totemo Cryptographic Module performs the following self-tests at power-up: • Software integrity check using RSA 2048 digital signature verification with SHA-256 hash • Known Answer Tests (KATs) o AES KAT o AES-CMAC KAT o Triple-DES KAT o Triple-DES-CMAC KAT o RSA Signature Generation KAT o RSA Signature Verification KAT o DSA Pairwise Consistency Test o ECDSA Pairwise Consistency Test o SHA-1 KAT o SHA-224 KAT o SHA-256 KAT o SHA-384 KAT o SHA-512 KAT o HMAC SHA-224 KAT o HMAC SHA-256 KAT o HMAC SHA-384 KAT o HMAC SHA-512 KAT o SP 800-90A HASH_DRBG KAT 2.9.2 Conditional Self-Tests The Totemo Cryptographic Module performs the following conditional self-tests: • Continuous Random Number Generator Test for the SP 800-90A HASH_DRBG • Continuous Random Number Generator Test for the NDRNG entropy source • RSA Pairwise Consistency Test for signature generation and verification • RSA Pairwise Consistency test for wrapping and unwrapping • DSA Pairwise Consistency test for signature generation and verification Totemo Cryptographic Module (TCM) Page 17 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 • ECDSA Pairwise Consistency test for signature generation and verification 2.9.3 Critical Functions Self-Tests The Totemo Cryptographic Module implements the SP 800-90A HASH_DRBG as its random number generator. This DRBG employs two critical functions which must also be tested on a regular basis to ensure the security of the SP 800-90A DRBG. Therefore, the following critical function tests are also implemented by the crypto module: o DRBG Instantiate Critical Function Test o DRBG Reseed Critical Function Test o DRBG Generate Critical Function Test o DRBG Uninstantiate Critical Function Test 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. Totemo Cryptographic Module (TCM) Page 18 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 3 Secure Operation The Totemo 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 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. The 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 by the operating system software and hardware. 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. 3.1.1 Initial Setup The Totemo Cryptographic Module is one of many components of the Totemo Security Platform, which is delivered as part of a Totemo host application. The Crypto Officer shall follow the installation procedures of the host software application to ensure proper installation and operation of the TCM. Detailed documentation on installing, uninstalling, configuring, managing and upgrading the host application is provided as part of the product documentation set. To place the Totemo Cryptographic Module into a FIPS-Approved mode of operation the JRE system property “tsp.tcm.fipsMode” shall be set to “FIPS”. This can be done via the CLI26 (use Java startup option -Dtsp.tcm.fipsMode=FIPS), by modifying the JRE system property file directly, or programmatically using the Java API for setting system properties. 3.2 User Guidance The Totemo Cryptographic Module is designed for use by the Totemo Security Platform. The TCM does not have the ability to input or output CSPs beyond its physical boundary, nor does it persistently store CSPs within its logical boundary. However, the module may store CSPs within the physical boundary of the host system on which it runs. Operators are responsible for providing persistent storage of the cryptographic keys and CSPs, and to ensure that keys are transmitted outside the physical cryptographic boundary in the appropriate manner. 26 CLI – Command Line Interface Totemo Cryptographic Module (TCM) Page 19 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 4 Acronyms This section describes the acronyms. Table 7 – Acronyms Acronym Definition AES Advanced Encryption System CBC Cipher Block Chaining CFB Cipher Feedback CLI Command Line Interface CMVP Cryptographic Module Validation Program CPU Central Processing Unit CSEC Communications Security Establishment Canada CSP Critical Security Parameter DES Data Encryption Standard DH Diffie-Hellman DRBG Deterministic Random Bit Generator ECB Electronic Code Book ECDH Elliptic Curve Diffie-Hellman ECMQV Elliptic Curve Menezes–Qu–Vanstone EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standard GPC General Purpose Computer GUI Graphical User Interface HDD Hard Disk Drive HMAC (Keyed) Hash Message Authentication Code JCA Java Cryptography Architecture JCE Java Cryptography Environment JRE Java Runtime Environment JVM Java Virtual Machine KAT Known Answer Test LAN Local Area Network LCD Liquid Crystal Display LED Light Emitting Diode MQV Menezes–Qu–Vanstone Totemo Cryptographic Module (TCM) Page 20 of 22 © 2012 Totemo AG This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.0 December 20, 2012 Acronym Definition NIST National Institute of Standards and Technology NVLAP National Voluntary Laboratory Accreditation Program OFB Output Feedback OS Operating System PKCS Public Key Cryptography Standard PSS Probabilistic Signature Scheme RAM Random Access Memory RSA Rivest Shamir and Adleman SHA Secure Hash Algorithm SHS Secure Hash Standard SP Special Publication TCM Totemo Cryptography Module TSP Totemo Security Platform USB Universal Serial Bus Totemo Cryptographic Module (TCM) Page 21 of 22 © 2012 Totemo AG 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 Highway Fairfax, VA 22033 United States of America Phone: +1 (703) 267-6050 Email: info@corsec.com http://www.corsec.com