Here’s a sophisticated credit card fraud ring that intercepted credit card authorization calls in Phuket, Thailand.
The fraudsters loaded this data onto MP3 players, which they sent to accomplices in neighbouring Malaysia. Cloned credit cards were manufactured in Malaysia and sent back to Thailand, where they were used to fraudulently purchase goods and services.
It’s 2006 and those merchant terminals still don’t encrypt their communications?
Jimi • August 15, 2006 8:30 AM
A new use for Blowfish. Encryption of Thai credit card processing. I was thinking the same thing (It’s 2006 and…)about the VA data losses. The VA could use it as well, with all the missing data being reported lately they sure have problems. Don’t we all.
Jimi • August 15, 2006 8:40 AM
This is sounding expensive. VA data theft may cost $500 million. Another story says it could be worse than first thought. I guess the VA doesn’t encrypt anything. I’m sure they will start and it will cost a bundle. It will be less costly than doing nothing.
MBY • August 15, 2006 10:27 AM
Sad that no apparent crypto was used. No need even for a good old block replay attack! 😉
Michael Ash • August 15, 2006 11:55 AM
Why should you use crypto when tapping phone lines is illegal? If you haven’t done anything wrong, you have nothing to hide.
(For those who didn’t get it, that was sarcasm.)
Pat Cahalan • August 15, 2006 12:39 PM
C’mon, Bruce, if you allow people to crypto their credit card transmissions, the terrorists will just use credit card terminals to send their communications back and forth so that the NSA can’t eavesdrop on them!
(like Michael, that was sarcasm).
Jiminy • August 15, 2006 12:54 PM
If the VA had just used a VPN or something on the laptop, they would never need to save data on anything beyond the central servers, which can be hardened and encrypted against attack. Every one of the laptop issues was b/c it was stolen and the data was saved onto it. You can login to a VPN from ANYWHERE there’s an internet connection. What is the excuse? It’s all smoke and bs at this point…
Jimi • August 15, 2006 1:35 PM
Data has a way of ending up on different devices. They made DOD systems interoperable with VA systems so information could flow both ways, so when the VA security failed it left the DOD systems open to attack. The result is that information is easier to share and unfortunately easier to steal. The VA was warned about data security problems for 5 years. It would be nice if everything could be stored on one secure server and be safe. The number of devices for storage keeps growing and will keep growing and getting smaller, while holding more data. You won’t need a central server. At CMUthey are working on a system to store different chunks of data on multiple devices, so if physical security is breached, you won’t have all the data on one device. You will need multiple devices to access the data. All your eggs won’t be in one basket. Spreading data over multiple devices makes sense. My understanding of it is it’s a jigsaw approach. One hard drive has the pieces and the other has the directions for how to put them together. I guess they are connected with a network. It’s an interesting approach.
Michael Kohne • August 15, 2006 4:41 PM
I worked on dial-up credit card terminals (not ones you’re likely to have seen in the wild) a few years ago, and none of the processor specs included encryption that I saw. It appears that the processors make the assumption that no one will be able to tap the phones.
Brian Miller • August 15, 2006 5:23 PM
How are you supposed to encrypt DTMF? If the dial-up terminals made a modem connection, then that could be encrypted. But DTMF? Or if the call is made verbally, that would be the same thing as DTMF. Both use audio frequencies, and can be tapped. I don’t know of anybody using a secure line for these transactions.
Fergus Doyle • August 15, 2006 5:41 PM
It’s true processors do not encrypt this information and this applies to ATMs as much as to POS. The only thing that would normally be encrypted is the pinblock, which contains the pin number. The whole track 2 from the card would be sent in the clear. So for signature based authorisation you’re in trouble of course not all territories do this for POS these days with the intoduction of Chip and PIN and EMV things are improving in 2006 … slowly!
Arthur Chaparyan • August 16, 2006 2:13 AM
That’s just insane! I once had a guy come up to me and ask if I would program a device that would listen in on a phone line and record the data being passed. I told him I wouldn’t do it based on moral objections, but I also told him to stop trying because there is no way those things are not encrypted. I guess I was wrong!
“these days with the intoduction of Chip and PIN and EMV things are improving in 2006 … slowly!”
It’s been a few years since I worked with these, but the latest EMV standard I saw (dated 2003) did away with most of the encryption requirements at least here in Finland. The first version had public key systems etc. Then the second version still contained all the descriptions of the first version but ended with a short chapter saying basically “Message protection is done as in the previous messaging standard”.
And the older standard is mostly from 1987 (IIRC), uses DES and protects only the integrity of transaction messages. Most of the protection was seen to come from the fact that they still use X.25… Of course big chains can use whatever networks they want internally and some banks accepted transaction data with http://FTP...
The banker’s association was working to build a national VPN over Internet for this traffic, but I have no idea how that is going. The documents I saw seemed quite good though.
Karl • August 16, 2006 5:51 AM
The VISANet protocol documents were publicly available from Vital (not TSYS) for a while. I took a look at them, and there’s zero authentication or encryption except for PIN data.
It seems plausible that someone could call the phone number that a credit card terminal is connected to, just as the terminal calls for authorization, fake the dial tone and ringing, and fake an authorization response. The card wouldn’t even have to be valid. The merchant wouldn’t know anything was wrong until they try to post the transaction (usually done at the end of the day). For debit transactions (which are posted instantaneously), they might never know.
Jimi • August 16, 2006 8:19 AM
People are ripping off virtual gold, weapons and other property from online gamers using malware and other tools. This stuff is then sold for real cash. A game developer could build a virtual bank and let players take a crack at virtual safes and point of sale systems to see what sort of innovation takes place. It could also spawn new revenue (real money) no doubt through advertising and marketing. The banks could let employees play it to understand network security. If players could build banks in the game, they could sell them off. The players with the most secure banks, most deposits and transactions would become virtual millionaires and perhaps real millionaires depending on the security of their virtual banks which could be sold at auction for real cash. Those who cheat or run a dishonest bank will not be trusted. It should be easy to spot the banks run by the criminals. I suppose some people will get duped and quit the game earlier than others.
Jimi • August 16, 2006 8:46 AM
The virtual banker could go virtually public and offer virtual stock to expand their operations. http://vse.marketwatch.com/Game/Homepage.aspx
You wouldn’t need regulations to keep the whole thing honest. Figures don’t lie. Security is rewarded, stupidity is punished. Instead of trying to prove the banks are stupid, try proving you are smart. The banks aren’t dumb!
1234567890 • August 16, 2006 9:32 AM
@Fergus Doyle who said:
“It’s true processors do not encrypt this information and this applies to ATMs as much as to POS.”
My awnser:
Why should microprocessors need to encrypt?
usualy this being done elsewhere, and only the digest is being proccessed.
@Fergus Doyle who said:
“The only thing that would normally be encrypted is the pinblock, which contains the pin number.”
And:
“The whole track 2 from the card would be sent in the clear.”
My awnser:
The PIN isn’t stored, nor is it in plain anywhere. There is only a digest of the PIN. The PIN is not stored anywhere besides in your head.
And:
Well, the second contains only trivial data.
solinym • August 16, 2006 10:33 PM
SET protects against this; it’s actually quite good, IMHO. I worked for a company that wrote SET software. They went under. I imagine this is due to a “nobody else is doing it”, or “it will never happen to me”, or “I don’t suffer if this is exploited” attitude.
shoobe01 • August 17, 2006 3:15 PM
Do tell me this was in jest:
“How are you supposed to encrypt DTMF?”
???? DTMF is a transmission scheme for numbers. That’s like asking how you encrypt written numbers.
Anyone know what devices they use in Thailand? I know lots of old hardware (e.g. linotype machines, 3-strip technicolor) that works fine gets recycled overseas. Wonder if these are just old US technology, in a world that’s advanced past them. As opposed to being new, badly designed devices, I mean.
RvnPhnx • August 18, 2006 3:25 PM
@shoobe01
“???? DTMF is a transmission scheme for numbers. That’s like asking how you encrypt written numbers.”
Ummm….no.
DTMF := Dual Tone Multi-Frequency
DTMF encoding is often used to encode decimal numbers, but it is actually designed around a 4×4 grid of tones (4 in one audio range, 4 in the other) with two tones being sent at once. The “common” definitions are “0123456789ABCD*#” (where often E = * and F = # for the purposes of encoding hexidecimal data)–not in that order.
So, the individual whom asked: “How are you supposed to encrypt DTMF?” was making a valid point. The POS system often is just a glorified telephone set, so it knows nothing about encryption–it just converts whatever is typed on the keypad and the data from the stripe (acct#) to DTMF audio just like any other basic modem technology.
So, the real question is: What do we do about antiquated technologies that were not designed with encryption in mind? It isn’t the datastream encoding that is broken at much as the expectation to send that datastream without interception. It was assumed that human beings wouldn’t be able to “hear” the content of a DTMF encoded datastream (I wouldn’t put it past some blind people however), but that was a misinterpretation of the real security risk.
Mistaking DTMF as being equal (in a sense) to written numbers is a symptom of this problem. One CAN encrypt written numbers (try running Feld-Hell encoding past the uninitiated–the Germans got away with that for quite a while, without adding actual encryption to the mix), one just has to find a way to encrypt the encoding scheme. DTMF encoding, on the other hand, is not the sort of thing open to this option in any sane manner (encrypting written numbers may sound hard, but has been done for quite some time). It is possible to encode the datastream BEFORE DTMF modulation. This is where the focus needs to be. It is a lot easier to encode the encrypted data–and much more secure.
Fergus Doyle • August 25, 2006 1:09 AM
@1234567890
The nub of the problem is for signature based tranactions there is enough data in the authorisation message to commit a later fraud for signature based POS transactions not for pin. Hence the fraud desribed in the original post.
In detail:
As far as only trivial data being included in the message if you have the whole of track two and can make a new card with this data that’s all you need to make a purchase for a signature based transaction.
Or additionally a card not present transaction where the only details required are from track two (ie no CVV2 name, or address verification)
This is really where the protection of Chip and PIN benifits you the most because you won’t have the pin number.
eTechSupport • August 25, 2006 10:30 AM
In few asian countries I have came across with few service providers or sellers they even dont bother to verify the signature after swaping the Credit card, so any one can make fraud by using any signature with stolen card. I think those merchants should train their front level staff to check and verify it thoroughly during billing process to avoid possible fraud on that way.
firstdown • October 6, 2006 2:23 AM
by vnPhnx
The POS system often is just a glorified telephone set, so it knows nothing about encryption–it just converts whatever is typed on the keypad and the data from the stripe (acct#) to DTMF audio just like any other basic modem technology.
The POS does have encryption and the protocol used is SDLC. It’s binary. Traditionally, credit/debit (signature based) transactions are never encrypted. If it is debit with PIN, only the PIN Block is encrypted.
Currently in Thailand, suppliers of POS terminals are from Verifone, Ingenico, Hypercom, PAX…..
If Blowfish were to be used, are there hardware devices (appliances…) to encrypt/decrypt these messages between the terminal & the host (processor)?
I know that some suppliers are looking to implement CBC based Blowfish, but have difficulty finding the hardware at the host end to encrypt/decrypt messages.
firstdown • October 6, 2006 2:26 AM
I need to add that encryption is done by secure modules within the terminals, these are terminals are VISA PCI and EMV certified. Typically they used 3DES and EMV uses Public Key as well for keys. Terminals are also now 32bit.
Mr Kanth • January 30, 2007 2:46 AM
I am not a techie but very keen to know why is it not necessary to enter the pin code while purchasing any goods using ones credit card, where as the pin code is necessary for purchasing using a debt card…… I know we have a pin number for credit card also but this is used only while transaction is made in ATM centres n not while purchasing goods, if iam wrong then please do correct me……
Ndonga • February 5, 2007 1:14 AM
Interesting stuff. I live in 3rd world and i see no point why we should not experiment.
mike • October 7, 2007 12:03 PM
tell me how on the earth now the data is captured (Track2)from the phone line (POS) out put and stored and how is the pin pad the tampered and what equipment is used to store the pin?
0ffby0ne • January 26, 2008 12:48 PM
I have question. Don’t know if its appropriate but here goes. Can you extrapolate the cvv2 of a batch by having three or for cards in sequential order(such as last four of cards 0008,0016,0024,0032,0040,0058)and the first 12 being the same and expiration the same. and if so what method would you use to find the key for the whole batch?
mony4j2 • November 10, 2008 8:28 AM
exactly what numbers are necissary when encoding or writing a credit card is it jus the pan expiration and name or do we need the saervice code in the equation for the card to actually work when going in stores?
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Tim • August 15, 2006 7:52 AM
I’ve noticed that many banks in the UK ask you to punch in your card number while you get through to an appropriate operator. Odeon does it for phone bookings of cinema seats as well. I would have thought it could be fairly straightforward to make a little gadget that could listen out for card numbers, if you can just get a tap into the line somewhere…