PCI PIN on COTS – Digging into The Details

Written by: Andrew Jamieson

February 28, 2018 -

In my previous blog post on this standard, I discussed the release of the PCI Software PIN on COTS (SPoC) requirements, and gave an overview of the technology itself. Now, with the release of the Testing Requirements, I will be discussing the difference between the two sets of documents that have now been released, how to interpret these, and what we can glean from these documents in terms of how such a solution will ultimately be tested.

Same Same but Different

Firstly, why have two documents in the first place? A major complexity of a SPoC solution is that it requires multiple different parties and technologies to work together to form an overall solution, and the ways in which these disparate elements are tested can be quite different – from detailed laboratory testing, through to backend audits. I used the below diagram in my last post, and it may help to understand the scope of testing outlined in the DTRs, so I copy it again below.


There are also different groups within businesses who are interested in understanding the SPoC requirements and process; spanning the range from business interests – who may ‘just’ want to get a handle on what this is and how it may affect their ongoing business – to technical developers who want to know exactly what the lab is going to be doing when their solution is being evaluated.

Having two sets of documentation for the one standard  is actually not without precedent in the PCI world. PCI PTS also has high level ‘Security Requirements’ document as well as a laboratory ‘Derived Test Requirements’ document.  One is used for vendors to attest to their compliance to the requirements, and the other as an outline of the testing procedures to be used by the laboratory to validate that the vendor attestation of compliance is valid.

So, the two documents can be seen as different descriptions of the same thing, just with different levels of detail and formatting do their different audiences.  Same same, but different.

The Devil is in the Details

Running through the requirements, we have six sections (A – F) each with different high level test items.  For ease of reading, I’ve copied these out below:

You can see that this lines up well with the Security Requirement modules, but there are some individual differences assumedly caused by the scope and requirements of testing (as discussed above).  However, the test requirements provide greater detail about what exactly the laboratory will be doing to validate that any solution is compliant to the overall SPoC requirements, and there are some interesting areas in these details.

It's only Logical

Appendix B of the SPoC Testing Requirements provides details on a new logical costing methodology.  I’ve talked about the need for logical costing systems in the past, and it’s great to see PCI working towards methods to ensure objective measurement of logical security features – at least as much as they can be objectively measured.  The costing method seems to borrow from various sources such as PCI PTS, JIL, and CVSS to try to create an approach for ‘scoring’ the logical security of the systems under test.  I expect that this sort of approach to logical security evaluation will become more common in the future, as we move towards making more of a science out of security evaluation and testing.

So, what’s costed?  Well, the requirement for the lab to calculate costing appears in requirements B1 (PIN CVM Application Tamper Resistance), B2 (Leakage During PIN CVM Entry), B4 (Determining Keys Analysis), and B10 (Secure PIN Entry Process).  What does not appear is the minimums for these costings, and it can probably be assumed that PCI is waiting on some real-world results to add these minimums in – which is prudent, I think, given that we’re dealing with something that is entirely new.

It’s also interesting to see that the requirements are very much focused on the laboratories having full access to all code and implementations.  This has implications for use of third party solutions for obfuscation, whitebox, etc – the lab is going to want/need to see the code for these things.  This is not impossible – as a PTS lab, we regularly work with chip vendors and other solution providers to get access to data that is not otherwise available to the solution integrator – but it does mean that if you’re working on a solution you will want to try to make sure that this need is expressed in your contracts with third parties in order to avoid painful discussions and problems later in the testing phase.

Monitoring your Attestation

From these testing requirements, including the costing method outlined in Appendix B, we are starting to get a better idea of just how important the monitor system is in any SPoC solution. Indeed in the high level requirements that have a costing calculation required there is the following text in the guidance:

So; no monitor, no soup for you.  Indeed, even if you have a monitor, and it is not good enough – still no soup for you.  I see this as one of the key challenges for anyone looking to setup a SPoC solution; the difficulty and complexity associated with establishing a sufficiently robust monitor solution cannot be easily overstated.  As I noted in my first blog on this, the monitor requirements are one of the reasons why SPoC is not just “an easy way to accept PINs”, it has its own sets of challenges, of which the monitor is a major component.  This may be most easily demonstrated by the fact that the monitor testing requirements (C2 – Tamper Response) have 20 sub-tests, which is more than any other requirement in the standard.

However, the potential advantage is what once you’ve spent your Non Refundable Engineering costs on establishing your monitor, the incremental cost of running a base of 1,000 merchants, or 1,000,000 merchants, is perhaps not as significant as if you need to have PTS approved POI devices for each merchant.

The journey has just begun

PCI notes in their blog post that we still await the release of the Program Guide and PTS v5.1 requirements that will outline the specifics for the SCRP.  These can be expected soon (in their blog, PCI notes that the Program Guide will be available in April), and from there it can be expected that real testing of solutions can begin.  Such testing will take time, and it is reasonable to expect that solution vendors will need more time to ensure they have solutions that are going to pass testing.  So, I expect that it will really only be towards the end of this year that we start to see systems compliant to the SPoC requirements appearing in the field. 

This means 2018 will really be a pivotal point in card present payments – will ‘traditional’ terminals still have a place in the land of SPoC?  This is something that we’ll find out over the next few years, but you can be very sure that the initial skirmishes of this battle will be fought during this year.  If you’re a payment technology vendor, a merchant, an acquirer, or even an Issuer; pay attention. 

What's your strategy for SPoC? If you would like to discuss how you can begin your journey, click here for a 1-on-1 with a UL Advisor.​


These are the personal opinions of UL’s employees and its guests and should not be misunderstood as representing the opinion of UL's clients, suppliers or other relations.