Dell-CREDANT Cryptographic Kernel Mac Kernel Mode version 1.8 Mac User Mode version 1.8 Linux User Mode version 1.8 FIPS 140-2 Non-Proprietary Security Policy Security Level 1 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. Ubuntu and Canonical are registered trademarks of Canonical Ltd. Linux is a registered trademark of Linus Torvalds. Mac and OS X are trademarks of Apple Inc., registered in the U.S. and other countries. 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 ................................................................................................................. 9 4 Roles, Services, Policy...................................................................................................................................... 11 4.1 Roles Related Notes ............................................................................................................................... 16 4.2 Services Related Notes ........................................................................................................................... 16 4.3 Authentication Related Notes ................................................................................................................. 16 5 Finite State Model............................................................................................................................................. 16 6 Key Management .............................................................................................................................................. 17 7 Random Number Generation ............................................................................................................................ 18 7.1 RNG Seeding ......................................................................................................................................... 18 7.2 RNG Tests .............................................................................................................................................. 19 8 Module Interface ............................................................................................................................................... 19 9 Self-Tests .......................................................................................................................................................... 19 10 Secure Delivery, Installation and Operation ................................................................................................... 22 10.1 Linux User Mode and Mac User Mode Startup Procedures ................................................................... 22 10.2 Mac Kernel Mode Startup Procedures ................................................................................................... 22 List of Figures Figure I Linux User Mode Physical and Logical Cryptographic Boundaries ........................................................5 Figure II Mac User Mode Physical and Logical Cryptographic Boundaries ..........................................................6 Figure III Mac Kernel Mode Physical and Logical Cryptographic Boundaries .......................................................7 2 Dell Inc. List of Tables Table A Security Level Achieved in Each Security Category ...............................................................................8 Table B Explicit Mapping of the Module Versions, CCK File Names, and Tested Platforms ..............................9 Table C Explicit Mapping of the Module Versions, CCK File Names, and Tested Platforms ............................ 10 Table D Service Type Offered by Algorithm, FIPS Specification, and Availability ........................................... 11 Table E Access to Security Relevant Data Items (CSP) for Each Service and Role ........................................... 12 Table F Inputs and Outputs of Each Service Provided by the CCK .................................................................... 15 Table G States of the Finite State Model ............................................................................................................. 17 Table H RNGs Implemented Within the CCK .................................................................................................... 18 Table I Logical Interface Components, API Components, Physical Ports ......................................................... 19 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 Linux User Mode Physical and Logical Cryptographic Boundaries 5 Dell Inc. Figure II Mac User Mode Physical and Logical Cryptographic Boundaries 6 Dell Inc. Figure III Mac 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 1 security on the following configurations:   Ubuntu Linux 11.04 (32- and 64-bit, user mode) Mac OSX Lion 10.7.3 (32- and 64-bit, user and on a Dell OptiPlex™755 kernel mode) on a mid-2010 MacBook Pro (MacBookPro6,2) The module also runs on the following platforms not included in this validation:    Mac OSX 10.6 Mac OSX 10.5 Mac OSX 10.4 (32- and 64-bit) (32- and 64-bit) (32- and 64-bit) 7 Dell Inc. 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. The cryptographic module achieves an overall security level 1, 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 1 Cryptographic Module Ports and Interfaces 1 Roles, Services, and Authentication 1 Finite State Model 1 Physical Security N\A Operational Environment 1 Cryptographic Key Management 1 EMI\EMC 3 Self-Tests 1 Design Assurance 3 Mitigation of Other Attacks N\A The CCK consists of the following files:    CmgCryptoLib.so – CmgCryptoLib.bundle – A CREDANTCrypto.kext – Mac “bundle” of the CCK The dynamic link library A Mac kernel extension containing the CCK’s “bundle” of the CCK library library files, including the cryptographic functionality cryptographic functionality files, including the for Linux User mode. for Mac User mode and the cryptographic functionality supporting file for the for Mac Kernel mode and  CmgCryptoLib.mac – The software integrity test. the supporting file for file used to support software Contains the 32- and 64-bit software integrity test. integrity test of the file builds together inside the Contains the 32- and 64-bit CmgCryptoLib.so for Linux same file. builds together inside the User mode. same file. 8 Dell Inc. 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 Mac Kernel Mode CREDANTCrypto.kext Mac OSX Lion 10.7.3 (32-bit) on a Version 1.8 (32-bit) mid-2010 MacBook Pro (MacBookPro6,2) Mac Kernel Mode CREDANTCrypto.kext Mac OSX Lion 10.7.3 (64-bit) on a Version 1.8 (64-bit) mid-2010 MacBook Pro (MacBookPro6,2) Mac User Mode CmgCryptoLib.bundle Mac OSX Lion 10.7.3 (32-bit) on a Version 1.8 (32-bit) mid-2010 MacBook Pro (MacBookPro6,2) Mac User Mode CmgCryptoLib.bundle Mac OSX Lion 10.7.3 (64-bit) on a Version 1.8 (64-bit) mid-2010 MacBook Pro (MacBookPro6,2) Linux User Mode CmgCryptoLib.so Ubuntu Linux 11.04 (32-bit) on a Dell Version 1.8 (32-bit) CmgCryptoLib.mac OptiPlex 755 Linux User Mode CmgCryptoLib.so Ubuntu Linux 11.04 (64-bit) on a Dell Version 1.8 (64-bit) CmgCryptoLib.mac OptiPlex 755 Note: The “CREDANTCrypto.kext” file is the same between the 32- and 64-bit platforms and the “CmgCryptoLib.bundle” file is the same between platforms. This is due to how those platforms combine 32- and 64-bit versions of the library. The “CmgCryptoLib.so” files are different between 32- and 64-bit platforms 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. 9 Dell Inc. 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 Mac user-mode CmgCryptoLib library (but not included in the Linux user-mode or Mac kernel-mode libraries) to accelerate certain cryptographic algorithms. This library is 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. Table C Explicit Mapping of the Module Versions, CCK File Names, and Tested Platforms Module Version CCK Files Tested Platforms  Mac OS X Lion 10.7.3 (32-bit) on Mac Kernel Mode CREDANTCrypto.kext Version 1.8 (32- and 64-bit) a mid-2010 MacBook Pro (MacBookPro6,2)  Mac OS X Lion 10.7.3 (64-bit) on a mid-2010 MacBook Pro (MacBookPro6,2)  Mac OS X Lion 10.7.3 (32-bit) on Mac User Mode CmgCryptoLib.bundle Version 1.8 (32- and 64-bit) a mid-2010 MacBook Pro (MacBookPro6,2)  Mac OS X Lion 10.7.3 (64-bit) on a mid-2010 MacBook Pro (MacBookPro6,2)  Ubuntu Linux 11.04 (32-bit) on a Linux User Mode CmgCryptoLib.so Version 1.8 (32- and 64-bit) CmgCryptoLib.mac Dell OptiPlex 755  Ubuntu Linux 11.04 (64-bit) on a Dell OptiPlex 755 10 Dell Inc. 4 Roles, Services, Policy Table D 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, Triple-DES, Crypto User 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 User 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) 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, 11 Dell Inc. Service Type Algorithm FIPS Standard Library FIPS Algorithm Available in Certificate Roles Number 384, SHA-512 Kernel Mode Crypto User 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 E. 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 E Access to Security Relevant Data Items (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, AES key used to wrap the Execute, Read, CCK_initialize Crypto User software integrity test key Write (read access), MAC software integrity test key (read access), Expected result of software integrity test (read access), Computed software integrity test 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) Key Zeroization Crypto Officer, Last Triple-DES key used, Execute, Write CCK_reset_encryption_decryp Crypto User Last AES key used, tion_algorithm_state_info, HMAC key pair used in a CCK_clear_AES_keys, provided HMAC context CCK_clear_DES3_keys, CCK_HMAC_truncated_final _internal, CCK_HMAC_SHA2_final_an d_report_internal 12 Dell Inc. Service Access (Role) Accessible Type of CCK CSP Access API(s) Run Self Tests Crypto Officer, None Execute CCK_self_tests, Crypto User CCK_conditional_test, CCK_set_error_state, CCK_self_auth Show Status Crypto Officer, None Execute CCK_fips_mode, Crypto User CCK_status, CCK_test_status, CCK_role_auth_status AES Crypto Officer, AES key (read access to Execute, Read, CCK_set_AES_block_ Crypto User key passed as parameter, Write size_and_key, write access to cache the CCK_set_AES_XTS_ key) secondary_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, Triple-DES key (read Execute, Read, CCK_DES3_encrypt, Crypto User access to key passed as Write CCK_DES3_decrypt, parameter, write access to CCK_DES3_CBC_encrypt, cache the key) CCK_DES3_CBC_decrypt HMAC-SHA-1 Crypto Officer, HMAC-SHA-1 key pair Execute, Read, CCK_HMAC_init, Crypto User (read access to key passed Write CCK_HMAC_destroy, as a parameter, write CCK_HMAC_restart, access to store the derived CCK_HMAC_update, HMAC key pair) CCK_HMAC_truncated_final HMAC-SHA-256, Crypto Officer, HMAC key (read access Execute, Read, CCK_HMAC_SHA2_init, HMAC-SHA-384, Crypto User to key passed as Write CCK_HMAC_SHA2_destroy, HMAC-SHA-512 parameter, write access to CCK_HMAC_SHA2_restart, store the derived HMAC CCK_HMAC_SHA2_update, key pair) CCK_HMAC_SHA2_final_an d_report SHA-1 Crypto Officer, None Execute CCK_SHA1_reset, Crypto User CCK_SHA1_get_hash, 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 13 Dell Inc. Service Access (Role) Accessible Type of CCK CSP Access API(s) DRBG Crypto Officer, DRBG entropy seed (read Execute, Read, CCK_DRBG_generate_bytes, Crypto User access), Write CCK_DRBG_reseed_state, DRBG “Key” state data CCK_DRBG_check_alive (read and write access), CCK_DRBG_reinstantiate, DRBG “V” state data CCK_perform_DRBG_test (read and write access), RNG seed (read and write access) 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 14 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 F. The methods of the cryptographic software module are designed to be invoked by a single process per session handle. Table F 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 15 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 For the Level 1 Linux and Mac platforms in this validation, the only privilege unique to the Crypto Officer is ability to perform installation of the module. 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., Unix-style entropy source “/dev/random”) and less if weaker (e.g., system time). 4.3 Authentication Related Notes The cryptographic module does not support any methods of authenticating the operator on the Mac and Linux platforms since it is not required for Level 1. Within the CCK module, all operators are implicitly made a Crypto User. Whether an operator is a Crypto Officer is determined by the operating system’s permissions configuration. 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 16 Dell Inc. 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 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. 17 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 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 Mac-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. 18 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. This method of self-test applies to all versions of the cryptographic module, except for the Mac Kernel Extension. Following successful software integrity test, the CCK implements a number of self-tests to ensure that it 19 Dell Inc. is functioning properly. On startup, the CCK executes known answer tests (KATs) on all its cryptographic functions (listed in Table D) 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 Mac Kernel Extension (KEXT) version of the cryptographic module is needed at such an early point in the boot process that the file system does not exist. As such, the aforementioned method cannot be used to perform the self- test as it cannot find either the file storing the expected HMAC value or its own binary to perform the HMAC on itself. For this reason the Mac KEXT version of the library must find itself loaded in memory to compute the HMAC on itself. This approach, however, results in the operating system rearranging or relocating symbols as it loads the module into memory. The solution to this is to create a copy of the module in memory and, with the support of the relocation data generated at compile time, relocate all of the symbols back to their original compiled base locations prior to computing the HMAC. With this approach, the Mac KEXT self-test function must be provided the expected HMAC value, as well as the relocation data generated at compile time, in the form of a BLOB. This data is provisioned at install time so that it is available to the operator to pass it to the module at initialization time. Once the internal self-test function is called, the cryptographic module finds itself in memory, makes a copy, “unrelocates” the copy, and performs the HMAC on the relevant sections of the copy, comparing the result to the expected value. Until this self-test passes, the module cannot be initialized. 20 Dell Inc. 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 21 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. The host operating system must be configured to a single user mode of operation. Secure operation of the CCK requires that each instance of the library be used by one and only one operator at a time. The steps to initialize the library depend on the platform. 10.1 Linux User Mode and Mac User Mode Startup Procedures 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. 10.2 Mac Kernel Mode Startup Procedures In the Mac KEXT version of the CCK module, the application that constitutes the operator of the CCK must call the “CCK_auth_mac” to initiate the integrity self-test. If and only if this function succeeds in validating the Mac KEXT integrity, the operator can call “CCK_initialize” to begin using the cryptographic module. Until the “CCK_initialize” function is successfully called, no cryptographic functions are available to the operator application. 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. 22 Dell Inc. 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. 23 Dell Inc.