Chip-based credit and debit cards are designed to make it infeasible for skimming devices or malware to clone your card when you pay for something by dipping the chip instead of swiping the stripe. But a recent series of malware attacks on U.S.-based merchants suggest thieves are exploiting weaknesses in how certain financial institutions have implemented the technology to sidestep key chip card security features and effectively create usable, counterfeit cards.
A chip-based credit card. Image: Wikipedia.
Traditional payment cards encode cardholder account data in plain text on a magnetic stripe, which can be read and recorded by skimming devices or malicious software surreptitiously installed in payment terminals. That data can then be encoded onto anything else with a magnetic stripe and used to place fraudulent transactions.
Newer, chip-based cards employ a technology known as EMV that encrypts the account data stored in the chip. The technology causes a unique encryption key — referred to as a token or “cryptogram” — to be generated each time the chip card interacts with a chip-capable payment terminal.
Virtually all chip-based cards still have much of the same data that’s stored in the chip encoded on a magnetic stripe on the back of the card. This is largely for reasons of backward compatibility since many merchants — particularly those in the United States — still have not fully implemented chip card readers. This dual functionality also allows cardholders to swipe the stripe if for some reason the card’s chip or a merchant’s EMV-enabled terminal has malfunctioned.
But there are important differences between the cardholder data stored on EMV chips versus magnetic stripes. One of those is a component in the chip known as an integrated circuit card verification value or “iCVV” for short — also known as a “dynamic CVV.”
The iCVV differs from the card verification value (CVV) stored on the physical magnetic stripe, and protects against the copying of magnetic-stripe data from the chip and the use of that data to create counterfeit magnetic stripe cards. Both the iCVV and CVV values are unrelated to the three-digit security code that is visibly printed on the back of a card, which is used mainly for e-commerce transactions or for card verification over the phone.
The appeal of the EMV approach is that even if a skimmer or malware manages to intercept the transaction information when a chip card is dipped, the data is only valid for that one transaction and should not allow thieves to conduct fraudulent payments with it going forward.
However, for EMV’s security protections to work, the back-end systems deployed by card-issuing financial institutions are supposed to check that when a chip card is dipped into a chip reader, only the iCVV is presented; and conversely, that only the CVV is presented when the card is swiped. If somehow these do not align for a given transaction type, the financial institution is supposed to decline the transaction.
The trouble is that not all financial institutions have properly set up their systems this way. Unsurprisingly, thieves have known about this weakness for years. In 2017, I wrote about the increasing prevalence of “shimmers,” high-tech card skimming devices made to intercept data from chip card transactions.
A close-up of a shimmer found on a Canadian ATM. Source: RCMP.
More recently, researchers at Cyber R&D Labs published a paper detailing how they tested 11 chip card implementations from 10 different banks in Europe and the U.S. The researchers found they could harvest data from four of them and create cloned magnetic stripe cards that were successfully used to place transactions.
There are now strong indications the same method detailed by Cyber R&D Labs is being used by point-of-sale (POS) malware to capture EMV transaction data that can then be resold and used to fabricate magnetic stripe copies of chip-based cards.
Earlier this month, the world’s largest payment card network Visa released a security alert regarding a recent merchant compromise in which known POS malware families were apparently modified to target EMV chip-enabled POS terminals.
“The implementation of secure acceptance technology, such as EMV® Chip, significantly reduced the usability of the payment account data by threat actors as the available data only included personal account number (PAN), integrated circuit card verification value (iCVV) and expiration date,” Visa wrote. “Thus, provided iCVV is validated properly, the risk of counterfeit fraud was minimal. Additionally, many of the merchant locations employed point-to-point encryption (P2PE) which encrypted the PAN data and further reduced the risk to the payment accounts processed as EMV® Chip.”
Visa did not name the merchant in question, but something similar seems to have happened at Key Food Stores Co-Operative Inc., a supermarket chain in the northeastern United States. Key Food initially disclosed a card breach in March 2020, but two weeks ago updated its advisory to clarify that EMV transaction data also was intercepted.
“The POS devices at the store locations involved were EMV enabled,” Key Food explained. “For EMV transactions at these locations, we believe only the card number and expiration date would have been found by the malware (but not the cardholder name or internal verification code).”
While Key Food’s statement may be technically accurate, it glosses over the reality that the stolen EMV data could still be used by fraudsters to create magnetic stripe versions of EMV cards presented at the compromised store registers in cases where the card-issuing bank hadn’t implemented EMV correctly.
Earlier today, fraud intelligence firm Gemini Advisory released a blog post with more information on recent merchant compromises — including Key Food — in which EMV transaction data was stolen and ended up for sale in underground shops that cater to card thieves.
“The payment cards stolen during this breach were offered for sale in the dark web,” Gemini explained. “Shortly after discovering this breach, several financial institutions confirmed that the cards compromised in this breach were all processed as EMV and did not rely on the magstripe as a fallback.”
Gemini says it has verified that another recent breach — at a liquor store in Georgia — also resulted in compromised EMV transaction data showing up for sale at dark web stores that sell stolen card data. As both Gemini and Visa have noted, in both cases proper iCVV verification from banks should render this intercepted EMV data useless to crooks.
Gemini determined that due to the sheer number of stores affected, it’s extremely unlikely the thieves involved in these breaches intercepted the EMV data using physically installed EMV card shimmers.
“Given the extreme impracticality of this tactic, they likely used a different technique to remotely breach POS systems to collect enough EMV data to perform EMV-Bypass Cloning,” the company wrote.
Stas Alforov, Gemini’s director of research and development, said financial institutions that aren’t performing these checks risk losing the ability to notice when those cards are used for fraud.
That’s because many banks that have issued chip-based cards may assume that as long as those cards are used for chip transactions, there is virtually no risk that the cards will be cloned and sold in the underground. Hence, when these institutions are looking for patterns in fraudulent transactions to determine which merchants might be compromised by POS malware, they may completely discount any chip-based payments and focus only on those merchants at which a customer has swiped their card.
“The card networks are catching on to the fact that there’s a lot more EMV-based breaches happening right now,” Alforov said. “The larger card issuers like Chase or Bank of America are indeed checking [for a mismatch between the iCVV and CVV], and will kick back transactions that don’t match. But that is clearly not the case with some smaller institutions.”
For better or worse, we don’t know which financial institutions have failed to properly implement the EMV standard. That’s why it always pays to keep a close eye on your monthly statements, and report any unauthorized transactions immediately. If your institution lets you receive transaction alerts via text message, this can be a near real-time way to keep an eye out for such activity.
1. Is there a way to determine if a particular financial institution has implemented the EMV standard correctly?
2. More specifically, if a customer has a card issued by a small bank or credit union or store, is it that store that must implement the EMV standard, or the issuing card company (such as VISA or MasterCard)?
3. If a customer were to send a query to their financial institution, what specific EMV configuration would they ask for? Is it simply to check for a mismatch between the CVV and the iCVV?
4. Is there a way for the casual user to determine if their card data has been posted for sale on the dark web? Something akin to https://haveibeenpwned.com or https://haveibeenpwned.com/Passwords
5. If a user has frozen their accounts at all three major credit reporting agencies (Equifax, Experian, and TransUnion), does it matter overmuch to the individual, for financial reasons, if a credit card has been hacked? The individual might just as well wait for the card issuer to send an alert about the hack, or a new card, ‘cuz after all the financial hit to the individual can only be as much as $50 and is usually zero.
Honestly forget EMV – it’s just broken. Even if the issuer handles the CVV/iCVV correctly, the fact that the majority of the card data can be copied after it leaves the PED (PIN pad) makes EMV false security. If nothing else it makes it ripe for card not present fraud.
Really merchants should be implementing P2PE or E2EE with tokenization where the data is encrypted from the PED all the way to the issuer, without the merchant holding or having any capability to decrypt the card data at all and only being given a unique random “token” as a placeholder.
It is still possible for a PED to be compromised, but since they have controlled handling, code signing, and are tamper proof under PCI requirements, it’s a much less likely scenario.
that’s not correct. The EMV transaction information that travels contains a cryptogram, that is a secure hash of all the transaction information, and unique to this transaction. The issuing host verifies this cryptogram but also several other parts of the transaction, like an increasing sequence number. So you can make a copy of all of that information, but you can’t replay it, and you can’t calculate the next cryptogram.
EMV data cannot facilitate card-not-present fraud because it does not contain the CVV2 (number on the back of the card).
The only way is to reverse engineer.
Best bet would be to use your own card and manipulate the data that’s beyond the expiration date and see what declines or doesn’t decline when making a transaction.
But really does it matter ? If fraud happens, you don’t pay for anything. Let them do their job and if something happens let them fix it. Nothing to worry about nor waste your life trying to be one step ahead, bc ur already 10 miles behind.
One more thing. Just Bc someone says something won’t work doesn’t mean that in actuality it won’t work. Things aren’t always tested with all vulnerabilities known to mankind or not yet known. Always a trick or 2 that has t been implemented that will be abused. I’ve seen plenty of crazy tricks in my past that were surprising as hell when put into action. Somethings that you’d never believe would work , yet somehow did, defying all regulations..
Another great informative article !
Thank you. I had no idea about the 3 distinct values: iCVV, CVV, and the printed one on the back of the card. It seems to me as if online merchants always refer to the printed one as the CVV.
I thought that was confusing. According to wikipedia the printed one is “a type of” CVV, i.e. CVV2
https://en.wikipedia.org/wiki/Card_security_code#Types_of_codes
Same here. I didn’t know there were multiple CVV values in different places and the only time I’ve seen CVV refereed to is during online transactions.
Does the EMV chip still check the PIN locally?
I feel it should be properly done with some type of zero knowledge proof based on hashing and a shared secret (HMAC sytle) or public/private key crypto? Yes it would take more time.
US cards are generally chip and signature–not chip and PIN–so there’s usually no PIN on the card to verify. And even if there is one, almost all such cards are set up such that signature/no verification is preferred whenever possible. (Debit cards have some complications due to how debit routing works in the US, but I still consider those chip and signature because the Visa/MC AID on those is set up as such. Not to mention that PIN entry can be skipped nearly everywhere that asks.) There’s also the issue that a significant fraction of US merchant terminals simply can’t or won’t ask for PIN even if the card prefers it for verification, effectively downgrading chip and PIN cards to chip and signature anyway.
YMMV with cards/terminals from other countries, of course.
This is definitely true in my area; as I never put the PIN in, and in fact, most of the time a care giver is shopping for me and doesn’t know the PIN anyway. However, I found out if there is the slightest damage or glitch on the chip, the bank will tear up the card right in front of me, when I report refused sales. So they got a pretty tight system after all. They just order a new card and I have to switch cards until the new one gets in. So far this has happened only once.
Once PITA though is that merchants keep reporting their networks are down, almost as if they don’t want to deal with the Chip-N-PIN nightmare they’ve inherited. I’m about to call the company head quarters on this – especially since our state health officials are trying to get people off cash transactions because of the COVID problem.
It must be pointed out that in the US if you insert the card 3 times and comes back as ‘can’t read’ then you can swipe it. Thus allowing the normal track card thieves to steal whatever anyways when doing in person transactions.
yep… i am sure an honest criminal would never use this method though 🙂
The payment processors should be watching for patterns like this.
If a given reader makes a bunch of EMV transactions (for EMV enabled cards) and then a “damaged + Swipe” transaction (for an ostensibly swipe enabled card) and then more EMV transactions, ideally the processor should recognize that the card is misbehaving and reach out to the registered owner.
(I can’t remember if the Terminal information is available in all transactions.)
Card issuers accept mag stripe fallback transactions at their own risk and really should be declining them, as they do present a counterfeit fraud risk. Valid fallback is rare enough that rejecting such transactions impacts fraudsters much more than cardholders.
Over Christmastime last year, the chip on my card failed at a Kroger store.
I learned that Chase Bank will issue a “decline” if during the handshake with the termina, Chase Bank “learns” that the terminal supports Chip-based transactions, but the transaction is “swiped”.
The Merchant has to manually-key in the transaction or force it.
Kroger still doesn’t support ApplePay on its registers so I went to Safeway store instead.
I’ve ran into issues with “3-Dips before a Swipe” and Decline by Chase at other merchants as well.
MicroCenter, the computer store, as an example, is now a 100% card-based company, and heavy usage has caused some of their credit card terminals to need cleaning/replacement. However, and unlike Kroger, Microcenter supports ApplePay.
ApplePay has become a good backup for transactions that draw on Chase Bank accounts.
During a EMV transaction the terminal transmits if the previous transaction was processed with EMV Or if it was processed without EMV and swiped instead. Supposed to be apart of the approvals/decline process, fraud filters.
I hope that if you discover which banks are not properly implementing the standard that you name and shame them.
Bryan says: If your institution lets you receive transaction alerts via text message, this can be a near real-time way to keep an eye out for such activity.—I have set an alert that every time my credit card is charged $1 or more, I get an alert via email. It’s not a problem for me to get these emails. I just delete after confirming.
I have set it up with my bank, with notifications all the way down to $1. I have put in a request to have all transactions sent to me, regardless of amount, so that I can catch any rogue charges. I have read that some card thieves can put in charges under a dollar to verify the validity of the card number, in prelude to a big charge. Since I have put maybe one sub-$1 charge on my card in 15 years, it’s not like they will have to send many more messages to me, so I don’t see why the minimum charge amount can’t be set to the smallest possible publicly-traded amount (such as a single cent, as I doubt anyone who is not a fuel company needs single-mill notification).
I believe that banks have the ability to reject swiped transactions from cards that are supposed to have a chip, which would make this fraud a lot harder, at least for in-person transactions. But they don’t. They must be making a phenomenal amount from swipe fees to be able to eat all the fraud.
As for the swipe after three failures thing, the response to that is just say no. If the terminal is broken it’s broken and they should fix it or get a new one.
No, John, banks are incredibly competitive. If, for whatever reason, a change in a security procedure makes one cards’ transactions more likely to complete than another, then the customer will prefer that card without regard to security. Disabling non-EMV transactions on a chip card will simply mean that card is less preferred in that consumers wallet.
Regarding the near real-time alerts from banks of transactions just done, I have a credit card from Fidelity, where this is next to useless:
a) The SMS message is almost always a day, 3 days or even later than the transaction
b) To add to the confusion, a vast majority of the transactions sit in a pending state when I get into the app for the credit card
c) The worst part is that when the messages do appear, they are almost completely meaningless – they only have the amount with almost always no context. These appear to be the vast majority of transactions, including most of my online transactions, periodic automatic transactions
d) The exceptions are when the charges are online and the messages appear in near real-time. That’s about the only time there is a context
e) So long story short, I have to log onto the Credit Card app to see what charges of mine are in a pending state (and the messages haven’t reached me) and what the meaning of the messages are that I have just received
In comparison, Chase and Citi messages are within the app, always near real-time, and almost always with roughly meaningful context as to the vendor
Give bad reports about the card (to Consumer Reports, friends, etc.).
The way to fix this is to band together (and also vote w/ your wallet — take business away from this vendor).
iow, do what you’re doing here :-).
I found that one of the visa emv rsa keys was 512bits and I was able to factor it in a week with cado nfs, then I reported my findings to visa. I’m still waiting for a reply and the key is still listed as valid.
https://twitter.com/0x446172696f0a/status/1262170347505364992?s=19
https://www.eftlab.com/knowledge-base/243-ca-public-keys/
The acronym for POS in these types of articles doesn’t compute, maybe use PoS and that will be more understandable to simple dopes like me.
Thank you, love your work and insight.
Point Of Sale is too hard a concept to grasp from the context of the article? It’s not like Brian just made up an acronym at random, many common acronyms have different meanings.
“The technology causes a unique encryption key — referred to as a token or “cryptogram” — to be generated each time the chip card interacts with a chip-capable payment terminal.”
It sounds like this is meant to refer to a dynamic iCVV, which is not a key, a token, or a cryptogram (which are all different things)?
Is it still possible to glean the requisite data if you use ‘Tap and Go” where the card is tapped on the PoS terminal rather than inserted in the terminal? Here in Australia most merchants are only allowing “Tap and Go”. No Cash either!
Yes, contactless payment will transfer track1&2 equivalent data as well.
If you want to know more about your EMV cards, the open source software “Cardpeek” is a great tool (needs a smart card reader)
Track I&II data should be insufficient to process transactions though – no CVV2 means no card-not-present fraud; no iCVV, transaction counter, or card private key means no valid cryptograms for EMV transactions. Only very badly verified card-not-present, fallback, or mag stripe transactions present a problem – and any bank worth their salt will reject these.
Good article. And thought provoking. I see some are confused yet as to what is feasable with access to a communication and data. And using a modern computer. Such as a modern telephone. There are small programs that are used to decrypt electronic transmissions. Even to locate transmissions, and see what is said on solid wire and braided wire and not attached to the wire intercepters. Every signal can be taped, recorded and tested to the point of identification of what happened to generate the signal. All encryption does is to mix up the signal with noise. But, it is studied, and to be useful, must be of a recognizable pattern to be useful to a customer, in other words, I get hot coffee instead cold drink. Everyone is looking at the chip on the card as secure, but it has the same identification numbers, as the “card” , hidden in it. Creating another burst of noise. The pattern can be broken, and reused. Is tap and go any safer? That noise can be read up to sixty foot, twienty meter away according to a study. Done in the past century. Have communications improved since then? Not content. But reception technology. Just slightly. Tap and go depends on the reader to project a constant tone, and your device interrupts that tone, creating a number, the difference is, you don’t have to be in the location of the sale to access the data, just near enough.
I believe shaming those banks (and merchants) whose credit card transaction security is below par would be a great way to force them to tighten their procedures. We, as card holders, would know which banks (and which merchants) have poor security and decide whether or not to use their services.
The fact that VISA is owned by the banks makes it unlikely that VISA will out those banks whose card security is below par. Ever the problem of self-regulation.
The fact that VISA gets all its income from merchant fees is probably a reason why they will not indentify to the cardholder, whose card has been compromised, which merchant was responsible for the breach.
No matter that I am not financially responsible for the fraudulent use of my credit card, I am still impacted as I have to change my credit card information with other vendors who have my card information on file for transactions, automated and otherwise.
Even better , act like ur better than them and don’t use their cards. What makes I think they need you? Keep it moving bc they are too
Thank you for entertaining my suggestions for ticks with the chip. Please contact me if you have any other interest in my opinion. Thank u
Yet another reason to use Apple Pay.
Re: “… Yet another reason to use Apple Pay …”
Absolutely right.
IMO Apple doesn’t sufficiently “talk-up” the security benefits afforded by the architecture.
Ever heard of SIM swapping?
Making ur little token the crooks golden token once they are the Proud new owner of ur bulletproof method.
I’m surprised that the card companies don’t have a compliance suite that a bank would have to pass before it could issue cards.
Most people’s perception is that the card account number on an EMV card is secure. However, the card account number is transmitted in the clear (no encryption) when inserted into the PoS, or used as a contactless Tap and Go transaction. Unless the merchant is using P2PE, bad actors can continue to insert malware and capture unsecure card account data knowing that Banks are lax in implementing proper controls.
The solution is to tokenize the card account number in the EMV chip, making it different than the card account number printed on the card. The issuer can link the two accounts, but would know immediately that if the token account number is counterfeited or attempted to be used in a Card Not Present environment, it is a fraudulent transaction and decline (cardholder will never see the token transaction, so couldn’t possibly enter it manually). By tokenizing the card account numbers in all EMV chips, issuers will vastly reduce bad actor behavior. This could also virtually eliminate the need for PCI DSS requirements for millions of small merchants that are EMV enabled, since the use of tokens in leiu of Primary Account Numbers, would put their PoS out of scope of PCI requirements.
Is this really new?
I’ve both worked on cases involving 3rd party hardware mods built into a physical card and read about others (FUN card hack from 2015, among others) although all of these were abroad (Europe, South America).
Perhaps new in the US only?
My card was recently involved in a breach. I got a text on my phone asking if I attempted to withdraw around 1000 at a cardtronics ATM in Oregon but I live on the east coast. The bank claimed hackers got access to my bank account by means of weak passwords and (which it wasn’t weak, I use LastPass) and I suggested to them that perhaps my card was breached at a retailer I shop at and my card was made into a counterfeit card. They dismissed that idea, locked my account down and it took a month to get my new account and access straightened out. I am thankful for this article because now I have an idea what is going on and trying to find out which chips are more secure.