For the last time, there are no single ‘silver bullet’ solutions to perfectly securing cardholder data and their related transaction flows. As my blog shows, I get comments from all sorts of people saying otherwise. However, whether you are talking about Chip and PIN, end-to-end encryption, data encryption or tokenization, none of these technologies offer the complete solution to stopping credit card fraud.
Chip and PIN
Chip and PIN was developed to address the problem of face-to-face transaction fraud. It does not solve the problem of cardholder data being breached in back office systems where most breaches take place. The attackers know that somewhere in the transaction flow process, someone has to have the cardholder data. Chip and PIN does not address the back office and never will. It is not that Chip and PIN is a bad idea, it is the fact that implementing Chip and PIN does not, in and of itself, solve the issues faced with breaches.
End-To-End Encryption
End-to-end encryption requires that each end uses the same encryption process. So the first problem is that each acquiring bank or service provider will likely have their own particular implementation of end-to-end encryption meaning that interoperability will not exist. So those merchants with multiple processors will likely have problems with end-to-end encryption unless they use separate systems. However, that is minor compared to the next issue. The other problem is that there are a lot of ISOs and service providers in the transaction flow that require access to the transaction making end-to-end encryption not quite as easy as one might think. However, the biggest problem with end-to-end encryption is that it only protects the cardholder data from one endpoint to the other endpoint. It does nothing about protecting the endpoints themselves or the environment outside of the endpoints. As a result, the endpoints and the environments outside the endpoints become the targets. While the endpoint at the processor or acquiring bank is likely fairly well protected, the endpoint at the merchant is probably the weak link and therefore the merchant is still the target. The most likely target here is doctoring the card terminals or POS software so that the attacker can gain access to the cardholder data before it hits the encryption process. End-to-end encryption does nothing to prevent the tampering of the endpoints. As with Chip and PIN, end-to-end encryption only addresses a part of the problem.
Data Encryption
Data encryption is great for protecting the data when it is stored as well as when it is in transit. However, unlike end-to-end encryption, under data encryption when data is in transit there are multiple points where the data is decrypted and encrypted as it moves through the authorization and payment processes. Any one of these points could be compromised and the data encryption defeated. Cardholder data that is stored encrypted still has the threat of being compromised either at the point it is encrypted or if the encryption key be compromised. If data is only encrypted during transmission or if it is only encrypted when stored, the data is susceptible to compromise wherever it is not protected. As with end-to-end encryption, data encryption can solve a portion of the problem, but not the entire problem.
Tokenization
Tokenization is the act of creating a value, the ‘token’, and using the token as a way to reference the actual cardholder data. Tokenization is great for merchants because it allows them to keep their old systems running unmodified by having the system believe it is getting back the PAN when in fact it is just a token. However, the cardholder data still has to be transmitted in order for a token to be generated, so the merchant is still not out of scope. Worse yet, if the transmission is not protected, then the data stream is susceptible to compromise. As with all of our other solutions, tokenization is also not a complete solution.
The bottom line is that none of these technologies individually is the answer to our security issues with cardholder data. However, if they are used together, they can provide a formidable defense against compromise. But why is that? As with all good security solutions, it involves defense in depth. Since there is no single, ‘silver bullet’ that can solve the problem, we have to look at multiple solutions that, when put together, create a defense in depth approach to provide as much security as possible.
By using Chip and PIN in conjunction with end-to-end encryption, data encryption and tokenization, we create a gauntlet of protection. However, as I always like to remind people, security is not perfect and even this solution is not a ‘silver bullet’. There are controls and monitoring required ensuring that endpoints remain secure, encryption keys are protected and that endpoints are not tampered with. However, such an approach would go a long way to minimizing the threat of compromises.
PCI Guru 
EMV: “It does not solve the problem of cardholder data being breached in back office systems”
Yes it does for Chip & PIN data. The data is rendered useless in EMV transactions. Get hold of the EMV data from the backend and what can you do?
1. Replay the chip & PIN transaction? No, it’s protected by the cryptogram.
2. Create a clone chip & PIN card? No, you don’t have all the card data (or the crypto keys).
3. Order something over the web? No, you don’t have the CVV2.
4. Create a mag stripe clone? No, you don’t have the CVV.
So, not a problem for Chip & PIN, then.
The problem is accepting legacy payment transactions, i.e. those based on the real mag stripe data (technical fallback) or the embossed card data (CNP transactions). The fact that those legacy data get compromised in EMV Land strengthens the case for ridding the world of magstripe (and zip-zap machines).
It is better to make the data useless than to protect it. That’s how chip & PIN works. It’s how contactless and mobile payments work. You can have my data, I don’t care – or is that a bit too 21st century?
So then where do my European clients keep getting the PANs that they are storing in their back office systems if that cannot be happening with an EMV card? It isn’t magically appearing in their systems. It shows up because they are functioning as their own transaction switch so they are decrypting the cryptogram in order to determine which processor or card brand to send the transaction for approval. I would agree with your conclusions if we were talking about a small business that does not aggregate transactions. But not everyone is a “Mom & Pop” operation. But even ignoring the small business aspect, the point here is that at some point the cryptogram must be decrypted and it is at that point the clear text can be done with as the applications at that endpoint decide. It is ignoring the full data flow that gets people in trouble because they forget that at some point the data must be acted upon and that can only occur if it is decrypted. It is at the decryption point where the risk of compromise shoots up and there must be extreme security measures in place to ensure that the now clear text data is properly protected.
I think you misunderstand.
Let’s just say the PAN is in clear as is the rest of the EMV transaction data. The cryptogram is just a part of that data and is merely the device used by the issuer to verify that the transaction is genuine – it is not and cannot be decrypted or verified by the merchant.
So, just to re-iterate, the EMV payment transaction data is not encrypted because it doesn’t need to be for the reasons I mentioned in my post. It’s in the clear, but we don’t care.
I guess it might be a problem for a merchant prepared to accept a payment based on PAN and Expiry without CVV, CVV2, etc., but then the merchant knows that and fully accepts the associated risk.
I can see how EMV would significantly reduce fraud for the card-present transactions. However, how does it raise security on card-not-present? The consumer still manually enter’s their account information just as they do with magstripe cards. So I would think while it may decrease card-present fraud, the card-not-present fraud would significantly increase. EMV by itself may solve one part of the issue – but not the whole issue. That’s where security and the PCI DSS come in…
Sorry. I forget that not everyone reads all of the posts and I should have put in a reference to the other post on EMV. If the banks, Web sites and developers all developed a common API for using EMV cards online, then online transactions would benefit from the same security provided in face-to-face transactions.
I have read the past posts 🙂 But it was not my understanding that the banks, Web sites, and developers have that currently in place. Do they and I just missed that?
I’m not saying it’s not possible for EMV to provide more security in both – but that at this time, while it does add security to card-present the same is not true for card-not-present (unless I’m misunderstanding how it’s currently in use). They are less prone to fraud in the physical world because of their authentication process, but that doesn’t pass onto card-not-present currently since they still type the info into the web site (or provide it on the phone or through mail). Aite Group estimates that EMV would elimate 30% of card fraud, 90% due to counterfeiting and 95% due to lost/stolen cards. It is currently said that it does nothing to increase security for card-not-present.
I am not aware of any collaboration between the banks, merchants, Web sites and developers to create a standard protocol that would interface between an EMV card and reader attached to a consumer’s PC and the merchant Web site. It’s not like the necessary hardware does not exist, it’s just that there is no software in place to make it work. And in order to be effective, there needs to be a standard API created so that no matter what Web site is accessed, the EMV transaction can be processed.
Barclay’s and a few other banks tried in the early part of the century with their own individual proprietary standards, but none of those caught on. After a while, each bank dropped their EMV online transaction efforts.
Without a single standard, leveraging EMV to secure online transactions is not feasible.
The “issuers are required to maintain the track data” is, I think, a little misleading. They are specifically NOT allowed to store things like the Card Security Code (CVV / CVC and so on), which is the one bit of data that couldn’t be guessed reasonably easily. These are card scheme rules, and have existed as long as the CSC. This means that the CSC is NEVER stored in the card file; it is calculated in real time (hopefully in an HSM) as and when it is needed during the authorisation process.
Track data, if you like, is therefore never stored, and as it is never stored, it cannot ever be considered vulnerable. The crim cannot hack into an issuing bank and pick up the “track data” simply because it isn’t there. Why are we trying to protect data that doesn’t actually exist?
I need to add – even if they *do* mandate – as they clarified in 2.0 – it will make no business sense to the network. Networks rely on big issuers for transaction volume so they can be profitable. Threatening an issuer of consequences because they didn’t protect their data according to a 3rd person/entity’s requirements is downright nonsensical. The issuers are bearing the risk. It is *their* data. They have to deal with the ramifications if cardholder data is breached. The last thing they need is a network to come and tell them that they are doing something wrong in the way they are protecting their data.
I’m sorry – but when you say Chip-and-PIN doesn’t solve the problem of cardholder data being breached because of back office fraud, it may be nice to highlight that neither does PCI. At least till they begin to mandate issuers to be compliant – and they can’t really do that can they? 🙂
Issuers are required to maintain the track data, otherwise they would not be an issuer. Therefore, they will always be at risk and required to do more to protect that information. This is the same with acquiring banks. In the end, the data has to exist somewhere in the system. And where that somewhere is, the cardholder data must be protected.
The “issuers are required to maintain the track data” is, I think, a little misleading. They are specifically NOT allowed to store things like the Card Security Code (CVV / CVC and so on), which is the one bit of data that couldn’t be guessed reasonably easily. These are card scheme rules, and have existed as long as the CSC. This means that the CSC is NEVER stored in the card file; it is calculated in real time (hopefully in an HSM) as and when it is needed during the authorisation process.
Track data, if you like, is therefore never stored, and as it is never stored, it cannot ever be considered vulnerable. The crim cannot hack into an issuing bank and pick up the “track data” simply because it isn’t there. Why are we trying to protect data that doesn’t actually exist?