Schneier on Security

Clive Robinson • November 30, 2012 12:10 AM

As @Chris above has noted in many ways,

That’s how they used to do it in the old days… …we’re back where we started.

If you think about it that’s perhaps the biggest indicator there is that there is something wrong with the base technology, and it’s time for a compleate re-think.

And for those who might be thinking “What to do next…” proffesionaly I urge you not to use Near Field Communications (NFC) because with a minor variation it will still be the same failing system underneath, except you will have in all probability made some relay attacks easier.

And that’s the problem the “security” changes that have been made over the past twenty or so years to ATM’s are just cosmetic and are in effect “like puting a sticking plaster on a broken bone”, they are a quick fix on the surface but leave the real problem in a broken condition, and that’s usually crippling at best and quite often fatal…

And unless a radical change is made we are just going to see “the same old same over and over” that we have seen in the past but with minor variations.

Do I know the solution “no” have I thought of a way to go “not realy” but one suggestion is to think about a couple of base level important things,

1, Make it “communications channel” independent.
2, Always include the user in the comms channel to reliably authenticate the transaction in both ways.

The reason for the first is it will alow future changes in technology to be quickly and easily incorperated into the overal system thus giving customers more choice more quickly.

And the second is the whole point of banking to ensure the “customer” and the what the customer thinks is the “bank” realy are not just for opening the comms channel but for each and every transaction.

Thus if done correctly “Internet banking” and “ATM Banking” will be the same. But further if the “Merchant” is likewise correctly authenticated then the solution will include both Banking and Purchasing across any communications channel. And that ultimately should be the goal for all parties.

Clive Robinson • November 30, 2012 1:56 AM

@ Steve,

Then there are machines where you just slide the card in and out of the reader yourself. Those are immune to this

Whilst they might be immune to this specific attack it leaves the system wide open to “card not present” attacks.

Basicaly the “not present” attack works on voting machines as well as ATMs and many other systems and should realy be called “session not closed” attacks.

What happens is the user starts a session in which they perform a transaction, but don’t close the session when they finish and thus “walk away with the session still open” If the system either allows or can be coerced into allowing another transaction to take place then an attacker jumps in on the open session and makes another transaction for themself at the users cost. With ATM’s the cost might just be a few hundred dollars, with voting machines it means their vote gets stolen.

One of the reasons why cards are kept in the machine is specificaly to stop “card not present” attacks and as often as not the reason it is done is the view the legislators and judiciary take.

It is also intrinsic to some systems (or should be) like Chip-n-Pin.

User not present style attacks can be a bit more subtal than this and can occur with what are in effect Man In The Middle (MITM) attacks or Relay attacks and these days are not just possible but probable with all card systems. These attacks occur because the PIN is a laughably weak form of one way authentication that is only performed on opening a sesssion not on individual transactions.

Essentialy the user opens the channel(s) with their PIN and from that point onwards performs no further authetication… And thus as long as the channel(s) stay open the attackers are free to proceade from that point onwards, it’s why I say above that authentication must be on every transaction not the channel(s).

In the case of MITM there is only one channel what the attacker does is “be transparent” during the authentication phase and then either fake what the user sees or performs another transaction in the background which is not visable to the user.

With some relay attacks two or more channels could be opened with multiple simultanious transactions possible unless the Bank has appropriate preventative measures in place at the Banks end which we know from some other attacks is not always the case, and further all offline transactions are compleatly vulnerable to multiple channel attacks. It’s why I say above that all the authentication has to be two way, that way the user knows that the channel they are seeing is actually talking directly to the bank.

To remove the multiple channel issue or replay attacks the user has to actually be in the communications channel and the authentication has to be strong not weak as unfortunatly PINS are.

What do I mean by strong authentication well firstly it has to be sufficiently strong to make guessing and similar attacks not feasable so needs a high level of entropy. Secondly it should not actually use the secret (PIN) in a way that it could be recorded and then be used for a replay attack, this is it either needs to have some time based changing element or some kind of verification of a shared secret where the secret it’s self is never transfered across the communications channel, preferably both.

And the reason the user needs to be in the channel well so they can reliably see what is being authenticated and when.

It is these last two points that are difficult to find a solution to because of the required level of entropy in the secret and the size and number of values used for proper transaction authenttication. Whilst having an independent token is now becoming more normal, humans are still not particularly good at typing in long strings of what appears to them to be random data.

It is a problem I’ve been thinking on how to solve for over a decade now and the solutions I’ve thought of (such as using something humans are good at and computers bad) have been beaten by the attackers one way or another.

As a couple of exampless,

Back in the last century (mid to late 1990’s) I proposed using an out of band authentication channel using either a token or as they were becoming quite common then the mobile phone SMS text message. Back then the problem it failed on with using SMS was the mobile phone operators regarded it as a secondary service at best, and delivery of texts was neither timely or even guarenteed.

Later with the development of the smart phone and the lack of channel seperation this cause as far as I was concerned had “put the nail in the coffin” of this idea. However not as far as the Banks were concerned, because it was at this point that Banks finally said yes we will use SMS and started rolling systems out. However as we now know the attackers exploited an entirely different weakness to the one I’d seen, they exploited a “human” weakness in either the Bank’s or the phone service suppliers Customer Service Depts to change the phone number used in some way so the SMS went to the attacker not the customer…

As a second example of a big rock on the journy, I liked the idea of capatchers, they are relativly easy for humans to read but currently quite difficult for computers.

So I thought well why not compress the transaction data via some method or uses a checksum and encode it in a capatcher for the user to type into the token to cut down on user typing.

Well it turned out that labour is so cheap and employers so unethical in some parts of the world that attackers could rent people to translate the capatchers in real time for the attackers computers…

In short it’s a hard problem to solve and there are many rocks and pot holes as yet unseen on the journey, and currently all the advantages appear to be with the attackers due to the very human (not technical) weaknesses of the customers, banks and associated third parties such as mobile phone suppliers…