The Green Sheet Online Edition
May 25, 2009 • Issue 09:05:02
Diverse perspectives on end-to-end encryption
Issues pertaining to data security have received unprecedented attention in recent years, fueled partly by high-profile breaches at businesses like TJX Companies Inc., Hannaford Bros. Co., Heartland Payment Systems Inc. and RBS Worldpay Inc. Featured prominently in the discussion is end-to-end encryption.
"There are different takes on it," said Robert O. Carr, Chief Executive Officer of payment processor Heartland. "There are a lot of smart people in the industry and in the security world - each of them has their own understanding of what end-to-end encryption is."
Theoretically, end-to-end encryption is exactly what it sounds like: the uninterrupted encryption of bankcard data, from the moment it enters the POS domain - such as through an on-site "swipe" card reader or Internet payment platform - to its final destination with the card issuer (and, in between, the gateway and processor).
Yet, the concept of end-to-end data encryption has become difficult to pin down, as the practice continues to evolve and be redefined. And while blanket encryption of a payment network might well be the closest thing to being a foolproof defense, most agree that implementing a completely encrypted security system is neither practical nor realistic.
Among other things, it would involve huge costs and a complicated overhaul of systems up and down existing payment chains.
"When you start talking about end-to-end encryption, it's somewhat of a misnomer, because 'end-to-end' suggests the cardholder data would never be in the clear," said Andy Deignan, Business Unit Manager for information technology security company MagTek Inc.
Most industry veterans agree certain things should, and can, be done to improve industry methods for encrypting data. And while opinions vary about precisely what to target, there is a prevailing sense that the most feasible solution is to home in on at least one of several glaring vulnerabilities.
Industry insiders interviewed for this article touched on a range of potential and proven flaws within existing networks. Among them, three basic points of vulnerability continually surfaced:
- The lack of encryption within private networks
- The decryption of data at points of transfer between institutions
- Inadequate or lack of encryption at the POS
None of these flaws is present in every network. Where weaknesses do exist, it is generally thought that even unencrypted data is safe when the Payment Card Industry (PCI) Data Security Standard (DSS) is strictly followed. Insiders say the problem is the challenge of PCI compliance. And where compliance is a struggle, other solutions are sometimes in order.
The first vulnerability within conventional payment chains is private networks, many of which reportedly don't use encryption. That dynamic is at least partly a function of the PCI DSS, which mandates that data be encrypted when passing through public networks, but not private ones.
Thus, data moving between institutions (merchant to processor, processor to issuer) are virtually always encrypted, but data moving within the private networks of each entity frequently are not.
"Very sophisticated malware is now sniffing some of that data as it traverses even internal networks in plain text," said Michael Petitti, Chief Marketing Officer at data security firm Trustwave. "That typically has been something of an unsuspected opportunity for a hacker.
"And now that we've learned better, you're seeing solutions that say not only should data be encrypted in traversing between networks, it probably should be encrypted when it's at those parties as well."
The payment chain's second major vulnerability is transfer points, where receiving parties decrypt data to make it readable. Because card data-handling institutions typically have different encryption keys, data that is encrypted by one party must be decrypted by the next recipient and then re-encrypted for processing. Eventually the data is sent out to the next destination, where the process starts anew.
A receiver on the supply chain "encrypts the data as it moves from point A to point B, but the system at point B needs to know something about that data to do something with it - so it decrypts it and then encrypts it again," said Jeff Wakefield, Vice President of Marketing at VeriFone. "As long as you're doing that, there are vulnerabilities in your system."
Wakefield said he considered what he called "the encryption, decryption, re-encryption cycle" to be the most vulnerable link in payment networks generally, adding that about 70 percent of data breaches are perpetrated by installing malware into decrypted data. But for institutions that want to limit the frequency of decryption, there are alternative systems.
One option, known as tokenization, is simply the use of a single, common encryption key by different parties up and down networks. It is considered by many to be a relatively uncomplicated way to avoid decrypting data when it's transferred, since each handler is privy to the original encryption formula.
Concerns about tokenization usually center on resting the security of an entire data supply chain on a single cache of information, which - if it is somehow accessed by an outsider - could spell total disaster.
"There's merit to [tokenization], but at some point, somewhere - whether it be at the payment processor or entity that supplies the tokens - that data is still assigned a value and ... that value can be decoded," Petitti said. "The risk is more focused on a particular entity, as opposed to spread out among various entities. And you're reliant upon a single entity, that entity has to be hardened and secured beyond all potential doubt."
Wakefield was critical of tokenization - which he said relied on uniformity, while effective encryption used variation. He said good encryption goes beyond "data base level encryption" by encrypting cards individually (he noted that the hackers who breached national clothing retailer TJX in 2006 exploited database-level encryption to steal millions of card numbers).
The third vulnerable area is where data enters the payment system - at brick-and-mortar shops, through a card reader. The problem is that encryption often doesn't begin until card data reaches the POS terminal, to which it travels via router from the card reader - a short distance, to be sure, but nevertheless vulnerable.
"If [data] is in the clear, it's able to be compromised," Deignan said. "I don't care if it's in the clear for a millisecond, if it's in the clear it's in the clear."
Data entering the POS network unencrypted can be intercepted either by a hardware skimming device slipped onto the card reader or by remotely operated malware - also known as "sniffers" which are essentially bugs planted by computer hackers that roam a network in search of exposed data.
Card readers are a crucial danger zone. Statistically, data breaches occur much more often in the merchant arena than in any other part of networks - a trend in which, it is safe to say, readers that lack encryption play no small part.
"A tremendous volume of breaches are happening at the merchant level - most of the breaches," said James McKenzie, President and CEO of Network Merchants Inc., a company that builds e-commerce payment gateways.
The current, most common remedy to the problem is an encrypted reader housed inside a Tamper Resistant Security Module, which provides physical protection. For merchants unwilling to swap out older, security-weak card readers, they can instead connect them to encryption programs on their central processing units - a practice security experts say is at least safer than the absence of encryption on the readers altogether.
But it's not as robust a solution as getting new card readers with state-of-the-art encryption built in, Deignan noted. Since encryption via hook-up involves a slight delay, "the data is still in the clear until it's encrypted," he said.
The vulnerability of card readers has its virtual counterpart in the online platforms where e-commerce transactions take place. Within this environment, there are several problem areas. Hackers generally can steal data in two ways.
The first is the use of a "key logger," a device that records a computer's keystrokes. The other is interception of credit card data within a network, which experts say isn't especially difficult to do.
To address the issue of key logging, Carr said industry leaders are considering the use of "touch screens," where purchases would be made by punching numbers on a computer monitor, rather than typing them in.
Another development is the use of individual card readers - which some industry leaders say could revolutionize card-not-present transactions by transforming them into ones where cards are, in fact, present.
The readers connect to PCs or Internet-based phones, and consumers swipe their cards as they would at conventional merchant locations rather than enter all their data manually.
"[MagTek] has designed readers that can interface with smart phones and with any PC, but they're small enough ... that consumers can now use them and conduct card-present transactions," Deignan said. MagTek is among the first companies to roll out the product.
"You might be conducting a transaction where the card is not present, but it's not because you don't have the card; it's because you don't have the POS terminal," Deignan added.
Yet, others say that, while fortifying online POS platforms is an important step, it doesn't address the more pressing issue of security within merchant locations. Even if consumer-merchant interfaces are secured, the data passing through remains in the hands of those who tend to have little security expertise.
"As a fraudster, do I want to collect individual data off each card entry, or do I want to go to a higher level and collect more data?" McKenzie said. "Most breaches that are happening are happening at a higher level than the card level, they're happening at the next level, which is the merchant level."
McKenzie suggested that rather than try to fix the way merchants handle security, why not simply bypass merchants altogether?
"Typically [e-commerce] data is sent to the merchant encrypted with the SSL [secure socket layer] certificate and then that data is decrypted, and bam - that's where the exposure happens," he said.
McKenzie's solution, which Network Merchants employs, is to use a security-savvy third party to receive and decrypt payment data, which then "sends the merchant a token representing the encrypted data, but the data remains encrypted."
Wakefield agreed that by removing merchants from processing chains - in both brick-and-mortar and e-commerce environments - the industry's most significant vulnerability would be removed.
"We think the only answer to truly securing this system is to eliminate usable data from retail systems," he said.
"Yes, they want to take card payments, but they really don't want card data. ... If we could encrypt that data in every retail enterprise, then the only place it needs to exist unencrypted is with the acquirers, processors and banks. And you know what? They kind of are in the security business."
Rather than striving to secure points within the existing framework, removing merchants from the equation merely eliminates one of the end points and redefines the chain.
Another example of an unconventional solution is one that would essentially reduce end-to-end encryption to a specific point on the encryption chain - yet would also expand the theoretical end-to-end parameters by redefining one of those endpoints.
According to Deignan, MagTek is testing such an application. MagnaPrint uses a credit card's magnetic stripe as an identifier at the point of swipe - "the fingerprint of the magnetic stripe."
"Because the mag stripe is so ubiquitous, because you don't have to reissue cards to begin taking advantage of it, because you have it in your pocket right now - it's just that not everyone is using this info," he said.
"We're saying to the payment world that we can provide you with an ultra-secure mag stripe card with no additional cost to the card. The issuance process remains effectively unchanged - [the stripe] is already there."
Within every stripe is a unique pattern of iron particles, he said. MagTek's aim is to install new technology inside card readers that would verify a card by comparing its stripe pattern to one stored on the issuer's database - thereby redefining the scope of end-to-end encryption by encoding, before the card is ever used at the POS, what Deignan called "dynamic" card information.
In a sense, the data is already functionally encrypted before it leaves the card; if it's stolen, it can't be used again. Or, as Deignan put it, "If I steal a transaction, I don't have the ability to determine what a future transaction would look like."
"End-to-end only solves one problem: It helps protect the data while it is at rest or in motion," Deignan said. "However, if I introduce a fraudulently copied card into this infrastructure, what is the system doing to stop its use? With data breaches, their intent is to steal data because data is good for future transactions."
In other words, the data is "static," he said. The information on the mag stripe, such as the card number and the expiration date, is the same from one transaction to the next. But by making that data dynamic, "the data sitting in the database is useless for future transactions ... it was only good for that one point in time," he said.
However, Deignan conceded that the use of dynamic data would do little to prevent fraud within card-not-present transactions like online and phone payments where only the card's numerical data is used and not the stripe. Securing that end would also require the use of individual card readers. But getting consumers to adopt that technology on a wide scale could be difficult.
Indeed, the immediate, wide-scale adoption of any new encryption method would likely only be triggered by changes in the PCI DSS to make end-to-end encryption mandatory.
The PCI DSS mandates the use of defenses like firewalls and segmentation (complete separation of a single network or database) whenever information isn't encrypted. Bob Russo, General Manager, PCI Security Standards Council, pointed out that "encryption, in some form, is essentially part of many PCI DSS requirements."
Russo also said far-reaching changes to the current system are unlikely.
"Participating organization feedback to the council indicates many are not in favor of end-to-end encryption, as it is a hugely expensive undertaking that in itself does not guarantee defense against data theft, and in many cases slows transaction speed for merchants who work hard to maintain it for customers," Russo said.
He added that "we will continue to advocate for the PCI standards as an organization's best line of defense against data compromise."
But while many support Russo's position, others contend that PCI requirements might make a very good standard, but they are not always easy to adhere to.
"In theory [PCI regulations] are all doable - in practice, it's practically impossible," Wakefield said. He added, however, that any solution - including the use of more encryption - would involve a complicated and piecemeal process.
"Retail systems have been put in place over 20, 30 years," Wakefield said. "People have applications they installed in the 80's that are still running, and POS systems they purchased a decade ago. Those systems weren't designed understanding today's criminal ... I'm trying to go back to those things and say, 'Ok, let me make this secure.' It would be like saying, I want to turn a resort into a high security prison. It's not easy to do."
Can institutions generally be relied on to implement the PCI DSS? And if not, is some form of end-to-end encryption necessary to secure payments? Therein lies the rub.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.