Hewlett Packard India Software Operations Pvt Ltd HP-UX Kernel Cryptographic Module Software Version: 1.0 FIPS 140-2 Non-Proprietary Security Policy FIPS Security Level: 1 Document Version: 1.2 Prepared for: Prepared by: Hewlett Packard India Software Operations Pvt Ltd Corsec Security, Inc. Survey No.192, Whitefield Road, 13135 Lee Jackson Memorial Highway Mahadevapura Post Suite 220 Bangalore – 560 048 Fairfax, VA 22033 India United States of America Phone: +91 (80) 251-66194 Phone: +1 (703) 267-6050 Email: info@hp.com Email: info@corsec.com http://www.hp.com/ http://www.corsec.com Security Policy, Version 1.2 January 15, 2014 Table of Contents 1 INTRODUCTION ................................................................................................................... 3 1.1 PURPOSE ................................................................................................................................................................ 3 1.2 REFERENCES .......................................................................................................................................................... 3 1.3 DOCUMENT ORGANIZATION ............................................................................................................................ 3 2 HP-UX KCM............................................................................................................................. 4 2.1 OVERVIEW ............................................................................................................................................................. 4 2.1.1 KCM Architecture Overview................................................................................................................................ 4 2.2 MODULE SPECIFICATION..................................................................................................................................... 5 2.2.1 Physical Cryptographic Boundary ...................................................................................................................... 6 2.2.2 Logical Cryptographic Boundary ........................................................................................................................ 6 2.3 MODULE INTERFACES .......................................................................................................................................... 7 2.4 ROLES AND SERVICES ........................................................................................................................................... 8 2.4.1 Crypto Officer Role ................................................................................................................................................ 8 2.4.2 User Role ................................................................................................................................................................... 8 2.4.3 Authentication .......................................................................................................................................................... 9 2.5 PHYSICAL SECURITY ...........................................................................................................................................10 2.6 OPERATIONAL ENVIRONMENT.........................................................................................................................10 2.7 CRYPTOGRAPHIC KEY MANAGEMENT ............................................................................................................10 2.7.1 Key Generation..................................................................................................................................................... 11 2.7.2 Key Entry and Output ........................................................................................................................................ 11 2.7.3 Key/CSP Storage and Zeroization.................................................................................................................. 12 2.8 EMI/EMC ............................................................................................................................................................12 2.9 SELF-TESTS ..........................................................................................................................................................12 2.9.1 Power-Up Self-Tests ............................................................................................................................................ 12 2.9.2 Conditional Self-Tests ......................................................................................................................................... 12 2.9.3 Critical Function Tests ........................................................................................................................................ 13 2.9.4 Error Behavior....................................................................................................................................................... 13 2.10 MITIGATION OF OTHER ATTACKS ..................................................................................................................13 3 SECURE OPERATION ......................................................................................................... 14 3.1 SECURE MANAGEMENT .....................................................................................................................................14 3.1.1 Installation and initialization ............................................................................................................................ 14 3.1.2 Management ........................................................................................................................................................ 14 3.1.3 Zeroization ............................................................................................................................................................ 14 3.2 USER GUIDANCE ................................................................................................................................................14 4 ACRONYMS .......................................................................................................................... 16 Table of Figures FIGURE 1 – HP INTEGRITY BL860C I2 SERVER BLADE BLOCK DIAGRAM..........................................................................6 FIGURE 2 – HP-UX KERNEL CRYPTOGRAPHIC MODULE LOGICAL CRYPTOGRAPHIC BOUNDARY .............................7 List of Tables TABLE 1 – SECURITY LEVEL PER FIPS 140-2 SECTION .........................................................................................................4 TABLE 2 – FIPS-APPROVED ALGORITHM IMPLEMENTATIONS .............................................................................................5 TABLE 3 – FIPS 140-2 LOGICAL INTERFACE MAPPINGS ......................................................................................................7 TABLE 4 – CRYPTO OFFICER SERVICES...................................................................................................................................8 TABLE 5 – USER SERVICES ........................................................................................................................................................ 9 TABLE 6 – CRYPTOGRAPHIC KEYS, CRYPTOGRAPHIC KEY COMPONENTS, AND CSPS............................................... 10 TABLE 7 – ACRONYMS .......................................................................................................................................................... 16 HP-UX Kernel Cryptographic Module Page 2 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 1 Introduction 1.1 Purpose This is a non-proprietary Cryptographic Module Security Policy for the HP-UX Kernel Cryptographic Module (Software Version: 1.0) from Hewlett Packard India Software Operations Pvt Ltd This Security Policy describes how the HP-UX Kernel Cryptographic Module meets the security requirements of Federal Information Processing Standards (FIPS) Publication 140-2, which details the U.S. and Canadian Government requirements for cryptographic modules. More information about the FIPS 140-2 standard and validation program is available on the National Institute of Standards and Technology (NIST) and the Communications Security Establishment Canada (CSEC) Cryptographic Module Validation Program (CMVP) website at http://csrc.nist.gov/groups/STM/cmvp. This document also describes how to run the module in a secure FIPS-Approved mode of operation. This policy was prepared as part of the Level 1 FIPS 140-2 validation of the module. The HP-UX Kernel Cryptographic Module is referred to in this document as the KCM, the crypto-module, or the module. 1.2 References This document deals only with operations and capabilities of the module in the technical terms of a FIPS 140-2 cryptographic module security policy. More information is available on the module from the following sources: • The HP website (http://www.hp.com) contains information on the full line of products from HP. • The CMVP website (http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm) contains contact information for individuals to answer technical or sales-related questions for the module. 1.3 Document Organization The Security Policy document is one document in a FIPS 140-2 Submission Package. In addition to this document, the Submission Package contains: • Vendor Evidence document • Finite State Model document • Other supporting documentation as additional references This Security Policy and the other validation submission documentation were produced by Corsec Security, Inc. under contract to HP. With the exception of this Non-Proprietary Security Policy, the FIPS 140-2 Submission Package is proprietary to HP and is releasable only under appropriate non-disclosure agreements. For access to these documents, please contact HP. HP-UX Kernel Cryptographic Module Page 3 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 2 HP-UX KCM 2.1 Overview The HP-UX Kernel Cryptographic Module (also called “KCM”) is an extraction and integration of the cryptographic functionality of various kernel-mode HP-UX software programs into a single kernel library. The various kernel-mode HP-UX software applications that utilize the cryptographic services of the module are: • Encrypted Volume and File System (EVFS) – EVFS is a volume and file-level encryption utility developed by HP and designed to run in HP-UX’s kernel space. EVFS relies on AES1 with 128, 192, and 256-bit keys in both CBC2 mode to encrypt files on disk or entire logical disk volumes. When encrypted files or volumes are requested of EVFS by a user, the user establishes a secure session with the software and utilizes the cryptographic functionalities. • Whitelisting Infrastructure (WLI) – WLI is HP’s file-level whitelisting infrastructure. This application protects files based on administrator established policy, providing file-level integrity checking and some level of user-granular access control to the files. Policies are user-specific, as each user is issued a unique RSA3 key pair which is identified by WLI using the user’s Crypto Identifier, a block of meta data created using the public key of the user. • IPsec4 – HP’s implementation of IPsec in HP-UX is proprietary and based on several modular components that execute in both user space and kernel space. User space modules include a Policy daemon, IKE5 daemon, and a Command and Utilities module. Kernel space modules include the IPsec core within the XPORT6 kernel of the TCP/IP7 stack, and the IPsec ISU8 kernel. 2.1.1 KCM Architecture Overview HP KCM is an integration of algorithms and functionalities used by EVFS, WLI, and IPsec into a single library. The library is written in C and exports an API9 within which a unique call exists for each cipher- specific operation. Applications requiring KCM services invoke those services using the module’s exported API. The KCM is validated at the following FIPS 140-2 Section levels listed in Table 1 below. Table 1 – Security Level Per FIPS 140-2 Section Section Section Title Level 1 Cryptographic Module Specification 1 2 Cryptographic Module Ports and Interfaces 1 3 Roles, Services, and Authentication 1 1 AES – Advanced Encryption Standard 2 CBC – Cipher-Block Chaining 3 RSA – Rivest Shamir Adleman 4 IPsec – Internet Protocol Security 5 IKE – Internet Key Exchange 6 XPORT – Transport 7 TCP/IP – Transmission Control Protocol/Internet Protocol 8 ISC – Independent Software Unit 9 API – Application Programming Interface HP-UX Kernel Cryptographic Module Page 4 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 Section Section Title Level 4 Finite State Model 1 N/A10 5 Physical Security 6 Operational Environment 1 7 Cryptographic Key Management 1 EMI/EMC11 8 1 9 Self-tests 1 10 Design Assurance 1 11 Mitigation of Other Attacks N/A 2.2 Module Specification The HP-UX Kernel Cryptographic Module is a software module (Software Version: 1.0) with a multi-chip standalone embodiment. The overall security level of the module is 1. The cryptographic boundaries of the module consists of the KCM library as shown by the red-colored dotted line in Figure 1 (for the physical boundary) and Figure 2 (for the logical boundary). The module was tested and found compliant on an HP Integrity BL860c i2 server blade running the HP-UX 11i v3 operating system. Security functions offered by the module (and their associated algorithm implementation certificate numbers) are listed in Table 2 below. Table 2 – FIPS-Approved Algorithm Implementations Algorithm Certificate Number Symmetric Key Algorithm AES in CBC mode (128/192/256 bits) 2488 Asymmetric Key Algorithm RSA key generation and signature generation/verification (2048-bit) 1277 Secure Hashing Standard (SHS) SHA12-256, SHA-384, SHA-512 2106 Message Authentication Code (MAC) Function HMAC13 using SHA-256, SHA-384, and SHA-512 1530 Random Bit Generation (RBG) SP14 800-90A Hash-based DRBG15 346 The module also implements the following non-Approved algorithm: • RSA16 (key wrapping; key establishment methodology provides 112 bits of encryption strength) 10 N/A – Not Applicable 11 EMI/EMC – Electromagnetic Interference / Electromagnetic Compatibility 12 SHA – Secure Hash Algorithm 13 HMAC – (Keyed-) Hash Message Authentication Code 14 SP – Special Publication 15 DRBG – Deterministic Random Bit Generator 16 RSA key wrapping is allowed for use in the Approved mode of operation16 per Implementation Guidance D.9. The calling application may use this to implement a key transport scheme, which is allowed for use in FIPS mode. HP-UX Kernel Cryptographic Module Page 5 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 2.2.1 Physical Cryptographic Boundary As a software cryptographic module, there are no physical protection mechanisms implemented. Therefore, the module must rely on the physical characteristics of the host system. The physical boundary of the cryptographic module is defined by the hard enclosure around the host platform on which it executes. The module supports the physical interfaces of host system. These interfaces include the integrated circuits of the system board, processor, network adapters, RAM17, hard disk, device case, power supply, and fans. See Figure 1 for block diagram of the test system. Figure 1 – HP Integrity BL860c i2 Server Blade Block Diagram 2.2.2 Logical Cryptographic Boundary Figure 2 shows a logical block diagram of the module, where “Calling Application” represents any other software/firmware component loaded on the host platform that employs the module’s services. The module’s logical cryptographic boundary (also illustrated in Figure 2) encompasses all functionality provided by the module as described in this document. 17 RAM – Random Access Memory HP-UX Kernel Cryptographic Module Page 6 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 Figure 2 – HP-UX Kernel Cryptographic Module Logical Cryptographic Boundary The cryptographic module is a shared object that provides cryptographic and secure communication services to the various HP-developed kernel-space applications. In this document, those applications will be referred to collectively as the “calling application”. The module is used by the calling application to provide symmetric key encryption/decryption, digital signature generation and verification, hashing, assymmetric keypair generation, random bit generation, and message authentication functions. 2.3 Module Interfaces The module’s physical ports can be categorized into the following logical interfaces defined by FIPS 140-2: • Data input • Data output • Control input • Status output As a software module, the module has no physical characteristics. The module’s physical and electrical characteristics, manual controls, and physical indicators are those of the host system. The mapping of the module’s logical interfaces in the software to FIPS 140-2 logical interfaces is described in Table 3 below. Table 3 – FIPS 140-2 Logical Interface Mappings FIPS 140-2 Interface Physical Interface Module Interface (API) Data Input Network/Serial/USB port, DVD/CD, Function calls that accept, as their Keyboard port, and Mouse port arguments, data to be used or processed by the module Data Output Network/Serial/USB port, DVD/CD, Arguments for a function that specify Graphics/Video port, and Audio where the result of the function is stored HP-UX Kernel Cryptographic Module Page 7 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 FIPS 140-2 Interface Physical Interface Module Interface (API) Control Input Network/Serial/USB port, Keyboard Function calls utilized to initiate the port and Mouse port, Power button module and the function calls used to control the operation of the module Status Output Network/Serial/USB port, Return values for function calls; Graphics/Video, LED indicators, and module-generated error messages Audio Power Input Power plug/adapter, Power Switch Not Applicable 2.4 Roles and Services There are two roles in the module that operators may assume: a Crypto Officer role and User role. The Crypto Officer is responsible for managing the module and monitoring the module’s status, while the User accesses the services implemented by the module. The available functions are utilized to provide or perform the cryptographic services. The various services offered by the module are described in Table 4 and Table 5. The Critical Security Parameters (CSPs) used by each service are also listed. Please note that the keys and CSPs listed in the tables use the following notation to indicate the type of access required: • R – Read: The keys and CSPs are read. • W – Write: The keys and CSPs are established, generated, modified, or zeroized. • X – Execute: The keys and CSPs are used within an Approved or Allowed security function or authentication mechanism. 2.4.1 Crypto Officer Role The Crypto Officer (CO) role is responsible for initializing module, zeroizing keys and CSPs, executing self-tests, and monitoring status. Descriptions of the services available to the Crypto Officer role are provided in Table 4. Table 4 – Crypto Officer Services Service Description Input Output CSP and Type of Access Initialize module Performs integrity API call Status None check and power-up parameters self-tests Show status Returns the current API call Status None mode of the module Run self-tests on Performs power-up None Status None demand self-tests Zeroize keys Zeroizes and de- API call, reboot None AES key – W allocates memory command or RSA private/public key – W containing sensitive cycling power data 2.4.2 User Role The User role can utilize the module’s cryptographic functionalities. Descriptions of the services available to the User role are provided in Table 5. HP-UX Kernel Cryptographic Module Page 8 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 Table 5 – User Services Service Description Input Output CSP and Type of Access Random Returns the specified API call Status, DRBG seed – RWX number number of random bits to parameters random bits Hash_DRBG V value – RWX generation calling application Hash_DRBG C value – RWX (Hash_DRBG) Random bits – W Message digest Compute and return a API call Status, hash None generation message digest using SHS parameters, (SHS) algorithms message Keyed hash Compute and return a API call Status, hash HMAC key – RX (HMAC) message authentication parameters, key, generation code using HMAC-SHAx message Symmetric Encrypt plaintext using API call Status, AES key – RX encryption supplied key and parameters, key, ciphertext algorithm specification plaintext (AES) Symmetric Decrypt ciphertext using API call Status, AES key – RX decryption supplied key and parameters, key, plaintext algorithm specification ciphertext (AES) Symmetric key Generate and return the API call Status, key AES key – W generation specified type of parameters pair symmetric key (AES) Asymmetric Generate and return the API call Status, key RSA private/public key – W key pair specified type of parameters pair generation asymmetric key pair (RSA) RSA key Perform key wrapping API call Status, RSA public key – RX wrapping using RSA public key parameters, key, ciphertext (used for key transport) plaintext RSA key Perform key unwrapping API call Status, RSA private key – RX unwrapping using RSA private key parameters, key, plaintext (used for key transport) ciphertext Signature Generate a signature for API call Status, RSA private key – RX Generation the supplied message parameters, key, signature using the specified key message and algorithm (RSA) Signature Verify the signature on API call Status RSA public key – RX Verification the supplied message parameters, key, using the specified key signature, and algorithm (RSA) message 2.4.3 Authentication The module does not support any authentication mechanism. Operators of the module implicitly assume a role based on the service of the module being invoked. Since all services offered by the module can only be used by either the Crypto Officer or the User, the roles are mutually exclusive. Thus, when the operator HP-UX Kernel Cryptographic Module Page 9 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 invokes a Crypto Officer role service, he implicitly assumes the Crypto Officer role. When the operator invokes a User role service, he implicitly assumes the User role. 2.5 Physical Security Since this is a software module, the module relies on the target system to provide the mechanisms necessary to meet FIPS 140-2 physical security requirements. The module was tested and found compliant on an HP Integrity BL860c i2 server blade. All components of the blade are made of production-grade materials, and all integrated circuits coated with commercial standard passivation. 2.6 Operational Environment The KCM was tested and found compliant with the applicable FIPS 140-2 requirements when running on the following operational environment(s): • HP-UX 11i v3 running on an HP Integrity BL860c i2 server blade with Intel Itanium Processor 9350 (single user mode) All cryptographic keys and CSPs are under the control of the operating system (OS), which protects the keys and CSPs against unauthorized disclosure, modification, and substitution. The module only allows access to keys and CSPs through its well-defined APIs. The module performs a Software Integrity Test using an Approved RSA digital signature verification. The vendor also affirms that the module executes in its FIPS-Approved manner on other platforms equipped with an Intel Itanium processor running the HP-UX 11i v3 operating system. 2.7 Cryptographic Key Management The module supports the critical security parameters listed below in Table 6. Please note that the “Input” and “Output” columns in Table 6 are in reference to the module’s logical boundary. Table 6 – Cryptographic Keys, Cryptographic Key Components, and CSPs CSP/Key CSP/Key Input Output Storage Zeroization Use Type AES key AES128, 192, Input Never exits Plaintext By API call, Encryption, 256-bit key electronically the module in volatile power cycle decryption in plaintext memory or host reboot Internally API call Used by calling generated via parameter application DRBG HMAC key HMAC key Input Never exits Plaintext By API call, Message electronically the module in volatile power cycle Authentication in plaintext memory or host with SHS reboot Internally API call Used by calling generated via parameter application DRBG RSA private RSA 2048-bit Input Never exits Plaintext By API call, Signature key key electronically the module in volatile power cycle generation, in plaintext memory or host decryption HP-UX Kernel Cryptographic Module Page 10 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 CSP/Key CSP/Key Input Output Storage Zeroization Use Type Internally API call reboot Used by calling generated via parameter application DRBG RSA public key RSA 2048-bit Input Never exits Plaintext By API call, Signature key electronically the module in volatile power cycle verification, in plaintext memory or host encryption reboot Internally API call Used by calling generated via parameter application DRBG DRBG seed 440-bit Internally Never exits Plaintext By API call, FIPS-Approved random value generated the module in volatile power cycle random number using nonce, memory or host generation personalization reboot string along with entropy input string Entropy input 256-bit Externally Never exits Plaintext By API call, FIPS-Approved string random value generated the module in volatile power cycle random number using an memory or host generation NDRNG18 and reboot input in plaintext Hash_DRBG Internal hash Internally Never Plaintext Reboot, Used for SP 800- V value DRBG state generated in volatile power cycle 90 Hash_DRBG value memory Hash_DRBG Internal hash Internally Never Plaintext Reboot, Used for SP 800- C value DRBG state generated in volatile power cycle 90 Hash_DRBG value memory 2.7.1 Key Generation The module uses an SP 800-90A hash-based DRBG implementation to generate cryptographic keys and the key generation process complies with example 1 of IG197.8. This DRBG is FIPS-Approved (as shown in Annex C to FIPS PUB 140-2). The module also supports the generation of the RSA public/private keys using the RSA key generation function specified in FIPS 186-3. It is the responsibility of the calling applications to ensure that the module is supplied with enough entropy to meet the requirement of the hash- based DRBG. This entropy is supplied by means of callback functions. Those functions must return an error if the minimum entropy strength cannot be met20. 2.7.2 Key Entry and Output Keys are passed into the module’s logical boundary in plaintext via the exposed APIs, but only from applications resident on the host platform. However, the cryptographic module does not support key entry 18 NDRNG – Non-Deterministic Random Number Generator 19 IG – Implementation Guidance 20 Caveat: The module generates cryptographic keys whose strengths are modified by available entropy. Thus, there is no assurance of the minimum strength of generated keys. HP-UX Kernel Cryptographic Module Page 11 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 or key output across the host platform’s physical boundary. Similarly, keys and CSPs exit the module in plaintext (but remain in the physical boundary) via the well-defined exported APIs. 2.7.3 Key/CSP Storage and Zeroization As a software module, the module does not provide for the persistent storage of keys and CSPs. Keys and CSPs stored in RAM can be zeroized by a power cycle or a host platform reboot. Additionally, symmetric and asymmetric keys are either provided by or delivered to the calling process, and are subsequently destroyed by the module at the completion of the API call. The DRBG seed is initialized by the module (internally generated) at power-up and remains stored in RAM until the module is uninitialized by a host platform reboot or power cycle. The keys can also be zeroized by the calling application by invoking an API function. The key zeroization techniques used for clearing volatile memory, once invoked, take effect immediately and do not allow sufficient time to compromise any plaintext secret and private keys and CSPs stored by the module. 2.8 EMI/EMC The HP-UX Kernel Cryptographic Module is a software module. Therefore, the only electromagnetic interference produced is that of the host platform on which the module resides and executes. The test platform for the module is an HP Integrity BL860c i2 server blade. This equipment has been tested and found to comply with Federal Communications Commission (FCC) EMI and EMC requirements for business use as defined in Subpart B, Class A of FCC 47 Code of Federal Regulations Part 15. 2.9 Self-Tests The HP-UX Kernel Cryptographic Module performs a set of self-tests upon power-up and conditionally during operation as required in FIPS 140-2. 2.9.1 Power-Up Self-Tests The HP-UX Kernel Cryptographic Module performs the following self-tests at power-up (these tests can also be performed on demand by cycling the power on the host platform, by calling the function libkcm_FIPS_selftest(), or by reinitializing the module by using the libkcm_core_load() function): • Software integrity check using RSA digital signature verification • Known Answer Tests (KATs) for: o AES o SHA-256 o SHA-384 o SHA-512 o HMAC SHA-256 o HMAC SHA-384 o HMAC SHA-512 o RSA signature generation o RSA signature verification o DRBG 2.9.2 Conditional Self-Tests The module performs the following conditional self-tests: • Continuous DRBG test (CRNGT) for FIPS-Approved random number generator • RSA Pairwise Consistency test HP-UX Kernel Cryptographic Module Page 12 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 2.9.3 Critical Function Tests The HP-UX Kernel Cryptographic Module implements the SP 800-90A HASH_DRBG as its random number generator. The SP 800-90A specification requires that certain critical functions be tested conditionally to ensure the security of the DRBG. Therefore, the following critical function tests are implemented by the cryptographic module: • DRBG Instantiate Critical Function Test • DRBG Reseed Critical Function Test • DRBG Generate Critical Function Test • DRBG Uninstantiate Critical Function Test 2.9.4 Error Behavior If any power-up self-test fails, the module will enter a critical error state, during which cryptographic functionality and all data output is inhibited and the module does not get loaded. To clear the error state, the CO must reboot the host platform. If any conditional self-test or on-demand power-up self-test fails, the module will enter a critical error state, during which cryptographic functionality and all data output is inhibited. Subsequent calls to the module will not result in data output; rather, the module will only return an error code indicating that it is in an error state. To clear the error state, the CO must explicitly unload the module and reboot the host platform. 2.10 Mitigation of Other Attacks This section is not applicable. The modules do not claim to mitigate any attacks beyond the FIPS 140-2 Level 1 requirements for this validation. HP-UX Kernel Cryptographic Module Page 13 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 3 Secure Operation The HP-UX Kernel Cryptographic Module meets level 1 requirements for FIPS 140-2. The sections below describe how to place and keep the module in its FIPS-Approved mode of operation. Section 3.1 below provides guidance to the Crypto Officer for managing the module. 3.1 Secure Management The following sections provide the necessary guidance to ensure that the module is running in its FIPS- Approved mode of operation. 3.1.1 Installation and initialization The module will be provided as a binary to the Crypto Officer by HP. The module is installed after the process of installing the HP-UX kernel which is achieved via HP-UX OS installation. Upon delivery, the Crypto Officer will also receive the HP-UX KCM Installation Procedure documentation that lists the steps and commands to be followed for successful installation of the module. In order to install and setup the module, the following steps must be performed by an authorized CO: 1. Install the module on the system by using the command “swinstall –s /HP- KCM.depot”. 2. Check the success or failure of the module installation by using the command “swlist | grep –i kcm”. If the module is successfully installed on the system, the following message will be displayed: “HPUX-KCM A.01.00.00 HP-UX Kernel Cryptography Module” 3. The CO can also verify whether the module is properly installed or not by using the command “swverify HPUX-KCM”. If either “swinstall” or “swverify” shows any Errors or Warnings, then either the module is not installed or not installed properly. If the installation procedure reports error consistently, then HP Customer Support should be contacted. Once installed correctly, the module is initialized by a call to a single initialization function libkcm_core_load(). When the module is installed and initialized, the module is considered to be running in its FIPS-Approved mode of operation. 3.1.2 Management Since the Crypto Officer cannot directly interact with the module, no specific management activities are required to ensure that the module runs securely; the module only executes in an Approved mode of operation when operated according to this Security Policy. If any irregular activity is noticed or the module is consistently reporting errors, then HP Customer Support should be contacted. 3.1.3 Zeroization The module does not persistently store any key or CSPs. All ephemeral keys used by the module are zeroized upon session termination. Individual keys can be zeroized by API call. All keys can be zeroized by power cycling or rebooting the host platform. 3.2 User Guidance It is the responsibility of the calling application developer to ensure that only appropriate algorithms, key sizes, and key establishment techniques are applied. HP-UX Kernel Cryptographic Module Page 14 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 Although the User does not have any ability to modify the configuration of the module, they should notify the Crypto Officer if any irregular activity is noticed. HP-UX Kernel Cryptographic Module Page 15 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 4 Acronyms Table 7 below defines the acronyms used in this document. Table 7 – Acronyms Acronym Definition AES Advanced Encryption Standard API Application Programming Interface BIOS Basic Input/Output System CBC Cipher Block Chaining CD Compact Disc CMVP Cryptographic Module Validation Program CO Crypto Officer CPU Central Processing Unit CSEC Communications Security Establishment Canada CSP Critical Security Parameter DRBG Deterministic Random Bit Generator DVD Digital Video Disc EMC Electromagnetic Compatibility EMI Electromagnetic Interference EVFS Encrypted Volume and File System FCC Federal Communications Commission FIPS Federal Information Processing Standard GPC General Purpose Computer HDD Hard Disk Drive HMAC (Keyed-) Hash Message Authentication Code IG Implementation Guidance IKE Internet Key Exchange IPsec Internet Protocol Security ISU Independent Software Unit KAT Known Answer Test KCM Kernel Cryptographic Module LCD Liquid Crystal Display LED Light Emitting Diode N/A Not Applicable NDRNG Non-Deterministic Random Number Generator HP-UX Kernel Cryptographic Module Page 16 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Security Policy, Version 1.2 January 15, 2014 Acronym Definition NIST National Institute of Standards and Technology OS Operating System PCI Peripheral Component Interconnect PCIe PCI Express PKCS Public Key Cryptography Standards PUB Publication RAM Random Access Memory RBG Random Bit Generator RNG Random Number Generator RSA Rivest Shamir and Adleman SATA Serial Advanced Technology Attachment SCSI Small Computer System Interface SHA Secure Hash Algorithm SHS Secure Hash Standard SP Special Publication TCP/IP Transmission Control Protocol/Internet Protocol USB Universal Serial Bus WLI Whitelisting Infrastructure XPORT Transport HP-UX Kernel Cryptographic Module Page 17 of 18 © 2014 Hewlett Packard India Software Operations Pvt Ltd This document may be freely reproduced and distributed whole and intact including this copyright notice. Prepared by: Corsec Security, Inc. 13135 Lee Jackson Memorial Highway, Suite 220 Fairfax, VA 22033 United States of America Phone: +1 (703) 267-6050 Email: info@corsec.com http://www.corsec.com