PCI Watch

Tracking changes across the Payment Card Industry

Document Comparison

PCI_PTS_POI_SRs_v4-1c-November.pdf → PCI_PTS_POI_SRs_v5.pdf
80% similar
60 → 61 Pages
16026 → 16329 Words
58 Content Changes

Content Changes

58 content changes. 73 administrative changes (dates, page numbers) hidden.

Added p. 2
June 2016 5.x RFC Version

September 2016 5.0 Public release Note to Assessors When protecting this document for use as a form, leave Section 5 (Device Photos) unprotected to allow for insertion of a device-or component photos. Under “Tools / Protect Document,” select “Forms” then “Sections,” and un-check Section 5 as illustrated below.
Added p. 5
 The addition of new appendices in the Derived Test Requirements for:
Added p. 6
 The Physical Attack Costing Potential Formulas have been updated to reflect a more granular approach for attack times and expertise that more appropriately recognizes security enhancements.

 Firmware scoping guidance has been added to deal with the increasing complexity of device designs to ensure the PTS evaluation scope includes any code that can be construed to be firmware.

 Additional guidance has been added for ensuring that devices are resistant to side-channel-based attacks. Side-channel attacks are those based on analyzing emanations from a device, such as power consumption, for the determination of sensitive information.
Added p. 9
• Message Authentication Codes (MACs)

• Part 1: Mechanisms using a block cipher ISO 9797-1 Banking

• Key Management (Retail) ISO 11568 Banking

• Secure Cryptographic Devices (Retail) ISO 13491 Financial services -- Requirements for message authentication using symmetric techniques Information Technology

• Encryption algorithms

• Encryption algorithms

• Part 1: General ISO/IEC 18033-1 Information technology -- Security techniques -- Encryption algorithms -- Part 3: Block ciphers ISO/IEC 18033-3 Information Technology
Added p. 11
Firmware/Software Version Number*: Use of “x” represents a request for field to be a variable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Additional versions:

Application Version Number*: (if applicable) Version of PCI PTS POI Security Requirements: V5 FAQ version:
Added p. 39
Authentication by secret information will become mandatory in POI v6.

 Is immediately and automatically erased if any physical or functional alteration to the device is attempted, and  Can be verified by the initial key-loading facility, but cannot feasibly be determined by unauthorized personnel.
Added p. 55
Least Privilege In information security, computer science, and other fields, the principle of least privilege (also known as the principle of minimal privilege or the principle of least authority) requires that in a particular abstraction layer of a computing environment, every module (such as a process, a user, or a program, depending on the subject) must be able to access only the information and resources that are necessary for its legitimate purpose Manual Key Entry The entry of cryptographic keys into a secure cryptographic device, using devices such as buttons, thumb wheels, or a keyboard.
Added p. 60
Unique Accountability Actions are attributable to a specific person or role.
Modified p. 1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements Version 4.1c
Payment Card Industry (PCI) PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements Version 5.0
Modified p. 2
July 2015 4.1a Updates for errata and new core section J
July 2015 4.1a Updates for errata and new core section J.
Removed p. 5
Version 3 introduced significant changes in how PCI will be evaluating PIN and non-PIN acceptance POI terminals. PCI no longer maintains three separate security evaluation programs (point-of-sale PIN entry device (PED), encrypting PIN pad (EPP), and unattended payment terminal (UPT)). Instead PCI provides and supports one set of modular requirements, which covers all product options.

This change was reflected in our renaming of this document to be the Modular Security Requirements.

The layout of the document was also changed to enable vendors to select the appropriate requirements that match the product they are submitting for evaluation.
Modified p. 5
This version 4 additionally provides for:
This version 5 additionally provides for:
Modified p. 5
 Greater granularity and robustness of the underlying PCI-recognized laboratory test procedures for compliance validation of a device to these requirements as detailed in the Derived Test Requirements.
Equipment Classification guidance for the equipment that is required to identify or exploit device vulnerabilities  Side-Channel Analysis Standards  Firmware Scoping Guidance  Greater granularity and robustness of the underlying PCI-recognized laboratory test procedures for compliance validation of a device to these requirements as detailed in the Derived Test Requirements.
Modified p. 5
Scope of the Document This document is part of the evaluation support set that laboratories require from vendors (details of which can be found in the PCI PTS Program Manual) and the set may include:
Scope of the Document This document is part of the evaluation support set that laboratories require from vendors (details of which can be found in the PCI PTS Device Testing and Approval Program Guide) and the set may include:
Modified p. 5 → 6
 Submission by the vendor for assessment and publication on the PCI website of a user-available security policy addressing the proper use of the POI in a secure fashion, as further delineated in requirement B20.
 Enhancements to the information required to be presented in the user-available security policy addressing the proper use of the POI in a secure fashion.
Removed p. 6
 The addition of a new Core Module section that applies to all POI device types that addresses the configuration and maintenance procedures relevant to the security of POI devices;  The addition of testing requirements to reflect that PTS evaluation laboratories will begin validating vendor documentation of vendor policies and procedures for compliance with the Device Management security requirements. These requirements were not previously assessed by the PTS laboratories and pertain to device management during manufacture and between manufacturer up until the facility of initial key loading or deployment, where other PCI requirements such as PIN Security and Point-to-Point Encryption (P2PE) provide coverage.
Modified p. 10 → 11
Device type claim POS terminal containing a PIN entry device (select one):
Device Details Device type claim POS terminal containing a PIN entry device (select one):
Modified p. 10 → 11
Hardware Version Number*A: Use of “x” represents a request for field to be a variable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Firmware/Software Version Number*: Use of “x” represents a request for field to be a variable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 …
Hardware Version Number*A: Use of “x” represents a request for field to be a variable 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Additional versions:
Modified p. 10 → 11
Validation modules required (where applicable, please see Section C

• Selection of Evaluation Modules):
Validation modules required (where applicable, please see Evaluation Module Groupings):
Modified p. 10 → 11
Yes No N/A Core PIN Entry Security POS Terminal Integration Open Protocols Secure Reading and Exchange of Data Previously Approved Components Used* (if applicable) Vendor Name Device Marketing/Model
Yes No N/A Core PIN Entry Security POS Terminal Integration Open Protocols Secure Reading and Exchange of Data Device Management Always Applicable:
Modified p. 10 → 11
PCI PTS Approval Product Type per PCI SSC Website Other Continued on next page * Fields marked with an asterisk (*) will be used in the PCI SSC Approved PIN Transaction Security Devices Approval List. A See “Optional Use of Variables in the Identifier,” following page.
* Fields marked with an asterisk (*) will be used in the PCI SSC Approved PIN Transaction Security Devices Approval List. A See “Optional Use of Variables in the Identifier,” following page.
Removed p. 16
A2 Failure of a single security mechanism does not compromise device security. Protection against a threat is based on a combination of at least two independent security mechanisms.
Modified p. 16 → 17
Note: The replacement of both the front and rear casings shall be considered as part of any attack scenario. All attacks shall include a minimum of ten hours’ attack time for exploitation.
Note: The replacement of both the front and rear casings shall be considered as part of any attack scenario.
Modified p. 16 → 17
A3 The security of the device is not compromised by altering:
A2 The security of the device is not compromised by altering:
Modified p. 16 → 17
 Environmental conditions  Operational conditions (An example includes subjecting the device to temperatures or operating voltages outside the stated operating ranges.) A4 Sensitive functions or data are only used in the protected area(s) of the device. Sensitive data and functions dealing with sensitive data are protected from modification without requiring an attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for exploitation, exclusive of the IC card reader, for identification and initial …
 Environmental conditions  Operational conditions (An example includes subjecting the device to temperatures or operating voltages outside the stated operating ranges.) A3 Sensitive functions or data are only used in the protected area(s) of the device. Sensitive data and functions dealing with sensitive data are protected from unauthorized modification without requiring an attack potential of at least 26 for identification and initial exploitation, with a minimum of 13 for exploitation, exclusive of the IC card reader, for identification and …
Modified p. 16 → 17
B As defined in Appendix B of the PCI PTS POI DTRs.
B As defined in Appendix B of the PCI PTS POI DTRs. C As defined in Appendix B of the PCI PTS POI DTRs.
Modified p. 17 → 18
A7 The unauthorized alteration of prompts for non-PIN data entry into the PIN entry key pad such that PINs are compromised, i.e., by prompting for the PIN entry when the output is not encrypted, cannot occur without requiring an attack potential of at least 18 per device for identification and initial exploitation with a minimum of 9 for exploitationC.
A6 The unauthorized alteration of prompts for non-PIN data entry into the PIN entry key pad such that PINs are compromised, i.e., by prompting for the PIN entry when the output is not encrypted, cannot occur without requiring an attack potential of at least 18 per device for identification and initial exploitation with a minimum of 9 for exploitationC.
Modified p. 17 → 18
A8 The device provides a means to deter the visual observation of PIN values as they are being entered by the cardholder.
A7 The device provides a means to deter the visual observation of PIN values as they are being entered by the cardholder.
Modified p. 17 → 18
A9 It is not feasible to penetrate the device to make any additions, substitutions, or modifications to the magnetic-stripe reader and associated hardware or software, in order to determine or modify magnetic-stripe track data, without requiring an attack potential of at least 16 per device, for identification and initial exploitation, with a minimum of 8 for exploitationC.
A8 It is not feasible to penetrate the device to make any additions, substitutions, or modifications to the magnetic-stripe reader and associated hardware or software, in order to determine or modify magnetic-stripe track data, without requiring an attack potential of at least 16 per device, for identification and initial exploitation, with a minimum of 8 for exploitationC.
Modified p. 18
A11 If PIN entry is accompanied by audible tones, the tone for each entered PIN digit is indistinguishable from the tone for any other entered PIN digit.
A10 If PIN entry is accompanied by audible tones, the tone for each entered PIN digit is indistinguishable from the tone for any other entered PIN digit.
Modified p. 19
B4 If the device allows updates of firmware, the device cryptographically authenticates the firmware and if the authenticity is not confirmed, the firmware update is rejected and deleted.
B4 The device must support firmware updates. The device must cryptographically authenticate the firmware and if the authenticity is not confirmed, the firmware update is rejected and deleted.
Modified p. 20
B13 It is not possible to encrypt or decrypt any arbitrary data using any PIN- encrypting key or key-encrypting key contained in the device.
B13 It is not possible to encrypt or decrypt any arbitrary data using any PIN- encrypting key, data-encrypting key, or key-encrypting key contained in the device.
Removed p. 22
Note: All attacks shall include a minimum of ten hours’ attack time for exploitation.
Modified p. 29
H2 The device has guidance that describes the default configuration for each protocol and services for each interface that is available on the device. Each interface and protocol on the device should default to secure settings. If the interface has the ability to be configurable to non-secure settings, vendor guidance should strongly recommend against configuring to non-secure settings.
H2 The device has guidance that describes the default configuration for each protocol and services for each interface that is available on the device. Each interface and protocol on the device should be configured with secure default settings. If the interface has the ability to be configurable to non-secure settings, vendor guidance should strongly recommend against configuring to non-secure settings.
Modified p. 29
d) Key-management security guidance ensures secure use of keys and certificates.
d) Key-management security guidance ensures secure use of keys and certificates, including certificate status (e.g., revoked), secure download, and roll-over of keys.
Modified p. 32
J3 If a deployed device can be updated, the device vendor maintains guidance describing how to update the device for both local and remote updates.
J3 The device vendor maintains guidance describing how to update the device for both local and remote updates.
Removed p. 34
K1.2 Failure of a single security mechanism does not compromise device security. Protection against a threat is based on a combination of at least two independent security mechanisms.
Modified p. 34
Note: MSRs and ICCRs must meet the attack potentials stipulated in DTRs A9 and D1 respectively.
Note: MSRs and ICCRs must meet the attack potentials stipulated in DTRs A8 and D1 respectively.
Modified p. 34
K3 Determination of any cryptographic keys used for account-data encryption, by penetration of the device and/or by monitoring emanations from the device (including power fluctuations), requires an attack potential of at least 26 for identification and initial exploitation with a minimum of 13 for exploitation.I K3.1 Public keys must be stored and used in a manner that protects against unauthorized modification or substitution. Unauthorized modification or substitution requires an attack potential of at least 26 for identification and initial exploitation …
K3 Determination of any cryptographic keys used for account-data encryption, by penetration of the device and/or by monitoring emanations from the device (including power fluctuations), requires an attack potential of at least 26 for identification and initial exploitation with a minimum of 13 for exploitation.I K3.1 Public keys must be stored and used in a manner that protects against unauthorized modification or substitution. Unauthorized modification or substitution requires an attack potential of at least 26 for identification and initial exploitation …
Modified p. 35
K12 If the device allows updates of firmware, the device cryptographically authenticates the firmware and if the authenticity is not confirmed, the firmware update is rejected and deleted.
K12 The device must support firmware updates. The device must cryptographically authenticate the firmware and if the authenticity is not confirmed, the firmware update is rejected and deleted.
Modified p. 38
Note: In the following requirements, the device under evaluation is referred to as the “device.” The device manufacturer, subject to PCI payment brand site inspections, confirms the following. The PCI test laboratories will validate this information via documentation reviews. Any variances to these requirements will be reported to PCI for review. However, this information will only be used for analyses at this time and will not impact whether a device receives an approval. Site inspections shall not begin until subsequent …
Note: In the following requirements, the device under evaluation is referred to as the “device.” The device manufacturer, subject to PCI payment brand site inspections, confirms the following. The PCI test laboratories will validate this information via documentation reviews, and by means of evidence that procedures are properly implemented and used. Any variances to these requirements will be reported to PCI for review. Site inspections shall not begin until subsequent to the publication of POI v5.
Modified p. 38
Number Description of Requirement Yes No N/A L1 Change-control procedures are in place so that any intended change to the physical or functional capabilities of the POI causes a re- certification of the device under the Physical Security Requirements or the Logical Security Requirements of this document. Immediate re- certification is not required for changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality. …
Number Description of Requirement Yes No N/A L1 Change-control procedures are in place so that any intended change to the physical or functional capabilities of the POI causes a re- certification of the device under the impacted security requirements of this document. Immediate re-certification is not required for changes that purely rectify errors and faults in software in order to make it function as intended and do not otherwise remove, modify, or add functionality that impacts security. Approval of delta …
Modified p. 40
Note: In the following requirements, the device under evaluation is referred to as the “device.” The device manufacturer, subject to PCI payment brand site inspections, confirms the following. The PCI test laboratories do not currently validate this information; however, the vendor is still required to complete these forms and the information will be reported to PCI for review, and if necessary corrective action. Site inspections shall not begin until subsequent to the publication of POI v5.
Note: In the following requirements, the device under evaluation is referred to as the “device.” The device manufacturer, subject to PCI payment brand site inspections, confirms the following. The PCI test laboratories will validate this information via documentation reviews and by means of evidence that procedures are properly implemented and used. Any variances to these requirements will be reported to PCI for review. Site inspections shall not begin until subsequent to the publication of POI v5.
Modified p. 40
Number Description of Requirement Yes No N/A M1 The POI should be protected from unauthorized modification with tamper-evident security features, and customers shall be provided with documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the POI.
Number Description of Requirement Yes No N/A M1 The POI should be protected from unauthorized modification with tamper-detection security features, and customers shall be provided with documentation (both shipped with the product and available securely online) that provides instruction on validating the authenticity and integrity of the POI.
Modified p. 40
Where this is not possible, the POI is shipped from the manufacturer’s facility to the initial key-loading facility or to the facility of initial deployment and stored en route under auditable controls that can account for the location of every POI at every point in time.
Where this is not possible, the POI is shipped from the manufacturer’s facility to the initial key-loading facility or to the facility of initial deployment and stored en route under auditable controls that can account for the location of every POI at every point in time•such as the use of serialized tamper-evident packing for all devices with no tamper detection, in conjunction with thorough physical inspection (possibly including sampling of HW internals) upon reception.
Modified p. 40
Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage they are managing is compliant with this requirement.
Where multiple parties are involved in organizing the shipping, it is the responsibility of each party to ensure that the shipping and storage they are managing is compliant with this requirement. In the absence of defined agreements stipulating otherwise, the POI vendor remains responsible.
Modified p. 40
M2 Procedures are in place to transfer accountability for the device from the manufacturer to the facility of initial deployment. Where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment.
M2 Procedures are in place to transfer accountability for the device from the manufacturer to the facility of initial deployment. Where the device is shipped via intermediaries such as resellers, accountability will be with the intermediary from the time at which they receive the device until the time it is received by the next intermediary or the point of initial deployment. In the absence of defined agreements stipulating otherwise, the POI vendor remains responsible.
Modified p. 40 → 41
 Shipped and stored in tamper-evident packaging; and/or  Shipped and stored containing a secret that is immediately and automatically erased if any physical or functional alteration to the device is attempted, that can be verified by the initial key-loading facility, but that cannot feasibly be determined by unauthorized personnel.
 Shipped and stored in tamper-evident packaging; and/or  Shipped and stored containing a secret that:
Modified p. 40 → 41
M4 The device’s development-security documentation must provide means to the initial key-loading facility to assure the authenticity of the TOE’s security relevant components.
M4 The device’s development-security documentation must provide means to the initial key-loading facility to assure the authenticity of the TOE’s security-relevant components.
Modified p. 46
2. For each of the supported functionalities, report any marking “x” from the functionality column to the baseline column. “x” stands for “applicable,” in which case the requirement must be considered for vendor questionnaire and possibly evaluation.
2. For each of the supported functionalities, report any marking “X” corresponding to the listed requirement. “X” stands for “applicable,” in which case the requirement must be considered for both the vendor questionnaire and evaluation. In all cases, if a security requirement is impacted, the device must be assessed against it.
Modified p. 46
Requirement Feedback to cardholder Device is a Implements TCP/IP stack account data Conditions Core Requirements Modules Core Physical Security Requirements A8 x If keypad that can be used to enter non-PIN data.
Requirement Feedback to cardholder Device is a Implements TCP/IP stack account data Conditions Core Requirements Modules Core Physical Security Requirements A7 X If keypad that can be used to enter non-PIN data.
Modified p. 53
Holds one or more professional credentials applicable to the field, e.g., doctoral-level qualifications in a relevant discipline or government certification in cryptography by an authoritative body (e.g., NSA).
Holds one or more professional credentials applicable to the field, e.g., doctoral-level qualifications in a relevant discipline or government certification in cryptography by an authoritative body (e.g., NSA).
Modified p. 53
Has published extensively in peer-reviewed publications on the relevant subject.
Has published extensively in peer-reviewed publications on the relevant subject.
Modified p. 53
Has years of experience in the relevant subject.
Has years of experience in the relevant subject.
Modified p. 53
Is recognized by his/her peers in the field (e.g., awarded the Fellow or Distinguished Fellow or similar professional recognition by an appropriate body, e.g., ACM, BCS, IEEE, IET, IACR).
Is recognized by his/her peers in the field (e.g., awarded the Fellow or Distinguished Fellow or similar professional recognition by an appropriate body, e.g., ACM, BCS, IEEE, IET, IACR).
Modified p. 53
Subscribes to an ethical code of conduct and would be subject to an ethics compliance process if warranted.
Subscribes to an ethical code of conduct and would be subject to an ethics compliance process if warranted.
Modified p. 55
Key Usage Employment of a key for the cryptographic purpose for which it was intended Key variant A new key formed by a process (which need not be secret) with the original key, such that one or more of the non-parity bits of the new key differ from the corresponding bits of the original key.
Key Usage Employment of a key for the cryptographic purpose for which it was intended Key Variant A new key formed by a process (which need not be secret) with the original key, such that one or more of the non-parity bits of the new key differ from the corresponding bits of the original key.
Modified p. 59
 A service keyboard (SK),  A service display (SD), and A service data exchange support (SDE), which may consist of a card reader, a floppy disk drive, a USB interface or the like.
 A service keyboard (SK),  A service display (SD), and A service data exchange support (SDE), which may consist of a card reader, a floppy disk drive, a USB interface or the like.