Skimming continues to highlight the inherent vulnerability of account information transfer mechanisms (such as magstripe), as opposed to fixed currency transfer mechanisms. The fact that every vendor I transact with has the ability to capture my account information and make future requests for my money with it is terrifying. I have to trust that every 17-year old that handles my card at a restaurant isn't going to copy it and shop online with it later. The fact that the system works at all in its current state is a miracle.
Even if Bitcoin never gains mass adoption, I really like the idea of being able to encode a consumable transaction that both authorizes the transfer and encodes the transfer amount. I can imagine a similar payment system (NFC payment with phones, perhaps?) that doesn't disclose arbitrary access to my account, but instead allows a transaction to be proposed, I accept the transaction on my trusted hardware (phone), and the transaction authorization with amount is then sent up the wire.
This seems like it should be trivially accomplishable via mutual asymmetric signing. Vendor generates a request for money and signs it, sends it to my phone. My phone validates the chain-of-trust, presents me with the transaction request, and I can authorize it. If I authorize it, then the request is counter-signed with my private key, and the signed authorization is sent off to the payment processor, who has pubkeys for the vendor and myself and can validate the request and process it.
Even if you could capture the transaction-in-transit, you wouldn't be able to compromise it, since you would need signing keys for both the vendor and the customer in order to forge the transaction, or to create new transactions with the signed account information.
Chip and pin pretty much solves this. My understanding is that its much more difficult to intercept the transaction due to the cryptography involved. No one handles your card or walks away with it like in the US. They bring the wireless cc terminal to you.
These are coming to the US in 2015. I suspect a lot of the issues we have today will be minimized as we move away from magstripes and waiters walking away with your credit card.
Sadly that is not the case. Major problems with chip and pin:
- the chips used (32kb 90s-style smartcards AIUI) are simple to read and save, making chip and pin readers susceptible to the same social engineering attacks as magnetic stripe cards (btw, in the UK there have been skimmers for chip and pin for some time)
- most terminals on the market transmit the pin in the clear from one part of the unit to the other, so it is trivial to doctor a legitimate chip and pin unit
- it is difficult for the consumer to verify the trustworthiness of an unfamiliar chip and pin unit
- in the UK, people often still try to walk away with my card, just as when we had magnetic stripe
- transactions can be conducted offline in most configurations (true for example in the UK, but not in Germany)
IMO the main selling point of Chip and PIN to UK retail banks is that they allow banks to reassign liability to for fraud to the customer. When your signature is forged, existing law clearly says you are not liable. When you PIN is discovered and used to send transactions, existing law is unclear and currently this allows banks to convince the customer to accept the liability. IIRC, American consumer fraud law is pretty strict, which is why the US has been slower to adopt the machines than eg the UK.
In the UK, Chip and PIN seemed to cut fraud for a while, until attacks like skimming were applied. Now fraud is back on the rise :(
There is good coverage of this in chapter 10 of Security Engineering 2nd edition by Ross Anderson, a book I highly recommend!
>> - the chips used (32kb 90s-style smartcards AIUI) are simple to read and save, making chip and pin readers susceptible to the same social engineering attacks as magnetic stripe cards (btw, in the UK there have been skimmers for chip and pin for some time)
Erm, while it is simple to read public data off a smart card, you can't get at the private keys etc, this is pretty secure.
I work in this area and while I am aware of a couple of weaknesses in the scheme (Static Data Authentication is a big one, but only affects some cards), I am not aware that even a PoC 'skimmer' exists.
AFAIK (and as I said, I work in this industry) the only key-recovery attack so far involved an electron microscope.
>> - most terminals on the market transmit the pin in the clear from one part of the unit to the other, so it is trivial to doctor a legitimate chip and pin unit
This depends on the card, not the terminal. All parts of the system in a terminal must be secure, we have stringent standards to stop tampering.
>> it is difficult for the consumer to verify the trustworthiness of an unfamiliar chip and pin unit
This is true. A fake unit could me made pretty trivially.
>> in the UK, people often still try to walk away with my card, just as when we had magnetic stripe
This is less of a concern.
>> IMO the main selling point of Chip and PIN to UK retail banks is that they allow banks to reassign liability to for fraud to the customer. When your signature is forged, existing law clearly says you are not liable. When you PIN is discovered and used to send transactions, existing law is unclear and currently this allows banks to convince the customer to accept the liability.
100% false.
The liability transfer was to the merchant, not the customer.
>> In the UK, Chip and PIN seemed to cut fraud for a while, until attacks like skimming were applied. Now fraud is back on the rise :(
Please provide sources for EMV skimming attacks, I'd love to read about them.
Chip & Pin has the fatal flaw of asking me to trust unverified hardware. I know that my phone is trustworthy. I don't know that your POS terminal is. It definitely eliminates a lot of the issues present in the current magstripe setup, but what I want is something that requires access to a black box I trust.
As long as I'm handing credentials to an untrusted computer that I have to trust to behave honestly, the problem isn't solved.
"I really like the idea of being able to encode a consumable transaction that both authorizes the transfer and encodes the transfer amount."
This occurs in EMV transactions. It's not exactly as you describe but there are a lot of similarities. Effectively, in your scenario, your credit card becomes your signing token.
--edit--
Just to give you a bit more detail, there is mutual auth (terminal to card, card to terminal, card to payment process and payment processor to card), and the card creates a cryptogram from various pieces of transaction data (date/time, amount, customer verification method used etc etc).
EMV is all very well and good (to be clear, without a cryptogram the payment can't be charged), but it falls down because of the requirement for backwards compatibility. For physical, retail transactions the easy way out of this is a liability shift (make the retailer liable for any fraudulent transactions that aren't run using EMV), but it's much harder for card-not-present (online) transactions, where people just type in card numbers and go.
For cardholder not present transactions there's 3D Secure[1], which sits in the middle of online transactions. Customers fill in their details on the merchant's site, then redirect to a service run by their card provider which asks for some form of authentication that only the provider knows about, and then a token is passed back to the merchant which can be used to authenticated the transaction.
Much as in store transactions which aren't conducted with Chip & PIN transfer liability to the merchant, online transactions without 3D Secure will also transfer liability, giving merchants a potentially hefty incentive to verify the customer's identity.
I hate this model. Try to buy something get redirected to a 4th party (not the retailer, buyer or the bank / card issuer) and get asked to enter private secret information. It teaches all the wrong things about security.
Well yes, for physical transactions there is the back compat issue, but hopefully as more countries take up the scheme (hint hint USA) we'll have less and less need of fallback.
I agree that a system for verifying/authorising specific amounts for online transactions would be a good thing, and I agree that the "here's my card info, charge what you like" model is a bad one.
The whole idea of building hardware to be easily verified by the user is pretty interesting -- it's the intersection of industrial design/design for manufacturing, ee. computer security, in some cases crypto, etc.
We haven't gotten much beyond stupid stickers and hologram seals.
I wonder if it's maybe time for banks to stop printing magstripe cards by default and offer a "world" version of their card as an option for people who travel to places like the US?
Some banks issue chip-and-pin cards which also have a magnetic stripe, but the magstripe is not activated unless you specifically ask for it. And you can do things like activate the magstripe for a specific country for a specific time frame.
That's similar to what was done (mandated by the government) last year where I live. Overseas withdrawals are disabled by default and customers must now opt-in to allow them.
The customer can choose a validity period and per/day withdrawal limit, but I don't think it's possible to enable on a per country basis.
I wonder if one could somehow temporarily disable the magnetic stripe? I wouldn't dare scratch it off completely, but I would love to cover it up as a precaution.
You could always get hold of a card reader/writer and do it your self. The magstripe is essentially just a small capacity magnetic disk. You can read the information off and store it, then proceed to wipe it clean. If you want to restore, just write the data back.
It's not that easy, there are High Coercivity and Low Coercivity magstripes. HiCo cards need special writers because they're more resistant to external magnetic fields.
"One of the simplest ways to protect yourself from ATM skimmers is to cover the PIN pad when you enter your digits."
As I understand the PIN is stored encrypted on the magnetic strip (salted with the account number) which allows it to be verified even when offline. I wonder how strong this encryption actually is, given some ATMs still run on 20 year old hardware it can't be that intensive.
There were some cases where pin was either stored encrypted on magstrip or was generated from information on magstrip, but I think these very few cases and I don't think any bank does it anymore.
Most cards I dealt with had option to change PIN either online or via call to bank support. So it can not be stored on card for offline verification.
Method that is used to store PIN on mag stripe is kind of weird, but reasonably secure. Idea is that card issuer has some unspecified algorithm that generates PIN from card number and what is stored on the magstripe is difference from this "default PIN". In essence this is weird formulation of counter mode of block cipher, more so that the unspecified algorithm typically entails encrypting card number with (Tripple-)DES or AES and BCD-reducing the result.
This offline verification of PIN is mostly only relevant for ATMs owned by card issuer, as whatever device that does this verification has to know secret symmetric key for this algorithm.
I don't understand this one: my card didn't come with a PIN and forced me to set it myself online (of between 4 and 12 characters) - and this from a major Australian bank (CommBank).
I don't think having a PIN encoded on the magnetic strip is common practice at all. I've worked in payment cards on and off for over a decade and never heard of this before, certainly not here in the UK.
In Australia the chip card market is pretty advanced, and those use either online PIN, or can be updated (usually by the bank's own ATM). When offline PIN is used with EMV then the card itself does the validation.
The OP described the original offline PIN system. My memory is a bit fuzzy, but my recollection is that the original ATM PIN system was designed for offline verification and didn't allow user-selectable PINs. There was a tamper-resistant chip that encrypted the account number with single DES (using a system-wide fixed key) and took the first 16 bits of the result. There was a 16 entry table that mapped nybbles to keypad digits, and this was used to non-invertibly map the 16 bits nyble by nyble to a 4 digit decimal number. The interface to the tamper-resistant hardware module took in the 4-digit PIN and the account number and spat back out pass/fail, to minimize the utility of stealing an ATM. I probably got some of the details a bit wrong, but that's the gist of the system.
Soon after rollout, enough customers complained about wanting to set their own PINs that they added a 4 digit offset field to the magnetic stripe. The offset from the stripe was added to the user-entered PIN, and the least significant 4 digits were sent to the hardware verifier. That way the hardware verifier didn't need to be changed. The only way to change the PIN was by physically bringing the card to the bank. As I said, the details are probably a bit wrong, but it went something like that.
I read about one attack where the 16 entry nyble-to-digit mapping wasn't authenticated very well, so attackers could steal an ATM, then trick the hardware module into loading a mapping that mapped 0-7 to "0" and 8-F to "1", then bruit force the PINs for a bunch of cards. Then they'd change the mapping to 0-3 -> "0", 4-7 -> "1", 8-B -> "2", C-F -> "3". After two more rounds of this, they could use the production mapping of nybles to keypad digits. For each round, it takes an average of 8 guesses and a maximum of 16 guesses to guess the PIN with the PIN. (Information gained from one round is fed forward to the next round's guesses.) There are four rounds, so an average of 32 guesses and a maximum of 64 guesses to extract a PIN. Once the PINs were bruit-forced using the stolen ATM, they could be brought to a real ATM, even though the attack wasn't able to extract any information about the DES key used by the system.
A later system had a tamper-resistant module that used 3DES to encrypt modem traffic between the bank and the ATM. Changing 3DES keys involved two different employees being physically present at the the ATM. Each employee would load their key-change info and enter their PIN. A combination of a master 3DES key and the employee's PIN would be used only inside the tamper-resistant module to decrypt the key change information. The key change info from the two employees would be XOR'd together to get the new modem 3DES key and a keyed cryptographic message authentication code (MAC) over the new modem 3DES key. Only if the new MAC checked out would the new modem 3DES key replace the old modem 3DES key. This way, no one employee ever had enough information to learn the new 3DES modem key, even if they somehow stole the master 3DES key used to encrypt the key change information. As I said, I may have had the details a bit wrong, but it's none the less very well thought out.
These days, I would hope ATMs use something similar to Kerberos tunneled over TLS with pinned certificates so that just breaking the public key algorithm or just stealing the Kerberos shared secret isn't sufficient to read the traffic or spoof communications. The bandwidth required for an ATM is so low that doubling the encryption overhead vs. TLS isn't a big deal.
Anyway, I'll try and dig up the paper on the attack on the poor authentication of the nyble-to-decimal mapping in the tamper-resistant chip. It was quite an interesting read. I'm pretty sure the paper was the main subject of a Slashdot article in the early 2000s.
The published attack [1] used a more sophisticated pattern of compromised decimalization tables, recovering the PIN in an average of 15 instead of 32 attempts. The naive pattern I described will work, but the published attack is more than twice as efficient.
Also, in the IBM 3624 + Offset PIN block algorithm, the offset is subtracted (digit by digit without carry/borrow) from the customer-entered PIN, rather than added. [2]
My memory has faded a bit in the 12 years since I read the paper.
I like Wells Fargo ATM machines, the thing you insert the card into is a transparent green glowing device and all the ATMS look the same and have touch screens. It's easier to tell if someone put a skimmer on them. I do not use non-Wells Fargo ATM machines. I only wish I had the option to type the password on the big touch screen and not the number pad.
I though that a big green thing just makes it easier for criminals to install a skimmer - they smash the original one off and add their fake version. Being big it has plenty o room for electronics.
I image searched "wells fargo atm" to find an example of the big green thing. I saw lots of older style machines, but the first link to the newer machine with a green thig was to an article about skimmers.
Not just can they remove (or overlay) the big green thing to add on their own skimmer... once the presence of the big green anti-skimming device is normalised, you can add big green skimmers to all the ATMs that don't have them yet: http://krebsonsecurity.com/2011/03/green-skimmers-skimming-g...
I designed those glowing green skimmers because they make inserting your card seem so much more inviting ... and everyone knows that green means go!
On a more serious note, when I saw the translucent skimmer in the article I immediately thought of the glowing rim around the credit card slot at my bank's (not Wells-Fargo) ATMs and realized I'd assume it was unadulterated if that skimmer also glowed.
Are customers really held accountable for ATM fraud? I have found credit card fraud to be handled well by my bank (USAA). The primary reason I use a credit card is because I am not sure how ATM/check card fraud is handled.
>I am not sure how ATM/check card fraud is handled.
In my personal experience, through a couple of phone calls. I can't imagine that credit card fraud could be any easier than the experience that I had with debit fraud.
1) Maximum liability is $50 if you report a loss or theft within 2 days of being aware of the loss or theft, $500 afterwards, until 60 days after you receive the statement with the disputed debits on it.
2) Whether or not your card was lost or stolen (or cloned), 60 days after you receive the statement with the disputed charges on it, your liability becomes unlimited.
summary: Report loss or theft within 2 days, check your statements for crap charges at least once every 2 months, and your maximum liability is $50.
Credit card fraud has a LOT of federally mandated protections, giving you a lengthy window of time in which to report it, capping the maximum amount you're liable for to $50 (I believe), etc.
Debit cards tend to have fewer protections, though they still have some. And because the money has already been taken out, you can be more detrimentally effected; the bank has to investigate and decide to give you your money back, basically, which takes time (and hopefully you have an uncompromised account if you need to pay bills or whathaveyou) whereas with credit cards the bank has to investigate and decide it's not actually fraudulent behavior and re-charge you (not sure how all that works though). Just plain inertia works in your favor when it comes to credit cards.
Debit cards have the same federally mandated protections.
In addition to the required liability rules, VISA and MasterCard both add on their own bits which reduce the liability to $0 under most circumstances, for credit and debit cards.
I could be wrong, but I'm pretty sure all US banks will take the hit and reimburse the customer for this kind of fraud. Even in cases where it's the customer's own mistakes or ignorance that leads to the card being compromised they'll do that; they better do it when it's their own (or another bank's) ATMs that have been rigged with spying equipment.
It's been tried (I was mildly involved in 2 such projects). Very hard to do within the constraints of a typical ATM.
One option that seemed to have promise was basically a coil around the card slot area that would detect signals from rogue electronics being placed anywhere on/around the cardslot.
So, there are these ATMs my bank in Germany uses and they have these new translucent green protrusions (dome shaped and weirdly organic) with a lock symbol on them. They also light up when you get your card back. Do you have any idea what that is?
I assume it’s some sort of defense mechanism against skimmers, but I have no idea whether that’s actually the case. (I mean, at first sight those weird protrusions seemed like skimmers to me because they definitely look like foreign objects. But they are not.)
They've been popping up over the UK as well, but the first few times I saw them they looked more like skimmers than security devices. As per the article, they don't really prevent skimming anyway.
“It [the skimmer] will immediately disrupt those wishing to operate via Russian ATMs: A majority of the BINs [Bank Identification Numbers] of Russian banks are hardwired into the chip; they are not processed.”
I wonder whats behind that move; are russian banks more dangerous to have as an enemy? Did they pay ransom money to the developer?
There was a law recently passed in Russia that criminalizes development, production and distribution of skimming devices. So the Russian guy selling those is probably trying to make it less likely that authorities will go after him.
Perhaps the maker/seller lives in Russia. Presumably Russian authorities would be more responsive to a complaint from a Russian bank than from a foreign bank.
Unfortunately, the United States is the last of the G-20 nations that has yet to transition to chip & PIN, which means most ATM cards issued in Europe have a magnetic stripe on them for backwards compatibility when customers travel to this country. Naturally, ATM hackers in Europe will ship the stolen card data over to thieves here in the U.S., who then can encode the stolen card data onto fresh (chipless) cards and pull cash out of the machines here and in Latin America.
According to the article, the reason they still have magnetic strips is so they can be used in the USA:
"Unfortunately, the United States is the last of the G-20 nations that has yet to transition to chip & PIN, which means most ATM cards issued in Europe have a magnetic stripe on them for backwards compatibility when customers travel to this country."
So, in the UK I very rarely use the magstripe on my card - 99.9% of transactions I do are chip & pin.
The chip on my card broke recently, and I found out that it doesn't even work in ATMs any more. Does that mean ATMs are only looking at the chip? If I blank my magstripe with a magnet, will I have made my card skim-proof while retaining ATM capabilities?
Chip ATMs will generally only look for the chip and therefore work with the stripe missing. (Many ATMs have two slots, one chip and one stripe) So in most of EU you should be perfectly fine if you remove or otherwise disable the magstripe on your card.
You'll be screwed though if you end up in a situation where your chip doesn't work and need to pay with the stripe fallback (pretty much all cards allow this).
Unfortunately, it doesn't even matter. If the reader detects that you have a chip card, you cannot use the magstripe even if your chip is faulty. The error you will get, after swiping the card, entering the amount and then pressing enter waiting for confirmation will be "PLEASE INSERT CARD". Quite vague but that's exactly what you get.
I do not know of any readers that won't let you bypass this. Many terminals have a button that literally says "bypass PIN" that'll let you use the stripe in case the chip fails.
Interesting. I was using my chip card in a country where chip cards were not really well known till last year. Surprisingly they already had chip-ready readers for easily two years before now so I have personally experienced the part where the cashier is completely baffled with the face of "I've never encountered this error before". Then, I have to operate the terminal, and insert my card (again) and press enter. I do not remember seeing any way to bypass it. I would have loved to do that because by this time it'd already be in my wallet and I cba to remove it again.
Many companies in the UK now don't allow you to pay with the stripe fallback. Even those that do, the employees often don't know how to put the till in that mode. Found this all out the hard way!
Annoyingly I only have the one card and I'm travelling to the US at the end of the month, otherwise I'd give this a go and report back!
I don't know about the UK, but in France highway toll booths only look at the magstripe (the automated booths, where you don't have to input a pin - the manned booths use chip & pin).
That's how I discovered that my card's magstripe was faulty (and being stuck in the automated booth on a busy highway is not a comfortable way to discover that).
Hard to tell if you're being facetious, but just in case...
1. If your cash gets stolen, it's goodbye cash. If your credit card gets stolen / cloned in the vast majority of cases you're not going to be liable for any of the charges.
2. The more cash you carry, the higher the risk to you, whereas a credit card has a relatively flat risk profile.
My cash has never been stolen. I have never been mugged.
I've had my card cancelled multiple times though due to fraud and now have credit monitoring.
My card is far more likely to be skimmed or be stolen/copied in a massive database like Target than for my cash to be stolen.
If credit cards are used for risk mitigation, they are failing for the vast majority of transactions. A $10K transaction? Sure. But for a $3 coffee? It's not worth the risk.
>My cash has never been stolen. I have never been mugged.
If you can figure out how to make this scalable to everyone, there will be no advantage to carrying plastic. I have my doubts that this is possible.
>My card is far more likely to be skimmed or be stolen/copied in a massive database like Target than for my cash to be stolen.
Mine was, at Target, my account was drained of about $2K, and it cost me about six phone calls over two days. The only lingering effect was an example of how trivial an experience with false charges on your debit is, which comes in handy during my rants about how many politicians, news outlets, and credit card marketers scream about card number theft in order to grab eyeballs and push agendas.
I'm not a big advocate of slutting your card around, but that's because I don't feel like broadcasting every single minor purchase I make throughout the day, and because it's slower and more annoying (to you and everyone around you) than having your cash ready before you get to the register. I'm embarrassed if by some lapse of routine I get to the checkout and have to use a card for a $10 purchase, and the first thing I do is apologize.
I haven't ever been mugged, either. But that guy will probably only clean me out once in our lifetimes. My spouse has taken more cash from me than I care to admit.
Be warned, single folks.
You won't just lose cash to faceless thieves in dark alleyways. It will disappear into birthday cards, pizza deliverator tips, bribes to children, and other countless, petty, unnecessary, and off-budget expenses. That is where the card advantage comes in. It has your name on it, and you will more easily notice if someone uses it without your consent.
It's hardly worth worrying about strangers stealing your money when everyone in your family has a thumb in your wallet 24 hours a day. The additional friction in the transaction process for cards is actually an advantage there. If they made a payments processing system that somehow involved the buyer carrying around a 10kg block of stone everywhere, I'd sign up for that in an instant. I don't care if it makes it more inconvenient for me to spend money, just so long as it is much worse for everyone else.
$10K is an unreasonable amount of money to cite here. Heck, how many of us even have credit limits that high? Check or wire transfer is what I've used for such sums in times past.
Also, I don't know where you live, but in most of the US (by state and population), we're allowed to carry concealed handguns after jumping through some moderate hoops, and in the places I've lived like this, Virginia and Missouri, muggings are also not-coincidentally much less frequent (that was particularly clear when I lived in Northern Virginia with D.C. and Maryland a subway trip away).
I routinely carry ~$450 and a .45, more if needed, and just don't worry about credit card compromise aside from uses on the net.
ATM compromise is another story, of course; the one I use with a bank account with "a lot" of money is in a Wal-Mart open 24x7 that's part of a bank branch open during normal business hours, there are so many easier targets I'd be really surprised if it got hacked. The other one I use never has more than $1,000 in the account. For that matter, I don't let the first one get much above $2,500 before transferring money out of it.
The gun, I should note, is to protect my life; the mugging/robbery angle only comes in because by definition it requires a credible threat of violence, the mugger isn't going to know how much money I'm carrying.
Even if Bitcoin never gains mass adoption, I really like the idea of being able to encode a consumable transaction that both authorizes the transfer and encodes the transfer amount. I can imagine a similar payment system (NFC payment with phones, perhaps?) that doesn't disclose arbitrary access to my account, but instead allows a transaction to be proposed, I accept the transaction on my trusted hardware (phone), and the transaction authorization with amount is then sent up the wire.
This seems like it should be trivially accomplishable via mutual asymmetric signing. Vendor generates a request for money and signs it, sends it to my phone. My phone validates the chain-of-trust, presents me with the transaction request, and I can authorize it. If I authorize it, then the request is counter-signed with my private key, and the signed authorization is sent off to the payment processor, who has pubkeys for the vendor and myself and can validate the request and process it.
Even if you could capture the transaction-in-transit, you wouldn't be able to compromise it, since you would need signing keys for both the vendor and the customer in order to forge the transaction, or to create new transactions with the signed account information.
Is there any reason this wouldn't work?