Non-Proprietary Box JCA Cryptographic Module 1.0 FIPS 140-2 Level 1 Security Policy Version Number: 1.5 Date: February 29, 2016 Table of Contents 3 1. MODULE OVERVIEW 5 2. MODES OF OPERATION 5 2.1 APPROVED CRYPTOGRAPHIC FUNCTIONS 6 2.2 ALL OTHER ALGORITHMS 6 3. PORTS AND INTERFACES 7 4. ROLES AND SERVICES 7 4.1 CRYPTO-OFFICER AND USER ROLES 7 4.2 APPROVED SERVICES 8 5. CRYPTOGRAPHIC KEYS AND CSPS 9 6. SELF-TESTS © 2016 Box, Inc. The Security Policy may be reproduced only in its original entirety (without revision). 2 3 1. Module Overview The Box Java Cryptography Architecture (JCA) Cryptographic Module is a Java Cryptography Architecture provider that provides encryption, hashing and random number generation utilizing FIPS 140-2 approved algorithms. The JCA is a software module that executes in a modifiable operational environment by a general purpose computer. The logical boundary of the software module includes of the following components (Figure 1): boxjca_provider.jar o box_sunjce_provider.jar o local_policy.jar o US_export_policy.jar o boxjca_provider.hmac o Figure 1: Box JCA Cryptographic Module Block Diagram Cryptographic Boundary Box JCA Cryptographic Module Includes: boxjca_provider.jar, box_sunjce_provider.jar, local_policy.jar, US_export_policy.jar, and boxjca_provider.hmac Java Virtual Machine Operating System FIPS 140-2 conformance testing was performed at Security Level 1. The configuration tested by the lab is described in Table 1. © 2016 Box, Inc. The Security Policy may be reproduced only in its original entirety (without revision). 3 4 Table 1: Configuration tested by the lab Java Run-Time CPU Operating System Software Component Environment (JRE) boxjca_provider.jar • Scientific Linux Dell PowerEdge R610 • JRE 1.6.0 box_sunjce_provider.jar • using 6.4 • JRE 1.7.0 local_policy.jar Intel(R) Xeon(R) • US_export_policy.jar X5675 • • boxjca_provider.hmac The Box JCA Cryptographic Module meets FIPS 140-2 Level 1 requirements as described in Table 2. Table 2: Module Security Level Statement FIPS Security Area Security Level Cryptographic Module Specification 1 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 1 Mitigation of Other Attacks N/A © 2016 Box, Inc. The Security Policy may be reproduced only in its original entirety (without revision). 4 5 2. Modes of Operation In the FIPS 140-2 approved mode of operation, the JCA module performs FIPS approved security functions as listed in section 2.1 Approved Cryptographic Functions. When the Java virtual machine begins execution, it loads the class BoxProvider of the boxjca_provider and instantiates the provider if the power-up self-tests have been passed successfully. The power-up self-tests are called from the constructor of the class BoxProvider. 2.1 Approved Cryptographic Functions The following approved cryptographic algorithms are used in the FIPS approved mode of operation. Table 3: Approved Cryptographic Functions Algorithm CAVP Certificate AES ECB (128 , 192 , 256) 2666 AES CTR (128 , 192 , 256) SHS (SHA1, SHA256, SHA384 and SHA512) 2239 HMAC (HMAC-SHA1, HMAC-SHA256, HMAC- 1657 SHA384, and HMAC-SHA512) SP 800-90A HMAC_DRBG 429 © 2016 Box, Inc. The Security Policy may be reproduced only in its original entirety (without revision). 5 6 2.2 All Other Algorithms In the non-FIPS mode of operation the module performs non-approved functions listed in this section. With the exception of NDRNG these functions shall not be used in FIPS approved mode of operation. o AES (CBC, PCBC, CTS, CFB, CFB8, PBEWithSHA1AndRC2_40 o CFB128, OFB, OFB8, and OFB128 modes; ARCFOUR o non-compliant) RSA (key wrapping; non-compliant) o o Blowfish HMAC-MD5 o o DES PBKDF2WithHmacSHA1 o o Triple-DES (non-compliant) DSA (non-compliant) o o RC2 MD2 o o Diffie-Hellman (non-compliant) MD5 o o PBEWithMD5AndDES SHA1PRNG o o PBEWithMD5AndTripleDES NDRNG o o PBEWithSHA1AndTripleDES 3. Ports and Interfaces The logical interfaces to the module are implemented via an Application Programming Interface (API). The following table describes each logical interface. Table 4: FIPS 140-2 Logical Interfaces Logical Interface Description Input parameters that are supplied to the API Data Input commands Output parameters that are returned by the API Data Output commands Control Input API commands Exceptions and return status provided by API Status Output commands © 2016 Box, Inc. The Security Policy may be reproduced only in its original entirety (without revision). 6 7 4. Roles and Services 4.1 Crypto-Officer and User roles There are two roles the module supports: Crypto-Officer role and a User role. 4.2 Approved Services The module provides the following cryptographic services. Table 5: Roles and Services Types of Access to Cryptographic Keys and Critical Security Parameters (CSPs) Service Corresponding Roles R – Read W – Write or Create Z – Zeroize AES Cipher Encrypt User AES Key: R / Decrypt Crypto-Officer SHA hash User None computation Crypto-Officer HMAC hash User HMAC Key: R computation Crypto-Officer Entropy Input: R HMAC-SHA256 User DRBG seed: R, W DRBG Random Crypto-Officer AES key: W output HMAC key: W User N/A Perform Self-Tests Crypto-Officer Zeroization by All: Z User power cycling or Crypto-Officer rebooting the system User N/A Show status Crypto-Officer Installation of the N/A Crypto-Officer module © 2016 Box, Inc. The Security Policy may be reproduced only in its original entirety (without revision). 7 8 The module provides the following APIs: o Cipher.getInstance Mac.init o o Cipher.init Mac.doFinal o o Cipher.doFinal SecureRandom.getInstance o o MessageDigest.getInstance SecureRandom.setSeed o o MessageDigest.digest SecureRandom.nextBytes o o Mac.getInstance o boxProvider.powerOnSelfTest The user must call the module’s APIs with appropriate parameters to invoke the module’s services. See user guidance for details. Non-Approved cryptographic services are implementations of Non-Approved algorithms. They are listed in the Section 2.2. 5. Cryptographic Keys and CSPs The table below describes cryptographic keys and CSPs used by the module. Table 6: Cryptographic keys and CSPs employed by the module Origin Zeroization Key Description/Usage AES Key Used during AES Generated using Zeroized during power cycle encryption and HMAC_DRBG or reboot decryption HMAC Key Used during Generated using Zeroized during computation of HMAC_DRBG power cycle or reboot HMAC Entropy Input Used during Generated using Zeroized during construction of the NDRNG power cycle or reboot seed DRBG Seed Used during Constructed in Zeroized during instantiation of the accordance with SP power cycle or reboot DRBG 800-90A The keys must be generated by using SP 800-90A HMAC_DRBG. The Keys and CSPs are stored in plain text within the module. © 2016 Box, Inc. The Security Policy may be reproduced only in its original entirety (without revision). 8 9 6. Self-tests The module performs power-up and conditional self-tests that are listed in the table below. Upon failure of a power-up self-test the module throws an exception and fails to load. Upon failure of a conditional self-test the module throws an exception and returns no data to the caller. The following table describes self-tests implemented by the module. Table 7: Self-Tests Algorithm Test AES encrypt Known Answer Test [KAT] AES decrypt KAT SHA1 KAT SHA256 KAT SHA384 KAT SHA512 KAT HMAC-SHA1 KAT HMAC-SHA256 KAT HMAC-SHA384 KAT HMAC-SHA512 KAT SP800-90A KAT HMAC_DRBG Continuous Random Number Generator test DRBG Health test Native NDRNG Continuous Random Number Generator test Box entropy source Continuous Random Number Generator test NDRNG Software integrity test KAT using HMAC © 2016 Box, Inc. The Security Policy may be reproduced only in its original entirety (without revision). 9