chip & pin - could this happen?

although i find chip and pin to be convenient, is the following possible?

- the chip and pin terminal in the shop is modified to record the pin number

- the card number and other essential details are captured so the card can be cloned

- some crook then spends money using the cloned card and your bank says you failed to keep the pin number secret

or are there some technical details which make this impossible? e.g. the chip on the card stores the card number in an encrypted form

Reply to
Scott2k5
Loading thread data ...

Bitstring , from the wonderful person Scott2k5 said

Afaik no crooks have technology to clone the Chip yet. They can clone the magstripe just dandy, so it might work if they can find a machine that'll work based on magstripe alone (which is still 99% of the machines on the planet).

Reply to
GSV Three Minds in a Can

Yes, but only 1% of the machines in the country. :-)

Reply to
Ronald Raygun

Actually its about 10% in the country, but 99%+ of the machines on the planet.

Reply to
john boyle

I know I was thinking about this - major major flaw

Anyone clever with electronics could put a key logger in one of those things

the hard part would be copying the CHIP.

Or they could just knock you out and take your card once they have your pin.

Reply to
Chris.Holland16

As I understand it at no point is the pin read from the card. The card is just "asked" is this number is correct and expects a YES/NO in response. Begs the question is there a way of faking a YES response of course.

You could record the pin somehow when the person enters it but at the moment they claim no one is able to make duplicate cards yet anyway. But it's only a matter of time before they can although I suspect it's a few years away.

Reply to
Silver

At 13:41:22 on 11/02/2006, Scott2k5 delighted uk.finance by announcing:

Yes. Although tampering should be quite evident, there's nothing to stop someone making a dummy terminal

Only the mag stripe could be cloned easily; without the bank's secret key you could not clone the chip

And then you ask them to prove that, especially since the transaction was performed using the mag stripe and not the chip (so the merchant becomes liable).

Reply to
Alex

If I were designing C&P, I'd have the terminal send the chip on the card the pin requiring validation and a timestamp. If the PIN was valid, I'd then have the chip reply after a random delay of upto a minute or so (fixed and defined in the specification, naturally) with a the timestamp and 'yes', and have that reply signed with private key (i.e. embedded in the chip, inaccessible) whose corresponding public key (also on the chip, but retrievable by the terminal) is signed with the issuing bank's key. If the PIN was invalid, no reply will be sent from the chip. The random delay would mean that an attacker attempting to brute force the pin would have to wait the maximum reply time for every attempt - i.e. 10000 minutes (just under 7 days) for a standard four digit PIN (should be long enough for the customer to notice his card missing, report it, and have it cancelled). I'd make that random delay longer if I thought it would be acceptable to customers in a busy supermarket.

That should make the chips unforgeable without either a) knowing the Bank's private key or b) physically analysing the chip, probably destroying it in the process. However, there are all sorts of attacks that have been discovered against and used to break systems like this - for instance, relying on minute variations in time taken to perform certain operations or precisely measuring the amount of power that is drawn throughout an operation.

Security is always a race between you and the attackers. Your only hope is to notice when the attackers are getting close to cracking your system, and change the rules before they're successful.

Best Regards, Alex.

Reply to
Alex Butcher

At 12:15:34 on 12/02/2006, Alex Butcher delighted uk.finance by announcing:

And you'd end up having wasted all your efforts. Who do you think is going to be content waiting a minute or so for every transaction to be authorised?

So, the way it currently works then.

Then how does the terminal know that the chip got its request?

What? You only get 3 attempts at a PIN. And the current specifications are for an average of 1 PIN entry every 30 seconds (one implementation being the token bucket method).

Reply to
Alex

The cloned card (magstrip) can be used with the genuine PIN in a cash machine!!!!!!

Why take a chance? Opt for Chip & Signature, especially with your credit cards:

The Consumers Association:

"Our biggest concern is when banks refuse to look at the issue because they say if the pin was correct it's not fraud," says Naomi Newman, senior researcher at Which? "That's going against the Banking Code and the Consumer Credit Act, under which the onus is on them to prove gross negligence. Instead we're hearing about them saying that if the pin was known there's no need to regard it as fraud."

CARD users unable to remember different card numbers or who are worried about security, can ask their bank or card issuer for a chip and signature card, so they can continue to sign for purchases.

Apacs says it is not necessary to be disabled or to suffer from an impairment such as short-term memory loss to be entitled to ask for an alternative card. More than 100,000 new chip and signature cards have already been issued.

Reply to
jjamies

At 22:18:56 on 12/02/2006, snipped-for-privacy@tiscali.co.uk delighted uk.finance by announcing:

Until the cash machines are updated!!!!!!!#'*&£$^%!!??!!?!!

Bollocks to that. I like not leaving my signature everywhere.

Reply to
Alex

[snip]

You must have missed my 'or so' - the period of a minute would be determined by usability testing prior to standardisation and implementation.

Good.

Does it care? If it doesn't get a response back within the maximum specified time for a reply, either resend, or ask the user to enter another PIN. After some period of time, have the terminal decline the card, either because it's faulty, or because the user can't provide a successful PIN.

I was working on the assumption that the chip, being cheap enough to put on millions of credit cards, would be stateless between transactions. If the chip is sophisticated enough to have the capability to maintain state between transactions, great - have the chip self-block after three failed attempts within a given time period instead.

Anyway, this was all minutiae for the benefit of explaining the essentials of how C&P works so I could outline the two main technological attacks one could use to clone live chips.

Best Regards, Alex.

Reply to
Alex Butcher

Alex Butcher wrote: ...

No need to make assumptions btw.... start at

formatting link
and work through the specs......

Reply to
Mike Scott

At 21:29:19 on 13/02/2006, Alex Butcher delighted uk.finance by announcing:

The 'or so' is redundant. The big chains think even the sub-10 second transaction times are too slow.

Absolutely.

So you'd have a world based on timeouts rather than acknowledgements?

No. Have it block after three failed attempts full stop.

One of which requires an unlikely level of access to the bank's systems and the other of which is currently impractical.

Reply to
Alex

What do you think is the difference between a faulty card/chip and a card for which the user cannot produce a valid PIN?

You're putting words in my mouth. Why do you think this would be an inappropriate choice in this context?

Even months or years apart? Sounds somewhat unreasonable to me, especially if the user forgets to apply for a new card after their second failed attempt.

Which was exactly my point. Well, sort of; the folks in Ross Anderson's security team at Cambridge have gotten crypto material out of 'tamperproof' IBM crypto modules used in ATMs and power analysis has been done on satellite TV cards in order to crack those, so I'm not sure why you say either is _currently_ impractical. Anyway, my point is that the crypto and the chips is probably the least vulnerable part of C&P, which I suspect we agree on.

Shoulder-surfer a customer entering their PIN then bonking them over the head and stealing their card is probably the most usable vulnerability. For this, as far as the card holder is concerned, the attacker doesn't even have to be successful in determining their PIN in order to suffer potentially serious physical harm - sure, the card ends up unused, but who cares about that if you're bruised and unconscious in a gutter somewhere?

Second is probably bribing someone within the official card manufacturing facilities to make you up a few hundred blanks. This is the most common kind of "forgery" of secure documents (e.g. ID cards, passports) these days.

Best Regards, Alex.

Reply to
Alex Butcher

Frankly, I couldn't be bothered to read the spec for a 5 minute post to USENET.

Instead, I gave a description of a broadly equivalent system that would not be vulnerable to chip copying. I would certainly expect that the folks at the card companies are capable of designing something at least as good as I can in 5 minutes, and getting the political/financial will to get it implemented according to specification.

Best Regards, Alex.

Reply to
Alex Butcher

At 00:55:08 on 14/02/2006, Alex Butcher delighted uk.finance by announcing:

The valid chip card will respond. The faulty one will not.

Tesco estimate it costs them £1m per second wasted at the checkout. Do you really expect them to accept up to a £50m per second hit?

Apply for a new card? They just call their bank and request a PIN reminder.

Really? So they'll expend all this effort to crack a card which may be useful for a few hundred pounds, if it hasn't already been reported lost/stolen?

And nobody carries mobile phones these days for exactly the same reason, right?

And then what? The cards are only useful when they've been personalised by the bank. This happens immediately prior to them being stuck in an envelope and sent out.

Reply to
Alex

At 00:58:49 on 14/02/2006, Alex Butcher delighted uk.finance by announcing:

Then stop assuming.

Reply to
Alex

*Sigh*

The reason I came up with an invented C&P scheme was to avoid getting into an offtopic (for uk.finance) discussion about technical details of the actual C&P implementation and interpretation of technical specs. The OP wanted to know whether the chips were clonable, and I endeavoured to answer that ("not really, not yet, for practical purposes, and probably not for the foreseeable future either" was the answer I was hoping to communicate) in such a way that they could see *why* I was saying that was the case.

I made no assumptions about the actual C&P implementation. If I had, you would have been entirely justified in pulling me up for such an assumption. The only assumption I made was that my hypothetical design worked on the basis of just about the *simplest* functional hardware I could envisage. You've already said that the actual C&P implementation uses *better* smartcard technology - fine, that doesn't contradict anything I said, and it eliminates other potential pitfalls that would exist with my hypothetical design.

To use an analogy, I was saying 'If I assume that I walk, I can get to Bath from Bristol in under 3 hours' and you were saying "Yeah, but you're actually driving, so you can get to Bath in under an hour"[*]. Note how one hour *is* under 3 hours.

Take a deep breath, and realise that not everyone on USENET is trying to start an argument or have a pissing contest about how much detail they know about some esoteric subject. I know that's uncommon these days, but...

Best Regards, Alex.

[*] Notwithstanding assumptions about Bristol and Bath's traffic... :-)
Reply to
Alex Butcher

Well, yes. I meant in terms of how the rest of the transaction will proceed.

I've already said that delays in my hypothetical design would be subject to user acceptance testing. Obviously the folks behind the actual C&P design found that delays that long weren't acceptable, and chose other techniques to mitigate risk, like picking a more sophisticated smartcard and having it maintain state. That works too.

But you said the chip maintains state between transactions, and as such enters a 'blocked' state after 3 failed PIN attempts. Or do we perhaps have a different definitions of 'state' and/or 'blocked'?

Right, I thought you were suggesting that power analysis and timing attacks were impractical in the general case, rather than in this specific case. I thought I implied that such attacks *probably* wouldn't be used against live credit/debit cards *today* in order to clone them but may do in the future, but I can see how what I wrote could be misinterpreted to suggest that such techniques could be used today.

I'm not sure exactly what point you're making here. If you're making the point that people carry mobile phones despite the possibility that they may get mugged for them, then I'd accept that. However, note that not everyone deems it an acceptable risk to carry a valuable up-to-date phone and use it recklessly; for example I'm still happy with my old brick from

2002 and attempt to use it discretely when I must. Call me a paranoid luddite if you like...

I was thinking of a confluence of a) a situation similar to that experienced by Panama with Unisys in relation to their ID cards scheme and b) the dummy accounts described in .

Best Regards, Alex.

Reply to
Alex Butcher

BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.