“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?”
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.