Security Policy 30.07.19 RSA BSAFE® Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication This document is a non-proprietary Security Policy for the RSA BSAFE Crypto-C Micro Edition 4.1.4 (Crypto-C ME) cryptographic module from RSA Security LLC (RSA), a Dell Technologies company. This document may be freely reproduced and distributed whole and intact including the Copyright Notice. Contents: Preface ............................................................
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication Preface This security policy describes how Crypto-C ME meets the relevant Level 2 security requirements of FIPS 140-2 and describes how to securely operate Crypto-C ME in a FIPS 140-2-compliant manner. Federal Information Processing Standards Publication 140-2 - Security Requirements for Cryptographic Modules (FIPS 140-2) details the United States Government requirements for cryptographic modules.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1 Crypto-C ME Cryptographic Toolkit Crypto-C ME is designed for different processors, and includes various optimizations. Assembly-level optimizations on key processors mean Crypto-C ME algorithms can be used at increased speeds on many platforms. The Crypto-C ME software development toolkit is designed to enable developers to incorporate cryptographic technologies into applications.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.1 Cryptographic Module Crypto-C ME is classified as a multi-chip standalone cryptographic module for the purposes of FIPS 140-2. As such, Crypto-C ME must be tested on a specific operating system and computer platform. The cryptographic boundary includes Crypto-C ME running on selected platforms running selected operating systems while configured in “single user” mode.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.1.1 Laboratory Validated Operating Environments For FIPS 140-2 validation, Crypto-C ME is tested by an accredited FIPS 140-2 testing laboratory on the following operating environments: • • Apple®: – iOS® 11.0 on ARM®v8 (64-bit), built with Xcode® 9 – iOS 10.0 on ARMv7 (32-bit), built with Xcode 9 – macOS® 10.13 on x86_64 (64-bit), built with Xcode 7.3 – macOS 10.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication • Micro Focus®: – SUSE® Linux Enterprise Server 15 on x86_64 (64-bit), built with LSB 4.0 and gcc 4.4 – SUSE Linux Enterprise Server 12 SP3 on: – • • ARMv8 (64-bit) built with gcc 4.8 • PowerPC (64-bit), built with gcc 4.8 • x86_64 (64-bit), built with LSB 4.0 and gcc 4.4 • x86 (32-bit), built with LSB 4.0 and gcc 4.4.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication – Windows Server 2008 Enterprise SP2 on: • • Oracle®: – – Solaris® 11.4 on • SPARC® v9-T4 (64-bit), built with Sun C 5.13 • SPARC v8+ (32-bit), built with Sun C 5.13 • SPARC v8 (32-bit), built with Sun C 5.8 • x86_64 (64-bit), built with Sun C 5.13. Solaris 10 Update 11 on: • • Itanium (64-bit), built with Visual Studio 2010 (/MT). x86 (32-bit), built with Sun C 5.13.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication – – – – • – • 8 • x86_64 (64-bit), built with Xcode 7.3 • x86 (32-bit), built with Xcode 7.3. OS X 10.10 on: • x86_64 (64-bit), built with Xcode 7.3 • x86 (32-bit), built with Xcode 7.3. OS X 10.9 on: • x86_64 (64-bit), built with Xcode 7.3 • x86 (32-bit), built with Xcode 7.3. OS X 10.8 on: • x86_64 (64-bit), built with Xcode 7.3 • x86 (32-bit), built with Xcode 7.3.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication • IBM: – • • PowerPC 64-bit, built with XLC v11.1 • PowerPC 32-bit, built with XLC v11.1. Micro Focus®: – – – • AIX v7.1 on: SUSE® Linux Enterprise Server 15 on: • x86 (32-bit), built with LSB 4.0 and gcc 4.4 • PowerPC 64-bit, built with and gcc 4.8. SUSE Linux Enterprise Server 12 SP4 on: • ARMv8 (64-bit) built with gcc 4.8 • PowerPC (64-bit), built with gcc 4.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication • – Windows Server 2016 on: • – – – – • x86_64 (64-bit), built with Visual Studio 2017 (/MD) • x86_64 (64-bit), built with Visual Studio 2013 (/MT • x86_64 (64-bit), built with Visual Studio 2010 (/MT).
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication • • Oracle: – Solaris 11.4 on SPARC v9-T2 (64-bit), built with Sun C 5.13 – Solaris 10 Update 11 on: • SPARC v9-T4 (64-bit), built with Sun C 5.13 • SPARC v9-T2 (64-bit), built with Sun C 5.13 • SPARC v8+ (32-bit), built with Sun C 5.13 • SPARC v8 (32-bit), built with Sun C 5.8 • x86_64 (64-bit) built with Sun C 5.13. Red Hat: – Enterprise Linux 7.
RSA BSAFE Crypto-C Micro Edition 4.1.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication Privileged user accounts are able to use tracing and debugging utilities to target a process with a different user id to the controlling process. An operator using this privilege to inspect or manipulate a process operating on behalf of another operator contravenes the single operator mode of operation.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.2 Crypto-C ME Interfaces Crypto-C ME is validated as a multi-chip standalone cryptographic module. The physical cryptographic boundary of the module is the case of the general-purpose computer or mobile device, which encloses the hardware running the module.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication The underlying logical interface to Crypto-C ME is the API, documented in the RSA BSAFE Crypto-C Micro Edition Developers Guide. Crypto-C ME provides for Control Input through the API calls. Data Input and Output are provided in the variables passed with the API calls, and Status Output is provided through the returns and error codes documented for each call.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.3 Roles, Services and Authentication Crypto-C ME meets all FIPS 140-2 Level 2 requirements for roles, services, and authentication, implementing both a User role and Crypto Officer role. Role-based authentication is implemented for these roles. Only one role can be active at a time and Crypto-C ME does not allow concurrent operators. 1.3.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication To set the initial authentication data in the roles database, the call to R_PROV_FIPS140_init_roles() must supply an authentication callback function. The authentication callback function is called once for each type of role to allow the application to set the initial authentication data.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.3.4 Unloading and Reloading the Module A roles database stored in memory is erased when the cryptographic module is unloaded. When the cryptographic module is reloaded, the roles database must be recreated before any roles are accessible. For the steps to create a roles database in memory, see To create the roles database in memory:.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.4 Cryptographic Key Management Cryptographic key management is concerned with generating keys, key assurance, storing keys, managing access to keys, protecting keys during use, and zeroizing keys when they are no longer required. 1.4.1 Key Generation Crypto-C ME supports the generation of DSA, RSA, Diffie-Hellman (DH) and Elliptic Curve Cryptography (ECC) public and private keys.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication Table 2 Key Storage (continued) Key or CSP Generation/Input/Output Storage HMAC keys • Entered in plaintext through the API or generated by an explicit API call • Output in plaintext through the API. Volatile memory only (plaintext) DH public/private keys • Entered in plaintext through the API or generated by an explicit API call • Output in plaintext through the API.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.4.4 Key Access An authorized operator of the module has access to all key data created during Crypto-C ME operation. Note: The Crypto User and Crypto 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 CSPs.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.4.5 Key Protection/Zeroization All key data resides in internally allocated data structures and can be output only using the Crypto-C ME API. The operating system protects memory and process space from unauthorized access.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.5 Cryptographic Algorithms To achieve compliance with the FIPS 140-2 standard, only FIPS 140-2-approved or allowed algorithms can be used in an approved mode of operation. Note: Crypto User Guidance on Algorithms provides algorithm-specific guidance on the use of the algorithms listed in this section. 1.5.
RSA BSAFE Crypto-C Micro Edition 4.1.
RSA BSAFE Crypto-C Micro Edition 4.1.
RSA BSAFE Crypto-C Micro Edition 4.1.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.5.2 FIPS 140-2-allowed Algorithms The following table lists the Crypto-C ME FIPS 140-2-allowed algorithms, with appropriate standards.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.5.3 Non-FIPS 140-2-approved Algorithms The following table lists the algorithms that are not FIPS 140-2-approved.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.6 Self Tests Crypto-C ME performs a number of power-up and conditional self-tests to ensure proper operation. If a power-up self-test fails for one of the resource libraries, all cryptographic services for the library are disabled. Services for a disabled library can only be re-enabled by reloading the FIPS 140-2 module.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 1.6.2 Conditional Self-tests Crypto-C ME performs two conditional self-tests: • A pair-wise consistency test each time Crypto-C ME generates a DH, DSA, RSA, or ECC public/private key pair. • A Continuous Random Number Generation (CRNG) test each time the toolkit produces random data, as per the FIPS 140-2 standard.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication Constant time padding operation: RSA PKCS#1 v1.5 encryption padding operations are implemented in constant time in order to make the operation immune to timing attacks. For more information, see Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS #1.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2 Secure Operation of Crypto-C ME This section provides an overview of how to securely operate Crypto-C ME in compliance with the FIPS 140-2 standards. Note: The module operates as a Validated Cryptographic Module only when the rules for secure operation are followed. 2.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication • – The key establishment methodology provides: • between 112 bits and 256 bits of encryption strength when using approved domain parameter size sets, as listed in Table 4. • between 112 and 256 bits of encryption strength when curves that are allowed. • less than 112 bits of encryption strength when using curves that are not allowed.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication • • 112 or 128 bits of encryption strength when using approved modulus sizes, as listed in Table 4. • between 112 and 256 bits of encryption strength when using allowed modulus sizes. • less than 112 bits 256 bits of encryption strength when using modulus sizes that are not allowed. Digital Signatures. – An approved DRBG must be used for digital signature generation.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication • KDFs: – – For HKDF: • A FIPS 140-2 approved HMAC must be used. • A particular key-derivation key must only be used for a single key-expansion step. For more information see SP 800-56C Rev. 1 • The derived key must be used only as a secret key. • The derived key shall not be used as a key stream for a stream cipher.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication • The KDF is performed in the context of the TLS protocol • HMAC is as specified in FIPS 198-1 • P_HASH uses either SHA-256, SHA-384 or SHA-512. For more information, see SP 800-135 Rev. 1. The TLS protocols have not been tested by the CAVP and CMVP. • • MAC: – The key length for an HMAC generation or verification must be equal to or greater than 112 bits.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication RFC 5288, are generated deterministically by the module using an 64-bit global counter within the module. The module uses the current system time to initialize the counter when it is first used. The module user must ensure the system time is valid to prevent repetition of IVs. – In case the power to the module is lost and then restored, a new key must be used for AES GCM encryption/decryption.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2.1.2 Crypto User Guidance on Obtaining Assurances for Digital Signature Applications The module provides support for the FIPS 186-4 standard for digital signatures. The following gives an overview of the assurances required by FIPS 186-4. SP 800-89 provides the methods to obtain these assurances.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication Table 9 Verifier Requirements (continued) FIPS 186-4 Requirement Module Capabilities and Recommendations Outside the scope of the module. Obtain assurance that the claimed signatory actually possessed the private key that was used to generate the digital signature at the time that the signature was generated. 2.1.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2.1.4 Crypto User Guidance on Obtaining Assurances for Key Transport Applications The module provides support for the recommendations for key transport in SP 800-56B, which provides the methods to obtain these assurances. The table below describes the SP 800-56B recommendations for key transport.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication To comply with both roles database requirements the PIN must have a minimum of 73 random bits.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2.2 Roles If a user of Crypto-C ME needs to operate the toolkit in different roles, then the user must ensure all instantiated cryptographic objects are destroyed before changing from the Crypto User role to the Crypto Officer role, or unexpected results could occur.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2.3 Modes of Operation The following table lists the available mode filters to determine the mode Crypto-C ME operates in and the algorithms allowed. Table 13 Crypto-C ME Mode Filters Mode Description R_MODE_FILTER_FIPS140 FIPS 140-2-approved. Implements FIPS 140-2 mode and provides the cryptographic algorithms listed in Table 4. The default pseudo-random number generator (PRNG) is CTR DRBG.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2.4 Operating Crypto-C ME Crypto-C ME operates in an unrestricted mode on startup, providing access to all cryptographic algorithms available from the FIPS 140-2 provider set against the library context. To restrict the module to a specific set of algorithms, call R_LIB_CTX_set_mode() with one of the mode filters listed in listed in Table 13.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 2.6 Deterministic Random Number Generator In all modes of operation, Crypto-C ME provides the CTR DRBG as the default deterministic random number generator (DRNG).
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services and Authentication 3 Services The following is the list of authenticated and unauthenticated services provided by Crypto-C ME. Authenticated services can only be used by users authenticated in the Crypto Officer or Crypto User role. Unauthenticated services can be used by any user. For more information about authentication of roles, see Roles, Services and Authentication.
RSA BSAFE Crypto-C Micro Edition 4.1.
RSA BSAFE Crypto-C Micro Edition 4.1.
RSA BSAFE Crypto-C Micro Edition 4.1.
RSA BSAFE Crypto-C Micro Edition 4.1.
RSA BSAFE Crypto-C Micro Edition 4.1.
RSA BSAFE Crypto-C Micro Edition 4.1.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services, and Authentication 4 Acronyms and Definitions The following table lists and describes the acronyms and definitions used throughout this document. Table 14 Acronyms and Definitions Term Definition AES Advanced Encryption Standard. A fast symmetric key algorithm with a 128-bit block, and keys of lengths 128, 192, and 256 bits. Replaces DES as the US symmetric encryption standard.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services, and Authentication Table 14 Acronyms and Definitions (continued) 54 Term Definition CTR DRBG Counter mode Deterministic Random Bit Generator. CTS Cipher text stealing mode of encryption, which enables block ciphers to be used to process data not evenly divisible into blocks, without the length of the ciphertext increasing. DES Data Encryption Standard.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services, and Authentication Table 14 Acronyms and Definitions (continued) Term Definition FFC Finite Field Cryptography (FFC): the public-key cryptographic methods using operations in a multiplicative group of a finite field. FFC keys are use in algorithms including DSA and Diffie-Hellman. FIPS Federal Information Processing Standards.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services, and Authentication Table 14 Acronyms and Definitions (continued) 56 Term Definition Key A string of bits used by cryptographic algorithms. There are a variety of cryptographic key types. These keys might be used for operations such as encryption or decryption, cryptographic signing or verification, or key agreement. Some types of keys are intended to be kept secret, and other keys are intended to be public.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services, and Authentication Table 14 Acronyms and Definitions (continued) Term Definition PRF PseudoRandom Function 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. Public Key TBA RC2 Block cipher developed by Ron Rivest as an alternative to the DES.
RSA BSAFE Crypto-C Micro Edition 4.1.4 Security Policy Level 1 with Level 2 Roles, Services, and Authentication Table 14 Acronyms and Definitions (continued) 58 Term Definition SHA-2 The NIST-mandated successor to SHA-1, to complement the Advanced Encryption Standard. It is a family of hash algorithms (SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256), which produce digests of 224, 256, 384, 512, 224, and 256 bits respectively.
RSA BSAFE Crypto-C Micro Edition 4.1.