whiteCryption Secure Key Box 4.6.0 Crypto Module FIPS 140-2 Level 1 Security Policy Document version: 1.2 Last updated: 2014.11.06 Crypto Module Security Policy Copyright Notice © 2014, whiteCryption Corporation. © 2014, Intertrust Technologies Corporation. This non-proprietary document may be freely reproduced and distributed whole and intact including this Copyright Notice. Revision History Authors Date Version Comment Kristaps Straupe September 4, 2012 0.5 Initial draft Kristaps Straupe January 16, 2013 0.6 Updates according to design Juris Olekss January 23, 2013 0.7 Formatting and spell-checking Kristaps Straupe February 11, 2013 0.8 Various updates and clarification Juris Olekss February 15, 2013 0.9 Formatting and spell-checking. Added page numbers. SKB version changed to 4.6.0. Kristaps Straupe July 26, 2013 1.0 Final updates Kristaps Straupe August 12, 2014 1.1 Updates per CMVP comments Kristaps Straupe November 6, 2014 1.2 Updates per CMVP comments © 2014, whiteCryption Corporation. Page 2 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Table of Contents 1  Introduction ....................................................................................................................................... 4  1.1  About FIPS 140-2 ..................................................................................................................... 4  1.2  About Secure Key Box ............................................................................................................. 4  2  Module Specification ........................................................................................................................ 5  2.1  Tested Configurations ............................................................................................................... 6  2.2  Cryptographic Functionality and Approved Mode of Operation ................................................ 6  3  Ports and Interfaces ....................................................................................................................... 10  4  Roles and Services ........................................................................................................................ 11  5  Operational Environment ................................................................................................................ 14  6  Cryptographic Key Management .................................................................................................... 15  7  Self-Tests ........................................................................................................................................ 17  8  Design Assurance .......................................................................................................................... 19  9  Mitigation of Other Attacks.............................................................................................................. 20  Appendix A – Module Integrity .............................................................................................................. 21  Appendix B – Source Entropy Input for the SKB Module ...................................................................... 22  Appendix C – HASH_DRBG Specification ............................................................................................ 23  Appendix D – Service to Module API Mapping When Performing Services in Approved Mode ........... 24  Glossary ................................................................................................................................................ 27  © 2014, whiteCryption Corporation. Page 3 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy 1 Introduction This document comprises the non-proprietary FIPS 140-2 Security Policy for the whiteCryption Secure Key Box Crypto Module version 4.6.0. 1.1 About FIPS 140-2 FIPS 140-2 (Federal Information Processing Standards Publication 140-2 – Security Requirements for Cryptographic Modules) 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 Cryptographic Module Validation Program (CMVP) website, which is maintained by National Institute of Standards and Technology (NIST) and Communication Security Establishment Canada (CSEC): http://csrc.nist.gov/groups/STM/cmvp/index.html. 1.2 About Secure Key Box Secure Key Box (SKB) is a C/C++ library that provides an extensive set of high-level classes and methods for working with the most popular cryptographic algorithms. SKB exposes a comprehensive interface that provides access to a set of cryptographic algorithms. An application that is integrated with SKB executes the cryptographic algorithms via the SKB API. SKB Crypto Module Logical Boundary SKB overview Because of the library’s robust design, systems integrated with SKB can be safely deployed in insecure environments, such as mobile devices, tablets, and desktop computers, where anyone could have access to the program code and device memory. In this document, whiteCryption Secure Key Box is referred to as SKB, the library, or the Module. © 2014, whiteCryption Corporation. Page 4 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy 2 Module Specification The Module is a software library providing a C-language application program interface (API) for use by other processes that require cryptographic functionality. The Module is classified by FIPS 140-2 as a software module, multi-chip standalone module embodiment. The physical cryptographic boundary is the general purpose computer on which the Module is installed. The logical boundary of the cryptographic Module is the single shared object (SO). The Module performs no communications other than with the calling application (the process that invokes the Module services). System diagram © 2014, whiteCryption Corporation. Page 5 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy The FIPS 140-2 security levels for the Module are as follows: Security Requirement Security 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 EMI/EMC 1 Self-Tests 1 Design Assurance 3 Mitigation of Other Attacks N/A Table 1 – Security level of security requirements The Module’s software version for this validation is 4.6.0.  2.1 Tested Configurations Operational Environment Processor Optimizations (Target) Android 4.2.2 Qualcomm Snapdragon S4 (ARMv7) None Table 2 – Tested platforms 2.2 Cryptographic Functionality and Approved Mode of Operation The Module supports FIPS 140-2 approved mode. Tables 3a and 3b list the approved and non- approved but allowed algorithms contained within the Module. Function Algorithm Options Cert # Random number [SP 800-90] Hash_DRBG using SHA-256 at highest security 335 generation DRBG strength (256 bit) and prediction resistance not supported © 2014, whiteCryption Corporation. Page 6 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Function Algorithm Options Cert # Symmetric cipher [FIPS 197] AES 128/192/256 ECB, CBC, CTR 2451, 2452, 2453, 2454, 2455, 2456, 2457, 2458, 2459, 2460, 2461, 2462, 2463, 2464, 2465, 2466, 2467 Message [FIPS 198] HMAC-SHA-1, 1516, authentication code HMAC HMAC-SHA-256 1517 [SP 800-38B] CMAC 128 AES 2470, 2471 CMAC Hashing [FIPS 180-3] SHA-1 2084, 2085, SHA SHA-2: SHA-256, SHA-384 2086, 2087, 2088, 2089, 2090 Digital signature and [FIPS 186-3] Key pair: P-224, P-256 403 asymmetric key ECDSA SigGen: P-224 (SHA-256), P-256 (SHA-256 generation Key pair: P-384, P-521 404 SigGen: P-384 (SHA-256), P-521 (SHA-256) ECDSA SigGen component: P-224 (SHA-256, CVL 83 SHA-384), P-256 (SHA-256, SHA-384) ECDSA SigGen component: P-384 (SHA-256, CVL 84 SHA-384), P-521 (SHA-256, SHA-384) [FIPS 186-3] SigGenPKCS #1 v1.5 and SigGenPSS 2048 1263 RSA with SHA-256 CVL 94 RSASP1 PKCS #1 v1.5 SigGenComponent 2048 with SHA-256 Key derivation [SP 800-108] KDF in Counter Mode using CMAC AES-128 KBKDF 11 KDF and AES 2471 [SP 800-56A] Ephemeral unified ECC CDH primitive on all CVL 79 EC Diffie-Hellman (§5.7.1.2) NIST defined P curves; P-224, P-256 key agreement Ephemeral unified ECC CDH primitive; P-384, CVL 80 primitive P-521 Table 3a – FIPS approved cryptographic functions © 2014, whiteCryption Corporation. Page 7 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Function Algorithm Description Key unwrap AES Key unwrap using AES 128, 192 or 256 (Certs. #2464 and #2465). No CSPs are established into or exported out of the Module. This is only used for system level key establishment, which is beyond the scope of this module. When used for system level key establishment, this service provides between 128 and 256 bits of security. RSA primitives and RSA The RSA (OAEP) 2048 decrypt operation and RSADP 2048 primitive. operations No CSPs are established into or exported out of the Module. This is only used for system level key establishment, which is beyond the scope of this module. When used for system level key establishment, this service provides 112 bits of security. Table 3b – Non-FIPS approved but allowed cryptographic functions Table 3c lists the algorithms/options that are Disallowed as of January 1, 2014 per the NIST SP 800- 131A algorithm transitions. Algorithms providing less than 112 bits of security strength are not allowed in the FIPS Approved mode of operation for use by Federal agencies. Function Algorithm Options Cert # Key pair: P-192 403 Digital signature and [FIPS 186-3] asymmetric key ECDSA SigGen: P-192 (SHA-1, 256), P-224 (SHA-1), P- generation 256 (SHA-1) SigGen: P-384 (SHA-1), P-521 (SHA-1) 404 CVL 83 ECDSA SigGen component: P-192, P-224 (SHA- 1), P-256 (SHA-1) CVL 84 ECDSA SigGen component: P-384 (SHA-1), P- 521 (SHA-1) 1262 [FIPS 186-3] SigGenPKCS #1 v1.5 and SigGenPSS 1024 RSA (SHA-1, SHA-256) 1263 SigGenPKCS #1 v1.5 and SigGenPSS 2048 (SHA-1) CVL 94 RSASP1 PKCS #1 v1.5 SigGenComponent 2048 (SHA-1) Ephemeral unified ECC CDH primitive; P-192 CVL 79 EC Diffie-Hellman [SP 800-56A] key agreement (§5.7.1.2) primitive RSA N/A RSA primitives and The RSA (OAEP) 1024 decrypt operation and operations RSADP 1024 primitive. No CSPs are established into or exported out of the Module. Table 3c – Cryptographic Functions Disallowed (as of 1/01/2014) per NIST 800-131A Transitions The Module does not provide full EC Diffie-Hellman key agreement scheme, only the primitive. © 2014, whiteCryption Corporation. Page 8 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy The following non-FIPS Approved and not allowed algorithms are included in the Module:  ECDSA Key Pair and SigGen with SHA-1 and SHA-256 using SECG, secp160r1 curve  PKCS #1 v1.5 RSA 1024 decryption operation  PKCS #1 v1.5 RSA 2048 decryption operation  RSASP1 PKCS #1 v1.5 SigGenComponent non-compliant mod length 1024 These non-approved and not allowed cryptographic algorithms shall not be used while operating the Module in the FIPS approved mode. The Module operates in FIPS 140-2 Approved mode of operation as long as only the services using approved and allowed algorithms are used. When the Module library is loaded into memory an integrity check along with power-up self-tests is performed. If any of these fail, the Module will enter a fail state and an error code will be returned resulting in no cryptographic services available. The Module is a cryptographic engine library, which can be used only in conjunction with additional software. Aside from the use of the NIST-defined elliptic P curves as trusted third party domain parameters, all other FIPS 186-3 and SP 800-56A assurances are outside the scope of the Module, and are the responsibility of the calling process. The algorithm selection in Module services is achieved by passing a specific enum value in the service call. For enum values corresponding to approved and allowed algorithms please refer to Appendix D. Rules of operation enforced by the cryptographic Module to implement the security requirements of this FIPS 140-2 Level 1 Module are as follows:  The operating system shall be restricted to a single operator mode of operation (i.e., concurrent operators are explicitly excluded).  The Module shall be operated in single user/operator mode. The external application that makes calls to the cryptographic Module is the single user of the cryptographic Module, even when the application is serving multiple clients (IG 6.1).  The unauthorized reading, writing, or modification of the address space of the Module is prohibited.  The referencing application accessing the Module runs in a separate virtual address space with a separate copy of the executable code.  The operating system is responsible for multi-tasking operations so that other processes cannot access the address space of the process containing the Module.  The operator (calling application) shall use appropriate entropy sources (entropy source callback in the Module) for generating the seeding material for the FIPS-approved DRBG of the Module. The entropy in the seeding material input to the Module must be at least as much as the security strength of the Modules employed DRBG (256 bits).  Operator (calling application) shall only use algorithms, key sizes, and elliptic curves outlined in Tables 3a and 3b.  Operator (calling application) shall use the zeroization services provided by the Module on keys or service contexts no longer needed by the operator.  The operator (calling application) shall operate the Module only through services and API calls and parameters listed in Table 10 in Appendix D. © 2014, whiteCryption Corporation. Page 9 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy 3 Ports and Interfaces The Module uses the same physical ports as the computer system on which it is executing. The logical interface is a C-language API. Logical Interface Type Description Control input API entry point and corresponding stack parameters Data input API entry point data input stack parameters Status output API entry point return values and status stack parameters Data output API entry point data output stack parameters Table 4 – Logical interfaces As a software module, control of the physical ports is outside of the Module scope. However, when the Module is performing self-tests, or is in an error state, all output on the logical data output interface is inhibited. The Module is single-threaded and in error scenarios returns only an error value (no data output is returned). © 2014, whiteCryption Corporation. Page 10 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy 4 Roles and Services The roles of the Crypto Officer or User role are assumed implicitly when installing or operating the services of the Module. The Module does not support any kind of authentication. The Module is not allowed to be used with concurrent operators. The Module does not provide identification or authentication mechanisms that would distinguish between the two supported roles. The Crypto Officer role can also install, remove, or instantiate the Module. All services implemented by the Module (and accessible to both roles) are listed below, along with a description of service CSP access – read (R) the CSP, or write (W) the CSP. ** It is the responsibility of the module operator to ensure that algorithms, modes, and key sizes Disallowed per the NIST SP 800-131A algorithm transitions are not used. Impact of SP 800- CSP and Access Service Description Input Output Approved Approved 131A Transitions Operation (Disallowed Options Mode Mode Non- in RED)** X Instantiate N/A Instantiates the None Engine Seed (W, R) Module engine instance, DRBG state (W) Status Table 5a – Crypto Officer Services and CSP access Impact of SP 800- CSP and Access Service Description Input Output Approved Approved 131A Transitions Operation (Disallowed Options Mode Mode Non- in RED)** X Check Integrity N/A Checks the integrity None Status None of the Module using the SHA-256 digest of the Module in memory against the embedded known MAC value, sets the Module error status on mismatch X Execute Self- N/A Runs the power-up None Status None Test tests of the Module including KAT and sign/verify where applicable, updates the Module error status on failure X Get Error N/A Gets the error status None Status None Status indicating the state of the Module – operational or in fail state © 2014, whiteCryption Corporation. Page 11 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Impact of SP 800- CSP and Access Service Description Input Output Approved Approved 131A Transitions Operation (Disallowed Options Mode Mode Non- in RED)** X AES Encrypt/ N/A Encrypt/decrypt Parameters, Status, AES Key (R) Decrypt plaintext/ciphertext AES key, ciphertext/ plaintext/ plaintext ciphertext X RSA-OAEP RSA key size: Decrypt ciphertext Parameters, Status, RSA private key (R) Decrypt 1024-bit; RSA private keying 2048-bit (SHA-1) key, ciphertext material X RSA key size: 2048-bit (SHA-2) X Secure N/A Hash data Parameters, Status, None Hashing Data digest X RSA Signature RSA key size: Signature generation Parameters, Status, RSA private key (R) Generation 1024-bit; and/or Signature RSA private signature If generating RSA 2048-bit (SHA-1) primitive only (steps key, data PSS signature: 3 to 6 of PKCS #1 Seed (R)* X RSA key size: v1.5 encoding DRBG state (R, W) 2048-bit (SHA-2) included) X ECDSA ECDSA key size: Signature generation Parameters, Status, ECDSA private key Signature P-192; and/or Signature ECDSA private signature (R) Generation P-224, P-256, P-384, primitive only key, data Seed (R)* P-521 (SHA-1) DRBG state (R, W) X ECDSA key size: P-224, P-256, P-384, P-521 (SHA-2) X HMAC N/A Generate (or verify) Parameters, Status, HMAC Key (R) MAC using HMAC HMAC key, MAC/ data/signature verification result X CMAC N/A Generate (or verify) Parameters, Status, AES Key (R) MAC using CMAC AES key, MAC/ data/signature verification result X Random Byte N/A Generate random Parameters Status, AES AES Key (W) or Generation value which can be or HMAC HMAC Key (W) used for system key Seed (R)* level AES/HMAC DRBG state (R, W) keys X Compute ECDH: Elliptic Curve Diffie- Parameters, Status, ECDH Private ECDH Key P-192 Hellman key ECDH private shared component (R) Agreement agreement shared component and secret ECDH Public key X ECDH: Shared Secret secret computation public key (R) P-224, P-256, P-384, P-521 X Generation of ECDSA key size: Generate an ECDSA Parameters Status, ECDSA private key ECDSA key P-192; key pair ECDSA (W) pair P-224, P-256, private key ECDSA public key P-384, P-521 (SHA-1) and public (W) © 2014, whiteCryption Corporation. Page 12 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Impact of SP 800- CSP and Access Service Description Input Output Approved Approved 131A Transitions Operation (Disallowed Options Mode Mode Non- in RED)** X ECDSA key size: key Seed (R)* P-224, P-256, DRBG state (R, W) P-384, P-521 (SHA-2) X Key Derivation N/A SP 800-108 key Parameters, Status, AES KDK (R) derivation function in AES key (KDK), keying AES Key (W) or counter mode using data (label, material HMAC Key (W) CMAC context) X Key Unwrap N/A AES Key Wrap Parameters, Status, AES AES KEK (R) algorithm AES key (KEK), key AES Key (W) or wrapped AES HMAC Key (W) key X Import N/A Converts an Key (byte Status, Key AES Key (W) or exported key (from a buffer) HMAC Key (W) or pre- formatted byte RSA private key (W) buffer) to or appropriate Module ECDSA private key type object for key(W) use in Module services. Key is loaded from inside the physical boundary of the GPC. X Export N/A Converts the key Parameters, Status, key AES Key (R) or from a Module key key (byte buffer) HMAC Key (R) or type object to a pre- RSA private key (R) formatted byte buffer or (within the physical ECDSA private key boundary of the (R) GPC) X Key/service N/A Zeroizes and Memory Status All CSPs (W) context deallocates the address zeroization memory containing a symmetric key, asymmetric private key, DRBG state * only if periodic DRBG re-seed happens Table 5b – User Services and CSP access © 2014, whiteCryption Corporation. Page 13 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy 5 Operational Environment The FIPS 140-2 Area 6 Operational Environment requirements are applicable because the Module operates in a modifiable operational environment. Operational testing of the Module was performed on the following environment:     Android 4.2.2 (single-user mode)  The Module is considered to be FIPS 140-2 compliant when running on other binary compatible operating environments/hardware provided that rules described in “Cryptographic Functionality and Approved Mode of Operation” are met. © 2014, whiteCryption Corporation. Page 14 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy 6 Cryptographic Key Management The Module supports the following critical security parameters in tables below. It should be noted that the Module key paths are interpreted as being the input and output via “INT” paths as defined in IG 7.7. Therefore, key establishment mechanism is not applicable for this particular Module since all input and output is occurring within the physical boundary of the GPC. All CSPs used by the Module are described in this section. All access to these CSPs by Module services are described in Table 5. ** It is the responsibility of the module operator to ensure that algorithms, modes, and key sizes Disallowed per the NIST SP 800-131A algorithm transitions are not used. Impact of SP 800- Description/ Key Generation Destruction Approved Mode Non-Approved 131A Transitions Purpose (Disallowed Options in RED)** Mode 1024-bit; Used to create RSA An application program X RSA keys Externally 2048-bit (SHA-1) digital signatures and to which uses the API may decrypt (OAEP) keys destroy the key. The X 2048-bit (SHA-2) key/context destruction service zeroizes this CSP. ECDSA P-192; Used to create ECDSA May be generated An application program X private keys P-224, P-256, P-384, digital signatures internally by ECDSA which uses the API may P-521 (SHA-1) key pair generation destroy the key. The key service or generated destruction service P-224, P-256, P-384, X externally zeroizes this CSP. P-521 (SHA-2) ECDH private P-192 Used to derive the May be generated An application program X components shared secret during internally (by underlying which uses the API may ECDH key agreement ECDSA key pair destroy the key. The P-224, P-256, X protocol generation service) or ECDH context destruction P-384, P-521 externally service zeroizes this CSP. Used during AES May be generated An application program X AES keys N/A encryption, decryption, internally (by random which uses the API may CMAC operations, or byte generation destroy the key. The as KDK/KEK for service), derived/ key/context destruction KDF/Wrapping unwrapped or service zeroizes this CSP. generated externally Used during HMAC May be generated An application program X HMAC keys N/A SHA-1/256 operations internally (by random which uses the API may byte generation destroy the key. The service), derived/ key/context destruction unwrapped or service zeroizes this CSP. generated externally Used to seed the Generated internally X DRBG seed N/A Automatically after use DRBG for random through supplied SEI value generation source © 2014, whiteCryption Corporation. Page 15 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Impact of SP 800- Description/ Key Generation Destruction Approved Mode Non-Approved 131A Transitions Purpose (Disallowed Options in RED)** Mode DRBG 'V' and N/A Used in HASH_DRBG An application program X Internally 'C' values state which uses the API may destroy the DRBG state. The internal DRBG state used for key generation services is zeroized upon Module engine destruction. Table 6a – Critical Security Parameters Module integrity data is loaded into the Module during the Module build process and otherwise cannot be accessed. The Module does not output intermediate key generation values. Key Description/Purpose Generation DH public components Used to derive the shared secret during ECDH Internally using ECDSA key pair generation key agreement protocol service or externally ECDSA public keys Public component of ECDSA key pair Internally using ECDSA key pair generation service Table 6b – Public keys For all CSPs and public keys:  Storage: RAM, associated to entities by memory location. The Module does not store any CSPs persistently.  Generation: The Module implements SP 800-90 compliant DRBG algorithm used by services for creation of AES/HMAC keys, and elliptic curve as shown in Tables 6a and 6b.  Entry and output: The cryptographic Module itself does not support key entry or key output from its physical boundary. CSPs enter the Module’s logical boundary in plaintext as API parameters, associated by memory location. The Module does not output CSPs other than as explicit results of key generation services. The calling application using the Module is responsible for ensuring that the input or output of secret and private keys is accomplished in encrypted form.  Destruction: Zeroization of sensitive data is performed automatically by API function calls for temporarily stored CSPs. The calling application is responsible for keys passed in and out of the Module as well as the employed Module service contexts which might store CSPs (such as expanded keys). The Module provides services for destruction of keys and service contexts which store the CSPs. The Module offers zeroization of these CSPs through API functions SKB_FIPS_SecureData_Release – for key destruction, SKB_FIPS_Cipher_Release, SKB_FIPS_Transform_Release, SKB_FIPS_KeyAgreement_Release – for service context destruction as well as SKB_FIPS_Engine_Release for Module employed DRBG CSPs destruction. © 2014, whiteCryption Corporation. Page 16 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy 7 Self-Tests The Module performs the self-tests listed below on Module library load (in Default Entry Point) or when self-test function is manually invoked during operation. Algorithm Type Test Attributes Software integrity KAT HMAC-SHA-256 AES KAT Separate encrypt and decrypt for each ECB, CBC, CTR mode and 128, 192, 256 bit key length combination on all supported algorithm implementations SHS KAT SHA-1, SHA-256, and SHA-384 HMAC KAT MAC and verify with SHA-1 and SHA-256 AES CMAC KAT Sign and verify, 128 bit key length RSA KAT Signature generation PKCS #1 v1.5 1024 and 2048 bit mod length and SHA-256. KAT Decrypt OAEP with 1024 and 2048 bit mod length ECDSA PCT Signature generation P-256 and P-384 curve bit length with SHA- 256 DRBG KAT HASH_DRBG using SHA-256 ECC CDH KAT P-256 and P-384 curve bit length primitive “Z” computation KAT (SP 800-56A §5.7.1.2) KDF KAT KDF in counter mode (SP 800-108) KW-AD(C) KAT Key unwrap using AES Table 7 – Power-on self-tests (KAT = known answer test; PCT = pairwise consistency test) When Module library is being loaded in memory by a calling application, a run-time integrity check and all power-up self-tests listed above are performed returning a result value indicating success or failure. The power-up self-tests may also be performed on-demand by calling SKB_FIPS_ExecuteSelfTests. The same is true for integrity checking function SKB_FIPS_ExecuteIntegrityCheck. Interpretation of the return value is the responsibility of the calling application. If the integrity check or any component of the self-test fails an internal flag is set to prevent subsequent invocation of any cryptographic function calls. The Module also implements the following conditional tests: Algorithm Test ECDSA key Pairwise consistency test on each generation of a key pair (sign with private part, verify generation with public part) DRBG Health tests as required by [SP800-90] Section 11 (refer to Appendix C for more information) © 2014, whiteCryption Corporation. Page 17 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Algorithm Test DRBG DRBG FIPS 140-2 continuous test for stuck fault Table 8 – Conditional tests If the pairwise consistency test fails, the Module enters a fail state to prevent subsequent invocation of any cryptographic function calls. In case a health test failure occurs in the Module engine's internal DRBG used by the key generation service and other services the Module will enter a fail state and deny any further operation. Once the Module is in a fail state, a successful reloading of the Module's library is required to continue operation. © 2014, whiteCryption Corporation. Page 18 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy 8 Design Assurance Subversion (SVN), Jenkins, and whiteCryption proprietary extensive SKB test suite and release scripts are used to provide testing and configuration management for the Module and related documentation. These solutions provide access control, versioning, testing, and logging. © 2014, whiteCryption Corporation. Page 19 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy 9 Mitigation of Other Attacks The Module does not claim any attack mitigation beyond FIPS 140-2 Level 1 requirements. © 2014, whiteCryption Corporation. Page 20 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Appendix A – Module Integrity The Secure Key Box shared library file is protected by a HMAC-SHA-256 MAC. The MAC value is pre- calculated and embedded in the delivered Module object. This value is calculated on the code (.text) and constant/read-only data (.rdata) sections. The value is stored in a specifically marked place in the constant data section of the Module. This place is not included in the message input for the digest algorithm, thus it does not influence the digest value. At run-time, the integrity validation check is executed once the Module library is being loaded into memory. The integrity check performs HMAC- SHA-256 on .text and .rdata sections of the Module in volatile memory and compares it to the embedded value. If the integrity check fails, further operations of services in the Module are denied. This check can also be initiated at any time during the operation of the Module by calling the integrity checking API method directly. By doing so, the Operator of the Module can reassure from time to time that the Module in memory has not been altered. To assure the authenticity of the distributed module, compute and compare SHA-256 digest of the Modules file (libSkbFips.so) against this provided value: AD8D2A5B1A8A3E188FC5B49D541C8292EC489586B8C4D5854D25D1EFB09F6C12 © 2014, whiteCryption Corporation. Page 21 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Appendix B – Source Entropy Input for the SKB Module As the Module implements various algorithms that use underlying DRBG mechanism, a SEI has to be made available for the Module operation. The Module has a callback function for SEI that needs to be initialized before operation. The callback function's signature is as follows: SKB_Result ApplicationEntropySource(SKB_Byte* buffer, SKB_Size count) The first parameter is a byte buffer in which to store the entropy input. The second argument is the byte count of the requested entropy input. The return value specifies if the callback was successful and shall return SKB_SUCCESS in case of normal operation. If an error is encountered, for instance the entropy of 256 bits cannot be achieved, the return value shall be SKB_FAILURE. The Module will enter error state if the callback is unsuccessful. The entropy source callback will be used only for instantiating and re-seeding the Module's internal SHA-256 HASH_DRBG. The SKB API call to set the callback function is as follows: SKB_FIPS_SetEntropySource(ApplicationEntropySource) © 2014, whiteCryption Corporation. Page 22 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Appendix C – HASH_DRBG Specification The Module implements SHA-256 hash DRBG compliant to SP800-90A publication. The DRBG supports only maximum 256 bit security strength and has no prediction resistance capability. The source of entropy input for the DRBG is completely under application control and the callback for entropy source has to be set beforehand to make the operation of DRBG possible (see Appendix B). DRBG Health Testing Implementation health testing is performed for the following DRBG functions:  instantiate  re-seed  generate Health testing checks if the expected error codes are returned in response to invalid parameters or context, and verifies that the DRBG KATs pass. Health testing is done before the actual function is performed. If any health check fails, the given DRBG context (on which the call to DRBG service was made) is placed in an error state and no further operations can be performed on that DRBG instance until it has been re-instantiated. The instantiate function health test is initiated on each instantiation and performs the following checks:  Instantiate with invalid parameters (null context, already instantiated context, context is in error state, invalid nonce/personalization string)  Instantiate with entropy source failure (when entropy source does not return SKB_SUCCESS because of insufficient entropy)  Instantiate KAT test variants of nonce/personalization string passed/omitted The re-seed function health test is initiated on each re-seeding (whether explicit or within the automatic re-seed inside the generate function) and performs the following checks:  Re-seed with invalid parameters (null context, uninstantiated context, context in error state)  Re-seed with entropy source failure (when entropy source does not return SKB_SUCCESS because of insufficient entropy)  Instantiate then re-seed KAT test The generate function health test is initiated on the first run of generate for given DRBG context and on each subsequent 224 generation. The check interval can be adjusted via a function call. The health checks performed in the generate function are as follows:  Generate with invalid parameters (null context, non-instantiated context, context in error state, null buffer for output requested bytes, requested byte count too large)  Instantiate then generate KAT test  Instantiate then generate with triggered re-seed KAT test  Instantiate then generate, and then again generate a stuck fault test The uninstantiate function health test is performed whenever the other DRBG health tests execute. The uninstantiate function's health test checks include:  Uninstantiate with invalid (null) context  Check that the CSPs (V and C) have been zeroized after the uninstantiate call © 2014, whiteCryption Corporation. Page 23 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Appendix D – Service to Module API Mapping When Performing Services in Approved Mode The following table maps the Module services to actual Module API functions and enumeration values used to select the algorithms. When operating the Module in FIPS approved mode, the Module user shall use only the functions and enumerations found in this table. Service API Function API Enumeration Value Initialize SKB_FIPS_GetInstance SKB_FIPS_ExecuteIntegrityCheck Check integrity SKB_FIPS_ExecuteSelfTests Execute self- tests SKB_FIPS_GetErrorStatus Get error status AES encrypt/ SKB_FIPS_Engine_CreateCipher SKB_CIPHER_ALGORITHM_AES_128_ECB decrypt SKB_FIPS_Cipher_ProcessBuffer SKB_CIPHER_ALGORITHM_AES_192_ECB SKB_CIPHER_ALGORITHM_AES_256_ECB SKB_FIPS_Engine_CreateDataFromWrapped SKB_CIPHER_ALGORITHM_AES_128_CBC SKB_FIPS_SecureData_Wrap SKB_CIPHER_ALGORITHM_AES_192_CBC SKB_FIPS_Engine_WrapDataFromPlain SKB_CIPHER_ALGORITHM_AES_256_CBC SKB_CIPHER_ALGORITHM_AES_128_CTR SKB_FIPS_SecureData_Derive SKB_CIPHER_ALGORITHM_AES_192_CTR SKB_CIPHER_ALGORITHM_AES_256_CTR SKB_CIPHER_DIRECTION_ENCRYPT SKB_CIPHER_DIRECTION_DECRYPT SKB_DERIVATION_ALGORITHM_CIPHER SKB_DATA_FORMAT_RAW SKB_DATA_TYPE_BYTES SKB_FIPS_Engine_CreateCipher SKB_CIPHER_ALGORITHM_RSA_OAEP RSA-OAEP Decrypt** SKB_FIPS_Cipher_ProcessBuffer SKB_CIPHER_ALGORITHM_RSA SKB_CIPHER_DIRECTION_DECRYPT SKB_Engine_CreateDataFromWrapped SKB_DATA_FORMAT_RAW SKB_DATA_TYPE_BYTES SKB_FIPS_Engine_CreateTransform SKB_DIGEST_ALGORITHM_SHA1 Secure hashing SKB_FIPS_Transform_AddSecureData SKB_DIGEST_ALGORITHM_SHA256 SKB_FIPS_Transform_AddBytes SKB_TRANSFORM_TYPE_DIGEST SKB_FIPS_Transform_GetOutput SKB_FIPS_SecureData_Derive SKB_DERIVATION_ALGORITHM_SHA_384 © 2014, whiteCryption Corporation. Page 24 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Service API Function API Enumeration Value SKB_FIPS_Engine_CreateTransform RSA SKB_SIGNATURE_ALGORITHM_RSA (only on modulus signature size 2048) SKB_FIPS_Transform_AddSecureData generation** SKB_SIGNATURE_ALGORITHM_RSA_SHA1 SKB_FIPS_Transform_AddBytes SKB_SIGNATURE_ALGORITHM_RSA_SHA256 SKB_FIPS_Transform_GetOutput SKB_SIGNATURE_ALGORITHM_RSA_PSS_SHA1 SKB_SIGNATURE_ALGORITHM_RSA_PSS_SHA1_EX SKB_SIGNATURE_ALGORITHM_RSA_PSS_SHA256 SKB_SIGNATURE_ALGORITHM_RSA_PSS_SHA256_EX SKB_TRANSFORM_TYPE_SIGN SKB_FIPS_Engine_CreateTransform SKB_SIGNATURE_ALGORITHM_ECDSA ECDSA signature SKB_FIPS_Transform_AddSecureData SKB_SIGNATURE_ALGORITHM_ECDSA_SHA1 generation** SKB_FIPS_Transform_AddBytes SKB_SIGNATURE_ALGORITHM_ECDSA_SHA256 SKB_FIPS_Transform_GetOutput SKB_TRANSFORM_TYPE_SIGN SKB_ECC_CURVE_NIST_192 SKB_ECC_CURVE_NIST_224 SKB_ECC_CURVE_NIST_256 SKB_ECC_CURVE_NIST_384 SKB_ECC_CURVE_NIST_521 HMAC SKB_FIPS_Engine_CreateTransform SKB_SIGNATURE_ALGORITHM_HMAC_SHA1 SKB_FIPS_Transform_AddSecureData SKB_SIGNATURE_ALGORITHM_HMAC_SHA256 SKB_FIPS_Transform_AddBytes SKB_TRANSFORM_TYPE_SIGN SKB_FIPS_Transform_GetOutput SKB_TRANSFORM_TYPE_VERIFY CMAC SKB_FIPS_Engine_CreateTransform SKB_SIGNATURE_ALGORITHM_AES_128_CMAC SKB_FIPS_Transform_AddSecureData SKB_TRANSFORM_TYPE_SIGN SKB_FIPS_Transform_AddBytes SKB_TRANSFORM_TYPE_VERIFY SKB_FIPS_Transform_GetOutput Random byte SKB_FIPS_Engine_GenerateSecureData SKB_DATA_TYPE_BYTES generation SKB_FIPS_Engine_CreateKeyAgreement SKB_KEY_AGREEMENT_ALGORITHM_ECDH Compute ECDH key SKB_FIPS_KeyAgreement_GetPublicKey SKB_DATA_FORMAT_ECC_BINARY agreement SKB_FIPS_KeyAgreement_ComputeSecret SKB_ECC_CURVE_NIST_192 shared secret** SKB_ECC_CURVE_NIST_224 SKB_ECC_CURVE_NIST_256 SKB_ECC_CURVE_NIST_384 SKB_ECC_CURVE_NIST_521 © 2014, whiteCryption Corporation. Page 25 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Service API Function API Enumeration Value Generation of SKB_FIPS_Engine_GenerateSecureData SKB_DATA_TYPE_ECC_PRIVATE_KEY ECDSA key SKB_FIPS_SecureData_GetPublicKey SKB_DATA_FORMAT_ECC_BINARY pair** SKB_ECC_CURVE_NIST_192 SKB_ECC_CURVE_NIST_224 SKB_ECC_CURVE_NIST_256 SKB_ECC_CURVE_NIST_384 SKB_ECC_CURVE_NIST_521 SKB_FIPS_SecureData_Derive Key SKB_DERIVATION_ALGORITHM_NIST_800_108_COUN derivation TER_CMAC_AES128 Key unwrap SKB_FIPS_Engine_CreateDataFromWrapped SKB_CIPHER_ALGORITHM_NIST_AES SKB_DATA_TYPE_BYTES SKB_DATA_FORMAT_RAW Import SKB_FIPS_Engine_CreateDataFromExported Export SKB_FIPS_SecureData_Export SKB_EXPORT_TARGET_CROSS_ENGINE SKB_EXPORT_TARGET_PERSISTENT SKB_FIPS_Engine_Release Key/service context SKB_FIPS_SecureData_Release zeroization SKB_FIPS_Transform_Release SKB_FIPS_Cipher_Release SKB_FIPS_KeyAgreement_Release ** Services impacted by the NIST SP 800-131A algorithm transitions. It is the responsibility of the module operator to ensure that algorithms, modes, and key sizes Disallowed per NIST SP 800-131A are not used.  Table 10 – Module services to API mapping in approved mode of operation © 2014, whiteCryption Corporation. Page 26 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Glossary Term Description AES Advanced Encryption Standard API Application programming interface CBC Cipher block chaining CMAC Cipher-Based Message Authentication Code (SP 800-38B) CO Crypto officer CPU Central processing unit CSP Critical security parameter CTR Counter DRBG Deterministic random bit generator EC Elliptic curve ECB Electronic codebook ECC CDH Elliptic curve cryptography cofactor Diffie-Hellman ECDSA Elliptic Curve Digital Signature Algorithm (FIPS 186-3) FIPS Federal Information Processing Standard GPC General purpose computer HMAC-SHA-1 Keyed-Hash Message Authentication Code (FIPS 198-1) HMAC-SHA-256 IV Initialization vector KAT Known answer test KDF Key derivation function MAC Message authentication code NIST National Institute of Standards and Technology (USA) OAEP Optimal asymmetric encryption padding OS Operating system PCT Pair-wise consistency test © 2014, whiteCryption Corporation. Page 27 of 28 © 2014, Intertrust Technologies Corporation. Crypto Module Security Policy Term Description PKCS Public-Key Cryptography Standard RSA Rivest, Shamir and Adleman algorithm (FIPS 186-3) SECG Standards for Efficient Cryptography Group SEI Source entropy input SHA-1, SHA-256, Secure Hash Algorithm (FIPS 180-3) SHA-384 SHS Secure Hashing Standard SKB Secure Key Box by whiteCryption Table 9 – Glossary © 2014, whiteCryption Corporation. Page 28 of 28 © 2014, Intertrust Technologies Corporation.