FTA: A fraudulent chip can listen for that query and pre-empt the real chip with its own answer: a “yes” signal regardless of whatever random PIN the fraudster has entered. “The attacker intercepts the PIN query and replies that it’s correct, whatever the code is,”
Wait, what? How is that the protocol? There's no two way validation at all? The chip just says "yes"?!
Can anyone with knowledge of details confirm? This seems isomorphic to my ears with "the PIN is just security theater".
In this case the fault lies with the bank. The chip can authenticate the transaction and also optionally cryptographically sign it as verified. The bank should check the last step but most/some don't because a lot of the first wave of terminals that went out didn't have full/proper implementation, therefore they only relied on the chip saying "yeah it looks good", instead of "yeah it looks good, btw here is my signature on this transaction which you can pass to the bank to verify that it really is kosher".
So it is more an issue of the bank accepting partially verified transactions on large dollar amounts.
The card does sign the transaction, even without the PIN. As I understand it the chip believes that it's a non-PIN transaction, whilst the bank and merchant think it's a PIN transaction and that the PIN had been verified by the card, because the standard apparently didn't have any way to ensure that the chip and everyone else agreed on whether a PIN had been used. It's a really broken protocol.
The best part? In the UK, the cardholder is liable for the transactions because the bank thinks that the PIN was used.
This doesn't cover the issue, because the issuers assert that the customer has not been victim of a fraud - they claim that the customer made the transaction.
You're talking about something different to makomk, but again, not true, you're repeating another urban myth. It's rare for banks to do that, save for a handful of cases. Occasionally they contest it, but generally when they really think the customer is trying to pull a fast one.
If you believe you have a case, talk to the citizens advice bureau, they will help you. Otherwise stop trying to alarm people with a bunch of nonsense.
It is quite simple - the link you provide states that customers are not responsible for fraud, but that does not help if the issuer claims either that the cardholder authorized the transaction or was careless in protecting the PIN (that they can do this is also covered in your link.) If you were to read the link I provided, you would find cases in which issuers denied restitution for fraud on these grounds, even though they could not possibly have evidence that this happened (and there is plenty of circumstantial evidence that it didn’t). The reason they don’t have the evidence is that they chose to open an exploitable hole in their own protocol.
At least at the time of the article, the law allowed the issuers to act as if the protocol was as secure as it was intended to be, instead of how it actually was. If things have changed since then, I would be grateful if you could present evidence that actually shows that to be so.
Instead of being annoyed that I dare mention these inconvenient issues, you should spare your ire for the idiots who created this completely avoidable problem and who tried to brush it under the rug.
Edit: It is telling that the issuers didn't take this seriously until a case involving unissued cards arose - a case that cannot be blamed on the customer.
I think it comes down to unreliable communications... In the case that your POS terminal isn't able to connect upstream, do you completely decline the transaction? Businesses used to accept checks from most people without issue.. these transactions took several days.. yes there was some fraud, but it was minimal.
In this case it may be part of the protocol to not confirm if there is a communication problem, and that risk may be acceptable. It seems to me a test of is "0000" valid and is "9999" valid and at least one of the two rejected before the user is allowed to enter their pin would be reasonable here.
There's a lot to be said for user in/convenience in decision making.
Well... in principle the device is supposed to be able to provide an authenticated public key that gets signed by some upstream bank/authority, right? It's the same principle as TLS -- you can trust the site because they have a signed cert.
And this part apparently was unbroken, because the attackers left the initial chip in place and just proxied the PIN response.
So... if you have that, why on earth didn't the protocol specify a two-way kind of thing that allows the already-authenticated card device to sign and return a "I validated that PIN" message, which wouldn't be MitMable?
I'm just stunned that somehow they went through the trouble of putting a !@#!?! computer into every credit card capable of elaborate crypto and then blew this really obvious hole in the middle of it...
Offline authentication was included for reasons you state but banks and terminals are supposed to limit it to small transactions, i.e buying a cup of coffee. For larger ones you wait and retry for online transaction before you let the customer walk out with that shiny new 2K MBP.
The uncoverers of the original exploit made that point in their paper: the primary goal of the industry is not fraud reduction but liability shift (from them, on to the customers and/or merchants.)
The term "liability shift" was not invented by the paper's authors; it is the industry's own term. Here we can read MasterCard’s Carolyn Balfany openly using it:
In a way it is isn't though ;-) They are insured against it, they will refund the money back and their risk analysis probably indicates that loosing all that money to fraud is cheaper than waiting and properly deploying and testing the solution.
I imagine just like in the government security world, a lot of bank security is "paper" security (the way I call it). It is a set of formalities, certifications, rubber stamps, audits, other other red tape that in the end all check off and yet the system is still not secure.
> They are insured against it, they will refund the money back and their risk analysis probably indicates that loosing all that money to fraud is cheaper than waiting and properly deploying and testing the solution.
This. Some behaviour i encountered by acquiring banks when working on backend software for interfacing with them:
- Authorising a transaction when they failed to contact the issuing bank, because the value of the transaction is lower than a certain threshold.
- Overloading fields in the APACS spec to get around 3D Secure / Verified By Visa, i.e. passing the cardholder straight through the process and then marking it as bypassed (a poorly implemented one factor auth becomes a "eh, this looks ok to me" zero factor auth by the issuing bank).
- Being sat in meetings where the max value of contactless transactions was explicitly stated as being that of a level that any contactless chargebacks were not defended because they're so low.
- Asking me to send PANs in clear text, split over two e-mails (no, i didn't).
Backend backing systems are horrible. Nobody really wants to work on them and they have so much legacy cruft that they're like concrete, so any change takes forever and carries massive amounts of dev/test/risk.
Even the seemingly sensible ones have major WTF's - One of the integrations i did at my previous job was interfacing to Amex's endpoint for online authorisations. HTTPS posts over the web, seems sensible enough right compared to APACS-70 over X.25? No, the ISO-8859-1 POST parameter values needed to be encoded as EBCDIC and then converted to hex (IIRC) before being sent.
Banks playing the chargeback cost balancing game is all well and good for them, but if you're living on the edge and experience fraud then this can lead to all sorts of financial problems.
Having had to re-implement a few legacy systems in newer code for nothing nearly as complex or with as much risk as what you're referring to, I can't imagine any dev not screaming and running for the hills if asked to do this. The chance it will work correctly without bugs early on is close to nil, and the downside for bugs when dealing with financial systems makes the risk analysis being as large as it is, it's pretty clear cut.
I keep telling myself one of these days I'll get to reimplement some system that has good test cases, but I know that will never happen. Any system that is designed well enough to have good tests doesn't really require rewrites in the vast majority of cases.
Sorry. I'm not sure I understand your comment. Are you saying it is the bank's fault or it isn't?
EDIT: Thanks kbenson for clarification.
The banks did lobby hard to be able to shift the liability to customer when PIN is used so do they do care less and do care more about approved xactions/second than anything else.
There's nothing wrong with the smart card system and the crypto protocols developed around them. The problem is that the applications that have been bodged onto the smart card since it was invented (in the 70s) have all been garbage. The banks and payment networks just aren't qualified to implement these things, and they don't have any reason to because they've managed to externalize the cost of fraud onto the individual customers and the merchants.
Sorry, but in this case we have a POS terminal accepting a fraudulent PIN because the card device, which could have cryptographically signed that validation, did not because the protocol didn't require it.
That's a fundamentally broken protocol. The hardware capability was there to do this securely, the software design messed up.
Unless what you're saying is that the PIN itself is an "application", in which case your point seems sorta specious. OK, so the application has a broken protocol which invalidates the whole idea of "Chip & PIN" authentication.
I think we agree. This is a broken application, built upon a sound technology. The card is perfectly capable of signing the transaction, and will only do so if the correct PIN is entered (smart cards can also be programmed to disable themselves after a number of incorrect PIN attempts). However the banks either don't know how to, or do not want to, run a public-key cryptosystem, so they don't ask the card to sign.
> According to their paper, at least some chip-and-PIN card readers now send a command to verify a PIN before the user even enters it to check if the card responds with a spoofed “verified” signal.
Trivial to detect and control, e.g. have a discrete button on the card that you press exactly when you enter your pin that enables the spoofed response. There are probably more sophisticated methods.
Hopefully they've done more than just that though. Hopefully.
Why not just have it reply with a "verified" signal when you enter a predefined PIN? That way you're mimicking the card's original behavior with a different PIN code.
I don't like their hack, but the card reader could issue multiple attempts at the password verification in succession, with only one of them randomly being the one typed in.
On the bright side, this only affects offline PIN verification. Cards which are configured to require online PIN verification should be more secure. They will send a (triple DES encrypted) PIN block to the terminal, which sends it to the issuer, which decrypts and verifies it.
It's complicated. U.S. EMV credit is (virtually) all chip and signature. Debit is split between PIN and signature. US Debit Common AID is Online PIN, but you can legally do PIN bypass ("no cvm") or even fall back (or have user select) the card brand's application on the card (instead of the US Debit Common AID), in which case for Visa it will be signature and for Mastercard it will be online PIN. Politics and posturing.
I've only ever seen one merchant (Target) that requires the chip. Every other store is still using the mag stripe. In fact, while travelling this weekend, I used my card in a dozen new stores. But none used the chip.
I share your amazement. That said, apparently the functional security was "how could you put a system physically between the card and the reader?" which seems silly. The chip is capable of signing the response with the secret key of the card, why wouldn't it do that?
It's fucking ridiculous, especially since this was already commonplace with mobile phone SIM cards when they said it, but it allowed UK banks to force their customers to accept potentially-fraudulent payments by claiming that their PIN must have been used. (Otherwise they'd have had to eat the loss and no bank wants to do that.)
Here's a good write-up of SDA (very vulnerable to the yes-card) and DDA (not vulnerable to the yes-card if authenticated online, but still vulnerable if authenticated offline due to a bad protocol):
This is technically old news - as the article states, it has since been resolved. Edit: I guess they're shedding new light on how they performed the hack.
Another thing, in context of USA, is that the authentication being done isn't much of a vulnerability as this only applies to offline chip transactions. In the USA (I believe) and here in Canada, all transactions are online, which means the pin will be rejected by your financial institute's back end systems in these scenarios.
Edit: Many Canadian financial institutes still use the weakest data authentication (SDA) because all transactions go online - spoofing a card PIN verification response doesn't fool the back-end system. Visa and Mastercard both have mandates to have newly issued cards be provisioned on chips with CDA (I believe, could be DDA which would still be susceptible to this attack).
Edit 2: When I say "offline", I mean at a point of sale machine - the POS does not reach out to the payment network to perform an "online" transaction where the PIN and card are validated by the back-end systems.
Edit 3: The article doesn't give EMVCo any credit for actually solving the issue before any real world hack was known to exist.
I'm not sure I'd describe it as "resolved". They've deployed a couple of countermeasures that take advantage of bugs in this particular implementation of the exploit (it doesn't detect parity errors in the card-to-reader transmissions and replies yes to the PIN authentication command even if it's sent at the wrong time). Those bugs can easily be fixed, and the first trick is probably very familiar to most folks acquainted with Funcards.
In CDA, the responses are encrypted by the card, which means a they can no longer be spoofed.
The only lingering possibility of this type of attack occurring is in regions where offline transactions are still permitted, and if you can find a terminal which still does not have CDA capabilities or if you have a card which doesn't have CDA. Totally possible, but the opportunities are diminishing rapidly as the issued has been RESOLVED.
The CDA cards have this advantage over the DDA cards, in that the message signed by the ICC which includes an additional Application Cryptogram (AC), which is used to protect and validate the specific transaction messages (amount, time, etc) generated during the transaction. The ICC uses the AC Session Keys (derived from the ICC AC Master Key, shared only between the ICC and the card issuer) to place this MAC on the transaction details.
Well, that explains why the implementation seems brain-dead, it's because they wanted offline transactions. I'm not sure why they thought offline transactions would be a good idea given the near impossibility to do it securely (given enough incentive someone will completely reverse-engineer the chip), but the whole situation seems fairly ridiculous.
Well, this article only applies to point of sale transactions, so it is either online or offline.
Offline transaction, meaning "authorized within the acquirer domain (at acceptance device, or at the acquirer host)". In other words, the transaction does not hit the issuer's system.
Edit: Even in an online transaction, offline pin is still performed, but the online would fail.
That's amazing. They were able to MITM the chip-and-pin chip by taking it out and attaching it to another hobbyist chip that's capable of spoofing the response, and the whole thing when put back in the card was only a slight bulge bigger than the original.
They say nearly 600k Euros were charged, but given the sophistication of the attack, I wouldn't be surprised if we hear later that it was in use at different locations as well, and we just aren't hearing about it because they haven't caught those people yet. They only caught these ones because they kept going back to the same locations.
Don't keep purchasing at the same merchants; that's like Carder 101!
Regardless, this whole "ask the card if the PIN was right" protocol is just dumb. Surely they could have e.g. had the card sign a challenge in a way it could only do if given the right PIN? That gets slightly more complicated when revoking old PINs or issuing new ones, but it would still be possible. For all we heard about the wonders of C'n'P, this seems to fall short. If you're going to the expense of chipping all those cards and replacing all those terminals, at least get the software right.
> Don't keep purchasing at the same merchants; that's like Carder 101!
I know! It's the stupid details and extra people they bring in that seems to eventually get these rings caught.
> Surely they could have e.g. had the card sign a challenge in a way it could only do if given the right PIN?
Well, the article seemed to imply the chip put in the CC was from a different card, so maybe they know the pin for that chip, and the MITM is really about the authentication of the chip in the wrong card? Later they do seem to imply the fix was to authenticate the chip, but I'm not sure without reading the original paper if that's an over-simplification of what the fix was, and maybe it's better authentication of the chip.
But the chip is the only part of the communication that knows the PIN. (the protocol does not need a network connection to the bank).
The chips could be made to sign their response with a bank's private key and the terminal checks this against a known list of banks. But that would be cumbersome (lots of banks, lots of keys), the terminals would need to be constantly updated to keep the key list up to date, and it all falls apart when a key is extracted out of the chip.
Now if the protocol required a network connection to the bank, you could speak to the bank to validate a PIN instead of talking to the chip at all.
They signed transaction would indeed fix this issue but it was ignored by the bank (to their detriment) for other reasons. The implementation is actually pretty decent.
It doesn't require key management the way you describe it.
Banks use a derived key schemes for EMV transactions. In a way you can think of it as PKI. In any event, the actual verification doesn't happen on the terminal. The terminal is supposed to take the signed transaction and pass it up through the network where it will end up with the originating bank who will say "Yes, we accept it", or "No, we don't accept this charge". This is something that happens today but it is the CC# and the CVV that get passed. If they are revealed/stolen you're screwed.
Merchants are constantly punished for all sorts of things, why not punish them (e.g. with a higher rate or more cumbersome chargeback) when they don't have network connections? Then you could have two slightly different protocols and the secure one would actually be somewhat secure.
Designing a protocol for the offline case sounds like a game of Whack-a-Mole and also like something we've all been advised against. However, ISTM that the attacks against a better offline protocol that included e.g. zero-knowledge proofs would be much more difficult than racing to say "yes".
The chip would not have the bank's private key - that'd be bad for the reason you mentioned. It'd have a unique private key signed by the bank. I.e. exactly how certificate systems work. (Still would have issues of cert management if the bank's key or system master keys are lost.)
The chip does have a unique private key signed by the bank, and the terminal can use that to verify that it's a genuine bank-issued chip - that's why the fraudsters needed to embed genuine chips from valid bank cards in their hacked cards. Unfortunately, due to banking industry stupidity that signed message doesn't tell the terminal whether the PIN was verified or not. It has to rely totally on an unsigned, unprotected message that can be MITMed to verify the PIN.
Actually, the card number is signed by issuer's certificate for exactly this reason. The same signed datastructure can also contain card's own public key(s) when needed by the used EMV implementation. There can be signing key that is used when card generates signed data files internally (I'll admit that I have no idea what that is good for) and second RSA encryption public key that is used for some card holder authentication mechanisms (eg. for encrypting PIN sent over cable from PIN pad to the actual terminal).
One important point in this is that nothing from this PKI mechanism is involved when the card generates the final transaction signature (called "Transaction Certificate" by EMV). Standard does not specify mandatory algorithm for that and also such algorithm necessarily has to be some kind of truncated symmetric MAC, as the resulting value has to fit into 32 bits (and ideally contain only BCD nibbles). There are some recommendations about what algorithms can be used for that in the standard also with recommendations about key management for the symmetric part.
The MitM essentially has no idea about EMV whatsoever and only traps one command and returns fixed OK response. Due to way how the card holder verification process works this results in terminal thinking that the entered pin was correct, while card thinks that no PIN was required for transaction (the idea there is that terminal and card calculates what verification methods they deem sufficient depending on various parameters of transaction and their internal state). While these two states are obviously different, they are encoded by same binary pattern in transaction flags (there is bit that means "verification failed" and nothing that encodes whether the verification was attempted or even what method was selected) and thus the terminal's view of transaction matches the signature generated by card.
Interesting point in this is that the card usually allows the transaction even without the verification succeeding. Idea behind this is that the transaction can be downgraded to card+signature by the terminal for various reasons (standard specifies list of some reason codes that contains reasonable things like "hardware problem with keyboard" but also "cardholder does not know the PIN").
In it's entirety the protocol is designed not to be absolutely secure, but to be efficient, reliable and provide usable audit trail for later review that is usable to unequivocally assign blame for disputed transactions. Essentially only problems with EMV from security standpoint come from complexity that is motivated by the reliability and backward compatibility requirements.
By the way there are certainly better workarounds for this vulnerability that testing whether card with no selected application responds to pin verification command that can be implemented on the card side, but they reduce reliability (eg. disallowing offline PIN verification, disallowing transactions without cardholder verification...). On the other hand these workarounds really solve the issue, while testing from protocol peculiarities by the terminal can be worked around by the attacker by implementing better MitM chip that tracks state of the original chip.
Arm's race between phone companies and phreakers who emulated payphone EPROM chipcards that involved things like the phone measuring various impedances of the card pins and finally ended with deprecating the whole thing (either by migrating to true smartcards or by simply discontinuing the cards, or even payphones) should be enough to convince anyone that authenticating devices by means of implementation details only slows the attacker down.
It's a clever hack, but shouldn't people have thought of this before they developed the whole protocol? How can any random chip answer a "true" response to the pin request? Shouldn't it have some sort of authorization built-in? Maybe public / private key with a bunch of implicitly trusted public keys?
As I say that, I guess this relies on having a network connection which cannot be assumed when you're developing a POS. Hmm.
Yeah, it'd be a huge complication to maintain and update the keys across all the terminals, many of which are not network attached. Plus an attacker could extract a key from the chip (probably hard, due to anti-tampering technology, but not impossible)
Although I'm pretty sure when you are talking about validating a credit card, a network connection is a given. Otherwise how do you authorize or deny the purchase?
The reverse is more likely in the US. There's plenty of old legacy POS systems/registers, which have a card reader that's with it, attached or not. The only way I've ever seen a card run without a network (whether it be an existing network or an integrated modem and phone line), is when there's a power outage and someone busts out one of the old carbon copy manual card machines, where they take an impression of the card. Those may not even be accepted anymore, since they don't deal with CVV numbers and some cards don't even have embossed numbers anymore.
Makes me wonder if carder community has systems to protect from and/or punish idiots with poor OPSEC. It takes only one such idiot to ruin a perfectly good attack vector.
My understanding is that the online forums for this work quite a bit on reputation (for sellers at least). I can imagine people that use these hacks remove themselves from the ecosystem when they get caught. I also imagine the selling of this hack, if it happened, was probably brokered as a unique sale where the seller would not resell the hack, similar to how I imagine a lot of high-end zero-day exploits are sold. This, of course, is where the seller reputation would come into play.
I'm dealing with development on some of this right now for US based POS customers and so far everything I've been told is that the US isn't even going to attempt to utilize the PIN entry capabilities, so we're still using signature validation in case of fraud. I'm not sure how this is any better than MSRs. The whole spoofing PIN validation thing doesn't even come into play because it's not even going to be checked.
I've left the back of my credit-card unsigned for 2+ years, and in that entire time, and north of 500+ transactions with a signature, I've been asked for identification less than 10 times.
I wonder if there has been a single person challenged on a signature in the last 5+ years with a credit card if they even made the slightest attempt to sign in a fashion similar to what's on the back of the card?
retailers aren't supposed to accept unsigned cards though. And they can even force you to sign the card before they accept it. They are also not allowed to ask for Identification if your signature matches the back of the card (customer can complain to Visa/MC etc if they are asked). This is why the 'SEE ID' stuff is not really recommended. IT all comes back to fraud prevention though, and the point of the signature is not to protect you, but to protect the merchant in case you file a charge-back saying that you didn't actually authorize the purchase.
None of my cards are signed and the merchant never checks the back of the card or asks for ID after signing. In a lot of cases AMEX doesn't even require signatures for purchases.
As a consumer that uses credit cards, I don't think of this as much of a problem. All the credit cards I've used have 0 liability for fraud. It's a nuisance if my card is used fraudulently because I'll be issued a new card with a new card number, but disputing and getting a fraudulent charge removed has never been difficult. In fact, in a lot of cases, the bank is proactive about trying to identify those up front and contacts me.
If someone steals your chip+pin card and your pin you will probably be considered negligent by the bank. If they steal your credit card and fake your signature you will probably have zero liability.
Depending on how the liability is defined, I might consider purposefully burning out my chip-and-pin so it falls back to signature authorization. I'm not interested in allowing the credit industry pulling a bait-and-switch on me by promising a new secure system that also shifts liability to me, when the new system is horribly insecure. Luckily, since I live in the US, it looks like they are requiring online auth, so I just need to make sure this includes online pin auth.
Tip from my father, who switched from cash to almost all credit cards at POS: write "Photo ID Req." in permanent marker in the signature area. And, hey, one time when he sent me in to BBQ joint for some takeout with his card the cashier did look, but I was able to show my ID and make a plausible case for being his eldest son ^_^.
The lesson from your story is that "See ID" doesn't work. Indeed, these are the merchant guidelines from Visa:
> In the US, some customers write “See ID” or “Ask for ID” in the signature panel,
thinking that this is a deterrent against fraud or forgery; that is, if their signature
is not on the card, a fraudster will not be able to forge it. In reality, criminals
often don’t take the time to practice signatures. They use cards as quickly as possible after a theft and prior to the accounts being blocked. They are actually counting on you not to look at the back of the card and compare signatures; they may even have access to counterfeit identification with a signature in their own handwriting. In this situation, follow recommended steps listed above under Unsigned Cards.
It makes even more sense given this guideline, from the same handbook:
> When should you ask a cardholder for an official government ID? [M]erchants cannot make an ID a condition of acceptance. Therefore, merchants cannot as part of their regular
card acceptance procedures refuse to complete a purchase transaction because a cardholder refuses to provide ID.
I struggle to understand the security rationale behind that advice - what is more likely - Thief spends 60-90 seconds practicing the signature on the card, or Thief acquires government ID that matches name on the card.
Regardless - any time I'm making a large purchase (even with a signed card), you can be certain they scrutinize my government ID - I've never seen a retailer who has ever paid attention to the rules that stipulate you cannot make an ID a condition of acceptance.
If it were a meaningful amount of money, it's more likely the criminal would clone the card onto one with their own name on it.
It's purely a branding rationale. For some people, being "grilled like a potential criminal" by a checker would be enough for them to stop using the card or not shop at that store. Either way, it's a negative association between that merchant and that card for that kind of customer. Card networks have fantastic anti-fraud algorithms that are way more reliable than a bored teen checker.
Whenever a checker takes care to examine my credit card I make a point of thanking them for their diligence, as long as its within reason they're doing everyone a favor but the criminals.
I worked retail thru high school and college. Although some people were thankful I'd checked their ID, the majority were annoyed. N=1 and all that, but I imagine this was well-studied by the credit card companies - they're not in the business of losing money.
Problem is the card is not valid unless signed. An attentive merchant will insist on the card being signed. This has only happened to me a couple of times but still.
In California, Singapore, British Columbia - I've never had any problem with having an unsigned card, other than being asked for ID a handful of times.
I know people who do that, and they tell me that most merchants don't actually ask for ID. Which is surprising, since the merchant bears the pain in the case of fraud.
Except the person working the cash register isn't the merchant -- they are an employee, who isn't really worried about their job because they've only been there for a few months, and replaced a previous employee that was there for less than a year.
I guess in 99% of cases they see the transaction is not a fraud.
This is, by the way, the reason software development is hard - if you were to approach this problem the way typical software requirements are defined, you'd only piss the clerks off. In real life, people dynamically adjust their compliance with procedures to run the common case with minimum effort and improvise if something unexpected happens.
Considering at this point the vast majority of my CC usage never requires the card leave my possession, I can't imagine anything the card says being a major impediment.
The chip+signature card is pretty annoying when traveling. While visiting New Zealand (where local cards are all chip+PIN) with a U.S. chip+signature card, the majority of clerks actually request to see the card and visually inspect the signature. Also, I can’t use the cheapest petrol stations because they all require PIN.
It's much better than MSRs because online transactions aren't vulnerable to skimming / replay. This eliminates the ability to clone cards using an ATM skimmer or over-the-wire stolen track data, which by my understanding is one of the primary identity theft attacks against US cards.
This "yes-card" attack relied on having physically stolen the original card (not skimmed) and only worked against offline transactions using SDA, which, as far as I know, aren't supposed to happen in the US.
As long as merchants continue to accept magstripes the security benefit isn't really there, but, in the ideal world where they accept only chip-and-sig, it's still much more secure than MSR even without the added protection of a PIN.
It worked against transactions that use offline PIN verification, which happen to be a lot more common than offline transactions. Some security researchers in the UK demonstrated the same attack using online transactions with offline PIN verification, which was standard for everything except ATM transactions at the time.
It's possible to encode a card with a specific number, so as long as you know the number and cvv, you could conceivably create your own card, since you are bypassing the chip-and-pin system anyway.
Going for signature instead of pin is BRILLIANT ... for the banks, because any fraud is charged out of merchants pocket - he didnt verify card owner identity at the time of the transaction. Good luck asking every single customer for ID at the supermarket checkout.
Whole point of PIN was to move responsibility over to VISA and banks. This is why they kept claiming every transaction with chip&pin card is 100% valid and there is no chance of fraud.
Reading this article gave me LOL. Their super fraud prevention is asking the card for multiple pin verification before client enters real PIN, so if the card validates random bad PINs reader can flag fraud. This will stop scammers for ... one week? until they start programming shims to only validate one particular PIN making the card act like the real one.
it's just an odd situation, the Chip cards have to remain inserted while the entire transactions completes, but the signature is on the card.. how do you verify until after the fact?
Do banks in the US transmit the signature to the bank when you sign on an electronic pad? Can the signature be retrieved later on if you query a transaction?
My understanding is yes, but they are never looked at unless requested. Planet money did a story on this last year[1], and recently re-ran it. The money quote from the article was when asking the expert if there was any consequence to signing some random picture as your signature was something along the lines of "No, except it may be somewhat awkward if you had to verify it in a trial for some reason."
Your question doesn't make much sense to me, but with what I've worked with _retailers_ do not send the electronic signature to the bank. It is for the retailers documents (ie to print on the receipt, or to store in a database with the transaction). In the case of a dispute they would then send the information.
Noteworthy: For the Cambridge researchers, the French attack is an “I-told-you-so” moment. Five years ago, EMVCo and the UK Cards Association both dismissed their attack as improbable or impossible.
no, afaik this article talks about super thin shim glued on top of real chip on real card
but I guess you could use cards you linked IF you drill them, cut real chip from real card, place it in drilled hole, cover hole so its not visible, print card over with authentic looking color scheme/logo, stamp number, sounds like a lot of work
Let's not lose sight of one thing -- this doesn't make chip-and-pin less secure than swipe-and-sign, it just makes it no more secure, in the worst case.
It's not just about security though, it's also about liability. Chip-and-pin may have different liability rules than have been established for signatures. If so, then a hacked chip-and-pin system may be no less secure for the consumer, but it may be much more costly.
I was under the impression that the card created a cryptographic signature on the transaction, and the card had to receive the correct pin before it would sign it. Which is why you have to leave the card in the reader until the total is completed. Is this really not the case? Or does the card still cryptographically sign the transaction, but doesn't process the PIN first (other than answering valid/invalid)?
> "They also note that other protections have been added to the system at the network level, which they decline to detail for fear of tipping off criminals."
Security by obscurity. That's always a good plan. I'm sure that folks who went through all this trouble to design this hack wouldn't ever be able to find that information. </sarcasm>
pretty lame if the card can just say "yes" no matter what PIN is entered.
Away from being a proprietary tech, I'm not sure why fingerprinting the magnetic stripe never took off. It seems so much simpler, and if you cannot rearrange iron at the molecular level impossible to replicate.
Probably it's lack of infrastructure buy-in. And personally, I find the misuse of the word biometric in the white paper off-putting, along with the lack of detail on the basis for the technique. The fingerprint is somehow related to the magnetic particle distribution--how stable is it against weak magnetic fields, or against heat?
If you really can reliably get magnetic signatures, it would be really hard to clone cards.
Edit: the particles won't really change, but their magnetic states feasibly could
Wait, what? How is that the protocol? There's no two way validation at all? The chip just says "yes"?!
Can anyone with knowledge of details confirm? This seems isomorphic to my ears with "the PIN is just security theater".