PCI PIN Security v3.1

PIN Security Requirements:
18-2 To prevent or detect usage of a compromised key, key-component packaging, or containers that show signs of tampering indicating a component was potentially compromised must be assessed and the analysis formally documented. If compromise is confirmed, it must result in the discarding and invalidation of the component and the associated key at all locations where they exist.
Testing Procedures:
18-2.a Verify that documented procedures require that key-component packaging/containers showing signs of tampering indicating a component was potentially compromised are assessed and the analysis is formally documented. If compromise is confirmed, it must result in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist.
18-2.b Interview personnel and observe processes to verify procedures are implemented to require that key-component packaging/containers showing signs of tampering indicating a component was potentially compromised are assessed and the analysis is formally documented. If compromise is confirmed, it results in the destruction and invalidation of all associated key components and the resultant cryptographic key(s) at all locations where they exist. 

PIN Security Requirements:
18-3 Encrypted symmetric keys must be managed in structures called key blocks. The key usage must be cryptographically bound to the key using accepted methods
The phased implementation dates are as follows: 
Phase 1 – Implement Key Blocks for internal connections and key storage within Service Provider Environments – this would include all applications and databases connected to hardware security modules (HSM). Effective date: 1 June 2019. 
Phase 2 – Implement Key Blocks for external connections to Associations and Networks. Effective date: 1 January 2023. 
Phase 3 – Implement Key Block to extend to all merchant hosts, point-of-sale (POS) devices, and ATMs. Effective date: 1 January 2025. 
Acceptable methods of implementing the integrity requirements include, but are not limited to: 

18-3 Using the cryptographic-key summary to identify secret keys conveyed or stored, examine documented procedures and observe key operations to verify that secret cryptographic keys are managed as key blocks using mechanisms that cryptographically bind the key usage to the key at all times via one of the acceptable methods or an equivalent. 
Where key blocks are not implemented, identify and examine project plans to implement in accordance with the prescribed timeline. 

PIN Security Requirements:
18-6 Controls must be in place to prevent and detect the loading of unencrypted private and secret keys or their components by any one single person. Note: 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.
Testing Procedures:
18-6.a Examine documented key-injection procedures to verify that controls are defined to prevent and detect the loading of keys by any one single person.
18-6.b Interview responsible personnel and observe key-loading processes and controls to verify that controls—for example, viewing CCTV images—are implemented to prevent and detect the loading of keys by any one single person. 

PIN Security Requirements:
18-7 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: 

18-7.a Examine documented procedures to verify they include: 

18-7.b Interview responsible personnel and observe key-loading processes and controls to verify that: 

PIN Security Requirements:
19-1 Encryption keys must be used only for the purpose they were intended⎯i.e., key-encryption keys must not to be used as PIN-encryption keys, PIN-encryption keys must not be used for account data, etc. Derivation Keys may be derived into multiple keys, each with its own purpose. For example, a DUKPT Initial Key may be used to derive both a PIN encryption key and a data encryption key. The derivation key would only be used for its own purpose, key derivation. 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.
Testing Procedures:
19-1.a Examine key-management documentation (e.g., the cryptographic key inventory) and interview key custodians and key-management supervisory personnel to verify that cryptographic keys are defined for a specific purpose.
19-1.b Using a sample of device types, validate via examination of check values, terminal definition files, etc. that keys used for key encipherment or PIN encipherment are not used for any other purpose. 

PIN Security Requirements:
19-2 Private keys: 

Note: The restriction does not apply to certificate signing requests e.g., PKCS #10.
 Testing Procedures:
19-2 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that private keys are: • Used only to create digital signatures or to perform decryption operations. 

PIN Security Requirements:
19-3 Public keys must only be used for a single purpose—a public key must only be used for either encryption or for verifying digital signatures, but not both (except for transaction-originating POI devices).
Testing Procedures:
19-3 Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that public keys are only used: 

PIN Security Requirements:
19-4 Keys must never be shared or substituted between production and test/development systems:
Key used for production keys must never be present or used in a test system, and
Keys used for testing keys must never be present or used in a production system.
Note: For logically partitioned HSMs and computing platforms, if one or more logical partitions of a physical device are used for production and one or more other logical partitions are used for testing, including QA or similar, the entire configuration that is impacted⎯computing platform(s) and networking equipment⎯must be managed and controlled as production.
Testing Procedures:
19-4.a Examine key-management documentation and interview key custodians and key-management supervisory personnel to verify that cryptographic keys are never shared or substituted between production and development systems.
19-4.b Observe processes for generating and loading keys into in production systems to ensure that they are in no way associated with test or development keys.
19-4.c Observe processes for generating and loading keys into test systems to ensure that they are in no way associated with production keys.
19-4.d Compare check, hash, cryptogram, or fingerprint values for production and test/development keys for higher-level keys (e.g., MFKs, KEKs shared with other network nodes, and BDKs) to verify that development and test keys have different key values. 

PIN Security Requirements:
19-5 If a business rationale exists, a production platform (HSM and server/standalone computer) 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.
Note: This does not apply to HSMs that are never intended to be used for production.
Testing Procedures:
19-5 Interview personnel to determine whether production platforms are ever temporarily used for test purposes. If they are, verify that documented procedures require that: 

PIN Security Requirements:
20-1 POI devices must implement unique secret and private keys for any function directly or indirectly related to PIN protection. These keys must be known only in that device and in hardware security modules (HSMs) 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.
This means that not only the PIN-encryption key(s), but also keys that are used to protect other keys, firmware-authentication keys, payment application authentication, and display-prompt control keys. As stated in the requirement, this does not apply to public keys resident in the device.
POI private keys must not exist anywhere but the specific POI they belong to, except where generated external to the POI and prior to the injection into the POI.
Testing Procedures:
20-1.a Examine documented procedures for the generation, loading, and usage of all keys used in transaction-originating POI devices. Verify the procedures ensure that all private and secret keys used in transaction-originating POI devices are: 

20-1.b Observe HSM functions and procedures for generating and loading secret and private keys for use in transaction-originating POIs to verify that unique keys are generated and used for each POI device.
20-1.c Examine check values, hashes, or fingerprint values for a sample of cryptographic keys from different POI devices to verify private and secret keys are unique for each POI device. This can include comparing a sample of POI public keys (multiple devices for each POI vendor used) to determine that the associated private keys stored in the POI devices are unique per device—i.e., the public keys are unique. 

PIN Security Requirements:
20-2 If a transaction-originating terminal (for example POI device) interfaces with more than one acquiring organization, the transaction-originating terminal SCD must have a completely different and unique key or set of keys for each acquiring organization. These different keys, or sets of keys, must be totally independent and not variants of one another.
Testing Procedures:
20-2a Determine whether any transaction-originating terminals interface with multiple acquiring organizations. If so: 

20-2b Observe processes for generation and injection of keys into a single POI for more than one acquiring organization, to verify: 

PIN Security Requirements:
20-3 Keys that are generated by a derivation process and derived from the same Base (master) Derivation Key must use unique data for the derivation process as defined in ISO 11568 so that all such cryptographic devices receive unique initial secret keys. Base derivation keys must not ever be loaded onto POI devices—i.e., only the derived key is loaded to the POI device.
This requirement refers to the use of a single “base” key to derive initial keys for many different POIs, using a key-derivation process as described above. This requirement does not preclude multiple unique keys being loaded on a single device, or for the device to use a unique key for derivation of other keys once loaded, for example, as done with DUKPT.
Note: The same BDK with the same KSN installed in multiple injection systems or installed multiple times within the same injection system will not meet uniqueness requirements.
Testing Procedures:
20-3.a Examine documented procedures and observe processes for generating initial keys. Verify the following is implemented where initial keys are generated by a derivation process and derived from the same Base Derivation Key: 

20-3.b Verify that derivation keys used to generate keys for multiple devices are never loaded into a POI device. 

PIN Security Requirements:
20-4 Entities processing or injecting DUKPT or other key-derivation methodologies must incorporate a segmentation strategy in their environments. Segmentation must use one or more of the following techniques: 

20-4.a Examine documented key-generation and injection procedures to verify that entities processing or injecting DUKPT or other key-derivation methodologies incorporate a segmentation strategy in their environments using one or more of the following techniques: 

20-4.b Examine documented key-generation and injection procedures to verify that key-injection vendors use at least one unique Base Derivation Key (BDK) per acquiring organization and are able to support segmentation of multiple BDKs of acquiring organizations. 

PIN Security Requirements:
20-5 Key-injection facilities that load DUKPT keys for various POI 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 facility must ensure that any one given key cannot be derived for multiple devices except by chance.
Testing Procedures:
20-5.a If the key-injection facility loads DUKPT keys, examine documented procedures for generation and use of BDKs to verify they require use of separate BDKs per terminal type.
20-5.b Observe key-loading processes for a sample of terminal types used by a single entity, to verify that separate BDKs are used for each terminal type. 

PIN Security Requirements:
20-6 Remote Key-Establishment and Distribution Applications The following requirements apply to key-injection facilities participating in remote key-establishment and distribution applications: 

20-6.a For techniques involving public key cryptography, examine documentation and develop a schematic to illustrate the process, including: 

20-6.b If key-establishment protocols using public-key cryptography are used to distribute secret keys, verify that: