Dell-CREDANT Cryptographic Kernel Windows Kernel Mode version 1.8 Windows User Mode version 1.8 FIPS 140-2 Non-Proprietary Security Policy Security Level 2 Validation Revision Date: May 05, 2014 Information in this document is subject to change without notice. © 2014 Dell Inc. All rights reserved. Reproduction of this document is allowed provided the document is copied in its entirety without modification. Trademarks used in this text: Dell™, the Dell logo, and OptiPlex™ are trademarks of Dell Inc. Intel is a trademark of Intel Corporation in the U.S. and/or other countries. Protected by one or more U.S. Patents, including: Number 7665125; Number 7437752; and Number 7665118. Table of Contents 1 Introduction ........................................................................................................................................................ 4 1.1 Dell Data Protection | Encryption............................................................................................................. 4 2 Product, Boundary, Module Definition .............................................................................................................. 5 3 Approved and Non-Approved Modes ................................................................................................................. 8 4 Roles, Services, Policy........................................................................................................................................ 9 4.1 Roles Related Notes ............................................................................................................................... 14 4.2 Services Related Notes ........................................................................................................................... 14 4.3 Authentication Related Notes ................................................................................................................. 15 5 Finite State Model............................................................................................................................................. 15 6 Key Management .............................................................................................................................................. 16 7 Random Number Generation ............................................................................................................................ 17 7.1 RNG Seeding ......................................................................................................................................... 17 7.2 RNG Tests .............................................................................................................................................. 18 8 Module Interface ............................................................................................................................................... 18 9 Self-Tests .......................................................................................................................................................... 18 10 Secure Delivery, Installation, and Operation .................................................................................................... 20 List of Figures Figure I Windows User Mode Physical and Logical Cryptographic Boundaries ..................................................5 Figure II Windows Kernel Mode Physical and Logical Cryptographic Boundaries ...............................................6 2 Dell Inc. List of Tables Table A Security Level Achieved in Each Security Category ...............................................................................7 Table B Explicit Mapping of the Module Versions, CCK File Names, and Tested Platforms ..............................7 Table C Service Type Offered by Algorithm, FIPS Specification, and Availability .............................................9 Table D Access to Critical Security Parameters (CSP) for Each Service and Role ............................................. 10 Table E Inputs and Outputs of Each Service Provided by the CCK .................................................................... 13 Table F Authentication Strength ......................................................................................................................... 15 Table G States of the Finite State Model ............................................................................................................. 15 Table H RNGs Implemented Within the CCK .................................................................................................... 17 Table I Logical Interface Components, API Components, Physical Ports ......................................................... 18 3 Dell Inc. 1 Introduction Dell Data Protection | Encryption offers simple, comprehensive and flexible data security for the entire organization. 1.1 Dell Data Protection | Encryption As organizations grapple with securing endpoint devices, consumerization, globalization and workforce mobility are creating new challenges. Meanwhile, all you have to do is look at the headlines to see that threats are more coordinated and coming faster. Dell helps businesses through these challenges by enabling an easier path to data protection, compliance, and business continuity. Dell Data Protection | Encryption (DDP|E) provides organizations with the confidence that their user’s data is secure, with a solution designed for simple, comprehensive, and flexible protection. It is a policy-based solution that protects data stored on the system drive and/or external media. Designed for easy deployment, end-user transparency, and hassle-free compliance, the DDP|E portfolio of products delivers a high level of protection, fills critical security gaps and enables organizations to manage encryption policies for multiple endpoints and operating systems—all from a single management console. The Dell-CREDANT Cryptographic Kernel (CCK) is the library of cryptographic functions used by the DDP|E suite of enhanced security solutions. The CCK takes the form of a (dynamically linked) software library, which provides an API to cryptographic functions, including AES (with ECB, CBC, CTR, CCM, and XTS modes), Triple-DES (with ECB and CBC modes), SHA-1, SHA-256, SHA-384, SHA-512, HMAC-SHA-1, HMAC-SHA-256, HMAC- SHA-384, HMAC-SHA-512, and DRBG 800-90 compliant pseudorandom number generator. The suite is comprised of a Dell Server (Dell Data Protection Enterprise Server or Dell Data Protection Enterprise Server – Virtual Edition), Dell Policy Proxy, and Encryption components. These three components work together to ensure the security of data. The Encryption component installs on the endpoint computer and protects its data from unauthorized access. The Dell Policy Proxy receives key material and policy information from the Dell Server and communicates it to the DDP|E-protected computer. An administrator sets policies via the Dell Server using a management console, and the Dell Server forwards these policies to the instances of the Dell Policy Proxy. When a DDP|E-protected computer polls the Dell Server through the Dell Policy Proxy, it receives policy updates. Note: In this latest version, CCK has been renamed and is now known as CmgCryptoLib. As such, all references in this or any other document to CCK, Dell-CREDANT Cryptographic Module, or CREDANT Cryptographic Module should be understood to be synonymous with CmgCryptoLib. 4 Dell Inc. 2 Product, Boundary, Module Definition The CCK library and header file constitute the cryptographic software module for this FIPS 140-2 validation. The logical boundary contains the software modules that comprise the CCK library. The physical boundary for the module is defined as the enclosure of the computer system on which the functions of the library execute. Figure I Windows User Mode Physical and Logical Cryptographic Boundaries 5 Dell Inc. Figure II Windows Kernel Mode Physical and Logical Cryptographic Boundaries The module constitutes a multi-chip stand-alone device (listed below), as defined by the FIPS 140-2 standard. The Dell-CREDANT Cryptographic Kernel runs in compliance with the requirements for FIPS 140-2 Level 2 security on the following CCEVS approved configurations:  Microsoft Windows 7 Enterprise; on a Dell  Microsoft Windows 7 Enterprise x64 Edition; on a OptiPlex™755 Workstation (http://www.niap- Dell OptiPlex™755 Workstation (http://www.niap- ccevs.org/st/vid10390/) ccevs.org/st/vid10390/) The module also runs on the following platforms not included in this validation:  Microsoft Windows XP (32- and 64-bit)  Microsoft Windows Vista (32- and 64-bit) The CMVP makes no statement as to the correct operation of the module or the security strengths of the generated keys when so ported if the specific operational environment is not listed on the validation certificate. 6 Dell Inc. The cryptographic module achieves an overall security level 2, with the individual level according to each security requirement shown in the table below. Table A Security Level Achieved in Each Security Category Security Category Level Cryptographic Module Specification 2 Cryptographic Module Ports and Interfaces 2 Roles, Services, and Authentication 2 Finite State Model 2 Physical Security N/A Operational Environment 2 Cryptographic Key Management 2 EMI\EMC 3 Self-Tests 2 Design Assurance 3 Mitigation of Other Attacks N/A The CCK consists of the following files:  CmgCryptoLib.dll – The Dynamic Link Library  CmgCrypt.sys – The system driver library containing containing the CCK’s cryptographic functionality for the CCK’s cryptographic functionality for Windows Windows User mode. Kernel mode.  CmgCryptoLib.mac – The file used to support the  CmgCrypt.mac – The file used to support the software integrity test of the file CmgCryptoLib.dll for software integrity test of the file CmgCrypt.sys for Windows User mode. Windows Kernel mode. The following table provides an explicit mapping of the module versions, CCK file names, and tested platforms. Table B Explicit Mapping of the Module Versions, CCK File Names, and Tested Platforms Module Version CCK Files Tested Platforms Windows Kernel Mode CmgCrypt.sys Microsoft Windows 7 Enterprise (32- Version 1.8 (32-bit) CmgCrypt.mac bit); on a Dell OptiPlex 755 Workstation Windows Kernel Mode CmgCrypt.sys Microsoft Windows 7 Enterprise x64 Version 1.8 (64-bit) CmgCrypt.mac Edition (64-bit); on a Dell OptiPlex 755 Workstation Windows User Mode CmgCryptoLib.dll Microsoft Windows 7 Enterprise (32- Version 1.8 (32-bit) CmgCryptoLib.mac bit); on a Dell OptiPlex 755 Workstation Windows User Mode CmgCryptoLib.dll Microsoft Windows 7 Enterprise x64 Version 1.8 (64-bit) CmgCryptoLib.mac Edition (64-bit); on a Dell OptiPlex 755 Workstation 7 Dell Inc. 3 Approved and Non-Approved Modes The CCK library is capable of operating in both FIPS approved and FIPS non-approved modes. Non-approved mode generally contains the same functionality as approved mode, with the addition of extra non-approved functionality. Differences between approved and non-approved mode are noted where appropriate throughout this Security Policy. Statements about CCK are, in general, intended to apply to both modes unless otherwise noted. The mode that the library will operate in is determined at initialization time via a parameter specified by the user. The default value, should the user not explicitly specify the mode, is approved mode. To choose the mode of operation, the CCK user creates a structure of variables used for CCK initialization. One of these variables is named “fips_mode” and can be set to the values “FIPS_MODE” or “NON_FIPS_MODE”. They may optionally call a CCK API to initialize the structure, which will set “fips_mode” to “FIPS_MODE”. The user can manually set the value of “fips_mode” as desired. This structure is then provided as an argument to “CCK_initialize” and the value of “fips_mode” dictates the mode the CCK is in and is stored in a similar variable within the CCK session for the lifetime of that session. A Crypto User or Crypto Officer may check the FIPS approved verses non-approved state of the CCK session at any time. The API “CCK_fips_mode” returns the values “FIPS_MODE” or “NON_FIPS_MODE” as the state of the session. There is no internal functionality to facilitate changing the mode between approved and non-approved modes, so a CCK session handle may only operate in one of those modes over its lifetime. No session data from an approved mode session is shared with a session in non-approved mode. Version 7.0 of the third-party Intel® Integrated Performance Primitives (Intel® IPP) library is statically linked with the CmgCryptoLib library to accelerate certain cryptographic algorithms. This library is not FIPS certified and only utilized when CmgCryptoLib is in a non-approved mode. When it is in FIPS approved mode, no code from the IPP library is permitted to execute. 8 Dell Inc. 4 Roles, Services, Policy Table C Service Type Offered by Algorithm, FIPS Specification, and Availability Service Type Algorithm FIPS Standard Library FIPS Algorithm Available in Certificate Roles Number Self-Tests AES, AES CCM, N/A N/A N/A Crypto Officer, Crypto User1 Triple-DES, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512, SHA-1, SHA-256, SHA-384, SHA- 512, DRBG 800- 90 Key Zeroization N/A N/A N/A N/A Crypto Officer, Crypto User2 Symmetric Cipher AES (CTR, CCM, 197 User Mode #2131 Crypto Officer, CBC, ECB, XTS) Crypto User Kernel Mode #2130 Symmetric Cipher Triple-DES (ECB, 46-3 User Mode #1354 Crypto Officer, CBC) Crypto User Kernel Mode #1353 Message HMAC-SHA-1, 198 User Mode #1301 Crypto Officer, Authentication HMAC-SHA-256, Crypto User HMAC-SHA-384, Kernel Mode #1300 HMAC-SHA-512 Message Digest SHA-1 180-1 User Mode #1855 Crypto Officer, Crypto User Kernel Mode #1854 Message Digest SHA-256, SHA- 180-2 User Mode #1855 Crypto Officer, 384, SHA-512 Crypto User Kernel Mode #1854 Random Number DRBG 800-90 186-2 User Mode #236 Crypto Officer, Generation Crypto User Kernel Mode #235 When CCK is in non-approved mode, the following also apply: Symmetric Cipher Rijndael (32 byte 197 User Mode N/A Crypto Officer, block size) with Crypto User and without IPP Kernel Mode (CBC, ECB) Symmetric Cipher AES with IPP 197 User Mode N/A Crypto Officer, (CTR, CCM, Crypto User Kernel Mode CBC, ECB, XTS) Crypto User has access to a portion of this service’s functionality (see Section 4.1). 1 Crypto User has access to a portion of this service’s functionality (see Section 4.1). 2 9 Dell Inc. Service Type Algorithm FIPS Standard Library FIPS Algorithm Available in Certificate Roles Number Symmetric Cipher Triple-DES with 46-3 User Mode N/A Crypto Officer, IPP (ECB, CBC) Crypto User Kernel Mode Message Digest SHA-256, SHA- 180-2 User Mode N/A Crypto Officer, 384, SHA-512 Crypto User Kernel Mode with IPP Random Number ANSI X9.31 186-2 User Mode N/A Crypto Officer, Generation Crypto User Kernel Mode A summary CCK of services by role and the access granted to critical security parameters of these services for each role is shown in Table D. Note: The CCK file “CCK_api.h” enumerates the CCK APIs in this table along with the parameters passed to each. Consult the publication NIST SP 800-131A for details on recommendation for transitioning the use of cryptographic algorithms and key lengths. Table D Access to Critical Security Parameters (CSP) for Each Service and Role Service Access (Role) Accessible Type of CCK CSP Access API(s) Installation Crypto Officer* None Execute --None-- Initialization Crypto Officer, Initializes all state Execute, Read, CCK_initialize Crypto User information for all keys to Write zero, Read access for AES key used to decrypt the HMAC integrity key and value, Read access for the encrypted HMAC integrity key and value, Read and write access for the decrypted HMAC integrity key and value Termination Crypto Officer, Last Triple-DES key used, Execute, Write CCK_terminate Crypto User Last AES key used, DRBG entropy seed (read and write access), DRBG “Key” and “V” state data (read and write access), RNG seed (read and write access) 10 Dell Inc. Service Access (Role) Accessible Type of CCK CSP Access API(s) Key Zeroization Crypto Officer, Last Triple-DES key used, Execute, Write CCK_reset_encryption_decryp Crypto User3 Last AES key used, tion_algorithm_state_info, HMAC key pair used in a CCK_clear_AES_keys, given HMAC context CCK_clear_DES3_keys, CCK_HMAC_truncated_final _internal, CCK_HMAC_SHA2_final_an d_report_internal Run Self Tests Crypto Officer, None Execute CCK_self_tests, Crypto User4 CCK_conditional_test, CCK_set_error_state, Show Status Crypto Officer, None Execute CCK_fips_mode, Crypto User CCK_status, CCK_test_status, CCK_role_auth_status AES Crypto Officer, Read access to keys Execute CCK_set_AES_block_ Crypto User passed as pointer size_and_key, parameters to constant CCK_set_AES_XTS_ structures, write access to secondary_key, cache the AES key CCK_AES_encrypt, CCK_AES_decrypt, CCK_AES_CBC_encrypt, CCK_AES_CBC_decrypt, CCK_AES_CTR_encrypt, CCK_AES_CTR_decrypt, CCK_AES_XTS_encrypt, CCK_AES_XTS_decrypt, CCK_AES_CCM_encrypt, CCK_AES_CCM_decrypt Triple-DES Crypto Officer, Read access to keys Execute, Read, CCK_DES3_encrypt, Crypto User passed as pointer Write CCK_DES3_decrypt, parameters to constant CCK_DES3_CBC_encrypt, structures; write access to CCK_DES3_CBC_decrypt cache the Triple-DES key HMAC-SHA-1 Crypto Officer, Read access to keys Execute, Read, CCK_HMAC_init, Crypto User passed as pointer Write CCK_HMAC_destroy, parameters to constant CCK_HMAC_restart, structures; store the CCK_HMAC_update, HMAC key for use in the CCK_HMAC_truncated_final HMAC operation Crypto User has access to a portion of this service’s functionality (see Section 4.1). 3 Crypto User has access to a portion of this service’s functionality (see Section 4.1). 4 11 Dell Inc. Service Access (Role) Accessible Type of CCK CSP Access API(s) HMAC-SHA-256, Crypto Officer, Read access to keys Execute, Read, CCK_HMAC_SHA2_init, HMAC-SHA-384, Crypto User passed as pointer Write CCK_HMAC_SHA2_destroy, HMAC-SHA-512 parameters to constant CCK_HMAC_SHA2_restart, structures; store the CCK_HMAC_SHA2_update, HMAC key for use in the CCK_HMAC_SHA2_final_an HMAC operation d_report SHA-1 Crypto Officer, None Execute, CCK_SHA1_reset, Crypto User Read, CCK_SHA1_get_hash, Write CCK_SHA1_update, CCK_SHA1_truncate_and_rep ort, CCK_SHA1_final_and_report, CCK_SHA1_final SHA-256, Crypto Officer, None Execute CCK_SHA2_reset, SHA-384, Crypto User CCK_SHA2_update, SHA-512 CCK_SHA2_final_and_report DRBG Crypto Officer, Read access to the DRBG Execute, Read, CCK_DRBG_generate_bytes, Crypto User input seed, Write CCK_DRBG_reseed_state, Read and write access to CCK_DRBG_check_alive the DRBG “Key” and “V” CCK_DRBG_reinstantiate, state data, CCK_perform_DRBG_test Read and write access to the RNG seed The following only apply when CCK is in non-approved mode: RNG Crypto Officer, RNG seed, Execute, Read, CCK_X931RNG_generate_ Crypto User RNG seed key Write Byte 12 Dell Inc. Note: Installation differs from initialization in that installation does not involve execution of CCK services. Initialization must occur after installation is invoked by the CCK client, and results in execution of several CCK services in the process of creating memory and starting services necessary to support subsequent CCK operation. The inputs and outputs of each service are shown in Table E. The methods of the cryptographic software module are designed to be invoked by a single process per session handle. Table E Inputs and Outputs of Each Service Provided by the CCK Service Input/Output Installation Input: Installation Software Package Output: Installed CCK software Initialization Input: Installed CCK software Output: Initialized CCK software (and client application) Termination Input: Initialized CCK software Output: Uninitialized CCK software Run Self Tests Input: None Output: Self-test status Show Status Input: None Output: Module status indicator AES encryption Input: Plaintext, key, IV in CBC mode (ECB and CBC modes) Output: Ciphertext AES CTR Encryption Input: Plaintext, key, counter_block, number of bytes to increment Output: Ciphertext AES XTS Encryption Input: Plaintext, key, sector block size, sector number Output: Ciphertext AES CCM Encryption Input: Plaintext, key, associated data and length, nonce and length, mac length Output: Ciphertext, mac AES Decryption Input: Ciphertext, key, IV in CBC mode (ECB and CBC modes) Output: Plaintext AES CTR Decryption Input: Ciphertext, key, counter_block, number of bytes to increment Output: Plaintext AES XTS Decryption Input: Ciphertext, key, sector block size, sector number Output: Plaintext AES CCM Decryption Input: Ciphertext, key, associated data and length, nonce and length, mac block and length Output: Plaintext (if mac is valid) Triple-DES encryption Input: Plaintext, key, IV in CBC mode (ECB and CBC modes) Output: Ciphertext Triple-DES decryption Input: Ciphertext, key, IV in CBC mode (ECB and CBC modes) Output: Plaintext HMAC-SHA-1 Input: A sequence of bytes, key Output: Authentication Code HMAC-SHA-256 Input: A sequence of bytes, key HMAC-SHA-384 Output: Authentication Code 13 Dell Inc. Service Input/Output HMAC-SHA-512 SHA-1 Input: A sequence of bytes Output: Hash value SHA-256 Input: A sequence of bytes, hash length SHA-384 Output: Hash value SHA-512 DRBG Input: --Optional-- additional seed bytes Output: A sequence of random bytes When CCK is in non-approved mode, the following also apply: RNG Input: Date/time (D/T) and seed (V) Output: A random byte 4.1 Roles Related Notes The CCK supports both Crypto Officer (CO) and Crypto User roles for an operator, where an “operator” is the application using CCK services to perform encryption, decryption, hashing, and random number generation. The Crypto User has limited access to some of the services. The role can perform self-tests, but only implicitly as a result of the initialization (since initialization includes the self-test check). The Crypto User can perform key zeroization only on HMAC keys they provide. The module does not support a maintenance role or a bypass capability. 4.2 Services Related Notes The implementation of the counter used in the AES CTR implementation is a simple counter incremented by one (1), the first value of which is established by an operator-supplied initial value (a nonce). The size of the counter is 16 bytes, creating a space of 2^128, satisfying the requirement that a repeat will not occur for a long time. A stream of plain text or cipher text submitted to the AES CTR algorithm for encryption or decryption, respectively, would have to be greater than 2^128 16 byte blocks in length to trigger a repeat in the counter value. An improved seeding source has been implemented for the purpose of providing random bytes in support of DRBG 800-90 algorithm initialization and is based on entropy from a combination of sources, each contributing in proportion to the strength of its entropy; that is, more if stronger (e.g., Microsoft API “CryptGenRandom”) and less if weaker (e.g., system time). An audit logging facility has been implemented for the purpose of reporting accesses to Crypto Officer functions, attempts to access Crypto Officer functions by Crypto Users, and accesses to any functions by non-authenticated operators. Events written by the CCK running at the user level are written into the Windows Application log and may be identified as having originated from source “CmgCryptoLib_Audit”. Events written by the CCK running at the kernel level are written into the Windows System log and may be identified as having originated from source “CmgCryptoLibProxy”. The Windows Event Viewer may be used to inspect events written into the Windows Application and System logs. 14 Dell Inc. 4.3 Authentication Related Notes The CCK module uses role-based authentication, relying on the operating system for authentication prior to use of the module and assumption of the Crypto Officer or Crypto User role. If the operator (the software application running under the logged-in operator account) is an authenticated administrator on the host operating system, the operator assumes the role of Crypto Officer. All other authenticated operators assume the Crypto User role. The module does not support a maintenance role. In order to meet the FIPS 140-2 requirements for authentication strength, the operating system must require a password with a minimum of 8 characters chosen from the range of printable ASCII characters (which include the upper and lower case alpha characters, numeric characters, and printable symbols such as !@#$, for a total of 94 characters). This creates 94^8 unique combinations, and the probability of any single attempt successfully guessing the password is 1 in 94^8, (approximately 1 in 6,000,000,000,000,000), which is far greater than the 1 in 1,000,000 requirement for a single login attempt. The fastest CPU on a computer that is being certified in this submission is 3GHz with dual cores. Assuming 16 CPU instructions per login attempt (one for each character’s input, and one for each character’s verification), this would limit the attacker to 3,000,000,000 * 2 / 16 = 375,000,000 attempts per second and approximately 1 in 948 / (375,000,000 * 60) = 270,000 chance of success per minute. Various other features of the operating system (such as cool down time between unsuccessful login attempts and account lockout after a certain number of login attempts) can make the chance of a successful login inside of a minute even more remote, but they are not necessary to meet the FIPS 140-2 authentication strength requirements. Given the above conditions, the authentication has the following strength for a single attempt and continuous attempts over a one minute period: Table F Authentication Strength Number of Attempts Time Probability of Random Minimum FIPS Authentication Success Probability Requirement 1 N/A 1 in 6,000,000,000,000,000 1 in 1,000,000 60,000,000 1 minute 1 in 270,000 1 in 100,000 5 Finite State Model The CCK uses a Finite State Model (FSM) to keep track of whether the module is in a valid state for performing cryptographic operations. The FSM resides in a thin layer of code between the API and the underlying cryptographic functions. The FSM guards access to all cryptographic functions and requires that the software module be properly initialized and must pass self-tests before allowing cryptographic functions to be performed. It also tracks the state of conditional tests. If any of these tests fail, the FSM goes into an error state, preventing any further cryptographic functioning. The FSM has the states shown in Table G. Table G States of the Finite State Model State Description FSM_CRYPTOOFFICER Crypto officer installs the CCK 15 Dell Inc. State Description Initial (startup) state – self-tests not yet run FSM_POWER_ON FSM_RUNNING_SELF_TESTS Self-tests are running FSM_RUNNING_CONDITIONAL_TEST Test of specific method being invoked from FSM_USER state FSM_USER Self-tests have passed. Ready to accept service requests. FSM_ERROR Self-test or conditional tests failed FSM_POWER_OFF CCK has been installed but is not running 6 Key Management The CCK does not perform key generation or key establishment. The CCK does not perform key storage. Other than the key used to decrypt the library authentication data, the CCK maintains keys only in memory and does not store keys to persistent media. The aforementioned key, an AES 256 key is stored in an obfuscated format compiled into the module, and is zeroed out after each use (the key still remains persisted in the obfuscated format, but is not persisted in plaintext in memory or in the binary). As such, it does not provide means for key storage or retrieval between successive power-up cycles of the device. The HMAC key and integrity value used to validate the CCK library are protected by being AES-256 encrypted. The key used for the encryption of the HMAC key and integrity value is hardcoded in an obfuscated manner in the module, and is only loaded into memory in plaintext form when needed to decrypt the validation data contained in the MAC file. After validation is performed, the decryption key, decrypted HMAC key, and decrypted HMAC integrity value are all protected by being zeroized immediately after use. 16 Dell Inc. The CCK does perform key input. All key values and initial values are generated by code outside the cryptographic software boundary and are passed to the methods in the CCK by pointer reference. That is, they are stored in memory at an address allocated by code outside the cryptographic software boundary and then passed to the methods of the CCK. The CCK does not perform key output. It has no key output methods, nor any methods that have the effect of key output. All secret keys and CSPs (including RNG seeds) used by the CCK are protected by the absence of any methods provided by the CCK API that enable, allow, or contribute to the disclosure, modification, or substitution (authorized or unauthorized) of any key, initial value, or seed passed into or used by the CCK. All CSPs used internally by the CCK (i.e. not passed to the CCK), such as those used by the random number generator, are protected by being zeroized immediately after use. Since keys and initial values passed into the CCK are stored in memory allocated by code outside the cryptographic software boundary, zeroization of these artifacts is the responsibility of the code calling the CCK. The Crypto Officer could also zeroize these artifacts by reformatting the hard drive. Occasionally, the memory containing keys and CSPs can be swapped by the Windows operating system to the hard drive of the computer. In order to avoid availability of these keys and CSPs in plain text, these swap files must either be wiped by the operator or encrypted. When the CCK is executing in Dell's Windows-based products, the swap files are encrypted. 7 Random Number Generation The CCK implements three random number generators (RNG), summarized in Table H: Table H RNGs Implemented Within the CCK RNG Deterministic/Non-Deterministic Validated SP800-90 AES-CTR Deterministic Yes X9.31 Deterministic No Generic entropy gathering seed source Non-deterministic No 7.1 RNG Seeding The SP800-90 DRBG is seeded by a combination of the generic entropy seed source and optional user input, both provided at seeding time. This is in accordance with the SP800-90 specification which allows for the seeding process to use a default seeding mechanism and still allow the caller to supplement seeding material as they see fit. This ensures that the quality of the seeding material is not left exclusively to either party. It was implemented with the specification’s DF “smoothing” function that transforms a large seed buffer of raw entropy to a suitable working state. The X9.31 algorithm is seeded by the SP800-90 DRBG. It is not certified and thus not seeded or permitted to execute when the CCK is in FIPS mode. 17 Dell Inc. The generic entropy gathering seed source gathers entropy non-deterministically from a variety of entropy sources. The entropy sources use the current CCK module execution environment and the host platform RNG sources. It is not an implementation of an Approved NDRNG (as there are no Approved NDRNGs at this time). The seeding sources vary by availability on the active platform and the available sources can be individually turned on or off (meaning that they do or do not contribute to the entropy gathering, respectively) by the user at the CCK API level. The entropy collected by this function is used to seed the SP800-90 DRBG, which has its own appropriate entropy “smoothing” function. The entropy gathered is destroyed after seeding the DRBG and is never made available outside of the CCK boundaries. 7.2 RNG Tests All RNGs run a continuous test (CRNG) on their output to ensure that each output block is distinct from the previous one. A few of the specific entropy sources have their own additional tests to continuously test for failures like long repeated runs or default to zero. The SP800-90 DRBG and X9.31 RNG have known-answer tests that execute as a part of the CCK library self-tests. A few of the generic entropy gatherer’s sources have self-tests that check that entropy is available from the source and passes basic conditions. 8 Module Interface Table I maps elements of the API to the four required components of the logical interface. Table I Logical Interface Components, API Components, Physical Ports Logical Interface Component Corresponding API Component Physical Ports Data Input API functions that accept input data Serial port, parallel port, network port, arguments mouse port, PC card interface, keyboard port Data Output API functions that produce output in Serial port, parallel port, network port, arguments and return values PC card interface, video display port Control Input API functions to initialize and shut Serial port, parallel port, network port, down the module and to run self-tests mouse port, PC card interface, keyboard port, power switch Status Output API functions which return Serial port, parallel port, network port, information regarding module status PC card interface, video display port Power N/A Power Supply 9 Self-Tests When the CCK library is initialized for the first time in approved mode, the software integrity test is performed to ensure that the library has not been modified. The test is not performed when CCK is in non-approved mode. The software integrity test uses HMAC-SHA-512 to compute the message authentication code of the library and compares the digest to an expected value. If the computed and expected values do not match, the attempt to initialize the library will fail, as will all subsequent initialization attempts until the library is re-loaded. Otherwise, it will succeed. 18 Dell Inc. Following successful software integrity test, the CCK implements a number of self-tests to ensure that it is functioning properly. On startup, the CCK executes known answer tests (KATs) on all its cryptographic functions (listed in Table C) before any cryptographic functions can be executed. In addition, the required continuous RNG test for each RNG ensures that it generates distinct arrays of bytes on each call. The module implements the following self-tests: Power-up Tests  AES  Software Integrity  HMAC-SHA-1 o o o ECB encryption and Integrity self-test of the CCK Short message KAT decryption KAT software module using o Long message KAT HMAC-SHA-512 o CBC encryption and  HMAC-SHA-256 decryption KAT  SHA-1 o Short message KAT o CTR encryption and o Short message KAT decryption KAT o Long message KAT o Long message KAT o XTS encryption and  HMAC-SHA-384 decryption KAT  SHA-256 o Short message KAT o CCM encryption and o Short message KAT o Long message KAT decryption KAT o Long message KAT  HMAC-SHA-512  Triple-DES  SHA-384 o o Short message KAT ECB encryption and o Short message KAT decryption KAT o Long message KAT o Long message KAT o CBC encryption and When CCK is in non-approved mode, decryption KAT  SHA-512 the following also apply:  DRBG o Short message KAT  X9.31 RNG o o Long message KAT KAT o KAT o Continuous Test If an error is encountered during power-up, then a descriptive error code is set inside of the initialization parameter provided by the module operator. The error code will be any of the codes unequal to CCK_INIT_SUCCESS. Conditional Tests  DRBG  NDRNG When CCK is in non-approved mode, the following also apply: o o Continuous Test Continuous Test  X9.31 RNG o Continuous Test 19 Dell Inc. If a conditional test encounters an error, then the API that triggered the error will return “false” (if it has a return value) and the internal state will enter FSM_ERROR. This status can be retrieved via the dedicated API call that queries the internal FSM state. If any of these tests fail, the FSM controlling the operation of the CCK enters an error state, preventing any further functioning of the CCK. See Section 10 for further details. The self-tests can be run on demand by power-cycling the device running the CCK. The CCK library also contains an API, available only to Crypto Officers, which enables the operator to execute the self-tests. 10 Secure Delivery, Installation, and Operation When a customer purchases Dell software that includes the CCK library, they are able to obtain the software only by secure download from a site which requires authentication and sends the installation files over an encrypted data stream. Secure installation of the CCK must be performed by an employee playing the role of Crypto Officer at Dell Inc. or by a Crypto Officer at the organization using the CCK or its associated products. Installation must be performed according to the instructions in the Installation Guide accompanying the CCK or its associated products. There is no special action the Crypto Officer must perform to ensure that the CCK is operated in FIPS mode. The CCK operates in FIPS mode by default. Secure operation of the CCK requires that each instance of the library be used by one and only one operator at a time. In addition, the application that constitutes the operator of the CCK must call the “CCK_initialize” method to initialize the CCK. Before initialization, no cryptographic functions are available. When “CCK_initialize” is called, the self-tests are automatically invoked and if, and only if, the tests pass, the module is available to perform cryptographic functions. The different platforms are able to be built from the same repository by using #ifdef macros in the code to compile different platform-specific code segments where necessary. In order to meet FIPS 140-2 security level 2 requirements, the host Windows operating system must require that all operator accounts acting as operators of the cryptographic module have an eight (8), or greater, character password. The operating system must be configured with the password entry obscured in the user interface, and must not be altered to provide feedback to an unsuccessful entry that would weaken the authentication mechanism in any way. In addition, the host Windows operating system must be configured to record addition of an operator to the administrators group, deletion of an operator from the administrators group, as well as operator login attempts. Instructions for configuring the audit mechanism to record these events are included with the installation guide. To recover from an error state, the power to the CCK must be recycled. If the CCK remains in the error state after a power recycle, the hard drive of the computer must be reformatted to ensure that all keys and CSPs used by the CCK are zeroized. Thereafter, the CCK must be reinstalled. There are no other means for recovering from an error state. After the CCK has been uninstalled, the hard disk that the CCK was on should be either a) reformatted using a full disk format that overwrites the contents of the disk, or b) overwritten using software that overwrites the entire disk with new data. This process should be performed at least once. 20 Dell Inc.