Maybe the shysters cited their rights under GPL to take the device away?

Should "KUKPT" in the brochure be read to mean "DUKPT" i.e. Derived Unique Key Per Transaction ?

Shell Chip And PIN Breach - Response From RSA Security
http://www.theitshield.com/pr/7118

can you say security proportional to risk
http://www.garlic.com/~lynn/aadsm23.htm#26 Petrol firms suspends chip-and-pin
and
http://www.garlic.com/~lynn/2001h.html#61
or parameterized risk management
http://www.garlic.com/~lynn/aadsm23.htm#1

note that the chip&pin counterfeit "yes card" chips mentioned in 2002 reference
http://web.archive.org/web/20030417083810/http://www.smartcard.co.uk/resources/articles/cartes2002.html
and
http://www.garlic.com/~lynn/aadsm22.htm#20 FraudWatch - Chip&Pin

would have involved compromised and/or counterfeit chip&pin readers skimming information (for loading into the counterfeit chips) from the chip&pin protocol chatter.
http://www.garlic.com/~lynn/aadsm23.htm#25 Petrol firm suspends chip-and-pin

more in the on going saga

Lloyds TSB admits chip and Pin flawed
http://www.thisismoney.co.uk/saving-and-banking/article.html?in_article_id=408976&in_page_id=7
Bank admits flaws in chip and PIN security
http://www.dailymail.co.uk/pages/live/articles/news/news.html?in_article_id=385811&in_page_id=1770
Surge in overseas ATM fraud
http://www.itn.co.uk/news/business_341509.html
Surge in overseas ATM fraud
http://www.channel4.com/news/content/news-storypage.jsp?id=341509

in 2000 there was a one week conference in London with the Lloyds of London syndicates that provide retail fraud insurance. One of the subjects discussed extensively was the threat model involving compromised and counterfeit terminals for things like skimming ... as well as x9.59 characteristic of having eliminated requirement to hide the transaction for fraud elimination.

slight cross-over
http://www.garlic.com/~lynn/aadsm23.htm#28 JIBC April 2006 - "Security Revisionism"

Lynn, who/which was taking out the insurance? Why weren't they self-insuring? It seems with such a large and spread population only self-insurance makes sense?

Iang wrote:
> Lynn, who/which was taking out the insurance? Why
> weren't they self-insuring? It seems with such a large
> and spread population only self-insurance makes sense?

retail merchants (brick&mortar) ... many places in the world.

for payment cards ... the retail merchant having fraudulent transactions is held liable for the transaction. standard dispute process ... and burden of proof is on the merchant in any dispute.

for a little drift ... a few past posts mentioning disputes
http://www.garlic.com/~lynn/2000g.html#34 does CA need the proof of acceptance of key binding ?
http://www.garlic.com/~lynn/aadsm15.htm#8 Is cryptography where security took the wrong branch?
http://www.garlic.com/~lynn/aadsm17.htm#59 dual-use digital signature vulnerability
http://www.garlic.com/~lynn/aadsm18.htm#55 MD5 collision in X509 certificates
http://www.garlic.com/~lynn/aadsm19.htm#33 Digital signatures have a big problem with meaning
http://www.garlic.com/~lynn/aadsm19.htm#46 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm2.htm#useire U.S. & Ireland use digital signature
http://www.garlic.com/~lynn/aadsm20.htm#0 the limits of crypto and authentication
http://www.garlic.com/~lynn/aadsm20.htm#22 ID "theft" -- so what?
http://www.garlic.com/~lynn/aadsm23.htm#14 Shifting the Burden - legal tactics from the contracts world

looking at the threat model for compromised and/our counterfeit terminals was attempting to get a feeling for production of counterfeit cards that could be used at other merchants for fraudulent transactions (and therefor overall merchant fraud).

the early x9.59 protocol analysis from the mid-90s had the transaction being directly authenticated.
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

separation of authentication from the actual operations tends to mimick more of session type paradigm. however, session type paradigm (with authentication separate form actual operations), tends to be more vulnerable to end-point compromises, infrastructure compromises, replay attacks, mitm-attacks, etc.

In the past, physical compromises of end-points (like terminals) or infrastructure (like networks) have tended to involve evesdropping and harvesting related exploits. the attackers would take the gathered information and use it for mounting attacks on other parts of the infrastructure. Part of this can be viewed from the standpoint of fraud ROI ... it takes some amount of investment to put into play compromised (or counterfeited) end-points amd/or other parts of the infrastructure (like network). Using information from the exploit to attack other parts of the infrastructure, draws attention and suspicion away from the the point of exploit (tending to maximise its criminal operation). Performing fraudulent transactions at the point of exploit tends to focus suspicion much quicker, the implication that the point of exploit will be discovered and have a much shorter useful (criminal) lifetime. This has tended to be the model for compromised and/or counterfeit terminals.

However, the economics somewhat change in the online/virtual
world. Getting a trojan/virus into a personal computer end-point tends to represent much lower investment. The trojan/virus can operate as a compromised terminal, havesting/skimming information that enables attacks at other points of the infrastructure. However, the trojan/virus can also be used to directly perform fraudulent operations. This may shorten the life expectency of the trojan/virus ... but it doesn't take a lot of such fraud for an attacker to recover their expenses.

as oft repeated before, the requirements given the x9a10 standards working group for x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payments.

part of those requirements, implied x9.59 requiring dynamic data authentication (digital signatures) as countermeasure to skimming/harvesting (potentially by compromised or counterfeit end-points) and replay attacks.
http://www.garlic.com/~lynn/subpubkey.html#harvest

however, it also implied that authentication be applied directly to the transaction, drastically reducing the susceptability to various kinds of other end-point and infrastructure vulnerabilities as well as mitm-attacks.
http://www.garlic.com/~lynn/subpubkey.html#mitm

misc. past posts mentioning compromised and/or counterfeit terminals.
http://www.garlic.com/~lynn/aadsm19.htm#38 massive data theft at MasterCard processor
http://www.garlic.com/~lynn/aadsm22.htm#44 Creativity and security
http://www.garlic.com/~lynn/aadsm22.htm#45 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm22.htm#46 Court rules email addresses are not signatures, and signs death warrant for Digital Signatures
http://www.garlic.com/~lynn/aadsm23.htm#2 News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens
http://www.garlic.com/~lynn/aadsm23.htm#15 Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan
http://www.garlic.com/~lynn/aadsm23.htm#30 Petrol firm suspends chip-and-pin
http://www.garlic.com/~lynn/aadsm23.htm#32 Chip-and-Pin terminals were replaced by "repairworkers"?
http://www.garlic.com/~lynn/2004i.html#24 New Method for Authenticated Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2004l.html#31 Shipwrecks
http://www.garlic.com/~lynn/2005g.html#41 Maximum RAM and ROM for smartcards
http://www.garlic.com/~lynn/2005g.html#57 Security via hardware?
http://www.garlic.com/~lynn/2006e.html#3 When *not* to sign an e-mail message?