Соответствие требованиям

Куда я попал?

SECURITM это SGRC система, автоматизирующая процессы в службах информационной безопасности. SECURITM помогает построить и управлять ИСПДн, КИИ, ГИС, СМИБ/СУИБ, банковскими системами защиты.
А еще SECURITM это место для обмена опытом и наработками для служб безопасности.

Подробнее

Наш канал

PCI PIN Security v3.1

Framework

Control Objective 1

Для проведения оценки соответствия по документу войдите в систему.

Список требований

Control Objective 1: PINs used in transactions governed by these requirements are processed using equipment and methodologies that ensure they are kept secure
Requirement 1: All cardholder-entered 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
A secure cryptographic device (SCD) must meet the requirements of a “Physically Secure Device” as defined in ISO 13491. This is evidenced by their being validated and approved against one of the following:
One of the versions of the PCI PTS standard, as members of Approval Classes EPP, PED, SCRP or UPT (collectively known as POI Devices) and Approval Class HSMs, or
FIPS 140-2 or FIPS 140-3 level 3 or higher
PIN Security Requirements:
1-1 The entity acquiring PIN-based transactions is responsible for maintaining information sufficient to demonstrate the use of approved devices. For each individual device, the minimal information elements are indicated below (in line with PCI PIN Requirement 30, PCI PIN Requirement 33, and PCI DSS Requirement 9.9.1):
- The company name (vendor) of the device model
- The device model name
- The PCI PTS Approval Number
The POI device information must include the following summary information
- List of models used
- Total number of devices, broken down by model.
Note: The addition of applications that replace or disable the PCI evaluated firmware functionality invalidates the device approval for each such implementation unless those applications are validated for compliance to PTS POI Security Requirements and listed as such in the approval listings.
Testing Procedures:
1-1 Testing Procedures applicable to POI devices (PCI PTS standards):
1-1.a Obtain the POI device information. Check for the completeness of the information.
1-1.b Compare the information against the list of approved PTS devices at www.pcisecuritystandards.org to determine which POI devices used are PCI approved and are listed, with a valid PCI approval number on the PCI SSC website.
1-1.c For devices identified as PCI approved, verify that all of the following POI device characteristics match the PCI PTS listing.
- Vendor name
- Model name/number
- Hardware version number
- Firmware version number
- Name and application version number of any applications resident within the device that were included in the PTS assessment
1-1.d For a sample of the PCI-approved devices, verify that the device displays the firmware version and either displays or has a label with the hardware version number.
Note: PCI-approved devices must show the same version numbers of hardware and firmware as have been approved and are shown in the list of approved devices. If it is not displayed, the hardware number must be shown on a label attached to the device. The firmware and application version numbers, and optionally the hardware version number, must be shown on the display or printed during startup or on request. This includes all modules addressed in testing, including SRED and Open Protocols. For unattended devices, the focal point is the PIN-entry vehicle.
1-1.e Using the sample above, identify all other software (applications) on the device and that software’s functionality and verify that the software does not replace or disable the PCI-evaluated firmware functionality unless that software is also validated and PCI approved as shown on the PCI website.
Note: The entity acquiring PIN-based transactions is responsible for identifying all software on the device that has been added subsequent to the device’s approval. Any such software should be developed in accordance with the device vendor’s security guidance, which stipulates what is and is not allowed⎯e.g., replacing the device’s PCI evaluated IP stack with an IP stack bundled with the add-on application would invalidate the approval. See PTS POI Technical Frequently Asked Questions, General FAQ #42, for additional information.
PIN Security Requirements:
1-2 Not used in Transaction Process Operations procedures.
PIN Security Requirements:
1-3 All hardware security modules (HSMs) shall be either:
FIPS 140-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.
Testing Procedures:
1-3.a 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.
1-3.b Examine documented procedures and interview personnel to verify that all PIN-translation operations are performed only by the FIPS-approved and/or PTS-approved HSMs identified above
PIN Security Requirements:
1-4 The approval listing must match the deployed devices in the following characteristics:
Vendor name
Model name and number
Hardware version number
Firmware version number
The PCI PTS HSM or FIPS 140 approval number
For PCI-approved HSMs, any applications resident within the device, including application version number, that were included in the PTS assessment.
Testing Procedures:
1-4.a For all PCI-approved HSMs used, examine HSM devices and examine the PCI SSC List of Approved PCI PTS Devices to verify that all of the following device characteristics match the PCI PTS listing for each HSM:
Vendor name
Model name/number
Hardware version number
Firmware version number
The PCI PTS HSM number
Any applications, including application version number, resident within the device which were included in the PTS assessment
1-4.b For all FIPS-approved HSMs used, examine HSM devices and examine the NIST Cryptographic Module Validation Program (CMVP) list to verify that all of the following device characteristics match the FIPS140-2 or FIPS 140-3 Level 3 (or higher) approval listing for each HSM:
Vendor name
Model name/number
Hardware version number
Firmware version number
The FIPS 140 approval number
Requirement 2: Cardholder PINs shall be processed in accordance with approved standards.
a) All cardholder PINs processed online must be encrypted and decrypted using an approved cryptographic technique that provides a level of security compliant with international and industry standards. Any cryptographic technique implemented meets or exceeds the cryptographic strength of TDEA using double-length keys.
b) All cardholder PINs processed offline using IC card technology must be protected in accordance with the requirements in Book 2 of the EMV IC Card Specifications for Payment Systems and ISO 9654.
PIN Security Requirements:
2-1 Documented procedures exist and are followed that ensure any employee or agent neither requests a cardholder to divulge their PIN in an oral or written manner nor enters it for the cardholder—e.g., documented procedures state that the merchant, clerk, and/or teller will not request or accept the PIN from the cardholder.
Testing Procedures:
2-1.a Through interview of responsible personnel, demonstration at sample points of entry, and examination of documented procedures, determine that:
Written procedures include language prohibiting employees from requesting, observing, or entering a cardholder's PIN.
Such procedures are followed at the point of PIN entry.
PIN Security Requirements:
2-2 Online PIN translation must only occur using one of the allowed key-management methods: DUKPT, fixed key, master key/session key.
Note: Effective 1 January 2023:
Fixed key for TDEA PIN encryption in POI devices is disallowed.
Effective 1 January 2023:
Fixed key for TDEA PIN encryption in host-to-host connections is disallowed
Testing Procedures:
2-2.a Interview responsible personnel to determine key-management methods used for online PIN acquisition.
2-2.b Examine system documentation, the summary of cryptographic keys, and the network schematic (see “Overview” section) to determine keymanagement methods used within each zone—e.g., terminal to host, host to next node, etc. Confirm only approved methods are in use
PIN Security Requirements:
2-3 Online PINs must be encrypted using an algorithm and key size that is specified in ISO 9564. Currently, the only approved algorithms for online PIN are:
The TDEA using the electronic code book (TECB) mode of operation, and
AES as described in ISO 18033-3 For purposes of these requirements, all references to TECB are using key options 1 or 2, as defined in ISO 18033-3.
Note: The effective dates for supporting ISO Format 4 PIN Blocks that were previously communicated in v3.0 of the PCI PIN Security Requirements and Testing Procedures have been suspended at this time.
Due to the nature of TDEA-to-AES migration and its effect across the payment ecosystem, PCI SSC is reevaluating these dates. Revised effective dates will be communicated at a later time.
PCI SSC encourages all parties to continue their migration efforts to support ISO Format 4 PIN Blocks.
Testing Procedures:
2-3.a Interview responsible personnel to determine encryption algorithms utilized in connection with “not-on-us” acquisitions of PIN blocks.
2-3.b Examine system documentation, the list of cryptographic keys, and the network schematic to verify information provided during the aforementioned interviews:
For internally developed systems, examine system design documentation or source code for type of key (algorithm) and key sizes used to encrypt the PIN blocks. Examine the point in the code where the calls are made to the hardware security module.
For application packages, examine parameter files (e.g., the Base24 KEYF file) to determine type of key (algorithm) and key sizes used to encrypt PIN blocks.
2-3.c Examine the HSM configuration to ensure that the PIN translation encryption algorithms are only TDEA and/or AES.
2-3.d Examine the algorithm type parameter (to ensure it denotes TDEA and/or AES) and hardware-encryption-required parameter (if applicable, to ensure it indicates hardware encryption—not software encryption) on every terminal link, network link, and if applicable, internal path (i.e., if using an intermediate key) for the host application.
PIN Security Requirements:
2-4 All cardholder PINs processed offline using IC card technology must be protected in accordance with the requirements in Book 2 of the EMV IC Card Specifications for Payment Systems and ISO 9564.
See Book 2, Section 7, of the EMV IC Card Specifications for Payment Systems, and ISO 9564
PIN submission method
Enciphered PIN block submitted to the IC card.
Plaintext PIN block submitted to the IC card.
PIN entry device and IC reader integrated as a device meeting the requirements of ISO 9564
The PIN block shall be submitted to the IC card enciphered using an authenticated encipherment key of the IC card.
No encipherment of the PIN block is required.
PIN entry device and IC reader not integrated as a device meeting the requirements of ISO 9564
The PIN block shall be enciphered between the PIN entry device and the IC reader in accordance with ISO 9564 or enciphered using an authenticated encipherment key of the IC card. The PIN block shall be submitted to the IC card enciphered using an authenticated encipherment key of the IC card.
The PIN block shall be enciphered from the PIN entry device to the IC reader in accordance with ISO 9564.
Testing Procedures:
2-4.a Interview the responsible personnel to determine which POI device models identified in Requirement 1 summary are used for offline PIN acquiring.
2-4.b Validate that the POI device models used for offline PIN—including both the ICCR and the PIN entry device where non-integrated—are approved for “Offline PIN” on the PTS Approved Devices Listing at www.pcisecuritystandards.org
Requirement 3: For online interchange transactions, PINs must be only encrypted using ISO 9564–1 PIN-block formats 0, 1, 3 or 4. Format 2 must be used for PINs that are submitted from the IC card reader to the IC card
PIN Security Requirements:
3-1 For secure transmission of the PIN from the point of PIN entry to the card issuer, the encrypted PIN-block format must comply with ISO 9564 format 0, ISO 9564 format 1, ISO 9564 format 3, or ISO 9564 format 4.
Testing Procedures:
3-1.a Interview responsible personnel to determine the PIN-block format(s) utilized for “not-on-us” traffic from point of acquisition through routing of the transaction to another entity. Examine and verify the accuracy of the network schematic.
3-1.b Examine system documentation to verify information provided during interviews. This is mandatory, especially if personnel have indicated the use of a compliant PIN-block format:
For internally developed systems, examine system design documentation, transaction logs, or source code for type of PIN-block format(s) used.
For application packages, examine parameter files where the PIN-block format is specified (e.g., the KEYF file for Base 24). Verify the format is ISO Formats 0, 1, 3, or 4 as the online PIN-block type for compliance.
PIN Security Requirements:
3-2 PINs enciphered only for transmission between the PIN entry device and the IC reader must use one of the PIN-block formats specified in ISO 9564. Where ISO format 2 is used, a unique-key-per-transaction method in accordance with ISO 11568 shall be used. Format 2 shall only be used in connection with either offline PIN verification or PIN change operations in connection with ICC environments.
Testing Procedures:
3-2.a Using the summary from Requirement 1, identify any non-PCI-approved devices and device types for which the ICC card reader is not integrated in the PIN entry device. For each of these device types, Interview applicable personnel to determine that PINs enciphered only for transmission between the PIN entry device and the ICCR use one of the PIN-block formats specified in ISO 9564. If format 2 is used, verify that a unique-key-pertransaction method in accordance with ISO 11568 is used.
Note: PCI-approved devices are validated to this; nevertheless, personnel must still be interviewed to validate the implementation.
3-2.b Examine device documentation to validate that the device functions as described above.
PIN Security Requirements:
3-3 Standard PIN-block formats (i.e., ISO formats 0, 1, 2, 3, and 4) shall not be translated into non-standard PIN-block formats.
PINs enciphered using ISO format 0, ISO format 3, or ISO format 4 must not be translated into any other PIN-block format other than ISO format 0, 3, or 4 except when translated to ISO format 2 as specified in the table below. PINs enciphered using ISO format 1 may be translated into ISO format 0, 3, or 4, but must not be translated back into ISO format 1. ISO format 1 may be translated into ISO format 2 as specified in the table below.
Translations between PIN-block formats that both include the PAN shall not support a change in the PAN. The PIN-translation capability between ISO formats 0, 3, or 4 (including translations from ISO format 0 to ISO format 0, from ISO format 3 to ISO format 3, or from ISO format 4 to ISO format 4) must not allow a change of PAN. The following illustrates translations from formats 0, 1, 3 and 4:
Note: This translation restriction is not applicable to surrogate PANs used in tokenization implementations.
Translation
from: ISO Format 0, 3, 4
to: ISO Format 0, 3, 4
Permitted anywhere without change of PAN
Change of PAN only permitted in sensitive state for card issuance
Change of PAN token to real PAN only permitted with cryptographic binding of PAN token to real PAN
from: ISO Format 1
to: ISO Format 0, 3, 4
Permitted
from: ISO Format 2
to: ISO Format 0, 3, 4
Not permitted
from: ISO Format 0, 3, 4
to: ISO Format 1
Not permitted
from: ISO Format 1
to: ISO Format 1
Permitted
from: ISO Format 2
to: ISO Format 1
Not permitted
from: ISO Format 0, 3, 4
to: ISO Format 2
Permitted for submission to an IC card
from: ISO Format 1
to: ISO Format 2
Permitted for submission to an IC card
from: ISO Format 2
to: ISO Format 2
Permitted for submission to an IC card
Testing Procedures:
3-3.a Verify the following, using information obtained in the prior steps of Requirement 3:
- ISO PIN-block formats are not translated into non-ISO formats.
- ISO PIN-block formats 0, 3, and 4 are not translated into any PIN-block formats other than 0, 3, or 4 except for submission to an IC payment card.
- If ISO format 1 is translated to ISO format 0, 3, or 4, it is not translated back to ISO format 1.
- If ISO format 1 is translated to ISO format 2, it is only for submission to an IC payment card.
- PIN-block translations from ISO format 0, 3, or 4 to any of ISO format 0, 3, or 4 do not support a change in PAN.
3-3.b Where translated to format 2, verify that the PIN block is only submitted to the IC card.
Note: For offline PIN this is verified for PCI-approved POI devices:
a) The PIN that is submitted by the ICC reader to the IC shall be contained in a PIN block conforming to ISO format 2 PIN block. This applies whether the PIN is submitted in plaintext or enciphered using an encipherment key of the IC.
b) Where the ICC reader is not integrated into the PIN entry device and PINs are enciphered only for transmission between the PIN entry device and the ICC reader, the device shall use one of the PIN-block formats specified in ISO 9564-1. Where ISO format 2 PIN blocks are used, a unique-key-per-transaction method in accordance with ISO 11568 shall be used.
Requirement 4: PINs must not be stored except as part of a store-and-forward transaction, and only for the minimum time necessary. If a transaction is logged, the encrypted PIN block must be masked or deleted from the record before it is logged
PIN Security Requirements:
4-1 Transactions may be stored and forwarded under certain conditions as noted in ISO 9564. PIN blocks, even encrypted, must not be retained in transaction journals or logs. PIN blocks are required in messages sent for authorization but must not be retained for any subsequent verification of the transaction. Transaction PINs shall only exist for the duration of a single transaction (the time between PIN entry and verification, i.e. store and forward). For the storage of other data elements, see the PCI Data Security Standards.
Testing Procedures:
4-1 Interview appropriate personnel to determine whether PINs are stored or retained for some period of time as part of a store-and-forward environment:
- Examine transaction journals/logs to determine the presence of PIN blocks. If present, PIN blocks—whether enciphered or not—must be masked before the record is logged. For environments using online transaction monitors (e.g., CICS), specifically note how management is ensuring that PINs are not stored in online transaction journals.
- For entities that drive POS devices, examine documentation (operating procedures) to verify the disposition of PIN blocks when communication links are down.

Мы используем cookie-файлы, чтобы получить статистику, которая помогает нам улучшить сервис для вас с целью персонализации сервисов и предложений. Вы может прочитать подробнее о cookie-файлах или изменить настройки браузера. Продолжая пользоваться сайтом, вы даёте согласие на использование ваших cookie-файлов и соглашаетесь с Политикой обработки персональных данных.