Comments on: There Are No ‘Silver Bullets’

By: The Harsh Reality Of Security « PCI Guru

The Harsh Reality Of Security « PCI Guru — Wed, 22 Dec 2010 16:47:10 +0000

[...] include tokenization, end-to-end encryption (E2EE) and Chip & PIN (EMV). I recently posted a blog entry on all of these technologies, so I will not go into all of these here. The bottom line on all of [...]

By: PCIGuru

PCIGuru — Tue, 23 Nov 2010 17:50:33 +0000

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.

By: T. Anne

T. Anne — Mon, 22 Nov 2010 20:35:53 +0000

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.

By: PCIGuru

PCIGuru — Sun, 21 Nov 2010 20:55:46 +0000

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.

By: T. Anne

T. Anne — Thu, 18 Nov 2010 18:27:07 +0000

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…

By: Richard Allen

Richard Allen — Thu, 18 Nov 2010 12:21:24 +0000

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.

By: PCIGuru

PCIGuru — Wed, 17 Nov 2010 23:25:31 +0000

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.

By: Richard Allen

Richard Allen — Wed, 17 Nov 2010 12:41:27 +0000

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?

By: David Griffiths

David Griffiths — Tue, 16 Nov 2010 16:02:59 +0000

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?

By: David Griffiths

David Griffiths — Tue, 16 Nov 2010 16:02:03 +0000