ZTE Unified Element Management Platform Cryptographic Module Version 4.11.10 FIPS 140-2 Non-Proprietary Security Policy Policy Version 1.1 Last Updated: 2011-07-05 © Copyright ZTE 2011. This document may be reproduced only in its original entirety without revision, including this copyright notice. Table of contents 1.  Introduction ....................................................................................................................................................... 3  2.  Cryptographic Module Specification................................................................................................................. 4  2.1.  Module Overview ............................................................................................................................... 4  2.2.  Cryptographic Boundary..................................................................................................................... 4  2.3.  Cryptographic Module Security Level................................................................................................ 6  2.4.  Tested Platforms ................................................................................................................................. 6  2.5.  Approved Mode of Operation ............................................................................................................. 7  3.  Cryptographic Module Ports and Interfaces ...................................................................................................... 9  4.  Roles, Services and Authentication ................................................................................................................. 10  4.1.  Roles ................................................................................................................................................. 10  4.2.  Services ............................................................................................................................................. 10  5.  Physical Security ............................................................................................................................................. 12  6.  Operational Environment ................................................................................................................................ 13  6.1.  Installation and Invocation................................................................................................................ 13  6.2.  Rules of Operation ............................................................................................................................ 14  7.  Cryptographic Key Management .................................................................................................................... 16  7.1.  Random Number Generator .............................................................................................................. 16  7.2.  Key Generation ................................................................................................................................. 16  7.3.  Key Entry and Output ....................................................................................................................... 16  7.4.  Key Storage....................................................................................................................................... 16  7.5.  Key Zeroization ................................................................................................................................ 16  8.  EMI/EMC ........................................................................................................................................................ 17  9.  Self Tests ......................................................................................................................................................... 18  9.1.  Power-Up Tests ................................................................................................................................. 18  9.1.1.  Integrity Test .......................................................................................................................... 18  9.1.2.  Cryptographic algorithm KAT ............................................................................................... 18  9.2.  Conditional Tests .............................................................................................................................. 19  9.2.1.  Pair-wise consistency test ...................................................................................................... 19  9.2.2.  Continuous test for DRBG ..................................................................................................... 19  10.  Design Assurance ............................................................................................................................................ 20  10.1.  Configuration Management .............................................................................................................. 20  10.2.  Guidance ........................................................................................................................................... 20  10.2.1.  Cryptographic Officer Guidance ............................................................................................ 20  10.2.2.  User Guidance ........................................................................................................................ 20  11.  Mitigation of Other Attacks ............................................................................................................................. 21  12.  Appendix A ..................................................................................................................................................... 22  ©2011 ZTE corporation Page 2 of 22 1. Introduction This document is a non-proprietary FIPS 140-2 Security Policy for the Unified Element Management Platform Cryptographic Module (“UEP Cryptographic Module” or “UEPCM” or “module”) version 4.11.10. It describes how this module meets the requirements as specified in FIPS PUB 140-2 (Federal Information Processing Standards Publication 140-2) for a Security Level 1 multi-chip standalone software module. The companion document ZTE UEPCM User’s Guide is a technical reference for the UEPCM application developers to use and integrate the UEPCM into their applications. The security policy is required for FIPS 140-2 validation and is intended to be part of the package of documents that are submitted to Cryptographic Module Validation Program (CMVP). It describes the capabilities, protection, and access rights provided by the cryptographic module. It also contains a specification of the rules under which the module must operate in order to be in the FIPS mode. This security policy allows individuals and organizations to determine whether the cryptographic module meet their security requirements and to determine whether the module, as implemented, satisfies the stated security policy. The targeted audience of this document consists of but not limited to the UEPCM module and its application developers, testers at the Cryptographic Services Testing (CST) lab and reviewers from CMVP. ©2011 ZTE corporation Page 3 of 22 2. Cryptographic Module Specification 2.1. Module Overview The Unified Element Management Platform Cryptographic Module (Software Version 4.11.10) is a software only, multi-chip standalone cryptographic module that runs on a blade system. The UEPCM is used by the ZTE to provide a solution for mutual authentication and cryptographic services between network elements and their management platform. 2.2. Cryptographic Boundary The logical cryptographic boundary for the Module is the library itself. The format of this library is a jar file (uepcm.jar). The physical boundary of the UEPCM is a blade in a blade system on which the module is to be executed. A blade is the hardware platform on which the module runs. A blade consists of standard integrated circuits, including processors, memory, hard disk, data I/O interface, clock and power input. The block diagram for the module is shown below. Figure 1 : Block Diagram of the Cryptographic Module ©2011 ZTE corporation Page 4 of 22 The UEPCM cryptographic module is developed in JAVA language and is provided to application developers as a JAR file. Applications interact with the cryptographic module through an API (see appendix A). The relationship between the UEPCM and the ZTE UEP application is shown in the following diagram. ZTE UEP Application ZTE UEP Application code UEPCM UEPCM code Figure 2: Functional Decomposition of the UEPCM and Its UEP Application  ZTE UEP Application – The ZTE UEP application using the UEPCM. The UEP application is built upon the application code and the UEPCM JAR file.  ZTE UEP Application code – The program using the UEPCM to perform cryptographic functions.  UEPCM – The cryptographic module to be validated that contains a uepcm.jar that can be linked to the ZTE UEP application.  uepcm.jar – a dynamically linkable cryptographic library that is compiled from the UEPCM code. The module components within the logical boundary of the UEPCM are specified in Table 1. Component Type File Name Version Dynamic Library binary uepcm.jar 4.11.10 code Documentation UEPCM_SP.doc 1.0 FiniteStateMachine(UEPCM).doc 1.1 ComponentsList(UEPCM).doc 1.2 ©2011 ZTE corporation Page 5 of 22 ZTE_UEPCM_USER_Guide.doc 1.2 Table 1: The UEPCM Cryptographic Module Components 2.3. Cryptographic Module Security Level The module is validated as a software module running on a multi-chip standalone platform against FIPS 140-2 at overall Security Level 1 cryptographic module. The following table shows the security level claimed for each of the eleven sections that comprise the FIPS 140-2: FIPS 140-2 Sections Security 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 1 Self Tests 1 Design Assurance 1 Mitigation of Other Attacks N/A Table 2 - Security Levels for Eleven Sections of the FIPS 140-2 Requirements 2.4. Tested Platforms The UEPCM validation was performed on the following platforms. Manuf Model CPU EMI/EMC Compliance OS and Version JDK/JRE Version acturer Sun JDK/JRE ZTE SBCO AMD Opteron® FCC report provided by ZTE NewStart CGS Linux 64 CORPORATION EMC V3.02 (single user 1.6.0_11 Laboratory mode) Sun JDK/JRE ZTE SBCW Intel® Xeon™ FCC report provided by ZTE NewStart CGS Linux 64 CORPORATION EMC V3.02 (single user 1.6.0_11 Laboratory mode) ©2011 ZTE corporation Page 6 of 22 Sun JDK/JRE HP BL680c Intel® Xeon™ Conformance declaration NewStart CGS Linux Blade 64 provided by Hewlett-Packard V3.02 (single user 1.6.0_11 Server Company mode) Table 3 - Tested platforms 2.5. Approved Mode of Operation The UEPCM module implements a list of FIPS-Approved algorithms and callable in FIPS-mode as shown in Table 4. Algorithm w/modes Keys/CSPs Usage Algorithm Certificate # AES 128, 192, 256 bit keys Encryption/decryption INTEL:# 1584 (ECB, CBC, OFB, CFB8, AMD: # 1583 CFB128) Triple-DES 3-key 168 bits Encryption/decryption INTEL:# 1040 AMD: # 1039 (ECB, CBC, CFB8，CFB64, OFB) DSA (FIPS 186-3, PQG(gen), p, q, g; 2048 bits Key Pair generation, INTEL:# 490 PQG(ver), KEYGEN, modulus size Generate and Verify signature AMD: # 489 SIG(gen), SIG(ver)) 2048 bits modulus size key pair RSA (ANSI X9.31 Module sizes: 1536, Key Pair generation, INTEL:# 774 (Key(gen));PSS (SIG(gen), 2048, 3072, 4096; Generate and Verify signature AMD: # 773 SIG(ver))) Public Key sizes: 3, 17, 65537 DRBG SP800-90 seed value Random bit generation. INTEL:# 74 (Hash_DRBG SHA256） and 256 bit seed key AMD: # 73 values. SHA224 (BYTE-only) N/A Hashing INTEL:# 1403 SHA256 (BYTE-only) AMD: # 1402 SHA384 (BYTE-only) SHA512 (BYTE-only) HMACSHA-224 HMAC keys Message Authentication INTEL:#930 HMACSHA-256 Key Size Ranges AMD: # 929 Tested: HMACSHA-384 Key Size < Block HMACSHA-512 Size, ©2011 ZTE corporation Page 7 of 22 Key Size = Block Size, Key Size > Block Size Table 4: FIPS-Approved Cryptographic Algorithms The UEPCM always operates in a FIPS approved mode of operation. For the purposes of FIPS- 140- 2 validation, the Module is classified as a multi-chip stand-alone Module. ©2011 ZTE corporation Page 8 of 22 3. Cryptographic Module Ports and Interfaces As a software only cryptographic module, the logical interface of the UEPCM is its API documented in the ZTE UEPCM User’s Guide. The execution of the UEPCM is powered by its hardware platform that connects to a power supply through its physical boundary. The table below maps the FIPS 140-2 required ports and interfaces to the UEPCM logical interfaces originated in its API. FIPS Required Interface The UEPCM Interface Data Input API input parameters Data Output API output parameters Control Input API function calls, API input parameters Status Output API return codes/messages Power Input Power connector through the underlying hardware power supply port Table 5: Ports and Interface of the UEPCM The UEPCM communicates any error status synchronously through the use of its documented return codes. It is optimized for library use and does not contain any terminating assertions or exceptions. The UEPCM does not support cryptographic bypass capability, either. Any internal error detected by the UEPCM will be reflected back to the application with an appropriate return code or error message. The calling application must examine the return code and handle exceptional conditions in a FIPS 140-2 appropriate manner. Return codes and error conditions are fully documented in the ZTE UEPCM User’s Guide. They do not reveal any sensitive material to callers. ©2011 ZTE corporation Page 9 of 22 4. Roles, Services and Authentication 4.1. Roles The UEPCM supports two roles: a Cryptographic Officer role and a User role. Each of roles is authenticated through the operating system prior to using any system services. The module does not require any further authentication that would allow the module to distinguish between the two supported roles. The Crypto Officer and User roles are implicitly assumed by the entity accessing services implemented by the module. Both roles can access all of the cryptographic services provided by the module. In addition, the Crypto Officer role can integrate the module with its applications, install and initialize the module. If any of the Crypto- Officer-specific services are involved, then the operator is implicitly assumed in the Crypto-Officer role; otherwise the operator is by default assumed in the User role. The module does not allow concurrent operators. 4.2. Services Services are accessed through documented API interfaces from the calling application. The following services listed in Table 6 can be used in the FIPS-approved mode. Service Roles Access to CSPs API function Crypto User - Officer Crypto module No CSP to be accessed FIPSModuleContext.cm_init() ✕ ✓ initialization/end FIPSModuleContext.cm_end() Get module status No CSP to be accessed FIPSModuleContext.getState() ✓ ✓ Self-test Read access to HMAC FIPSModuleContext.selfTests() ✓ ✓ key. AES encryption Read/write access to the FIPSModuleContext.fips_AES_encrypt() ✓ ✓ and decryption AES symmetric key FIPSModuleContext.fips_AES_decrypt() Triple-DES Read/write access to the FIPSModuleContext.fips_TDES_encrypt() ✓ ✓ encryption and Triple-DES symmetric FIPSModuleContext.fips_TDES_decrypt() decryption key DSA domain Write access to the DSA FIPSModuleContext.fips_DSA2_genPQG() ✓ ✓ parameter domain parameters generation DSA domain Read access to the DSA FIPSModuleContext.fips_DSA2_verPQG() ✓ ✓ parameter domain parameters validation DSA Key pair Write access to the DSA FIPSModuleContext.fips_DSA2_genKeyPair() ✓ ✓ generation key pair ©2011 ZTE corporation Page 10 of 22 Service Roles Access to CSPs API function Crypto User - Officer DSA Signature Read access to DSA FIPSModuleContext.fips_DSA2_genSignature() ✓ ✓ generation private key DSA Signature Read access to DSA FIPSModuleContext.fips_DSA2_verSignature() ✓ ✓ verification public key RSA key generation ✓ Write access to the RSA FIPSModuleContext.fips_RSA_genKeyPair() ✓ key pair RSA Signature Read access to RSA FIPSModuleContext.fips_RSA_genSignature() ✓ ✓ Generation based private key on PSS (probabilistic signature scheme) RSA Signature Read access to RSA FIPSModuleContext.fips_RSA_verifySignature() ✓ ✓ Verification based public key on PSS (probabilistic signature scheme) SHA-224 No CSP to be accessed FIPSModuleContext.fips_SHA2_digest() ✓ ✓ SHA-256 SHA-384 SHA-512 HMAC-SHA224 Read access to HMAC- FIPSModuleContext.fips_HMAC_digest() ✓ ✓ SHA key HMAC-SHA-256 HMAC-SHA-384 HMAC-SHA-512 Write access to seed FIPSModuleContext. fips_SHA256DRBG () ✓ ✓ DRBG SP800-90 (Hash_DRBG SHA256) Table 6: Services that are callable in the FIPS-Approved mode ©2011 ZTE corporation Page 11 of 22 5. Physical Security The UEPCM is a software only cryptographic module and thus does not claim any physical security. ©2011 ZTE corporation Page 12 of 22 6. Operational Environment 6.1. Installation and Invocation The UEPCM is installed as part of the Unified Element Management Platform on the host system. The validated version of the UEPCM is provided to the ZTE application developers through the uepcm.jar(version 4.11.10). The module is accessed from its applications by importing the uepcm.jar to its classpath, and it is invoked via the APIs as documented in the UEPCM User’s Guide. The following API calling sequence must be conducted in order to initialize the module into the FIPS-Approved mode:  FIPSModuleContext()  FIPSModuleContext .cm_init() to perform the self-tests and turn the module into the FIPS-Approved mode Figure 3 and Figure 4 below shows the blade system on which UEPCM and its applications run. UEPCM runs on the blade SBCW located at slot 11 and blade SBCO located at slots 1-6 and 9-14. Figure 3: An Overview of a Blade System with the Front Door Open ©2011 ZTE corporation Page 13 of 22 Figure 4: An Overview of a Blade System with the Back Door Open 6.2. Rules of Operation The UEPCM will operate in a modifiable operational environment per the FIPS 140-2 definition. The following rules must be adhered to for operating the cryptographic module in a FIPS 140-2 compliant manner: 1. The Operating System shall be restricted to a single human operator mode of operation. The concurrent operators shall be explicitly excluded. 2. The Operating System authentication mechanism must be enabled in order to prevent unauthorized users from being able to access system services. 3. The module must run on a host with commercial grade enclosure and be physically protected as prudent in an enterprise environment. 4. All host system components that can contain sensitive cryptographic data (main memory, system bus, disk storage) must be located within a secure environment. 5. The unauthorized replacement or modification of the legitimate cryptographic module code is not allowed. ©2011 ZTE corporation Page 14 of 22 6. The application using the module services must utilize a separate copy of the module. 7. The address space of the module must be accessed only by a single process. 8. The unauthorized reading, writing or modification of the application address space which contains the module instance is not allowed. 9. All keys entered into the module must be verified as being legitimate and belonging to the correct entity by software running on the same machines as the module (e.g. the application of the module). 10. The application using the module must access to secret keys, private keys, or other sensitive material through the documented API. Bypassing the API to access any code or data belonging to the cryptographic module is forbidden. The above rules must be upheld at all times in order to ensure continued system security and FIPS 140-2 compliance after initial setup of the validated configuration. If the module is removed from the above environment, it is assumed not to be operational in the validated mode until such time as it has been returned to the above environment and re-initialized by the Crypto-Officer to the validated condition. It is the responsibility of the Crypto-Officer to configure the Operating System to operate securely and ensure that only a single operator may operate the module at any particular moment in time. ©2011 ZTE corporation Page 15 of 22 7. Cryptographic Key Management 7.1. Random Number Generator The UEPCM implements a FIPS-Approved SP800-90 based Deterministic Random Bit Generator (DRBG) (i.e. Hash_DRBG SHA-256). During initialization, the module obtains a seed and feeds the DRBG (using java.security.SecureRandom to generate the seed randomly, and the DRBG will be reseeded automatically after 1000000 times calls). The UEPCM ensures that the seed key is not identical to the seed, generating the seed key from the seed value hashed with SHA-256. UEPCM performs the continuous test to guarantee that every output is not identical to the previous one. 7.2. Key Generation The UEPCM uses an FIPS-Approved DRBG SP800-90 as inputs to create the following keys/CSPs:  RSA keys  DSA parameters and keys In the FIPS-Approved mode, the RSA/DSA parameters and key pairs are generated by FIPS-Approved RSA/DSA key generation algorithms. The UEPCM implements the RSA key generation in accordance with the algorithm described in ANSI X9.31, and DSA key generation in accordance with the algorithms described in FIPS 186-3. 7.3. Key Entry and Output The UEPCM module does not support manual key entry or intermediate key output. In addition, the module does not output keys/CSPs in plaintext format outside its physical boundary. 7.4. Key Storage The UEPCM, as a software library, does not provide any long-key storage. Keys used by the module are never stored on the hard disk. 7.5. Key Zeroization Key zeroization is performed via the following API calls:  Arrays.zeroization():zeroize the byte array.  DSA2Param.zeroization(): zeroize dsa pqg parameter. ©2011 ZTE corporation Page 16 of 22  SecureBigInteger.zeroization(): zeroize DSA2 public key and private key.  RSAPrivateCrtKeyParameters.zeroization(): zeroize RSA private key.  RSAKeyParameters.zeroization(): zeroize RSA public key.  KeyParameter.zeroization(): zeroize AES, TDES, HMAC key. 8. EMI/EMC The Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) properties of the UEPCM are not meaningful for the software library itself. Systems utilizing the UEPCM services have their overall EMI/EMC ratings determined by the host hardware platform. The tested platforms for FIPS 140-2 validation have FCC Class A ratings. ©2011 ZTE corporation Page 17 of 22 9. Self Tests The UEPCM module implements a number of self-tests to check proper functioning of the module. This includes power-up self-tests (which are also callable on demand) and conditional self-tests. The self-test can be initiated by calling the API function FIPSModuleContext.selfTests(). If the self-test is successful, then the module enters the FIPS-Approved operational state. Otherwise, the module enters an error state and returns an error code with applicable description of the error. Once the module is in the error state, API functions that perform cryptographic operations are not available (see Appendix A for the functions available in the error state) and no data output is possible from the module. When the module is performing self-tests, no API functions are available and no data output is possible until the self-tests are successfully completed. 9.1. Power-Up Tests The UEPCM module performs self-tests automatically when the API function FIPSModuleContext.cm_init() is called or on demand when the FIPSModuleContext.selfTests() is called. Whenever the power-up tests are initiated, the module performs the integrity test and the cryptographic algorithm Known Answer Test (KAT). If any of these tests fails, the module enters the error state. 9.1.1. Integrity Test The UEPCM uses FIPS-Approved algorithm HMAC based on SHA-256 for its integrity test. When UEPCM is built, a group of HMAC values are generated for each java class and saved in a fingerprint file mac, which is delivered with uepcm.jar to the UEPCM application developers. When UEPCM is initialized by its application, it calculates the HMAC value for each class and compares this newly generated HMAC value with the previously saved value. If all pairwise match, then the integrity test is successful. Otherwise, the UEPCM integrity test fails and no services and data outputs from UEPCM shall be available. 9.1.2. Cryptographic algorithm KAT Upon power-up, a KAT is performed for the following FIPS-Approved algorithms:  AES cbc, ecb, cfb8, cfb 128, ofb mode encryption/decryption;  Triple-DES cbc, cfb8, cfb64, ecb, ofb mode encryption/decryption;  RSA 1536 bits(SHA-224, SHA-256) PSS signature generation/verification  DSA (L=2048, N=224, SHA-224, SHA-256)signature generation/verification  SHA256_DRBG ©2011 ZTE corporation Page 18 of 22  SHA-224, SHA-256, SHA-384, SHA-512  HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512 9.2. Conditional Tests 9.2.1. Pair-wise consistency test The UEPCM module performs the pair-wise consistency test for each pair of RSA/DSA keys that it generates. The consistency of the key pair is tested by the calculation and verification of a digital signature. If the digital signature cannot be verified, the test fails. 9.2.2. Continuous test for DRBG The UEPCM module implements a continuous test for the DRBG SP800-90. The DRBG generates a string of random bits per request. The generated random bits is compared with the random value generated for the previous request. If the generated data for two requests are identical, a conditional test error flag is raised. ©2011 ZTE corporation Page 19 of 22 10. Design Assurance 10.1. Configuration Management The UEPCM module develop team utilizes Subversion (SVN), a software versioning and a revision control system, to maintain current and historical versions of files such as source code and design documentation that contribution to the UEPCM. SVN integrates several aspects of the software development process in a distributed development environment to facilitate project-wide coordination of development activities across all phases of the product development life cycle:  Configuration Management – the process of identifying, managing and controlling software modules as they change over time.  Version Control – the storage of multiple versions of a single file along with information about each version.  Change control – centralizes the storage of files and controls changes to files through the process of checking files in and out. The list of files that are relevant to the UEPCM module and subject to SVN control is detailed in the ZTE UEPCM component list document. 10.2. Guidance 10.2.1. Cryptographic Officer Guidance A Crypto officer uses the installation instructions provided in the ZTE UEPCM User’s Guide to install the module in their environment. To bring the module into FIPS-Approved mode, the crypto officer has to carry out the startup steps as specified in the ZTE UEPCM User’s Guide and follow the rules of operations as stated in Section 6 of this Security Policy. 10.2.2. User Guidance The ZTE application developers using the UEPCM services must verify that ownership of keys is not compromised, and keys are not shared between different users of the calling application. Note that this requirement is not enforced by the UEPCM itself. It is the responsibility of the application to provide the verified keys to the UEPCM. The ZTE application developers are referred to the ZTE UEPCM User’s Guide for details in regard to integrating UEPCM module into their applications. ©2011 ZTE corporation Page 20 of 22 11. Mitigation of Other Attacks No other attacks are mitigated. ©2011 ZTE corporation Page 21 of 22 12. Appendix A The module API functions are fully described in the ZTE UEPCM User’s Guide. The following is the list of the module API functions serving as a quick reference for the completion of this document. Y - Functions that can be performed in FIPS mode N - Functions that cannot be performed in FIPS mode. E - Functions that can be performed in error state. N FIPSModuleContext.FIPSModuleContext() FIPSModuleContext.cm_init() N FIPSModuleContext.cm_end() YE FIPSModuleContext.selfTests() YE FIPSModuleContext.getState() YE IntegrityTest.test() YE FIPSModuleContext.fips_AES_encrypt() Y FIPSModuleContext.fips_AES_decrypt() Y FIPSModuleContext.fips_TDES_encrypt() Y FIPSModuleContext.fips_TDES_decrypt() Y FIPSModuleContext.fips_SHA2_digest() Y FIPSModuleContext.fips_HMAC_digest() Y FIPSModuleContext.fips_SHA256DRBG() Y FIPSModuleContext.fips_RSA_genKeyPair() Y FIPSModuleContext.fips_RSA_genSignature() Y FIPSModuleContext.fips_RSA_verifySignature() Y FIPSModuleContext.fips_DSA2_GenPQG() Y FIPSModuleContext.fips_DSA2_verPQG() Y FIPSModuleContext.fips_DSA2_genKeyPair() Y FIPSModuleContext.fips_DSA2_genSignature() Y FIPSModuleContext.fips_DSA2_verSignature() Y Arrays.zeroization() YE SecureBigInteger.zeroization() YE DSA2Param.zeroization() YE RSAPrivateCrtKeyParameters.zeroization() YE RSAKeyParameters.zeroization() YE KeyParameter.zeroization() YE ©2011 ZTE corporation Page 22 of 22