Visa PIN Security Requirements Key Injection Facility Auditor s Guide

Transcription

1 Visa PIN Security Requirements Key Injection Facility Auditor s Guide To be used in conjunction with Payment Card Industry (PCI) PIN Security Requirements, V1.0 September 2011

2 Visa PIN Security Requirements Auditor s Guide Key Injection Facility/Annex B Contents Key Injection Facility Introduction... 3 How to Use this Guide... 4 KIF Security Program Overview... 4 Control Objective 1 Secure Equipment and Methodologies... 7 Control Objective 2 Secure Key Creation Control Objective 3 Secure Key Conveyance / Transmission Control Objective 4 Secure Key Loading Control Objective 5 Prevent Unauthorized Usage Control Objective 6 Secure Key Administration Control Objective 7 Equipment Management Page 2 of 76

3 Key Injection Facility Introduction This document applies to third party vendor and acquirer operated KIFs that inject symmetric keys and/or asymmetric keys (KIFs that inject keys used in a remote key management scheme including associated CAs). This document replicates some of the information in the Visa PIN Security Requirements: Auditor s Guide that is applicable to key injection facilities. Requirements 2 (a and b), 3, 4, and 17 are not applicable to key injection facilities and are therefore not included in this document. Questions that have specific additional requirements that apply to KIFs used for remote key distribution and their associated CAs are 5, 6, 10, 15, 18, 19, 20, 21, 22, 25, 28, and 31. Any key in a device must be generated, possibly transported (conveyed) and then inserted into the device. Several scenarios can exist for key injection: A key may be generated and used inside the key generation device. A key may be generated inside a key generation device and directly injected into the destination device physically connected to the key generation device. A key may be generated inside a key generation device, and then transferred to a different physical location where it is inserted into the destination device. The transferred key may be: In clear-text form within a secure Key Loading Device (a SCD) In component form (for symmetric keys) In encrypted form Key injection systems that do not use secure cryptographic hardware are inherently less secure. The payment brands may establish dates by which all key injection facilities providing key injection services to multiple entities shall have to use secure cryptographic hardware for key injection. While we have attempted to make this document easy to read and use, we wish to reiterate the tremendous importance that Visa places in PIN Security and cryptographic key security. We consider PIN and Key Security to be a matter of collective security, rather than an area for competition, and we encourage everyone involved to share information and knowledge freely and openly. Page 3 of 76

4 How to Use this Guide As you go through the Self-Audit Questionnaire, refer to the appropriate individual sections of this Auditor's Guide. Each of these sections describes what we mean by "compliance" in a particular area, and the things to look for during a review to determine whether an acceptable level of compliance exists. Use the Auditor's Guide as a reference tool, not as hard-and-fast rules for the only acceptable way to do things. In many areas, there are a variety of ways to establish compliance, some cleverer than others. Remember that this analysis is important to your company, to staff involved in cryptography, to the other participants in the Visa payment system, and to the integrity of the Visa brand. KIF Security Program Overview Visa requires a KIF Security Self-Audit before commencing operations and in subsequent years. While filling out this document, an auditor usually identifies some areas of non-compliance. For each of these areas, an Exception Report must be completed and filed with Visa. All entities that inject cryptographic keys into devices that accept or process PIN-based transactions for Visa- branded products (and their associated CAs if applicable) are subject to these requirements. Following receipt of the Member's documents, Visa may call to schedule a site inspection. This is one of the most valuable and educational services that Visa provides to its Members and their agents. Field Review Logistics The KIF Security Field Review usually requires two days to complete. During the review (note that we use the term "review" rather than "audit"), the information submitted on the Self-Audit Questionnaire and Exception Forms is verified and a determination is made as to whether the entity is in compliance with each of the seven control objectives examined. The Review generally begins with introductions followed by a restatement of the goals and objectives of the KIF Security Program. Page 4 of 76

5 Then a network diagram is developed which describes how keys flow through the entity operation being reviewed. This includes any CAs that is involved in a remote key establishment or distribution scheme. The types and quantities of ATMs, POS equipment, Host computers, and Hardware Security Modules are listed and the operating system and application software used in systems injecting keys (if applicable) are identified. The details of the cryptographic structure are discussed. This begins with the method(s) used to initialize or re-initialize ATMs or POS equipment. This is followed by the "life history" of all of the other cryptographic keys, including the Master File Key, devicelevel keys and any keys shared with other entities. The information gathered on each cryptographic key includes the date and method of creation, storage methods and location (if managed in hard copy, on EPROMs, and so forth) and the usage of the key. At this point, a substantial portion of the data gathering process has been completed. At some point during the review, we will: Need to see that portion of the data center housing the key injection equipment. Need to see the Certification Authority facility that is used, if applicable, for a remote key distribution scheme. Carry out a physical inventory of all key components and key-loading equipment. Need to see demonstrations of key loading for all cryptographic device types used to process PINs (HSMs, ATMs, POS devices). These "field trips" can be scheduled so as to minimize disruption to your operations. 4 We will also need to interview staff involved with receiving and installing keys into ATM EPPs and POS devices, and staff knowledgeable about key injection operations. Detailed conversations with cryptographic key custodians should reveal all of the details relevant to the receipt, dispatch and storage of cryptographic keys, and how keys are actually loaded (e.g., for HSMs, ATMs, POS devices). At various points during the review, we will need to look at all available written documentation, including policies, procedures, audit trails and logs. After the Field Review After the review is complete, an exit interview is held, during which the compliance status of each area is presented. A question and answer session then brings the on-site portion of the review to an end. In some cases a management report of findings labeled "Tentative and Preliminary" is submitted and any errors of fact, omission or oversight that are agreed upon between the reviewer and the Vendor/Member are corrected. In all cases a final Page 5 of 76

6 report shall be issued and the Vendor/Member (or their agent) is asked to submit a compliance plan within 30 days. This plan must address each of the areas of non-compliance identified during the review, along with a timeline for completion. Visa will review the plan and agree to establish an action plan with the Vendor/Member. After an action plan has been agreed upon, periodic status updates must be submitted by the Vendor/Member (or their agent) in order to track the remedial plan until full compliance is established. Preparing for the Audit Among the questions to address: How many ATMs, cash dispensers, and POS terminals with PIN pads are deployed or in inventory? How many of these devices are compliant with Visa's cryptographic device security requirements? Where do these devices go when they leave the KIF? To the organization's operational sites? To a third party processor? Somewhere else? What CAs are involved? Once you understand the above, then you can move on to other questions. Does the organization under review operate a backup site that includes the ability to inject keys? If a CA, does it operate a backup site? What steps are required to bring a new ATM and/or POS PIN pad into operation? (Make certain that you identify every cryptographic key involved in this process and how each key is used.) Does the organization under review use in-house (proprietary) developed key injection processing software or does the organization use a commercial package? With this information in hand, you can proceed to investigate the 28 individual questions that make up the KIF Security Self- Audit. This document refers to some of the information in the Payment Card Industry PIN Security Requirements that is applicable to key injection facilities. Requirements 2 (a and b), 3, 4, and 17 are not applicable to key injection facilities and are therefore not included in this document. Questions that have specific additional requirements that apply to KIFs used for remote key distribution and their associated CAs are 5, 6, 10, 15, 18, 19, 20, 21, 22, 25, 28, and 31. Page 6 of 76

7 Control Objective 1 Secure Equipment and Methodologies PINs used in transactions governed by these requirements are processed using equipment and methodologies that ensure they are kept secure. Key-Injection Facility Security Requirement 1. All cardholderentered PINs must be processed in equipment that conforms to the requirements for secure cryptographic devices (SCDs). PINs must never appear in the clear outside of an SCD. SCDs are considered tamperresponsive or physically secure devices i.e., penetration of the device will cause immediate erasure of all PINs, secret and private cryptographic keys and all useful residues of PINs and keys contained within it. All newly deployed ATMs and POS PIN-acceptance International/Industry Standard A secure cryptographic device (SCD) must meet the requirements of a Physically Secure Device as defined in ISO Such a device must have a negligible probability of being successfully penetrated to disclose all or part of any secret or private cryptographic key or PIN. A SCD shall be used only after it has been determined that the device s internal operation has not been modified to allow penetration (e.g., the insertion within the device of an active or passive tapping mechanism). An SCD (e.g., a PIN entry device (PED)) that complies with this definition may use a fixed key or a master key/session key key-management technique that is, a unique (at least) double-length TDES PIN-encryption key for each PED or may use double-length key DUKPT as specified in ANSI X9.24: PART 1. An SCD relying upon compromise-prevention controls requires that penetration of the device when operated in its intended manner and environment shall cause the automatic and immediate erasure of all PINs, secret or private cryptographic keys and other secret values, and any useful residuals of those contained within the device. These devices must employ physical barriers so that there is a negligible probability of tampering that could successfully disclose such a key. In the cases where a PIN is required to travel outside the tamper-resistant enclosure of the PED, the PED must encrypt the PIN directly at the point of entry within the secure cryptographic boundary of the PED to meet the requirements for compromise prevention. PEDs in which the clear-text (unenciphered) PIN travels over cable or similar media from the point of entry to the cryptographic hardware encryption device do not meet this requirement. Purchase orders for point-of-interaction PIN-acceptance devices must specify compliance to the applicable PCI Point of Interaction Security Requirements Applicability Question Scope Applies to the equipment that a Key Injection Facility injects keys into, specifically to all PIN entry devices and Host/Hardware Security Modules (HSMs) used with the key injection platform. See and Page 7 of 76

8 devices must be compliant with the applicable PCI Point of Interaction Security Requirements. Newly deployed hardware security modules (HSMs) should be PCI approved. For specific considerations, contact the payment brand(s) of interest. Intent of Question To ensure PINs and keys are processed only in equipment (ATMs, POS devices, cash dispenser, and other PIN entry devices PEDs, and Host Security Modules HSMs) that meet the requirements for physical security as defined in ISO 9564 and ISO This requirement is to ensure that key injection facilities only inject keys into equipment that conforms to the requirements for SCDs. Note: The characteristics of the actual device can vary, depending on the cryptographic scheme being employed. If a unique master key/unique session key hierarchy is being used, the PIN entry device must qualify as a Secure Cryptographic Device (SCD) using compromise prevention techniques. If a unique fixed key hierarchy is being used, the PIN entry device must also qualify as a SCD using compromise prevention techniques. If the device does not retain any key that has been used to encrypt or decrypt secret data, including other keys (e.g., Derived Unique Key per Transaction DUKPT), the PIN entry device may use compromise detection techniques. SCDs relying on compromise detection must use DUKPT. Ultimately, to prevent disclosure of PINs and keys. The processing of PINs outside a SCD represents a serious violation because it exposes cryptographic keys and the PINs that they protect in unprotected computer memory. POS 1. Identify all PIN entry devices (ATMs, POS) and Host Security Modules and compile a list of all such equipment that accepts PINs and processes PINs (e.g., translates PINs from encryption under one key to encryption under another key). 2. Review list of ATM and POS against the Approved PIN Transaction Security Devices list on the PCI website to ensure PIN entry device security evaluation has been completed. (modified) php 3. Review list of ATM and POS devices against Visa device and TDES mandates. To ensure equipment is approved for use Examine the device and its characteristics to ensure tamper-responsive features are enabled. A SCD has a number of features that are designed to protect the secrecy of the cryptographic key(s) contained in its memory. These features may include temperature, pressure and motion sensors, an enclosing wire grid, and an armored case and components. All of these features are designed to detect, resist and react to any attempt by an adversary to learn the value of cryptographic keys. The primary method used by a SCD to Page 8 of 76

9 defeat such an attempt is to "dump" or erase the keys whenever unauthorized intrusion is detected. Ensure indicator lights (if any) signify that the device is powered up and armed. Ensure locks (if any) are turned to the locked position and the keys are removed. Determine if the device has mechanisms that will cause it to dump or erase the keys in the event of intrusion. Determine if the same make and model were previously reviewed and determined to be compliant or non-compliant then. 5. If it is not clear that the device is a SCD, request an affidavit of compliance from the manufacturer. This affidavit should stipulate that the device satisfies ANSI and ISO requirements for a SCD, should identify the independent testing lab that supports this claim, and should bear the signature of a corporate officer. 6. Obtain documented verification of the PED evaluation. 7. Verify that Visa PED usage mandates are being adhered to. Refer to 8. Review Visa PED usage mandates to ensure equipment being reviewed adheres to applicable dates. HSM 9. Identify any HSMs used in the key injection platform and compile a list of all such equipment that accepts and/or processes cryptographic keys. 10. Obtain and examine one or more of the following: NIST certification that the equipment used for PIN translation or key encryption or XORing of key components (hardware or host security modules) complies with a minimum of level 3 of FIPS Security Requirements for Cryptographic Modules. This may be obtained from the NIST website (csrc.nist.gov). Hardware Security Modules must be compliant with FIPS Level 3 or Level 4 (formal certification is not required; however, such certification is evidence of a device's compliance to this requirement). Vendor Certification letters or technical documentation to indicate that the equipment has been designed to meet (ANSI X9.24 and ANSI X9.8/ISO 9564 are the minimum criteria): FIPS Security requirements for Cryptographic Modules-Level 3 or 4. ANSI X9.24 Financial Services Retail Key Management. ANSI X9.8 Personal Identification Number Management and Security (all parts). ISO 9564 Banking-Personal Identification Number Management and Security (all parts). ISO Banking-Secure Cryptographic Devices (Retail), Part 1 Concepts, Page 9 of 76

10 Requirements and Evaluation methods. Note: Vendor documentation previously reviewed may be referenced where the documentation exists in workpapers pertaining to another specific review (this review and the workpaper references must be cited) using the same make and model of equipment. 11. Review purchase order template for new PIN acceptance devices to validate language is included that indicates devices must be in compliance to the applicable PCI Point of Interaction Security Requirements. Page 10 of 76

11 Control Objective 2 Secure Key Creation Key-Injection Facility Security Requirement 5. All keys and key components must be generated using an approved random or pseudo-random process. International/Industry Standard Keys must be generated so that it is not feasible to determine that certain keys are more probable than other keys from the set of all possible keys. Random or pseudo-random number generation is critical to the security and integrity of all cryptographic systems. All cryptographic-key generation relies upon good-quality, randomly generated values. An independent laboratory must certify self-developed implementations of a cryptographic pseudo-random number generator, which includes testing in accordance to the statistical tests defined in NIST SP , consistent with testing performed on PCI approved HSMs and POIs. Applicability Question Scope This question applies to: All cryptographic keys for all ATMs, PIN pads, PIN entry devices and network processor links to the site's host system for all directions of PIN flow incoming and outgoing. Master Keys and hierarchy keys (e.g., Atalla equipment's Super Keys ). Any keys used for internal PIN translations that may occur in the system, or keys used internally. Master Keys and hierarchy keys used by a CA s Host Security Module. All Public and Private key pairs used in the remote key establishment and distribution scheme. Intent of Question This question applies to: All cryptographic keys for all ATMs, PIN pads, PIN entry devices and network processor links to the site's host system for all directions of PIN flow incoming and outgoing. Master Keys and hierarchy keys (e.g., Atalla equipment's Super Keys ). Any keys used for internal PIN translations that may occur in the system, or keys used internally. Master Keys and hierarchy keys used by a CA s Host Security Module. All Public and Private key pairs used in the remote key establishment and distribution scheme. 1. Using the network schematic from the preliminary step, interview responsible personnel to determine the origin of Page 11 of 76

12 the cryptographic keys used for interchange. 2. Examine the operation's documentation that describes the key generation processes. This should include manual logs for Master File Keys and Key Exchange Keys. 3. Examine cryptogram files (or samples of check values) to validate unique symmetric keys (random/pseudorandom generation). 4. Examine asymmetric key s fingerprints or hash values to validate unique keys. (Examine public keys to verify uniqueness.) 5. Have the technical staff sort on the cryptograms field (or the check digit field or fingerprint field) to make it easier to spot duplicates. 6. Examine vendor certification letters or technical documentation to indicate that the equipment has been designed to meet appropriate standards and specifications. The equipment must meet one or more of the following: FIPS Security requirements for Cryptographic Modules-Level 3 or Level 4. ISO Banking-Key Management (Retail)-Part 1: Introduction to Key Management. ISO Banking-Key Management (Retail)-Part 2: Key Management Techniques for Symmetric Ciphers. ISO Banking-Key Management (Retail)-Part 3: Key Life Cycle for Symmetric Ciphers. ANSI X9.17 Financial Institution Key Management (Wholesale). ANSI X9.24 Financial Services Retail Key Management. PCI approved SCD. 7. Observe a demonstration of the key generation process. 8. Ensure keys are generated by using the key generation function of a Hardware Security Module (HSM) or similar device. Other acceptable ways are a series of coin flips or any similar process where the outcomes can be reduced to binary values (0-1, true-false, on-off, red-white, and so forth). 9. Ensure keys are NOT generated as follows: By staff thinking up values. Statistical analysis has shown that some values occur more often than others, resulting in an uneven distribution of key values. In computer memory. These could be compromised during the process. By a method that gives the same output value every time a specific starting or seed value is used. Page 12 of 76

13 10. Compare key check values against those for known, default, test, predictable, easily guessed or simple keys. Such check values are often printed in vendor manuals. 11. Ask key custodians to examine symmetric key components in order to identify any obviously non-random components. 12. Refer to the vendor documentation for a list of known factory default and test key check values. If you spot one of these values, ensure the key is replaced and ensure they generate a new random key. Also see requirement #15. Page 13 of 76

14 Key-Injection Facility Security Requirement 6. Compromise of the keygeneration process must not be possible without collusion between at least two trusted individuals. International/Industry Standard The output of the key-generation process must be monitored by at least two authorized individuals Who can ensure there is no unauthorized tap or other mechanism that might disclose a clear-text secret or private key or key component as it is transferred between the key-generation SCD and the device or medium receiving the key or key component. Multi-use/purpose computing systems shall not be used for key generation where any clear-text secret or private key or component thereof appears in unprotected memory. Printed key components must be printed within blind mailers or sealed immediately after printing so that only the party entrusted with it can observe each component and so that tampering can be detected. Any residue from the printing, export, display or recording process that might disclose a component must be destroyed before an unauthorized person can obtain it. Applicability Question Scope This question applies to the generation of: All cryptographic keys for all ATMs, PIN pads, PIN entry devices and network processor links to the site's host system for all directions of PIN flow incoming and outgoing. Master Keys and hierarchy keys. Any keys used for internal PIN translations that may occur in the system, or keys used internally. Master Keys and hierarchy keys used by a CA s Host Security Module. All Public and Private key pairs used in the remote key establishment and distribution scheme. Intent of Question To ensure: The secrecy and integrity of keys during the key generation process, including during the transfer to the target device or medium. No visual or electronic surveillance or monitoring occurs during the key generation and transfer of the key to the target device or medium. Any secure device (such as a SCD) used for generating keys is free from any electronic tapping devices, that the component values cannot be observed by any unauthorized person, and that only secure printed output such as a PIN mailer is created. Page 14 of 76

15 Key pair uniqueness per device is guaranteed especially when the key pair is generated externally to the device (in which case the key pair is immediately zeroized from the source device after the transfer to the target device). 1. For keys identified in the network schematic, interview appropriate personnel to determine the processes used for the key generation. 2. For keys generated as components and/or manually loaded, examine the documentation of how the processes should occur. 3. Examine key generation logs to verify that multiple personnel participate in the key generation processes. 4. Witness a structured walk through/demonstration of the key generation processes for all key types (MKs, AWKs, TMKs, Public/Private key pairs etc.). This should be done to verify information provided through verbal discussion and written documentation: 5. Observe if there is any way that an adversary could obtain the values of the key components and/or key pairs. Inspect the devices used in the process for evidence of tampering. Observe whether the devices are "cold started" and powered off after use (except when an HSM is being used to generate key components/key pairs). Observe whether any live network connections exist. Determine whether any compromise of paper outputs can take place, including waste, printer ribbons, and so forth. Determine that if the key pair is generated externally to the device that will use it, that the key pair and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) immediately after the transfer to the device which will use the key pair occurs. 6. Examine the physical area to verify that the key component and/or key generation process can be done in complete seclusion. Verify that any mechanical or electronic devices being used do not have any extra "dangly bits", such as wiretaps, or mysterious wires or cables sprouting from them. If the component value is printed out, ensure that it is either printed inside a blind envelope, such as a PIN mailer, or that no one but the authorized custodian ever has physical access to the output. 7. Verify that multi-use/purpose computing systems are not used for key generation where any clear text secret or private key or component thereof appears in unprotected memory. For entities participating in remote key establishment and distribution applications: 8. Interview appropriate personnel to determine if any key pairs are generated external to the device; the process used for generation on the key pairs; the methods used to transfer the key pairs from the device that generated them to the devices that will used them. Page 15 of 76

16 9. Verify that key pairs are deleted or zeroized immediately from the device that generated them after the transfer to the device which will use the key pairs. 10. Examine logs to verify that deletion of key pairs takes place as required in Requirement 24. Page 16 of 76

17 Key-Injection Facility Security Requirement 7. Documented procedures must exist and be demonstrably in use for all keygeneration processing International/Industry Standard Written key-creation procedures must exist and all affected parties (key custodians, supervisory staff, technical management, etc.) must be aware of those procedures. All key-creation events must be documented. Applicability Question Scope This question applies to written procedures that describe how all cryptographic keys for all ATMs, PIN pads, PIN entry devices and network processor links to the site's host system for all directions of PIN flow incoming and outgoing are generated. This includes Master Keys and hierarchy keys, and any keys used for internal PIN translations that may occur in the system, or keys used internally, Master Keys and hierarchy keys used by a CA s Host Security Module, and all Public and Private key pairs used in the remote key establishment and distribution scheme. Intent of Question To ensure: Adequate and appropriate documented written procedures exist for the generation of all cryptographic keys. Documented procedures are followed, and that keys are not generated in a non- compliant manner. 1. Review existing documentation for completeness. Documentation detailing procedures and personnel (by organizational placement or name) may include references to vendor documentation. Overview of Documented Procedures for All Questions: Questions 7, 11, 16, 28 and 32 Procedure Documentation. Documented procedures are in place for all aspects of cryptographic key management. Question 7 Key-Generation Procedures. Documented procedures exist and are demonstrably in use for all key-generation processing. Question 11 Key-Transmission Procedures. Documented procedures exist and are demonstrably in use for all key transmission and conveyance processing. Question 16 Key-Loading Procedures. Documented procedures exist and are demonstrably in use (including audit trails) for all key-loading activities. Question 2 8 Key Administration Procedures. Documented procedures exist and are demonstrably in use for all key administration operations. Page 17 of 76

18 Question 32 Equipment Security Procedures. Documented procedures exist and are demonstrably in use to ensure the security and integrity of PIN-processing equipment (e.g., PEDs and HSMs) placed into service, initialized, deployed, used, and decommissioned. Page 18 of 76

19 Control Objective 3 Secure Key Conveyance / Transmission Key-Injection Facility Security Requirement 7. Secret or private keys must be transferred by: a. Physically forwarding the key as at least two separate key shares or full-length components (hard copy, smart card, SCD) using different communication channels, or b. Transmitting the key in ciphertext form. Public keys must be conveyed in a manner that protects their integrity and authenticity. International/Industry Standard Keys conveyed to a key-injection facility must be conveyed in compliance with these requirements. Such keys can include, but are not limited to: Derived Unique Key Per Transaction (DUKPT) Base Derivation Keys (BDKs) used in the DUKPT key-management method, Key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf or from a merchant to a third party that is performing key-injection on their behalf), Terminal master keys (TMKs) used in the master key/session key key-management method, PIN-encryption keys used in the fixed-transaction key method, Public keys used in remote key-establishment and distribution applications. Keys conveyed from a key-injection facility (including facilities that are device manufacturers) must be conveyed in compliance with these requirements. Such keys can include, but are not limited to: Digitally signed HSM-authentication public key(s) that are signed by a device manufacturer s private key and subsequently loaded into the HSM for supporting certain key-establishment and distribution applications protocols (if applicable), Device manufacturer s authentication key loaded into the HSM for supporting certain key-establishment and distribution applications protocols (if applicable). Specific techniques exist in how keys must be transferred in order to maintain their integrity. An encryption key, typically Key Encryption Keys (KEKs), must be transferred by physically forwarding the separate components of the key using different communication channels or transmitted in cipher text form. Key components must be transferred in either tamper-evident packaging or within a SCD. No person shall have access to any clear text key during the transport process. Specific techniques exist in how keys must be transferred in order to maintain their integrity. An encryption key, typically a key-encryption key (KEK), must be transferred by physically forwarding the separate components of the key using different communication channels or transmitted in cipher-text form. Key components must be transferred in either tamper-evident, Page 19 of 76

20 authenticable packaging or within an SCD. No person shall have access to any clear-text key during the transport process. A person with access to one component or share of a secret or private key, or to the media conveying this value, must not have access to other components or shares of this key or to any other medium containing other components or shares sufficient to form the necessary threshold to derive the key. E.g., in an m-of-n scheme, such that any three key components or shares can be used to derive the key, no single individual can have access to more than two components/shares. shall not be used for the conveyance of secret or private keys or their components, even if encrypted, unless the key (or component) has already been encrypted in accordance with these requirements, i.e., in an SCD. This is due to the existence of these key values in unprotected memory just prior to encryption or subsequent to decryption. In addition, corporate systems allow the recovery by support staff of the clear text of any encrypted text or files conveyed through those systems. Components of encryption keys must be transferred using different communication channels, such as different courier services. It is not sufficient to send key components for a specific key on different days using the same communication channel. Public keys must use a mechanism independent of the actual conveyance method to validate that the correct key was received. Applicability Question Scope This question applies to written procedures that describe how all cryptographic keys for all ATMs, PIN pads, PIN entry devices, key generation devices and key loading devices are generated. This includes Master Keys and hierarchy keys, and any keys used internally by the key injection platform, Master Keys and hierarchy keys used by a CA s Host Security Module, and all Public and Private key pairs used in the remote key establishment and distribution scheme. Intent of Question To ensure: Secrecy and integrity of keys when key components are transferred from the location of generation to the location of loading and/or storing. Integrity and authenticity of public keys that are conveyed from one location to another. This is to protect against a man-in-the-middle attack, or substitution of a public key by an adversary. Secret or private keys: When a secret or private cryptographic key is sent from one place to another, it must be sent in such a way that it remains totally secret. The governing principles of a secret or private key transmitted as two or more components are split knowledge and dual control. This means that no one person has sufficient knowledge to compromise the key and the key cannot be formed without the direct participation of more than one person. To ensure that these principles are observed, a secret or private key must be sent as two or more full-length components to separate designated Page 20 of 76

21 recipients through separate delivery methods, such as different courier service firms, or it can be sent encrypted. Note: An encrypted secret or private key may be sent without any special precautions. Public keys: When a public cryptographic key is sent from one place to another, some mechanism independent of the actual conveyance method that provides the ability to validate that the correct key was received must be used. 1. Interview appropriate personnel and examine transmittal and receipt logs for key components that are manually conveyed or received. 2. Review procedural documentation for key receipt and transfer of key components. Note: Electronically transmitted keys or components must only be transmitted as cryptograms. 3. Follow the route taken by each key component that the KIF sends. If the KIF generates a KEK, these consist of the Key Exchange Key (KEK) components that the KIF creates and sends to an entity with which it exchanges cryptograms of keys to be used in the key injection process. (The entity may alternatively generate the KEK and send it to the KIF.) Verify that each key component is sent in an opaque, tamper-evident package to a specific, named recipient. 4. Ensure that the components are sent through different methods (for example, FedEx for one and UPS for the other). Components sent on chip cards or other non-paper media must follow the same rules. 5. If sending the cryptogram of a key rather than its components, no special precautions need be taken. However, it is still a good practice to give a transmittal notice and receive a notice of receipt. 6. When the KIF receives key components, verify that the components are received by staff designated as key custodians and that they are logged before being placed into secure storage. 7. Trace how all keys are sent and received under normal conditions to ensure that the rules have been followed. 8. Review the written documentation and the key logs to crosscheck that everything has been accounted for. 9. Validate that when a public cryptographic key is sent from one place to another, some mechanism independent of the actual conveyance method provides the ability to validate that the correct key was received. 10. Determine how keys are sent in an emergency. (It seems to be common practice to violate every Page 21 of 76

22 security procedure in the name of customer service, and it is often the case that the key values are dictated over the telephone or faxed. This has the possibility of compromising that key and all of the keys and/or PINs that it ever protected.). 11. Verify that when a public cryptographic key is sent from one place to another, some mechanism independent of the actual conveyance method provides the ability to validate that the correct key was received. 12. Validate through interviews, observation and logs, that is not used as means to convey keys. Page 22 of 76

23 Key-Injection Facility Security Requirement 8. During its transmission, conveyance, or movement between any two organizational entities any single, unencrypted secret or private key component must at all times be: a. Under the continuous supervision of a person with authorized access to this component, or b. Locked in a security container (including tamperevident, authenticable packaging) in such a way that it can be obtained only by a person with authorized access to it, or c. Contained within a physically secure SCD. International/Industry Standard Key components conveyed to and from a key-injection facility must be conveyed in compliance with these requirements. Such key components include but are not limited to those for Key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf), or key components for the BDKs themselves, and terminal master keys used in the master key/session key key-management method. Key components are the separate parts of a clear-text key that have been created for transport to another endpoint in a symmetrical cryptographic system. Typically, key components exist for KEKs, such as keys used to encrypt working keys for transport across some communication channel. Until such keys can be protected by encryption, or by inclusion in an SCD, the separate parts must be managed under the strict principles of dual control and split knowledge. Dual control involves a process of using two or more separate entities (usually persons), which are operating in concert to protect sensitive functions or information. Both entities are equally responsible for the physical protection of the materials involved. No single person shall be able to access or use all components or a quorum of shares of a single secret or private cryptographic key. Split knowledge is a condition under which two or more entities separately have key components that individually do not convey any knowledge of the resultant cryptographic key. Procedures must require that plain-text key components stored in tamper-evident, authenticable envelopes that show signs of tampering must result in the destruction and replacement of the set of components, as well as any keys encrypted under this key. No one but the authorized key custodian (and designated backup) shall have physical access to a key component prior to transmittal or upon receipt of a component. Mechanisms must exist to ensure that only authorized custodians place key components into tamper-evident, authenticable packaging for transmittal and that only authorized custodians open tamper-evident, authenticable packaging containing key components upon receipt. Pre-numbered, tamper-evident, authenticable bags shall be used for the conveyance of clear-text key components. Out-ofband mechanisms must exist to verify receipt of the appropriate bag numbers. Applicability Question Scope This question applies to: all unencrypted symmetric c ryptographic keys and key components when they are transmitted, conveyed or moved between two entities or departments (whether internal or external) to the organization This applies to all symmetric cryptographic key components for all ATMs, PIN pads, PIN entry devices, key generation devices and key loading devices (if conveyed). This question also applies to components of Master Keys and hierarchy Page 23 of 76

24 keys used by Host Security Modules that are part of the key injection platform (if conveyed). This question also applies to components of any keys used internally by the key injection platform (if conveyed). Clarify to be both... Intent of Question To ensure the secrecy and integrity of key components and keys when key components are transferred, conveyed or moved between two organizational entities. Unlike the previous question, which examines the methods used to transport keys (as either cryptograms or key components); this question addresses the transfer of key components between business entities. This question refers to the methods in place to transport key components within a specific enterprise. (For example, this question is intended to ensure that key components are not compromised while they are being transported from secure storage to the data center where they will be entered into a SCD.) 1. Interview appropriate personnel and examine documented procedures for the custody (and storage or destruction if applicable) of key components from the time of generation to the time of transmittal/loading, or for the time from receipt until the time of loading. 2. Examine logs of access to the security containers to validate that only the authorized individual(s) accesses each component. 3. Ensure that the principles of dual control and split knowledge are being strictly enforced. Diagram the process, as detailed in the written procedures and during conversations with the participants. Identify any points in the process when someone other than a designated key custodian holds a key component or when one person has physical control of all of the components of a key. Dual Control No single person can gain control of a protected item or process. Split Knowledge The information needed to perform a process such as key formation is split among two or more people. No individual has enough information to gain knowledge of any part of the actual key that is formed. 4. Examine the key component storage arrangements. Ensure the container is secure and the custodian is the only person who has access to the contents. (For example, if the components are stored in a safe, they should be in different locked areas with the brass keys or combinations held by the designated custodians.). 5. Ensure key components are NOT stored in unsecured desk drawers. (This is not robust enough for the purpose, and master brass keys are often held by facilities or maintenance staff.) 6. Ensure multiple components are NOT stored in the same physical area within a safe or lockbox. Verify that the key custodian must participate in the process of retrieving the component and that no single person, whether designated Page 24 of 76

25 as a custodian or not, can access all components of a key. Page 25 of 76

26 Key-Injection Facility Security Requirement 10. All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed. International/Industry Standard Key-encryption keys used to convey keys to a key-injection facility must be (at least) as strong as any key transmitted or conveyed. Such keys include key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is performing key-injection on their behalf). All DES keys used for encrypting keys for transmittal must be at least double-length keys and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment. A double- or triple-length DES key must not be encrypted with a DES key of a shorter length. RSA keys used to transmit or convey other keys must use a key modulus of at least 1024 bits. RSA keys encrypting keys greater in strength than double-length TDEA keys shall use a modulus of at least 2048 bits. An RSA key with a modulus of at least 1536 bits should be used to encipher double-length TDEA keys. RSA keys with a modulus of 2048 or higher should be used wherever both endpoints support those sizes. In all cases, keys existing outside of an SCD must be protected by keys of equal or greater strength as delineated in Annex C. Applicability Question Scope This question applies only to keys that are used to transmit other keys. It does not apply to keys that encrypt PINs. Applicable keys include symmetric cryptographic keys used in encrypting other symmetric keys exchanged with a KIF, and TMKs used with the Master Key/Session Key key management method. Applicable keys also include asymmetric keys used to convey other keys. Intent of Question To ensure that encrypted keys are protected by encryption with keys that are as least as strong as they are. Ultimately to protect against a key exhaustion attack to protect the key that ultimately protects PINs. Note: All DES cryptographic keys fall into one of three categories: o o A specific key is a Master key, used to encrypt other keys for storage as cryptograms in a device or host environment. A Key Encryption (Key Exchange, Key Transport, Key Encipherment) key is used to encipher a DES key during transport. This question involves these DES keys. These DES keys must be at least double Page 26 of 76

27 length keys and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key encipherment. A double or triple length DES key must not be encrypted with a DES key of a shorter length. o A Working key is used to encipher the actual data, such as a PIN. Visa requires that all DES Key Exchange keys must be at least double length (32 hexadecimal characters). Note: As of the publication date of this document, Visa has not set global dates for enforcement of the requirement for TDES. However for specific Visa Regional implementation dates contact your Visa Regional Risk Group. The industry is developing techniques for using asymmetric keys to distribute symmetric keys to remote devices. Such schemes may involve RSA keys to encrypt a TDES symmetric key. If implemented, the RSA key must use a key modulus of at least 1024 bits to be in compliance with this question. Based upon the network schematic, identify all key encipherment keys. 1. Interview appropriate personnel and examine documented procedures for the creation of these keys. This must be done to ensure that they are at least double length keys and use TECB or TCBC mode of operation for encryption if a DES key, and if a RSA key, it uses a key modulus size of at least 1024 bits. 2. Using the table in Annex C, validate the respective key sizes for DES, RSA, Elliptic Curve, and DSA algorithms that are used. 3. Examine the cryptograms of key exchange keys and validate that all DES symmetric keys are 32 or 48 hexadecimal characters. If there are RSA asymmetric transport keys, validate that the RSA public key modulus is at least 1024 bits. 4. Verify that no Key Exchange Key is shorter than the cryptographic keys that it protects and it is at least double length for a DES key; and if RSA, that it uses a key modulus of at least 1024 bits. Verify that if RSA is used to convey triple length DES keys or AES keys, then it uses a key modulus of at least 2048 bits. 5. Examine the DES key cryptogram and ask the custodians to count the number of characters in each DES key component in order to verify compliance with this requirement. Examine the RSA public key modulus and count the number of characters to verify it is at least 1024 bits. 6. Page 27 of 76

28 Key-Injection Facility Security Requirement 11. Documented procedures must exist and be demonstrably in use for all key transmission and conveyance processing. International/Industry Standard Written procedures must exist and all affected parties must be aware of those procedures. Conveyance or receipt of keys managed as components or otherwise outside an SCD must be documented. All key conveyance events performed by a key-injection facility must be documented. Applicability Question Scope This question applies to written procedures that describe how all cryptographic keys and/or symmetric key components are transmitted, conveyed or moved between the KIF and other entities. This applies to all keys and symmetric key components transmitted/conveyed for all ATMs, PIN pads, PIN entry devices, key generation devices and key loading devices (if conveyed). This question also includes conveyance of any Master Key and hierarchy key components (e.g., if operating multiple production data centers and/or host hardware security modules and/or hardware platforms, etc.). This question also includes any keys used internally by the key injection platform (if conveyed). This question also includes any asymmetric keys used for key transport, exchange or establishment between a KIF and other entities. Documented procedures must exist and be demonstrably in use for all such asymmetric keys (because they are used to convey the symmetric key between the PIN entry devices and the hosts). Intent of Question To ensure that: Adequate and appropriate documented written procedures exist for the conveyance of all cryptographic keys. Documented procedures are followed and that keys are not conveyed in any other (especially non-compliant) manner. 1. Review existing documentation for completeness. Refer to Requirement 7. Page 28 of 76

29 Control Objective 4 Secure Key Loading Key-Injection Facility Security Requirement 10. Secret and private keys must be input into host hardware security modules (HSMs) and PIN entry devices (PEDs) in a secure manner. a. Unencrypted secret or private keys must be entered into host hardware security modules (HSMs) and PIN entry devices (PEDs) using the principles of dual control and split knowledge. b. Key-establishment techniques using public-key cryptography must be implemented securely. International/Industry Standard Key-injection facilities must load keys (unencrypted symmetric keys must be loaded as key components) using dual control and for secret and private keys, split knowledge. Such keys include, but are not limited to: Derived Unique Key Per Transaction (DUKPT) Base Derivation Keys (BDKs) used in the DUKPT key-management method, Key-encryption keys used to encrypt the BDKs when the BDKs are conveyed between entities (e.g., from the BDK owner to a device manufacturer that is performing key-injection on their behalf, or from a merchant to a third party that is injecting keys on their behalf), Terminal master keys (TMKs) used in the master key/session key key-management method, PIN-encryption keys used in the fixed-transaction key method, Master keys for key-injection platforms and systems that include hardware devices (SCDs) for managing (e.g., generating and storing) the keys used to encrypt other keys for storage in the key-injection platform system, Public and private key pairs loaded into the POIs for supporting remote key-establishment and distribution applications, Digitally signed POI public key(s) that are signed by a device manufacture s private key and subsequently loaded into the POI for supporting certain key-establishment and distribution applications protocols (if applicable. Dual control is not necessary where other mechanisms exist to validate the authenticity of the key, such as the presence in the device of an authentication key, Device manufacturer s authentication key (e.g., vendor root CA public key) loaded into the POI for supporting certain key-establishment and distribution applications protocols (if applicable). Key-injection facilities must implement dual control and split knowledge controls for the loading of keys into equipment. Such controls can include (but are not limited to): Physical dual access controls that electronically provide for restricted entry and egress from a room dedicated to keyinjection such that the badge access system enforces the presence of at least two authorized individuals at all times in the room so that no one person can singly access the key-loading equipment. Access is restricted to only appropriate personnel involved in the key-loading process. Logical dual control via multiple logins with unique user IDs to the key-injection platform application such that no one person can operate the application to singly inject cryptographic keys into devices. Key-injection platform applications that force the entry of multiple key components and the implementation of procedures involving multiple key custodians that store and access key components under dual-control and splitknowledge mechanisms. Page 29 of 76

30 Demonstrable procedures that prohibit key custodians from handing their components to any other individual for key entry. The master file key and any key-encryption key, when loaded from the individual key components, must be loaded using the principles of dual control and split knowledge. Procedures must be established that will prohibit any one person from having access to all components of a single encryption key. Key components shall be combined using a process such that no active bit of the key can be determined without knowledge of the remaining components for example, via XOR ing. Note that concatenation of key components together to form the key is unacceptable; e.g., concatenating two eight-hexadecimal character halves to form a sixteenhexadecimal secret key. The resulting key must exist only within the SCD. Host security module (HSM) master file keys, including those generated internal to the HSM and never exported, must be at least double-length keys and use the TDEA (including parity bits) or AES using a key size of at least 128 bits. For manual key-loading, dual control requires split knowledge of the key among the entities. Manual key-loading may involve the use of media such as paper or specially designed key-loading hardware devices. Any other SCD loaded with the same key components must combine all entered key components using the identical process. The initial terminal master key (TMK) must be loaded to the device using either asymmetric key-loading techniques or manual techniques e.g., the device keypad, IC cards, key-loading device, etc. Subsequent loading of the terminal master key may use asymmetric techniques, manual techniques or the existing TMK to encrypt the replacement TMK for download. Keys shall not be reloaded by any methodology in the event of a compromised device, which must be withdrawn from use. TR-31 or an equivalent methodology should be used for key-loading whenever a symmetric key is loaded encrypted by another symmetric key. This applies whether symmetric keys are loaded manually (i.e., through the keypad), using a keyinjection device, or from a remote host. It does not apply when clear-text symmetric keys or their components are loaded using standard dual-control techniques. Any equivalent method must include the cryptographic binding of the key-usage information to the key value using accepted methods. Any binding or unbinding of key-usage information from the key must take place within the secure cryptographic boundary of the device. Key-establishment protocols using public-key cryptography may also be used to distribute PED symmetric keys. These key-establishment protocols may use either key transport or key agreement. In a key transport protocol, the key is created Page 30 of 76

31 by one entity and securely transmitted to the receiving entity. For a key agreement protocol, both entities contribute information, which is then used by the parties to derive a shared secret key. Meet all applicable requirements described in Annex A of this document. A public-key technique for the distribution of symmetric secret keys must: Use public and private key lengths that are deemed acceptable for the algorithm in question (e.g., 1024-bits minimum for RSA). Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question. Provide for mutual device authentication for both the host and the PED, or host-to-host if applicable, including assurance to the host that the PED actually has (or actually can) compute the session key and that no other entity other than the PED specifically identified can possibly compute the session key. Applicability Question Scope The scope pertains to unencrypted keys and key components. A public-key technique for the distribution of symmetric secret keys must: Use public and private key lengths that are deemed acceptable for the algorithm in question (e.g., 1024-bits minimum for RSA). Use key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question. Ensure mutual device authentication for both the host and the PED, or host-to-host is specified for remote autheif applicable, including assurance to the host that the PED actually has (or actually can) compute the session key and that no other entity other than the PED specifically identified can possibly compute the session key. Host-to-host and host-to-pin accepting device authentication is mandatory for Remote Key Distribution schemes. Intent of Question To ensure that no one knows the final key during key loading (knowledge of any one key component gives no knowledge of the final key). (For DES, the method to implement this is to enter the cryptographic key values as two or more components, each of which is equal in size to the actual key.) HSM 1. Interview appropriate personnel and review documentation to determine the procedures for key loading to the HSM. (This includes key loading of symmetric Master Keys for the CA s HSM, if a CA is used in a remote key injection process.) 2. Demonstration/walk through of the usage of any equipment (terminals, PIN pads, etc) used as part of the key loading process. 3. Examine logs of access to security containers that passwords, PROMs, smartcards, brass keys, etc. are stored in to ensure dual control. Page 31 of 76

32 4. Ensure key loading devices can only be accessed and used under dual control. 5. Examine vendor documentation describing options for how the HSM MFK is created. Corroborate this with information gathered during the interview process and procedural documentation provided by the entity under review. PED 6. Interview appropriate personnel and review documentation to determine the procedures for key loading to PEDs. 7. Demonstration/walk through of the usage of any equipment (terminals, external PIN pads, key guns, etc) used as part of the key loading process. 8. Examine logs of access to security containers for key components. 9. For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including the size and sources of the parameters involved, and the mechanisms utilized for mutual device authentication for both the host and the PED HSM & PED 10. Interview appropriate personnel to determine the number of key components, the length of the key components, and the methodology used to form the key for each interchange related key identified in the network schematic. If other mechanisms do not exist to verify key component length, a custodian may be requested to examine a component stored on paper. 11. Examine HSM and PED vendor documentation to determine the methodologies (XOR, DEA, and Concatenation) supported for the combination of key components. 12. Witness a structured walk through/demonstration of various key generation processes for all key types (MKs, AWKs, TMKs, etc.). Verify the number and length of the key components generated to information provided through verbal discussion and written documentation. Also verify that the process includes the entry of individual key components by the designated key custodians. 13. Ensure check values from the HSM and verify that PED are the same during the key loading demonstration. Custodians do NOT hand their components to a third party to enter. Components are double-length (two or more components, each of which is equal in size to the actual key) HSM brass keys are held under dual control. 14. Verify that mutual authentication takes place when remote key distribution is performed between two host systems or between host and PIN entry device. Page 32 of 76

33 Key-Injection Facility Security Requirement 13. The mechanisms used to load secret and private keys, such as terminals, external PIN pads, key guns, or similar devices and methods must be protected to prevent any type of monitoring that could result in the unauthorized disclosure of any component. spend time on 13 International/Industry Standard Key-injection facilities must ensure key-loading mechanisms are not subject to disclosure of key components or keys. Some key-injection platforms use personal-computer (PC)-based software applications whereby clear-text secret and/or private keys and/or their components exist in unprotected memory outside the secure boundary of an SCD for loading keys. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. These weaknesses include: XOR ing of key components is performed in software. Clear-text keys and components can reside in software during the key-loading process. Some systems require only a single password. Some systems store the keys (e.g., BDKs, TMKs) on removable media or smart cards. These keys are in the clear with some systems. PCs, by default, are not managed under dual control. Extra steps (e.g., logical user IDs, physical access controls, etc.) must be implemented to prevent single control of a PC. Data can be recorded in the PC s non-volatile storage. Software Trojan horses or keyboard sniffers can be installed on PCs. Key-injection facilities that use PC-based key-loading software platforms which allow clear-text secret and/or private keys and/or their components to exist in unprotected memory outside the secure boundary of an SCD must minimally implement the following additional controls: Stand-alone (i.e., without modems, not connected to a LAN or WAN, not capable of wireless connections, etc.), Dedicated to only the key-loading function (e.g., there must not be any other application software installed), and Located in a physically secure room that is dedicated to key-loading activities. All hardware used in key-loading (including the PC) must be managed under dual control. Key-injection must not occur unless there are minimally two individuals in the key-injection room at all times during the process. If a situation arises that would cause only one person to be in the room, all individuals must exit until at least two can be inside. PC access and use must be monitored and logs of all key-loading must be maintained. These logs must be retained for a minimum of three years. The logs must be regularly reviewed by an authorized person who does not have access to the room or to the PC. The reviews must be documented. The logs must include but not be limited to: Logs of access to the room from a badge access system, Logs of access to the room from a manual sign-in sheet, Page 33 of 76

34 User sign-on logs on the PC at the operating system level, User sign-on logs on the PC at the application level, Logs of the device IDs and serial numbers that are loaded along with the date and time and the individuals performing the key-injection, Video surveillance logs. Cable attachments and the PC must be examined before each use to ensure the equipment is free from tampering. The PC must be started from a powered-off position every time key-loading activities occur. The software application must load keys without recording any clear-text values on portable media or other unsecured devices. Keys must not be stored except within an SCD. The personnel responsible for the systems administration of the PC (e.g., a Windows administrator who configures the PC s user IDs and file settings, etc.) must not have authorized access into the room they must be escorted by authorized key-injection personnel, and they must not have user IDs or passwords to operate the key-injection application. The key-injection personnel must not have system s administration capability at either the O/S or the application level on the PC. The PC must not be able to boot from external media (e.g., USB devices or CDs). It must boot from the hard drive only. Key-injection facilities must cover all openings on the PC that are not used for key-injection with security seals that are tamper-evident and serialized. Examples include but are not limited to PCMCIA, network, infrared and modem connections on the PC, and access to the hard drive and memory. The seals must be recorded in a log and the log must be maintained along with the other key-loading logs in a dual control safe. Verification of the seals must be performed prior to key-loading activities. If the PC application stores keys (e.g., BDKs or TMKs) on portable electronic media (e.g., smart cards), the media must be secured under dual control when not in use (e.g., in a dual control safe). If possible, instead of storing the key on those media, the key should be manually entered at the start of each key-injection session from components that are maintained under dual control and split knowledge. Note: For DUKPT implementations, the BDK should be loaded from components each time and this requires manual tracking of the device ID counter and serial numbers from the previous key-loading session. Key-injection facilities with PC applications that require passwords to be used to initiate decryption of keys on portable electronic media (e.g., smart cards) must ensure the passwords are maintained under dual control and split knowledge. Manufacturer s default passwords for PC-based applications must be changed. SCD equipment must be inspected to detect evidence of monitoring and to ensure that dual-control procedures are not Page 34 of 76

35 circumvented during key-loading. An SCD must transfer a plain-text secret or private key only when at least two authorized individuals are identified by the device (e.g., by means of passwords or other unique means of identification). Plain-text secret and private keys and key components must be transferred into an SCD only when it can be ensured that there is no tap at the interface between the conveyance medium and the cryptographic device that might disclose the transferred keys, and that the device has not been subject to any tampering which could lead to the disclosure of keys or sensitive data. Non-SCDs shall not be used in the loading of clear-text secret or private keys or their components, outside of a secure key-loading facility, as delineated in Annex B. For example, ATM controller (computer) keyboards shall never be used for the loading of clear-text secret or private keys or their components. The injection of key components from electronic medium to a cryptographic device (and verification of the correct receipt of the component is confirmed, if applicable) must result in either of the following: The medium is placed into secure storage, if there is a possibility it will be required for future re-insertion of the component into the cryptographic device, or All traces of the component are erased or otherwise destroyed from the electronic medium. For secret or private keys transferred from the cryptographic hardware that generated the key to an electronic key-loading device: The key-loading device must be a physically secure SCD, designed and implemented in such a way that any unauthorized disclosure of the key is prevented or detected; and The key-loading device must be under the supervision of a person authorized by management, or stored in a secure container such that no unauthorized person can have access to it; and The key-loading device must be designed or controlled so that only authorized personnel under dual control can use and enable it to output a key into another SCD. Such personnel must ensure that a key-recording device is not inserted between the SCDs; and The key-loading device must not retain any information that might disclose the key or a key that it has successfully transferred. The media upon which a component resides must be physically safeguarded at all times. Any tokens, EPROMs, or other key component holders used in loading encryption keys must be maintained using the same controls used in maintaining the security of hard copy key components. These devices must be in the physical possession of only the designated component holder and only for the minimum practical time. If the component is not in human-comprehensible form (e.g., in a PROM module, in a smart card, on a magnetic-stripe card, and so forth), it must be in the physical possession of only one entity for the minimum practical time until the component is entered into an SCD. Page 35 of 76

36 If the component is in human-readable form (e.g., printed within a PIN-mailer-type document), it must be visible only at one point in time to only one person (the designated component custodian) and only for the duration of time required for this person to privately enter the key component into an SCD. Printed key-component documents must not be opened until just prior to entry. The component must never be in the physical possession of an entity when any one such entity is or ever has been similarly entrusted with any other component of this same key Applicability Question Scope This question applies to: Key loading mechanisms and the process of loading all cryptographic keys for all ATMs, PIN pads, PIN entry devices, key generation devices and key loading devices. Key loading process of Master Keys and hierarchy keys used by the Host Security Modules that are part of the key injection platform. Key loading process of any keys used internally by the key injection platform. Key loading process of Master Keys and hierarchy keys used by a CA s Host Security Module. Key loading process of all Public and Private key pairs used in the remote key establishment and distribution scheme. Personal Computer (PC) based software applications without SCDs used for loading keys. Intent of Question To ensure: Security and integrity of keys during the key loading process into a SCD specifically to ensure no visual or electronic surveillance or monitoring occurs during the key transfer process. Secrecy and the integrity of keys transported from the location of generation to the location of loading in an electronic key loading device (KLD). Security of the KLD. That the KLD is a SCD. The KLD is designed or controlled so it cannot output a key into another SCD except under dual control. Compensating security controls exist for PC based software applications without SCDs that are used for loading keys. 1. Interview appropriate personnel and review documentation to determine the procedures for key loading to PEDs, key loading devices, HSMs that are part of the key loading platform, and CA s HSMs. Review any logs of key loading. Ensure all documentation supports the key loading process is in accordance with this question's requirements Page 36 of 76

37 (e.g., key transfer devices require two authorized identifications before transfer, procedures to ensure there are no taps, key- loading device requirements stated above, and dual control and split knowledge references above, and compensating controls exist for PC based key loading software platforms without SCDs, etc.). 2. Observe/demonstration/walk through of the usage of any equipment (terminals, PIN pads, key guns, etc.) that is part of the key loading process. 3. Inspect the environment(s) where key loading occurs. 4. Ensure cameras cannot monitor the entering of key components. 5. Ensure dual control mechanisms and dual control custody of the key loading devices and of the key loading process. 6. Ensure the SCD equipment is inspected for evidence of monitoring. Electronic monitoring would normally be accomplished by attaching taps on the cable between the PIN pad and the encryptor board or by tapping the line between the ATM and the host. Physical inspection of the device should be performed to identify and remove any such devices. 7. Ensure there are no default dual control mechanisms (e.g., default passwords usually printed in the vendor's manual in a key loading device). 8. Validate that key loading procedures include instructions to delete the keys from the key loading device after successful transfer. 9. Ensure KIF using PC based key loading software platforms uses a SCD 10. Ensure the injection system (hardware and software) is standalone Inspect the computer for LAN/WAN connections, wireless connections, modems, etc. and inquire how these communication paths are disabled. Ensure the PC is dedicated to only key loading functions by examining the programs that are installed on the PC to verify there are no other executables, and that all unnecessary services (e.g., telnet, etc.) are disabled. Ensure the PC is in a physically secure room dedicated to key loading activities only. Validate that mechanisms are implemented to enforce a minimum of two individuals in the room at all times. Review all logs of PC access and key loading and ensure they exist for the prior 3 years, that they are reviewed regularly by an authorized person with no access to the room or PC, and that the reviews are documented. Ensure the logs include badge access logs, operating system user sign-on logs, application user sign-on logs, video surveillance logs, and logs of the device IDs and serial numbers that are loaded along with the date and time and the individuals performing the key injection. Validate procedures exist and are followed to examine cable attachments and the PC prior to each use to ensure the equipment is free from tampering. Validate procedures exist and are followed to ensure the PC is started from a powered-off position every time key loading activities occur (observe this during the key loading demonstration). Page 37 of 76

38 Review the PC user IDs and the badge access system s authorized list of persons with access to the room, and interview key custodians and operating system administrators to ensure that personnel responsible for the PC systems administration do not have authorized access into the room and that they do not have user IDs or passwords to operate the key injection platform, and that the key injection personnel do not have systems administration capability on the PC. Validate the PC cannot boot from floppies or CDs. Validate all the PC openings specified above are covered with tamper-evident, serialized security seals. Validate the seals are recorded in a log that is stored in a dual control safe and that verification of the seals is performed prior to key loading activities. If the PC application stores keys on diskette or smart cards, validate those devices are stored under dual control when not in use. Validate passwords are maintained under dual control and split knowledge. Validate manufacturer s default passwords have been changed. Page 38 of 76

39 Key-Injection Facility Security Requirement 14. All hardware and passwords used for key-loading must be managed under dual control. International/Industry Standard Key-injection facilities must ensure that the key-injection application passwords and user IDs are managed under dual control. Also, the hardware used for key-injection must be managed under dual control. Vendor default passwords must be changed. Any hardware used in the key-loading function must be controlled and maintained in a secure environment under dual control. Use of the equipment must be monitored and a log of all key-loading activities maintained for audit purposes. All cable attachments must be examined before each application to ensure they have not been tampered with or compromised. Passwords must be managed such that no single individual has the capability to enable key loading. Any physical (e.g., brass) key(s) used to enable key-loading must not be in the control or possession of any one individual who could use those keys to load secret or private cryptographic keys under single control. Applicability Question Scope This question applies to: Key loading equipment, specifically to ensuring dual control over the equipment and/or any enabling passwords used with the key loading devices and systems. It also applies to key loading equipment used to load: all ATMs, PIN pads, and PIN entry devices. Key loading equipment used to load the Master Keys and hierarchy keys used by the Host Security Modules that are part of the key injection platform. Key loading equipment used to load any keys used internally by the key injection platform. Key loading equipment used to load Master keys and hierarchy keys used by a CA s Host Security Module. Key loading equipment used to load all Public and Private key pairs used in the remote key establishment and distribution schemes Intent of Question To ensure the secrecy and integrity of keys during the key loading process, specifically to contribute to this by ensuring dual control over the use of key loading devices. 1. Interview appropriate personnel and review documentation to determine the procedures for the use of any key loading equipment or device enablers that are used for either HSMs that are part of the key loading platform, and CA s HSMs or PEDs. Examine emergency procedures in order to determine whether dual control rules are violated under those Page 39 of 76

40 circumstances. 2. Inspect storage locations of key loading equipment (including physical brass keys used to enable loading, passwords, key guns, etc.) to ensure enforcement of dual control (procedural controls are not adequate). 3. Review logs of equipment usage to determine documentation of dual custody and that only authorized individuals have access. 4. Ensure dual control mechanisms and dual control custody of the key loading devices and of the key loading process. 5. Ensure the SCD equipment is inspected for evidence of monitoring. 6. Ensure there is no default dual control mechanisms (e.g., default passwords usually printed in the vendor's manual in a key loading device). 7. Verify that if passwords are used for key loading, they are under dual control, and that no one person has access to the full password. Page 40 of 76

41 Key-Injection Facility Security Requirement 15. The loading of keys or key components must incorporate a validation mechanism such that the authenticity of the keys is ensured and it can be ascertained that they have not been tampered with, substituted, or compromised. International/Industry Standard A cryptographic-based validation mechanism helps to ensure the authenticity and integrity of keys and components (e.g., testing-key check values, hashes, or other similar unique values that are based upon the keys or key components being loaded). See ISO Recorded or displayed key-component check values and key check values shall not exceed six hexadecimal characters in length. The public key must have its authenticity and integrity ensured. In order to ensure authenticity and integrity, a public key must be encrypted, or if in plain-text form, must: Be within a certificate; or Be within a PKCS#10; or Be within a SCD; or Have a MAC (message authentication code) created using the algorithm defined in ISO Applicability Question Scope This question applies to: Mechanisms (e.g., key check values, hashes, etc.) that validate the keys and key components that are loaded. Key loading validation mechanisms used to load all cryptographic keys for all ATMs, PIN pads, and PIN entry devices, Key loading validation mechanisms used to load Master Keys and hierarchy keys used by the Host Security Modules that are part of the key injection platform. Key loading validation mechanisms used to load any keys used internally by the key injection platform Key loading validation mechanisms used to load Master Keys and hierarchy keys used by a CA s Host Security Module. Key loading validation mechanisms used to load all Public and Private key pairs used in the remote key establishment and distribution scheme. Intent of Question To ensure the integrity and authenticity of keys after loading. To be able to validate that the key on the system and in the PED is in fact the key that is desired to be on the system and in the PED, (i.e., to ensure that the key was not tampered with, substituted, or compromised during the loading process).. Page 41 of 76

42 1. Interview appropriate personnel and review documentation (including both logs and procedural) to determine the mechanisms used to validate the authenticity of the keys loaded to HSMs that are part of the key loading platform, and CA s HSMs and PEDs. 2. Review vendor documentation to determine which methods of verification for key loading are supported. 3. Observe a demonstration of the key loading process. 4. If check values are used, compare key check values against those for known, default, test, predictable, easily guessed or simple keys. Such check values are often printed in vendor manuals. 5. Verify check sum digits do not exceed six hexadecimal characters. 6. If the public key scheme includes the embedding of valid authorized key distribution host certificates in EPPs/PEDs, then verify that the loading of these certificates, if done at key injection time, includes procedures to ensure only legitimate key distribution host certificates are loaded. Review documentation, interview key injection personnel, and witness the loading process to validate the authenticity of the certificates loaded into the EPPs/PEDs. 7. If the Public/Private key pairs are generated external to the device that uses the key pair, validate that the key loading process provides for key protection. Review documentation, interview key injection personnel, and witness a key loading process to validate that the key pair is not tampered with, substituted or compromised during the transfer from the generation device to the target device. Also validate that the key pair is immediately deleted from the generation device (to ensure no other device can be loaded with the key pair) after successful loading to the target device. 8. Verify that public keys exist in only the allowed storage forms.- certificates, PKCS #10s, in a secure cryptographic device, encrypted, or have a MAC (Message Authentication Code) created using the algorithm defined in ISO Verify that validation of authentication credentials occurs immediately prior to any key establishment for both initial and any subsequent key exchanges in remote key distribution environments. Page 42 of 76

43 Key-Injection Facility Security Requirement 16..Documented procedures must exist and be demonstrably in use (including audit trails) for all key-loading activities. International/Industry Standard Written procedures must exist and all parties involved in cryptographic key-loading must be aware of those procedures. All keyloading events performed by a key-injection facility must be documented. Applicability Question Scope This question applies to written procedures that describe how all cryptographic keys are loaded. This applies to all keys loaded into all ATMs, PIN pads, PIN entry devices, host security modules (including CA s HSMs) and key loading devices. Intent of Question To ensure that: Adequate and appropriate documented written procedures exist for the loading of all cryptographic keys. Documented procedures are followed and keys are not loaded in any other (especially non- compliant) manner. 1. Review existing documentation for completeness. See Requirement 7 for details. Page 43 of 76

44 Control Objective 5 Prevent Unauthorized Usage Key-Injection Facility Security Requirement 18. Procedures must exist to prevent or detect the unauthorized substitution (unauthorized key replacement and key misuse) of one key for another or the operation of any cryptographic device without legitimate keys. International/Industry Standard Key-injection facilities must implement controls to protect against unauthorized substitution of keys and to prevent the operation of devices without legitimate keys. Examples include but are not limited to: All key-loading must be performed using dual control and split knowledge. Controls must be in place to prevent and detect the loading of keys by any one single person. Controls include physical access to the room, logical access to the key-loading application, video surveillance of activities in the key-injection room, physical access to secret or private cryptographic key components or shares, etc. All devices loaded with keys must be tracked at each key-loading session by serial number. Unloaded devices must be managed in accordance with Requirement 29. Key-injection facilities must use something unique about the EPP or POS device (e.g., serial number) when deriving the key (e.g., DUKPT, TMK) injected into it. Multiple synchronization errors in PIN translation may be caused by the unauthorized replacement or substitution of one stored key for another or the replacement or substitution of any portion of a TDEA key, whether encrypted or unencrypted. Procedures for investigating repeated synchronization errors must exist to help reduce the risk of an adversary substituting a key known only to them. To prevent substitution of a compromised key for a legitimate key, key-component documents that show signs of tampering must result in the discarding and invalidation of the component and the associated key at all locations where they exist. TDEA keys should be managed as key bundles at all times, e.g., using TR-31. The bundle and the individual keys should: Have integrity whereby each key in the bundle has not been altered in an unauthorized manner since the time it was generated, transmitted, or stored by an authorized source; Be used in the appropriate order as specified by the particular mode; Be considered a fixed quantity in which an individual key cannot be manipulated while leaving the other two keys unchanged; and Cannot be unbundled for any purpose. Applicability Question Scope This question applies to the procedures that need to exist to protect against unauthorized key substitution for all cryptographic keys for all ATMs PIN pads, PIN entry devices, key generation devices, and key loading devices. This question also refers to protections against substitution of Master Keys and hierarchy keys used by Host Security Page 44 of 76

45 Modules that are part of the key injection platform or used by a CA s Host Security Module, and any keys used internally by the key injection platform, and all Public and Private key pairs used in the remote key establishment and distribution scheme. Intent of Question To: Prevent and detect the unauthorized substitution of keys. Prevent misuse of a SCD to determine keys and PINs by exhaustive trial and error. Ensure procedures are executed when multiple synchronization errors occur. 1. Interview appropriate personnel and review techniques and procedural documentation pertaining to preventing key substitution. 2. Ensure procedures/policy does not allow CA s HSMs to remain in the authorized state when connected to online production systems. 3. Ensure that keys no longer needed are destroyed, especially those keys used to encipher other keys for distribution. Ensure controls exist over the access to and use of devices (e.g., QKTs and SCTs) used to create cryptograms. 4. In the case of paper components, review procedures and discuss with key custodians the steps that are taken whenever a key component appears to have been tampered with. These procedures must include a requirement to immediately replace any key whose components may have been tampered with as well as any key ever stored or transported under the suspect key. 5. Validate that all key loading is performed using dual control and split knowledge. Verify there are controls for physical access to the room, logical access to the key loading application, video surveillance of activities in the key injection room, physical access to cryptographic key components, etc. 6. Validate that all devices loaded with keys are tracked at each key loading session by serial number. Inspect logs of key loading activities that were recently completed. 7. Validate that something unique about the EPP (e.g., the serial number) is used when deriving the key (e.g., DUKPT, TMK) injected into it. Witness a key loading session and verify the serial number or something unique is used in the process. 8. See question 29 to validate that unloaded devices are securely managed Page 45 of 76

46 Key-Injection Facility Security Requirement 19. Cryptographic keys must be used only for their sole intended purpose and must never be shared between production and test systems. Check what the logical vendor security requirements say on this offline pin generation reqs. International/Industry Standard Key-injection facilities must have a separate test system for the injection of test keys. Test keys must not be injected using the production platform, and test keys must not be injected into production equipment. Production keys must not be injected using a test platform, and production keys must not be injected into equipment that is to be used for testing purposes. Keys used for signing of test certificates must be test keys. Keys used for signing of production certificates must be production keys. Encryption keys must only be used for the purpose they were intended (e.g., key-encryption keys must not be used as PINencryption keys). This is necessary to limit the magnitude of exposure should any key(s) be compromised. Using keys only as they are intended also significantly strengthens the security of the underlying system. MFKs and their variants used by host processing systems for encipherment of keys for local storage shall not be used for other purposes, such as key conveyance between platforms that are not part of the same logical configuration. Private keys shall only be used to create digital signatures and to perform decryption operations. Private keys shall never be used to encrypt other keys. Keys must never be shared or substituted in a processor s production and test systems. Except by chance, keys used in production must never be used in testing, and keys used in testing must never be used in production. Note: If a business rationale exists, a production platform (HSMs and servers/stand-alone computers) may be temporarily used for test purposes. However, all keying material must be deleted from the HSM(s) and the key injection server/computer platforms prior to testing. Subsequent to completion of testing, all keying materials must be deleted, the server/computer platforms must be wiped and rebuilt from read-only media, and the relevant production keying material restored using the principles of dual control and split knowledge as stated in these requirements. At all times the HSMs and servers/computers must be physically and logically secured in accordance with these requirements. Applicability Question Scope This question applies to the procedures that need to exist to protect against unauthorized key substitution for all cryptographic keys for all ATMs PIN pads, PIN entry devices, key generation devices, and key loading devices. This Page 46 of 76

47 question also refers to protections against substitution of Master Keys and hierarchy keys used by Host Security Modules that are part of the key injection platform or used by a CA s Host Security Module, and any keys used internally by the key injection platform, and all Public and Private key pairs used in the remote key establishment and distribution scheme. Intent of Question To: Prevent and detect the unauthorized substitution of keys. Prevent misuse of a SCD to determine keys and PINs by exhaustive trial and error. Ensure procedures are executed when multiple synchronization errors occur. 1. Using the network schematic from the preliminary step, interview responsible personnel to determine which keys exist at various points in the injection process, whether any keys are used to encipher other keys and whether keys are shared between production and test. 2. Obtain check values for master file keys for both production and test environments and ensure they are different values. This applies to CAs also. 3. Examine the cryptograms and key check values in both the production and test systems to ensure that all keys are different. Examine hash and/or fingerprint values in both production and test systems to ensure asymmetric keys are different. 4. Examine system documentation to verify information provided during interviews this is mandatory if personnel have indicated the use of unique keys. Coordinate this with steps in question Examine certificates to ensure that production keys have been issued production certificates (i.e., that the CA has used a production key to sign the certificate issued for production public keys). Verify that a test key hierarchy exists for obtaining test certificates from the CA signed by a test key. 6. Observe the process and determine that key pairs are not reused for certificate renewal or replacement. 7. Validate that X.509 compliant certificate extensions are used for restricting and controlling the use of public and private keys. If X.509 certificates are not used, obtain information on what techniques are used to produce the same result. 8. Verify that private keys are only used for digital signatures or decryption. 9. If an offline key generation platform exists, ensure that the MFK is different than what is defined in host processing system by checking each has a different key check value. Page 47 of 76

48 Key-Injection Facility Security Requirement 20. All secret and private cryptographic keys ever present and used for any function (e.g., keyencipherment or PINencipherment) by a transactionoriginating terminal (PED) that processes PINs must be unique (except by chance) to that device. International/Industry Standard Key-injection facilities must ensure that unique keys are loaded into each device. The same key(s) must not be loaded into multiple devices. Key-injection facilities that load DUKPT keys must use separate BDKs for different entities. Key-injection facilities that load DUKPT keys for various terminal types for the same entity must use separate BDKs per terminal type if the terminal IDs can be duplicated among the multiple types of terminals. In other words, the key-injection facilities must ensure that any one given key cannot be derived for multiple devices except by chance. Any key used to encrypt a PIN in a PED must be known only in that device and in security modules at the minimum number of facilities consistent with effective system operations. Disclosure of the key in one such device must not provide any information that could be feasibly used to determine the key in any other such device. In a master/session key approach, the master key(s) and all session keys must be unique to each cryptographic device. If a transaction-originating terminal interfaces with more than one acquirer, the transaction-originating terminal SCD must have a completely different and unique key or set of keys for each acquirer. These different keys, or set of keys, must be totally independent and not variants of one another. Keys that are generated by a derivation process and derived from the same Base Derivation Key must use unique data for the derivation process so that all such cryptographic devices receive unique initial secret keys. Entities processing or injecting DUKPT or other key derivation methodologies on behalf of multiple acquiring financial institutions must use different Base Derivation Keys for each financial institution. The processing entity may share one or more Base Derivation Keys for merchants that are sponsored by the same acquirer. Remote Key-Establishment and Distribution Applications The following requirements apply to key-injection facilities participating in remote key-establishment and distribution applications: Keys must be uniquely identifiable in all hosts and EPPs/PEDs. Keys must be identifiable via cryptographically verifiable means (e.g., through the use of digital signatures or key check values). Key pairs must be unique per device including key-distribution hosts (except as otherwise provided for), EPPs and POS PEDs. Page 48 of 76

49 Applicability Question Scope This question applies to: All cryptographic keys for all ATMs, PIN pads, and PIN entry devices (note this applies only to keys used by a transaction-originating device). Keys that encrypt PINs and to keys that encrypt other keys Intent of Question To: Compartmentalize the risk associated with disclosure of a device key, so that the risk is limited to just that one device, and so that the discovery of that one key does not provide information to determine the key in any other device. Eliminate the use of known keys. To avoid the use of default, test, predictable, easily guessed or simple keys (e.g., abcdef, alternating 0s and 1s, etc.). 1. Interview responsible personnel to determine which keys are shared between multiple PEDs. Examine system documentation to verify information provided during interviews. This is mandatory if personnel have indicated the use of unique keys per PED: 2. Obtain check values for a sample of PEDs injected keys (both TMKs and PEKs) to verify key uniqueness. 3. Obtain hash values and/or fingerprint values for a sample of PEDs injected keys (public/private keys) to verify key uniqueness. Review KIF system design documentation or source code (or any program/compiled files) for uniqueness of cryptograms of injected keys. 4. Examine cryptograms of injected keys (if available). 5. Corroborate this information to what is determined during review of key generation, storage and destruction. 6. Have the technical staff sort all of the key encrypting key cryptograms for every injected KEK, and sort the entire PIN encrypting key cryptograms for every injected PEK, if available from the key injection system. Ask for a printout of the sorted information including the terminal ID numbers and check digits if available. Compare all PIN encrypting key cryptograms to ensure there are no duplicates. Then compare all key encrypting key cryptograms to ensure there are no duplicates. Note: A PIN key may be the same as an encrypting key, but the cryptograms will be different if variants of the MFK are used to encipher different key types, although the check digit will be the same. Also, it is still possible to compare all PIN Page 49 of 76

50 encrypting keys' cryptograms encrypted by the same value (i.e., MFK variant) to see if they are duplicates of each other, and then to separately compare all key encrypting keys' cryptograms encrypted by the same value (i.e., MFK variant) to see if they are duplicates of each other. 7. Compare key check values against those for known, default, test, predictable, easily guessed or simple keys. Such check values are often printed in vendor manuals. 8. For processors with multiple customers, ensure that BDKs are unique for each of the financial institutions by verifying check digits are different. 9. Compare key check values against those for known, default, test, predictable, easily guessed or simple keys. Such check values are often printed in vendor manuals. 10. Perform a comparison check between the number of devices being injected and the number of cryptographic keys. If there are fewer keys than devices, it is clear that the same key is being used in several devices. 11. Examine "emergency" procedures i an attempt to identify situations where otherwise compliant procedures are violated. Ensure these procedures support this question's requirements for unique PED keys. For Remote Key-Establishment and Distribution Applications 12. Verify that keys are in all hosts and EPPs/PEDs. Keys must be identifiable via cryptographically verifiable means (e.g., through the use of digital signatures or key check values) 13. Verify the Key pairs are also unique per device including key-distribution hosts (except as otherwise provided for), EPPs and POS PEDs. Page 50 of 76

51 Control Objective 6 Secure Key Administration Key-Injection Facility Security Requirement 21.. Secret keys used for enciphering PIN-encryption keys, or for PIN encryption, or private keys used in connection with remote keydistribution implementations, must never exist outside of SCDs, except when encrypted or securely stored and managed using the principles of dual control and split knowledge. International/Industry Standard Key-injection facilities must ensure that KEKs and PIN encryption keys do not exist outside of SCDs except when encrypted or stored under dual control and split knowledge. Some key-injection platforms use Personal Computer (PC) based software applications whereby clear-text secret and/or private keys and/or their components exist in unprotected memory outside the secure boundary of an SCD for loading keys. Such systems do not therefore meet this requirement. Such systems have inherent weaknesses that, if exploited, may cause the unauthorized disclosure of components and/or keys. The exploitation of some of the weaknesses could be possible without collusion. Therefore, key-injection facilities that use PC-based key-loading software platforms whereby clear-text secret and/or private keys and/or their components exist in unprotected memory outside the secure boundary of an SCD must minimally implement the compensating controls outlined in Requirement 13. Effective implementation of these principles requires the existence of barriers beyond procedural controls to prevent any custodian (or non-custodian for any individual component) from gaining access to all key components. An effective implementation would have physically secure and separate locking containers that only the appropriate key custodian (and their designated backup) could physically access. Components for a specific key that are stored in separate envelopes, but within the same secure container, place reliance upon procedural controls and do not meet the requirement for physical barriers. Furniture-based locks or containers with a limited set of unique keys are not sufficient to meet the requirement for physical barriers. Key components may be stored on tokens (e.g., PC cards, smart cards, and so forth). These tokens must be stored in a special manner to prevent unauthorized individuals from accessing the key components. For example, if key components are stored on tokens that are secured in safes, more than one person might have access to these tokens. Therefore, additional protection is needed for each token (possibly by using tamper-evident, authenticable envelopes) to enable the token s owner to determine whether a token was used by another person. In particular, key components for each specific custodian must be stored in separate secure containers. If a key is stored on a token and a PIN or similar mechanism is used to access the token, only that token s owner (or designated backup) must have possession of both the token and its corresponding PIN. Printed or magnetically recorded key components must reside only within tamper-evident, authenticable, sealed Page 51 of 76

52 envelopes so that the component cannot be ascertained without opening the envelope. DES keys that are used to encipher other keys or to encipher PINs, and which exist outside of an SCD, must be enciphered using keys of equal or greater strength as delineated in Annex C. For example: The TDEA using at least double-length keys or RSA using a key modulus of at least 1024 bits. A double- or triple-length DES key must not be encrypted with a DES key of a shorter length. Symmetric secret keys may be enciphered using public-key cryptography for distribution to PEDs as part of a keyestablishment protocol as defined in Requirement 12. Applicability Question Scope This question applies to all secret and private used to encrypt PINs and to all keys (symmetric and asymmetric) used to encrypt those keys. Intent of Question To ensure clear keys are not exposed across network links or on databases, software programs, computer memory, electronic media, or system logs, backup tapes, etc. 1. Using the network schematic, interview responsible personnel to determine which keys are stored as components and on which type of media they are stored (paper, PROM, smartcard, etc.). Keys that will probably be managed as components include ATM initialization keys (TMKs), Base derivation keys (BDKs), Master keys and Key Exchange Key components, and possibly asymmetric keys stored using a recognized (e.g., Shamir) secret sharing scheme (not really components ). 2. Examine documented procedures to determine the algorithms and key sizes used for storing encrypted keys. 3. Ensure keys and key components outside of SCDs are protected by keys whose strength conforms to Annex C. 4. Examine vendor documentation describing options for injection of key encipherment keys (both symmetric and asymmetric). Corroborate this with information gathered during the interview process and procedural documentation provided by the entity under review. 5. Physically verify the location of all key components, including the inspection of any containers for those components. For each of the keys identified in the first paragraph above under Audit Technique, identify the key custodians and perform a physical inventory to verify that each symmetric key is managed as two or more fulllength components. Be alert for instances where both components of a symmetric key are stored together or where Page 52 of 76

53 the non-random test value is not stored at all, but rather known to a number of current and former employees and third party staff. 6. Identify all individuals with access to components and trace that access to key custodian authorization forms. 7. Examine logs of access to the key components to ensure only authorized custodians access components, PROMs, smartcards, etc., including verification of tamper evident serial numbers. 8. Ensure there are no clear keys stored in containers, in databases, on floppy disks, and in software programs. 9. Ensure key components are not XOR'ed or otherwise combined in software programs. 10. Inspect key-loading procedures for HSMs and PEDs to ensure that no key component values have been recorded in inappropriate places. 11. If the key injection platform uses PC based software applications without SCDs for loading keys, validate the compensating controls outlined in question 13 are implemented. 12. Validate RSA keys that are injected have a key modulus of at least 1024 bits. 13. Validate that private keys used to sign certificates, certificate status lists, messages or secret key protection only exist in one of the above outlined approved forms. Page 53 of 76

54 Key-Injection Facility Security Requirement 22.. Procedures must exist and be demonstrably in use to replace any known or suspected compromised key and its subsidiary keys (those keys enciphered with the compromised key) to a value not feasibly related to the original key International/Industry Standard Key-injection facilities must have written procedures to follow in the event of compromise of any key associated with the keyinjection platform and process. Written procedures must exist and all parties involved in cryptographic key-loading must be aware of those procedures. All key-compromise procedures must be documented. Key components must never be reloaded when there is any suspicion that either the originally loaded key or the device has been compromised. If suspicious alteration is detected, new keys must not be installed until the SCD has been inspected and assurance reached that the equipment has not been subject to unauthorized physical or functional modification. A secret or private cryptographic key must be replaced with a new key whenever the compromise of the original key is known or suspected. In addition, all keys encrypted under or derived using that key must be replaced with a new key within the minimum feasible time. The replacement key must not be a variant of the original key, or an irreversible transformation of the original key. Procedures must include a documented escalation process and notification to organizations that currently share or have previously shared the key(s). The procedures must include a damage assessment and specific actions to be taken with system software and hardware, encryption keys, encrypted data, and so forth. The compromise of a key must result in the replacement and destruction of that key and all variants and non-reversible transformations of that key, as well as all keys encrypted under or derived from that key. Known or suspected substitution of a secret key must result in the replacement of that key and any associated keyencipherment keys. Specific events must be identified that would indicate a compromise may have occurred. Such events may include, but are not limited to: Missing cryptographic devices Tamper-evident seals or authenticable envelope numbers or dates and times not agreeing with log entries Tamper-evident seals or authenticable envelopes that have been opened without authorization or show signs of attempts to open or penetrate Indications of physical or logical access attempts to the processing system by unauthorized individuals or entities Failure to document that a secret or private key has been managed using the principles of dual control and split knowledge from its date of creation. Page 54 of 76

55 If attempts to load a secret or private key or key component into a cryptographic device fail, the same key or component must not be loaded into a replacement device unless it can be ensured that all residue of the key or component has been erased or otherwise destroyed in the original device. Prolonged use of a key increases the risk of its cryptanalytic compromise, depending upon, for example, implementation, key length, and availability of corresponding cipher texts/plain texts. Cryptoperiods for keys should be assigned to minimize this risk taking into account any additional risk associated with key changes. For example, recommended maximum cryptoperiods for the following TDES double-length keys, based on guidance in NIST SP800-57, ISO TR and NIST SP are: Type of Key Exchange Key Type Cryptoperiod Static PEK 12 months Dynamic KEK 3 years Dynamic PEK 12 hours (or UKPT) UKPT is the preferred option. Applicability Question Scope This question applies to the key compromise procedures that need to exist for all cryptographic keys for all ATMs, PIN pads, PIN entry devices, Key generation devices, and key loading devices. This question also refers to Master Keys and hierarchy keys used by the Host Security Modules that are part of the key injection platform, any keys used internally by the key injection platform, Master Keys and hierarchy keys used by a CA s host system, and all Public and Private key pairs used in the remote key establishment and distribution schemes. This question also applies to all subsidiary keys of compromised keys. Intent of Question To ensure a proactive, well-conceived, (not reactive) plan is established for expedient and efficient execution should a key compromise occur, in order to minimize the fraudulent activities and also the potential adverse effects to other organizations that may result due to key compromise, and to effectively communicate such to all interested parties. 1. Interview appropriate personnel and examine documented procedures to determine the adequacy of key compromise procedures. 2. If written procedures do not exist for replacing compromised keys, the institution is out of compliance. If written procedures do exist, review them to verify that all of the steps needed to generate and deploy a random key are in place. Also verify that for each key in the institution's key suite, the keys protected or transported under each key are listed. This allows the recovery team to assess the scope of the recovery Page 55 of 76

56 process. Ensure that the procedures include the names and/or functions of each staff Member assigned to the recovery effort, as well as phone numbers and the place where the team is to assemble. 3. Validate the existence of more than one root for key distribution management systems. Validate Root CAs support subordinate CAs. 4. Validate procedures for compromise of a CA includes procedures to revoke subordinate certificates and to notify affected entities. 5. Validate the CA s key compromise procedures include the steps that it will cease issuance of certificates if a compromise is known or suspected, and will perform a damage assessment, including a documented analysis of how and why the event occurred, and that the CA will determine whether to recall and reissue all signed certificates with a newly generated signing keys. 6. Validate that CAs have mechanisms to ensure that phony certificates cannot successfully be used. 7. Validate that compromised CAs will notify superior or subordinate CAs, and will ensure that subordinate CAs and KDHs will have their certificates reissued and distributed to them or will be notified to apply for new certificates. 8. Validate the minimum cryptographic strength for the CA will be for a Root to have a minimum RSA 2048 bits or equivalent, and subordinate CAs, EPP/PED devices and KDHs to have a minimum RSA 1024 bits or equivalent. 9. Validate that the expiration of EPP/PED keys are within twelve months after the expected end- of-life of the device, and that the expiration of KDH keys are every five years, unless another mechanism exists to prevent the use of a compromised KDH private key. 10. If the key injection platform uses PC based software applications without SCDs for loading keys, validate the compensating controls outlined in question 13 are implemented. 11. Validate RSA keys that are injected have a key modulus of at least 1024 bits. 12. Validate that private keys used to sign certificates, certificate status lists, messages or secret key protection only exist in one of the above outlined approved forms. Page 56 of 76

57 Key-Injection Facility Security Requirement 23.. Key variants must be used only in devices that possess the original key. Key variants must not be used at different levels of the key hierarchy e.g., a variant of a key-encipherment key used for key exchange must not be used as a working key or as a master file key for local storage. International/Industry Standard A secret key used to encrypt a PIN for interchange must never be used for any other cryptographic purpose. A key used to protect the PIN-encrypting key must never be used for any other cryptographic purpose other than key encipherment. Variants of the same key may be used for different purposes. Any variant of the PEK or a key used to protect the PEK must be protected in the same manner i.e., under the principles of dual control and split knowledge. An MFK used by host processing systems for encipherment of keys for local storage, and variants of the MFK must not be used external to the (logical) configuration that houses the MFK itself. Applicability Question Scope This applies to all cryptographic keys used for protection of PINs or establishment of those keys. Intent of Question To ensure there is a separation of keys to minimize misuse (for example so that HSMs use a mechanism that ensures that the commands recognize the purpose of the keys and force the use of separate types of keys). For example, some types of Hardware Security Modules (Atalla, Racal) do not encrypt other keys under the actual MFK, but under a variant. A variant of a key is the result of combining the key with a known value (typically done by the XOR process) to derive another key. Variants in HSMs are used to segregate cryptograms into groups based on the type of key being encrypted (Key Exchange Key, Working Key). It is a requirement that no variant of a key exist in any device that does not also contain the original key. 1. Interview responsible personnel to determine which host MFKs keys exist as variants. Note: Some HSMs may automatically generate variants or control vectors for specific keys, but it is still up to the entity to specify exact usage. 2. Review vendor documentation to determine support for key variants. 3. Examine the key creation and injection process to ensure that a unique key is generated and loaded into each PIN entry device and that it is not just a variant of an existing key and that variants of a key are not used as both working keys and key encipherment keys Page 57 of 76

58 Key-Injection Facility Security Requirement 24.. Secret and private keys and key components that are no longer used or have been replaced must be securely destroyed. International/Industry Standard Instances of keys (including components or shares) that are no longer used or that have been replaced by a new key must be destroyed. Clear-text key components or shares maintained on paper must be burned, pulped or shredded in a crosscut shredder. Keys on other storage-media types and in other permissible forms of a key instance (physically secured, enciphered, or components) must be destroyed following the procedures outlined in ISO or ISO In all cases, a third party other than the custodian must observe the destruction and sign an affidavit of destruction. The procedures for destroying keys that are no longer used or that have been replaced by new keys must be documented. Key-encipherment key components used for the conveyance of working keys must be destroyed after successful loading and validation as operational. Applicability Question Scope This questions applies to: All cryptographic keys used at all ATMs, PIN pads, PIN entry devices, Key generation devices and Key loading devices. Any keys used internally by the key injection platform. All Master Keys or hierarchy keys used by the Hardware Security Modules that are part of the key injection platform. All Master Keys or hierarchy keys used by a CA s Host Security Module. All Public and Private key pairs used in the remote key establishment and distribution scheme. Destruction of the components of secret and private keys. Intent of Question To prevent the misuse or mismanagement of the inactive key that could potentially lead to compromise of data and loss of integrity to the active system, and to minimize the damage to the active key hierarchy should the inactive key be compromised. Page 58 of 76

59 1. Interview responsible personnel and identify all keys that have been destroyed. 2. Examine all logs of destruction. Note: All key encipherment keys should be traceable to either storage or destruction. Examine key history logs and key destruction logs to determine compliance. 3. During the physical inventory of key components, be alert for any envelopes that cannot be accounted for on the list of keys expected to be stored in the container. It is not uncommon to find keys that were in use by entities that have been absorbed by merger or keys linking the institution to networks that no longer exist. Be particularly alert for Master File keys that have been replaced. Page 59 of 76

60 Key-Injection Facility Security Requirement 25.. Access to secret and private cryptographic keys and key material must be: a. Limited to a need-to-know basis so that the fewest number of key custodians are necessary to enable their effective use. b. Protected such that no other person (not similarly entrusted with that component) can observe or otherwise obtain the component. International/Industry Standard Limiting the number of key custodians to a minimum helps reduce the opportunity for key compromise. In general, the designation of a primary and a backup key custodian for each component is sufficient. This designation must be documented by having each custodian sign a Key Custodian Form. The form must specifically authorize the custodian and identify the custodian s responsibilities for safeguarding key components or other keying material entrusted to them. Each custodian must sign a Key Custodian Form acknowledging these responsibilities before receiving custody of key components or enablers (for example, PINs) for keys or their components. Key custodians must be free from undue influence in discharging their custodial duties. Key custodians sufficient to form the necessary threshold to create a key must not directly report to the same individual. For example, for a key managed as three components, at least two individuals must report to different individuals. In an m-of-n scheme, such as 3 of 5 key shares, no more than two key custodians can report to the same individual. In all cases, neither the direct reports, nor the direct reports in combination with their immediate supervisor shall possess a quorum of key components sufficient to form any given key. Applicability Question Scope This questions applies to: All cryptographic keys used at all ATMs, PIN pads, PIN entry devices, Key generation devices, key loading devices and key destruction. Any keys used internally by the key injection platform. All Master Keys or hierarchy keys used by the Host Security Modules that are part of the key injection platform. Master Keys and hierarchy keys used by a CA s Host Security Module. All Public and Private key pairs used in the remote key establishment and distribution scheme. Intent of Question To reduce the possibility of key compromise. This is ultimately to protect against PIN compromise. 1. Interview responsible personnel and identify all individuals with access to components and trace to key custodian authorization forms. Compare information to the individuals who open secure containers. Page 60 of 76

61 2. Review organization charts to ensure that key custodians report up through different chains of command. 3. Examine logs of access to keys and key materials to ensure only authorized custodians access components, PROMs, smartcards, etc., including verification of tamper evident serial numbers. 4. Validate that the systems have logical security controls that protect from unauthorized access, modification, substitution, insertion or deletion. Validate that all user access is directly attributable to an individual user, and are restricted to actions authorized for that role through the use of a combination of CA software, operating system and procedural controls. Examine the key injection platform s operating system and application to ensure they require individual user ID logon. Validate that any guest or group user IDs are disabled. 5. Obtain and examine CA s certificate security policy and certification practice statement and verify that all the above-mentioned requirements are included in those documents. Verify implementation of these (not just that the requirements are documented but that they are also implemented), for example, ensure the CA is offline by examining network connections, verify the CA and RA software updates are only done locally at the console, validate non-console access requires two-factor authentication by witnessing such a login by staff, etc. 6. Validate CAs require separation of duties for critical CA functions by witnessing operational procedures. 7. Examine and validate that unnecessary services and ports are disabled. Obtain documentation that supports the enablement of all active services and ports. 8. Validate default passwords are changed. 9. Examine audit trails and validate they include all of the above-mentioned requirements. 10. Validate records pertaining to certificate issuance and revocation are retained for the life of the associated certificate. 11. Validate the fields for recorded events include the minimum specified above in the requirements. 12. Validate the CA application logs are protected via a digital signature or symmetric MAC mechanism and that the mechanism is protected using a secure cryptographic device. 13. Verify the passphrase management techniques for RKD is a minimum of 8 characters. 14. Verify that the CA system components are protected by firewall(s) and intrusion detection systems. Page 61 of 76

62 Validate the firewalls are minimally configured as required above. 15. Verify the existence of network and host based Intrusion Detection Systems for the online CA systems, and that they protect the minimum servers stated above. Page 62 of 76

63 Key-Injection Facility Security Requirement 26.. Logs must be kept for any time that keys, key components, or related materials are removed from storage or loaded to an SCD. International/Industry Standard Key-injection facilities must maintain logs for the key management of all keys and keying material used in all keyloading sessions. These include keys and materials removed from safes and used in the loading process. At a minimum, the logs must include the date and time in/out, purpose of access, name and signature of custodian accessing the component, envelope number (if applicable). Applicability Question Scope This question applies to: All containers that secure cryptographic materials. Each such container must have a log. Contents of the containers may include cryptographic keys (components) used at all ATMs, PIN pads, PIN entry devices, Key generation devices and key loading devices. Any keys used internally by the key injection platform (if stored). All Master Keys or hierarchy keys used by Host Security Modules that are part of the key injection platform (if stored). All Master Keys or hierarchy keys used by a CA s Host Security Module (if stored). All Public and Private key pairs used in the remote key establishment and distribution scheme (if stored note they must be stored in one of the approved forms, i.e., private keys must not be stored in the clear). Intent of Question To maintain an audit trail of access to stored cryptographic materials. 1. Review logs for completeness. Inspect logs for any discrepancies. 2. Attempt to identify anomalies, such as a key that remained out of storage for an excessive time or an access that did not have a corresponding key load event. Page 63 of 76

64 Page 64 of 76

65 Key-Injection Facility Security Requirement 27.. Backups of secret and private keys must exist only for the purpose of reinstating keys that are accidentally destroyed or are otherwise inaccessible. The backups must exist only in one of the allowed storage forms for that key. International/Industry Standard The backup copies must be securely stored with proper access controls, under at least dual control, and subject to at least the same level of security control as the primary keys (see Requirement 21 i.e., within an SCD, unless encrypted or securely stored and managed using the principles of dual control and split knowledge). Backups (including cloning) must require a minimum of two authorized individuals to enable the process. Note: It is not recommended to retain backup copies. Applicability Question Scope This applies only to backup copies of keys and key components. Intent of Question To ensure the secrecy and integrity of keys, minimize the potential for their exposure, minimize the number of potential attack points and minimize the number of places where controls need to be established for the management of keys. 1. Interview responsible personnel and determine whether any copies of keys or their components exist for backup/recovery or disaster recovery purposes. 2. Inspect location of key components stored for backup/recovery or disaster recovery purposes. Determine that no obsolete key materials are being retained and that the storage arrangements are satisfactory. Inspect any key logs in order to identify any unusual access events. 3. Review disaster recovery plans and discuss them with the responsible staff. The intent here is to identify any circumstance that could cause normal security procedures to be breached. Page 65 of 76

66 Key-Injection Facility Security Requirement 28.. Documented procedures must exist and be demonstrably in use for all keyadministration operations. International/Industry Standard Written procedures must exist and all affected parties must be aware of those procedures. All activities related to key administration performed by key-injection facilities must be documented. This includes all aspects of key administration, as well as: Security awareness training. Role definition - nominated individual with overall responsibility. Background checks for personnel. Management of personnel changes, including revocation of access control and other privileges when personnel move. Applicability Question Scope This question applies to written procedures that describe how all cryptographic keys are administered. Intent of Question To ensure that: Adequate and appropriate documented written procedures exist for the administration of all cryptographic keys. Documented procedures are followed, and that keys are not administered in any other (especially non-compliant) manner. 1. Review existing documentation for completeness. See Question 7 for details. 2. Verify that CA operations are dedicated to certificate issuance and management. Validate that all physical and logical CA system components are separated from key distribution systems. 3. Obtain and verify that CA operators have developed a certification practice statement as defined above. 4. Obtain and verify procedures exist and are followed to validate identities of certificate requestors and recipients. 5. Validate that the verification includes all of the bullets specified above Page 66 of 76

67 Control Objective 7 Equipment Management Key-Injection Facility Security Requirement 29.. PINprocessing equipment (e.g., PEDs and HSMs) must be placed into service only if there is assurance that the equipment has not been substituted or subjected to unauthoriz ed modificatio ns or tampering prior to the loading of cryptograp hic keys and that precaution s are taken to minimize the threat International/Industry Standard Key-injection facilities must ensure that only legitimate, unaltered devices are loaded with cryptographic keys. Secure areas must be established for the inventory of PEDs that have not had keys injected. The area must have extended walls from the real floor to the real ceiling using sheetrock, wire mesh, or equivalent. Equivalence can be steel cages extending floor to real ceiling. The cages can have a steel cage top in lieu of the sides extending to the real ceiling. The cages must have locks (with logs) or badge control with logging for entry. HSMs and PEDs must be placed into service only if there is assurance that the equipment has not been subject to unauthorized modification, substitution, or tampering or is otherwise subject to misuse. To achieve this, controls must exist to protect secure cryptographic devices from unauthorized access before, during, and after installation. Access to all cryptographic hardware must be documented, defined, and controlled. Cryptographic devices must not use default keys or data. A documented security policy must exist that specifies personnel with authorized access to all secure cryptographic devices. Unauthorized individuals must not be able to access, modify, or substitute any secure cryptographic device. A documented chain of custody must exist to ensure that all cryptographic hardware is controlled from its receipt through its installation and use. Controls must ensure that all installed hardware components are from a legitimate source. Dual-control mechanisms must exist to prevent substitution of secure cryptographic devices, both in service and spare or backup devices. Procedural controls, which may be a combination of physical barriers and logical controls, may exist to support the prevention and detection of substituted cryptographic devices but must not supplant the implementation of dual-control mechanisms. This requires physical protection of the device up to the point of key-insertion or inspection, and possibly testing of the device immediately prior to key-insertion. Techniques include, but are not limited to, the following: Cryptographic devices are transported from the manufacturer s facility to the place of key- Page 67 of 76

68 of compromis e once deployed. insertion using a trusted courier service. The devices are then securely stored at this location until key-insertion occurs. Cryptographic devices are shipped from the manufacturer s facility to the place of keyinsertion in serialized, counterfeit-resistant, tamper-evident, authenticable packaging. The devices are then stored in such packaging, or in secure storage, until key-insertion occurs. The manufacturer s facility loads into each cryptographic device a secret, device-unique transport-protection token. The SCD used for key-insertion has the capability to verify the presence of the correct transport- protection token before overwriting this value with the initial key that will be used. Applicability Question Scope This applies to all cryptographic equipment from the time of manufacture or removal of service to the time of initial key loading. Intent of Question To: Determine that only legitimate equipment is used and is operating properly and that equipment has not been subject to unauthorized modifications/tampering prior to loading keys. Prevent the ability to monitor and gain knowledge of keys and components during loading and use. Prevent equipment awaiting deployment from being tampered with prior to possessing secret keys that would zeroized upon tamper 1. Examine documentation and interview appropriate personnel. To ensure that: Devices are not deployed into production using default or test keys or data. Physical inspection and testing of the equipment occur immediately prior to key loading. Procedures ensure that inventory practices accurately track cryptographic equipment, including devices used for key loading. The equipment is physically protected to prevent or detect access by unauthorized personnel from the time of manufacture or removal from service to the time of initial key loading. For example: o Bonded carrier. o Device Authentication code injected by terminal vendor and verified by the terminal deployer. o Tamper evident packaging. 2. Review all written purchasing, receipt and deployment procedures. It is crucial that these procedures include a step that verifies the actual machine serial number against the serial number from the shipping waybill or manufacturer's invoice. Page 68 of 76

69 Validate the documents used for this process were not shipped with the equipment i.e., that they were sent via a separate communication channel. Then discuss what pre-installation inspections take place. These should include both physical and functional tests as well as a thorough visual inspection. 3. Review how equipment is received and where it is "staged." It should remain in the original packaging until it is installed, unless it is received and staged at a secure facility. Be alert to gaps in the process that would allow an adversary to tamper with a device before it is placed into service. 4. Verify there are explicit requirements to guard against post-deployment compromise or modification. 5. Ensure there are procedures in use to ensure security for undeployed PEDs with or without cryptographic keys. 6. Ascertain how serial numbers are loaded to the institution's asset register in order to determine if the identity of the installed device is known at the time of installation, or only later. Page 69 of 76

70 Key-Injection Facility Security Requirement 30.. Procedures must exist that ensure the destruction of all cryptographic keys and any PINs or other PINrelated information within any cryptographic devices removed from service. International/Industry Standard Key-injection facilities must have procedures to ensure keys are destroyed in cryptographic devices removed from service. This applies to any SCDs (e.g., HSM) used in the key-injection platform, as well as to any devices that have been loaded with keys and securely stored or warehoused on site that are subsequently deemed to be unnecessary and never to be placed into service. If a key-injection facility receives a used device to reload with keys, procedures shall ensure that old keys that may be in the device are destroyed prior to loading of new keys. (The used device should have had its keys destroyed when it was removed from service, but this is a prudent secondary check that the keys were destroyed). If an SCD has been removed from service, all keys stored within the device that have been used (or potentially could be) for any cryptographic purpose must be destroyed. All critical initialization, deployment, usage, and decommissioning processes e.g., key- or component-loading, firmware- or software-loading, and verification and activation of anti-tamper mechanisms must impose the principles of dual control and split knowledge. Key and data storage must be zeroized when a device is decommissioned. If necessary to comply with the above, the device must be physically destroyed so that it cannot be placed into service again, or allow the disclosure of any secret data or keys. Applicability Question Scope This question applies to all SCDs that are removed from service, including HSMs used in the key injection platform, as well as any devices that have been loaded with keys and securely stored or warehoused on site that are subsequently deemed to be unnecessary and never to be placed into service. Intent of Question To protect against the unauthorized use of a production-cryptographically-capable device. To protect against the disclosure of cryptographic keys and ultimately the disclosure of PINs. 1. Interview appropriate personnel and review documentation of procedures to ensure that a proactive practice exists to ensure that cryptographic devices removed from service have all keys and keying materials destroyed. Page 70 of 76

71 2. Ensure that this process is also performed on all equipment being returned for repair. 3. ATMs and PIN pads removed from service can retain cryptographic keys (including PIN Encryption keys) in battery-backed RAM for days or weeks. Proactive key removal procedures must be in place to delete all such keys from equipment being removed from the network. 4. Host/Hardware Security Modules can also retain keys and of course, the Master File key is resident within these devices. Therefore, proactive key removal procedures must also be in place for HSMs. Page 71 of 76

72 Key-Injection Facility Security Requirement 31. Any SCD capable of encrypting key and producing cryptograms (i.e., an HSM or keyinjection/loading device) of that key must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following: a. Dual access controls are required to enable the keyencryption function. b. Physical protection of the equipment (e.g., locked access to it) under dual control. c. Restriction of logical access to the equipment. International/Industry Standard Key-injection facilities must ensure protection against unauthorized use for SCDs (e.g., HSMs) used in the keyinjection platform that are capable of encrypting a key and producing cryptograms of that key. The facility must implement a secure area (i.e., room) for key injection. This key injection room shall: 1. Exist in a secure area with extended walls from the real floor to the real ceiling using sheetrock or wire mesh. 2. Alarm or block any windows into the room to detect and/or prevent access. 3. Install a solid-core door or a steel door, ensuring that door hinges cannot be removed from outside the room. 4. Implement a badge control system that supports dual-access requirements for entry to the secure area and supports anti-pass-back. 5. Ensure that the badge system supports an alarm (e.g., through use of motion detection) when one person remains in the secure area alone beyond 30 seconds. 6. Install either two safes with dual control (key and combination or two combinations) or one safe with two locked non-removable steel containers where the two key custodians possess the key. 7. Utilize a CCTV system that supports remote monitoring on a 7/24 basis so that alarms can be remotely resolved by authorized personnel 8. Secure the CCTV server and digital storage in a separate secure area that is not accessible to the personnel that have access to the key injection area 9. Focus the cameras on the entrance door, inventories of devices both pre and post key injection, any safe that is present and the equipment used for key injection (without focusing on any combination locks or keyboards used to enter passwords or other authentication credentials). Cryptographic equipment must be managed in a secure manner in order to minimize the opportunity for key compromise or key substitution. Physical keys, authorization codes, passwords, or other enablers must be managed so that no one person can use both the enabler(s) and the device which can create cryptograms of known keys or key components under a key-encipherment key used in production. Unauthorized use of secure cryptographic devices (including key-loading devices) shall be prevented or detected by all of the following: Page 72 of 76

73 The device is at all times either locked or sealed in a tamper-evident cabinet or else is under the continuous supervision of at least two authorized people who ensure that any unauthorized use of the device would be detected; The device has functional or physical characteristics (e.g., passwords or physical high-security keys) that prevent use of the device except under the dual control of at least two authorized people; and when in a state in which it is useable, the device is under the continuous supervision of at least two such people who ensure that any unauthorized use of the device would be detected. Network access to the device is based on the following controls: PCI DSS: The network shall meet any PCI DSS compliance requirements. Network separation: The HSM production network shall be logically and physically separate from any other business networks. Firewalls (Hardware or Software): The HSM production network should use a nested firewall configuration with an external and inner network boundary, protected by a firewall and coupled with an IDS. Access controls: Authorized access to logical and physical components of the HSM production network shall be based on timed access and dual control. It is strongly recommended that devices and applications be set with the most stringent, logical access-control settings where applicable. Access-control settings shall be specified for production domains, servers, proxy servers, firewalls, routers, and organizational units (OUs) and other protected resources. IDS (Intrusion-detection system): The HSM network environment shall be monitored using IDS on a 24/7 basis. Monitoring, as a minimum, should include normal and exception reporting on personal access, violation of established protocols, and processes that affect the HSMs for example, unusual/out-of-pattern access events, software/firmware loads, HSM velocity checking. VPN (Virtual Private Networks): Separate internal IP addresses and/or separate VPNs should be applied to HSM production networks where direct cabling or device isolation into a single physical location is not practical. Encrypted VPN solutions should be used to separate the production network platform from any other internal network. Logging and auditing: 24/7 logging and reviews of audit trails shall be implemented for devices and any platforms that support the production network, for example ACLs (access control lists), organizational units (OUs) and other protected resources. Staff: It is strongly recommended that patch management, database administration, or system administration services be conducted for the HSM production environment under dual control and authorized/monitored by the appropriate network security management personnel. Page 73 of 76

74 Applicability Question Scope This question applies to all SCDs, including HSMs and key-injection equipment at key injection facilities and at CAs. This question includes test, production, and spare, and old and new devices. This question also includes key loading devices that can encrypt keys and produce cryptograms of those keys. Intent of Question To protect against the ability to misuse a SCD in a manner that would allow the discovery of known plaintext and the corresponding cipher text, which could allow the discovery of keys and ultimately the discovery of PINs. To protect against key compromise and key substitution. 1. Interview appropriate personnel and review documentation of procedures to ensure the adequacy of procedures over equipment that could be used to produce cryptograms of keys under valid production keys. 2. Ensure procedures/policy does not allow CA s HSMs to remain in the authorized state when connected to online production systems. 3. Ensure KLDs are not under single control, and that they do not use default passwords. 4. Examine the storage arrangements for all HSM brass keys, passwords, and any devices that are used to enter the component values into the HSM. Verify that no single person has the ability to place the device in a state that would allow key values to be entered. 5. If multiple brass keys are needed to activate the HSM, ensure that these keys are not in the locks and that they have been assigned to separate designated custodians. 6. Inspect the HSMs to ensure that they are in an armed state, that the anti-tamper sensors have been enabled and that the brass keys are not in the locks. Advise that the copies of an individual brass key be separated and stored securely in two different sites. 7. Verify that CA and RA database and application servers and cryptographic devices (SCDs) reside in a physically secure and monitored environment. Validate that all bullets above that specify the characteristics of the physically secure environment are met (e.g., physically dedicated room, CCTV monitoring, etc.). 8. If required, obtain verification that identified SCDs were included within PCI DSS scope review. Page 74 of 76

75 Key-Injection Facility Security Requirement 32. Documented procedures must exist and be demonstrably in use to ensure the security and integrity of PINprocessing equipment (e.g., PEDs and HSMs) placed into service, initialized, deployed, used, and decommissioned. International/Industry Standard Written procedures must exist, and all affected parties must be aware of those procedures. Records must be maintained of the tests and inspections performed by key-injection facilities on to PIN-processing devices before they are placed into service, as well as devices being decommissioned. Procedures that govern access to HSMs must be in place and known to data-center staff and any others involved with the physical security of such devices. HSM security policies/configurations must be validated to secure settings at least annually. Applicability Question Scope This question applies to all SCDs at key injection facilities and at CAs. This question includes test, production, and spare, and old and new devices. This question also includes key loading devices that can encrypt keys and produce cryptograms of those keys. Intent of Question To protect against the ability to misuse a SCD in a manner that would allow the discovery of known plaintext and the corresponding cipher text, which could allow the discovery of keys and ultimately the discovery of PINs. To protect against key compromise and key substitution. 1. Interview appropriate personnel and review documentation of procedures to ensure the adequacy of procedures over equipment that could be used to produce cryptograms of keys under valid production keys. 2. Ensure procedures/policy does not allow CA s HSMs to remain in the authorized state when connected to online production systems. 3. Ensure KLDs are not under single control, and that they do not use default passwords. 4. Examine the storage arrangements for all HSM brass keys, passwords, and any devices that are used to enter the component values into the HSM. Verify that no single person has the ability to place the device in a state that would allow key values to be entered. Page 75 of 76

76 5. If multiple brass keys are needed to activate the HSM, ensure that these keys are not in the locks and that they have been assigned to separate designated custodians. 6. Inspect the HSMs to ensure that they are in an armed state, that the anti-tamper sensors have been enabled and that the brass keys are not in the locks. Advise that the copies of an individual brass key be separated and stored securely in two different sites. 7. Validate that HSM settings/command sets are audited/validated annually. 8. Verify that CA and RA database and application servers and cryptographic devices (SCDs) reside in a physically secure and monitored environment. Validate that all bullets above that specify the characteristics of the physically secure environment are met (e.g., physically dedicated room, CCTV monitoring, etc.).obtain verification that identified SCDs were included within PCI DSS scope review. 9. Verify that CAs and their associated RA servers that issue certificates to Key Distribution Hosts or subordinate CAs also meet the respective bullets stated above (e.g., true floor to ceiling walls, intrusion detection, three layers of physical security, etc.). 10. Verify the existence and use of a CA room log book. 11. Verify all stated requirements for the individual physical access layers are met Page 76 of 76