Is Heartland’s End-to-End Move The First Shot In A Processor Lock-In War?
Written by Evan SchumanBack in the late 80s, when I was covering the Unix area, much of the activity involved anti-competitive moves from one vendor to the next. Indeed, those folk did a lot more fighting than they did inventing or selling, which is why Microsoft never sweated Unix much.
In those days, proprietary was a bad word, suggesting a vendor ploy to lock-in IT departments to have to stick with their products because it became too expensive to switch. Open systems, packages that could theoretically work with a lot of other systems, was the better approach.
Today, you don’t hear much about open systems and proprietary is a word tossed around by vendors with barely a hint of yesteryear’s unpleasantness. Indeed, Heartland itself is describing its proposed end-to-end encryption approach as proprietary.
Is that necessarily a bad thing? As my colleague, Dave Taylor, eloquently articulates in this week’s column about the Heartland move, Heartland’s hardware-connected-with-card-reader approach will not be alone for very long. At least two other major processors are also preparing to unveil end-to-end encryption offerings.
Heartland’s approach is based on the licensed technology from several vendors—including Voltage Security—along with a healthy dose of code written by salaried Heartland programmers, said Heartland spokesperson Jason Maloni.
From the retail perspective, is this mostly good? The good part is that, without a doubt, the likely result of all of these processor moves will be much strong security. After all, that’s primarily what a processor is supposed to do: Get the transaction from point A to point B without mucking it up along the way.
A retailer generally doesn’t crave a lot of value-add from its payment processors. In the friendliest way possible, the merchant attitude is “Just do your job and stay out of my way.” But with more aggressive data breach artisans out there, retailers need the processors to do more to protect them. So from that perspective, these developments are very good news.
That all said, processors need to be profit-making businesses. Today, merchants can switch processors fairly easily. It’s a pain, of course, but it can be done. One critical net effect of these end-to-end enhancements is that it will make it much more difficult for retailers to switch processors.
“Switching out processors is something (retailers) now do on a relatively regular basis,” said Wasim Ahmad, VP/Marketing for Voltage Security. “Solutions that involve bolt-on-hardware raise those switching costs.”
To that extent, these moves could make it more difficult for retailers to negotiate the best terms after the initial contract. How much pain is a retail IT exec willing to endure to avoid a 10 percent rate hike? Or slower tech response? The harder it is to leave a supplier, the less incentive that supplier has to, well, earn its swipes every day.
There’s a broader issue, however. Any material improvement in security is likely to involve non-trivial infrastructure changes. In short, it would require changes that will make it harder to switch.
The answer to this would rest with the PCI Council, the NRF and other industry players. If standards can be worked out so that the security enhancement devices are all interoperable, that would address the question. Of course, interoperability invariably means “weaker approach.” It means that a programmer can’t necessarily craft the best thing they can because it now must be in accordance with the standard.
Heartland has been fond of saying that they are deploying these enhancements to stay one step ahead of the bad guys. The key question: Which bad guys are they thinking about? Cyber thieves or rival processors?
-Marc
May 13th, 2009 at 3:25 pm
How will this so-called ‘end to end’ encryption system solve anything? Sending card data sent to Heartland (or any other processor) is already done using SSL. Therefore, the “ends” (as Heartland defines them) are already using encrypted communications. I believe that is what Heartland calls ‘end to end encryption’.
But, when Heartland was breached, it was not a consequence of someone intercepting the SSL communications from the merchants to Heartland, it was from obtaining the unencrypted data Heartland held on their internal systems. If Heartland wants to encrypt that data now (not a bad idea!), then they should do so. But that has nothing to do with communications between them and their merchants. In other words, this fancy, new, proprietary system does nothing to address the problem that got them into this situation in the first place.
True ‘end to end’ encryption (with respect to credit cards) would involve using smartcards (the card actually being one end) and keeping the data encrypted throughout the entire process until it reaches the issuer’s authorization platform (the other actual end). This is a proven, existing system known as ‘chip and PIN’. Anything else is just lipstick on a pig.
May 14th, 2009 at 10:28 pm
Yes, this is definitely more of a “pretty-near-one-end to kind-of-the-middle” encryption scheme, but that doesn’t have the nice marketing ring of “end-to-end” to it.
One thing this does is it theoretically keeps the merchants’ IS systems free of pesky PCI data, except for several minor glitches. If the merchant has issued magnetic stripe cards for other purposes, (gift cards, house charge cards, etc.,) then they can no longer decrypt their own data. They’d likely have to pay their processor to access their own card data! And if the processor provides them with a decryption service, that’s like handing the keys back to the bad guys, several of whom have proven themselves to be capable hackers able to figure out a system like this and call the decryptor themselves.
An encryption chip near the read head doesn’t stop a skimmer, nor does it stop cloned cards, nor hand-keyed account numbers. About all it does is prevent the merchant from accidentally building an easy-to-steal stream or database of credit card numbers. For most merchants, that’s probably better than where they are right now, so this isn’t necessarily a bad thing. But this technology won’t help them at all when Chip and PIN arrives (and may in fact interfere.)
May 15th, 2009 at 5:44 pm
Smartcards have high cost, and hidden complexity and risk which is why they aren’t going to be here any time soon in the US due to the payment system scale. They are not the silver bullet. The major problem *is* that merchants today have to manage an easy to steal stream of card data, and any place where this data can be accessed is a target.
In respect to smarcards, the cost is still too high and has been for the last 20 “years of the smartcard”. Whilst they have been forced on consumers in Europe and Asia Pac and particularly in the UK, fraud levels simply shift to other attack techniques and system abuse as we have seen. The standard, EMV, is excellent though complex and has its problems too.
EMV focused mostly on the fraud reduction in Cardholder Not Present cases. Meanwhile, card fraud has taken many other twists and since the EMV technology was first put on the table in the mid 90’s and is highly complex, dynamic change is restricted by such complexity and requires complex standards change processes. Not a bad thing, just a reduction in agility which might be essential in fighting very agile criminal attackers.
Smartcard microprocessor systems themselves are also not immune to abuse, and suffer from the major issue that if the chip fails the consumer is in a bad place – can’t pay. Failure can be any one of simple or complex scenarios: contact failure or corrosion, chip failure, Power supply problems, false positive security mode invocation locking the device, eeprom or flash memory failure to due over writes, RF interference etc causing instruction mis-execution, signal noise or power variations despite on-chip conditioning, or outright tampering of the chip with rudimentary chip attackers – e.g. send a stream of invalid Cardholder Verification PINS to lock the card and force a PIN Unblock invocation as a denail of service attack, or brute for send 100V AC to +VCC, DATA, and GND and the chip has blown meaning the .
This has a dire negative impact on overall effectiveness of the scheme. These are real issues and a bit of a dirty secret in the industry.
Some of the issues include:
* massive increase in scope for PIN capture as ALL cards must have a PIN for every transaction using the chip card. PINs may unlock other functions and applications on the cards or be used as ATM PINs to permit access to MCR stripe based applications for backwards compatibility with legacy ATM’s. Some terminals have been shown to easily permit PIN sniffing at the ICC card interface or other forms of simple tampering using devices as simple as paper clips (http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-711.pdf).
* Cards using Static Authentication Data (using simpler smartcard processors to reduce costs) can be potentially copied – its harder than mag stripe for sure, but they can (ref. Ross Anderson, Cambridge University)….and…
* Static Data Authentication used in some EMV deployments – mostly UK -(the consumer will be unaware of this by the way) does nothing to prevent replay attacks – and these cases exist. So, we have a false sense of security and the consumer is at risk of increased liability because….
* there is a shift of liability to the CUSTOMER based on the false assumption that since everything is “perfectly secure” (wrong), it has to be the consumers fault. This is major and somewhat unpalatable shift. As has been shown in recent court case in the UK, there *has* been fraud in EMV enabled cards which have been copied. Those presumed secure: case “Job V Halifax, April 30th 2009 – http://www.finextra.com/community/fullblog.aspx?id=842. Ross Anderson et al have shown tampering without expensive hardware or investments is indeed possible.
* Incremental cost of the chip card, its production, plastic handling, distribution, and application development and lifecycle management vs static magnetic cards which are least cost by comparison with simple re-issuance processes.
* cost of personalization of the card per consumer. This is a data injection process. This has to be repeated upon loss, and is far more complex than simply printing processes, has to be handled in a secure facility which needs more expensive equipment (card personalization and plastic fab/chip injection lines are not cheap).
* The card itself has to trust the card accepting device, the card accepting device has to trust the card, the card has to be unlocked by the user: implying a PIN or password operations by users – again a shift from credit cards in use today in the US. This complexity increases application development costs for terminal, card accepting device and other related software which has increased QA and engineering costs, more time to bring out new applications and innovation etc.
* The Key management with EMV is incredibly complex – and this comes at a cost. Several complex PKI’s need to be managed with corresponding key injection into cards and terminals – complex and expensive and slow to change/evolve as a standard as as result to meet new requirements.
* Upgrading millions of merchant terminals and training merchants on smartcard user operations to avoid rejection, new card readers, terminal fleet management systems, software and maintenance agreement – billions of dollars in cost and a major time investment.
* If chips fail, the fallback is manual entry or magnetic track data which puts you quickly back to square one – mag stripe.
So, whilst a good tool and introduce another risk management approach, smartcards on their own are not a realistic solution in solving the problem on their own right and do not realistically address the problem at hand in the US. Just look at the number of PC’s that have smartcard interfaces doing absolutely nothing – or not even presented to an outside card interface. I do see a future for them personally – but in the next decade or two, not tomorrow. Do we want to wait whilst the criminals have a decade of R&D investment in new attacks or should something practical be done now ?
EMV will reduce fraud in some areas, – but shift it to others.
In the meantime, the risk at hand – that of abuse of cardholder data in payments streams has to be quickly reduced by effective means quickly. True End to End Encryption does seem to be the logical and practical next step as an effective means to achieve this at a very reasonable cost without massive impact.
I look forward to more discussion on this.
June 30th, 2009 at 4:14 pm
What Heartland wants to do is encrypt the data at the time of swipe. That encrypted data is formed using a “format preserving” method. At some later point, the data is decrypted and passed to the issuers/associations. The clear data is then encrypted again for storage. So, the goal is to only see clear data in your environment when you have to pass it over to the issuers/associations for approval or settlement etc.
To PCI Guy – I don’t know about Heartland’s communications with its devices, but anything over dial or frame is generally NOT encrypted. SSL is only used when a device is using IP to communicate to an auth host. Encrypting the payload is better than encrypting the transport in this case so that you protect against capture attacks at the ends of the auth process.
To Payments Expert – As far as EMV or Chip and PIN go, that’s still several years out (if it ever makes it) in the US. Mag stripes aren’t going away any time soon…unfortunately. And I agree that this isn’t really “end-to-end” but most that are implementing this type of solution are trying to extend the “end” into the processors. As far as entry point attacks (manually keyed, skimmers, cloners etc) there are solutions to protect manually keyed entries using the technology that Heartland is proposing. Combine that with one of the card auth schemes (like Magnaprint from Magtek or Warble from Semtek) and that hurts the bad guys in a big way.
There is no magic bullet for card processing security. You just need to make your attack surface smaller and smaller. We should look at these technologies as ways to reduce risk today rather than waiting for something that may never come.