CCORE Module FIPS 140-2 Level 1 Security Policy Document Version: 4.1 Date: April 13, 2010 Prepared for: CellCrypt Limited Revision History Version Date Author 0.1 07-11-2008 C. Davies (Cell Telecom Ltd.) 0.2 07-27-2008 C. Davies (Cell Telecom Ltd.) 0.3 08-12-2008 C. Davies (Cell Telecom Ltd.) 0.4 11-12-2008 C. Davies (Cell Telecom Ltd.) 1.0 11-12-2008 C. Davies (Cell Telecom Ltd.) 2.0 19-12-2008 C. Davies (Cell Telecom Ltd.) 3.0 22-12-2008 Saffire Systems 3.1 12-01-2009 Saffire Systems 3.2 16-01-2009 Saffire Systems 3.3 02-02-2009 Saffire Systems 3.4 02-18-2009 Saffire Systems 3.5 05-01-2009 Saffire Systems 3.6 06-11-2009 Saffire Systems 3.7 06-17-2009 Saffire Systems 3.8 06-30-2009 Saffire Systems 4.0 01-27-2010 Saffire Systems 4.1 04-13-2010 J. Smith (CygnaCom Solutions) Table of Contents 1 Introduction ............................................................................................................. 1 1.1 Purpose .......................................................................................................... 1 1.2 Security Level Summary ................................................................................ 1 2 CCORE Module Specification................................................................................. 1 2.1 Hardware Platform ......................................................................................... 2 2.2 Module Boundary ........................................................................................... 2 2.3 FIPS-Approved Mode of Operation ................................................................ 4 3 Ports and Interfaces................................................................................................ 4 4 Roles, Services and Authentication ........................................................................ 5 5 Physical Security..................................................................................................... 7 6 Operational Environment ........................................................................................ 7 7 Cryptographic Key Management ............................................................................ 8 7.1 FIPS Approved Algorithms ............................................................................. 8 7.2 FIPS Allowed Algorithms ................................................................................ 9 7.3 FIPS Non-Approved and Other Algorithms .................................................... 9 7.4 Cryptographic Keys and Critical Security Parameters ................................... 9 8 Self Tests .............................................................................................................. 10 8.1 Power-up Self-Tests..................................................................................... 10 8.2 Conditional Self-Tests .................................................................................. 10 9 Mitigation of Other Attacks.................................................................................... 11 10 OperationAL Guidance..................................................................................... 11 10.1 Crypto Officer Guidance............................................................................... 11 10.2 User Guidance ............................................................................................. 12 11 Glossary ........................................................................................................... 14 Table of Tables Table 1 Security Level Summary ................................................................................... 1 Table 2 Ports and Interfaces .......................................................................................... 5 Table 3 Services Authorized for Roles........................................................................... 6 Table 4 Access Rights within Services for Crypto Officer .............................................. 6 Table 5 Access Rights within Services for User............................................................. 7 Table 6 FIPS Approved Algorithms................................................................................ 8 Table 7 FIPS Allowed Algorithms................................................................................... 9 Table 8 FIPS Non-Approved and Other Algorithms ....................................................... 9 Table 9 Cryptographic Keys and Critical Security Parameters .................................... 10 Table 10 Power-Up Self Tests ..................................................................................... 10 Table 11 Conditional Self Tests ................................................................................... 10 Table of Figures Figure 1 Logical Diagram ............................................................................................... 3 Figure 2 Physical Cryptographic Module ....................................................................... 4 CCORE Module Security Policy i 1 INTRODUCTION 1.1 Purpose This non-proprietary document specifies the Security Policy for Cellcrypt's CCORE Module and was developed as part of the Federal Information Processing Standard (FIPS) 140-2 Level 1 validation of CCORE version 0.6.0-rc3 (hereafter CCORE or CCORE Module). This document may be freely reproduced and distributed as published. The FIPS 140-2 standard, and information on the CMVP, can be found at http://csrc.nist.gov/cryptval. 1.2 Security Level Summary FIPS 140-2 Section Level Cryptographic Module Specification 1 Cryptographic Module Ports and Interfaces 1 Roles, Services and Authentication 1 Finite State Model 1 Physical Security N/A Operational Environment 1 Cryptographic Key Management 1 Electromagnetic Interference/Electromagnetic Compatibility 1 Self-tests 1 Design Assurance 1 Mitigation of Other Attacks N/A Table 1 Security Level Summary 2 CCORE MODULE SPECIFICATION The CCORE module is a Software Cryptographic Module. For the purposes of FIPS 140-2 validation, the CCORE module is delivered as a discrete unit of binary object code. The binary object code is generated from a specific set and revision level of C language source files. These platform-portable source files are compiled to create this object code for execution on a general purpose computer for use by an application to provide cryptographic services. The purpose of the CCORE module is to provide, through an API library, cryptographic service support for Cellcrypt's secure Voice-Over-IP products. The major cryptographic services provided by the module are: · Initialization of Critical Security Parameters for peer to peer communication · Key establishment between two peers · Encryption of a maximum 4KB block of user data at a time · Decryption of a maximum 4KB block of user data at a time The CCORE module is distributed in its binary object code form as part of Cellcrypt's software package applications. Since the CCORE module is a Software CCORE Module Security Policy 1 Cryptographic Module, it is conceptually comprised of two sub-elements: a Physical Cryptographic Module (PCM) and the Logical Cryptographic Module (LCM). The above services execute/operate within the PCM that contain the processor or central processing unit (CPU) and memory devices interconnected with a system bus. For the purposes of FIPS 140-2 level 1 validation the CCORE module can be considered a multi-chip standalone module. The CCORE module library implements a secure and reliable transport layer. It contains all functions for handling encryption and decryption of data. The library is used by the originating call handler (the initiator) and the terminating call handler (the responder). The main services of key establishment and data encryption by an initiator or responder instance of the user application are performed by invoking CCORE functions. The module establishes an encrypted tunnel and data sent through that tunnel is processed twice. In the first pass output data is processed with 256-bit RC4 obfuscation, which is treated as plaintext manipulation for the purpose of FIPS 140-2 validation. For this 1st pass keys are established using the Elliptic Curve Diffie- Hellman (ECDH) protocol and authentication between peers is performed with ECDSA digital signing. The second pass is a FIPS 140-2 compliant encryption, using 256 bit AES. For the 2nd pass, keys are established using RSA key transport and authentication between peers is performed with RSA Digital signing. All data output from the module is processed by both passes, so it is first obfuscated using RC4 and then encrypted using AES. 2.1 Hardware Platform The module was tested for FIPS 140-2 level 1 requirements on a Ubuntu Server 8.04.1 operating system running on a Pentium 4 computer platform. 2.2 Module Boundary The logical cryptographic boundary for the CCORE module is the LCM boundary which surrounds the discrete contiguous block of binary object code containing the machine instructions and data (that resides on the local file system) generated from the CCORE source code, as used by the user application. The logical cryptographic boundary is defined in terms of an Application Programming Interface (API) which is the logical interface to the CCORE module. The CCORE module interfaces to the underlying modules SIPm and RIPm. SIPm deals with the network signalling and RIPm deals with the media transport. They are only involved in the transport of data to and from the network and so are outside of the cryptographic boundary. CCORE Module Security Policy 2 Cellcrypt CCORE module Software components execute within the Client physical boundary Application File storage components as mapped here Hard Disk / CCORE.dll System Memory Cellcrypt SIPm/RIPm modules CPU / System SIPm.dll Bus RIPm.dll Ubuntu Server 8.04.1 OS TCP/IP stack Network Interface Card Component within cryptographic boundary Component outside cryptographic boundary Ciphertext (encrypted) data Plaintext (unencrypted) data Control data Status data Figure 1 Logical Diagram CCORE Module Security Policy 3 Networking I/O Monitor CPU Ccore Module Keyboard RAM Mouse Hard Disk Power Supply System Bus within cryptographic boundary Component within cryptographic boundary Figure 2 Physical Cryptographic Module 2.3 FIPS-Approved Mode of Operation The module is designed to only work in an Approved FIPS mode of operation. There is no special configuration required to operate in a FIPS-Approved mode. The services of the module, when used by an application, provide FIPS 140-2 level 1 compliant cryptographic operations. 3 PORTS AND INTERFACES The following table describes the ports and interfaces to the CCORE Module. FIPS Logical Logical Interface Physical Entry/Exit Port Input/Output Data input API function and the context passed System Bus towards with it contain the data input to the Network Port / System module. The data input will be memory provided by either the network protocol stack for data from the network port or from system memory for data provided by a user application. CCORE Module Security Policy 4 FIPS Logical Logical Interface Physical Entry/Exit Port Input/Output Data output API function and the context passed System Bus from Network with it contain the data output from Port / System memory the module. The data output from the module will either be output through the network protocol stack for data to be sent from a network port or output to system memory for data to be provided to a user application. Control input API function call provides the control System memory data input to the module. Status output Return codes (both error and non- System memory error) from called functions. Table 2 Ports and Interfaces The operating system software is responsible for keeping logical interfaces that share the same physical port separate. For example, encrypted data sent to and received from the network will pass through the network port of the general purpose computer. Received and sent data from/to the network is processed by the network protocol stack software of the operating system and delivered to or read from the CCORE module as a data structure. 4 ROLES, SERVICES AND AUTHENTICATION The cryptographic services are provided through the API of the module. There are two roles supported with the module. They are the User role and Crypto Officer role. Roles are implicitly assumed by an application that uses the services implemented in the module. The application switches roles implicitly depending on which API call is issued by the application. The Crypto Officer role is implicitly assumed when the application requests initialization of the module or zeroization of the data in the module. Self tests are performed as a part of the initialization. After the module has been initialized, the User role is implicitly assumed when the application requests services implemented by the module that makes use of services defined through the module's API, except initialization, executing self-tests, and zeroization. Note that only a single application may access the module services at any one time. The services provided by the module are listed in the following table. CCORE Module Security Policy 5 Role Service API/Function call Crypto Officer Initialization / Perform self-tests CC_new() Crypto Officer Zeroization of CSPs (session CC_deinit() keys, RNG seed) and all session data2 User Create new peer CC_newpeer() User Show Status CC_FIPS_geterror() User Zeroization of peer session keys CC_deinitpeer() and data User Key establishment (initiator) with CC_encode() peer to peer authentication using digital signing User Key establishment (responder) CC_decode() with peer to peer authentication using digital signing User Encryption of a maximum of 4KB CC_encode() block of user data at a time User Decryption of a maximum of 4KB CC_decode() block of user data at a time User Process timeouts CC_tick() Table 3 Services Authorized for Roles Service Cryptographic Key/CSP Type of Access to Key/CSP Initialization / Perform Self- RNG seed file, Asymmetric W tests private keys (RSA and ECDSA) Zeroization of CSPs (session Asymmetric public and private W keys, RNG seed) and all keys (RSA and ECDH), session data3 Asymmetric public key (ECDSA), Symmetric keys (AES and RC4) Table 4 Access Rights within Services for Crypto Officer 2 Note: The module's RSA key file must be manually deleted. See Section 10.1, Crypto Officer Guidance. 3 Note: The module's RSA key file must be manually deleted. See Section 10.1, Crypto Officer Guidance. CCORE Module Security Policy 6 Service Cryptographic Key/CSP Type of Access to Key/CSP Create new peer None N/A Show Status None N/A Zeroization of peer session Asymmetric public keys (RSA W keys and data and ECDH), Asymmetric public key (ECDSA), Symmetric keys (AES and RC4) Key establishment with peer RNG seed file R to peer authentication using Asymmetric public and private R, W, E digital signing keys (RSA, ECDH and ECDSA) Symmetric keys (AES and RC4) R, W Encryption/Decryption (2nd Symmetric key (AES) E pass) Obfuscation/De-obfuscation Symmetric key (RC4) E (1st pass) Process timeouts None N/A Table 5 Access Rights within Services for User Note that the Obfuscation/De-obfuscation as used for the 1st pass is regarded as manipulation of plaintext user data for FIPS 140-2 level 1 validation purposes. While authentication of peers for the creation of the encrypted tunnel is provided, authentication of User Role or Crypto Officer Role, or of operators using the application which assumes those roles, is not provided by the CCORE module. It is the responsibility of the operator of the general purpose computer that is running the user application, or the application itself, that uses the services of the module to provide a secure environment in terms of restricting non-authorized use. 5 PHYSICAL SECURITY This section is not applicable, as physical security is not required for software modules. 6 OPERATIONAL ENVIRONMENT The module was tested using the Ubuntu operating system on a Pentium 4 platform. In accordance with IG4 Section G.5, the module will remain compliant with the FIPS 140-2 validation when operating on the following operating systems provided that the general purpose computer (GPC) uses the specified single user operating system/mode specified on the validation certificate, or another compatible single user operating system: · Red Hat · Debian · Gentoo · CentOS · Fedora · Gnu · Suse 4 Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program. CCORE Module Security Policy 7 During operation, the keys, seed values and other CSPs are used in the process space of the CCORE module. The operating system uses its inherent memory management mechanisms to ensure that other processes do not access the process space used by the module. Outside of operation the module stores a seed file and keys on the local file system. It is the responsibility of the operator of the general purpose computer that is running the user application that uses the services of the module to provide a secure environment in terms of protecting this data. 7 CRYPTOGRAPHIC KEY MANAGEMENT Other than a seed file that the application must provide, all Cryptographic Keys and Critical Security Parameters are internally managed by the module, i.e. they cannot be input or output to/from the module. The module manages a tunnel with two processing passes. The first pass obfuscates data using 256-bit RC4. Keys are established using the Elliptic Curve Diffie-Hellman (ECDH) protocol. Authentication between peers is performed with ECDSA digital signing. The second pass encrypts data using 256-bit AES encryption. Keys are established using RSA key transport. Authentication between peers is performed with RSA digital signing. 7.1 FIPS Approved Algorithms Algorithm Algorithm Standard Use FIPS Certificate # Type Symmetric AES CTR Mode FIPS 197 Encrypt/Decrypt Cert #1089 Key (256 bits) user tunnel traffic Hashing SHA-384 FIPS 180-3 Hashing Cert #1022 Hashing SHA-512 FIPS 180-3 Hashing, Cert #1022 key derivation HMAC HMAC (SHA- FIPS 198-1 Software Cert #612 512) integrity check RNG RNG (ANSI ANSI X9.31 Key generation Cert #611 X9.31) Asymmetric RSA RSASSA- Signing, Cert #514 Key PKCS1_V1_5 Verification Table 6 FIPS Approved Algorithms CCORE Module Security Policy 8 7.2 FIPS Allowed Algorithms Algorithm Algorithm Standard Use FIPS Certificate # Type Asymmetric RSA (key wrapping; key N/A Session key N/A Key establishment establishment methodology provides 112 bits of encryption strength) Table 7 FIPS Allowed Algorithms 7.3 FIPS Non-Approved and Other Algorithms Algorithm Type Algorithm Use Notes Symmetric Key RC4 (256 bits) Obfuscate/De- RC4 is used for the 1st pass obfuscate user which is regarded as tunnel traffic manipulation of plaintext user data for FIPS 140-2 level 1 validation purposes. Hashing MD5 Hashing, Key MD5 is used for the 1st pass generation which is regarded as manipulation of plaintext user data for FIPS 140-2 level 1 validation purposes. Key Agreement Elliptic Curve Diffie- Session key The Elliptic Curve Diffie- Hellman (ECDH) (key agreement Hellman (ECDH) algorithm is agreement; key a non-compliant establishment implementation. methodology provides 112 bits of encryption strength) Asymmetric Key Elliptic Curve DSA Signing, The ECDSA algorithm is a verification non-compliant implementation. Table 8 FIPS Non-Approved and Other Algorithms 7.4 Cryptographic Keys and Critical Security Parameters Cryptographic Key/CSP Storage Use ECDSA Public Key RAM Verification by peer ECDSA Private Key Non-volatile memory Signing ECDH Public Key RAM Session key agreement (RC4) ECDH Private Key RAM Session key agreement (RC4) RSA Public Key (2048 RAM (see note 1) Session key establishment bits) (AES), verification by peer RSA Private Key Non-volatile memory Session key establishment (AES), signing Integrity Check HMAC Key Non-volatile memory Software integrity check CCORE Module Security Policy 9 (160 bits) AES Session Key (256 RAM Encrypt/Decrypt FIPS bits) tunnel traffic RC4 Session Key (256 RAM Obfuscate/De-obfuscate bits) user tunnel traffic RNG Seed Non-volatile memory Seed used for RNG Table 9 Cryptographic Keys and Critical Security Parameters The RSA Public key and ECDSA Public key of any peer that the module communicates with are stored in non-volatile memory. These keys are used to verify the signatures in the 2nd and 1st passes respectively. 8 SELF TESTS The CCORE Module performs self tests at initialization. The tests are as follows: 8.1 Power-up Self-Tests The following algorithm tests are performed at power-up of the CCORE module. Note that KAT tests are Known Answer Tests. Algorithm Test AES CTR Mode KAT for encryption only (256 bits) RNG/PRGN (ANSI ANSI x9.31 KAT X9.31) RSA (digital KAT for digital signature generation and verification signature) RSA (encryption) KAT for encryption and decryption HMAC (SHA-512) Integrity Test (no separate KAT required ­ IG Section 9.3 ) SHA-512 No separate KAT required ­ IG Section 9.3 SHA-384 No separate KAT required ­ IG Section 9.2 Table 10 Power-Up Self Tests In addition to algorithm tests, HMAC (SHA-512) is used to perform a software integrity test at power up. 8.2 Conditional Self-Tests The following conditional self tests are provided. Algorithm Test RSA key Pairwise consistency test verifying that the key pair generation is correct for encryption/decryption and for signature/verification. RNG (X9.31) Check each 4 byte chunk to verify it is different than the previous 4 byte chunk and discard the first 4 byte chunk from the seed value. Table 11 Conditional Self Tests CCORE Module Security Policy 10 9 MITIGATION OF OTHER ATTACKS This is not applicable. The module does not mitigate against other attacks. 10 OPERATIONAL GUIDANCE 10.1 Crypto Officer Guidance The Crypto Officer role initializes the module. This role is assumed by the application that uses the module on the operating system of the general purpose computer. The interface to the module for the application is through the logical interface of the CCORE API library. The following file needs to be created by the application and stored in the base directory that is specified by the function CC_new when it is invoked by the application. The file contents are used as a seed (256 bytes) for the RNG used by CCORE. · cf_seed.dat which stores the RNG seed Before initialization the application needs to: · Create a session context structure · Set the Maximum Transmission Unit (MTU) for the network (CC_SET_CTX_MTU) and the MTU for the audio transmission (CC_SET_AUDIO_MTU) To fulfil the role at initialization the application needs to invoke the CC_new function of the CCORE API library. This function initializes the following security related information: · Private RSA key (stored in file referenced through header definition CC_KEY_NAME) · Private Elliptic Curve Digital Signature Algorithm key (stored in file referenced through header definition CC_ECDSA_KEY_NAME) Both during and outside of operation these files are stored on the local file system. It is the responsibility of the operator of the general purpose computer that is running the user application that uses the services of the module to provide a secure environment in terms of protecting these files. The CC_new function additionally performs self tests. See the self test matrices in Section 8 for details. If a self test fails then the module will report an error and the module will zeroize all context data including all keys and CSPs stored in RAM/volatile memory. It is the responsibility of the operator of the general purpose computer that is running the user application, or the application itself, to decide what to do next. Zeroization of keys and CSPs should be performed when the module is no longer required to operate. To fulfil this, the Crypto Officer role needs to invoke the CC_deinit function of the CCORE API library to zeroize the keys from memory. CCORE Module Security Policy 11 Additionally the content of the files stored on the local file system need to be zeroized and then deleted. Authentication of the operator in the Crypto Officer role is not provided. It is the responsibility of the operator of the general purpose computer that is running the user application, or the application itself, that uses the services of the module to provide a secure environment in terms of restricting non-authorized use. 10.2 User Guidance The User role is implicitly assumed by an application that uses the services implemented in the module and is executing on the general purpose computer that makes use of the services defined through the module's API. The interface to the module for the User application is through the logical interface of the CCORE API library. An operator executing an application that uses the module will be able to communicate with another individual over a secure transport layer tunnel encrypted using 256-bit AES where keys have been established using RSA key transport. The User role that is assumed by the application needs to set the CCORE flag CC_SET_INITIATOR if it is to act as the initiator. The User role (as the initiator or responder) that is assumed by the application needs to invoke the CC_newpeer function of the CCORE API library as the first thing that it does in a session. This function initializes all structures to be used. The functions CC_encode and CC_decode of the CCORE API library serve different purposes as and when invoked by an application. Their initial invocation will result in the execution of the CCORE Cryptographic Key Handshake Protocol. The first invocation of the CC_decode function will initiate cryptographic key establishment for the initiator using the CCORE Cryptographic Key Handshake Protocol. The responder's invocation of CC_decode function will perform the cryptographic key establishment by responding to the initiator using the CCORE Cryptographic Key Handshake Protocol. This is internally driven through flags and states. When communication is made with a peer for the first time then a directory is created for that peer. The following files are created in the peer directory. · rsa_pub-tmp.bin which stores the received RSA public key of the peer before authentication of the peer · rsa_pub.bin which stores the received RSA public key of the peer after authentication of the peer · ec_pub.bin which stores the received ECDSA public key of the peer. When the User role that is assumed by the application (as the initiator or responder) needs to send encrypted data, it invokes the CC_encode function. When the User role that is assumed by the application (as the initiator or responder) needs to receive encrypted data, it invokes the CC_decode function. CCORE Module Security Policy 12 The User role that is assumed by the application must invoke the CC_tick function in order that the CCORE module can process timeouts. This must be at least every second. When the User role that is assumed by the application needs to know the status of the module it invokes the CC_FIPS_geterror function of the CCORE API library. At the completion of a session the User role that is assumed by the application needs to invoke the CC_deinitpeer function of the CCORE API library. The function clears/zeroizes all data used in the session. When an error is reported to the application, the module will zeroize all context data including all keys and CSPs stored in RAM/volatile memory. Calls to all I/O are blocked. Calls to CC_FIPS_geterror, CC_deinit and CC_deinitpeer are not blocked. Authentication of the operator in the User Role is not provided. It is the responsibility of the operator of the general purpose computer that is running the user application, or the application itself, that uses the services of the module to provide a secure environment in terms of restricting non-authorized use. CCORE Module Security Policy 13 11 GLOSSARY ACRONYM DEFINITION AES Advanced Encryption Standard API Application Programming Interface CSP Critical Security Parameter CTR Counter DSA Digital Signature Algorithm E Execute ECDH Elliptic Curve Diffie-Hellman ECDSA Elliptic Curve Digital Signature Algorithm FIPS Federal Information Processing Standards GPC General Purpose Computer HMAC keyed-Hash Message Authentication Code I/O Input/Output KAT Known Answer Test LCM Logical Cryptographic Module OS Operating System PBX Private Branch Exchange PCM Physical Cryptographic Module R Read RAM Random Access Memory RNG Random Number Generator RIPm Cellcrypt Real Time Protocol for Mobile SHA Secure Hash Algorithm SIP Service Information Protocol SIPm Cellcrypt Service Information Protocol for Mobile W Write CCORE Module Security Policy 14