May 09, 2006

Chip-and-Pin terminals were replaced by "repairworkers" ?

In comments to the chip-and-pin fraud story, Lynn points to:

Chip and pin hack exposed

According to our source, a team of shysters has been turning up at petrol stations posing as engineers and taking the Trintech Smart5000 Chip and Pin units away for repair. They have then bypassed the anti-tamper mechanisms and inserted their own card skimmer.

... snip ...

this is also could be considered from the angle of my old security proportional to risk theme

That might explain all the arrests, as they could have gone and examined the videos to see who the repairmen actually were.

The attack on the merchant terminals reminds me of the old one-way-triangle chipmoney designs. They used in general a diversified key arrangment so if you cracked a user card then you could only duplicate that one card. This threat was addressed by blacklisting within the system (there were all sorts of secret instructions and capabilities in these chip money products, some of which got them into hot water from time to time because of the secrecy).

So, with the diversified key design, the limitation was that the upstream merchant card had to hold the full key, only the downstream user card would hold the diversified key. (Think of it as k and H(k). One can prove the other, but not the other prove the one.)

Which simply shifts the burden of the attack to the merchant, so the merchant in theory had to secure the card his device more carefully than a user card. I pointed this out on occasion, but it was not considered a grave risk, mostly because I suspect it was actually a shifting the burden pattern, a la Senge. That is, cognitively, the story had an answer, and going the extra distance to analyse the new story was beyond saturation point.

This is apparently the device, Trintech:

The Smart 5000 PED

The Smart 5000 is based on an ARM7 processor, with MMU (memory management unit). It boots a 2.4 series embedded Linux kernel from 4MB of Flash (8MB optionally available). The device includes 16MB of SDRAM, and 512K of SRAM.

Trintech's Smart 5000 PIN entry device

Standard I/O ports include an RS-232 serial port, and USB. Optional ports include PSTN (public switched telephone network), ISDN (integrated service digital network), and IP/LAN (Ethernet).

The Smart 5000 includes an 8-line, 132 x 64 pixel backlit graphics display, along with 15 keys and 6 programmable keys. It also contains an EMV L1 certified chip card reader; a Track 1, 2, & 3 magswipe reader; and 3 additional SIM/SAM readers.

The Smart 500 measure 8 x 4.3 x 4.7 inches (205 x 110 x 120 mm).

Trintech's Linux-based Smart 5000 PED received certification by Visa as a secure PED in October, 2003. The device also sports certified encryption capabilities for DES, 3DES, RSA (2048-bit key length), with countermeasures agains DPA, DFA, an DTA. It also supports SHA1 and KUKPT.

Posted by iang at May 9, 2006 05:40 AM | TrackBack

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

Posted by: Dr. Evil at May 9, 2006 05:59 AM

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

Posted by: Watching Them, Watching Us at May 9, 2006 06:28 AM

Shell Chip And PIN Breach - Response From RSA Security

can you say security proportional to risk Petrol firms suspends chip-and-pin
or parameterized risk management

note that the chip&pin counterfeit "yes card" chips mentioned in 2002 reference
and 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. Petrol firm suspends chip-and-pin

Posted by: Lynn Wheeler at May 9, 2006 10:36 AM

more in the on going saga

Lloyds TSB admits chip and Pin flawed
Bank admits flaws in chip and PIN security
Surge in overseas ATM fraud
Surge in overseas ATM fraud

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 JIBC April 2006 - "Security Revisionism"

Posted by: Lynn Wheeler at May 11, 2006 09:54 AM

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?

Posted by: Iang at May 11, 2006 10:02 AM

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 does CA need the proof of acceptance of key binding ? Is cryptography where security took the wrong branch? dual-use digital signature vulnerability MD5 collision in X509 certificates Digital signatures have a big problem with meaning the limits of crypto and authentication U.S. & Ireland use digital signature the limits of crypto and authentication ID "theft" -- so what? Shifting the Burden - legal tactics from the contracts world

Posted by: Lynn Wheeler at May 11, 2006 10:30 AM

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.

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.

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.

misc. past posts mentioning compromised and/or counterfeit terminals. massive data theft at MasterCard processor Creativity and security Court rules email addresses are not signatures, and signs death warrant for Digital Signatures Court rules email addresses are not signatures, and signs death warrant for Digital Signatures News and Views - Mozo, Elliptics, eBay + fraud, naive use of TLS and/or tokens Security Soap Opera - (Central) banks don't (want to) know, MS prefers Brand X, airlines selling your identity, first transaction trojan Petrol firm suspends chip-and-pin Chip-and-Pin terminals were replaced by "repairworkers"? New Method for Authenticated Public Key Exchange without Digital Certificates Shipwrecks Maximum RAM and ROM for smartcards Security via hardware? When *not* to sign an e-mail message?

Posted by: Lynn Wheeler at May 11, 2006 04:20 PM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.