FAQS about the Evolution of the PCI PTS standard
December 2, 2016 - UL recently hosted a webinar about Evolution of the PCI PTS standard - An overview of the PCI PTS POI Version 5. We received quite a few questions on this topic, which we have listed and answered for you.
Which is the legal impact of not using AES pinblock format 4 at application level in a device certified under PCI-PTS V5? Is this solution "losing" PCI-PTS compliancy, or falling into V4?
If the device is previously approved and the version 5 doesn’t support AES pinblock format 4 then it will be listed on the website as not supporting pinblock format 4 but it won’t lose its approval. Any new devices must support AES pinblock format 4 or they won’t get their compliant report.
When will the SRED will be required?
SRED is required for any device looking for a secure card reader (SCR) approval or any POS device which attaches to a mobile phone through audio jack, USB, Bluetooth or any other interface. Other than that is mostly optional, however it is required for a PCI P2P encryption solution.
If PIN is not supported by the device this will, most likely, fall into the Secure Card Reader Module approval class, for which SRED is mandated. However, non-PED approval class devices, do exist which would not require SRED approval. It is important to ensure that your device is being assessed to the correct approval class.
How long the Version 5 will take compared to Version 4?
We estimate that Version 5 is taking 2 weeks longer than the previous version, with the added difficulties of the extra time on side channel attack and logical testing. In the end this will depend on the characteristics of the product.
What is the merchant obligation in terms of remote patch downloads required by PCI 5?
Responsibility for maintaining the compliance of the device logical operation post sale is on the Acquirer. The operational handling of this may be deferred to their agent, but the acquiring entity is _responsible_ (where 'acquiring entity' is defined by whomsoever is liable for PCI PIN compliance of the transaction originating device).
Can a device vendor do something to reduce the scope of Version 5?
If we have already performed the side channel for a chip and protected solution, we can cut down on side channel analysis, however we still need to check that the solution represented in the new device is the same that was previously tested. Regarding the scope it will depend on which modules are applicable, for example looking out for USB classes and not including wireless or TCP/IP enabled interfaces if you are looking to avoid module 3.
Certain test requirements, from each module, may not be applicable to all devices, and correctly identifying the not-applicable requirements will help to reduce the lab’s workload during the evaluation. If in doubt, assume that it is applicable; it will be faster for the lab to determine that a requirement is not applicable, than to request further information if a requirement is incorrectly marked N/A, by the vendor.
What are the common mistakes that vendors make when submitting their devices?
We usually see coding vulnerabilities with standard functions in C language such as “mem compare” “mem set”. Developers must be mindful of the security implications.
UL offers a pre evaluation service to help vendors to prepare to formal approvals. This service gives input at the prototyping stages as we can look at hardware and software and give the vendor an idea of potential vulnerabilities. The pre evaluation also gives an insight of the testing and the process before the formal evaluation.
Is it possible to use an independently developed secure protocol, instead of SSL/TLS, to meet the PCI requirements?
For open protocols it calls out certain security cipher suites when using TLS, however, the lab can evaluate the protocol to ensure that it provides integrity, confidentiality and session management. There are also certain FAQs which state that as long as the protocol is independently reviewed it is acceptable to use a non-TLS/non-standard solution for Core and SRED purposes (such as key loading) as well. In this case UL cannot act as an independent reviewer. It must be reviewed by a third party.
What are the risks of touch screens?
It is harder to secure a touch screen, as you are looking to protect an LCD. When using a touch screen, the LCD X-Y coordinates must be protected from disclosure as this will reveal a PIN, which is typically more difficult than protecting a physical keypad.
If using a non-standard key array (numbers in different places), on a touch screen, the keypad image must also be protected from disclosure along with the touchscreen coordinates.
Are applications a risk to the security of the device?
This is something we look at in both CORE and SRED, the separation of applications from firmware. It is very important to make sure that applications can’t access firmware memory space and secure memory space. Something else to consider with Android is making sure that any application which are downloaded or APK’s are also signed with your application signature key.
Does a display which is used on a NON-PED device (displaying amount only) also need to be certified?
Yes, if this is an integrated display. This will be certified as part of the device, the display should be controlled through the firmware.
No, if the display is an attached device. It won’t be approved as part of the NON-PED. The interface between the device and the attached display will still be evaluated.