PCI Watch

Tracking changes across the Payment Card Industry

Document Comparison

SPoC_Technical_FAQs_v1.2_June_2018.pdf → SPoC_Technical_FAQs-v1.3.pdf
57% similar
7 → 13 Pages
2855 → 3332 Words
29 Content Changes

From Revision History

  • April 2018 1.0 Initial release.

Content Changes

29 content changes. 13 administrative changes (dates, page numbers) hidden.

Added p. 2
April 2018 1.0 Initial release.

May 2018 1.1 Added General Question Q4 and updated General Questions Q5 and Q13.

June 2018 1.2 Added General Question Q14, SPoC Security Requirement 3.6 Q1, and SPoC Security Requirement 5.1 Q1.

May 2019 1.3 Removed General Question Q8. Added General Question Q4, and updated General Question Q1, Q8, Q9 and Q11. Added SPoC Security Requirement 2.4 Q19, SPoC Test Requirement B2 Q25 and SPoC Test Requirement B5.2 Q26. Standardized terminology throughout the document. Minor grammatical updates.
Added p. 4
Q 1 [May 2019] Are contactless transactions allowed under the SPoC Standard? A Yes. The Standard supports both EMV-based and magnetic stripe mode contactless transactions.
Added p. 5
Q 4 [May 2019] Regarding “Customer Data” and “Correlatable Data”, what is the scope of this data? A The scope applies to data that is entered into a PIN CVM Application on a COTS Device as part of the payment transaction process, or sent from the Back-end Monitoring System to the COTS Device. The scope is limited to data entered by the cardholder at the time of the transaction for purposes such as receipt transmission.
Added p. 6
Q 7 Is SPoC synonymous with PIN on Glass? A No. The SPoC Standard covers a software-based approach for accepting a PIN as the cardholder verification method on a merchant-owned COTS Device. The phrase “PIN on Glass” is often used to describe a variety of use cases, where a PIN is entered on a glass-based capture mechanism; that is, a touch screen.

There are numerous PCI PIN Transaction Security (PTS) approved hardware- based POI devices that accept a PIN using a touch screen (PIN-on-Glass). These POI devices are built purposely for payment acceptance. Therefore, care must be taken when using the generic phrase “PIN-on-Glass”: for example, a PTS- approved POI device that accepts PIN-on-Glass is very different from a SPoC Solution that uses a merchant-facing COTS Device to accept a PIN.

Q 8 [May 2019] Are magnetic stripe-based transactions allowed by the SPoC Standard? A Yes. The Standard supports both EMV-based and …
Added p. 9
Q 15 Is it possible to include an operating system (OS) version in the COTS System Baseline of the initial Solution evaluation that is not supported by the OS vendor at the time of evaluation? A No. Security Requirement 2.2.2 requires that PIN CVM Applications must be developed only for operating systems that are still supported by the operating system vendor. All new Solutions must operate only on supported platforms. The initial COTS System Baseline must not include any version of a COTS OS that is not supported by the OS vendor at the time of the initial evaluation.

Q 19 [May 2019] Security Requirement 2.2.4 states that the PIN CVM Application must detect sensor activation and polling of sensor data. Does this requirement apply to all COTS Platforms? A The intent of the requirement is to protect the PIN entry process from manipulation or subversion. Because several attack vectors use …
Added p. 12
Q 23 If an OS vender issues an update to a COTS OS that was initially listed in the Solution System Baseline, does the SPoC Standard disallow transactions on COTS Devices using the updated OS until the updated OS is evaluated? A No. If an updated version of an OS that is already listed in the COTS System Baseline is made available by the original OS vendor, then the Solution Provider may add that version to the COTS System Baseline and must provide evidence that the acceptance and use of such a platform as a part of the annual update of the risk-assessment policy and procedure. If such evidence is accepted at time of the review by PCI SSC after review of the laboratory evaluation report, then the new platform may continue to be used.

SPoC Test Requirement B2

Q 25 [May 2019] Test Requirement TB2.5 calls for the disabling of on-device …
Removed p. 1
Payment Card Industry (PCI) Software-based PIN Entry on COTS Security Requirements Technical FAQs for use with Version 1

PCI Software-based PIN Entry on COTS FAQs
Removed p. 3
Q 1 Are non-EMV based contactless transactions allowed under the Software-based PIN Entry on COTS (SPoC) standard? A The Standard has been developed for chip-based transactions which support dynamic transaction data. The only method explicitly excluded is contact magnetic stripe because it has static transaction data. Contact magnetic stripe read capabilities are not permitted within SCRPs and contact magnetic stripe transactions are not permitted to be accepted or processed by SPoC solutions.
Modified p. 3 → 4
Q 2 In the SPOC TRs, where the attack costing thresholds are required, there is no minimum to be met. When will the attack costing threshold values be added and how should labs evaluate the relative requirements in the interim? A The PCI SSC will be working directly with the labs that are qualified to perform Solution assessments. Each assessment will be used to contribute relative attack costing information using actual Solution validation data that will factor in to the …
Q 2 In the SPoC Test Requirements (TRs), where the attack-costing thresholds are required, there is no minimum. When will the attack-costing threshold values be added, and how should labs evaluate the relative requirements in the interim? A The PCI SSC will work directly with the labs that are qualified to perform Solution assessments. Each assessment will be used to contribute relative attack-costing information using actual Solution validation data that will be factored into the development of appropriate attack-costing values. …
Modified p. 3 → 5
Q 3 Please explain the difference between a “session” and a “transaction” within the context of the Software-based PIN Entry on COTS (SPoC) standard? A A “session” is established when the PIN CVM Application is used to initiate a payment. This session includes establishing secure channels with the SCRP and with the back-end monitoring system. The session is terminated once the payment has completed or if any anomalous behavior is detected in The Solution at any point during the payment …
Q 3 Please explain the difference between a “session” and a “transaction” within the context of the SPoC Standard? A A “session” is established when the PIN CVM Application initiates a payment. This session establishes secure channels with the Secure card reader

• PIN (SCRP) and with the Back-end Monitoring System. The session terminates when payment is complete or when any anomalous behavior is detected in The Solution at any point during the payment process.
Modified p. 3 → 5
A “transaction” consists of the payment processing messages created and sent to and from the back-end payment processing systems to gain authorization for a customer.
A “transaction” consists of the payment processing messages created and exchanged with the Back-end Payment Processing Systems to gain authorization for a customer.
Modified p. 3 → 5
Q 4 What are the use cases for a SPoC Solution? SPoC Solutions are intended to be used in a face-to-face environment where the merchant hands the COTS device to the customer. The customer then enters their PIN and hands the COTS device back to the merchant.
Q 5 What are the use cases for a SPoC Solution? A SPoC Solutions are intended for use in a face-to-face environment where the merchant hands the COTS Device to the customer. The customer then enters a PIN and hands the COTS Device back to the merchant.
Modified p. 3 → 5
SPoC Solutions are not intended for environments where the device is part of a kiosk (semi- attended or self-checkout) or Automated Fuel Dispenser. These are unattended environments and pose a greater risk of compromise and are not permitted under this standard.
SPoC Solutions are not intended for environments where the device is part of a kiosk (semi-attended or self-checkout) or Automated Fuel Dispenser. These unattended environments pose a greater risk of compromise and are not permitted under this Standard.
Removed p. 4
Merchant COTS devices in unattended environments pose a higher risk of compromise and are not permitted under this standard. Unattended environments would mean the COTS device is not handed to the customer by the merchant or merchant staff but rather the COTS device is part of a kiosk (semi-attended or self-checkout) or of a vending machine with no merchant involvement at the time of the transaction.

Q 6 Is Software-based PIN Entry on COTS (SPoC) synonymous with PIN on Glass? A No. The SPoC Standard covers a software-based approach to for accepting PIN as the cardholder verification method on a merchant owned COTS device. The phrase “PIN on Glass” is often used generically regarding a variety of use cases, with the commonality simply being entering a PIN value on to a glass-based capture mechanism (i.e., a touch screen) on a variety of device types.

There are numerous PCI PTS approved hardware-based point …
Modified p. 4 → 5
Q 5 What is the intent of use of a SPoC Solution in an attended versus an unattended environment? A The intent of the SPoC standard is for merchant COTS devices in attended environments. Attended environments are when the COTS device is made available to the customer by the merchant during a payment transaction. For example, the merchant handing the COTS device to the customer. The customer enters their PIN and hands the COTS device back to the merchant.
Q 6 What is the intent of use of a SPoC Solution in an attended versus an unattended environment? A The SPoC Standard is intended for merchant COTS Devices in attended environments. Attended environments are when the COTS Device is made available to the customer by the merchant during a payment transaction. For example, the merchant hands the COTS Device to the customer. The customer enters a PIN and hands the COTS Device back to the merchant.
Modified p. 4 → 6
A SPoC Solution includes an SCRP (Secure Card Reader

• PIN), a PIN CVM application, the merchant’s COTS device as well as back-end monitoring and attestation systems. These elements all work together to ensure the PIN, accepted by a software application on the COTS device, is isolated within the COTS device from other sensitive account data. The back-end monitoring and attestation systems continuously monitor the entire solution for anomalous activity and to ensure The Solution has not deviated from the baseline …
A SPoC Solution includes an SCRP (Secure Card Reader

• PIN), a PIN CVM Application, the merchant’s COTS Device, and a Back-end Monitoring/Attestation Systems. These elements work together to ensure the PIN, which has been accepted by a software application on the COTS Device, is isolated within the COTS Device from other sensitive Account data. The Back-end Monitoring/Attestation Systems continuously monitor the entire Solution for anomalous activity and to ensure The Solution has not deviated from the baseline because of tampering, …
Removed p. 5
Q 9 Can a merchant use their existing SCR to accept payments in a SPoC Solution? A No. Merchants may only use the PTS approved and listed SCRP for use with the SPoC Solution. See FAQ Q7 (above) for more information.

Q 11 What constitutes a SPoC Solution? Does the SPOC standard cover separate components or is it a single solution? A Only the Secure Card Reader - PIN (SCRP) will have a separate listing as they are evaluated and listed as part of the PTS POI Standard. However, all SCRPs associated with a SPoC Solution will be included as part of the evaluation of a SPoC Solution and listed as part of that SPoC Solution’s approval.

A SPoC Solution consists of a PCI-approved SCRP(s), a PIN CVM Application, a merchant COTS device(s) and back-end monitoring and attestation systems. The SPoC Solution will be listed on the PCI website along with the …
Modified p. 5 → 7
Q 10 Can a merchant put together their own SPoC solution by choosing a SCRP, PIN CVM Application and back-end monitoring system? A No. Only complete SPoC Solutions will be approved and listed on the PCI SSC website.
Q 10 Can a merchant put together their own SPoC Solution by choosing an SCRP, PIN CVM Application, and Back-end Monitoring System? A No. Only complete SPoC Solutions will be approved and listed on the PCI SSC Website.
Modified p. 5 → 7
Q 12 What is a COTS device? A A commercial-off-the-shelf (COTS) device is a mobile device (i.e. smartphone, tablet or wearable) that is designed for mass-market distribution and is not designed specifically for payment processing.
Q 12 What is a COTS Device? A A commercial-off-the-shelf (COTS) Device is a mobile device (smartphone, tablet, or wearable) that is designed for mass-market distribution, but is not designed specifically for payment processing.
Modified p. 5 → 8
Q 14 Are there any restrictions to the specific form factors for COTS devices and SCRPs which can be approved under the PCI SPoC program? A No, the SPoC requirements do not dictate any specific form factor for the COTS device, the SCRP or the combination thereof for inclusion in an approved and validated SPoC Solution.
Q 14 Are there any restrictions to specific form factors for COTS Devices and SCRPs that can be approved under the PCI SPoC Program? A No, the SPoC requirements do not dictate a specific form factor for the COTS Device, the SCRP, or the combination thereof for inclusion in an approved and validated SPoC Solution.
Modified p. 5 → 10
SPoC Security Requirement 2.2
SPoC Security Requirement 2.4
Removed p. 6
Q1 SPoC Security Requirements 3.6.1 and 5.1.2 state that if the Back-End Monitoring system resides in the Cardholder Data Environment, then PCI DSS and Appendix A3: Designated Entities Supplemental Validation (DESV) will apply. Does a SPoC Solution Provider have to be fully compliant with DESV when submitting a SPoC Solution for initial validation? A If the Solution Provider cannot meet DESV requirements at the point of an initial SPoC solution validation, the Solution Provider must provide, to the SPoC lab, an action plan demonstrating that work is in progress for requirements to be met at the first annual checkpoint. The action plan will be reviewed for sufficiency.
Modified p. 6 → 9
Q 2 Security Requirement 2.2.3 states that the PIN CVM Application must only support platforms that provide for a “trusted boot” mechanism that validates the operating systems authenticity. What are the implications of this requirement recognizing that for certain Android versions (e.g. Android 4), some OEMs did not support sufficient hardware capabilities to implement secure boot mechanism and implications associated with scenarios where a clear designation of trust boot support of “yes or no” can be determined? A For such …
Q 16 Security Requirement 2.2.3 states that the PIN CVM Application must only support platforms that provide for a “trusted boot” mechanism that validates the operating systems authenticity. What are the implications of this requirement recognizing that for certain Android versions (such as Android 4), some OEMs did not support sufficient hardware capabilities to implement the secure boot mechanism? What are the implications associated with scenarios where a clear designation of trust boot support of “yes or no” cannot be …
Modified p. 6 → 9
Q 3 Does Security Requirement 2.2.3 include OS level or other system applications? A No. This requirement is not intended for OS level or other system applications.
Q 17 Does Security Requirement 2.2.3 include OS level or other system applications? A No. This requirement is not intended for OS level or other system applications.
Modified p. 6 → 10
Q 4 Security Requirement 2.2.5 states that, where white-box cryptography is used, white-box keys must be unique per PIN CVM Application instance and that the reliance and use of common white-box keys must be minimized after the secure provisioning process. Does this requirement as it relates to unique keys per PIN CVM Application apply to all white-box keys or just those used for encrypting PIN? A The intent of the requirement is that where white-box cryptography is used, the PIN …
Q 18 Security Requirement 2.2.5 states that where white-box cryptography is used, white-box keys must be unique for each PIN CVM Application instance, and that the reliance upon and use of common white-box keys must be minimized after the secure provisioning process. Does this requirement apply to all white-box keys as it relates to unique keys per PIN CVM Application, or just those used for encrypting a PIN? A The intent of the requirement is that where white-box cryptography is …
Removed p. 7
Q 2 If a new updated version of a COTS OS initially listed in the Solution System Baseline is made available by the original OS vendor, is it the intent of the SPOC standard to disallow transactions on affected COTS devices until the OS on those devices is evaluated? A No. If a new updated version of an OS which is already listed in the COTS System Baseline is made available by the original OS vendor then the Solution Provider may add that version to the COTS System Baseline and must provide justifications for the acceptance and use of such a platform as a part of the annual update of the risk-assessment policy and procedure. If such justifications are accepted at time of the review by PCI Council after review of the laboratory evaluation report then the new platform may continue to be used.
Modified p. 7 → 12
Q 1 If a version of the COTS OS initially listed in the Solution System Baseline reaches end of life such that it is no longer supported by the original OS vendor, is it the intent of the SPOC standard to disallow transactions on affected COTS devices until the OS on those devices is updated to a supported OS? A No. If a particular OS version has been assessed and is listed as included in the COTS System Baseline, (TR …
Q 22 If a version of the COTS OS initially listed in the Solution System Baseline reaches end-of-life such that it is no longer supported by the original OS vendor, does the SPoC Standard disallow transactions on affected COTS Devices until the OS on those devices is updated to a supported OS? A No. If an OS version has been assessed and is listed as part of the COTS System Baseline, (TR C1), and then the OS vendor ends support …
Modified p. 7 → 12
If such justifications are not provided or are not accepted by the PCI Council, the SPoC standard requires that merchants using the PIN CVM Application on affected platforms be notified by the Solution Provider and that the merchants are migrated to supported platforms. (SR 4.3.7).
If such evidence is not provided or is not accepted by the PCI SSC, the SPoC Standard requires that merchants who are using the PIN CVM Application on affected platforms be notified by the Solution Provider and that the merchants will be migrated to supported platforms. (SR 4.3.7).
Modified p. 7 → 13
Q1 SPoC Security Requirements 3.6.1 and 5.1.2 state that if the Back-End Monitoring system resides in the Cardholder Data Environment, then PCI DSS and Appendix A3: Designated Entities Supplemental Validation (DESV) will apply. Does a SPoC Solution Provider have to be fully compliant with DESV when submitting a SPoC Solution for initial validation? A If the Solution Provider cannot meet DESV requirements at the point of an initial SPoC solution validation, the Solution Provider must provide, to the SPoC lab, …
Q 24 SPoC Security Requirements 3.6.1 and 5.1.2 state that if the Back-end Monitoring System resides in the Cardholder Data Environment, then PCI DSS, Appendix A3, “Designated Entities Supplemental Validation (DESV)” will apply. Does an SPoC Solution Provider have to be fully compliant with DESV when submitting an SPoC Solution for initial validation? A If the Solution Provider cannot meet DESV requirements at the point of an initial SPoC Solution validation, the Solution Provider must provide an action plan to …