Куда я попал?
PCI PIN Security v3.1
Framework
Normative Annex B
Для проведения оценки соответствия по документу войдите в систему.
Список требований
-
PIN Security Requirements:
1-3 Ensure that all hardware security modules (HSMs) are either:- FIPS140-2 or FIPS 140-3 Level 3 or higher certified, or
- PCI approved. Note: PCI approved HSMs may have their approvals restricted whereby the approval is valid only when the HSM is deployed in controlled environments or more robust (e.g., secure) environments as defined in ISO 13491-2 and in the device’s PCI HSM Security Policy. This information is noted in the Additional Information column of approved PTS devices.
Note: Key-injection platforms and systems shall include hardware devices for managing (e.g., generating and storing) the keys that conform to the requirements for SCDs. This includes SCDs used in key-injection facilities (e.g., modified PEDs). If modified PEDs are not validated and approved to the KLD approval class, they must be managed in accordance with Requirement 13-9.
Testing Procedures:
1-3 For all HSM brands/models used, examine approval documentation (e.g., FIPS certification or PTS approval) and examine the list of approved devices to verify that all HSMs are either:- Listed on the NIST Cryptographic Module Validation Program (CMVP) list, with a valid listing number, and approved to FIPS 140-2 or FIPS 140-3 Level 3, or higher. Refer http://csrc.nist.gov.
- Listed on the PCI SSC website, with a valid SSC listing number, as Approved PCI PTS Devices under the approval class “HSM.” Refer to https://www.pcisecuritystandards.org.
-
PIN Security Requirements:
6-1.5 Physical security controls must be used to prevent unauthorized personnel from accessing the area during key-generation processes where clear-text keying material is in use. It must not be feasible to observe clear-text keying material either directly or via camera monitoring.
Testing Procedures:
6-1.5.a Examine documentation to verify that physical security controls (e.g., partitions or barriers) are defined to ensure the key component cannot be observed or accessed by unauthorized personnel.
6-1.5.b During the demonstration for 6-1.1.b, observe the physical security controls (e.g., partitions or barriers) used, and validate that they ensure the key-component/key-generation process cannot be observed or accessed by unauthorized personnel directly or via camera monitoring (including those on cellular phones). -
PIN Security Requirements:
6-2 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 memory outside the tamper-protected boundary of an SCD.
For example, it is not permitted for the cryptographic key to be passed through the memory of a computer unless it has been specifically tasked for the sole purpose of key loading. Computers that have been specifically purposed and used solely for key loading are permitted for use if all other requirements can be met, including those of Requirement 5 and the controls defined in Requirement 13 of Annex B.
Additionally, this requirement excludes from its scope computers used only for administration of SCDs, or key-generation devices that do not have the ability to access clear-text cryptographic keys or components.
Single-purpose computers with an installed SCD or a modified PED where clear keying material is injected directly from a secure port on the key-generating SCD to the target SCD (e.g., a POI device) meet this requirement. Where the components or key pass through memory of the PC, Requirement 13 of Annex B must be met.
SCDs used for key generation must meet Requirement 5.1
Note: See Requirements 5 and 13.
Testing Procedures:
6-2.a Examine documented procedures to verify that multi-purpose computing systems are not permitted for key generation where any clear-text secret or private key or component thereof appears in memory outside the tamper-protected boundary of an SCD.
6-2.b Observe generation process and examine vendor documentation for each type of key to verify that multi-purpose computing systems are not used for key generation where any clear-text secret or private key or component thereof appears in memory.
6-2.c Where single-purpose computers with an installed SCD or a modified PED are used, verify that either:- Clear keying material is injected directly from a secure port on the SCD to the target (e.g., a POI device), or
- Where clear keying material passes through memory of the PC, the PC requirements of Requirement 13 of Annex B are met.
-
PIN Security Requirements:
6-4 Any residue that may contain clear-text keys or components must be destroyed or securely deleted—depending on media—immediately after generation of that key, to prevent disclosure of a key or the disclosure of a key component to an unauthorized individual.
Examples of where such key residue may exist include (but are not limited to):- Printing material, including ribbons and paper waste
- Memory storage of a key-loading device, after loading the key to a different device or system
- Other types of displaying or recording
Testing Procedures:6-4.a Examine documented procedures to identify all locations where key residue may exist. Verify procedures ensure the following:- Any residue that may contain clear-text keys or components is destroyed or securely deleted immediately after generation.
- Specific direction as to the method of destruction is included in the procedure.
- If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device(s) immediately after the transfer to the device that will use the key.
Examine logs of past destructions and deletions to verify that procedures are followed.6-4.b Observe the destruction process of each identified type of key residue and verify the following:- Any residue that may contain clear-text keys or components is destroyed immediately after generation.
- The method of destruction is consistent with Requirement 24.
- If a key is generated in a separate device before being exported into the end-use device, confirm that the key and all related critical security parameters (e.g., secret seeds) are deleted (zeroized) from the generation and/or injection device(s) immediately after the transfer to the device that will use the key.
-
PIN Security Requirements:
8-4 Public keys must be conveyed in a manner that protects their integrity and authenticity. Examples of acceptable methods include:- Use of public-key certificates as defined in Annex A that are created by a trusted CA that meets the requirements of Annex A.
- Validating a hash of the public key sent by a separate channel (for example, mail)
- Using a MAC (message authentication code) created using the algorithm defined in ISO 16609
- Conveyance within an SCD
- Encrypted
Note: Self-signed certificates must not be used as the sole method of authentication.
Self-signed root certificates protect the integrity of the data within the certificate but do not guarantee the authenticity of the data. The authenticity of the root certificate is based on the use of secure procedures to distribute them. Specifically, they must be directly installed into the PIN pad of the ATM or POS device and not remotely loaded to the device subsequent to manufacture.
Testing Procedures:
8-4 For all methods used to convey public keys, perform the following:
8-4.a Examine documented procedures for conveying public keys to verify that methods are defined to convey public keys in a manner that protects their integrity and authenticity such as:- Use of public-key certificates created by a trusted CA that meets the requirements of Annex A
- Validation of a hash of the public key sent by a separate channel (for example, mail)
- Using a MAC (message authentication code) created using the algorithm defined in ISO 16609
- Conveyance within an SCD
- Encrypted
8-4.b Validate that procedures dictate that self-signed certificates must not be used as the sole method of authentication.
8-4.c Observe the process for conveying public keys, associated logs, and interview responsible personnel to verify that the implemented method ensures public keys are conveyed in a manner that protects their integrity and authenticity. -
PIN Security Requirements:
10-1 All key-encryption keys used to encrypt for transmittal or conveyance of other cryptographic keys must be at least as strong as the key being sent, as delineated in Annex C except as noted below for RSA keys used for key transport.- TDEA keys used for encrypting keys must be at least double-length keys (have bit strength of 80 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment.
- A double- or triple-length TDEA key must not be encrypted with a TDEA key of a lesser strength.
- TDEA keys shall not be used to protect AES keys.
- TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
- RSA keys used to transmit or convey other keys must have bit strength of at least 80 bits.
- RSA keys encrypting keys greater in strength than 80 bits shall have bit strength at least 112 bits.
Note: Entities using POI version1 and/or version 2 devices may use RSA key sizes of 1024 and/or SHA-1 if the devices do not support RSA key sizes of 2048 or SHA-2. However, in all cases, version 3 or higher devices must implement RSA using key sizes of 2048 or higher and SHA-2 when used for key distribution using asymmetric techniques in accordance with Annex A.
Testing Procedures:
10-1.a Examine documented procedures to verify there is a requirement that all keys used to transmit or convey other cryptographic keys must be at least as strong as any key transmitted or conveyed, except as noted for RSA keys.
10-1.b Using the network schematic and the summary listing of cryptographic keys and through interview of personnel, identify keys that protect other keys for transmission. Consider keys manually transferred (e.g., cryptograms sent to an ESO) as well as those that are system generated and transferred (e.g., KEK or TMK encrypting working keys)
10-1.c Observe key-generation processes for the key types identified above. Verify that all keys used to transmit or convey other cryptographic keys are at least as strong as any key transmitted or conveyed except as noted for RSA keys.- Interview appropriate personnel and examine documented procedures for the creation of these keys.
- Using the table in Annex C, validate the respective key sizes for TDEA, RSA, Elliptic Curve, DSA, and Diffie Hellman algorithms where used for key encryption.
- Verify that:
- TDEA keys used for encrypting keys must be at least double-length keys (have bit strength of 80 bits) and use the TDEA in an encrypt, decrypt, encrypt mode of operation for key-encipherment.
- A double- or triple-length TDEA key must not be encrypted with a TDEA key of lesser strength.
- TDEA keys are not used to protect AES keys.
- TDEA keys shall not be used to encrypt keys greater in strength than 112 bits.
- RSA keys used to transmit or convey other keys have bit strength of at least 80 bits.
- RSA keys encrypting keys greater in strength than 80 bits have bit strength at least 112 bits.
- Any POI device that is version 3 or higher is using RSA with a key size of at least 2048 and SHA-2, where applicable. Use as necessary the device information used in Requirement 1.
10-1.d Examine system documentation and configuration files to validate the above, including HSM settings. -
PIN Security Requirements:
12-8 If key-establishment protocols using public-key cryptography are used to distribute secret keys, these must meet the requirements detailed in Annex A of this document. For example:- A public-key technique for the distribution of symmetric secret keys must:
- Use public and private key lengths that are in accordance with Annex C 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 POI device or host-to-host if applicable, including assurance to the host that the POI device has (or can compute) the session key and that no entity other than the POI device specifically identified can possibly compute the session key.
Testing Procedures:12-8.a For techniques involving public key cryptography, examine documentation 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 POI.
12-8.b If key-establishment protocols using public-key cryptography are used to distribute secret keys, verify that the remote key-distribution requirements detailed in Annex A of this document are met, including:- Use of public and private key lengths that are in accordance with Annex C for the algorithm in question (e.g., 1024-bits minimum for RSA).
- Use of key-generation techniques that meet the current ANSI and ISO standards for the algorithm in question.
- Providing for mutual device authentication for both the host and the POI device or host-to-host if applicable.
-
PIN Security Requirements:
13-3 The loading of plaintext secret or private key components or shares from an electronic medium—e.g., smart card, thumb drive, fob or other devices used for data transport—directly into a cryptographic device (and verification of the correct receipt of the component, if applicable) results in either of the following:- The medium is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future reloading of the component into the cryptographic device); or
- All traces of the component are erased or otherwise destroyed from the electronic medium in accordance with Requirement 24.
Testing Procedures:13-3.a Examine documented procedures for the loading of secret or private key components from an electronic medium to a cryptographic device. Verify that procedures define specific instructions to be followed as a result of key loading, including:- Instructions for the medium to be placed into secure storage and managed under dual control (only if there is a possibility it will be required for future reloading of the component into the cryptographic device); or
- Instructions to erase or otherwise destroy all traces of the component from the electronic medium, including the method to use.
13-3.b Observe key-loading processes to verify that the loading process results in one of the following:- The medium used for key loading is placed into secure storage and managed under dual control (only if there is a possibility it will be required for future reloading of the component into the cryptographic device); or
- All traces of the component are erased or otherwise destroyed from the electronic medium.
13-3.c Examine records/logs of erasures to confirm that:- The documented procedure was followed.
- The method used was in accordance with Requirement 24
-
PIN Security Requirements:
13-9.1 PCs and similar devices must be:- Standalone (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 meeting the criteria of Requirement 32-9 that is dedicated to key-loading activities.
Testing Procedures:
13-9.1 For facilities using PC-based key-loading software platforms or similar devices, verify through interviews and observation that the platform is:- Standalone
- Dedicated to only key loading
- Located in a physically secure room meeting the criteria of Requirement 32-9 that is dedicated to key loading activities
-
PIN Security Requirements:
13-9.2 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.
Testing Procedures:
13-9.2 Verify through interviews and observation that:- All hardware used in key loading (including the PC) is managed under dual control.
- Key-injection cannot occur unless there are minimally two individuals in the key-injection room at all times during the process.
- Mechanisms exist (See Requirement 32) that do not permit the room to be occupied by fewer than two authorized individuals.
-
PIN Security Requirements:
15-2 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 plaintext form, must:- Be within a certificate as defined in Annex A; or
- Be within a PKCS#10 (authentication and integrity occurs via other mechanisms); or
- Be within an SCD; or
- Have a MAC (message authentication code) created using the algorithm defined in ISO 16609.
Testing Procedures:
15-2.a Interview personnel and examine documented procedures to verify that all public keys exist only in an approved form.
15-2.b Observe public-key stores and mechanisms to verify that public keys exist only in an approved form. -
Requirement 21: Secret keys used for enciphering PIN-encryption keys or for PIN encryption, or private keys used in connection with remote key-distribution implementations, must never exist outside of SCDs, except when encrypted or securely stored and managed using the principles of dual control and split knowledge.
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 or similar devices whereby clear-text secret and/or private keys and/or their components exist in 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 memory outside the secure boundary of an SCD must minimally implement the compensating controls outlined in Requirement 13. -
PIN Security Requirements:
21-1 Secret or private keys must only exist in one or more of the following forms:- At least two separate key shares (secret or private) or full-length components (secret)
- Encrypted with a key of equal or greater strength as delineated in Annex C
- Contained within a secure cryptographic device
Note: Key-injection facilities may have clear-text keying material outside of a SCD when used within a secure room in accordance with Requirement 32 in Annex B.
Testing Procedures:
21-1.a Examine documented procedures for key storage and usage to verify that secret or private keys only exist in one or more approved forms at all times when stored.
21-1.b Observe key stores to verify that secret or private keys only exist in one or more approved forms at all times when stored. -
PIN Security Requirements:
21-3 Key components/shares must be stored as follows:
Testing Procedures:
21-3 Examine documented procedures, interview responsible personnel, and inspect key-component/share storage locations to verify that key components/shares are stored as outlined in Requirements 21-3.1 through 21- 3.3 below: -
PIN Security Requirements:
29-2 Implement a documented “chain of custody” to ensure that all devices are controlled from receipt to placement into service. The chain of custody must include records to identify responsible personnel for each interaction with the devices.
Note: Chain of custody includes procedures, as stated in Requirement 29-1, that ensure that access to all POI devices and other SCDs is documented, defined, logged, and controlled such that unauthorized individuals cannot access, modify, or substitute any device without detection.
Testing Procedures:
29-2.a Examine documented processes to verify that the chain of custody is required for devices from receipt to placement into service.
29-2.b For a sample of devices, examine documented records and interview responsible personnel to verify the chain of custody is maintained from receipt to placement into service.
29-2.c Verify that the chain-of-custody records identify responsible personnel for each interaction with the device. -
PIN Security Requirements:
29-4.2 The security policy enforced by the HSM must not allow unauthorized or unnecessary functions. HSM API functionality and commands that are not required to support specified functionality must be disabled before the equipment is commissioned.For example, for HSMs used in transaction processing operations:- PIN-block format translation functionality is in accordance with Requirement 3, or non-ISO PIN-block formats must not be supported without a defined documented and approved business need.
- HSMs used for acquiring functions shall not be configured to output clear-text PINs or support PIN-change functionality. Documentation (e.g., a checklist or similar suitable to use as a log) of configuration settings must exist and be signed and dated by personnel responsible for the implementation. This documentation must include identifying information for the HSM, such as serial number and/or asset identifiers. This documentation must be retained and updated for each affected HSM any time changes to configuration settings would impact security.
Testing Procedures:29-4.2.a Obtain and examine the defined security policy to be enforced by the HSM.
29-4.2.b Examine documentation of the HSM configuration settings from past commissioning events to determine that the functions and commands enabled are in accordance with the security policy.
29-4.2.c For a sample of HSMs, examine the configuration settings to determine that only authorized functions are enabled.
29-4.2.d Verify that PIN-change functionality, PIN-block format translation functionality, or non-ISO PIN-block formats are not supported without a defined documented and approved business need.
29-4.2.e Verify that functionality is not enabled to allow the outputting of clear-text PINs.
29-4.2.f Examine documentation to verify:- Configuration settings are defined, signed and dated by personnel responsible for implementation.
- It includes identifying information for the HSM, such as serial number and/or asset identifiers.
- The documentation is retained and updated anytime configuration setting impacting security occur for each affected HSM.
-
Functionality of a key-injection facility may be located at a single physical location or distributed over a number of physical locations. Distributed KIF functionality may include key generation, CA functionality, key distribution, and key injection. In order to mitigate the expanded attack surface of a distributed KIF, specific controls apply to a distributed architecture. This may occur within a single organization or across organizations. If any secret or private keys or their components/shares appear in the clear outside of a SCD, Requirement 32-9 for a secure room must be met.
-
PIN Security Requirements:
32-8.1 The KIF must ensure that keys are transmitted between KIF components in accordance with Control Objective 3.
Testing Procedures:
32-8.1.a Examine documented procedures for key conveyance or transmittal to verify that keys used between KIF components are addressed in accordance with applicable criteria in Control Objective 3.
32-8.1.b Interview responsible personnel and observe conveyance processes to verify that the documented procedures are followed for key conveyance or transmittal for keys used between KIF components. -
PIN Security Requirements:
32-8.4 The channel for mutual authentication is established using the requirements of Control Objective 4.
Testing Procedures:
32-8.4.a Examine documented procedures for key loading to hosts and POI devices to verify that they are in accordance with applicable criteria in Control Objective 4.
32-8.4.b Interview responsible personnel and observe key-loading processes to verify that the documented procedures are followed for key conveyance or transmittal for keys used between KIF components. -
PIN Security Requirements:
32-9.1 The secure room must have walls made of solid materials. In addition, if the solid walls do not extend from the real floor to the real ceiling, the secure room must also have extended walls from the real floor to the real ceiling using sheetrock or wire mesh.
Note: In KIF environments where Level 1 and Level 2 physical barrier controls are in place and confirmed, the secure room may be implemented within a “caged” environment. A caged environment is an enclosed secure room that meets the criteria of Requirement 32 but is not made of solid walls. Refer to Normative Annex A: A2 for additional information on Level 1 and Level 2 physical barrier controls. All other criteria stated in Requirements 13-9 and 32-9 relating to clear-text secret and/or private keys and/or their components existing in unprotected memory outside the secure boundary of an SCD for loading keys apply.
Testing Procedures:
32-9.1 Inspect the secure room designated for key injection to verify that it is constructed with extended walls from the real floor to the real ceiling using sheetrock or wire mesh.
Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.