Document Comparison
PTS_Program_Guide_v1-7_May_2017.pdf
→
PTS_Program_Guide_v1-8.pdf
89% similar
53 → 56
Pages
17931 → 18869
Words
95
Content Changes
Content Changes
95 content changes. 59 administrative changes (dates, page numbers) hidden.
Added
p. 2
March 2018 1.8 Added SCRP approval class, including SCRP only specifications for new approvals and expiry dates. Added requirement for annual Attestation of Validation regarding firmware changes (Section 3). Changes in side channel testing. Added Appendix D: PTS Attestation of Validation. Errata.
Added
p. 5
PIN contains a complete set of requirements for the secure management, processing, and transmission of personal identification number (PIN) data during online and offline payment card transaction processing at ATMs and attended and unattended point-of-sale (POS) terminals.
• PTS POI: Frequently Asked Questions General frequently asked questions.
• PTS POI Security Requirements Technical FAQs for use with Version 5
• PTS PIN Security Requirements Technical FAQs for use with Version 2
• PIN Transaction Security (PTS) Point of Interaction (POI) Modular Evaluation Vendor Questionnaire, v5.1
• PIN Transaction Security (PTS) Point of Interaction (POI) Derived Test Requirements, v5.1
• PIN Transaction Security (PTS) Hardware Security Module (HSM) Derived Test Requirements, v3.0 Provide specific direction to vendors on methods the test laboratories may apply when testing against the requirements Recognized Laboratories List
• Payment Card Industry (PCI) Recognized Laboratories Currently recognized laboratories for PTS device testing.
• Payment Card Industry Vendor Release Contains the terms and conditions that govern …
• PTS POI: Frequently Asked Questions General frequently asked questions.
• PTS POI Security Requirements Technical FAQs for use with Version 5
• PTS PIN Security Requirements Technical FAQs for use with Version 2
• PIN Transaction Security (PTS) Point of Interaction (POI) Modular Evaluation Vendor Questionnaire, v5.1
• PIN Transaction Security (PTS) Point of Interaction (POI) Derived Test Requirements, v5.1
• PIN Transaction Security (PTS) Hardware Security Module (HSM) Derived Test Requirements, v3.0 Provide specific direction to vendors on methods the test laboratories may apply when testing against the requirements Recognized Laboratories List
• Payment Card Industry (PCI) Recognized Laboratories Currently recognized laboratories for PTS device testing.
• Payment Card Industry Vendor Release Contains the terms and conditions that govern …
Added
p. 16
Devices for which the approval has expired may also undergo deltas. This is because vendors may need to make maintenance fixes to devices that the vendor has already sold but must still provide support for. In addition, vendors may wish to port updated versions of firmware that were approved against newer security requirements to products for which the approval has expired. This may occur because customers of a vendor wish to standardize their deployment against a given version of firmware and/or to add functionality to that device.
As of 1 May, the vendor must complete and submit to PCI an Attestation of Validation (AOV) confirming adherence to the program guide•i.e., either the firmware has not been amended or the changes made are within the wildcard parameters or the changes were submitted for evaluation. For devices supporting open protocols, the vendor must provide evidentiary materials that an auditable record of an ongoing …
As of 1 May, the vendor must complete and submit to PCI an Attestation of Validation (AOV) confirming adherence to the program guide•i.e., either the firmware has not been amended or the changes made are within the wildcard parameters or the changes were submitted for evaluation. For devices supporting open protocols, the vendor must provide evidentiary materials that an auditable record of an ongoing …
Added
p. 18
• Robust side-channel testing is an important part of device assessment. Relevant side-channel test data (digitally represented waveforms and associated numerical data) produced by an evaluation must be stored by the laboratory for at least six months following device approval. The Council shall request some or all of this data to be provided as necessary. Laboratories should communicate with the Council to resolve any questions on this matter.
• Guidance on designing payment security devices to conform to the PCI security requirements
• Review of a vendor’s payment security device design, response to questions via e-mail or phone, and participation in conference calls to clarify requirements
• A preliminary physical security assessment on a vendor’s hardware
• Guidance on bringing a vendor’s payment security devices into compliance with the PCI requirements if areas of non-compliance are identified during the evaluation.
• Guidance on designing payment security devices to conform to the PCI security requirements
• Review of a vendor’s payment security device design, response to questions via e-mail or phone, and participation in conference calls to clarify requirements
• A preliminary physical security assessment on a vendor’s hardware
• Guidance on bringing a vendor’s payment security devices into compliance with the PCI requirements if areas of non-compliance are identified during the evaluation.
Added
p. 23
• Payment Security Device Identifier
• PIN Support (online, offline)
• Approved Components
For devices that embed other PCI-approved devices and are therefore basing their security on these sub-components (even partially), the renewal/expiration date shall be the earliest among all evaluations, including the embedded device itself.
• A revised Approval Letter will be issued to the vendor.
• Point of interaction or hardware security module
• Key-generation facility
• PIN Support (online, offline)
• Approved Components
For devices that embed other PCI-approved devices and are therefore basing their security on these sub-components (even partially), the renewal/expiration date shall be the earliest among all evaluations, including the embedded device itself.
• A revised Approval Letter will be issued to the vendor.
• Point of interaction or hardware security module
• Key-generation facility
Added
p. 29
COTS Commercial-off-the-Shelf device. A mobile device (e.g., smartphone or tablet) that is designed for mass-market distribution and is not designed specifically for payment processing.
SCR Secure Card Reader approval class SCRP Secure Card Reader PIN approval class.
SCR Secure Card Reader approval class SCRP Secure Card Reader PIN approval class.
Added
p. 33
• Application #, if applicable In order to ensure that the payment security device has received an approval, acquiring customers or their designated agents are strongly advised to purchase and deploy only those payment security device models with the information that matches exactly the designations given in the components of the Point of Interaction Device Identifier or the Hardware Security Module Identifier.
Added
p. 36
• PIN-entry technology
• Card Production and Personalization
• Cash Card Reloading
• Export of a key from one secure cryptographic device (SCD) to another SCD in plaintext, component, or enciphered form;
• Export of a key component from an SCD into a tamper- evident package (e.g., blind mailer);
• PIN-entry technology RAP This is for platforms that are used for remote administration of HSMs. Such administration may include device configuration and key-loading services.
• Is intended for use with a non-secure device, such as a mobile phone or other device; or
• May be defined as an OEM product type to be integrated into a POI terminal or ATM.
• A hybrid card reader
• A magnetic-stripe-only reader
• A chip-card-only reader
• A contactless-only reader SCRs must meet as applicable the ICCR and/or MSR requirements designated in Appendix B of the PCI PTS POI Security Requirements and the Secure Reading and Exchange of Data Module. If the device is …
• Card Production and Personalization
• Cash Card Reloading
• Export of a key from one secure cryptographic device (SCD) to another SCD in plaintext, component, or enciphered form;
• Export of a key component from an SCD into a tamper- evident package (e.g., blind mailer);
• PIN-entry technology RAP This is for platforms that are used for remote administration of HSMs. Such administration may include device configuration and key-loading services.
• Is intended for use with a non-secure device, such as a mobile phone or other device; or
• May be defined as an OEM product type to be integrated into a POI terminal or ATM.
• A hybrid card reader
• A magnetic-stripe-only reader
• A chip-card-only reader
• A contactless-only reader SCRs must meet as applicable the ICCR and/or MSR requirements designated in Appendix B of the PCI PTS POI Security Requirements and the Secure Reading and Exchange of Data Module. If the device is …
Added
p. 48
• V1.x: Requirements A1, A2, A3 & C1;
• V2.x: Requirements A1 & A7; and
• V3.x: Requirements A1 & A7 and
• V4x: Requirements A1, A6, B1 & B20
• V5x: Requirements A1, A5, B1 and B20
• V2.x: Requirements A1 & A7; and
• V3.x: Requirements A1 & A7 and
• V4x: Requirements A1, A6, B1 & B20
• V5x: Requirements A1, A5, B1 and B20
Added
p. 50
• Name of the approved PTS device;
• New hardware, firmware, and application version numbers, as applicable, to be assessed;
• Details of the currently approved PTS device on the List of Approved PTS Devices that is being used as a reference for the assessment;
• Details of the PTS Lab that performed the original evaluation on the device, and information on any subsequent delta evaluations performed on that device since the original approval;
• Description of the change;
• Description of why the change is necessary;
• Description of how the change functions;
• Explanation of how and why PTS requirements are impacted;
• Description of testing performed by the vendor to validate how PTS Security Requirements are impacted; and
• Description of how the identification (versioning) of the change fits into vendor’s configuration- control methodology.
• The reference approval report and any subsequent delta submissions upon which the current delta submission is based; and
• Any supporting documentation used …
• New hardware, firmware, and application version numbers, as applicable, to be assessed;
• Details of the currently approved PTS device on the List of Approved PTS Devices that is being used as a reference for the assessment;
• Details of the PTS Lab that performed the original evaluation on the device, and information on any subsequent delta evaluations performed on that device since the original approval;
• Description of the change;
• Description of why the change is necessary;
• Description of how the change functions;
• Explanation of how and why PTS requirements are impacted;
• Description of testing performed by the vendor to validate how PTS Security Requirements are impacted; and
• Description of how the identification (versioning) of the change fits into vendor’s configuration- control methodology.
• The reference approval report and any subsequent delta submissions upon which the current delta submission is based; and
• Any supporting documentation used …
Added
p. 54
The PTS vendor should complete all applicable sections and submit this document along with copies of all required validation documentation to PCIPTS@pcisecuritystandards.org per PCI SSC’s instructions for report submission as described in the PTS Device Testing and Approval Program Guide.
Part 1. PTS Vendor Company name:
Business address: City:
State/Province: Country: Postal code:
Part 1. PTS Vendor Company name:
Business address: City:
State/Province: Country: Postal code:
Added
p. 55
A: No modifications have been made to the firmware version; B: Firmware version noted uses a validated wildcard versioning methodology, and only “No Impact” changes have been made; or C: All changes have been submitted for evaluation by a PTS laboratory that did not fit into category B. This includes for POI devices all vulnerabilities identified by the vendor in each of the protocols and interfaces defined in POI security requirement F1 as evidenced by the vulnerability assessment process enumerated under Section G of the POI DTRs.
PTS Approval Number Model Name Firmware submission status for the 12 months ending December 31 of the prior year
PTS Approval Number Model Name Firmware submission status for the 12 months ending December 31 of the prior year
Modified
p. 1
Payment Card Industry (PCI) PIN Transaction Security (PTS) Device Testing and Approval Program Guide Version 1.7
Payment Card Industry (PCI) PIN Transaction Security (PTS) Device Testing and Approval Program Guide Version 1.8
Modified
p. 2
May 2017 1.7 Added requirement for security policy modification for administrative changes. Added text to call out where ISO PIN Block Format 4 is used for PIN encryption, specifically AES, and the method in which used, i.e., DUKPT, Fixed or Master/Session Key. Updated Appendix B for POI v5
May 2017 1.7 Added requirement for security policy modification for administrative changes. Added text to call out where ISO PIN Block Format 4 is used for PIN encryption, specifically AES, and the method in which used•i.e., DUKPT, Fixed or Master/Session Key. Updated Appendix B for POI v5.
Modified
p. 5
Document Name Description Security Requirements PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, v5.0 PIN Security Requirements, v2.0 PIN Transaction Security (PTS) Hardware Security Module (HSM) Security Requirements, v3.0.0 Contain the physical and logical security requirements as well as device management requirements for activity prior to initial key loading.
Document Name Description Security Requirements • PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, v5.1
• PIN Transaction Security (PTS) Hardware Security Module (HSM) Security Requirements, v3.0
• PIN Security Requirements and Test Procedures, v2.0 POI and HSM contain the physical and logical security device requirements as well as device management requirements for activity prior to initial key loading.
• PIN Transaction Security (PTS) Hardware Security Module (HSM) Security Requirements, v3.0
• PIN Security Requirements and Test Procedures, v2.0 POI and HSM contain the physical and logical security device requirements as well as device management requirements for activity prior to initial key loading.
Modified
p. 5
• Hardware Security Module (HSM) Technical FAQs for use with Version 3 Provide additional and timely clarifications to the application of the Security Requirements. The FAQs are an integral part of those requirements and shall be fully considered during the evaluation process.
Modified
p. 5
• PIN Transaction Security (PTS) Hardware Security Module (HSM) Evaluation Vendor Questionnaire, v3.0 Solicit additional information from vendors to support their claims of the conformity of their devices to those requirements.
Modified
p. 6
• Approved PIN Transaction Security Devices List of PCI SSC Approved PIN Transaction Security Devices The documents above described are available in the “PIN Transaction Security” section of the PCI SSC website•www.pcisecuritystandards.org. Earlier versions of the documents are available can be found in the PIN Transaction Security Document Archive of the same website.
Modified
p. 8
• Point of interaction (POI) and hardware security module (HSM) security requirements,
Modified
p. 8
• “PCI participants” or “PCI payment brand participants” means any entity then-currently admitted as a member of the Council in accordance with the Delaware Limited Liability Company Act. The PCI participants as of the date hereof are American Express Travel Related Services Company, Inc., DFS Services LLC (Discover), JCB Advanced Technologies, Inc., MasterCard International Incorporated, and Visa Holdings, Inc.
Modified
p. 8
• “Point of interaction (POI) devices” refers broadly to all PIN-acceptance devices, used in consumer-facing transactions. Other consumer-facing device types, as delineated in Appendix A, may be included in the POI framework, to address any emerging threats to cardholder or PCI participants’ sensitive data.
Modified
p. 8
• “Hardware security modules (HSMs)” refers to secure cryptographic devices used for PIN processing, card personalization, cryptographic-key management and data protection.
Modified
p. 8
• “Payment security devices” refers to POI devices and HSMs, collectively.
Modified
p. 8
• “PIN Transaction Security” refers to the framework within PCI standards and requirements that deals with the evaluation and approval of payment security devices.
Modified
p. 9
• Security requirements, • Testing methodologies, and
Modified
p. 9
• Customers benefit from a broader selection of secure devices.
Modified
p. 9
• Merchants, financial institutions, processors, and other third parties are assured that they will be using products that have met the required level of assurance.
Modified
p. 9
• Vendors are able to reduce the “time to market” for new devices, as they will only be required to complete a single security evaluation and single approval process.
Modified
p. 11
Open Protocols (OP) The interface of POI terminals to open networks using open protocols Secure Reading and Exchange of Data (SRED) To support secure encryption of account data in the POI Device Management Security Requirements Considers how the device is produced, controlled, transported, stored, and used throughout its life cycle.
Open Protocols (OP) The interface of POI terminals to open networks using open protocols Secure Reading and Exchange of Data (SRED) To support secure encryption of account data in the Device Management Security Requirements Considers how the device is produced, controlled, transported, stored, and used throughout its life cycle.
Removed
p. 12
The laboratory does not evaluate the payment security devices against the Device Management Requirements as specified in the PCI PTS POI Modular Security Requirements or PCI HSM Security Requirements; nevertheless these are requirements, and the information is required as part of the approval process. Such conformance may be separately evaluated by PCI SSC at their discretion.
Removed
p. 16
Devices for which the approval has expired may also undergo deltas. This is because vendors may need to make maintenance fixes to devices that the vendor has already sold, but must still provide support for. In addition, vendors may wish to port updated versions of firmware that were approved against newer security requirements to products for which the approval has expired. This may occur because customers of a vendor wish to standardize their deployment against a given version of firmware and/or to add functionality to that device.
Modified
p. 16
Upon publication of a major new release (e.g., 3.x, 4.x, 5.x) there will be a twelve month period of overlap beginning May of the year the newer major version is published. Vendors may choose during that period to submit a device under either version of the security requirements. As of 1 May of the following year the older version of security requirements will only be available for delta evaluations.
Upon publication of a major new release (e.g., 3.x, 4.x, 5.x) there will be a twelve-month period of overlap beginning May of the year the newer major version is published. Vendors may choose during that period to submit a device under either version of the security requirements. The exception for this is SCRPs, which for new approvals must always use the most current version of the Security Requirements. As of 1 May of the following year, the older version of …
Modified
p. 17
• Software quality procedures • Documentation and software control procedures • Change control logs
Removed
p. 18
Robust side-channel testing is an important part of device assessment. Relevant side-channel test data (digitally represented waveforms and associated numerical data) produced by an evaluation must be stored by the laboratory for at least four years following device approval. The Council shall request some or all of this data to be provided as necessary. Laboratories should communicate with the Council to resolve any questions on this matter.
Modified
p. 18
• Device samples: Two (2) terminals containing the same keys and applications as those supplied to the PCI-recognized laboratory. This includes all approval classes. For large items, please notify via contact details below before shipping. Provision of device samples is a necessary part of a device’s approval. These will be securely retained and may be used to assess vulnerability to new attack techniques. If a model is ever compromised in the field, the retained samples may be used to investigate …
Modified
p. 18
• Robust logical-anomalies testing is an important part of device assessment. Relevant fuzzing data examples (output data and/or logs, reports, etc.), providing a representative and comprehendible summary of the fuzzing attack test runs must be presented within or accompanying evaluation reports, indicating what testing was performed and why, in sufficient detail to explain testing rationale and conclusions.
Modified
p. 18
Attn: MasterCard Global Products and Solutions MasterCard Worldwide 5 Booths Park Chelford Road Cheshire WA16 8QZ Contact: Mrs. Deborah Corness Telephone: +44 (0)1565 626600 Fax: +44 (0)7738 202 663 E-mail: deborah_corness@mastercard.com
Attn: MasterCard Global Products and Solutions MasterCard Worldwide 5 Booths Park Chelford Road Cheshire WA16 8QZ Contact: Mrs. Deborah Corness Telephone: +44 (0)1565 626500 Fax: +44 (0)7738 202 663 E-mail: deborah_corness@mastercard.com
Removed
p. 19
Guidance on designing payment security devices to conform to the PCI security requirements Review of a vendor’s payment security device design, response to questions via e-mail or phone, and participation in conference calls to clarify requirements A preliminary physical security assessment on a vendor’s hardware Guidance on bringing a vendor’s payment security devices into compliance with the PCI requirements if areas of non-compliance are identified during the evaluation.
Modified
p. 19
Vendors are encouraged to contact a PCI-recognized laboratory directly in regards to the above services and any fees associated with them. However, the laboratories cannot offer any advice on the actual design of the POI device or HSM.
Vendors are encouraged to contact a PCI-recognized laboratory directly in regard to the above services and any fees associated with them. However, the laboratories cannot offer any advice on the actual design of the POI device or HSM.
Modified
p. 20
• An application error causes all testing within a portion of the logical software code to function incorrectly, preventing further testing within that area of the application.
Modified
p. 20
• The payment security device contains a catastrophic failure that prevents any continuation of testing.
Modified
p. 20
• Testing exceeds the scheduled test cycle length.
Modified
p. 20
• The vendor requests termination of the test cycle.
Removed
p. 23
Payment Security Device Identifier Approval Number Product Type Approval Class Version Expiry Date PIN Support (online, offline)
• POI only Key Management
• POI only Prompt Control Functions Provided Approved Components
• POI only Key Management
• POI only Prompt Control Functions Provided Approved Components
Modified
p. 23
Note: PCI SSC will not grant any “partial approvals” based upon the ability of a PTS device to meet some
•but not all
•of the applicable required physical or logical security requirements For various reasons, including revocation of approval, information on approval letters may become inaccurate.Therefore the PCI website is considered the authoritative source and should always be used to validate the approval status of a vendor’s product.
•but not all
•of the applicable required physical or logical security requirements For various reasons, including revocation of approval, information on approval letters may become inaccurate.
Note: PCI SSC will not grant any “partial approvals” based upon the ability of a PTS device to meet some
•but not all
•of the applicable required physical or logical security requirements For various reasons, including revocation of approval, information on approval letters may become inaccurate. Therefore, the PCI website is considered the authoritative source and should always be used to validate the approval status of a vendor’s product.
•but not all
•of the applicable required physical or logical security requirements For various reasons, including revocation of approval, information on approval letters may become inaccurate. Therefore, the PCI website is considered the authoritative source and should always be used to validate the approval status of a vendor’s product.
Modified
p. 23
The following diagram shows the relationship between the expiration of device model tested under Version 3 of PCI PTS POI Security Requirements and its laboratory testing work.
The following diagram shows the relationship between the expiration of device model tested under Version 5 of PCI PTS POI Security Requirements and its laboratory testing work.
Modified
p. 25 → 24
• The approved payment security device listing on the PCI website would be updated accordingly with the new information, and
Modified
p. 26 → 25
In all cases, the licensed device will receive a new approval number and the licensee vendor or third party shall be billed the annual listing fee for each such approval.
In all cases, the licensed device will receive a new approval number, and the licensee vendor or third party shall be billed the annual listing fee for each such approval.
Modified
p. 27 → 26
• Key-loading facility The vendor must also provide immediate feedback about any potential impact this (possible or actual) breach may or will have.
Modified
p. 27 → 26
• The number and location of actual products affected • The number of compromised accounts, (if known) • Details of any compromised keys • Any reports detailing the security breach or compromise • Any reports or evaluations performed to investigate the security breach or compromise
Modified
p. 28 → 27
• Notify PCI payment brand participants that a security weakness or compromise has occurred.
Modified
p. 28 → 27
• Attempt to obtain the compromised terminal to evaluate exactly how the compromise occurred. This may include utilizing PCI-recognized laboratories.
Modified
p. 28 → 27
• Contact the vendor to inform them that their product has a security weakness, or has been compromised and, where possible, share information relating to the actual weakness or compromise.
Modified
p. 28 → 27
• Work with the vendor to try and mitigate or prevent further compromises.
Modified
p. 28 → 27
• Work with appropriate law enforcement agencies to help mitigate or prevent further compromises.
Modified
p. 28 → 27
• Perform evaluations on the compromised product either internally or under the terms of PCI SSC’s Payment Card Industry Vendor Release Agreement, using PCI-recognized laboratories to identify the cause of the compromise.
Modified
p. 28 → 27
• It is clear that the payment security device does not offer sufficient protection against current threats and does not conform to security requirements. If PCI SSC considers that the payment security device has a security weakness or has been compromised, PCI SSC will notify the vendor in writing of its intent to withdraw its approval of that payment security device.
Modified
p. 28 → 27
• The vendor does not either meet contractual obligations vis-à-vis PCI SSC or strictly follow the terms of participation on the PCI PTS program as described in this document or the Payment Card Industry Vendor Release Agreement.
Modified
p. 31 → 30
Terminal Commercial device with a business function. It may be dedicated to payment (POS terminal with integrated or separate PIN pad) or to product-dispensing (for example, an ATM or petrol-dispensing self-service).
SPoC Software-based PIN-entry on COTS SRED Secure Reading and Exchange of Data Terminal Commercial device with a business function. It may be dedicated to payment (POS terminal with integrated or separate PIN pad) or to product-dispensing (for example, an ATM or petrol-dispensing self-service).
Modified
p. 33 → 32
• Approval is valid only when 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.
• Approval is valid only when 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.
Modified
p. 33 → 32
• Approval is valid in any environment.
• Approval is valid in any environment.
Removed
p. 34
Vendor Name Model Name/Number, Hardware #, Firmware #, and Application #, if applicable In order to ensure that the payment security device has received an approval, acquiring customers or their designated agents are strongly advised to purchase and deploy only those payment security device models with the information that matches exactly the designations given in the components of the Point of Interaction Device Identifier or the Hardware Security Module Identifier.
Modified
p. 35 → 34
Table 4: Examples on the Use of Hardware #s Hardware # of Payment Security Device in the Approval List Comments NN-421-000-AB Hardware # NN-421-000-AB of the Device Identifier does not employ the use of the variable "x." Hence, the payment security device being deployed must match the Hardware # exactly in order for the PTS device to be considered an approved payment security device (hardware component).
Table 4: Examples on the Use of Hardware #s Hardware # of Payment Security Device in the Approval List NN-421-000-AB Hardware # NN-421-000-AB of the Device Identifier does not employ the use of the variable "x." Hence, the payment security device being deployed must match the Hardware # exactly in order for the PTS device to be considered an approved payment security device (hardware component).
Modified
p. 35 → 34
NN-4x1-0x0-Ax Hardware # NN-4x1-0x0-Ax of the Device Identifier does employ the use of the variable "x." Hence, the payment security device being deployed must match the Hardware # exactly in only those position(s) where there is no "x." Actual Hardware # of POI Supplied by Vendor Comments NN-421-090-AC If the PCI website lists NN-421-000-AB as the Hardware # in the Device Identifier, then the payment security device with the Hardware # NN-421-090- AC cannot be considered an approved payment security …
NN-4x1-0x0-Ax Hardware # NN-4x1-0x0-Ax of the Device Identifier does employ the use of the variable "x." Hence, the payment security device being deployed must match the Hardware # exactly in only those position(s) where there is no "x." Actual Hardware # of POI Supplied by NN-421-090-AC If the PCI website lists NN-421-000-AB as the Hardware # in the Device Identifier, then the payment security device with the Hardware # NN-421-090-AC cannot be considered an approved payment security device (hardware component). …
Modified
p. 35 → 34
NN-421-090-YC If the PCI website lists NN-4x1-0x0-Ax as the Hardware # in the Device Identifier, then the payment security device with the Hardware # NN-421-090- YC cannot be considered an approved payment security device (hardware component).
NN-421-090-YC If the PCI website lists NN-4x1-0x0-Ax as the Hardware # in the Device Identifier, then the payment security device with the Hardware # NN-421-090-YC cannot be considered an approved payment security device (hardware component).
Modified
p. 36 → 35
A.9 Product Type The product type gives an insight on both the approval class of a device, and whether the device is a module to be integrated (OEM) or is ready-to-deploy equipment. The product type may be prefixed with “OEM” if the approved device is clearly designed to be integrated into a wider set, or as a Non-PED to clearly differentiate a non-PIN-acceptance POI device from a PIN-acceptance POI device.
A.9 Product Type The product type gives an insight on both the approval class of a device, and whether the device is a module to be integrated (OEM) or is ready-to-deploy equipment. The product type may be prefixed with “OEM” if the approved device is clearly designed to be integrated into a wider set, or as a non-PED to clearly differentiate a non-PIN-acceptance POI device from a PIN-acceptance POI device.
Removed
p. 37
Display PIN support Prompt control Key management PIN-entry technology EPP An approval class aimed at secure PIN entry and encryption modules in an unattended PIN-acceptance device. An EPP may have a built-in display or card reader, or rely upon external displays or card readers installed in the unattended device.
PIN support Prompt control Key management PIN-entry technology ICCR MSR CTLS SRED OP
PIN support Prompt control Key management PIN-entry technology ICCR MSR CTLS SRED OP
Modified
p. 37 → 36
Table 5: Approval Class Descriptions Class Description Potential Features (see Table 7 below for detail) PED An approval class aimed at POI devices, originally designed for supporting payment with PIN entry, and dedicated to payment. A PED must have an integrated display unless dedicated to PIN entry only. This class may cover both attended and unattended environments and OEM or stand-alone products.
Table 5: Approval Class Descriptions Class Description Potential Features (see Table 7 below for detail) EPP An approval class aimed at secure PIN entry and encryption modules in an unattended PIN-acceptance device. An EPP may have a built-in display or card reader, or rely upon external displays or card readers installed in the unattended device.
Modified
p. 37 → 36
An EPP is typically used in an unattended PIN-acceptance device for PIN entry and is controlled by a device controller. An EPP has a clearly defined physical and logical boundary and a tamper-resistant/responsive or tamper-evident shell. At a minimum, a device submitted for EPP approval must contain a PIN-entry keypad along with its built-in secure cryptographic module. Original equipment manufacturers (OEMs) or providers of encrypting PIN pads (EPPs) to unattended PIN-acceptance device manufacturers (e.g., ATMs or UPTs) and other self- …
An EPP is typically used in an unattended PIN-acceptance device for PIN entry and is controlled by a device controller. An EPP has a clearly defined physical and logical boundary and a tamper-resistant/responsive or tamper-evident shell. At a minimum, a device submitted for EPP approval must contain a PIN-entry keypad along with its built-in secure cryptographic module. Original equipment manufacturers (OEMs) or providers of encrypting PIN pads (EPPs) to unattended PIN- acceptance device manufacturers (e.g., ATMs or UPTs) and other …
Removed
p. 38
PIN Processing 3-D Secure Card Verification Card Production and Personalization ATM Interchange Cash Card Reloading Data Integrity Chip Card Transaction Processing UPT The UPT class of device covers cardholder-operated payment devices that read, capture, and transmit card information in conjunction with an unattended self-service device, including, but not limited to, the following:
Modified
p. 38 → 37
• Chip Card Transaction Processing KLD An SCD that may be used for securely receiving, storing, and transferring data between compatible cryptographic and communications equipment. Key-transfer and loading functions include the following:
Modified
p. 38 → 37
• Import of key components into an SCD from a tamper- evident package; Temporary storage of the key in plaintext, component, or enciphered form within an SCD during transfer.
Removed
p. 39
A Secure Card Reader can be A Hybrid Card Reader A Magnetic-stripe-only Reader A Chip-card-only Reader A Contactless-only Reader SCRs must meet as applicable the ICCR and/or MSR requirements designated in Appendix B of the PCI PTS POI Security Requirements and the Secure Reading and Exchange of Data Module. If the device is capable of communicating over an IP network or uses a public domain protocol (such as but not limited to Wi-Fi or Bluetooth), then requirements specified in the Open Protocols Module must also be met. Other requirements, such as B1, Self-tests, and B9, Random Numbers, may apply depending on device functionality.
Modified
p. 40
A.11 Version Version refers to the version of the security requirements the device has been evaluated against. Each approval class may follow its own version release schedule.
PIN support Prompt control Key management PIN-entry technology A.11 Version Version refers to the version of the security requirements the device has been evaluated against. Each approval class may follow its own version release schedule.
Modified
p. 41
Note: Readers should note that the approval cycle for PCI-approved devices is different than that of pre-PCI approved devices. Approvals for most pre-PCI devices ended on 31 December 2007
Note: Readers should note that the approval cycle for PCI-approved devices is different than that of pre-PCI approved devices. Approvals for most pre-PCI devices ended on 31 December 2007.
Modified
p. 42
Table 7: Specific Features Feature and Applicability Description PIN Support (PED, EPP, SCR, UPT) “PIN Support” denotes the type of PIN entry verification that can be supported by the POI. “Online” represents that the POI has the capability to support online PIN verification by the payment card’s issuer or its designated processor. To pass testing, POIs that support online PIN entry must support the use of TDES or AES to protect the PIN. Additionally, if the PIN needs to be …
Table 7: Specific Features Feature and Applicability Description PIN Support (PED, EPP, SCR, SCRP, UPT) “PIN Support” denotes the type of PIN entry verification that can be supported by the POI. “Online” represents that the POI has the capability to support online PIN verification by the payment card’s issuer or its designated processor. To pass testing, POIs that support online PIN entry must support the use of TDES or AES to protect the PIN. Additionally, if the PIN needs to …
Modified
p. 42
Key Management (PED, EPP, UPT) “Key management” denotes whether the laboratory has successfully evaluated the payment security device to support the use of Triple DES (TDES) or AES for PIN encryption for online PIN. TDES requires use of at least a double-length key.
Key Management (PED, EPP, SCRP, UPT) “Key management” denotes whether the laboratory has successfully evaluated the payment security device to support the use of Triple DES (TDES) or AES for PIN encryption for online PIN. TDES requires use of at least a double-length key.
Modified
p. 43
• Physical keypad: Set of buttons arranged in a block which bears digits and optionally letters, in conformance with ISO 9564.
Modified
p. 43
• Touch screen: Display that can detect the presence and location of a touch within the display area, and enable the cardholder entering his or her PIN.
Modified
p. 43
Approved Components (PED, UPT) “Approved components” contains, when relevant, the list of approved subcomponents that are part of the approved device, and which have successfully undergone a distinct evaluation.
Modified
p. 44
• Approval is valid only when 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.
• Approval is valid only when 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.
Modified
p. 44
• Approval is valid in any environment.
• Approval is valid in any environment.
Modified
p. 44
• PIN entry: The device enables cardholder PIN capture.
Modified
p. 44
• Card reader capabilities: The device has components that can capture card data, such as magnetic-stripe reader (MSR) or ICC reader (ICCR) or Contactless (CTLS).
Modified
p. 44
• Display: The device has an integrated display used for cardholder prompts and possibly the presentation of other information.
Modified
p. 44
• SRED: The device has met the requirements in the Secure Reading and Exchange of Data module.
Modified
p. 44
• OP: The device has met the requirements in the Open Protocols module.
Modified
p. 45
• Revisions to existing firmware or hardware on previously approved devices to add or modify functionality; • Adding EMV Level 1 to an existing approval; • Maintenance fixes on devices that have expired approvals; • Assessment of a device for offline PIN entry where the existing approval is only for online PIN entry, or vice versa; • The porting of a new set of firmware to an existing approved device.
Modified
p. 46
Firmware Change Types Impacted Requirements PTS Standard Version v1.x v2.x v3.x v4.x V5.x Any firmware change N/A N/A N/A B20 B20 Firmware changes with no apparent impact on PCI Requirements B3 B3 G1, H1, I1 B3, F1 B3, F1 Amendments in secure tamper-recovery methodology B1 B1 B1 B1 B1 Error handling (i.e., buffer overflows) A5, B2 A3, B2 A3, B2 A3, B2 A2, B2 Amendments to external communications protocols B2 B2 B2, F1 B2, F1 Change to software/firmware update mechanisms …
Firmware Change Types Impacted Requirements PTS Standard Version v1.x v2.x v3.x v4.x v5.x Any firmware change N/A N/A N/A B20 B20 Firmware changes with no apparent impact on PCI Requirements B3 B3 G1, H1, I1 B3, F1 B3, F1 Amendments in secure tamper-recovery methodology B1 B1 B1 B1 B1 Error handling (i.e., buffer overflows) A5, B2 A3, B2 A3, B2 A3, B2 A2, B2 Amendments to external communications protocols B2 B2 B2, F1 B2, F1 Change to software/firmware update mechanisms …
Modified
p. 48
Hardware Change Types Impacted Requirements PTS Standard Version v1.x v2.x v3.x v4.x V5.x Any hardware change2 A1, A2, A3, C1 A1, A7 A1, A7 Changes in casing plastics (e.g., cover- opening dimensions, areas that permit internal access, changes to PED look and feel, etc.) or output-only displays. Amended devices must remain consistent to the device’s original form factor.
Hardware Change Types Impacted Requirements PTS Standard Version v1.x v2.x v3.x v4.x v5.x Any hardware change2 A1, A2, A3, C1 A1, A7 A1, A7 Changes in casing plastics (e.g., cover- opening dimensions, areas that permit internal access, changes to PED look and feel, etc.) or output-only displays. Amended devices must remain consistent to the device’s original form factor.
Modified
p. 48
A4, A7, A9-A11, A2, A6, A8-A11, A2, A6, A8-A11, B16, D1- A5, A7-A9, A11 B16, D1- A4, A6-A8, A10 B16, D1- Modification to tamper/removal switches (e.g., changes to materials, performance, location, circuitry, tamper response, etc.) or tamper-resistance/evidence features A5, D1 A2, A3, A11, D1 A2, A3, A10, D1 Modifications to the secure controller(s) A5, A6, A7, A9, B1-B10, A3, A4, A6, A8, B1-B15, A3, A4, A6, A8, A11, B1-B19, A3, A4, A5, A7, A10, B2-B19, A2, A3, A4, A6, A9, …
A4, A7, A9-A11, A2, A6, A8-A11, A2, A6, A8-A11, B16, D1- A5, A7-A9, A11 B16, D1- A4, A6-A8, A10 B16, D1- 2 This item is not to be included in the count of changes when determining whether the number of changes in a single delta submission is within the acceptable range of four (4).
Removed
p. 49
Name of the approved PTS device; New hardware, firmware, and application version numbers, as applicable, to be assessed; Details of the currently approved PTS device on the List of Approved PTS Devices that is being used as a reference for the assessment; Details of the PTS Lab that performed the original evaluation on the device, and information on any subsequent delta evaluations performed on that device since the original approval; Description of the change; Description of why the change is necessary; Description of how the change functions; Explanation of how and why PTS requirements are impacted; Description of testing performed by the vendor to validate how PTS Security Requirements are impacted; and Description of how the identification (versioning) of the change fits into vendor’s configuration- control methodology.
Removed
p. 50
A description of the change; Identification of the amended configuration item or items (system files or hardware components) impacted by the change; A high-level assessment of the security impact of the change; Identification of the PTS Security Requirements that are impacted by the change (including requirements for which the previous responses remain accurate without change); and A high-level description of the testing completed, if any, used to validate the assessment; Updated responses to the affected PTS Security Requirements that clearly depict any changes that are necessary to the reference assessments.
Modified
p. 50
• A high-level description of the changes that have been made to the approved PTS device;
Modified
p. 50
• A table that depicts the following information about every change embodied in the update to the approved PTS device from the previously approved configuration: