HEWLETT ® PACKARD HPE OpenCall HLR Cryptographic Module I-HSS 01.08.01 FIPS 140-2 Non-proprietary Security Policy Version 2.3 2015-12-21 Open Call Business Unit HEWLETT ® PACKARD Hewlett-Packard 10810 Farnam Drive OMA01 Omaha, Nebraska 68154 TRADEMARKS or SERVICE MARKS The following are trademarks or service marks of Hewlett Packard Enterprise Corporation: HEWLETT PACKARD ENTERPRISE, HPE, OpenCall, OpenCall HLR. All other brand names and product names are trademarks or registered trademarks of their respective companies. COPYRIGHT This document may be freely copied and distributed without the Author's permission provided that it is copied and distributed in its entirety without modification. © 2015 Hewlett Packard Enterprise / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. HEWLETT ® PACKARD (This page left intentionally blank) © 2015 Hewlett Packard Enterprise / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. HEWLETT ® PACKARD Table of Contents TRADEMARKS or SERVICE MARKS ............................................................................................ ii COPYRIGHT ............................................................................................................................ ii 1. Introduction ....................................................................................................................... 1 1.1 Audience ................................................................................................................... 1 1.2 Product Description ................................................................................................... 1 2. Cryptographic Module Specification .................................................................................. 2 2.1 Module Overview ...................................................................................................... 2 2.2 FIPS 140-2 Validation ................................................................................................ 5 2.3 Modes of Operation ................................................................................................... 6 3. Ports and Interfaces........................................................................................................... 7 4. Roles, Services and Authentication ................................................................................... 8 4.1 Roles ......................................................................................................................... 8 4.2 Services .................................................................................................................. 10 4.3 Operator Authentication.......................................................................................... 14 5. Operational Environment................................................................................................. 15 5.1 Operational Environment Policy .............................................................................. 15 6. Physical Security ............................................................................................................. 16 7. Cryptographic Key and CSP Management ....................................................................... 17 7.1 Deterministic Random Bit Generator (DRBG).......................................................... 18 7.2 Key Generation ....................................................................................................... 19 7.3 Key Entry and Output.............................................................................................. 19 7.4 Key storage and Key Zeroization ............................................................................ 19 8. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) ........................ 20 9. Self-Tests ......................................................................................................................... 21 9.1 Power-Up Tests ....................................................................................................... 21 9.2 Conditional Tests..................................................................................................... 22 9.3 Continuous Tests..................................................................................................... 22 10. Design Assurance ............................................................................................................ 23 10.1 Configuration management .................................................................................... 23 10.2 Guidance ................................................................................................................. 23 10.2.1 Secure installation .......................................................................................... 23 10.2.2 Secrets distributions ....................................................................................... 24 10.2.3 Initialization and start-up ................................................................................ 24 10.2.4 Operational rules ............................................................................................ 24 11. Mitigation of Other Attacks .............................................................................................. 25 © 2015 Hewlett Packard Enterprise / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. HEWLETT ® PACKARD 12. Acronyms......................................................................................................................... 26 13. References ...................................................................................................................... 28 © 2015 Hewlett Packard Enterprise / atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. HEWLETT ® PACKARD 1. Introduction This document is the Federal Information Processing Standards (FIPS) 140-2 non-proprietary Security Policy for the HEWLETT PACKARD ENTERPRISE (HPE) OpenCall HLR Cryptographic Module to meet FIPS 140-2 security Level One requirements. This Security Policy details the secure operation of the HPE OpenCall HLR Cryptographic Module version I-HSS 01.08.01, developed by HPE as required in FIPS Publication 140-2 as published by the National Institute of Standards and Technology (NIST) of the United States Department of Commerce. The Federal Information Processing Standard Publication 140-2 (FIPS 140-2) is a U.S. government computer security standard used to accredit cryptographic modules. It was issued by the National Institute of Standards and Technology (NIST). 1.1 Audience This document is required as a part of the FIPS 140-2 validation process. It describes the HPE OpenCall HLR Cryptographic Module in relation to FIPS 140-2 requirements. The companion document "OpenCall I-HSS/HLR Installation Guide 1" provides the guidance for installing the the OpenCall HLR Cryptographic Module. The companion document "HPE OpenCall HLR Cryptographic Module User Guide1" is a technical reference for Service Providers using the OpenCall HLR Cryptographic Module. 1.2 Product Description The HPE OpenCall Home Location Register (HLR) is a centralized data repository of static and transient subscriber profile information that manages subscriber network access, availability, and location in wireless networks defined by European Telecommunications Standards Institute (ETSI). The ETSI-based HLR functionality is referred to as Global System for Mobile communications (GSM) and Universal Mobile Telecommunications System (UMTS). The Authentication Center (AuC) functionality present in the HPE OpenCall HLR ensures that only legitimate subscribers obtain access to the GSM/UMTS. The HPE OpenCall HLR protects sensitive subscriber data elements related to the information required to authenticate subscriber network access. The HPE OpenCall HLR Cryptographic Module provides the cryptography required to protect the sensitive subscriber data elements. FIPS 140-2 approved cryptographic algorithms (for example, AES-128 ECB) are used for cryptographic key protection, subscriber AV generation, and the protection of sensitive application data (for example, GSM/UMTS Ki values). The HLR/AuC Call Processing component uses subscriber keys in conjunction with FIPS 140-2 approved cryptographic algorithms to generate Authentication Vectors (AVs) for GSM/UMTS subscriber authentication. (An AV, in the context of this reference, is security context data that enables a UMTS/GSM wireless network to authenticate a UMTS/GSM wireless subscriber. The HPE OpenCall HLR utilizes a subscriber symmetric key present in both the HLR and the subscriber's user equipment (UE) to generate the authentication vector. The HPE OpenCall HLR and a Universal SIM (USIM) or Subscriber Identity Module (SIM) present in the UE contain the key value). 1 The reference document is provided with the module. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 1 HEWLETT ® PACKARD 2. Cryptographic Module Specification This section describes the module and its functionality as part of the larger product. 2.1 Module Overview The HPE OpenCall HLR Cryptographic Module (hereafter referred to as "the module" or simply "CM") is a multi-chip standalone software module running on a GPC. The module provides the cryptographic services (e.g. symmetric encryption and decryption, message digest, and SP800-90A random number generation) required to protect the sensitive subscriber data elements. The module is implemented as a shared library. The shared library defines the logical boundary as shown by the red box in the figure below. The HPE OpenCall HLR Cryptographic Module is comprised of the following files: libCMOD, keymgrx, libcrypt, libOSSL, libSSLF The following figure illustrates the HPE OpenCall HLR Cryptographic components. The figure references key material, key storage, utilities, and runtime components and depicts the relationships between the components and the OpenCall HLR Cryptographic Module. Please note that the database files are not part of the cryptographic module boundary and are shown in the Diagram 2-1 and Table 2-1 for reference. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 2 HEWLETT ® PACKARD Figure 2-1: OpenCall HLR Cryptographic Module The following table provides a brief summary of the components contained within the Open Call HLR CM depicted in Figure 2-1. Component Brief Description Data Key Material An encrypted file generated by the Management Keys Generation Utility. The OpenCall HLR application uses the file to securely install KEKs and Master Seed Keys into the Data Management Keys data file. Transport Key An encrypted file generated by the Management Keys Generation Material Utility. The OpenCall HLR application uses the file to securely install KEKs into the Transport Management Keys data file and the first entry in the Transport Encryption Keys data file. Management Keys Used to generate KEKs and Master Seed Keys for the Data Generation Utility Management Keys data file and KEKs for the Transport Management Keys and Transport Encryption Keys data files. Data Management Uses the Data Key Material to install KEKs and Master Seed Keys into Keys Utility the Data Management Keys data file. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 3 HEWLETT ® PACKARD Data Encryption Key Uses the active Master Seed Key from the Data Management Keys Generation Utility data file to generate cryptographic keys for the Data Encryption Keys data file. The utility uses the active KEK from the Data Management Keys data file to cover the generated cryptographic key stored in the Data Encryption Keys data file. Transport Uses the Transport Key Material to install KEKs into the Transport Management Keys Management Keys data storage component and the first entry in the Utility Transport Encryption Keys data storage component. Key Manager Distributes cryptographic keys, used to cover sensitive data attribute values, from the Data Encryption Keys data files. Also distributes cryptographic keys, used to cover sensitive data transmitted over the provisioning stream, from the Transport Encryption Keys file. Key Provisioning Manages the provisioning of subscriber AuC key values. AV Generation API Generates AVs for AuC related network traffic. CM Library Shared library which interfaces with the Key Manager to retrieve cryptographic keys and uses retrieved keys to encrypt and decrypt sensitive data elements stored in the Subscriber Data and SIM Data files as well as data elements transmitted over the provisioning stream. Also, provides routines that check the status of the CM module. Cryptographic Shared library which provides the cryptographic algorithms (e.g. AES Library and Secure Hash Algorithm (SHA)). Data Management A data file that contains KEKs and Master Seed Keys used to Keys respectively cover and generate cryptographic keys in the Data Encryption Keys data file. Data Encryption A data file that contains cryptographic keys used by application Keys components (e.g. HLR AC Call Processing) to protect sensitive data elements. Transport A data file that contains KEKs used to cover the cryptographic keys Management Keys stored in the Transport Encryption Keys data file. Transport Encryption A data file that contains cryptographic keys used to cover sensitive Keys data elements transported over the DPA provisioning stream. All cryptographic key entries cover sensitive data elements over the provisioning stream. Subscriber Data Legacy data file that contains sensitive data elements (e.g. K) SIM Data covered by a cryptographic key stored in the Data Encryption Keys data file. Table 2-1: Brief Component Description © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 4 HEWLETT ® PACKARD For the software module, the physical boundary is considered to be the surface of the case of the target platform as show below: Figure 2-2: Physical Boundary 2.2 FIPS 140-2 Validation For the purpose of the FIPS 140-2 validation, the module is a software-only, multi-chip standalone cryptographic module validated at overall security level 1. The table below shows the security level claimed for each of the eleven sections that comprise the FIPS 140- 2 standard: Security Component 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 © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 5 HEWLETT ® PACKARD EMI/EMC 1 Self Tests 1 Design Assurance 1 Mitigation of Other Attacks N/A Table 2-2: Security Levels Table 2-3 shows the platform on which the cryptographic module was tested on: Manufacturer Model O/S & Version Integrity NonStop BladeSystem HP HP NonStop v J06.18 NB54000c with Intel Itanium Processor Table 2-3: Platforms Tested 2.3 Modes of Operation When installed, the module only operates in FIPS approved mode. The module provides cryptographic services to applications running in the user space of the underlying operating system through an application program interface (API). The module interacts with the operating system via system calls. The GSM/UMTS functionality within the HPE OpenCall HLR can utilize the cryptographic module operating in FIPS 140-2 approved mode. The CM Library uses the data encryption key to either decrypt or encrypt data (for example, subscriber keys to generate AVs). To retrieve a new data encryption key, the Service Provider's personnel must configure the new system-level key index (Ki) and algorithm version values that the system uses as the basis for the generation of the new data encryption key. The following table shows the FIPS-Approved algorithms that are supported by the module: Algorithm/Modes Standard/Usage Key Lengths Certificate Number [SP800-38A] AES ECB, CTR 128 bits(ECB #3503 Encryption and modes only), 256 bits Decryption [FIPS180-4] SHA-1, SHA-256 N/A #2890 Message Digest [FIPS198-1] HMAC SHA-1 112 bits #2237 Message Integrity [SP800-90A] CTR_DRBG #872 Random Number Generation Table 2-4: FIPS-Approved Algorithms © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 6 HEWLETT ® PACKARD 3. Ports and Interfaces As a software-only module, the module does not have physical ports. For the purpose of the FIPS 140-2 validation, the physical ports are interpreted to be the physical ports of the hardware on which it runs. The logical interfaces are the application programming interface (API) through which applications request services (as show in the table below): Logical Description Interface API function calls, API input parameters for Control In control, CLI API return codes, API output parameters for Status Out status, CLI Data In API input parameters for data, CLI Data Out API output parameters for data, CLI Table 3-1: Ports and Interfaces The Data Input interface consists of the input parameters of the API functions data received through the I/O system calls, and CLI. The Data Output interface consists of the output parameters of the API, and CLI. The Control Input interface consists of the API function calls the input parameters and the CLI used to control the behavior of the module. The Status Output interface includes the return values of the API functions, status sent through output parameters, and the CLI. The CLI is the command line interface provided by the utilities listed in table 2-1. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 7 HEWLETT ® PACKARD 4. Roles, Services and Authentication 4.1 Roles This section contains a table that identifies the CM components and the CM roles that have access to or run the components. Note that the roles are actually associated with the role number and the role names contained in the table are for illustrative purposes only. # Role Description 1 Crypto Officer The Crypto Officer role has the ability to install, update, and destroy the CM components. Note that the Crypto Officer role cannot run any of the CM components. 2 FIPS Mode The FIPS Mode Manager role has the ability to use the FIPS Manager Indicator Utility to query the CM FIPS Mode indicator in the FIPS Info file as well as query and set the key limit threshold. 3 Management Key The Management Key Generation role has the ability to use the Generation Management Keys Generation Utility to generate data and transport management key material. 4 Data Management The Data Management Key Installation role possesses the ability Key Installation to use the Data Management Keys Utility to install data management keys in the Data Management Keys file and to re- encrypt entries in the Data Encryption Keys file with the latest Data Management Keys file KEK. The Data Management Key Installation role also has the ability to initiate the destruction of the Data Management Keys file. 5 Transport The Transport Management Key Installation role has the ability Management Key to use the Transport Management Keys Utility to install transport Installation management keys in the Transport Management Keys file, to install a KEK in the Transport Encryption Keys file default record, and to re-encrypt the entries in the Transport Encryption Keys file. The Transport Management Key Installation role also has the ability to initiate the destruction of the Transport Management Keys and Transport Encryption Keys. 6 Data Encryption The Data Encryption Key Generation role has the ability to use Key Generation the Data Encryption Key Generation Utility to generate Data Encryption Keys and place the generated keys in the Data Encryption Keys file. The Data Encryption Key Generation role also has the ability to initiate the destruction of the Data Encryption Keys files. 7 CM Operator The CM Operator role has the ability to run the Key Manager and © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 8 HEWLETT ® PACKARD # Role Description Transport Key Manager runtime processes. 8 Crypto Library The Crypto Library User role possesses the ability to use the User libraries associated with the CM and runs the FIPS Command Utility. Table 4-1: Cryptographic Module Roles The following table illustrates the capabilities of each role in regard to each OpenCall HLR component. The end of the table contains a legend that identifies the abbreviations used in the cells of the table. The numbers starting in column two of the header rows correlate with the role numbers specified in Table 4-1. Component/Role # 1 2 3 4 5 6 7 8 FIPS Info File PCRW RW R R R R RW R FIPS Status File PCRW R RW RW RW RW RW RW Data Management PCRW RW R RW Keys Data Encryption Keys PCRW RW RW RW Transport PCRW RW RW Management Keys Transport Encryption PCRW RW RW Keys Subscriber Data PCRW RW SIM Data PCRW RW Data Key Material WC RPC Transport Key Material WC RPC FIPS Indicator Utility PCRW E Management Keys PCRW E Generation Utility Data Management PCRW E Keys Utility Data Encryption Key PCRW E Generation Utility Transport Management Keys PCRW E Utility FIPS Command Utility PCRW E AuC Re-Encryption PCRW WE Utility Key Manager PCRW WE1 © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 9 HEWLETT ® PACKARD Component/Role # 1 2 3 4 5 6 7 8 CM Library PCRWE E E Cryptographic Library PCRW E E Key Provisioning PCRW E E AV Generation API PCRW E E R ­ Read File Content C ­ Create File W ­ Write, Delete, and Update File Content 1 ­ Restriction by executable E ­ Execute File P ­ Purge File and process name Table 4-2: Cryptographic Module Privileges by Role Note: The components listed in column one of Table 4-2 represent all of the components of the cryptographic module with the addition of supporting components which interface with the module. 4.2 Services The module provides services to users that assume one of the available roles. All services are described in detail in the user documentation. The following table shows the available services, the roles that can request the service, the Critical Security Parameters involved and how they are accessed: Service Service Function Role (Numbers CSPs Algorithm Ports from Table 4-1 I-In, O- Cryptographic Out Module Roles) C- Command D-Data S-Status CreateKey Create a key 3 AES 128 Key, AES, SHA- CI, DI, SO material file AES 256 DRBG 256, Seed Key SP800-90A CTR_DRBG DEKAdd Add a key to 6 AES 128 Key AES, SHA- CI, SO the Data 256 (Data Encryption Encryption Key Key Add) DB DEKClear Clears the I-HSS 1 AES 128 Key AES, SHA- CI, SO registration for 256 (Data Encryption specified key Key Clear) index and algorithm version DEKDeactivate Deactivate a 1 AES 128 Key AES, SHA- CI, SO key in the Data 256 © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 10 HEWLETT ® PACKARD Service Service Function Role (Numbers CSPs Algorithm Ports from Table 4-1 I-In, O- Cryptographic Out Module Roles) C- Command D-Data S-Status Encryption Key (Data Encryption DB Key Deactivate) DEKDestroy Destroy a key 1 AES 128 Keys N/A CI, SO from the Data (Data Encryption Encryption Key Key Destroy) DB DEKMigrate Migrate the 7 AES 128 Key AES, SHA- CI, SO keys in the 256 (Data Encryption Data Encryption Key Migrate) Key DB DEKReencrypt Re-encrypt the 4 AES 128 Key AES, SHA- DO, DI, CI, keys in the 256 SO (Data Encryption Data Encryption Key Reencrypt) Key DB DEKReport Reports the 6 N/A N/A DO, CI, SO keys in the (Data Encryption Data Encryption Key Report) Key database DEKUsageReport Reports the 1 N/A N/A DO, CI, SO references to a (Data Encryption Data Encryption Key Usage Key for a Report) specified Key Index and algorithm Version. DMKActivate Activate a key 4 N/A N/A CI, SO (or keys) in the (Data Data Management Management Key Activate) Key DB DMKAdd Add a key to 4 AES 128 Key AES, SHA- CI, DI, SO the Data 256 (Data Management Management Key DB Key Add) DMKDeativate Deactivate a 4 N/A N/A CI, SO key (or keys) in (Data the Data Management Management © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 11 HEWLETT ® PACKARD Service Service Function Role (Numbers CSPs Algorithm Ports from Table 4-1 I-In, O- Cryptographic Out Module Roles) C- Command D-Data S-Status Key Deactivate) Key DB DMKDestroy Destroy a key 1 AES 128 Keys N/A CI, SO from the Data (Data Management Management Key DB Key Destroy) DMKReport Reports the 4 N/A N/A DO, CI, SO keys in the (Data Data Management Management Key Report) Key database KMDestroy Destroy a key 1 AES 128 Key, N/A CI, SO material file DRBG Seed Key (Key Material Desrtroy) TEKAdd Add a key to 5 AES 128 Key N/A CI, SO the Transport (Transport Encryption Key Encryption Key DB Add) TEKDestroy Destroy a key 1 AES 128 Keys N/A CI, SO from the (Transport Transport Encryption Key Encryption Key Destroy) DB TEKReencrypt Re-encrypt the 5 AES 128 Key AES, SHA- DO, DI, CI, keys in the 256 SO (Transport Transfer Encryption Key Encryption Key Reencrypt) DB TEKReport Reports the 5 N/A N/A DO, CI, SO keys in the (Transport Transport Encryption Key Encryption Key Report) database TMKActivate Activate a key 5 N/A N/A CI, SO (or keys) in the (Transport Transport Management Management Key Activate) Key DB © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 12 HEWLETT ® PACKARD Service Service Function Role (Numbers CSPs Algorithm Ports from Table 4-1 I-In, O- Cryptographic Out Module Roles) C- Command D-Data S-Status TMKAdd Add a key to 5 AES 128 Key N/A DI, CI, SO the Transport (Transport Management Management Key DB Key Add) TMKDeactivate Deactivate a 5 N/A N/A CI, SO key (or keys) in (Transport the Transport Management Management Key Deactivate) Key DB TMKDestroy Destroy a key 1 AES 128 Keys N/A CI, SO from the (Transport Transport Management Management Key Destroy) Key DB TMKReport Reports the 5 N/A N/A DO, CI, SO keys in the (Transport Transport Management Management Key Report) Key database CM APIs Encrypt and 8 AES 128 Key AES, SHA- DI, DO, SO decrypt data 256 (via key index) FIPS Command Initiate Self- 8 N/A AES, SHA- CI, SO Utility Tests, Start and 1, HMAC- Stop Module SHA-1, SHA-256, AES based SP800-90A CTR_DRBG FIPS Indicator Get FIPS Status, FIPS_MODE_MGR 2, N/A N/A CI, SO Utility Alter/Query key limit threshold All roles Set up and Install module, 1 N/A N/A CI, SO Configure create files and 2 All roles can query the status but only the FIPS Mode Manager can alter the threshold for cryptographic keys that are about to expire. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 13 HEWLETT ® PACKARD Service Service Function Role (Numbers CSPs Algorithm Ports from Table 4-1 I-In, O- Cryptographic Out Module Roles) C- Command D-Data S-Status Module roles Table 4-3: Module Services 4.3 Operator Authentication The module does not implement authentication. The role is implicitly assumed based on the service requested. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 14 HEWLETT ® PACKARD 5. Operational Environment The module operates in a modifiable operational environment per the FIPS 140-2 specifications. 5.1 Operational Environment Policy · The OS shall be restricted to a single operator at one time (i.e., concurrent operators are explicitly excluded). · The applications that make calls to the CM are the single user of the CM, even when the application is serving multiple clients. · The OS enforces authentication methods to prevent unauthorized access to CM services · The applications using the module services consist of one or more processes in which each process is utilizing a separate copy of the instance data (no data is shared between instances). · This module is implemented in FIPS-approved mode only. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 15 HEWLETT ® PACKARD 6. Physical Security This module is a security Level One software module and offers no specific physical security as none is required. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 16 HEWLETT ® PACKARD 7. Cryptographic Key and CSP Management This section defines the cryptographic keys and Critical Security Parameters (CSPs) present in the system and how they are managed over their lifetime. Key/CSP Purpose Location Algorithm Creation/ Lifetime Destruction Type Input Data Encryption Data AES 128/ Locally Permanent in Destruction of KEK or Encryption Key (EK) Encryption SHA-256 generated, or encrypted record containing Keys Key DB imported via storage, Key an encrypted ephemeral and file and zeroized after shared key use when in plaintext Transport Encryption Transport AES 128/ Locally Permanent in Destruction of KEK or Encryption Key (EK) Encryption SHA-256 generated, or encrypted record containing Keys Key DB imported via storage, Key an encrypted ephemeral and file and zeroized after shared key use when in memory Data KEK Data AES 128/ Manually Permanent in Destruction of record Management Management SHA-256 input obfuscated containing Key Key Key DB plaintext storage, ephemeral and zeroized after use when in memory Transport KEK Transport AES 128/ Manually Permanent in Destruction of record Management Management SHA-256 input obfuscated containing Key Key Key DB plaintext storage, ephemeral and zeroized after use when in memory Data DRBG Seed Data AES-128/ Manually Permanent in Destruction of KEK or Management Management SHA-256 input obfuscated record containing Master Seed Key DB for plaintext Key Key integrity storage, and AES- ephemeral and 128 for use zeroized after in use when in SP800-90A plaintext CTR_DRBG SIM Data CSP SIM Data DB AES-128/ Imported via Permanent in Destruction of KEK or SHA-256. encrypted file encrypted record containing and shared storage, Key key ephemeral and zeroized after use when in plaintext © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 17 HEWLETT ® PACKARD Subscriber CSP Subscriber AES-128/ Imported via Permanent in Destruction of KEK or Data (used Data DB SHA-256. encrypted file encrypted record containing for AV and shared storage, Key generation) key ephemeral and zeroized after use when in plaintext SP 800-90A symmet- RAM for the SP800-90A Derived on Ephemeral and Automatically DRBG CSPs ric keys, lifetime of CTR_DRBG use zeroized after destroyed after use and DRBG use (seed, V) random instance number genera- tion HMAC-SHA-1 HMAC- Executable HMAC-SHA- Embedded at Plaintext N/A keys for SHA-1 file headers 1 file creation integrity keys checking HMAC-SHA-1 HMAC- Management HMAC-SHA- Derived on Obfuscated Destruction of record keys for SHA-1 Keys DB 1 use Plaintext containing Key integrity keys checking Table 7-1: Keys and CSPs 7.1 Deterministic Random Bit Generator (DRBG) The module uses a hardware source of entropy to seed an approved DRBG. The continuous test is performed on both the seed source and the DRBG (SP800-90A AES-256 Counter (CTR) Mode) output. Additionally, the DRBG performs the health checks specified in section 11.3 of SP 800-90A, including: · Known Answer Tests · Instantiate Function Test · Generate Function Test · Reseed Function Test The module uses NDRNG from the operational environment as the source of random numbers for DRBG seeds. The entropy source is outside the logical boundary of the software module but inside the physical boundary of the platform on which the software module is executed. The strength provided with each request from the NDRNG to seed the AES-256 CTR_DRBG is 384 bits. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 18 HEWLETT ® PACKARD 7.2 Key Generation AES keys are the only keys generated and are created using a SP800-90A compliant AES- 256 CTR DRBG approved random number generator per FIPS 140-2 IG 7.8 Approved key generation method. 7.3 Key Entry and Output Keys may be manually entered into the module in plaintext locally from the console terminal only. Those keys that are manually entered must be entered twice to verify integrity as required in FIPS 140-2 section 4.9.2. Keys may also be imported via an encrypted file under a shared key. 7.4 Key storage and Key Zeroization Persistent keys are always stored in files which are SHA-256 hashed and encrypted (with the exception of the master keys which are stored as obfuscated plaintext). The master keys may be zeroized by using the Destroy commands (please see Table 4-3 for the Destroy commands); this effectively zeroizes all stored keys since the remaining keys are in files which were encrypted under the now zeroized master keys. Ephemeral keys in memory are zeroized immediately after use. The individual record containing a key may also be erased. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 19 HEWLETT ® PACKARD 8. Electromagnetic Interference/Electromagnetic Compatibility (EMI/EMC) The test platform that runs the Module meets the requirements of 47 CFR FCC PART 15, Subpart B, Class A (Business use). © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 20 HEWLETT ® PACKARD 9. Self-Tests The HPE OpenCall components designated as part of the cryptographic module performs self-tests compliant with FIPS 140-2 Security Level One as described in section 4.9 of reference [2]. FIPS 140-2 security Level One compliance requires HPE to provide the ability to use power- up tests and conditional tests to validate the HPE OpenCall HLR CM components present in the Service Provider's environment. If any instance associated with the CM fails the self-tests, the entire CM will enter the error state and post an error message via the FIPS Indicator Utility indicating that the CM is the error state. The CM will not provide cryptographic services while in the error state. The CM will also post a notice that can be automatically sent to subscribing administrators. The FIPS Indicator Utility queries the FIPS 140-2 Mode Indicator value, and the Crypto period Expiration Warning Threshold, which is present in the FIPS Info data file. The FIPS Command Utility interfaces with runtime Cryptographic Module (CM) components to initiate self-tests compliant with FIPS 140-2 Security Level One. It also queries the FIPS Status file to obtain the CM status. CM status provides information as to whether the components within the CM can provide cryptographic services. The utility presents the results of the initiated self-tests and the CM status query to the user. The FIPS Command Utility Self-Test can act upon a categorical runtime component (e.g., provisioning or call processing) or the cryptographic module as a whole. 9.1 Power-Up Tests The power-up tests that apply to the HPE OpenCall HLR Cryptographic Module include the cryptographic algorithm test, the software integrity test, and the critical functions test. The HPE OpenCall HLR Cryptographic Module performs cryptographic algorithm Known Answer Tests (KAT) without user interaction to ensure the proper functioning of the encryption algorithms utilized by the HLR CM. The following table shows the known answer tests (KAT) performed: Algorithm Test AES · AES ECB, encryption/decryption tested separately SHS · KAT SHA-256 HMAC · KAT HMAC-SHA-1 DRBG · KAT AES-256 CTR_DRBG Table 9-1 ­ Self-Tests © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 21 HEWLETT ® PACKARD Integrity verification is performed as part of power up tests. During build time, the HMAC-SHA-1 value of the keymgrx executable, libCMOD, libcrypt, libOSSL, and libSSLF libraries are calculated and embedded in the cryptographic module. At load time the power-up tests are initiated by the module. The integrity test will compute the HMAC-SHA-1 of the module and compare them to the values generated during build. If the compared values differ, the module enters the error state. Once the module is in error state, all the cryptographic operations are prohibited and the only way to recover from this state is to reboot the module. 9.2 Conditional Tests The conditional tests that apply to the HPE OpenCall HLR Cryptographic Module include the software load test, the manual key entry test, and the continuous random number generator test. Note that part of the implementation of this feature will involve an effort to determine any differences between the software load test specified as part of the conditional test and the software integrity test included as part of the power-up tests. 9.3 Continuous Tests The standard FIPS 140-2 required continuous test is performed during operation on both the seed source and the DRBG. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 22 HEWLETT ® PACKARD 10. Design Assurance The HPE OpenCall HLR team adheres to internal coding practices defined for use by the HPE OpenCall HLR team. The software associated with the HPE OpenCall HLR Cryptographic Module is isolated into specific software packages. APIs associated with the CM module provide external access to the cryptographic functions associated with the CM. The software in the CM does not share global data between CM module components or CM module components and entities external to the CM. The software associated with the CM is either of block-structured or object oriented structure. The software is written in C or C++ and compiled with a C++ compiler. The structure of the software is hierarchical. The software associated with the CM exists at a specific level (e.g. software package) in the overall software hierarchy. The functions and classes associated with the software perform specific tasks. Software developed for the HPE OpenCall HLR Cryptographic Module undergoes unit and independent-level testing. 10.1 Configuration management HPE uses CollabNet to manage the software associated with the HPE OpenCall HLR Cryptographic Module. CollabNet is a leader in collaborative software development and the organization that supports the HPE software management website. CollabNet utilizes the CollabNet Enterprise Edition (CEE) software, which in turn utilizes the Subversion software configuration management (SCM) tool. The CollabNet hosted solution encrypts all data stored on the external configuration management website. The encryption occurs on the database level and restricts data access to the CEE interface. The CEE limits software accessibility to users given visibility to the data stored on the website. Examples of accessibility range from read-only access to full read and write access with additional access limitations associated with groupings of software. The configuration management structure of the HPE OpenCall HLR software, including the CM, involves supporting a main thread of software referred to as a trunk and branching from the trunk in order to support and manage releases of the HPE OpenCall HLR software. An HPE OpenCall HLR configuration management group manages branches associated with software provided for use by HPE customers. 10.2 Guidance 10.2.1 Secure installation The module is provided with detailed instructions. For complete installation instructions please see companion document: "OpenCall I-HSS/I-HLR Installation Guide" © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 23 HEWLETT ® PACKARD 10.2.2 Secrets distributions It is required that the customer will not synchronize the Data and Transport Management Keys files if they intend to operate the HPE OpenCall HLR in a FIPS 140-2 Security Level One compliant mode. The synchronization of the files, which are protected by obfuscating plain text cryptographic keys, creates a scenario that does not meet FIPS 140-2 Security Level One compliance. Rather the Data and Transport Management Keys must be manually entered at the console of each system. 10.2.3 Initialization and start-up The module is provided with accompanied documentation that provides detailed information for complete installation instructions please see: "OpenCall I-HSS/I-HLR Installation Guide" 10.2.4 Operational rules 10.2.4.1 The FIPS Status file must not be edited or modified manually. 10.2.4.2 Disabling Directory Browsing The HPE HLR/AuC DPA provisioning will ensure that directory browsing is disabled prior to accepting HLR/AuC provisioning requests. See OpenCall I-HSS/I-HLR Installation Guide for instructions. 10.2.4.3 A firewall should be installed and configured to prevent unauthorized network access. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 24 HEWLETT ® PACKARD 11. Mitigation of Other Attacks No additional mitigations will be employed. © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 25 HEWLETT ® PACKARD 12. Acronyms AES Advanced Encryption Standard API Application Programming Interface AuC Authentication Center AV Authentication Vector CEE CollabNet Enterprise Edition CLI Command Line Interface CPU Central Processing Unit CM Cryptographic Module CSP Critical Security Parameter CTR Counter DB Database DPA Dynamic Provisioning Architecture DRBG Deterministic Random Bit Generator ECB Electronic Code Book EK Encryption Key EMC Electromagnetic Compatibility EMI Electromagnetic Interference FIPS Federal Information Processing Standards GSM Global System for Mobile Communications GUI Graphical User Interface HMAC Hash Message Authentication Code HLR Home Location Register HP Hewlett Packard HPE Hewlett Packard Enterprise IETF Internet Engineering Task Force KAT Known Answer Test KEK Key Encryption Key Ki Key Index NIST National Institute of Standards and Technology SCM Software Configuration Management SHA Secure Hash Algorithm © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 26 HEWLETT ® PACKARD SHS Secure Hash Standard SIM Subscriber Identity Module SP Security Policy UMTS Universal Mobile Telecommunications System USIM Universal SIM © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 27 HEWLETT ® PACKARD 13. References The following references were utilized in preparing this SP. 1. HP, "FIPS 140-2 Security Level One Compliance FRS," v3.6, March 26, 2010. 2. FIPS 140-2, "Security Requirements for Cryptographic Modules," May 25, 2001. 3. OpenCall I-HSS/HLR Installation Guide, Release ID: I-HSS 01.08.00, September 8, 2015. 4. HLR Security Administrators Guide, Release I-HSS 01.08.00, August 2015. 5. NIST, "Implementation Guidance for FIPS PUB 140-2 and the Cryptographic Module Validation Program," Initial Release: March 28, 2003, Last Update: August 8, 2015. 6. FIPS 180-4, Secure Hash Standard (SHS), March 2012 (link) 7. FIPS 198-1, The Keyed Hash Message Authentication Code (HMAC), July 2008 (link) 8. NIST Special Publication 800-21, "Guideline for Implementing Cryptography In the Federal Government," December 2005 (link) 9. NIST Special Publication 800-38A, "Recommendation for Block Cipher Modes of Operation Methods and Techniques", December 2001 (link) 10. NIST Special Publication 800-57, "Recommendation for Key Management ­ Part 1: General (Revised)," March, 2007. 11. NIST Special Publication 800-90A ­ "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", January 2012 (link) 12. IETF "Keyprov Status Pages" (http://tools.ietf.org/wg/keyprov/) © 2015 Hewlett Packard Enterprise /atsec information security. This document can be reproduced and distributed only whole and intact, including this copyright notice. 28