Over the last few months, the PCI SSC has published a set of documents to establish a new program for the specification, testing, evaluation and PCI SSC listing of Software-based PIN entry on Commercial Off The Shelf devices (COTS) Solutions. Solutions also known as SPoC.
The PCI DSS developed this new PCI Security Standard and program in response to the increasing popularity of mobile payments amongst smaller merchants and recognising that, for small merchants in EMV enabled markets, the cost of existing PCI PTS approved PIN entry devices can be a barrier to entry.
SPoC Solutions are expected to be more cost effective as they will allow merchants to accept EMV chip & PIN payments with just their mobile device, a small (but still PTS approved) card reader and a secure PIN entry app.
What is Software-based PIN entry on COTS (SPoC)?
SPoC Solutions offer an alternative approach to PIN Cardholder Verification Method (CVM) entry from the traditional hardware-based method we are used to. Hardware-based PIN entry relies on PCI PTS approved hardware PIN entry devices to ensure the protection of the cardholder’s PIN.
With SPoC, the protection of the software-based PIN entry is assured through the combination of a series of individual components and processes to make a secure ‘Solution’. The SPoC Solution allows the cardholder to present their EMV enabled card for payment and enter their PIN into the merchant’s COTS device, such as the merchant’s own smartphone or tablet, for authorisation:
Figure 1: High-level view of a SPoC Solution
A SPoC Solution comprises a set of components and processes that have been evaluated by a PCI-recognised Laboratory (approved to perform SPoC evaluations) in accordance with the SPoC Security Requirements and SPoC Test Requirements and subsequently accepted for listing by the PCI SSC under the SPoC Program.
PCI Approved SPoC Solutions will be listed here: https://www.pcisecuritystandards.org/assessors_and_solutions/spoc_solutions
The function of and evaluation requirements for each component/process is outlined below:
|A commercial office the shelf mobile device, such as a smartphone, tablet or wearable.|
Operated by the merchant to run the PIN CVM Application and connected to the SCRP.
Provides the network connectivity for the solution enabling communications with the back-end monitoring/attestation system and payment processing system.
|No evaluation – considered unknown and untrusted.|
Not included in PCI SSC SPoC Solution listing.
|Secure Card Reader – PIN (SCRP)||A physical card reading device that is connected to the merchant’s COTS device. Accepts only EMV chip or contactless cards.|
Includes the Secure Reading and Exchange of Data (SRED) component to encrypt captured account data.
Receives encrypted PIN block from the PIN CVM application.
Performs PIN translation for either online PIN verification (contact and contactless EMV) or offline PIN verification (contact EMV only).
|Evaluated to PCI PTS v5.1 or later, under the new SCRP Approval Class.|
Separately listed on the PCI SSC website as approved PTS devices.
|PIN Cardholder Verification Method (CVM) application||A mobile app installed on the merchant’s COTS device. Includes software protection mechanisms to maintain the app’s integrity against attack.|
Establishes a secure communications channel with the solution’s back-end monitoring/ attestation system to report the security status of the mobile payment platform (SCRP, COTS device and PIN CVM app).
Presents the PIN Entry screen on the COTS device. Accepts the cardholder’s PIN, encrypts the PIN data and sends it to the SCRP.
|Evaluated by PCI-recognised SPoC Lab as part of overall SPoC Solution Evaluation.|
PIN CVM applications are listed only as part of the SPoC Solution; they are not listed separately on PCI SSC website.
|Monitoring / Attestation System||A set of back-end systems performing functions such as Attestation, Monitoring and Processing:|
• Attestation – receives security status information from the PIN CVM Application and verifies that solution components are in a secure state (SCRP, COTS device and PIN CVM app)
• Monitoring – controls to detect, alert and mitigate suspected or actual threats against SCRP, COTS device and PIN CVM app. Also validates updates and patches have been implemented and that the COTS device has not been tampered with. It is a key aspect in the payment process.
• Processing – receives and processes the encrypted cardholder data and PIN data from the SCRP
|Evaluated by PCI-recognised SPoC Lab as part of overall SPoC Solution Evaluation.|
Monitoring/Attestation Systems are listed only as part of the SPoC Solution; they are not listed separately on PCI SSC website.
|Back-end Monitoring and Processing Environment||The environment(s) that the Attestation, Monitoring and Processing Systems reside in and operate from.|
The back-end Monitoring/Attestation Environment and the back-end Processing Environment may be separate.
|Monitoring Environment (if no PAN/SAD/PIN present): Appendix A Basic Protections evaluated by PCI-recognised SPoC Lab as part of overall SPoC Solution Evaluation.|
Monitoring Environment (if PAN/SAD present): validated as compliant with PCI DSS requirements incl. Appendix A3 DESV.
Monitoring Environment (if PIN present): PCI PIN Security Requirements Assessment by PIN Auditor.
Back-end Monitoring Environments are listed only as part of the SPoC Solution; they are not listed separately on PCI SSC website.
The technical detail
The principles and requirements for a SPoC Solution are defined in the SPoC Security Requirements document. The security objectives in this highly technical and extensive standard are enveloped in a number of core modules and appendices:
|Module 1: |
|Details the general requirements that define the security controls. It is the solution provider who is responsible for ensuring that they are in place.|
The general requirements include documentation of the sensitive services, the random number generators, and the whole cryptographic environment.
PIN Cardholder Verification Method (CVM) Application
|Concerns the PIN CVM application and how it displays the PIN values on screen, i.e. masked, and how it interacts with the SCRP and the encryption of the PIN.|
|Module 3: Back-end Systems – Monitoring/Attestation||This is essentially the management of the entire solution and it is here that anomalous and potentially fraudulent activity is detected and mitigated.|
It brings together all of the other components to ensure that they are all functioning correctly and securely and that cardholder data and PIN data are protected.
|Module 4: Solution Integration Requirements||Primarily concerns the integration requirements along with the governance and responsibility of the entire solution.|
The solution provider is responsible for ensuring that these requirements are implemented.
|Module 5: Back-end Systems – Processing||Details the back-end payment processing and the payment industry standards that must be adhered to when decrypting cardholder and PIN data to process the payment transaction.|
|Module 6: Secure Card Reader (SCRP)||Concerns the function of the SCRP devices and, in particular, ensuring that they are certified to recognised industry security requirement for design and manufacturing.|
|Appendix A: Monitoring Environment Basic Protections||Is primarily concerned with defining the minimum requirements that must exist to ensure fundamental security of the back-end monitoring system and back-end attestation component.|
It covers: A.1 Governance and Security Policies; A.2 Secure Networks; A.3 Vulnerability Management; A.4 Access Controls; A.5 Physical Security; A.6 Incident Response; A.7 Audit Logs.
|Appendix B||Is the separate SPoC Test Requirements document.|
|Appendix C||Details the minimum and equivalent cryptographic keys sizes and strengths.|
|Appendix D||Contains 15 requirements for Application Security.|
These include software development process, testing, code reviews, versioning, using industry best standards, common coding vulnerabilities and protections, risk assessment techniques for dealing with threats utilising threat modelling, monitoring and timely patching.
It also details release documentation and an implementation guide.
SPoC Evaluation and PCI-listing
The mobile payment acceptance solution provider has overall responsibility for their SPoC Solution.
The solution provider must ensure that the design, implementation and management of the solution fulfils the security requirements, i.e. that the software, monitoring and back-end processes have been designed based on industry best practices, that the solution is adequately tested, that the code is secure and verified, with fail-safe defaults, able to address anomalous behaviour and take action to mitigate potential and actual threats.
Other parties may be involved, including PIN CVM Application developers, Monitoring/Attestation System software application developers, back-end Monitoring and Processing environment hosting providers or third-party service providers such as Key Injection Facilities (KIF). The software or services these third-parties deliver must be included in the evaluation conducted by a PCI-recognised SPoC Laboratory (SPoC Lab).
The SPoC Solution provider engages a SPoC Lab to carry out the SPoC Solution Evaluation. The SPoC Lab’s assessment determines whether the candidate SPoC Solution complies with the SPoC Security Requirements, validating those requirements in accordance with the SPoC Test Requirements. This includes confirmation that the solution requires the use of a PCI PTS approved SCRP.
If the SPoC Lab concludes that the solution is compliant, they submit the completed SPoC Evaluation Report and SPoC Solution Attestation of Validation (AOV), the solution provider’s signed Vendor Release Agreement (VRA) and any other requested documentation to the PCI SSC.
The solution provider (vendor) must first pay the Acceptance Fee (note: this is a one-off fee). The PCI SSC will then review the Evaluation Report for quality assurance and compliance. The PCI SSC may require remedial actions, e.g. to address security requirements that are not in place or not sufficiently evidenced in the Evaluation Report; further testing by the SPoC Lab may be necessary.
An updated Evaluation Report is provided to the PCI SSC and, if accepted, the AOV is countersigned and the SPoC Solution added to the PCI SSC’s List of Validated SPoC Solutions.
Once accepted and listed by the PCI SSC, further actions are required to maintain that listing. The SPoC Program Guide describes in detail the re-evaluation and change procedures that must be followed.
SPoC Solutions require an annual ‘checkpoint’ re-evaluation. The SPoC Lab must review all changes made since the last evaluation, confirm that the Solution remains compliant with all applicable SPoC Security Requirements and submit an updated AOV and other applicable documentation to the PCI SSC.
A Solution’s listing will expire on the third anniversary of acceptance/listing unless a new full evaluation is carried out. A SPoC Solution’s listing may also need to be updated for administrative changes, the addition/removal of supported SCRP devices or PIN CVM Applications, or changes that have an impact on the security functions or compliance with the SPoC.
Much like the other PCI SSC maintained lists of approved solutions, such as PA-DSS validated payment applications and validated Point-to-Point Encryption (P2PE) Solutions, the published list of SPoC Solutions is intended as a resource for merchants and acquirers to help in their selection of a security assured and independently validated SPoC Solution suitable for their needs.
At this stage, the PCI DSS compliance validation required of a merchant using a listed SPoC Solution is not known. It is possible, using PCI-listed P2PE Solutions as a guide, that a specific SPoC Self-Assessment Questionnaire (SAQ) may be published by the PCI SCC for eligible SPoC-using merchants to use for their PCI DSS compliance assessment.
PCI DSS requirements such as physical security of hard copy card data, tamper inspection of SCRP devices and incident response procedures should still be applicable to and the responsibility of the merchant. It is expected that the card schemes will update their merchant compliance validation programmes to address SPoC Solutions.
What SPoC is not
Some points to note about SPoC Solutions:
- SPoC solutions are not ‘PIN on glass’. Loosely this phrase – the entry of the PIN value on to a “glass-based capture mechanism” does appear to mean SPoC Solutions but ‘PIN on glass’ also applies to a number of PCI PTS approved hardware-based point of interaction (POI) devices that use a touch screen for PIN entry. These ‘PIN on glass’ PTS approved devices are neither SPoC Solutions nor are they PTS approved SCRPs.
- SPoC Solutions are not available for non-EMV based contact magnetic stripe transactions. SCRPs are not permitted to have mag stripe read capabilities and contact mag stripe transaction are not permitted for SPoC solutions.
- SPoC Solutions are not suitable for use in unattended environments. SPoC solutions are intended for use only in attended environments where the merchant’s COTS device is made available to the customers. An example of unattended COTS device would be a tablet embedded as part of an unattended payment kiosk. SPoC solutions rely on the COTS device being ‘in hand’ with the merchant during the payment transaction interaction with the customer.
- Unlike the Point-to-Point Encryption (P2PE) Standard and Program, SPoC does not allow for merchants to put together their own combination of SCRP, PIN CVM Application and back-end monitoring system as a ‘merchant-managed’ SPoC solution. Only complete SPoC Solutions submitted by a vendor or solution provider will be approved and listed on the PCI SSC website, on the basis that they take overall responsibility for the design, implementation and management of their Solution, ensuring that all applicable SPoC Security Requirements are met.
- SPoC Solutions are not ‘PCI DSS compliant’, they are PCI approved solutions conforming to the PCI SPoC Security Requirements. Nor will use of a PCI-listed SPoC Solution automatically confer PCI DSS compliance on a merchant using it. Using a SPoC Solution may help to minimise applicable PCI DSS requirements and reduce a merchant’s PCI DSS compliance validation effort but will not completely remove the need for PCI DSS validation in the merchant environment. As noted above, the card schemes may update their PCI DSS compliance validation programmes to specifically accommodate PCI DSS and SPoC Solutions.
SPoC Reference Documents
|PCI Software-based PIN Entry on COTS Program Guide, v1.0||Overview of the SPoC Standard program, including the process for evaluating SPoC Solutions||Click here to view document|
|PCI Software-based PIN Entry on COTS Security Requirements (“SPoC Security Requirements”)||Defines the technical security requirements for a SPoC Solution, PIN CVM Application and supporting Monitoring/Attestation System and the back-end Monitoring Environment||Click here to view document|
|PCI Software-based PIN Entry on COTS Test Requirements (“SPoC Test Requirements”)||Specifies the testing processes to be performed by the evaluation laboratories to evaluate the Solution against the SPoC Security Requirements||Click here to view document|
|Software-based PIN Entry on COTS FAQs – Technical – For Use with Version 1||Technical FAQs regarding the application of the PCI SPoC security requirements and corresponding testing requirements||Click here to view document|
|PCI PIN Transaction Security (PTS) Point of Interaction (POI) Modular Security Requirements, version 5.1||The list of security requirements against Point of Interaction (POI) devices are evaluated in order to obtain PCI PIN Transaction Security (PTS) POI device approval.|
Updated in March 2018 to include criteria for the new Secure Card Reader – PIN (SCRP) approval class.
|Click here to view document|
 Mobile payments: mobile point-of-sale (MPOS) solutions that allow merchants to take orders and accept payments using a tablet or smartphone.