Security Policy 11.02.16 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy This document is a non-proprietary security policy for the Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP (Canon imageRUNNER Crypto Module for MEAP) security software. For the remainder of this document the Canon imageRUNNER Crypto Module for MEAP will be referred to as the Module. This document may be freely reproduced and distributed whole and intact including the Copyright Notice. Contents: Preface ............................................................................................................ 2 References .............................................................................................. 2 Document Organization ......................................................................... 2 1 The Cryptographic Module ......................................................................... 3 1.1 Toolkit Interfaces ................................................................................ 4 1.2 Roles and Services ........................................................................... 5 1.3 Cryptographic Key Management ..................................................... 7 1.4 Cryptographic Algorithms ................................................................. 9 1.5 Self-tests ........................................................................................... 10 2 Secure Operation of the Module .............................................................. 12 2.1 Crypto User Guidance .................................................................... 12 2.2 Crypto Officer Guidance ................................................................. 12 2.3 Operating the Cryptographic Module ............................................ 13 2.4 Modes of Operation ......................................................................... 13 2.5 Startup Self Tests ............................................................................. 14 2.6 Default Random Number Generator ............................................. 14 3 Acronyms .................................................................................................... 15 11 February 2016 Copyright © 2016 Canon U.S.A., Inc. 1 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy Preface This document is a non-proprietary security policy for the Canon imageRUNNER Crypto Module for MEAP. This security policy describes how the Module meets the security requirements of FIPS 140-2, and how to securely operate it. This policy is prepared as part of the Level 1 FIPS 140-2 validation of the Module. FIPS 140-2 (Federal Information Processing Standards Publication 140-2 - Security Requirements for Cryptographic Modules) details the U.S. Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the NIST website. References This document deals only with operations and capabilities of the Module in the technical terms of a FIPS 140-2 cryptographic toolkit security policy. Document Organization This Security Policy document is one document in the FIPS 140-2 Validation Submission package. With the exception of the Non-Proprietary Canon imageRUNNER Crypto Module for MEAP Security Policy, the FIPS 140-2 Validation Submission Documentation is RSA Security-proprietary and is releasable only under appropriate non-disclosure agreements. For access to the documentation, please contact Canon U.S.A Inc. This document explains the Module’s features and functionality relevant to FIPS 140-2, and contains the following sections: • This section, “Preface” on page 2 provides an overview and introduction to the Security Policy. • “The Cryptographic Module” on page 3, describes the Module and how it meets the FIPS 140-2 requirements. • “Secure Operation of the Module” on page 12, provides information on implementing the FIPS mode of operation. • “Acronyms” on page 15, lists the definitions for the acronyms used in this document. 2 Preface Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy 1 The Cryptographic Module The Module is classified as a FIPS 140-2 multi-chip standalone module. As such, the Module is tested on particular operating systems and computer platforms. The cryptographic boundary includes the Module running on selected platforms that are running selected operating systems, while configured in single user mode. The Module is validated for all FIPS 140-2 Level 1 security requirements. It is packaged in a Java Archive (JAR) file containing all the code for the toolkit. In addition, the Module relies on the physical security provided by the host on which it runs. The Module is provided in the cryptoCDCFIPS.jar file. The Module is tested on the following platform: • Canon imageRUNNER with MEAP SDK 4.60 SP4 and CDC 1.1 Foundation Profile 1.1 with optional JCE provider package. The Cryptographic Module 3 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy 1.1 Toolkit Interfaces As a multi-chip standalone toolkit, the physical interface to the Module consists of a keyboard, mouse, monitor, serial ports and network adapters. The underlying logical interface to the toolkit is the API, documented in the RSA BSAFE TLS-J ME Javadoc. The Module provides for Control Input through the API calls. Data Input and Output are provided in the variables passed with API calls, and Status Output is provided in the returns and error codes documented for each call. This is shown in the following diagram. Application Data In Data Out Control In Status Out Cryptographic Boundary Cryptographic Module cryptoCDCFIPS.jar Provides services for Runs on JVM Module Java Virtual Machine (JVM) Provides services for Run on OS JVM Operating System (OS) Software Runs on Hardware Hardware Provides service for OS Hardware Figure 1 Logical Diagram 4 The Cryptographic Module Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy 1.2 Roles and Services The Module meets all FIPS140-2 Level 1 requirements for Roles and Services, implementing both a Crypto Officer role and a Crypto User role. As allowed by FIPS 140-2, the Module does not require user identification or authentication for these roles. 1.2.1 Crypto Officer Role The Crypto Officer role is responsible for installation of the toolkit. An operator can assume the Crypto Officer role by instantiating the CryptoProvider class with com.rsa.jme.FIPS140Context.OFFICER_FIPS140 or com.rsa.jme.FIPS140Context.OFFICER_FIPS140_SSL as a parameter. The Crypto Officer is provided with all the services available to the Crypto User (see section 2.4.2). In addition, the Crypto Officer can explicitly re-execute the power-up self-tests after the toolkit has been loaded. This can be done using the com.rsa.jme.CryptoModule.FIPS140.runSelfTests method with FIPS140Context.OFFICER_FIPS140 or FIPS140Context.OFFICER_FIPS140_SSL as the argument. Note: When the Module is loaded and configured for FIPS140-2 use, the power-up self tests run automatically. If the CryptoModule.FIPS140.runSelfTests method is invoked after the toolkit is loaded, all power-up tests will be re-executed. 1.2.2 Crypto User Role The Crypto User role is the default operating role. An operator can explicitly assume the Crypto User role by instantiating the CryptoProvider class with no parameters, or with com.rsa.jme.FIPS140Context.USER_FIPS140 or com.rsa.jme.FIPS140Context.USER_FIPS140_SSL as a parameter. The Cryptographic Module 5 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy 1.2.3 Services The following table details the services provided by the Module in terms of the toolkit interface. Table 1 Role for Authorized Services Authorized Service AlgorithmParameterSpec.java CCMParameterSpec.java Cipher.java CMACParameterSpec.java CryptoException.java CryptoModule.java CryptoProvider.java CryptoRuntimeException.java DESedeKeySpec.java DESKeySpec.java DHParameterSpec.java DHPrivateKeySpec.java DHPublicKeySpec.java DRBGOperParamSpec.java DRBGParamSpec.java DSAParameterSpec.java DSAPrivateKeySpec.java DSAPublicKeySpec.java ECIESParameterSpec.java ECParameterSpec.java ECPoint.java ECPrivateKeySpec.java ECPublicKeySpec.java EntropySource.java FIPS140Context.java GCMParameterSpec.java IvParameterSpec.java KDF.java KDFCounterModeParameterSpec.java KDFKeySpec.java KDFParameterSpec.java Key.java KeyAgreement.java KeyFactory.java KeyPair.java KeyPairGenerator.java KeySpec.java MAC.java MessageDigest.java NoSuchAlgorithmException.java PBKeySpec.java PBParameterSpec.java PrivateKey.java PrivateKeySpec.java PSSParameterSpec.java PublicKey.java PublicKeySpec.java RC2ParameterSpec.java RSAGenParameterSpec.java RSAGenStartValuesSpec.java RSAPrivateCRTKeySpec.java RSAPrivateKeySpec.java RSAPublicKeySpec.java SecretKey.java SecretKeySpec.java SecureRandom.java SensitiveData.java Signature.java SignatureException.java X942DHParameterSpec.java X942DHPrivateKeySpec.java X942DHPublicKeySpec.java The Cryptographic Module 6 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy 1.3 Cryptographic Key Management 1.3.1 Key Generation The Module supports the generation of the DSA, RSA, and ECDSA public and private keys. The toolkit also employs a FIPS-approved HMAC Deterministic Random Bit Generator (HMAC DRBG SP800-90A) for generating asymmetric and symmetric keys used in algorithms such as AES, Triple-DES, RSA, DSA, and ECDSA. 1.3.2 Key Protection All key data resides in internally allocated data structures and can only be output using the Module’s API. The operating system and the Java Runtime Environment (JRE) protects memory and process space from unauthorized access. 1.3.3 Key Access An authorized operator of the Module has access to all key data created during the operation of the Module. Note: The User and Officer roles have equal and complete access to all keys. The following table lists the different services provided by the toolkit with the type of access to keys or Critical Security Parameters (CSPs). Table 2 Key and CSP Access Service Key or CSP Type of Access Encryption and decryption Symmetric keys (AES and Triple-DES) Read/Execute Digital signature and Asymmetric keys (DSA, RSA, and ECDSA) Read/Execute verification Hashing None N/A MAC HMAC keys Read/Execute Random number generation HMAC DRBG Entropy, V Value, Key, and init_seed Read/Write/Execute Key establishment primitives Asymmetric keys (RSA), KDF CTR, and KDF X9.63 Read/Execute Symmetric keys (AES and Triple-DES) Key generation Write Asymmetric keys (DSA, ECDSA, and RSA) MAC keys (HMAC) Self-test (only available to Hardcoded keys Read/Execute Crypto Officer service) (AES, Triple-DES, RSA, DSA, ECDSA and HMAC) Show status None N/A Zeroization All Read/Write The Cryptographic Module 7 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy 1.3.4 Key Zeroization Users can ensure sensitive data is properly zeroized by making use of the SensitiveData.clearSensitiveData method for clearing sensitive data. The toolkit ensures that all ephemeral sensitive data is cleared within the toolkit. 1.3.5 Key Storage The Module does not provide long-term cryptographic key storage. Storage of keys is the responsibility of the user of the Module. The following table shows how the storage of keys and CSPs are handled. The Crypto User and Crypto Officer roles have equal and complete access to all keys and CSPs. Table 3 Key and CSP Storage Item Storage AES keys In volatile memory only (plaintext) Triple-DES keys In volatile memory only (plaintext) HMAC with SHA1 and SHA2 keys In volatile memory only (plaintext) ECDSA public keys In volatile memory only (plaintext) ECDSA private keys In volatile memory only (plaintext) RSA public key In volatile memory only (plaintext) RSA private key In volatile memory only (plaintext) DSA public key In volatile memory only (plaintext) DSA private key In volatile memory only (plaintext) HMAC DRBG Entropy In volatile memory only (plaintext) HMAC DRBG V Value In volatile memory only (plaintext) HMAC DRBG Key In volatile memory only (plaintext) HMAC DRBG init_seed In volatile memory only (plaintext) HMAC Integrity Test Key In Module JAR file (plaintext) The Cryptographic Module 8 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy 1.4 Cryptographic Algorithms The Module meets FIPS 140-2 requirements by implementing algorithm enforcement, such that when operating in FIPS140_MODE, only FIPS 140-approved algorithms are available for use. The following table lists the FIPS 140-approved algorithms provided by the Module, when operating in FIPS140_MODE. Table 4 FIPS-approved Algorithms in the Module Algorithm Validation Certificate AES in ECB, CBC, CCM, and CMAC mode Certificate #3442 AES key wrap (SP800-38F) - KW (AE, AD, AES-128, AES-192, and AES-256) Certificate #3442 AES in GCM mode with automatic Initialization Vector (IV) generation Certificate #3442 Certificate #1939 Triple-DES in ECB and CBC mode Triple-DES key wrap Non-approved (Allowed in FIPS mode) DSA Certificate #969 Note: Key size of 1024 bits can only be used for verification.1 Certificate #694 EC-DSA and EC-DSA-SHA1 Certificate #840 HMAC DRBG (SP800-90A) Certificate #2191 HMAC-SHA1, SHA224, SHA256, SHA384, and SHA512 Certificate #60 KDF CTR (SP800-108) CVL Certificate #528 KDF X9.63 (SP800-135) RSA key wrap Non-approved (Allowed in FIPS mode for key transport) NDRNG (Timer-based entropy) Non-approved (Allowed in FIPS mode) RSA X9.31, PKCS #1 V.1.5, PKC S#1 V.2.1, and RSASSA-PSS Certificate #1763 verification.1 Note: Key size of 1024 bits can only be used for SHA-1 and SHA-224, 256, 384, and 512 Certificate #2842 1 Key size restriction as per SP800-131A. The Cryptographic Module 9 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy The following list contains the non-FIPS 140-approved algorithms provided by the Module, when operating in NON_FIPS140_MODE. • DES • ECIES • MD4 • MD5 • PBE RC2® block cipher • RC4® stream cipher • • RSA OAEP for key transport Raw RSA (encrypt/decrypt) • • HMAC-MD5 • FIPS 186-2 PRNG • Diffie-Hellman (DH) primitives • EC-DH and EC-DH with Cofactor primitives. 1.5 Self-tests The Module performs power-up and conditional self-tests to ensure proper operation. If the power-up self-test fails, the toolkit is disabled and throws a SecurityException. The toolkit can only leave the disabled state by restarting the JVM. If the conditional self-test fails, the toolkit throws a SecurityException and aborts the operation. A conditional self test failure does not disable the toolkit. 1.5.1 Power-up Self-tests The following power-up self-tests are implemented in The Module: • FIPS186 PRNG KAT • AES encrypt/decrypt KAT • AES GCM encrypt/decrypt KAT • AES CCM encrypt/decrypt KAT • AES CMAC KAT • AES key wrap encrypt/decrypt KAT • KDF X9.63 KAT • KDR CTR KAT • Triple-DES encrypt/decrypt KAT • SHA-1 KAT • SHA-224 KAT The Cryptographic Module 10 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy • SHA-256 KAT • SHA-384 KAT • SHA-512 KAT • MD5 KAT • HMAC SHA-1 KAT • HMAC SHA-224 KAT • HMAC SHA-256 KAT • HMAC SHA-384 KAT • HMAC SHA-512 KAT • HMAC DRBG Self-Test • ECDSA KAT • DSA KAT • DSA, RSA, ECDSA pair-wise consistency test • RSA (signature) KAT • Software integrity check. Power-up self-tests are executed automatically when the Module is loaded into memory. 1.5.2 Conditional Self-tests The Module performs two conditional self-tests: • Pair-wise consistency tests each time the toolkit generates a DSA, RSA or ECDSA public/private key pair. • Continuous RNG (CRNG) test each time the toolkit produces random data, as per the FIPS 140-2 standard. The CRNG test is performed on all approved and non- approved PRNGs (HMAC DRBG). 1.5.3 Mitigation of Other Attacks RSA key operations implement blinding. Blinding is a reversible way of modifying the input data, so as to make the RSA operation immune to timing attacks. Blinding has no effect on the algorithm other than to mitigate attacks on the algorithm. Blinding values are squared for each operation. The Cryptographic Module 11 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy 2 Secure Operation of the Module The Module does not require any special configuration to operate in conformance with FIPS 140-2 requirements. The following guidance must be followed, however, to achieve a FIPS mode of operation. 2.1 Crypto User Guidance The Crypto User must only use algorithms approved for use in a FIPS mode of operation, as listed in Table 4, “FIPS-approved Algorithms in the Module,” on page 9. The requirements for using the approved algorithms in a FIPS mode of operation are as follows: • The bit-length for a DSA key pair must be 1024 bits. This key size can only be used for verification. • Random Number Generators must be seeded with values of at least 160 bits in length. Bit lengths for an RSA1 key pair must be 1024 (this key size can only be used for • verification), 2048 or 3072. • Bit lengths for an HMAC key must be one half of the block size. • If RSA key generation is requested in FIPS mode, the toolkit always uses the FIPS140-approved RSA X9.31 key-generation procedure. Key wrapping methodology provides between 112 and 128 bits of encryption strength. • When using an Approved RNG to generate keys, the RNG's requested security strength must be at least as great as the security strength of the key being generated. More information on the algorithm strength and key size is provided in the RSA BSAFE TLS-J ME Release Notes. Users should take care to zeroize CSPs when they are no longer needed. 2.2 Crypto Officer Guidance The Crypto Officer is responsible for installing the toolkit. Installation instructions are provided in the 4A-TLS-J ME Installation Guide. When operating the toolkit after installation, the Crypto Officer must follow the Crypto User guidance requirements detailed in section 2.1. 1 When used for transporting keys and using the minimum allowed modulus size, the minimum strength of encryption provided is 112 bits. Secure Operation of the Module 12 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy 2.3 Operating the Cryptographic Module The Module operates in FIPS140_MODE by default. When using the Module in this FIPS approved mode, the Module ensures that only the FIPS approved algorithms listed in “Services” on page 6 are available to operators. The Service CryptoModule.FIPS140.runSelfTests() is restricted to operation by the Crypto Officer. 2.4 Modes of Operation There are three modes of operation: • FIPS140_MODE • FIPS140_SSL_MODE • NON_FIPS140_MODE. The following table lists the available modes, and the algorithms available in those modes. Cryptographic algorithms can be created in different modes using the associated com.rsa.jme.FIPS140Context instance to instantiate a CryptoProvider object. For more information about operating in FIPS modes, see the RSA BSAFE TLS-J ME Javadoc. Table 5 Mode Value to Change the Mode of Operation Mode Value Algorithms Available Provides the cryptographic algorithms listed inTable 4, FIPS140Context.MODE_FIPS140 FIPS 140-2 approved. “FIPS-approved Algorithms in the Module,” on page 9. This is the default mode on start up. FIPS140Context.MODE_FIPS140_SSL Provides the same algorithms as FIPS 140-2 approved if used with TLS FIPS140Context.MODE_FIPS140, plus the MD5 message protocol implementations. digest. This mode can be used in the context of the key establishment phase in the TLSv1, TLSv1.1 and TLSv1.2 protocols. For more information, see section 7.1 Acceptable Key Establishment Protocols in Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program. The implementation guidance disallows the use of the SSLv2 and SSLv3 versions. Cipher suites that include non-FIPS 140-2-approved algorithms are unavailable. This mode allows implementations of the TLS protocol to operate the Module in a FIPS 140-2-compliant manner. Note: The TLS protocol was not reviewed or tested by the CAVP or CMVP. FIPS140Context.MODE_NON_FIPS140 Allows users to operate the Module without any cryptographic Not FIPS 140-2 approved. algorithm restrictions. Secure Operation of the Module 13 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy 2.5 Startup Self Tests All KATs are executed on toolkit start-up, which occurs on first use. If any KAT fails, the toolkit is disabled. 2.6 Default Random Number Generator The Module provides a default RNG, which is HMAC-DRBG, with 128-bit security, using SHA-256. Secure Operation of the Module 14 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy 3 Acronyms The following table lists the acronyms used in this document and their definitions. Table 6 Acronyms and Definitions Acronym Definition AES Advanced Encryption Standard. A fast block cipher with a 128-bit block, and keys of lengths 128, 192 and 256 bits. This will replace DES as the US symmetric encryption standard. API Application Programming Interface. Attack Either a successful or unsuccessful attempt at breaking part or all of a cryptosystem. Attack types include an algebraic attack, birthday attack, brute force attack, chosen ciphertext attack, chosen plaintext attack, differential cryptanalysis, known plaintext attack, linear cryptanalysis, middleperson attack and timing attack. CBC Cipher Block Chaining. A mode of encryption in which each ciphertext depends upon all previous ciphertexts. Changing the Initialization Vector (IV) alters the ciphertext produced by successive encryptions of an identical plaintext. CRNG Continuous Random Number Generation. CSP Critical Security Parameters. DES Data Encryption Standard. A symmetric encryption algorithm with a 56-bit key. Diffie-Hellman The Diffie-Hellman asymmetric key exchange algorithm. There are many variants, but typically two entities exchange some public information (for example, public keys or random values) and combines them with their own private keys to generate a shared session key. As private keys are not transmitted, eavesdroppers are not privy to all of the information that composes the session key. DRBG Deterministic Random Bit Generator. DSA Digital Signature Algorithm. An asymmetric algorithm for creating digital signatures. EC Elliptic Curve. ECB Electronic Code Book. A mode of encryption in which identical plaintexts are encrypted to identical ciphertexts, given the same key. ECC Elliptic Curve Cryptography. ECDH Elliptic Curve Diffie-Hellman. ECDHC Elliptic Curve Diffie-Hellman with Cofactor. ECDSA Elliptic Curve Digital Signature Algorithm. ECIES Elliptic Curve Integrated Encryption Scheme. Acronyms 15 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy Table 6 Acronyms and Definitions Acronym Definition Encryption The transformation of plaintext into an apparently less readable form (called ciphertext) through a mathematical process. The ciphertext may be read by anyone who has the key that decrypts (undoes the encryption) the ciphertext. FIPS Federal Information Processing Standards. HMAC Keyed-Hashing for Message Authentication Code. IV Initialization Vector. Used as a seed value for an encryption operation. JVM Java Virtual Machine. KAT Known Answer Test. KDF Key Derivation Function. Derives one or more secret keys from a secret value, such as a master key, using a pseudo-random function. Key A string of bits used in cryptography, allowing people to encrypt and decrypt data. Can be used to perform other mathematical operations as well. Given a cipher, a key determines the mapping of the plaintext to the ciphertext. Various types of keys include: distributed key, private key, public key, secret key, session key, shared key, subkey, symmetric key, and weak key. MD4 A message digest algorithm which implements a cryptographic hash function, created by Rivest. MD5 A message digest algorithm which implements a cryptographic hash function with a 128-bit hash value, created by Rivest. NDRNG Non-deterministic Random Number Generator. NIST National Institute of Standards and Technology. A division of the US Department of Commerce (formerly known as the NBS) which produces security and cryptography-related standards. OS Operating System. PC Personal Computer. private key The secret key in public key cryptography. Primarily used for decryption but also used for encryption with digital signatures. PRNG Pseudo-random Number Generator. RC2 Block cipher developed by Ron Rivest as an alternative to the DES. It has a block size of 64 bits and a variable key size. It is a legacy cipher and RC5 should be used in preference. RC4 Symmetric algorithm designed by Ron Rivest using variable length keys (usually 40 bit or 128 bit). RNG Random Number Generator. Acronyms 16 Canon imageRUNNER Crypto Module 2.1.1.1 for MEAP Security Policy Table 6 Acronyms and Definitions Acronym Definition RSA Public key (asymmetric) algorithm providing the ability to encrypt data and create and verify digital signatures. RSA stands for Rivest, Shamir, and Adleman, the developers of the RSA public key cryptosystem. SHA Secure Hash Algorithm. An algorithm which creates a hash value for each possible input. SHA takes an arbitrary input which is hashed into a 160-bit digest. SHA-1 A revision to SHA to correct a weakness. It produces 160-bit digests. SHA-1 takes an arbitrary input which is hashed into a 20-byte digest. SHA-2 The NIST-mandated successor to SHA-1, to complement the Advanced Encryption Standard. It is a family of hash algorithms (SHA-256, SHA-384 and SHA-512) which produce digests of 256, 384 and 512 bits respectively. Triple-DES A symmetric encryption algorithm which uses either two or three DES keys. The two key variant of the algorithm provides 80 bits of security strength while the three key variant provides 112 bits of security strength. Acronyms 17