People often ask me what can they do to prevent themselves from being victims of card fraud when they pay with their cards at shops or use them in ATMs (for on-line card fraud tips see e-victims.org, for example). My short answer is usually “not much, except checking your statements and reporting anomalies to the bank”. This post is the longer answer — little practical things, some a bit over the top, I admit — that cardholders can do to decrease the risk of falling victim to card fraud. (Some of these will only apply to UK issued cards, some to all smartcards, and the rest applies to all types of cards.)

Practical:

1. If you have a UK EMV card, ask the bank to send you a new card if it was issued before the first quarter of 2008. APACS has said that cards issued from January 2008 have an iCVV (‘integrated circuit card verification value‘) in the chip that isn’t the same as the one on the magnetic stripe (CVV1). This means that if the magstripe data was read off the chip (it’s there for fallback) and written onto a blank magstripe card, it shouldn’t — if iCVVs are indeed checked — work at ATMs anywhere. The bad news is that in February 2008 only two out of four newly minted cards that we tested had iCVV, though today your chances may be better.

2. In places that you are able to pick up the PIN entry device (PED), do it (Sainsbury’s actually encourages this). Firstly, it may allow you to hide your PIN from the people behind you in the queue. Secondly, it allows you to give it a cursory inspection: if there is more than one wire coming out from the back, or the thing falls apart, you shouldn’t use it. (In the picture on the right you see a mounted PED at a high-street shop that is crudely taped together.) In addition, be suspicious of PEDs that are mounted in an irregular way such that you can’t move or comfortably use them; this may indicate that the merchant has a very good camera angle on the keypad, and if you move the PED, it may get out of focus. Of course, some stores mount their PEDs such that they can’t be moved, so you’ll have to use your judgment.

3. Put a hand, wallet, purse, hat over your hand when you punch in the PIN at an ATM or PED. Don’t be shy about it. Practice punching in the PIN in such a way that your hand movements do not reveal the digits (one way is to use your thumb underneath your palm). Hiding your PIN as you enter it is prudent and good practice, though it may not save you if the PED has been compromised during manufacturing, or as we have demonstrated in the past.

4. If you have a debit card, keep as little money as possible in the account that is associated with that card so you minimize the amount of money criminals have access to. Also, try to set the account such that there is no overdraft allowed on it.

5. When you travel outside of the UK with an EMV card, local criminals can steal it and sign for goods at places without EMV infrastructure; they don’t need to know the PIN. You will then have to fight for your money with your bank. So don’t take along cards you do not intend to use, and if you do, hide them well, especially if you leave them behind in a dodgy hotel.

6. Set your cards to have different PINs: if someone saw your PIN when you entered it at a shop and later steals your wallet, he will be able to withdraw money from all of your cards. Even if the PIN wasn’t compromised, if the criminal assums that all PINs are the same, he now has more attempts to guess it. If you find it hard to remember multiple PINs, then set them to have some relationship (that you keep to yourself). Say, each digit of the second card’s PIN is an increment of the corresponding digit of the first card’s PIN; there are many ways to do this such that it is easy to derive PINs from the one you remember.

7. Be observant at ATMs. A broken ATM should either be off, or more properly, display an “out of order” message on the screen. A note posted on the screen may indicate that the criminals are trying to divert you to an ATM they have compromised (by installing an ATM skimmer or a Lebanese loop). Or, they have placed a fake ATM nearby that may give you the cash, but will empty your bank account. In general, avoid using mobile or detached ATMs; fake or tampered ones can be easily passed off as legitimate, and you are unlikely to notice. (The advice on how, where and when to install ATM skimmers by a seasoned card fraudster can also tell us what to look out for.) Finally, be suspicious of anyone “helping” you to use an ATM.

Paranoid:

8. Put a thin opaque tape over the CVV2 (the three digit number on the back of the card that is used for card-not-present, i.e. on-line, transactions). All a cashier or waiter needs to know in order to make an on-line transaction with your card is the account number, name, expiry date, and the CVV2; all helpfully available on the card itself. Hiding the CVV2 from being remembered on casual inspection may save you from paying for someone else’s big screen TV. In some cases the crooks may need your address as well, so the waiter that skims your card also gives you a raffle card to put your details on for a chance to win a free bottle of wine on your next visit. Since the address verification in the UK is inadequate, all they need to do in order to get the TV delivered is to find an address that matches the digits within yours.

The CVV2 is used as a weak indicator that the person making the on-line purchase is actually in possession of the card. There is nothing preventing you from scratching off the three digits and keeping them safe elsewhere (near the only computer you do on-line transactions on, for example). In addition, when you lose your card, it will be harder for criminals to use it on-line.

9. If you have access to a magstripe encoder, replace account details on the magstripe with 0’s. The disadvantage is that this card will be useless where smartcards are not accepted. So if you know that you’ll always use the chip, erasing the magstripe may be a good idea. (Practically, you may not want to erase the whole stripe because some ATM card slots check for data at the front of the stripe in order to accept the card; if that data is gone, you won’t be able to get cash. I also suppose that there are other ways to make the magstripe data invalid other than erasing it with an encoder.)

10. After you return from a trip abroad, if you have any doubt about the places that swiped your cards, change your PIN at an ATM. This will prevent criminals from withdrawing money from your account in countries that do not have EMV. You may also want to consider canceling the card, or ask your bank what to do. (In the UK, it is easy to change the PIN at an ATM, and I am unaware of any limitations on the amount of times that that can be done. I believe that some banks will re-issue you cards a small number of times per year for free, and then start charging you for them.)

11. If you know of shops that let you pay with your card as a chip transaction but also swipe the magstripe for good measure and no apparent good reason, stop shopping there (I’ve experienced this in two different chain stores in the UK). They are not supposed to do that, and it is bad practice to educate cardholders that this is OK. Sometimes, it happens so fast you can’t stop the swipe; if you are concerned, change the PIN. It is common for cashiers to use a ’swipe-and-dock’ register if the PED fails (or always!) Avoid letting them use it if you can.

12. If a waiter takes your card and walks away, call them back or follow them. With Chip and PIN, they are not supposed to take the card away; in fact, they are not supposed to handle the card at all. If they see you following them, they might think twice before skimming your card and details with a tiny portable card reader.

13. If your PIN has two (or more!) digits that are the same one after another (‘1066‘, is a good example of a really bad one), make sure you pause between them such that you do not help the criminals guess your PIN.

We can argue that in a well designed system some of the tips above would not be necessary, but that’s what we have to work with. It will be interesting to observe how banks will deal with card fraud in the current state of financial affairs. It seems to me that banks are going to be stricter with giving money back when fraud occurs, even in clear cases in favour of the cardholder, while victims are going to suffer even more due to the loss.

In February, Steven Murdoch, Ross Anderson and I reported our findings on system-level failures of widely deployed PIN Entry Devices (PED) and the Chip and PIN scheme as a whole. Steven is in Oakland presenting the work described in our paper at the IEEE Symposium on Security and Privacy (slides).

We are very pleased that we are the recipients of the new “Most Practical Paper” award of the conference, given to “the paper most likely to immediately improve the security of current environments and systems”. Thanks to everyone who supported this work!

Steven J. Murdoch, Ross Anderson and I looked at how well PIN entry devices (PEDs) protect cardholder data. Our paper will be published at the IEEE Symposium on Security and Privacy in May, though an extended version is available as a technical report. A segment about this work will appear on BBC Two’s Newsnight at 22:30 tonight.

We were able to demonstrate that two of the most popular PEDs in the UK — the Ingenico i3300 and Dione Xtreme — are vulnerable to a “tapping attack” using a paper clip, a needle and a small recording device. This allows us to record the data exchanged between the card and the PED’s processor without triggering tamper proofing mechanisms, and in clear violation of their supposed security properties. This attack can capture the card’s PIN because UK banks have opted to issue cheaper cards that do not use asymmetric cryptography to encrypt data between the card and PED.

In addition to the PIN, as part of the transaction, the PED reads an exact replica of the magnetic strip (for backwards compatibility). Thus, if an attacker can tap the data line between the card and the PED’s processor, he gets all the information needed to create a magnetic strip card and withdraw money out of an ATM that does not read the chip.

We also found that the certification process of these PEDs is flawed. APACS has been effectively approving PEDs for the UK market as Common Criteria (CC) Evaluated, which does not equal Common Criteria Certified (no PEDs are CC Certified). What APACS means by “Evaluated” is that an approved lab has performed the “evaluation”, but unlike CC Certified products, the reports are kept secret, and governmental Certification Bodies do not do quality control.

This process causes a race to the bottom, with PED developers able to choose labs that will approve rather than improve PEDs, at the lowest price. Clearly, the certification process needs to be more open to the cardholders, who suffer from the fraud. It also needs to be fixed such that defective devices are refused certification.

We notified APACS, Visa, and the PED manufactures of our results in mid-November 2007 and responses arrived only in the last week or so (Visa chose to respond only a few minutes ago!) The responses are the usual claims that our demonstrations can only be done in lab conditions, that criminals are not that sophisticated, the threat to cardholder data is minimal, and that their “layers of security” will detect fraud. There is no evidence to support these claims. APACS state that the PEDs we examined will not be de-certified or removed, and the same for the labs who certified them and would not even tell us who they are.

The threat is very real: tampered PEDs have already been used for fraud. See our press release and FAQ for basic points and the technical report where we discuss the work in detail.

Update 1 (2008-03-09): The segment of Newsnight featuring our contribution has been posted to Google Video.

Update 2 (2008-03-21): If the link above doesn’t work try YouTube: part1 and part 2.

For a while I have been looking very closely at how FPGA cores are distributed (the common term is “IP cores”, or just “IP”, but I try to minimize the use of this over-used catch-all catch phrase). In what I hope to be a series of posts, I will mostly discuss The problem (rather than solutions), as I think that that needs to be addressed and adequately defined first. I’ll start with my attempt at a concise definitions of the following:

FPGA: Field Programmable Gate Arrays are generic semiconductor devices comprising of interconnected functional blocks that can be programmed, and reprogrammed, to perform user-described logic functions.

Cores: ready-made functional descriptions that allow system developers to save on design cost and time by purchasing them from third parties and integrating them into their own design.

The “cores distribution problem” is easy to define, but challenging to solve: how can a digital design be distributed by its designer such that he can a) enable his customer to evaluate, simulate, and integrate it into its own, b) limit the amount of instances that can be made of it, and c) make it run only on specific devices. If this sounds like “Digital Rights Management” to you, that’s exactly what it is: DRM for FPGAs. Despite the abuse of some industries that made a bad name for DRM, in our application there may be benefits for both the design owner and the end user. We also know that enabling the three conditions above for a whole industry is challenging, and we are not even close to a solution.

The problem isn’t new, ASIC cores designers have been having trouble with this issue for years: run-on-fraud, copying, etc. The solution they arrived at is mostly based on trust and good reputation—valuable assets that are slowly gained yet easily lost—rather than cryptography. Big companies shaking hands with other big “trusted” companies relying on the potential reputation loss as an acceptable guarantee for honesty (plus a legal document). Apparently, this still works well for big companies, and while cryptographic solutions would be nice in order to alleviate the need for trust and provide for smaller companies world-wide, there is no real rush. “Panel unscrambles intellectual property encryption issues” has a very revealing discussion from the industry’s perspective and is well worth the read.

Back to FPGAs, with their unique use model, the trust-based system holds here as well; established companies can afford to purchase a blanket license for cores, are trusted, and that lets them use those as they like. You might have a problem, though, if you are a small and obscure company. As a poor start-up designer, you want to save time and money by taking advantage of “design-reuse”, but you can’t afford blanket licensing, and you may not be big enough, or in the right country, to be trusted even if you sign the NDA/licensing agreement. So, you either spend the time developing the design in-house, perhaps missing that three month opportunity window, or you give up. FPGA DRM could help you here because it will enable a pay-per-use model. You will be able to pay only for the instances of the core you use regardless of your company’s “trust status”, starting with small quantities until you hit it big. In turn, pay-per-use also benefits cores designers by giving them business that they wouldn’t have gotten otherwise. Both sides win. Sort of. More in Part 2.

On a recent visit to a local supermarket I noticed something new being displayed on the keypad before the transaction starts:

(“Did you know that you can remove the PIN pad to enter your PIN?”)

Picking up the keypad will allow the cardholder to align it such that bystanders, or the merchant, cannot observe the PIN as it is entered. On the one hand, this seems sensible (if we assume that the only way to get the PIN is by observation, no cameras are present, and that even more cardholder liability is the solution for card fraud). On the other hand, it also makes some attacks easier. For example, the relay attack we demonstrated earlier this year, where the crook inserts a modified card into the terminal, hoping that the merchant does not ask to examine it. Allowing the cardholder to move the keypad separates the merchant, who could detect the attack, from the transaction. Can I now hide the terminal under my jacket while the transaction is processed? Can I turn my back to the merchant? What if I found a way to tamper with the terminal? Clearly, this would make the process easier for me. We’ve been doing some more work on payment terminals and will hopefully have some more to say about it soon.

Handling the terminal is also good for helping cardholders detect a cleverly mounted tampered terminal, if they know what to look for (on occasion I examine terminals at shops but try not to seem too eager as I’m never sure if “it’s OK, I’m a researcher” would get me out of trouble). According to APACS‘ “Retailer advice“, terminal tampering is recognized as a very real threat (unfortunately, it assumes that merchants are universally honest). It is interesting to read that they actually recommend that merchants place a CCTV to cover the till area, but only such that the cardholder’s PIN cannot be observed. I wonder how that is reconciled with encouraging the cardholder to move the pad.

In this context I should mention that earlier this year we’ve seen Ingenico attempt at protecting against PIN observation by using “ViewSafe“, a magnifying glass mounted on top of the keypad such that the keys can only be viewed from the cardholder’s vantage point. The design has two main flaws, though. Firstly, the magnifying contraption is retractable when it should be fixed, and secondly, it provides a convenient setting for mounting a camera. The first trial was in our local Cambridge Boots store, so I had a few opportunities to see that none of the terminals had the magnifying glass in its “operational” state. I couldn’t find references to how successful the trials were and if these magnifying glasses are now more widely used.

A project called NSA@home has been making the rounds. It’s a gem. Stanislaw Skowronek got some old HDTV hardware off of eBay, and managed to create himself a pre-image brute force attack machine against SHA-1. The claim is that it can find a pre-image for an 8 character password hash from a 64 character set in about 24 hours.

The key here is that this hardware board uses 15 field programmable gate arrays (FPGAs), which are generic integrated circuits that can perform any logic function within their size limit. So, Stanislaw reverse engineered the connections between the FPGAs, wrote his own designs and now has a very powerful processing unit. FPGAs are better at specific tasks compared to general purpose CPUs, especially for functions that can be divided into many independently-running smaller chunks operating in parallel. Some cryptographic functions are a perfect match; our own Richard Clayton and Mike Bond attacked the DES implementation in the IBM 4758 hardware security module using an FPGA prototyping board; DES was attacked on the FPGA-based custom hardware platform, the Transmogrifier 2a; more recently, the purpose-built COPACOBANA machine which uses 120 low-end FPGAs operating in parallel to break DES in about 7 days; a proprietary stream cipher on RFID tokens was attacked using 16 commercial FPGA boards operating in parallel; and finally, people are now in the midst of cracking the A5 stream cipher in real time using commercial FPGA modules. The unique development we see with NSA@home is that it uses a defunct piece of hardware.

Let me explain why this is important. The Virtex-II PRO FPGA—the one used by NSA@home—was introduced in 2002, only about five years ago. It is spec’d at about 400 MHz while today’s latest FPGAs, two generations later, are spec’d at around 550 MHz. So we have not gained that much in speed, but rather in size, specialization, and integration of embedded interface functions such as fast serial transceivers, Ethernet MACs, more embedded memory, etc. But if you want only plain logic and memory for parallelism, the old dinosaurs of a few years ago are still very much relevant, especially if you can get them for next to nothing and someone already took the effort to design the PCB for you. Hobbyists are (extremely) displeased that the dense ball grid packages put them out of business, so to speak (and that the FPGA vendors do not care so much about it, which is another discussion). So, with FPGAs being used in ever more applications, I see this type of recycling becoming more popular. When will we see an enterprising student create a Logic-101 lab from recycled consumer electronics?

The other interesting aspect of NSA@home is the trade-offs. Much like Clayton and Bond, Stanislaw is checking subsets of the hash, places them within ranges, and leaves the final checking for the host PC; he could barely fit an unrolled, pipe-lined SHA-1 into each FPGA, so that trade-off was necessary. Another important aspect is the realization that FPGA resources are still there even if you do not use them. Usually, you would try to minimize the resources you use in order to make room for other functions; or, try to fit your design into a smaller FPGA and save money. But when you have a single application, and a given device size, you should try to use all at your disposal. This designer decided to use the embedded block RAMs, which would otherwise be unused, as look-up tables. Good job.

Steven Murdoch and I have previously discussed issues concerning the tamper resistance of payment terminals and the susceptibility of Chip & PIN to relay attacks. Basically, the tamper resistance protects the banks but not the customers, who are left to trust any of the devices they provide their card and PIN to (the hundreds of different types of terminals do not help here). The problem some customers face is that when fraud happens, they are the ones being blamed for negligence instead of the banks owning up to a faulty system. Exacerbating the problem is the impossibility of customers to prove they have not been negligent with their secrets without the proper data that the banks have, but refuse to hand out.

Using a fake terminal and custom circuitry we demonstrated that a fraudster can get away with charging an unwitting, honest customer’s card with a purchase he did not authorize. The importance of this demonstration was that it showed that even though the customer is diligent about keeping his PIN secret, he can still be defrauded. APACS, the UK payment association, say that they are unaware of any cases of relay attacks being used against Chip & PIN in the UK. The reason, we believe, is that even though the cost and the technical expertise that are required for implementing the attack are relatively low, there are easier ways to defeat the system. Methods such as card counterfeiting/theft, mail interception, and cardholder impersonation are routinely reported and are more flexible in deployment. These security holes are gradually being closed, but card fraud remains a lucrative industry — in 2006 £428m of fraud was suffered by UK banks. Criminals will adapt to the new environment and, to maintain their income, will likely resort to more technically demanding methods, so now is the time to consider how to prevent relay attacks for when that time arrives.

We propose a defense against the relay attack in the form of “distance bounding“. This will allow the payment terminal to measure the distance between itself and the card and decide, based on its risk settings, whether to accept the transaction. We have built such a system using an FPGA and demonstrated that it can reliably operate in the face of a capable attacker and discern the addition of short transmission distances. With EMV being the target application, we have made the design such that the additional cost is mostly absorbed by the terminal rather than the smartcard and that the customer-merchant “experience” is unchanged. If the banking industry adopts this extension to EMV, the risk from relay attacks would be negligible. We describe the engineering details in a paper (“Keep your enemies close: Distance bounding against smartcard relay attacks“) that will be presented in August at the 16th USENIX Security Symposium. Along with a description of the relay attack, we also discuss the security-economics aspects of customers bringing their own trusted device into the transaction, as well as the ineffectiveness of procedural and other technical solutions that were previously proposed.

Many discussions over the security of Chip & PIN have focused on the tamper-resistance of terminals (for example in the aftermath of the Shell Chip & PIN fraud). It is important to remember, however, that even perfect tamper resistance only ensures that the terminal will no longer be able to communicate with the bank once opened. It does not prevent anyone from replacing most of the terminal’s hardware and presenting it to customers as legitimate, so freely collecting card details and PINs.

Steven Murdoch and myself took the chassis of a real terminal and replaced much of the internal electronics such that it allows us to control the screen, keypad and card-reader. Steven suggested that in order to show that it is completely under our control, we should make it play Tetris (similarly to the guys who made a voting machine play chess). We recorded a short video showing our Tetris playing terminal in action. Have a merry Christmas and happy New Year

Update (2007-01-03): The video is now on YouTube.

Update (2007-01-05): The Association for Payment Clearing Services
(APACS) has responded:

APACS, the payments organisation representing high street banks, said the Cambridge breakthrough could be a threat.

‘People could, in theory, use this to steal account details from cards,’ said Sandra Quinn of APACS. ‘Our experts are in discussion with the manufacturers of terminals to see what can be done. Essentially what these people have done is replace the innards of a chip and Pin machine.

‘However, we would say that this has only been seen in a laboratory so far. People would not be able to create counterfeit chip and Pin cards, but they could use this information abroad to make purchases.’

Open video in external viewer

I recently got an email from Bank of America offering me a pretty good credit card deal. Usually, I chuck those offers away as spam (both electronic and physical) but this time I decided to bite.

The “apply now” button pointed to http://links.em.bankofamerica.com:8083/…, fair enough. I click. But wait… IE6 says…

Firefox provides more info without layers of abstraction…

I clicked “OK” and got to… https://www.mynewcard.com/! (you’ll notice that going there directly redirects to https://mynewcard.bankofamerica.com/, so only when you click “apply” do you get to see mynewcard.com.)

I consequently emailed BofA with my concerns and got this (surprisingly expedient) reply:

“We recognize that any unsolicited e-mail, legitimate or otherwise, is reason for concern. I can assure you that www.mynewcard.com is a legitimate website of Bank of America.”

Well, not much assurance there since I replied to the original email (cardservices@replies.em.bankofamerica.com), but a whois query confirms that mynewcard.com indeed belongs to BofA. What percentage of the population would go beyond clicking that “OK” on the IE warning as just another annoyance? You know the answer.

So, BofA got three things wrong. Firstly, they had links in the body of the email; the argument has been beaten to the ground… don’t educate people to click them. If the bank has great offers, they should have them available when people log into their accounts. Secondly, they messed up on the certificate… it’s for mynewcard.bankofamerica.com, not what appears in the address bar, mynewcard.com. And finally, they used an unfamiliar domain to process the application. Why? I think the answer lies somewhere in the marketing department where they decided that mynewcard.com is cooler sounding than sound security measures and long term good customer training.

Update: Richard mentioned that the rapid response meant that BofA have heard this concern once before. I found this thread [dansanderson.com] discussing mynewcard.com in August 2003! Which adds a fourth thing BofA did wrong: they didn’t fix it!