Reference Guide

ManualsBrandsDell ManualsBSAFEBSAFE Crypto-J

Security Policy

09.10.14

RSA BSAFE

Crypto-C Micro Edition

Version 4.1

Security Policy Level 1

This is a non-proprietary Security Policy for RSA BSAFE Crypto-C Micro Edition 4.1

(Crypto-C ME). It describes how Crypto-C ME meets the Level 1 security requirements

of FIPS 140-2, the Level 3 security requirements of FIPS 140-2 for design assurance,

and how to securely operate Crypto-C ME in a FIPS 140-2-compliant manner. This

Security Policy is prepared as part of the FIPS 140-2 Level 1 validation of

Crypto-C ME.

FIPS 140-2 (Federal Information Processing Standards Publication 140-2 - Security

Requirements for Cryptographic Modules) details the United States Government

requirements for cryptographic modules. For more information about the FIPS 140-2

standard and validation program, see the NIST website.

This document may be freely reproduced and distributed whole and intact including

the Copyright Notice.

Contents:

1 Introduction ................................................................................................... 2

1.1 References ......................................................................................... 2

1.2 Document Organization .................................................................... 2

2 Crypto-C ME Cryptographic Toolkit ........................................................... 3

2.1 Cryptographic Module ....................................................................... 3

2.2 Crypto-C ME Interfaces .................................................................. 12

2.3 Roles and Services ......................................................................... 14

2.4 Cryptographic Key Management ................................................... 15

2.5 Cryptographic Algorithms ............................................................... 18

2.6 Self Tests .......................................................................................... 20

3 Secure Operation of Crypto-C ME .......................................................... 22

3.1 Crypto Officer and Crypto User Guidance ................................... 22

3.2 Roles ................................................................................................. 23

3.3 Modes of Operation ......................................................................... 24

3.4 Operating Crypto-C ME .................................................................. 25

3.5 Startup Self-tests ............................................................................. 25

3.6 Pseudo-random Number Generator ............................................. 26

4 Services ...................................................................................................... 27

5 Acronyms and Definitions ......................................................................... 33

Summary of content (36 pages)

PAGE 1
Security Policy 09.10.14 RSA BSAFE® Crypto-C Micro Edition Version 4.1 Security Policy Level 1 This is a non-proprietary Security Policy for RSA BSAFE Crypto-C Micro Edition 4.1 (Crypto-C ME). It describes how Crypto-C ME meets the Level 1 security requirements of FIPS 140-2, the Level 3 security requirements of FIPS 140-2 for design assurance, and how to securely operate Crypto-C ME in a FIPS 140-2-compliant manner.
PAGE 2
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 1 Introduction The Crypto-C ME software development toolkit is designed to enable developers to incorporate cryptographic technologies into applications. Crypto-C ME security software helps to protect sensitive data as it is stored, using strong encryption techniques to ease integration with existing data models.
PAGE 3
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 2 Crypto-C ME Cryptographic Toolkit Crypto-C ME is designed with the ability to optimize code for different processors, and specific speed or size requirements. Assembly-level optimizations on key processors mean Crypto-C ME algorithms can be used at increased speeds on many platforms.
PAGE 4
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 The following table lists the certification levels sought for Crypto-C ME for each section of the FIPS 140-2 specification.
PAGE 5
RSA BSAFE Crypto-C Micro Edition 4.
PAGE 6
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 • Oracle®: – – • – • 6 SPARC® v8 (32-bit), built with Sun Studio 10, Sun C 5.8 • x86 (32-bit), built with Sun Studio 10, Sun C 5.8 • x86_64 (64-bit), built with Sun Studio 10, Sun C 5.8 Solaris 11: • SPARC v8+ (32-bit), built with Solaris Studio 12.3, Sun C 5.12 • SPARC v9-T2 (64-bit), built with Solaris Studio 12.3, Sun C 5.12 • SPARC v9-T4 (64-bit), built with Solaris Studio 12.3, Sun C 5.12 AIX® v6.
PAGE 7
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 • WindRiver®: – VxWorks 6.4 on PowerPC 604 (32-bit), built with gcc version 3.4.4 – VxWorks 6.7 on PowerPC 604 (32-bit), built with gcc version 4.1.2 2.1.2 Affirmation of Compliance for other Operating Environments Affirmation of compliance is defined in Section G.5, “Maintaining Validation Compliance of Software or Firmware Cryptographic Modules,” in Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program.
PAGE 8
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 • Novell: – – • • x86_64 (64-bit), built with LSB3.0 and gcc 3.4 • PowerPC (32-bit), built with gcc 3.4 • PowerPC (64-bit), built with gcc 3.4 SUSE Linux Enterprise Server 11 on Itanium (64-bit), built with LSB3.0 and gcc 3.4 – Ubuntu 12.04 LTS: • x86 (32-bit), built with LSB 3.0 and gcc 3.4 • x86_64 (64-bit), built with LSB3.0 and gcc 3.4 • x86_64 (64-bit), built with LSB4.0 and gcc 4.
PAGE 9
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 2.1.3 Configuring Single User Mode This section describes how to configure single user mode for the different operating system platforms supported by Crypto-C ME.
PAGE 10
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 HP-UX To configure single user mode for systems running an HP-UX operating system: 1. Log in as the root user. 2. Edit /etc/passwd and remove all the users except root and the pseudo-users. Make sure the password fields for the pseudo-users are a star (*). This prevents login as the pseudo-users. 3. Edit /etc/nsswitch.conf so files is the only option for passwd and group.
PAGE 11
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 Apple Mac OS X To configure single user mode for systems running an Apple Mac OS X operating system: 1. Start a terminal session. 2. Edit /etc/passwd and /etc/master.passwd to remove all the users except root and the pseudo-users (daemon users). Make sure the password fields in /etc/master.passwd for the pseudo-users are either a star (*) or double exclamation mark (!!). This prevents login as the pseudo-users. 3.
PAGE 12
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 2.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. The physical interfaces for Crypto-C ME consist of the keyboard, mouse, monitor, CD-ROM drive, floppy drive, serial ports, USB ports, COM ports, and network adapter(s).
PAGE 13
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 The underlying logical interface to Crypto-C ME is the API, documented in the RSA BSAFE Crypto-C Micro Edition API Reference 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. This is illustrated in the following diagram.
PAGE 14
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 2.3 Roles and Services Crypto-C ME meets all FIPS 140-2 Level 1 requirements for roles and services, implementing both a User (User) role and Crypto Officer (CO) role. As allowed by FIPS 140-2, Crypto-C ME does not support user identification or authentication for these roles. Only one role can be active at a time and Crypto-C ME does not allow concurrent operators. 2.3.
PAGE 15
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 2.4 Cryptographic Key Management Cryptographic key management is concerned with generating and storing keys, managing access to keys, protecting keys during use, and zeroizing keys when they are not longer required. 2.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.
PAGE 16
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 Table 2 Key Storage (continued) Key or CSP Storage HMAC DRBG entropy Volatile memory only (plaintext). HMAC DRBG V value Volatile memory only (plaintext). HMAC DRBG key Volatile memory only (plaintext). HMAC DRBG init_seed Volatile memory only (plaintext). FIPS 186-2 seed Volatile memory only (plaintext). FIPS 186-2 key Volatile memory only (plaintext). 2.4.
PAGE 17
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 Table 3 Key and CSP Access (continued) Service Type Key or CSP Type of Access Self-test (Crypto Officer service) Hardcoded keys (DSA and AES) Read/Execute Show status None N/A Zeroization All Read/Write 2.4.4 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.
PAGE 18
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 2.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. The following table lists the FIPS 140-2-approved and allowed algorithms supported by Crypto-C ME with validation certificate numbers.
PAGE 19
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 Table 4 Crypto-C ME FIPS 140-2-approved and allowed Algorithms (continued) Algorithm Type Algorithm Validation Certificate Key Wrapping RSA encrypt and decrypt (2048 to 4096-bit key size). For key wrapping using RSA, the key establishment methodology provides between 112 and 150 bits of encryption strength. Less than 112 bits of security (key sizes less than 2048 bits) is non-compliant.
PAGE 20
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 • Entropy RNG • OTP RNG. For more information about using Crypto-C ME in a FIPS 140-2-compliant manner, see “Secure Operation of Crypto-C ME” on page 22. 2.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.
PAGE 21
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 2.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 DSA, RSA, or EC 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.
PAGE 22
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 3 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. 3.1 Crypto Officer and Crypto User Guidance The Crypto Officer and Crypto User must only use algorithms approved for use in a FIPS 140 mode of operation, as listed in Table 4 on page 18.
PAGE 23
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 • When using GCM feedback mode for symmetric encryption, the authentication tag length and authenticated data length may be specified as input parameters, but the Initialization Vector (IV) must not be specified. It must be generated internally. • In the case where the module is powered down, a new key must be used for AES GCM encryption/decryption.
PAGE 24
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 3.3 Modes of Operation The following table lists and describes the available mode filters to determine the mode Crypto-C ME operates in and the algorithms allowed. Table 6 Crypto-C ME Mode Filters Mode Description R_MODE_FILTER_FIPS140 Implements FIPS 140-2 mode and provides the cryptographic algorithms listed in Table 4 on page 18. The default pseudo-random number generator (PRNG) is CTR DRBG. FIPS 140-2-approved.
PAGE 25
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 3.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 6 on page 24.
PAGE 26
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 3.6 Pseudo-random Number Generator In all modes of operation, Crypto-C ME provides the CTR DRBG as the default pseudo-random number generator (PRNG). Users can choose to use an approved PRNG other than the default, including HMAC DRBG or FIPS 186-2 (with or without mod q) when creating a cryptographic object and setting this object against the operation requiring random number generation (for example, key generation).
PAGE 27
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 4 Services The following is the list of services provided by Crypto-C ME. For more information about individual functions, see the RSA BSAFE Crypto-C Micro Edition API Reference Guide.
PAGE 28
RSA BSAFE Crypto-C Micro Edition 4.
PAGE 29
RSA BSAFE Crypto-C Micro Edition 4.
PAGE 30
RSA BSAFE Crypto-C Micro Edition 4.
PAGE 31
RSA BSAFE Crypto-C Micro Edition 4.
PAGE 32
RSA BSAFE Crypto-C Micro Edition 4.
PAGE 33
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 5 Acronyms and Definitions The following table lists and describes the acronyms and definitions used throughout this document. Table 7 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. API Application Programming Interface. BPS Brier, Peyrin and Stern.
PAGE 34
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 Table 7 Acronyms and Definitions Term Definition DSA Digital Signature Algorithm. An asymmetric algorithm for creating digital signatures. DRBG Deterministic Random Bit Generator. Dual EC DRBG Dual Elliptic Curve Deterministic Random Bit Generator. EC Elliptic Curve. ECAES Elliptic Curve Asymmetric Encryption Scheme. ECB Electronic Codebook. A mode of encryption, which divides a message into blocks and encrypts each block separately.
PAGE 35
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 Table 7 Acronyms and Definitions Term Definition MD2 A message digest algorithm, which hashes an arbitrary-length input into a 16-byte digest. MD2 is no longer considered secure. MD4 A message digest algorithm, which hashes an arbitrary-length input into a 16-byte digest. MD5 A message digest algorithm, which hashes an arbitrary-length input into a 16-byte digest. Designed as a replacement for MD4.
PAGE 36
RSA BSAFE Crypto-C Micro Edition 4.1 Security Policy Level 1 Table 7 Acronyms and Definitions Term Definition SEED SEED symmetric key encryption algorithm developed by the Korean Information Security Agency. SHA Secure Hash Algorithm. An algorithm, which creates a unique 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.