“Can You Sell Me a PCI DSS Certified Reader?” is the Wrong Question

Here at ID TECH, we get a lot of technical questions about the payments business. People are sometime confused about Payment Card Industry requirements. For example, we get questions like: “Can you help me by providing a PCI DSS Certificate for these devices?” or “I don’t see X product on the PCI website, is it P2PE certified?”

 

b2ap3_thumbnail_sredkey_20171226-233502_1.jpg

These are common questions, yet these kinds of questions are sometimes motivated by faulty assumptions. If the assumption is that non-PCI-certified devices are inherently less secure than PCI-certified devices, that’s simply not the case.

ID TECH can supply PCI PTS SRED certified hardware (such as the SREDKey pictured at right; or the Augusta S, Spectrum Pro, SecuRED, VP8800, or others), but our non-SRED devices are still highly secure devices that can be used for most payment solutions being developed for the market.

PCI DSS is a systems solution requiring certification of all aspects of a payment system, not just the hardware device(s). PCI DSS includes 12 specific requirements about how a compliant solution must handle security of access and cardholder data. The following items come straight out of PCI documentation.

Control objectives

PCI DSS requirements

Build and maintain a secure network 1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
Protect cardholder data 3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks
Maintain a vulnerability management program 5. Use and regularly update anti-virus software on all systems commonly affected by malware
6. Develop and maintain secure systems and applications
Implement strong access control measures 7. Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
Regularly monitor and test networks 10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
Maintain an information security policy 12. Maintain a policy that addresses information security

In reading the requirements, there is no statement regarding what peripheral payment hardware PCI requires solution providers to include in their solution.  PCI is mostly concerned that you meet the requirements, and not so much with how you meet the requirements. When a solution provider goes for PCI DSS certification, they could use a non-encrypting reader, but that would open up the solution to additional scrutiny with regard to how the system handles sensitive information. By using an encrypting card reader, where the merchant has no ability to decrypt the card data locally nor within the payment environment, it’s very likely the QSA (Qualified Security Assessor) can help the merchant realize valuable scope reduction in requirements No. 3, 4, and 9. (But it is up to the auditor to determine the actual level of scope reduction.)

Very few PCI requirements are hardware-related. The only hardware that PCI certifies, per se, are so-called PCI PTS (PIN Transaction Security) or ‘SRED’ devices, which is where the Secure Reading and Exchange of Data (SRED) requirement resides.  Non-SRED devices can (and usually do) have the same encryption features as SRED devices, but the non-SRED versions do not contain the necessary tamper mechanisms required for a product to qualify for SRED. (Also note, PCI has stringent rules for manufacturers regarding secure development of software, secure upgrading of software, etc. SRED devices have to be secure from cradle to grave.) ID TECH’s encrypting devices (even those that are not ‘SRED’ devices) can technically be considered PCI compliant, because they are used in many currently certified PCI DSS solutions, but the readers themselves are not “PCI certified.” The PCI DSS certification applies to the entire solution. It is not a device-level standard.

P2PE

There is a common misconception within the payments industry regarding “P2PE” (Point to Point Encryption). Many times, when people say “P2PE,” they really mean E2EE (end-to-end encryption). When a merchant is deploying a payment system that provides hardware-level encryption of cardholder data to the POS application, which then passes the encrypted data to a (remote) payment gateway, that’s considered “end-to-end” encryption. P2PE is an official PCI certification that involves all aspects of a transaction, from the hardware used (which must be SRED), the deployment environment, data handling (which must be maintained to P2PE regulations), the payment application, and the key injection and decryption facility. Merely having a SRED device in place does not automatically make a system P2PE-compliant.

You should understand that P2PE certifications are extremely costly and rare. Most people who think they need “P2PE” really don’t. Research your needs carefully.

Have questions about PCI certification, or payment-device security? ID TECH’s technical experts are glad to help. Give us a call any time at:

Toll Free Number
1-800-984-1010

This month’s post was written by Jason Hall, ID TECH’s Product Manager for Unattended Solutions, with input from Kas Thomas.

Leave a comment

You must be logged in to post a comment.