, , , , , , , , ,

For some reason this story was under my radar until I heard about it on the Tenable Security podcast. Last summer, Diebold and VMware demonstrated a prototype virtual ATM system – basically a cash machine with the OS hosted at a data centre. Something tells me the marketing hype will win, and this ‘innovative solution’ will eventually become commonplace.

Personally I reckon cloud computing is over-rated. It’s useful for many things, but not always a good solution. Diebold’s vice president says: ‘This development is an important milestone on Diebold’s roadmap to leveraging cloud computing technology in the retail financial space.’ But is that actually a good idea, or just outsourcing for the sake of it? Let’s bust a couple of myths, in particular the ones regarding efficiency and complexity that I deciphered from the marketing speak.

First off, the current ATM system is generally more efficient and secure compared to Diebold’s VM concept. Yes, it’s not perfect, but still… It boils down to complexity and the amount of traffic on the network. Complexity introduces more points of failure, points of entry and sometimes interoperability flaws between the system’s components. Those should be avoided when designing networks for security.

Instead of handling everything locally and exchanging data with the relevant banks over the SWITCH network, Diebold’s system introduces VMs as an intermediary, so now we have to worry about security locally, at the data centre, and the points between. And we have a lot more network traffic going in and out the local machine. Tim Conneally, of BetaNews.com, anticipates problems related to the logical addressing of the terminals and their VMs, including Man in the Middle attacks, which are unlikely but quite possible.
Contrary to what the press release claimed, the local ATMs still require onboard computers to handle network connections, hardware, I/O, whatever encryption, etc. Essentially they’re thin clients. They’d need servicing, just like current ATMs, and without biometrics could still be compromised through the usual attacks – shoulder surfing, card skimming, hidden cameras, fake keypads, social engineering, etc.

Complexity also means engineering problems, especially in terms of error handling and fault finding, both of which are fairly critical here. For example, what happens if the connection is dropped between dispensing cash and charging an account? What about something happening outside the scope of the software? How would the engineers quickly determine whether a fault is occurring in the terminal, VM or elsewhere? Have they considered the need for firmware updates somewhere along the line?

I’ve noticed commenters at The Register were mostly concerned about reliability, which is interesting because that shouldn’t be an issue. Current ATMs are already reliant on the public infrastructure. The VMs themselves would be an improvement, perhaps running a better OS and being closely managed. Data centres maintain something like 99.999% uptime, with excellent failure recovery.

Biometrics Again
The demonstration terminal also included biometrics, which I’m not a great fan of. Instead of being a miracle solution, biometrics simply add a layer of security under certain conditions. It’s not infallible and the sun doesn’t shine out of its ass, especially where it’s just tacked onto a standard serial interface with badly-written software doing the authentication.
Biometric readers are just input devices with the authentication itself done at the other end, which means a given system could potentially be subverted by pulling the reader off and sending whatever signal/data straight down the wire. Simpler methods of defeating them are sometimes demonstrated at hacker conferences. As far as ATMs are concerned, biometric readers can make life harder for ATM hackers, providing they’re highly tamper resistant, part of some multi-factor authentication system, and function reliably enough.