Is P2P Encryption Secure? That Depends...
In the wake of the highly publicized payment card security breaches of the past few years, point-to-point encryption (P2PE) has emerged as a frontrunner in the search for a stronger defense against data compromise. The technology is also being touted as a solution to limit the scope -- and therefore the expense -- of complying with the Payment Card Industry Data Security Standard (PCI DSS).
Yet the ability of P2PE to improve security as well as reduce PCI scope is entirely dependent on the implementation. Both the encryption points selected and the encryption methodologies used will have a direct effect on how well cardholder data is protected between the time it leaves the payment terminal and arrives at its destination.
What should also be remembered is that P2PE does not encrypt payment data "end to end" from the point-of-sale terminal all the way to the issuing banks. While true end-to-end encryption would guarantee safe data passage through the entire transaction cycle, implementation in the U.S. is not currently possible given the challenges of bringing the country's nearly 7 million merchants, more than a dozen major third-party processors, several hundred gateways, several thousand ISOs and over 100 acquirers on board.
Given those limitations, P2PE steers a middle course by shortening the required encryption chain from the payment terminal to the processor, gateway or acquiring bank. The precise strategy adopted by individual merchants will determine how vulnerable their data is to pilfering.
Least Secure: Encrypt at the Cash Register
Today, card data typically travels in clear text from the mag stripe reader over the merchant's network before being encrypted at a back-office server or, in the case of smaller merchants, transmitted to the processor as an SSL message. Either scenario leaves a lag time when unencrypted data is up for grabs. Some of the biggest breaches have involved hackers taking advantage of this time window by sniffing wireless networks from parking lots to capture not-yet-encrypted transaction data.
To plug this security hole, the most basic P2PE option is to encrypt the data at the point-of-sale computer/cash register as soon as it leaves the mag stripe reader. The merit of this method is that it reduces the interval before encryption and renders the data indecipherable even in the event of a successful hack.
The problem with this approach is twofold. First, computers are more vulnerable to attack than hardware payment terminals. Second, the cryptographic key must be installed on the computer if encryption is to occur there. If the merchant has used symmetric encryption in which the same key both encrypts and decrypts the data, a determined hacker who succeeds in reaching the point-of-sale computer itself may be able to gain access to data before it is encrypted or to the decryption key if key management processes are weak.
In that case, encryption at the register is only slightly more secure than current strategies. The only difference is that the hacker will need to get deeper into the merchant's network to harvest the information.
More Secure: Use Asymmetric Encryption
Encryption can be more safely performed at the cash register by utilizing asymmetric encryption, with one key encrypting data at the merchant site and another decrypting it at the processor, acquirer or bank. This adds another layer of protection, much like the two-key system used to open a bank safety deposit box. If a hacker intercepts the encrypted data, he can do nothing with it because it is unreadable. Hence, better P2PE security.
On the other hand, all the usual concerns about antivirus protection and other computer security controls remain. And because the computer has received unencrypted data including the primary account number (PAN), cardholder name and expiration date, it is not exempt from a PCI DSS audit.
Therefore, unless the PCI Security Standards Council rules otherwise when it issues detailed P2PE validation guidelines later this year, neither symmetric nor asymmetric encryption at the point-of-sale computer/cash register can reduce the testing that must be done to validate a merchant's PCI DSS compliance. That means that neither approach will help merchants attempting to trim their PCI program budgets.
Most Secure: Encrypt in the Card Swipe Hardware
The final P2PE option is to replace existing payment terminals with newer hardware devices offering built-in encryption capabilities. With encryption at the read head, all mag stripe data is encrypted on the hardware terminal itself as soon as the consumer swipes his or her card. No readable data ever leaves the unit, eliminating the risk of theft as it traverses the merchant network.
This strategy completely defuses the threat of online attacks. Physical possession of the terminal would be required to hack into it, and even then at great effort involving dismantling the unit and manually manipulating the encryption chip. Merchants can have no greater security in a point-to-point encryption implementation.
In addition, from a PCI DSS perspective, having encryption hard-wired into the hardware helps narrow the audit scope by removing the POS cash register from the list of system components that must be evaluated. Attention must be turned instead to the payment terminal itself, with auditors evaluating cryptographic key management issues such as how the key is loaded onto the hardware device and provisions for ensuring that each device has a different key.
However, this is a far simpler and less expensive process for the merchant, both for the PCI DSS audit itself and for the maintenance required to ensure continuing compliance with PCI DSS requirements between audits. When the PCI Security Standards Council issues its expected guidance on evaluating P2PE deployments later this year, this will be a promising option for merchants seeking to simplify their PCI DSS compliance efforts.