End-To-End Encryption – The Rest Of The Story

Step right up folks.  I have something that will cure all of your problems with credit card processing.  It is called end-to-end encryption.  Yes, folks, it is the be all, to end all in security.  It will cure all that ails you, particularly those nasty data breaches.  Don’t be shy, just step right up and get your own version while supplies last.

Gee, when end-to-end encryption (E2EE) is put that way, it sounds great, almost too good to be true.  And you would be right; it is too good to be true.  But if you listen to the statements of the proponents of E2EE, they make it sound like once E2EE is in place, it is like the Ronco Showtime Oven, “Just set it and forget it.”

Now, do not get me wrong.  E2EE is not a bad thing, but it does have its own set of risks.  And it is those risks that do not get discussed that concern me.  The reason for my concern is that if you discuss E2EE with any merchant, most see it as this panacea, something that will get them out of the PCI compliance game altogether.  However, nothing could be further from the truth.  If anything, E2EE may make PCI compliance even more daunting than it is today.

The first thing everyone seems to forget is that E2EE only removes those systems and networks that are between the endpoints.  That is because the data stream between the endpoints is encrypted and, therefore, out of scope for PCI compliance.  However, for a merchant, that means that the device that accepts the credit card is still in-scope for PCI compliance.  Bring this fact up to most merchants and they start complaining like no tomorrow.

That device might be as “simple” as a credit card terminal or as complex as an integrated point-of-sale (POS) workstation on a network.  However, since this device is an endpoint, the merchant or the merchant’s QSA needs to ensure that the endpoint is properly secured and cannot end up being a breach point.  Depending on the complexity of that device, that assessment might be very straight forward or very time consuming.  The reason the endpoint needs to be assessed is that security is only as good as its weakest link.  In the case of E2EE, the weakest links are the endpoints at which the data is encrypted and decrypted.

The next thing that seems to slip people’s mind is that fact that since the merchant has an endpoint, that endpoint is still a target.  Worse yet, because it is an endpoint, the level of sophistication likely required to compromise that endpoint goes up exponentially, meaning that any successful attack will likely be beyond the average merchant’s capability to readily detect.  The PCI DSS addresses this threat fairly well by requiring network monitoring, daily log reviews, anti-virus, anti-malware, firewalls and the like.  However, I can tell you from personal experience that your average merchant is not going to be equipped to deal with this new threat.

And what is the new threat?  The new threat is tampered with hardware and software.  If you think this is farfetched, think again.  It has already happened on a limited scale.  The doctoring of hardware is fairly straight forward to both accomplish and to detect.  Detection only takes looking inside the device and noticing something that does not belong.  However, doctored software is another story.  The concept of doctored software has been a concern in the health care industry since the start of using computerization for heart pacemakers.  While the health care industry has developed rigorous testing and certification procedures, the rest of the software industry has said there is no need.  That is, until now.  As the world further automates, the need for reliable, safe and secure software only increases because of the reliance people and organizations apply to that software.

So what can an organization do to stem this new threat after implementing E2EE?  Here are some thoughts.

• Purchase your credit card processing equipment only from your acquiring bank or reputable vendor.  This is not a perfect solution to the problem, but doing this should be better than buying a used unit off of eBay or from Joe’s Guaranteed Card Equipment.  Yes, you may save a few bucks, but is that worth having every one of your customers that uses a credit card being compromised?  Probably not.

• Ask your supplier of terminals or POS workstations about what they do to test these systems to ensure that they operate as expected and are not routing cardholder data to Timbuktu as well as your bank.  Ask them to provide those procedures in writing and review them to ensure they appear adequate.
• Use serialized tamperproof tape on the seams and doors of your terminals and POS workstations.  Require that at every Manager shift change the new manager on duty is required to log their review of the devices, inventory the devices and notate if any have been tampered with.  If a device does appear to have been tampered with, it should be taken out of service until a new, secure device can replace it.
• If using self-checkout systems, make sure to have those systems under both video and employee monitoring.
• Upgrade your card processing devices to the latest devices.  Over the last few years, some of these devices have seen significant changes in their design that improves their tamper resistance.  This is particularly true of fuel pumps and certain types of terminals.
• Review video monitoring if any manager notates that a device may have been tampered with to determine if you can identify possible suspects that may have tampered with the device.
• Patch your devices as soon as possible to minimize their susceptibility to attack or compromise.
• If the vendor of the equipment will perform updates, make sure that you or someone in your organization schedules the updates.  If anyone shows up at a location to “update” your equipment and it was not scheduled by your organization, contact law enforcement.
• If updates will be done by the vendor remotely, make sure that someone from your organization initiates the remote access and they observe the remote update process.  At the end of the update process, the person should terminate the remote session of the vendor.

Even implementing these processes will not remove all of the risk.  Particularly the risk of having modified software introduced into your environment.  However, these processes will show a court that you attempted to conduct due diligence and tried to keep your equipment secure.

Advertisement

Is “End-To-End Encryption” Realistic? Part 3

Hopefully by this point I have pointed out that encryption, end-to-end or otherwise, is not a silver bullet.  It is just another tool to minimize the risk of data loss.  But why has it become the topic du jour?  That is what I hope to examine in this post.

There is the issue of end-to-end encryption even being feasible.  As I pointed out in my last post, while it is feasible, it may not be as secure as Mr. Carr and others desire.  In some cases, it may not be able to be implemented considering the technology used by all merchants.  Merchants live on very thin margins, even Target and Wal-Mart.  So the investment required to make changes may put some merchants out of business.  In today’s economic climate, the loss of jobs will far outweigh the monetary losses.  Until the economy picks up, merchants will likely fight to minimize any expenses to make changes to their systems and networks.

Speaking of monetary losses.  Based on the latest statistics I could find, 7.5% of Americans (almost 23 million people) have suffered from financial fraud.  While that is a fairly large number of people impacted, the total monetary losses to fraud versus total credit card charges are still well below 1%.  Until that percentage gets higher, we will likely see the card brands and merchants to accept this loss as the cost of doing business.

The fact that the US House of Representatives looked at this issue in the Committee on Homeland Security speaks volumes.  There is an assumption that this is the case since the bulk of fraud is now committed by criminal organizations.  I do not discount the possibility that some of these fraud moneys likely flows to terrorists, but the amount is likely so small that it is inconsequential.  Then there is the fact that Internet access in known terrorist countries and the number of attacks coming from those countries just does not support the conclusion that fraud funds terrorism.  Granted, a lot of attacks and fraud are conducted by surrogates on behalf of others.  However, based on everything I have read, there has been no correlation between the attackers and terrorists.  Until this can be correlated, this is just a smoke screen in my book.

In her statement during the House hearings, Representative Yvette Clark (D-NY) held out Chip and PIN as one of the keys to securing credit card transactions.  As I pointed out in my Chip and PIN post, this technology is not a silver bullet.  In fact, it has its own security issues, the largest being that the encryption it offers is weak at best.

Unfortunately, I think this issue is being discussed because the people discussing it believe that encryption solves the data breach problem.  If properly implemented, encryption will reduce the risk of successful data breaches, but it will not entirely get rid of them.  It will just make them more difficult to execute.  After all, banks and art museums still are robbed even with all of the security measures they have implemented.  What makes anyone think that data breaches will stop because of encryption?  That is the point, it will not.  Data breaches will continue to occur with or without encryption.  It is how successful those breaches are that will change.

Is “End-To-End Encryption” Realistic? Part 2

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.

Final post on end-to-end encryption.

Is “End-To-End Encryption” Realistic? Part 1

A January 26 Digital Transactions News article discusses Robert Carr’s call for end-to-end encryption.  The Heartland press release that drove all of the media stories around that time states that, “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. While he believes this technology does not wholly exist on any payments platform today, Heartland has been working to develop this solution and is more committed than ever to deploying it as quickly as possible.”  Mr. Carr’s call for encryption appears to have been unknown to the public as the earliest reference of encryption a Google search could uncover was in Heartland’s 2008 annual report.  Given Heartland’s fiscal year ends on December 31, it is likely the statement on encryption in the annual report was written about the same time as the press release.

In response to Mr. Carr’s call for end-to-end encryption, Kevin Nixon argues in a March 24 article that end-to-end encryption is “bad medicine.”  So, what is meant by end-to-end encryption, the “one brief point” where cardholder data is exposed and why is this discussion creating such a stir?

In this post, I would like to discuss the “one brief point” comment.  Based on my experience with credit card processing, depending on where you are in the process, there can be more than just one “brief point.”  In fact, “brief“ may also be a misnomer.  Depending on the process, there could be numerous points where cardholder data is exposed.

Let us look at this from the merchant’s perspective.  For merchants using dial-up terminals, there is truly only one potential “brief point” of exposure between the terminal and the connection with the processor.  However, this exposure requires that the dial-up line be wire tapped and the electronic transmissions be recorded.  Given that a merchant with dial-up does not have a high volume of credit card transactions and that wire-tapping is a very serious federal felony, the risk of this occurring is low as the payback is also very low.

For merchants that use integrated POS, the first exposure point that can exist is between the credit card terminal and the POS solution.  This point exists because of the multitude of terminals that could possibly be connected to the POS.  Since POS vendors do not always have the resources to develop interfaces for every possible combination of credit card terminals, they develop interfaces to the most popular terminals following the 80/20 rule.  This compatibility issue has gotten less and less of a problem over the years as the terminal vendors adopted USB and other standard connectivity solutions to connect the terminals to the POS.  However, most POS vendors have made the wrong assumption that the connection between the terminal and the POS is secure which may or may not be true.

Then there is the connection between the integrated POS and the processor.  For large merchants that perform their own transaction switching, the connection between the POS and the internal switch can sometimes be unencrypted and that can be another point of exposure.  Interestingly enough, the connection between the merchant and the processor can also be an exposure point.  I cannot tell you the number of large processors that even up to a year ago were still struggling with getting connections to merchants encrypted.  And if a merchant’s connection to their processor is a private circuit, it is likely not encrypted because the PCI DSS does not require it.

Another exposure point is settlement.  While settlement is usually conducted over private circuits, it is typically done using FTP to transfer files between the merchant and the processor.  Some processors have moved to transferring settlement files via secure FTP, but have not necessarily moved all of their merchants to secure FTP.  As a result, there is potential risk in the fact that standard FTP is used during the settlement process.

These are just the obvious risks to cardholder data security.  Based on all of the custom solutions implemented by merchants and processors, there are unique risks present throughout the cardholder data flow.  As a result, each instance presents its own unique challenges to provide adequate security.  This is why securing cardholder data can be daunting.

In my next post, I will examine the definition of ‘end-to-end encryption’.