IBM 4768 PCIe Cryptographic Coprocessor with Common Cryptographic Architecture (CCA) PCI-HSM Security Policy

Transcription

1 IBM 4768 PCIe Cryptographic Coprocessor with Common Cryptographic Architecture (CCA) PCI-HSM Security Policy Version 1.11 July 19, 2018 This document may be reproduced only in its original entirety without revision.

2 CONTENTS 1 Introduction Terms and Definitions Overview of the System overview Hardware Internal components and design Tamper sensing and response Physical ports and interfaces Cryptographic algorithms provided by the HSM hardware Random number generation HSM Serial Number and other card information Firmware Updating the HSM firmware CCA (Common Cryptographic Architecture) firmware and functions The IBM HSM manufacturing process Operating environment Maintenance and Repair Development environment and controls Ensuring reliability of the HSM Self-testing Ensuring integrity of the HSM firmware Keys and other CSPs (Critical Security Parameters) Compliance-Tagged CCA keys Key Management Overview of key management using CCA Key Management Techniques Clarification of CCA key management and the Master / Session key management scheme Key Archival Financial PIN Processing Domains and virtualization of the HSM IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

3 10 Access Control for API functions and Administration Access Control for PCI-HSM Compliant Mode Logging of Security-Relevant Events Receiving, validating, and initializing the HSM Validating the integrity and origin of the HSM Verifying the HSM model and serial number Overview of 4768 authentication subsystem Authenticating the HSM in a customer system Ensuring HSM firmware levels meet PCI-HSM requirements Configuring access control Loading CCA Master Keys PCI-HSM Compliant Operation PCI-HSM Compliant Mode HSM modes Migration to a PCI-HSM compliant mode of operation Warn Mode Migration Mode Configuration for PCI-HSM compliance Decommissioning the HSM Moving the HSM References Annex A. Key Table From Evaluation Vendor Questionnaire IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

4 FIGURES Figure 1: Example SE display of firmware hash information... 8 Figure 2: Example of Crypto Module information from TKE... 9 Figure 3 - System overview Figure 4 - IBM 4768 Hardware Security Module (HSM) Figure 5 - Crypto Express6S Figure Hardware Block Diagram Figure Firmware Layers Figure 8 - Use of CCA operational keys Figure 9: Example CCA key hierarchy Figure 10: Master / Session key management using CCA Figure 11 - Example of mapping HSM domains to host LPARs Figure 12 - Example of Roles and User Profiles Figure 13 - TKE display of secure log record data Figure 14 - TKE Administration Overview Figure 15- Operational modes of the 4768 HSM Figure 16 - Wire to cut to zeroize the HSM IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

5 TABLES Table 1- Required Hardware and Firmware levels... 7 Table 2: Summary of hardware ports and interfaces Table 3 - Algorithms supported by CCA in the 4768 HSM Table 4 - Critical Security Parameters (CSPs) Table 5: Permitted PIN Translations Table 6: Keys in the HSM IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

6 REVISION HISTORY Date of revision Document version Author Description of changes 05/24/ Todd Arnold Remove 24 hour timeout on migration mode it was not implemented in the code. 06/13/ Todd Arnold Modifications according to review suggestions from Richard Kisley. 04/30/ Todd Arnold Updates related to evaluator feedback. 05/23/ Todd Arnold Additional info. and clarification on verifying firmware versions. 06/05/ Todd Arnold Update version number to 1.0 for the first released version, as requested by the evaluation agency. 06/07/ Todd Arnold Additional details added at the request of the evaluation agency. 07/19/ Todd Arnold Replaced the key table in Annex A with the updated version in the Vendor Questionnaire document. 6 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

7 1 INTRODUCTION This document is the Security Policy for the IBM 4768 PCIe Cryptographic Coprocessor, which is called the Crypto Express6S (CEX6S) when used in an IBM z System server. The document describes the HSM and its use in relation to the requirements defined in the PCI Security Standards Council PCI-HSM standard [1]. It is specific to the following 4768 hardware and firmware levels. Two different versions of the HSM hardware are certified, as indicated in the table below. Both versions of the hardware use identical firmware in Segments 1, 2, and 3. 1 Hardware (either version shown is acceptable) Firmware Segment 1 (either version shown is acceptable) Identifier P/N 01PP167 - or P/N 01KU719 Overall version: 6.0.8z POST 1: 0660 MB 1: 0660 POST 2: 0651 FPGA: F08A8 Overall version: z POST 1: 0662 MB 1: 0663 POST 2: 0652 Other This version identifier covers both the hardware itself, and the Segment 0 firmware, which is considered part of the hardware and cannot be updated once the card is manufactured. Hash is: 6BD50E94801E10C62183A7C2308D68FE 2B0A5A245EBC5045F5B27F72817AC02E FC0A CB301199A29B181120D2 6DEDE301AF2E8A3493DDAC7CE6B60AD4 Hash is: D608BCADEC5513FDA6F6A02603F241C9 DD935178B2D F7BBCBE B07353F3C096B56BBC137D1FB E0AA547400A2F012620DB5AEB7 FPGA: F08A8 Firmware Segment *z Any release beginning with 6.0 and ending in z is certified. The * reflects minor bug fix versions that may be released. Firmware Segment *z Any release beginning with 6.0 and ending in z is certified. The * reflects minor bug fix versions that may be released. Table 1- Required Hardware and Firmware levels Note that the Segment 2 and Segment 3 identifiers ending in z indicate a version of the firmware built for use in the IBM Z mainframe servers. The general format of firmware version identifiers is V.R.Ms, where V, R, M, and s are as follows: V is the major version. This changes with each new model of the HSM, but is constant over the life of a given HSM model. R is the release. This changes for each full release, which generally includes major functional enhancements. M is the modification level. This changes for each build of the firmware within a given release. s is a suffix character, which contains information about the platform where this version is intended to run, and the certification status. For example, the suffix z shown in the table 1 The firmware segments are described in Section IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

8 above indicates that the firmware is to be used in the IBM Z mainframe platform, and that the firmware is a version that is certified under PCI-HSM. The hardware and firmware levels of your HSM are shown on the Crypto Module panel on the TKE workstation [2]. For Segment 1, you should verify that you have an approved version by comparing the listed hash value with the one for the HSM in your system. These hash values can be displayed using the Support Element as described in reference [10]. Use the Cryptographic Details option under the Cryptographic Configuration window. Figure 1 shows an example of the SE display of this information. The Segment 1 hash information is highlighted. Figure 1: Example SE display of firmware hash information 8 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

9 Figure 2 shows an example of the TKE display of Crypto Module information. Figure 2: Example of Crypto Module information from TKE The supporting software in the host system must be compatible with these levels of HSM firmware, although that host software has no bearing on the security of the HSM. In addition, security administration for the HSM must be performed using the IBM TKE administrative workstation, and the TKE hardware and software must be a level that provides support for the PCI-HSM features of the HSM. This requires use of TKE version 9.0 or higher. Relevant functions of the TKE are described in other sections of this document. The IBM 4768 cryptographic coprocessor is a Hardware Security Module designed to provide secure processing for application programs in a host computer system. The module provides a rich set of Application Program Interface (API) functions which the host system can invoke to perform such functions as basic cryptographic algorithms, key management, finance-industry cryptographic algorithms, and others of that type. The 4768 can be used in a variety of host server computer types and operating systems. The 4768 is designed to meet NIST FIPS at security Level 4. That certification is currently in progress. The function of the 4768 is dependent on the firmware that is loaded into it. This document specifically addresses the 4768 when it is loaded with the IBM Common Cryptographic Architecture (CCA) firmware. CCA provides APIs (called verbs) to the host system for both general-purpose cryptographic functions and for the specialized functions that are required for use by banking applications such as payments systems. 9 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

10 This document describes the relevant characteristics of the 4768 for use in a manner compliant with the PCI-HSM standard version 3.0. It describes the 4768 hardware and firmware, as well as the methods to administer and use the HSM in a manner compliant with the standard. For information on the lifecycle of the 4768 HSM and the related actions that are required, see Reference [3]. 10 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

11 2 TERMS AND DEFINITIONS The following terms are used in this document and may not be familiar to all readers. API Application Programming Interface, a set of functions and parameters that a program can use to obtain services from a device or software module. ASIC Application-Specific Integrated Circuit, an integrated circuit chip that is custom-designed for a specific purpose. BBRAM Battery Backed Random Access Memory. This is static RAM that is powered by a battery when the HSM is powered off, so that the memory contents are retained. CCA Common Cryptographic Architecture, the API set used for the 4768 HSM in the context of this document. CRC Cyclic Redundancy Code, a mathematical code used to compute a value that is used to verify the integrity of a block of data. CSP Critical Security Parameter. Security-related information such as cryptographic keys or user passwords whose disclosure or modification can compromise the security of a cryptographic module. ECC Error Correcting Code, a value that is computed for a data element in computer memory that can detect when the data has been changed, and can correct errors of a limited length. Firmware computer software which runs inside a hardware device and is not directly seen by the end user of the device. FPGA Field Programmable Gate Array, a type of electronic logic device in which the functions of the hardware can be programmed and changed to give flexibility and to allow introduction of new functions. HSE High-Speed Erase, a type of memory that can be erased extremely quickly in order to destroy the data it contains. MCPU Module CPU, the term used to describe the microprocessors in the 4768 HSM that process the CCA API requests that come from the host computer system. Operational Key a CCA key that is used by an application program to perform an application-oriented cryptographic operation in the HSM. PCIe Peripheral Component Interconnect Express, the name of the interface bus technology that is used to connect the 4768 HSM card to the host computer system in which it resides. See [4]. POST Power On Self Test, the set of self-tests that are executed by a device when it is powered on, in order to determine that the device is functioning properly. RNG Random Number Generator, or Random Number Generation. A hardware component or software module that generates numbers that are random, or which appear to be random. 11 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

12 RTC Real Time Clock. Circuitry that contains timing counters that keep track of the current time and date. SE Support Element. On z System servers, the SE is a dedicated computer with a keyboard and display that is used for operating and monitoring the system. The SE is integrated into the server and is not a separate, remote device. See Reference [5]. SSP Security Service Processor, the microprocessor in the 4768 HSM that performs and secures service operations, such as the loading of new HSM firmware. TKE Trusted Key Entry, a specialized workstation that is used to securely administer the 4768 HSMs when they are used in IBM z Systems servers. Details on the function and use of the TKE are in Reference [2]. 12 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

13 3 OVERVIEW OF THE System overview The 4768 card receives request messages from programs in the host computer system, executes the specified operation, and returns a reply message with the result of the operation. The messages are transmitted over the PCIe bus through a host device driver. Application programs request functions using the CCA API. They specify the function using a high-level API, which is processed by a CCA library in the host system in order to create the low-level messages that are transmitted to the HSM card. Utility programs provided with the HSM will sometimes use the CCA API, and will sometimes communicate directly with the device driver, depending on the operation to be performed. Figure 3 - System overview 3.2 Hardware The 4768 HSM is an adapter card which plugs into the PCIe (PCI Express) bus of a host computer system. It provides cryptographic services to programs running in the host computer system via API functions that those programs can call. API requests are converted into request messages that pass over the PCIe bus to the 4768, where they are executed using a combination of hardware and firmware (embedded software). The 4768 creates a response message which is transferred back to the host system, and the results are returned to the program that invoked the API. 13 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

14 The photograph in Figure 4 shows the 4768 card, which is a full-height, half-length PCIe card. The Secure Module is a tamper-responding module which contains all of the security-relevant components, including memory, microprocessors, and cryptographic algorithm implementations. The batteries provide power to the non-volatile RAM memories and to power the tamper detection and response circuits when the card is not in a powered-on server. The PCIe bus interface connectors are the interface the HSM uses to communicate with the host computer. Figure 4 - IBM 4768 Hardware Security Module (HSM) In the IBM z System servers, the 4768 card plugs in to a carrier module which then plugs in to the server bus. This is shown in the photograph in Figure 5, where you can see the 4768 card at one end of the carrier module. The carrier has no cryptographic functions of its own; it is strictly a pass-through between the server bus and the PCIe bus of the 4768, as well as a way for the server to power the card on and off when needed. 14 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

15 Figure 5 - Crypto Express6S Note that maintenance of the z System servers is performed by IBM Customer Engineers (CEs) and not by the customers themselves. Thus, operations such as physical installation or removal of the Crypto Express6S (4768) are performed by the CE at the request of the customer Internal components and design Figure 6 shows a high-level block diagram of the 4768 HSM hardware. Figure Hardware Block Diagram 15 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

16 The diagram represents the functional blocks inside the 4768 at a high level. Many electronic functions are in a single custom ASIC (Application Specific Integrated Circuit) which is shown as a smaller shaded block in the card. The functional blocks that are shown have the following purposes. The PCIe interface at the left side is the interface the HSM uses to communicate with the host computer in which it is installed. The USB interface at the bottom is not used for any functional purpose. It is possible for firmware in the HSM to use the USB port, but standard IBM firmware specified as the target of this Security Policy does not use it. The MCPU is the Module CPU. This is the main microprocessor system that executes the API functions requested by host application programs. For high reliability and error detection, there are two identical MCPU processors which run identical firmware and process the same data. Cross-checking logic compares the operation of the two microprocessors at every cycle in real time, ensuring that any transient or hard error in either one will be detected. The SSP is the Security Service Processor. This is a separate microprocessor which performs service tasks such as loading and validating of new firmware and managing low-level keys the HSM uses to prove its validity and integrity. It does not participate in the processing of API functions requested by the host computer. The Cryptographic Engines are a set of hardware engines that implement cryptographic algorithms used in the HSM. This includes symmetric encryption algorithms like AES and Triple- DES (TDES), public-key algorithms like RSA and Elliptic Curve, and hashing algorithms like SHA-2. The engines also include a hardware-based prime number generator that is used for purposes such as the large prime numbers required in RSA keys. The RNG is a Random Number Generator. Hardware in this block includes a true random number source used to generate seed values, and a NIST SP A [6] compliant deterministic random number generator (DRNG) that is used to generate the random values used in HSM cryptographic API functions. The Tamper Controller is a separate hardware block used to operate the tamper sensors and to respond to tamper events. It is operated on battery power when the HSM is not powered from its host computer. The HSM uses several types of memory. Non-volatile memory is provided in three forms, Flash, Battery-backed Static RAM (BBRAM), and HSE-BBRAM. The HSE-BBRAM is a special, small SRAM contained in the tamper controller, and it can be erased extremely rapidly when a tamper is detected. HSE-BBRAM is used to store CSPs that must be zeroized immediately when a tamper occurs. In combination, these non-volatile memories are used to store both firmware (code) and persistent data. Runtime storage is provided by Synchronous DRAM (SDRAM). The RTC is a real-time clock which maintains the date and time. It is powered by the batteries when the card is not powered from its host computer. The expansion FPGA (field-programmable gate array) is a programmable hardware component which can be used to add new hardware features to the HSM over time. Programming for the 16 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

17 FPGA is loaded using the same cryptographically-authenticated, integrity-protected method that is used to load the HSM firmware. Hardware blocks components from accessing data to which they are not authorized. For example, the SSP maintains keys that it can use, but which cannot be accessed by the MCPU. The design ensures that no firmware layer can access or alter the sensitive data of any lower-level (and thus higher security) layer Tamper sensing and response The 4768 has self-contained tamper detection and response technology, designed to meet the stringent requirements of FIPS Level 4. Certification to that standard is currently in progress. The technology is similar to that used in predecessor IBM HSM cards, which all achieved FIPS 140 Level 4 certification. Following a tamper event, the 4768 renders itself permanently inoperable. The only functions it will perform after tamper are diagnostic functions which allow engineers to determine the cause of the tamper and to perform other forensic analysis if required. These functions do not provide any way to recover any sensitive information from the card. The electronic components of the secure module are enclosed in a tamper-sensing mesh, which is continuously monitored for any disturbance. Other sensors monitor temperature in the module and voltages from power supplies and from the battery. Any conditions that appear to be an attack result in immediate destruction of cryptographic keys and other sensitive data inside the HSM. Information in the HSE-BBRAM (see section 0) is zeroized within 100 ns. Sensitive information stored in other memories is encrypted with keys stored in HSE-BBRAM, and thus is rendered permanently unrecoverable in that same amount of time. If the sensors determine that the HSM is outside of its reliable operating limits, such as temperature or voltages above or below the acceptable ranges, the tamper monitoring circuitry immediately puts the HSM electronics into a reset state. It will not operate until the conditions return to acceptable parameter values. Once the reset is lifted, the HSM resumes operating normally. The 4768 is entirely self-protecting and there is no need for visual inspection to determine if tampering has occurred Physical ports and interfaces The primary interface for the 4768 is the PCIe bus which connects it to the host computer. This is the only interface that is used during normal operation of the HSM. It is used for all communication with application programs that make use of the HSM functions, and it is also used for administration and key management. The 4768 has three other hardware communications ports, one USB port and two RS-232 serial ports 2. The serial ports are used only for hardware debug by the IBM engineering team, and are not accessible 2 The two RS-232 ports share a single physical connector. 17 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

18 once the card is fully manufactured. They cannot be used to access any sensitive data or to influence the sensitive operations of the HSM. One of the serial ports is connected to the MCPU microprocessors in the HSM, and the other is connected to the SSP microprocessor. The USB port is not used when the HSM is operating with the PCI-HSM compliant firmware, and in the z System servers, the USB port is entirely blocked and is not accessible. There is also an interface for connection to an external switch that is used to indicate when the HSM has been physically removed from a server. This is called the intrusion latch, but it must not be confused with the tamper-response intrusion sensors on the HSM; it is not part of the intrusion detection system that detects attempts to penetrate the HSM itself. When the external switch is activated, a non-volatile latch is set inside the HSM, which can be interrogated by HSM firmware. When the firmware detects that this latch is set, it clears all CCA sensitive data such as master keys The messages over the PCIe bus are logically separated into control input, data input, status out, and data out. Power is supplied to the HSM card over PCIe bus pins that are physically separate from those used for message communications. The PCIe interface can be used in two different ways to request cryptographic operations in the HSM. Most requests send commands to the MCPU microprocessor, which determines what operation has been requested and performs that operation using a combination of firmware and hardware. A much more specialized set of commands can use what is called Accelerator Mode, in which simple cryptographic functions can be sent directly to the hardware cryptographic engines in the HSM. This provides faster performance, but with a very small set of functions. Accelerator Mode cannot use financial (PCI-HSM compliant) keys; it only accepts plaintext keys. Summarizes the ports and hardware interfaces and their use. Port Description Use and Comments PCIe bus 4 lane X4 PCIe bus. The HSM plugs into a PCIe slot on the host computer. Used for communications between the host computer and the HSM. Used to send commands (control) and data to the HSM, and to receive status and reply data from the HSM. Also provides power to Serial ports USB port Intrusion Latch Two serial ports, one connected to the MCPU processor in the HSM and one connected to the MCPU. Bidirectional USB port. May tunnel other signals (such as Ethernet-over- USB). Connection to an external signal that can be used to detect when some the HSM. Used for status output during power-on sequence and for hardware error information. Not used for input to the HSM. Not accessible when the HSM is installed for normal use; serial ports are blocked when HSM is in the host computer. Not used by IBM firmware. Not accessible when the HSM is installed for normal use; USB port is blocked when HSM is in the host computer. In IBM Z servers, this is connected to the PCIe bus in a way that sets the latch if the 18 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

19 interface Back up battery power external event has occurred. Latched inside the HSM in a non-volatile latch. Power from the on-card battery. Table 2: Summary of hardware ports and interfaces HSM is removed from the server. If CCA detects that the latch is set, it erases all CCA sensitive data such as master keys. Used when the HSM is now powered over the PCIe bus, to preserve contents of static RAM memory and to power the tamper detection circuits Cryptographic algorithms provided by the HSM hardware Most cryptographic algorithms are implemented in hardware for performance. The 4768 hardware provides the algorithms listed below. Note that some of these algorithms are neither used nor available through the HSM interface when using the PCI-HSM approved firmware. AES using 128, 192, or 256 bit keys. Encryption and MAC. Encryption Modes ECB, OFB, CFB, CBC, CTR, XTS, and GCM. MAC modes CBC, XCBC, and CMAC. Single-DES (56-bit) and triple-des (112 and 168 bit) keys. Encryption and MAC. Modes ECB, OFB, CFB, CBC, and CTR. MAC modes CBC, XCBC, and CMAC. Hashing: MD5, SHA-1, SHA-2 (224, 256, 384, and 512 bits) HMAC using any of the SHA-1 or SHA-2 hash functions. AES Key Wrap as specified in ANSI X Long-integer modular math functions for public-key cryptography up to 4096 bits. Elliptic curve point math functions. RSA with modulus sizes 512, 1024, 2048, and Elliptic Curve (ECDSA and ECDH) using NIST prime curves of sizes 192, 224, 256, 384, and 521, and Brainpool curves of sizes 160, 192, 224, 256, 320, 384, and 512. Random number generation, seeded by hardware random source and producing a pseudo random stream using a DRBG specified in NIST SP A. Prime number generation Random number generation A NIST SP A method is used to generate random numbers for keys and other purposes. In the 4768, this process is implemented entirely in hardware. The deterministic random bit generation (DRBG) function is the AES-256 CRT_DRBG method from that standard, and the seed data is generated with a hardware random number source within the 4768 secure module. 3.3 HSM Serial Number and other card information Each 4768 card has a unique serial number, determined at the factory. The serial number is printed on a label attached to the HSM card, and it is also programmed into the internal memory of the card. The serial number in card memory cannot be changed. 19 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

20 Functions are available to read the programmed serial number electronically. It can be read out using either protected or unprotected methods. With an unprotected method, the serial number is returned but it is not cryptographically protected in any way. With protected methods, the serial number is digitally signed using elliptic curve (ECC) keys that are part of a chain that can be verified back to a known IBM root signing key. The TKE administrative workstation does this automatically, verifying the integrity and authenticity of each 4768 card it administers. Unprotected information on the HSM can be seen using the ISPF panels provided with the z/os ISPF cryptographic support software [7] the Support Element server administration tool [5],and with the panel utility provided with CCA support on z Systems Linux [8]. Other data is also available in addition to the serial number. The 4768 Vital Product Data (VPD) which is programmed into the card at the factory includes firmware versions currently loaded in all segments, card part number, and hardware version information. Using TKE, the Crypto Module Notebook Details Tab (see Reference [2])is one way to read details on the HSM. In addition to other details, this information includes: Crypto Module ID (HSM Serial Number) CCA firmware version identifier Miniboot (low-level firmware) version identifier HSM hardware part number 3.4 Firmware The 4768 has a layered firmware architecture, in which the security of each higher layer is controlled by the layer below it. There are four layers, called segments, as depicted in Figure 7 below. Figure Firmware Layers Segment 0 and Segment 1 contain a combination of two sets of functions. 20 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

21 POST (Power On Self Test) provides self-testing of the HSM when it powers on or is reset. The majority of the POST functions are contained in POST0 and POST1, which execute in the SSP service processor in the card. The small number of tests that cannot run from the SSP are in POST2, which executes in the MCPU processor. Miniboot provides secure firmware loading and update functions. All miniboot firmware runs in the SSP (service) processor. Miniboot provides the ability to perform Concurrent Updates for Segment 3 firmware, in which the HSM continues to run normally while new firmware is installed. The new firmware image is loaded and validated by the SSP while the MCPU continues to process requests from the application programs in the host. When the new firmware has been validated, the MCPU rapidly switches to the new code without having to stop the host application programs. All Segment 0 firmware is permanent. It is loaded at the factory and can never be replaced or updated. It contains the most basic parts of the POST and Miniboot code. Segment 2 contains the card s internal operating system and the related device drivers for accessing the card s hardware resources. Segment 3 contains the CCA (Common Cryptographic Architecture) API firmware, which provides all of the functions that are accessed by host application programs. Host programs making use of the HSM for application-related functions only communicate with Segment 3. The CCA API does not provide direct access to functions or data in Segments 0, 1, or 2. See Section for more information about CCA Updating the HSM firmware Firmware in Segments 1, 2, and 3 is updated using a secure process, which is described in detail in Reference [9]. New firmware for these segments must be digitally signed and the 4768 will not accept the firmware unless it can verify the signature. In addition, it is possible to securely update the function of the FPGA in the card by loading new programming to it in the same way as the firmware is updated for the SSP or MCPU. When new FPGA programming is loaded to the card, it is included as part of the Segment 1 image and is protected and validated using the same process that was described above. On IBM z System servers, HSM firmware updates are installed from the Support Element (SE) Panel. The SE is a separate console used to administer the z System server configuration. The IBM Customer Engineer (CE) obtains the desired HSM firmware update package and loads it onto the SE, and then uses the SE menus to have the new firmware securely loaded into the HSM(s) in that server. See [10] for details of this process. Customers or IBM support personnel monitor the IBM ResourceLink website [11] to see when updates are available. The user must ensure that the firmware in the HSM is at the levels described in Table CCA (Common Cryptographic Architecture) firmware and functions The CCA firmware in Segment 3 provides the functions that are accessed by host system application programs that want to make use of the HSM. The name CCA refers to both the API function set and to 21 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

22 the underlying cryptographic architecture. The complete description of CCA functions, algorithms, and keys is in references [12] and [8]. CCA is designed to provide both general-purpose cryptographic functions and functions that are specific to the needs of the banking industry. In CCA, the API functions are called verbs. CCA API functions can be grouped into several categories. General-purpose cryptography Banking-specific cryptography and security Key management Administrative and configuration CCA supports the following cryptographic algorithms and key sizes. Some of these are not compliant with PCI-HSM requirements, and must not be used in applications that require PCI-HSM compliance. The CCA firmware has the ability to tag keys as compliant with PCI-HSM requirements, and it will not allow creation of any compliant-tagged key that uses a non-compliant algorithm or key length. As long as applications only use compliant-tagged keys for operations that must meet PCI-HSM requirements, the keys will always meet those requirements and the applications do not have to check them itself. Algorithm Key sizes or hash lengths Modes AES 128, 192, 256 Encryption/Decryption: CBC, ECB, GCM Authentication: CMAC Key wrapping: X9.102 AESKW DES and Triple-DES 56 (single-des) 112, 168 (Triple-DES) RSA Modulus bits Digital signature Key transport Elliptic Curve NIST Prime Curves: 192, 224, 256, 384, 521 Brainpool Curves: 160, 192, 224, 256, 320, 384, 512 Encryption/Decryption: CBC, ECB Authentication: CBC MAC, ISO 9797 MAC Algorithm 1, ISO 9797 MAC Algorithm 3, EMV MAC 3 ECDSA (digital signature), ECDH (key exchange) SHA Hash, HMAC SHA-2 224, 256, 384, 512 Hash, HMAC MD5 128 Hash RIPEMD Hash Table 3 - Algorithms supported by CCA in the 4768 HSM In the CCA architecture, operational keys are keys that are used by application programs when they request cryptographic services from the HSM. The operational keys are stored outside of the HSM in encrypted key structures which CCA calls key tokens. Other cryptographic systems use the term key blocks instead of key tokens, but the two terms refer to the same kind of structure. 3 See [18], Annex A IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

23 Within the HSM secure module, CCA maintains a set of master keys which are used to wrap the operational keys that are stored outside of the HSM. There are multiple master keys, each dedicated to wrapping operational keys of particular types, for example a master key for wrapping AES operational keys. The four master keys and their purposes are described in Table 4 in Section 6. When an application program wants the HSM to perform a cryptographic service, for example computing a MAC, the program passes the encrypted key token to the HSM as part of the API request. Within the HSM, CCA unwraps the key token using the appropriate internally-stored master key, then uses the recovered key for the requested operation. In this way, the operational keys never appear outside of the HSM in plaintext form. Figure 8 below illustrates this process. Figure 8 - Use of CCA operational keys 23 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

24 This is a simplified view of the process, showing the following steps which illustrate how the wrapped operational key is sent to the HSM and used there: 1. The application program running in the host system reads the encrypted (wrapped) key token from storage. Note that the token could also be held in memory. 2. The application program invokes the desired CCA API and provides the encrypted key token as a parameter to that API. The CCA host library software creates the request message and sends it to the HSM. 3. The HSM retrieves the correct master key from its internal secure storage and uses it to decrypt and validate the received key token. 4. The HSM uses the decrypted operational key from the received key token to perform the operation requested by the host application program. 5. The HSM sends a reply to the host with the results of the requested operation. 3.5 The IBM HSM manufacturing process The manufacturing process for the 4768 HSM is tightly controlled in secured facilities with trusted personnel. All significant operations are logged, including the identity of the person who performed the operation. Near the end of the manufacturing process, after the HSM is fully assembled and tested, two operations are performed that allow customers to ensure the HSM is secure and untampered. The first step is to have the HSM generate a unique Elliptic Curve device key pair which external entities can use to verify that the HSM is from IBM and that it has not been tampered. The device keys and their use are described in more detail in Section The secure process in the manufacturing facility requests the HSM to generate the key pair, then it creates a certificate containing the public key and signs that with the IBM Class Root private key as described in Section That certificate is installed into the HSM. The second step is to fully enable the protection features of the HSM, so that any attempt to tamper or attack the HSM after that point will be detected and will zeroize and permanently disable it. The result of this process is an HSM that can be trusted by the customer at any point in its life cycle. 3.6 Operating environment The 4768 is fully self-protecting and it does not have to run in a physically secure facility. However, it is most commonly used in a data center which has controlled-access and other security measures. From the time of manufacture, the 4768 card must be shipped, stored, and used within the following environmental specifications. Outside of these specifications, the IBM 4768 tamper sensors can be activated and render the IBM 4768 permanently inoperable. Shipping: Card should be shipped in original IBM packaging (electrostatic discharge bag with desiccant and thermally insulated box with gel packs). Temp shipping -34 C to +60 C 24 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

25 Pressure shipping Humidity shipping min 550 mbar 5% to 100% RH Storage: Card should be stored in electrostatic discharge bag with desiccant. Temp storage Pressure storage Humidity storage +1 C to +60 C min 700 mbar 5% to 80% RH Operation: (ambient in system) Temp operating Humidity operating Operating altitude (max) +10 C to +35 C 8% to 80% RH ft equivalent to 700 mbar min 3.7 Maintenance and Repair There is no physical maintenance or repair for the 4768 HSM.. The only maintenance operation users must perform is the loading of new firmware in order to obtain new features or fix problems. See Section for more information on updating the HSM firmware. 25 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

26 4 DEVELOPMENT ENVIRONMENT AND CONTROLS During product development, all source code and related files are stored in an access-controlled library which securely authenticates every request to access the central repository. Each person in the development team is given only the access rights required for their role, for example development of code in particular modules, administration of the library system, or building of code that is extracted from the library. Hardware design files are managed in a similar manner. Both designs and code are reviewed using a documented review process in order to identify errors at the earliest possible point in the development cycle. Results of the reviews are documented and archived. Documented processes are used to control distribution and storage of firmware modules that are to be loaded into the HSM during the manufacturing process in order to ensure they are not modified or replaced with unauthorized modules. IBM keeps no secret data that would allow compromising the security of a customer s HSM, nor are there any back doors in the HSM that would allow IBM or others to extract sensitive customer data from the HSM. 26 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

27 5 ENSURING RELIABILITY OF THE HSM It is essential to ensure that the HSM gives correct results to the operations it is asked to perform. The 4768 HSM has extensive hardware and firmware features in order to provide this assurance. 5.1 Self-testing Most self-testing takes the form of continuous testing built into the hardware. This detects both stuckfault (hard) errors and transient errors such as those caused by Alpha radiation or electrical noise. Hardware achieves the goal of preventing any undetected error through a combination of several techniques. Many components are fully duplicated with continuous comparison of results. Any difference in the results from the two separate hardware units will be immediately detected and will prevent the return of erroneous results to the host system. This includes the MCPU, the microprocessor that executes requests from application programs on the host system. There are two identical microprocessors that execute the same operations, and their outputs are continuously compared cycleby-cycle to detect any occurrence of an error in either one. All interfaces, registers, memory, cryptographic engines, and buses are protected at all times using parity, ECC, or CRC in order to detect errors, and to correct them in the case of ECC. The continuous hardware error checking is designed to detect any error that occurs during operation of the HSM. There is no need to perform periodic self-tests, because the level of continuous error checking far exceeds the coverage of any self-test. In addition, on-demand or periodic self-tests do not detect transient errors at all, while the 4768 continuous error checking will detect all such errors and halt before any erroneous results might be returned to the host system. The 4768 does have power-on self-tests (POST) which verify the operation of the device each time it is powered on or reset. The POST tests fully verify that the hardware is operating correctly. While the continuous error checking guarantees that no hardware errors occur during operation of the HSM, the user can also initiate execution of the POST tests if desired by initiating a reset of the HSM, either by powering it off and back on, or by initiating a reset through the host device driver using host system commands. This can be done on the z System server by using the System Element (SE) [13] to configure the HSM off (from all LPARs to which it is assigned) and then configure it back on. While configured off, the HSM is in reset state. See Section 8 for information about LPARs. In addition to the low-level tests described above, there are CCA API functions that can be used to perform on-demand tests if desired. The CSUARNT verb can perform the following tests. Tests of the random-number generation output using procedures specified in The NIST SP A Deterministic Random Bit Generator Validation System (DRBGVS). Known-answer tests for DES and Triple-DES, RSA, SHA-1, and AES Galois Counter Mode (GCM). These tests are only provided as a convenience to the user, since every cryptographic operation in the HSM is fully tested during operation by the error checking built in to the hardware. 27 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

28 5.2 Ensuring integrity of the HSM firmware The HSM firmware is stored in flash memory and uses a SHA-256 hash to verify integrity. The firmware is loaded into DRAM memory for execution, and the SHA-256 hash is verified at that time to ensure the firmware image in flash memory has not been corrupted. In addition, the SHA-256 hash is verified again against the copy of the firmware image in DRAM, after it has been copied there. Once the firmware is in DRAM, the error-correcting code (ECC) hardware ensures that no corruption occurs. If any single-bit error occurs on the firmware while in DRAM, it is automatically corrected by the hardware. If any multi-bit error occurs, the hardware detects it and halts execution with an error. Further details are available in Reference [9]. 28 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

29 6 KEYS AND OTHER CSPS (CRITICAL SECURITY PARAMETERS) The 4768 can contain a variety of Critical Security Parameters (CSPs). Some are associated with the HSM itself and are installed by IBM at the time of manufacture or are generated by the HSM itself. Others are owned and created by the end user of the HSM, such as cryptographic keys used when the HSM is in operation supporting business applications. The CSPs that are associated with Segments 0 and 1 (see 3.4) are described in the FIPS 140 Security Policy document [9]. This document will only provide details of the relevant CSPs that are not already covered in the FIPS 140 Security Policy. For reference, Annex A contains a list of all CSPs as documented in the PCI-HSM Modular Vendor Evaluation Questionnaire. Most CCA keys that are used by application programs are stored outside of the HSM, and therefore they are not listed here. Those keys are encrypted by one of the CCA Master Keys described in the table below, so that they are protected by an HSM CSP that is zeroized on tamper. This means that any tamper to the HSM renders all of these externally-stored keys unusable and unrecoverable. No CSPs are ever exported from the HSM in plaintext under any conditions. Except as noted, all of the CSPs listed in this table are stored in HSM internal BBRAM memory and are encrypted by the AES-256 key (M_MSK0) that is itself stored in HSE-BBRAM so that it can be destroyed (zeroized) quickly on tamper. When the M_MSK0 key is zeroized, all of these CCA CSPs become permanently unusable and unrecoverable. The M_MSK0 key is a CSP managed by Segment 1. CSP Name Parameters Description M_MSK0 AES 256-bit Encryption key that protects other CSPs stored in BBRAM memory. M_MSK0 is stored in HSE-BBRAM and is zeroized immediately on tamper. Directly accessible by SSP, but not by MCPU. SSP makes a copy in DRAM that is available to the MCPU, and that copy is zeroized on tamper or reset. DES Master Key TDES 168-bit Protects DES and TDES keys that are stored outside of the HSM. AES Master Key AES 256-bit Protects AES keys and HMAC keys that are stored outside of the HSM. PKA Master Key TDES 168-bit Protects RSA private keys that are stored outside of the HSM, when those keys use the legacy RSA key structure types 0x05, 0x06, or 0x08. APKA Master Key AES 256-bit Protects RSA and ECC private keys that are stored outside of the HSM when those keys use RSA key structure types 0x30 or 0x31, or ECC key structure type 0x20. Access Control Roles N/A Defines the access rights for classes of HSM users. Used by the integrated access control system. See Section 10. Access Control Profiles N/A Defines individual users of the HSM and maps their access rights to one of the Roles. Used by the integrated access KPIT key part table N/A control system. See Section 10. Contains key parts or combined key parts for operational keys that are being manually entered. This includes both the key 29 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

30 material itself, and the attributes that will be bound to the key when it is complete. Function Control Vector (FCV) N/A Allows IBM to limit the HSM cryptographic functionality in order to enforce export regulations or other restrictions. The FCV cannot be used to circumvent security of the PCI-HSM compliant mode of operation. Enable/Disable Flag N/A Determines whether the HSM is in disabled state such that it can be safely removed from the server without risk of sensitive keys being used. TKE CMSSN N/A Sequence number used in secure communications protocol between the HSM and the TKE administrative workstation. Retained Private Keys N/A CCA-generated RSA private keys that are stored inside the HSM. They are generated within the HSM and are cannot be exported Seg3 Epoch key pair ECC P521 in any way. Key pair used to sign messages from the HSM to the host in order to prove the HSM is valid and untampered. The public key is in a certificate signed with a chain of keys that go back to the published IBM Root public key. DRNG State N/A The HSM maintains three independent random number streams. All three use the hardware-based DRNG, but they use independent seeds and maintain the DRNG state so that each stream can restore that state to the hardware when a new set of random numbers must be generated. This data is stored in plaintext in DRAM and is zeroized on tamper or card reset. Root public key certificates N/A The end user can load root public key certificates into the HSM, which can subsequently be used to verify public keys that are used for CCA operations when those keys are provided in signed certificates. Compliance State N/A The HSM stores state information to indicate whether it is currently in a PCI-HSM compliant state. Table 4 - Critical Security Parameters (CSPs) Notes: 1. The key structure types for the RSA and ECC private keys are described in [12] and [8]. 2. The legacy RSA key structure types 0x05, 0x06, and 0x08 are not compliant with PCI-HSM and cannot be used by compliant applications. They are listed here for completeness. RSA key structure types 0x30 and 0x31, as well as ECC key structure type 0x20 have the capability to comply with PCI-HSM requirements, but the necessary functions to use them in a compliant manner are not yet implemented in CCA. 3. Retained RSA private keys are not compliant with PCI-HSM. They are listed here for completeness. 30 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

31 6.1 Compliance-Tagged CCA keys CCA keys that are used by application programs have an attribute to define whether they are compliant with PCI-HSM requirements 4. Keys that have this attribute set are called Compliance-Tagged keys, sometimes shortened to Comp-Tagged keys. During the migration phase, before the system is fully PCI- HSM compliant, a customer can convert existing keys to Compliance-Tagged keys if those keys meet all PCI-HSM requirements. See Section 13.2 for more information on the migration process. Compliance-tagged keys can only be used in Compliance Mode. They will fail if used in any other mode. Keys that are not compliance-tagged can be used in any mode. Compliance-tagged operational keys are wrapped with a different key than non-tagged keys. For nontagged keys, the Master Key is used directly, but for compliance-tagged keys a NIST-approved key derivation function (KDF) is applied to the master key first. This provides cryptographic key separation between non-compliant keys and compliance-tagged keys. It also prevents the possible use of the compliance-tagged keys with an earlier, non-compliant version of CCA firmware, since that earlier version would not use the KDF and would therefore be unable to unwrap the key and obtain the correct cleartext key. 4 This attribute is currently only implemented for Triple-DES keys. 31 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

32 7 KEY MANAGEMENT 7.1 Overview of key management using CCA A financial application typically uses a variety of keys that are structured in a key hierarchy. The leaves of the tree are keys that are used for application-oriented functions like encryption of data, verification of PINs, or computation of message authentication codes. All of the nodes in the hierarchy that are above leaf nodes contain key-encrypting keys (KEKs) which are used to encrypt other keys. There can be multiple levels of KEKs, such that one KEK may be used to encrypt another KEK. In CCA, the top level of the key hierarchy is a set of special key-encrypting keys called Master Keys, which are stored securely inside the HSM. The Master Keys are the only keys in the hierarchy that are stored within the HSM; all lower-level keys are created through API requests to the HSM and are stored outside of the HSM. Keys that are immediately below the Master Keys in the key hierarchy are encrypted by those Master Keys. Keys that are at lower levels in the key hierarchy are encrypted by KEKs that were created using HSM API requests, and those KEKs are not stored in the HSM. Figure 9 depicts an example key hierarchy for the 4768 and CCA. The Master Key at the top is stored inside the HSM. All other keys (below the dotted line) are stored outside of the HSM and are encrypted by other keys. Keys in the level immediately below the Master Key are encrypted by that Master Key. All the keys at levels below that are encrypted by KEKs, usually in preparation for transport to another cryptographic device. Figure 9: Example CCA key hierarchy No cryptographic keys ever leave the HSM in plaintext form. 32 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

33 There are no CCA API functions that return keys in plaintext form. There are no diagnostic or other functions in the hardware or firmware that return a key in plaintext form. All compliance-tagged keys that exit the HSM are encrypted using key wrapping methods that conform to the requirements of ANSI X9.24 Part 1 [14] and ANSI X9.102 [15]. This includes support for the TR-31 [16] key block for interchange of keys with other systems and devices. Each compliance-tagged key has a well-defined usage that is enforced by the HSM. For example, a PIN encryption key cannot be used for purposes other than encrypting a PIN block, a MAC key cannot be used for purposes other than message authentication code generation or verification, and a keyderivation key cannot be used for any purpose other than derivation of another key. In addition to this basic level of key separation, CCA offers a broad set of more granular key usage restrictions that can be used if desired. Key management techniques include those defined in ANSI X9.24 Part 1 [14] including DUKPT, ANSI X9.24 Part 2 [17], EMV-defined key derivation methods [18], and a variety of country-specific or other application-specific methods. Section 7.2 has more information about supported key management techniques. If any key is compromised, or suspected to be compromised, all use of that key and related keys should be ceased as soon as possible. Examples of related keys are keys that were encrypted by the compromised key or keys that were derived from the compromised key. The user should have a policy for key rotation such that all keys are replaced with new keys before there is significant possibility of their compromise. 7.2 Key Management Techniques CCA supports a number of compliant techniques for managing the keys that are used for financial operations. Generation: The key is randomly generated inside the HSM using a compliant random number generator. Secure Import: The key is received from an external source in a key block that is encrypted using a transport key (KEK). The HSM decrypts and validates the received key and converts it into a local key, encrypted under an HSM master key. This type of key transport is used in the method often called Master Key / Session Key, or Master Key / Transaction Key. See Section for additional information about how this method operates with CCA. Manual Loading in Key Components: A key may be split into multiple components, and in that case each custodian holds one component of the key. The component is securely stored, either in a physical form like a piece of paper, or an electronic form like a smart card. Each custodian loads their component into the target HSM, which combines them using Exclusive-OR to form the complete key. Using TKE, the components can be generated directly to smart cards so that they are never exposed in cleartext form. 33 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

34 Key Derivation: A base key is used with a key derivation algorithm to derive a new key. The derivation algorithm uses additional data, which is generally unique to each transaction or otherwise unique each time a key is derived. This ensures that the derived key will be different each time, even though the base key did not change. One of the supported key derivation methods, which is commonly used in payment applications, is the Derived Unique Key Per Transaction (DUKPT) method defined in Reference. [14] Clarification of CCA key management and the Master / Session key management scheme One method of managing keys is called Master / Session. In this scheme, the two parties who wish to communicate each possess a copy of the same KEK. One party generates a new, random key, and encrypts this under the KEK, then sends the encrypted key to the other party. That party decrypts the new key using their copy of the KEK, and then the two parties use the new key to communicate. The terminology used with this scheme can be confusing when it is implemented using CCA. The term Master Key has a different meaning with CCA than it does with Master Key / Session Key. This section explains how CCA key names correspond to the Master Key and Session Key in the key management scheme. Figure 10 shows how this scheme is typically done using CCA. In this case, the session key is a data encryption key, used to encrypt data sent between the two parties named Party A and Party B. It is important to understand that the CCA Master Key is not the Master Key used in the Master / Session scheme. As shown in the figure, a KEK created by the application program is actually what the scheme calls the Master Key. The key encrypted by that KEK is what the scheme calls the Session Key. The color coding in Figure 10 shows that Party A and Party B have the same KEK ( Master Key ), and the same Encryption Key ( Session Key ). However, they do not have the same CCA Master Key in their HSMs; Part A has Master Key A and Party B has Master Key B. Party A Party B Party A s HSM Party B s HSM Master Key A CCA Master Key - Not part of the Master / Session key process Master Key B Party A s application KEK The MASTER key used for Master / Session. Preshared by parties A and B. KEK Party B s application Encryption Key The SESSION key used for Master / Session. Transported under the KEK. Encryption Key Figure 10: Master / Session key management using CCA 34 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

35 The figure shows which keys reside inside the 4758 HSM and which are stored in the user s application program memory. The CCA Master Key is the only key that is stored within the HSM. For the Master / Session key management scheme, neither the Master nor the Session key resides inside the 4768 HSM. 7.3 Key Archival Many cryptographic keys need to be archived so that they are not lost in the event of equipment failure or other unexpected events. With the 4768 and CCA, the keys fall into multiple categories some need to be backed up, while others do not. Only two types of keys have to be backed up by the user, HSM master keys and Operational keys. See Section for a description of master keys and operational keys. Using TKE, the master keys are stored as multiple components (key parts) on smart cards. To back up the master keys, these smart cards are securely locked up under control of the individual key part custodians. If desired, the key parts can be copied to other smart cards to protect against failure or loss of the smart cards themselves. See Reference [2] for details on these procedures. Operational keys are stored outside of the HSM, and are encrypted under one of the HSM master keys. Thus, an HSM failure does not impact those keys; you only need to initialize an HSM with the same master keys, and your operational keys will immediately be usable. However, like any data stored on computer disks, you should back up the operational keys themselves to protect against failure of the host computer disk, or accidental erasure or corruption. You should ensure that you back up all essential operational keys, whether they are stored in the CCA key storage files or in some other place such as storage associated with the application that uses them. Some operational keys may be entered as multiple key components. As each key part custodian enters their component at TKE, the component is combined with previously-entered components of the same key inside the HSM. When all components of a key have been entered, the key is complete and it is encrypted with the appropriate CCA master key and exported from the HSM to be stored outside with the other operational keys. If the HSM fails during the process of entering and combining operational key components, the value in the HSM is lost. Thus, all key components for an operational key should be retained until the entire key is complete and has been stored on the host system. This allows reentering them if a failure occurs during their entry. 35 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

36 8 FINANCIAL PIN PROCESSING CCA has broad support for generation and processing of financial PINs. The following PIN block formats are supported by CCA: IBM 3621 format IBM 3624 format ISO-0 format (same as the ANSI X9.8, VISA-1, and ECI formats) ISO-1 format (same as the ECI-4 format) ISO-2 format ISO-3 format ISO-4 format (In CCA Release 5.4 and later) IBM 4704 encrypting PINPAD (4704-EPP) format VISA 2 format VISA 3 format VISA 4 format ECI2 format ECI3 format When operating in PCI-HSM mode, translations between PIN block formats comply with the restrictions in ISO 9564 [22] and ANSI X9.8 [21]. Those restrictions are enforced by the HSM. 36 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

37 9 DOMAINS AND VIRTUALIZATION OF THE HSM When used in z System servers, the 4768 HSM supports virtualization such that it appears as a set of multiple logically independent HSMs, each with its own CSPs (such as master keys) and its own execution context. The separate, virtualized HSMs are called domains. No domain can interfere with any other domain in any way, such as reading sensitive data from another domain or in any way affecting the processing of requests sent to another domain. The HSM supports a maximum of 256 separate domains, although the IBM Z host will use a maximum of 85. The z System architecture supports logical partitioning in which the server itself can be separated into multiple logically separate servers with hardware-enforced separation that is certified to Common Criteria level EAL5+ (see report in Reference [19]). Each logical partition is called an LPAR. When the customer configures the HSMs that are installed in their z System server, they assign domains of the HSM to LPARs in the machine. In this way, the logical partitioning and secure separation of the server LPARs is mirrored by domains in the HSMs. Note that domains from multiple HSMs can be assigned to the same LPAR, but a given domain in an HSM cannot be assigned to more than one LPAR. Figure 11 below shows an example in which various domains in three 4768 HSMs are mapped to three different LPARs in a single z System server. Figure 11 - Example of mapping HSM domains to host LPARs In the 4768, each domain can be independently set to be in a PCI-HSM compliant mode or to be in a non-compliant mode. This matches the virtualization model in which each domain is able to act as if it is 37 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

38 a separate HSM. If one domain is in a PCI-HSM compliant mode and another domain is not, the design prevents the non-compliant domain from accessing any information from the compliant domain or influencing it in any way. 38 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

39 10 ACCESS CONTROL FOR API FUNCTIONS AND ADMINISTRATION The CCA firmware in the 4768 HSM includes a role-based access control system. A set of Roles define sets of authority that define what operations are permitted for users or applications that operate under that Role. Each function that can be enabled/disabled is associated with a binary value in the role called an Access Control Point, or ACP 5. A set of User Profiles, which are called Authorities in some contexts, define the individual users of the HSM. Each user profile contains the identity of a role which defines which HSM functions that user will be allowed to perform, as well as authentication data that the HSM uses to authenticate that user when they attempt to log on. For administrators using the TKE, the profiles contain their public keys which are used to authenticate the digital signatures they apply to commands to the HSM. When users authenticate themselves to the HSM, they are then permitted to execute the functions that are enabled in the role that is mapped to their user profile. A special Role called the DEFAULT role defines the functions that can be performed by an unauthenticated HSM user. This role defines that base set of functions that are available to any user or application, when that user has not signed in to the HSM. With dual-control functions such as loading two parts of a cryptographic key, the two operations are assigned different Access Control Points and the roles are used to assign those two operations to separate people. An example overview of roles and profiles is shown in Figure 12 below. Figure 12 - Example of Roles and User Profiles This example shows three users with profiles User Profile X, User Profile Y, and User Profile Z. It shows four Roles, Role A, Role B, Role C, and the DEFAULT Role. In this example, the functions allowed for users X and Z are determined by Role C, the functions allowed for user Y are determined by Role A, and the functions available to unauthenticated users are defined by the DEFAULT role. In the 4768, all of the roles and user profiles are user-configurable. Any number of different roles or user profiles can be created, up to the limit of storage available in the HSM. This enables customers to choose their own set of HSM user roles with whatever granularity of access they want to configure. 5 The available Access Control Points are described in Reference [2]. 39 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

40 When used in z System servers, the access control system is used differently for application programs and for administration. The DEFAULT role (which can be configured by the administrators) is used to control what all application programs can do in the HSM. Every application running in the host system will have access to the same set of operations in the HSM. However, z System operating systems such as z/os have their own access control systems, and those can be used on the host side to control what functions can be requested from the HSM. Unlike application programs, the administrators on z System use the User Profiles (Authorities) and Roles to control their authority to execute functions on the HSM. These are used in conjunction with the TKE administrative workstation to control what administrators can perform each administrative or key management function on the HSM cards that the TKE administers. Note the administrators, if so authorized, can configure the functions that are permitted in the DEFAULT role. The administrators who use TKE authenticate themselves to the HSM using digital signatures. Each administrator has a smart card which contains their authentication private key, and their user profile in the HSM contains the corresponding public key. The control block that contains the administrative request message to the HSM is digitally signed by the administrator s smart card. The receiving HSM verifies the signature using the public key in that administrator s user profile. The HSM will only execute the command if (1) the signature can be verified, and (2) the requested function is enabled in the role associated with that administrator s user profile. Signatures use ECDSA with 521-bit NIST Prime Curve (P521) keys. Each administrative command is independently authorized using the digital signature technique. There is no persistent logon or session for the administrators. For this reason, there is no need for a timeout on duration of a session, or keeping track of the number of commands executed in a session. Conceptually, the session lasts for the duration of the execution of one command in the HSM, then ends Access Control for PCI-HSM Compliant Mode Each HSM starts with a default administrator that TKE uses in order to create the real administrators that are used for secure administration in PCI-HSM compliant mode. The default administrator has the identifier TKEAU100, and it can only be used while in Imprint Mode while creating the real administrators. The HSM automatically deletes the default administrator when it moves from Imprint Mode to Compliance Mode. See Reference [2] for details on these processes. When a domain in the 4768 enters Imprint Mode, the access control roles and profiles are reinitialized to the default state. The administrator must create the desired roles and profiles, and those will only be visible or usable in that one, specific domain. This is called domain-scope administration. An administrator in a given domain will have no rights in any other domain, unless they are separately authorized for that other domain. Note that it is possible to configure the same administrator IDs and credentials in multiple domains, but in this case they still act independently; if the same administrative operations are desired for multiple domains, each domain receives separate commands and they are 40 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

41 not aware of each other. For convenience, however, TKE can administer multiple domains and HSMs as a group such that it sends the same commands to all domains and HSMs in the group. To the administrator using the TKE workstation, it appears to be a single operation even though TKE is sending separate commands to each domain and HSM, each of which is independently authorized at the HSM. When operating in Compliant Mode, the administrators must be authenticated using methods that conform to the cryptographic strength requirements in PCI-HSM. Algorithms and key lengths must be sufficiently strong, even though shorter key lengths might be allowed with the same HSM domain when it is not in Compliant Mode. Versions of TKE that support PCI-HSM compliant HSMs also have support for compliant administrator authentication methods. In Imprint Mode or Compliant Mode, the HSM enforces that dual-control administrative operations are performed by two different administrators. The two phases of a dual-control operation are performed using HSM commands that are independently authorized with different Access Control Points (ACPs). The HSM will enforce that those two ACPs are assigned to two separate administrator user IDs. When in Imprint Mode or Compliant Mode the DEFAULT role, which defines the operations available to non-authenticated users, cannot be configured to allow execution of any part of any dual-control operation. This is to ensure that dual-control operations are always performed by two different people. 41 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

42 11 LOGGING OF SECURITY-RELEVANT EVENTS The 4768 maintains an internal, non-volatile log of security-relevant events that have occurred, including events in categories such as key management, changes to access control settings, enabling or disabling of HSM functions, firmware updates, and other administrative operations. Each log record includes the date and time of the event, the identity of the person who performed the operation, the serial number of the HSM, and a sequence number. The records are digitally signed when they are read from the HSM to prove that they have not been modified and that they came from a valid 4768 HSM. The signatures are computed using the Seg3 Epoch key, as described in Section and in Table 4. The corresponding public key certificate and the other certificates required to verify the signature can be read from the HSM using the CCA command CSUADPK; this is performed automatically by the TKE workstation and does not have to be done by the end user. The signature is computed using SHA-512 hashing and the ECDSA digital signature algorithm. The logged events fall into several general categories, including key management, modification of authentication data, software/firmware updates, enabling and disabling HSM security functions, and authentication events. For dual-control operations, there are separate log entries for each of the two steps. The specific events logged in the 4767 include the following: General o Load access control role or profile o Change expiration for a profile o Change passphrase for a profile o Reset failed logon count for a profile o Replace access control role or profile o Delete access control role or profile o Logon failed o Clear the audit log o Firmware update occurred o Master Key operations: Load first part, load middle part, load last part, clear key register (current or old key), set (activate) accumulated master key. Applies to each master key type: SYM, ASYM, AES, APKA o Load / clear of FCV (Function Control Vector) o Set Clock o Load / activate / remove PIN decimalization table o Load / activate / remove weak PIN table o PKI: load root o Operational key loading operations for loading keys as multiple cleartext key parts: load first part, add additional part, complete the key, clear the register o ACP (Access Control Poing) tracking start / stop o Card Migration operations: extract from source card, inject into target card o Transport key setup with TKE Compliance o enter imprint, 42 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

43 o o o enter / leave compliance, enter / leave migration mode, migration timer expiration Events are logged separately for events relevant to each separate HSM domain (see Section 8). In addition, there is one log for events with scope that is global to the HSM and not related to any specific domain. The management of the logs differs slightly for domain-scoped logs and HSM-scoped logs. For domain-scoped logs, each log must be read from the HSM and cleared before it fills. In order to avoid losing any log records, the logs do not wrap 6. If a log fills, it stops logging new events and any CCA command that would need to log an event aborts with Return Code 8 and Reason Code Each domain-specific log can hold up to 512 events. When a log reaches 70% of its capacity, the HSM will return a warning in the return code from the next CCA command that is executed and for all subsequent commands. The Return Code is 4 (indicating this is a Warning and not an Error) and the Reason Code is HSM-scoped logs operate in the same way as the domain-scoped logs described above for some commands, but a subset of HSM-scoped commands behave differently. The HSM-scope log can hold up to 2560 events. The set of commands that behave differently are those that should be allowed to execute, even if the log is full. An example is the loading of new firmware. If one of these events occurs and the log is currently full, the event is stored in a special cache that can hold one event of each type. When the log has been cleared, the cached events are copied into the log. Since each command of this type has a cache that can hold just one log record, the event in the cache is overwritten if the same command occurs again before the log has been cleared, however these commands are ones that should only occur with low frequency. In addition to the return codes described above, a log record is also sent to the host syslog when a log reaches the 70% full threshold and when a log becomes full. These syslog records are only sent to the host once, when the condition is detected, in order to avoid cluttering the host log file with repetitions of the same message. Logging is enabled using the command CSUACFC with the SLOGENAB and COMPMODE keyword options. It is disabled using CSUACFC with the SLOGDSBL and COMPMODE keyword options. These functions are not executed from user-written programs, but are performed using menus on the TKE administrative workstation. TKE is also used to read or clear the logs. The processes are described in the TKE manual, see Reference [2]. Figure 13 below is an example of the way the log records are displayed by the TKE workstation. Records are displayed for a specific, selected HSM. 6 When the HSM is not in PCI-HSM compliant mode, the log can be configured either to wrap or not to wrap. However, in PCI-HSM compliant mode, the wrap option is not available. 43 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

44 Figure 13 - TKE display of secure log record data Clicking on any record in a list such as the example shown in Figure 13 opens the details for that record. The first record ( Sequence 68 ) is an example of this, where you can see details on the user who executed the HSM function that caused the log event as well as data related to the event, which differs according to the function that was performed. It is the customer s responsibility to examine the logs to note any suspicious activity and perform appropriate investigations to determine the cause. In addition, the customer must monitor the logs in each HSM to ensure they are read out and cleared before they fill. Note that the TKE also keeps a log of relevant operations that are performed by the TKE workstation itself. The logs maintained by the HSM meet all the requirements of PCI-HSM, but the additional logs in TKE are also useful in tracking and understanding use of the system. 44 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

45 12 RECEIVING, VALIDATING, AND INITIALIZING THE HSM This section describes actions that are involved with the receipt of a new HSM. There are several ways you may receive a 4768 HSM for your z System server. You may purchase a new HSM feature for a server that is in your data center. You may purchase a new z System server that is pre-configured with the HSM. You may be replacing an HSM that has failed. Regardless of how you obtain the HSM, the steps in the remainder of this section should be used to ensure it is trustworthy and to prepare it for use Validating the integrity and origin of the HSM When the customer receives a new HSM, it is important to verify that the HSM is a genuine and untampered IBM HSM. The sections below describe the features of the HSM that allow the customer to do this, and the procedures they should use. The 4768 HSM is fully self-protecting and will zeroize all CSPs and become permanently inoperable if there is any attempt to tamper with it. Thus, there is no requirement to physically inspect the HSM at any time. If there has been any tampering with the HSM, it will not be operable Verifying the HSM model and serial number Customers can use the procedures in Section 3.3 to securely read device information from the HSM. Comparing this to the expected information, such as the HSM model and serial number, will provide assurance that the HSM can be trusted for use in their system Overview of 4768 authentication subsystem The 4768 HSM provides the ability to cryptographically verify that it is a genuine and untampered IBM HSM. The functions that provide this capability are part of the Outbound Authentication (OA) system. Details on OA and the related HSM internal functions are available in the IBM 4768 PCIe Cryptographic Coprocessor Custom Software Interface Reference [20]. With a z System server, the TKE administrative workstation automatically validates each HSM using the OA cryptographic process. In this way, you are assured that each HSM in your system is valid and untampered without the necessity of any action other than using the TKE to administer the HSM. The lower levels of the key hierarchy used for OA are described in Reference [9]. The firmware in Segment 1 provides a base for the security of the OA process, using a set of keys briefly described below. IBM maintains an IBM Root key pair that is used as the root of security for HSM authentication processes. The IBM Root public key is published so that it is available to anyone who needs to 45 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

46 verify a certificate chain that originates at the IBM Root. For example, the IBM Root public key is published in Reference [20]. IBM creates an IBM Class Root key pair for each class of HSM it develops. The public key for each IBM Class Root key pair is in a certificate that is signed by the IBM Root private key. Each 4768 HSM generates its own Device key pair as part of the secure manufacturing process. The Device private key never leaves the HSM. The Device public key is inserted into a certificate that is signed by the IBM Class Root private key. That signed certificate is then stored in the HSM and can be read out by external programs. The 4768 generates a key pair called the Operating System key pair (O/S key pair), and the public key of this pair is stored in the HSM in a certificate that is signed by the Device key pair private key. Segment 3 contains a component called the OA Manager which application firmware in Segment 3, such as CCA, can use to request operations from the OA subsystem. It can request that the OA Manager generate new key pairs, where the private key is retained by the OA Manager and the public key is returned to the Segment 3 application as a certificate that is signed by the O/S key pair private key. This allows validity of the key to be determined using the chain of certificates that has the IBM Root key as its root. Segment 3 can request the OA Manager to perform operations using the private keys of these key pairs, for example signing data with the private key. The CCA firmware generates one such key pair, called the Seg3 Epoch key pair, and uses that key pair to prove HSM validity to external computers and devices Authenticating the HSM in a customer system Customers will use the TKE workstation to administer the 4768 HSM cards in their z System servers. TKE communicates with the HSM cards over a network connection, using secure protocols. The network connection is between the TKE workstation and the server that contains the target HSM card, and does not terminate in the HSM itself. Software in the target server receives the TKE messages and forwards them to the HSM using functions that are part of its API set. All sensitive information is cryptographically secured using either an HSM or a smart card before it is inserted into the messages that flow across the network. The figure below shows how TKE works with a server that contains 4768 HSM cards. Note that a single TKE can administer HSMs in multiple servers. 46 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

47 Figure 14 - TKE Administration Overview The TKE sends request messages to the HSM cards as required, and every response message from an HSM is digitally signed using the Seg3 Epoch key pair described above. Note that this key pair is independently generated on each HSM card, and thus each HSM has a different Seg3 Epoch key pair. Verification of these signatures constitutes validation that the HSM is valid and untampered. Only IBM can sign the certificates with its root keys, and any attempt to tamper with the HSM immediately zeroizes the HSMs signing keys and renders the HSM inoperable. Thus, as soon as the TKE successfully begins working with a given HSM, the user knows that the HSM can be trusted. In order to verify the signatures it receives from the HSM, the TKE needs the public key certificates for the signing chain. The first thing TKE does when it begins communicating with an HSM is to request these certificates from the HSM and use them to verify the signature on the HSM s Seg3 Epoch public key certificate. TKE has the IBM Root key pair public key built-in, and uses that as the root public key in the signature chain. Subsequent to validating the Seg3 Epoch key pair public key certificate, TKE uses that public key to verify the signature on every message it receives from the HSM, which verifies that the HSM is genuine and untampered Ensuring HSM firmware levels meet PCI-HSM requirements When you receive a new HSM, the firmware may not be at the correct levels for PCI-HSM compliance. The required firmware levels are listed in Table 1 in Section 1. The methods described in Section 3.3 can be used to determine the levels of firmware that are currently installed in the HSM. Loading of new HSM firmware is described in Section Configuring access control The 4768 HSM and the CCA architecture have a powerful and flexible access control system, as described in Section 10. This must be configured prior to using the HSM with live customer applications. 47 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

48 In z System servers, there are two aspects of access control that must be configured. The DEFAULT role for each HSM domain, which defines what CCA API functions can be performed by application programs running on the z System server. The administrative roles and profiles which define the administrators who use TKE to securely administer the HSM. All of these are configured using the TKE administrative workstation, as described in Reference [2]. That manual has details on how to create the required roles and profiles for administrators to be used in PCI- HSM compliant mode. The HSM initially has a default administrator, as described in section 10.1, which is automatically deleted when the HSM enters PCI-HSM compliant mode. When the HSM is in Compliance mode (see Section ), it will not allow the DEFAULT role to be noncompliant. Any access control points that would not comply with PCI-HSM requirements are automatically changed to their compliant state before the HSM enters Compliance mode. Once in Compliance mode, any attempt to set access control points to values that would not be PCI-HSM compliant is rejected by the HSM. Thus, the administrators can set the DEFAULT role to meet the needs of their applications, and setting the role to allow non-compliant functions will be impossible Loading CCA Master Keys CCA uses Master Keys to wrap operational keys that are stored outside of the HSM. The Master Keys that will be needed on your system must be loaded before the HSM can be used by applications. The TKE User s Guide (Reference [2]) contains instructions for securely loading Master Keys. Section 6 contains an overview of the Master Keys. Additional details can be found in the CCA API manuals, References [12] and [8]. 48 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

49 13 PCI-HSM COMPLIANT OPERATION The 4768 provides a special PCI-HSM compliant mode of operation, and while in this mode the HSM itself enforces operation according to PCI-HSM security requirements. The work required by the application programs to ensure PCI-HSM compliance is very limited because the HSM itself enforces most of the requirements. The following requirements must be met in order to operate the HSM in compliance with the PCI-HSM standard. 1. TKE must be used for HSM administration, including activating and configuring the modes described in the remainder of this section. Details on setup and use of TKE are in Reference [2]. 2. The HSM clock must be set before entering Imprint Mode. This is because an accurate time is required for PCI-HSM compliant events such as writing log records. TKE will prompt you to set the clock when you try to enter Imprint Mode, if the clock is not already set. 3. The HSM must be in Compliance Mode (see Section ). The current mode is shown on the General tab of the Crypto Module panel on the TKE workstation. 4. For any symmetric cryptographic operations that fall under the scope of PCI-HSM requirements, the application programs must use compliance-tagged keys (see Section 6.1). 5. Public keys can only be used if they are in the form of an X.509 certificate and if they have sufficient key strength to meet PCI-HSM requirements PCI-HSM Compliant Mode The 4768 HSM provides a mode that enforces compliance with PCI-HSM requirements when compliance-tagged symmetric keys or compliant X.509 certificates are used. The TKE administrative workstation is used to set the HSM to compliant mode, using a dual-control process. The TKE can also display whether the HSM is currently in compliant mode. See Reference [2] for details HSM modes Figure 15 shows the three modes that are provided in the IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

50 Figure 15- Operational modes of the 4768 HSM The sections below describe each of these modes in more detail. Reference [2] contains information about how to use TKE to change modes Normal Mode All domains of the 4768 are in Normal Mode when the HSM is first manufactured, or when it is reinitialized. Normal Mode is the legacy mode in which PCI-HSM requirements are not enforced. All Modes have a sub-mode called Warn Mode, but it is particularly useful when in Normal Mode. Warn Mode is a feature provided to make it easier for customers to transition from their current noncompliant systems to ones that comply with PCI-HSM requirements. In Warn Mode, all applications run normally, but the HSM provides warnings when non-compliant keys or operations are used. In this way, the customer can see what needs to be changed in the way their application uses the HSM in order to achieve PCI-HSM compliance Imprint Mode Imprint Mode is a transitional state between the non-compliant Normal Mode and the PCI-HSM compliant Compliance Mode. The Imprint Mode initializes a chain of trust that protects all cryptographic keys that are PCI-HSM compliant. It creates a special administrative environment that 50 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

51 enforces controls to ensure that administrators are configured to match the requirements of PCI-HSM compliance. TKE is used to change from Normal Mode to Imprint Mode using a dual-control process. In the first step, TKE uses the HSM function CSUACFC with the COMPIMPR and INACTIVE options with the first administrator to enter a state where the transition to Imprint Mode is pending. TKE then uses the function CSUACFC with the COMPIMPR and ACTIVATE options with the second administrator to complete the transition to Imprint Mode. It is possible to return directly from Imprint Mode to Normal Mode using a single-control command to the HSM. The administrators used in the Normal Mode are HSM-scope administrators; they can perform administrative functions on any of the domains (virtual HSMs) in the In Imprint mode, in preparation for PCI-HSM compliant operation, domain-scope administrators are defined. These administrators only have the authority to perform administrative operations on a single domain. 7 While in Imprint Mode, application programs can continue to operate as if the HSM were in Normal Mode. All keys and API functions that worked in Normal Mode will work in Imprint Mode. The secure audit log is enabled as part of the transition to Imprint Mode, and is forced to the nonwrapping mode of operation. See Section 11 for details on the secure log Compliance mode Compliance Mode, also called PCI-HSM Mode, provides a fully PCI-HSM compliant environment. The transition from Imprint Mode to Compliance Mode is performed with TKE using a dual-control process. In the first step, TKE uses the HSM function CSUACFC with the COMP-SET and INACTIVE options with the first administrator to enter a state where the transition to Compliance Mode is pending. TKE then uses the function CSUACFC with the COMP-SET and ACTIVATE options with the second administrator to complete the transition to Compliance Mode. The HSM does not permit the use of any default (initial) administrative keys while in compliance mode, even if such keys have not been replaced or deleted. The final state transition shown in Figure 15 is a transition from Compliance Mode to Normal Mode. This is done using a dual-control operation performed using TKE, and the transition takes the HSM domain out of PCI-HSM compliant operation. Once in Normal Mode, the derived master key that was used to wrap the compliance-tagged CCA keys is unavailable (see Section 6.1), and thus none of the compliance-tagged keys for that domain can be used in Normal Mode. The operations that completely reinitialize a domain ( Zeroize domain ) or the entire HSM ( Zeroize crypto module ) also return it to Normal Mode after clearing all sensitive data. The zeroized operations can be performed either with TKE [2] or using the SE [13] on the z System server. The scope of an instance of PCI-HSM Compliant mode is one domain of the HSM (see Section 8). Domains are logically separate, and one domain can be in PCI-HSM Compliant mode while another domain is not. The two domains cannot share any keys or sensitive data, and cannot influence each other in any way. 7 It is possible to install identical domain-scope administrators for multiple domains, if desired. This can simplify administration of related domains as a group. 51 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

52 While in Compliance Mode, PIN operations are restricted to those allowed under ISO 9564, including restrictions on translations between different PIN block formats Migration to a PCI-HSM compliant mode of operation Most applications will require changes in order to be compliant with PCI-HSM requirements. For example, they may currently use some keys that are non-compliant, and they may use some HSM API functions that are not allowed under PCI-HSM. A special warn mode is available to assist the users in determining what they must change in their current applications in order to be compliant. By using this mode early in their migration process, they can determine what they must change and revise their applications accordingly until no more compliance violations remain. A separate migration mode is available to ease the transition to a PCI-HSM compliant system. In migration mode, the customer can perform special functions that help them convert their existing keys to full compliance Warn Mode The warn mode checks for two classes of compliance issues, keys that are not compliant and functions that are not compliant. Non-compliant keys violate PCI-HSM requirements because of characteristics including the following: Keys wrapped with non-compliant key wrapping methods. Keys that do not meet the key strength requirements because they use disallowed algorithms or are not of sufficient length. Keys that permit multiple usages that are not allowed under PCI-HSM. Non-compliant functions include all operations that are prohibited under PCI-HSM, such as functions that change the key usage attributes for a key. Warn Mode is actually an indicator that is inserted in the low-level request message from the host to the HSM, and is not a mode setting in the HSM itself. The setting is independent for each request to the card. The indicator will typically be set by the host library code that formats requests based on application program API requests. The method of instructing the host library to do this is outside the scope of PCI-HSM, but an example might be an environment variable or other configuration parameter that the user would set. If the HSM detects a compliance issue during execution of a command that has Warn Mode enabled, it will return a warning code in the response to the host system Migration Mode Migration Mode is enabled using a dual-control process through the TKE administrative workstation. The HSM must be in Compliance Mode before Migration Mode can be enabled. A query function is available to determine if the HSM is in Migration Mode. 52 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

53 The user can exit migration mode using a dual-control process through TKE. The HSM also enforces a 30-minute inactivity timeout while in migration mode. If no migration functions of the HSM 8 have been used for 30 minutes, the HSM automatically leaves migration mode. While the HSM is in Migration Mode, the customer can update existing operational keys to convert them to Compliance-Tagged keys that can be used while in PCI-HSM Compliant Mode (see Section 6.1). This is only possible if the keys meet the requirements for PCI-HSM compliance, such as key strength and key attributes. Compliance-Tagged keys cannot be used while the HSM is in Migration Mode. They can be used when the HSM returns to Compliance Mode Configuration for PCI-HSM compliance The only configuration step that must be taken to ensure the HSM is operating in PCI-HSM Compliant Mode is to put the HSM into Compliance Mode as described in Section This ensures that all security restrictions required by PCI-HSM are enforced. This configuration can be verified using the TKE in order to demonstrate that the HSM is operating in a PCI-HSM compliant mode. Reference [5] is a video showing how to use TKE to configure the HSM to be in compliant mode. Once the HSM is in Compliance Mode, the only other requirement is that the application programs using the HSM must only use Compliance Tagged keys. As described in Section 6.1, these keys are marked for use in PCI-HSM compliant operations. Restrictions that are enforced when the HSM is in PCI-HSM Compliant Mode include the PIN translation restrictions described in the Derived Test Requirements. Those restrictions are shown in Table 5 below. 8 The function that resets the inactivity timer is the verb CSNBKTR2 with the option keyword COMP-TAG. This is the method used to convert a non-compliant CCA key to a compliant one. 53 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

54 Table 5: Permitted PIN Translations 13.4 Decommissioning the HSM When the HSM is taken out of service, all keys and other CSPs installed into the HSM by the customer must be deleted. There are several scenarios that must be considered, such as: The HSM will no longer be used for the present application, but the customer will keep it for possible future use in other applications. The customer will never use the HSM again and plans to sell it to another company. The customer will never use the HSM again and wants to render it permanently unusable. The HSM has failed and is no longer working. For deletion of keys and CSPs, these fall into two broad categories, one where the HSM is still functioning properly and one where it is not working. When the HSM is operating normally, commands to the HSM can be used to delete keys and CSPs. When the HSM is not working properly, commands generally cannot be issued and other methods must be used to delete the keys and CSPs. When the HSM is operating normally, there are several ways keys and CSPs can be deleted. CCA commands can be used to individually clear items such as master keys and access control information. 54 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018

55 An entire HSM domain can be zeroized with a single operation from TKE or the SE, clearing all CCA keys and CSPs from the HSM. All domains of the HSM can be zeroized with a single operation from TKE or the SE, clearing all CCA keys and CSPs from all domains of the HSM. When the HSM is not working, there are two methods that can be used to ensure all keys and CSPs are deleted. The HSM is designed with an accessible wire loop for this purpose. If the wire is cut, the hardware in the HSM deletes all keys and CSPs and renders the HSM permanently inoperable. The HSM can be physically destroyed using methods such as shredding the device. The device must be physically destroyed, such that there is no possibility of the keys or other sensitive data being compromised. Figure 16 below shows the white wire that you can cut in order to permanently zeroized the HSM. Figure 16 - Wire to cut to zeroize the HSM The method for doing this in the z13 server is described in detail in Reference [10]. If the HSM will be retained for future use, care must be taken to ensure the HSM is stored and controlled securely so that it cannot be used or reconfigured without authorized approval Moving the HSM Under normal conditions, the HSM protects itself against unauthorized removal from the server. When the HSM is unplugged from the server bus (which includes removing power), a hardware latch called the Intrusion Latch is automatically set by hardware logic. The next time the HSM is powered on, it detects that the Intrusion Latch is set and it zeroizes all customer CSPs before it will respond to any commands. This ensures that no customer keys or other sensitive data can be used if someone removes the HSM and attempts to use it in another server. 55 IBM 4768 PCI-HSM Security Policy Version 1.10 June 7, 2018