Bruce Schneier

Syth

Bruce Schneier is a cryptographer and computer security expert. He writes a monthy computer security newsletter called Cryto-Gram. He writes about security in general, not just computer security, he has written some thoughtful articles on airport security.

I think many skeptics would find his writing interesting as he frequently looks at normally emotive topics (like airport security, anti-terrorism laws), with a calm rational skeptical eye. I am subscribed to his monthly newsletter and would recommend it to people who want rational material on topics where rationality and logica are frequently lacking.

davros

I'm subscribed (via RSS) myself and thoroughly endorse Syth's comments. It will be well worth paying attention to Mr Shneier's analysis of whatever security measures are put in place following the recent London bombings.

robindch

> recommend it to people who want rational material

Schneier is a good writer on security: his Applied Cryptography is probably the finest general-purpose text on the topic and I'd happily recommend it to anybody who's working with any aspect of security, whether it's computer security or otherwise. As above, the crypto-gram home page lives here and it's worth subscribing for his educated opinions.

However, despite his considerable skill in matters crypto and elsewhere, he doesn't get it right all the time -- his article on Mitigating Identity Theft, which appeared in his April mailing and which concerns credit card security, is inaccurate in almost every detail and seems to owe more to the frequently half-baked opinions of Cambridge's ever-boisterous Ross Anderson and his two-man Chip and Spin travelling roadshow, rather than any indepth analysis carried out by Schneier himself. At the time, I did take Schneier up on his inaccuracies [I work in credit card security], but he didn't include my reply in May's posting, despite some backing and forthing between us, which was a bit of a pity as it bugs the bejesus out of me to see well-intentioned people propagate nonsense!

Syth

robindch wrote:

However, despite his considerable skill in matters crypto and elsewhere, he doesn't get it right all the time -- his article on Mitigating Identity Theft, which appeared in his April mailing and which concerns credit card security, is inaccurate in almost every detail and seems to owe more to the frequently half-baked opinions of Cambridge's ever-boisterous Ross Anderson and his two-man Chip and Spin travelling roadshow, rather than any indepth analysis carried out by Schneier himself. At the time, I did take Schneier up on his inaccuracies [I work in credit card security], but he didn't include my reply in May's posting, despite some backing and forthing between us, which was a bit of a pity as it bugs the bejesus out of me to see well-intentioned people propagate nonsense!

Interesting, care to post your analysis of his proposals?

robindch

> Interesting, care to post your analysis of his proposals?

No problem -- see below. This reply bounced back and forth a few times in an effort to condense it for publication in less than 1000 words; the response below is more-or-less the final edit, while the initial effort was about twice the size, addressed his text more directly, and was more along the lines of the usual 'rebuttal-follows-declaration' style. Schneier, as I said above, seems to have fallen for Ross Anderson's bogus (it seems to me) "economic incentive" argument which states, rather baldly, that, with chip'n'pin, banks have come up with a wheeze to enable them to refuse liability for fraudulent transactions, which is in fact, quite false. Anderson has appeared on irish telly and radio a few times over the last while trotting out this line, and raised the blood pressure of many people, not just me.

I have to take issue with some of the points you made in your most recent Cryptogram concerning credit card security. I realize that most of your text relates to the US, but you're unfairly implying that banks are denying liability for fraudulent activity and doing nothing about it. In this reply, I’ll describe existing fraud-prevention mechanisms on magstripe cards, then take a look at the EMV (Europay/MasterCard/Visa, http://www.emvco.com) transaction standards for chip cards, and finish up with some misconceptions about economic incentives.

To declare my own interest -- I co-own a company which develops EMV test and certification software for credit card issuers, transaction acquirers, and the independent software and terminal vendors. We work with all levels of the industry, and from all sides, so we've an excellent overview of what's *actually* happening at the front and we are not beholden to any institution, nor any way of looking at the industry.

1. With magstripe cards, fraud arises with both card-not-present transactions (mailorder/internet; not addressed by EMV) and card-present transactions (either the cardholder signature is forged/not checked or the magstripe is captured by corrupt employee/lost by careless employee and counterfeit cards made; this is directly addressed by EMV).

To combat mailorder fraud, firstly, the card issuers have implemented wide support for the card security code (the three-digit code on the signature panel). Since the CSC isn’t on the magstripe, compromised magstripes alone can’t be used fraudulently where CSC verification is in place, though some mailorder vendors haven’t implemented it. Secondly, the numeric data provided by Address Verification System, AVS, can be used to verify that the carduser at knows numeric details (house number, postal code, etc) from the cardholder address. Again, AVS is not universally used, since few vendors’ software generate data of sufficient quality for a reliable implementation. Thirdly, some card issuers will only permit mailorder transactions to ship to the cardholder address. Finally, most card issuers are sensitive to what's deemed to be 'unusual' activity, and software does exist to help detect this (eg, Fair Isaac's 'Falcon' and others).

These individual measures do not come close to providing complete transaction security, but when used together properly, they can prevent some fraudulent activity. Incidentally, there do exist secure transaction environments such as SET, Visa's 3-D Secure and MasterCard's SecureCode, but these have yet to gain widespread support because of implementational complexity, though at some stage in the future, it’s possible that they, or derivative specifications, will be mandated for certain types, or perhaps all, customer-not-present transactions.

2. To combat cardholder-present fraud, the international networks have mandated the use of chip-enabled EMV cards and devices within the European region from January 2005. To date, these standards have been most widely implemented in the UK and Ireland, and they are due to be rolled out in the remainder of the world over the coming ten years or so.

In summary, here’s what happens during an EMV transaction: Firstly, the card authenticates itself to the terminal by presenting a digital signature, verified using RSA, or, with some more expensive cards, using a dynamic RSA-based challenge-response mechanism. Once the card is authenticated, the cardholder then authenticates himself/herself to the terminal by entering a card-verified PIN (stopping signature-verification fraud). Upon successful PIN entry, and entry of the transaction details, the card then calculates a triple-DES-derived transaction request cryptogram using the transaction and cashback amounts, date, and other items, together with a secret key, uniquely derived per card (the secrecy of the triple-DES key, together with the initial card authentication, prevents card cloning, which prevents skim fraud). This request cryptogram is sent by the terminal device, through the acquiring network, to the institution which issued the card. The issuer then validates the cryptogram, using the same transaction data elements, together with its own private copy of the card keys, to ensure that the transaction that it received for authorization was the same as the transaction presented to the card -- this authenticates the terminal to issuer link. The issuer then generates a corresponding response cryptogram which it returns, through the network, to the terminal device for verification at the card. EMV also supports sending MAC'd card commands from the issuer system to the card so that things like the oncard PIN-try counter can be reset, or the PIN changed, payment applications blocked, or the card itself permanently disabled. Using this scheme, EMV enables a card issuer to secure a transaction from the cardholder, through the networks, to itself and back again.

3. In your article, you say that the banks have no economic incentive to improve security. This is quite false. Not only have the banks had, to date, to bear the considerable financial losses due to fraud (see http://www.cardwatch.org.uk/ for details of the losses within the UK), but they also must deal with irritated cardholders and merchants, which banks do *not* enjoy. Additionally, some of the types of fraud I mentioned above (corrupt/sloppy employees) certainly are the merchant’s fault, and the institutions have every right to penalize them for sloppy security – take, for example, the case of the well-known multinational, two years or so ago, where millions of magstripes were compromised and the card issuers had to carry the enormous costs not only of the subsequent fraud, but also the cost of reissuing the millions of cards -- with EMV, this kind of disaster can be prevented, since card replication is currently realistically impossible. Since a secure cardholder-present transaction environment now exists, the European banks have transferred the liability for fraudulent transactions to the organization(s) within the transaction chain who are open to fraudulent activity, ie, those merchants who are not EMV-compliant. http://news.bbc.co.uk/2/hi/business/4098497.stm gives a high-level overview of this liability shift.

Finally, security is one element of multivariate system which includes the financial and procedural costs at the cardholder, merchant, acquirer, network and issuer levels. Implementing EMV in the UK and Ireland has been going on for around five years, at all five levels, and the cost estimates for nationwide implementations in both countries have been measured in terms of billions of euro. While it is more obviously more secure to require 100% EMV compliance from a given date at all five levels (as Ross Anderson says), it is, of course, not practically possible to do this, which is why the current phase-in is taking place.

EMV doesn't address all kinds of fraud, but it's still an excellent step towards cutting back on some kinds of fraud partially, and some other kinds, effectively completely, at least for the time being.