Let us examine what Robert Carr, CEO of Heartland, possibly means by ‘end-to-end encryption’. In the Heartland press release it says, “For the past year, Carr has been a strong advocate for industry adoption of end-to-end encryption – which protects data at rest as well as data in motion – as an improved and safer standard of payments security.”
One of the keys to defining end-to-end encryption is the fact that Mr. Carr refers to it as protecting data at rest as well as when it is in motion. As a former telecommunications and networking person, ‘end-to-end’ to me means from the initial point of contact with the network to that point on the network where the transmission terminates. However, Mr. Carr is implying that he also includes the point at which the cardholder data retrieved from (i.e., the card, Smartphone, etc.) and then stored. Therefore, it is from this definition that we will work. Technically, what Mr. Carr describes seems possible. However, there are some obstacles and limitations of the technology in place today that will make this re-engineering difficult and possibly impossible, at least for the immediate future.
In order to get true end-to-end encryption requires that the credit card also be encrypted. Guess what? We have that technology today in the Chip and PIN credit card. If you remember from my post on Chip and PIN, this is not a technology without if flaws. As I pointed out in that post, the chip on the Chip and PIN card is encrypted using either DES, 3DES, RSA or SHA. Since DES is no longer considered a secure encryption method, the card brands should no longer recommend its use. The larger problem with Chip and PIN encryption is that the encryption key is a four digit number (the PIN), which does not create a very secure cipher. Essentially, we are talking about something in the neighborhood of 13-bit encryption versus the more robust 128-bit or better encryption required by the PCI DSS. As a result, regardless of the encryption method used, it is the weak key (PIN) that creates weak encryption at the card. If Mr. Carr thinks that he has part of his end-to-end solution in Chip and PIN, he needs to think again.
Then we have the encryption from the swiping device to the processor for approval or decline of the charge. Now, a number of you may be saying, what about the POS system? Hold that thought and I will discuss it in a little bit. Let us talk about stand-alone terminals that may or may not be integrated into a POS system. In order to get end-to-end encryption, the encryption must occur from the terminal that accepts the card all the way through to the ultimate storage location of the transaction. The good news here is that the terminal is typically capable of using the latest encryption algorithms, so the transmission from the terminal to the processor can be properly secured. However, the problem with encryption from the terminal to the processor is that this technology currently is an encrypted tunnel. This means that any network devices between the terminal and the processor are unable to act on the message because it is contained in an encrypted tunnel. For true stand-alone terminals, this is not a problem. For terminals integrated with a POS solution, implementation of end-to-end encryption requires a separate connection from the terminal to the POS that transmits the approval/decline code and transaction amount back to the POS. All of this is available today from some POS solutions.
However, end-to-end encryption gets trickier when it is provided as part of an integrated POS solution. This is because these solutions typically integrate the terminal with the POS hardware and software. The trickiness comes from the fact that we are relying on hardware and software to provide our security. Since most of today’s POS solutions are based on some form of Microsoft Windows, security can be haphazard at best depending on how Windows has been implemented. All that is required to compromise this solution is a piece of malware that positions itself between the reading and decryption of the credit card and the application that processes the transaction. Based on what has been published, this appears to be exactly what happened in the Hannaford breach. Therefore, the POS solution must be rigorously hardened and sufficiently monitored to ensure that it is not compromised. Alternatively, if it is compromised, an alert is generated almost immediately to notify management of the compromise so that it can be addressed as soon as possible. All of this technology exists today in the form of anti-virus, anti-malware and critical file monitoring solutions. However, additional controls may also be needed to ensure that POS solution ghost images are not tampered with (use of hashing and periodic examination of images to ensure they hash properly) and that critical file monitoring is actually monitoring the correct files.
Those of you thinking of using Kerberos had better think again in regards to end-to-end encryption. Kerberos encrypts between devices and/or applications. Therefore, Kerberos just ensures encryption from the POS application/device to the next application/device it connects, most likely, just another application/device on your own network. So the threat of malware still exists, it just may be further spread out to other devices/applications. The other problem with Kerberos is interoperability outside of your own environment, in this case with your processor. While Kerberos supports such capability, in my experience, very few organizations get Kerberos implemented properly on their own networks, let alone working properly with an outside network.
Going back to encryption between the terminal or the POS system to the processor. I brought up the fact that current network encryption solutions (IPSec, PPTP, L2TP, etc.) create a tunnel that network devices between the two endpoints do not have access. Obviously, for those of you using MPLS (aka multiprotocol label switching), this is an issue because your traffic cannot be rerouted by MPLS if it is tunneled. Supposedly, this is being addressed by an IEEE committee to develop an encrypted tunnel that only encrypts packet payloads and leaves the information necessary for MPLS to operate in clear text. When this standard will be released is anyone’s guess. But until it is, MPLS networks become a potential problem for encrypted tunnels.
As you can see, end-to-end encryption is feasible, but its true value may not be what Mr. Carr believes or has been lead to believe.
PCI Guru 
1 Response to “Is “End-To-End Encryption” Realistic? Part 2”