BeCrypt Ltd. BeCrypt Cryptographic Library v 1.0 FIPS 140-2 Non-Proprietary Security Policy Level 1 Validation September 2008 © 2008 BeCrypt Ltd. All rights reserved. www.becrypt.com This document may be freely reproduced and distributed whole and intact including this copyright notice. Table of Contents 1.1 Purpose ..................................................................................................................... 3 1.2 References ................................................................................................................ 3 1.3 Document History ...................................................................................................... 3 2 PRODUCT DESCRIPTION .......................................................................................... 4 2.1 High Level Block Diagram ......................................................................................... 5 2.2 Finite State Machine.................................................................................................. 6 3 MODULE PORTS AND INTERFACES ........................................................................ 6 4 ROLES, SERVICES AND AUTHENTICATION ............................................................ 7 4.1 Identification and Authentication ............................................................................... 7 4.2 Roles and Services ................................................................................................... 7 5 PHYSICAL SECURITY ................................................................................................ 9 6 CRYPTOGRAPHIC KEY MANAGEMENT ................................................................... 9 7 SELF-TEST ................................................................................................................ 10 8 Crypto-Officer and User Guidance ............................................................................. 11 8.1 Secure Setup and Initialization ................................................................................ 11 8.2 Module Security Policy Rules .................................................................................. 11 Non-Proprietary Security Policy 2 BeCrypt Ltd. v1.0 1 INTRODUCTION 1.1 Purpose This is a non-proprietary FIPS 140-2 Security Policy for the "BeCrypt Cryptographic Library v1.0" cryptographic module. It describes how this module meets all the requirements as specified in the FIPS 140-2 Level 1 requirements. This Policy forms a part of the submission package to the validating lab. FIPS 140-2 (Federal Information Processing Standards Publication 140-2) specifies the security requirements for a cryptographic module protecting sensitive information. Based on four security levels for cryptographic modules this standard identifies requirements in eleven sections. For more information about the standard please visit csrc.nist.gov/groups/STM/cmvp/index.html. 1.2 References This Security Policy describes how this module complies with the eleven sections of the Standard: · For more information on the FIPS 140-2 standard and validation program please refer to the NIST website at csrc.nist.gov/groups/STM/cmvp/index.html. · For more information about BeCrypt Ltd. please visit www.becrypt.com. 1.3 Document History Authors Date Version Comment PS 21/2/08 0a1 First draft PS 23/5/08 01 Issued PS 12/6/08 01 Re-issued after minor amendments PS 10/9/08 02 Re-issued after review comments PS 12/9/08 02 Minor correction Non-Proprietary Security Policy 3 BeCrypt Ltd. v1.0 2 PRODUCT DESCRIPTION BeCrypt Cryptographic Library provides core cryptographic functionality for software applications. It supports AES (ECB), RSA (sign/verify), SHA256, Random Number Generation (ANSI X9.31) and HMACSHA256 algorithms in the approved mode and AES (CBC and OFB) and RSA (Encrypt/Decrypt and Key Generation) in the non-approved mode. The cryptographic module is comprised of two sub components, viz., a 16-bit sub component object that is designed to operate in a pre-OS or DOS environment and a 32-bit sub component object designed to operate in 32-bit operating environments. It is implemented as a set of cryptographic primitives that dependent upon the underlying platform CPU hardware to provide processing and memory storage services. The module is a multi-chip standalone cryptographic module consisting of software that executes on a general-purpose Intel® X86 General PC computing platform with an Intel® CoreTM 2 CPU, configured in single-user mode. The module was tested on Windows XP Professional SP2 and Linux Ubuntu 8.04. In this document, the BeCrypt Cryptographic Library is also referred to as "the module". The product meets the overall requirements applicable to Level 1 security for FIPS 140-2. Security Requirements Section Level Cryptographic Module Specification 1 Cryptographic Module Ports and Interfaces 1 Roles and Services and Authentication 1 Finite State Machine 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 Cryptographic Module Security Policy 1 Overall Level of Validation 1 Table 1 Module Compliance Table EMI/EMC properties of the BeCrypt Cryptographic Library are not meaningful for the library itself. Systems utilizing the BeCrypt Cryptographic Library services have their overall EMI/EMC ratings determined by the host system. The validation environment used for Functional Testing had FCC Class B ratings. Non-Proprietary Security Policy 4 BeCrypt Ltd. v1.0 2.1 High Level Block Diagram Figure 1 shows a block diagram of the cryptographic module that illustrates the physical boundary of the module and shows the module physical interfaces. The physical cryptographic boundary is the physical boundary of the PC case. Figure 1. High Level Block Diagram Showing Physical Boundaries Figure 2 shows a logical block diagram of the cryptographic module illustrating the components related to, and included within, the cryptographic boundary of the module. The 16 and 32-bit subcomponent objects are illustrated as logical components of a user application. The cryptographic boundary includes all application files as listed below: · fipslib ­ 32-bit cryptographic object · becrypt ­ 16-bit cryptographic object Figure 2. High Level Block Diagram Showing Logical Cryptographic Boundaries. Non-Proprietary Security Policy 5 BeCrypt Ltd. v1.0 The application boundary is defined as the boundary of the user application that incorporates the 16-bit and 32-bit sub component objects. 2.2 Finite State Machine The `Finite State Machine Mode' description is located in the Vendor Evidence (VE) document. 3 MODULE PORTS AND INTERFACES The physical ports map to logical interfaces as described in Table 2. All parameters passed to the mmodule routines are through Data Input interfaces. These interfaces accept keying material for processing that is stored by the User application in a local database. All control flags passed to the module routines are through Control Input interfaces. All parameters returned by the module routines are through Data Output interfaces. These interfaces pass ciphertext keying material and data. All error codes returned by the module routines are through Status Output interfaces. The table below maps elements of the API to the four required components of the logical interface. FIPS 140-2 Interface Logical Interface Physical Port Data Input API functions that accept input PC USB port, PCMCIA port, data arguments network port, Keyboard port, Mouse port, optical drive, floppy drive Data Output API functions that produce PC USB port, PCMCIA port, output in arguments network port, optical drive, floppy drive Control Input API functions to initialize and Mouse port, Keyboard port, PC shutdown the module and to Power Button run self tests Status Output API functions return values PC monitor which return information regarding module status Power N/A Supplied by device Table 2 ­ Mapping Physical Ports and Logical Interfaces The logical interfaces are described further in Table 3. Logical Non-Proprietary Security Policy 6 BeCrypt Ltd. v1.0 Logical Interface Description Data input interfaces The data input is all plaintext data entering the API functions for the purpose of being processed by the modules services. Data output interfaces The data output is all plaintext data exiting the API functions after being processed by the modules services. Control input interfaces The control input interface is used to configure the module. This is implemented by the API functions for key generation and module initialization. Status output interface The status output consists of all messages either logged by the module or returned by the API functions. Table 3. Logical Interfaces 4 ROLES, SERVICES AND AUTHENTICATION The module supports a crypto officer (CO) role and a user role. The crypto officer and user may be different operators or they may be the same operator performing role-specific module operations. Both the crypto officer and user roles are implicitly assumed. The crypto officer role is implicitly assumed by the operator configuring the module for use at installation time. Crypto officer operations consist of configuring the PC in single user mode and installing and building applications that use the cryptographic module. 4.1 Identification and Authentication Multiple concurrent operators are not allowed as the module is restricted to single user mode. Operators may change roles while operating the module. Access to the authorized roles is not restricted as explained in Table 4. Role Type of Authentication Authentication Data Crypto Officer None None User None None Table 4. Roles and Required Identification and Authentication 4.2 Roles and Services The Product Name supports the services listed in the following table. The table groups the authorized services by the operator roles and identifies the Cryptographic Keys and CSPs associated with the services. The modes of access are also identified per the explanation. R - The item is read or referenced by the service. W - The item is written or updated by the service. E - The item is executed by the service. (The item is used as part of a cryptographic function.) Tables 5 and 6 below show the services available to each role. Table 7 shows non-authorized services. Non-Proprietary Security Policy 7 BeCrypt Ltd. v1.0 Role Authorized Services Cryptographic Keys and CSPs Access Type 32-bit sub component CO Key Generation Seed and Seed Key R,W CO AES Encrypt / Decrypt AES data encryption key R,E CO RSA Sign / Verify RSA private and public key R,E CO SHA-256 Hash None N/A CO Show Status None N/A CO Perform Self Tests AES data encryption key R,E HMAC integrity check key R,E RSA public and private key R,E PRNG seed and seed key R,E CO Initialization None N/A CO Uninstall None N/A 16-bit sub component CO Import Key AES data encryption key R,E CO AES Encrypt / Decrypt AES data encryption key R,E CO SHA-256 Hash None N/A CO Show Status None N/A CO Perform Self Tests AES data encryption key R,E HMAC integrity check key R,E Table 5. Cryptographic Officer ­ Roles and Services Role Authorized Services Cryptographic Keys and CSPs Access Type 32-bit sub component User AES Encrypt / Decrypt AES data encryption key R,E User RSA Sign / Verify RSA private and public key R,E User SHA-256 Hash None N/A User Show Status None N/A User Perform Self Tests AES data encryption key R,E HMAC integrity check key R,E RSA public and private key R,E PRNG seed and seed key R,E 16-bit sub component User AES Encrypt / Decrypt AES data encryption key R,E User SHA-256 Hash None N/A User Show Status None N/A User Perform Self Tests AES data encryption key R,E HMAC integrity check key R,E Table 6. User ­ Roles and Services Non-Proprietary Security Policy 8 BeCrypt Ltd. v1.0 Role Non-authorized Services Cryptographic Keys and CSPs Access Type 32-bit sub component User, RSA Encrypt / Decrypt N/A N/A CO User, RSA Key Generation N/A N/A CO User, AES Encrypt / Decrypt in CBC N/A N/A CO and OFB modes Table 7. CO and User ­ Non-Authorised Roles and Services 5 PHYSICAL SECURITY This section is not applicable as this is a software module. 6 CRYPTOGRAPHIC KEY MANAGEMENT The following table identifies the Cryptographic Keys and Critical Security Parameters (CSPs) employed within the module. Key Generation Storage Use Role 32-bit sub component Data Encryption Generated internally using a Key not Encryption Key used to User Key PRNG compliant to ANSI X9.31. stored encrypt data CO AES PRNG seed Generated externally drawn from an Key not Used to generate User entropy pool. stored random numbers during CO disk key creation in FIPS mode. PRNG seed key Pre-loaded during the manufacturing Compiled Used to generate User process. in the random numbers during CO binary disk key creation in FIPS mode. Integrity Check Pre-loaded during the manufacturing Compiled Private key for approved User Key process in the integrity technique for CO HMACSHA256 binary checking the integrity of cryptographic module binaries. 16-bit sub component Data Encryption Generated internally using a Key not Encryption Key used to User Key PRNG compliant to ANSI X9.31. stored encrypt data CO AES Integrity Check Pre-loaded during the Compiled Private key for approved User Key manufacturing process in the integrity technique for CO HMACSHA256 binary checking the integrity of cryptographic module binaries. Table 8. Cryptographic keys and CSPs Non-Proprietary Security Policy 9 BeCrypt Ltd. v1.0 The module keys map to the following algorithms certificates: Approved Security Function Certificate 32-bit implementation Symmetric Key Encryption AES #765 ECB (FIPS PUB 197) : 128, 256 HASHING SHA-256 byte-oriented #772 HMAC-SHA-256 #419 Asymmetric Keys RSA #363 ANSI X9.31 (Sig Gen and Sig Ver) : 1024, 2048 Random Number Generation (ANSI X9.31) #440 16-bit implementation Symmetric Key Encryption AES #764 ECB (FIPS PUB 197) : 128, 256 HASHING SHA-256 byte-oriented #771 HMAC-SHA-256 #418 Non-Approved Security Function 32-bit implementation AES OFB and CBC modes N/A RSA Encrypt and Decrypt N/A RSA Key Generation N/A Table 9. FIPS Approved Algorithms Table Please Note: · Only FIPS Approved algorithms must be called when operating in FIPS mode. · RNGCreateKey() is the only function implemented by the module that can be used for random number generation in FIPS approved mode. · All keys generated by the approved Random Number Generation algorithm must be outputted from the module in encrypted format using AES in ECB mode. 7 SELF-TEST The cryptographic module will perform the following power up tests that can be either initiated by re- starting the cryptographic module, or initiated on demand by calling the appropriate API initialization function as described in section 8.1. 1. Known answer tests for cryptographic algorithms 2. Software Integrity (using an Approved Algorithm) tests on all components in the cryptographic boundary Non-Proprietary Security Policy 10 BeCrypt Ltd. v1.0 Cryptographic Algorithm KATs: The module will perform Known Answer Tests (KAT) on the cryptographic algorithms implemented. The known answer tests will be performed before the algorithms are utilized. Known Answer Tests (KATs) are run at power-up for: · 16-bit sub component : AES KAT encryption and decryption (ECB mode), SHA256 KAT · 32-bit sub component : AES KAT encryption and decryption (ECB mode), RSA signature generation and verification KAT, HMAC KAT, RNG KAT, SHA256 is tested as part of the HMAC software integrity test on the module Conditional RNG Test: The test is run each time an Approved RNG generates a random number. The test involves comparing the generated value with the previously generated value. The following conditional test is carried out: · 32-bit sub component : RNG test failure to a constant value Software/Firmware Integrity Tests: The module checks the integrity of its various components (16-bit sub component binaries and 32-bit sub component binaries) using HMAC-SHA-256. The software/firmware integrity tests are completed individually over the 16-bit and 32-bit sub-components. i.e., each sub component implements its own integrity test. 8 Crypto-Officer and User Guidance This section describes the configuration, maintenance, and administration of the cryptographic module. 8.1 Secure Setup and Initialization The module must be validated and initialized by successful completion of all self tests as documented in section 7 above. The self tests must be performed as part of the module initialization and can also be performed on demand by either COs or Users. The steps to securely initialize the module are as follows: · install the module on the target platform · initialize the module using fipsSelfTests(). Operators must confirm that the status returned is `0x0' and there are no errors reported. · after successful initialization, users may operate the module and access the cryptographic services implemented by the module. 8.2 Module Security Policy Rules COs must observe the following practice: · when performing key generation services, COs are required to use a data source with high entropy for generating the seed value to be provided to the Approved RNG algorithm. · the module is operating in FIPS mode when using AES in ECB mode. · keys that are entered or output from the cryptographic boundary must be done in encrypted form using AES in ECB mode. Non-Proprietary Security Policy 11 BeCrypt Ltd. v1.0