1 / 14

The Man-in-the-Middle Defence (… or – rehabilitating Charlie …)

The Man-in-the-Middle Defence (… or – rehabilitating Charlie …). Ross Anderson, Mike Bond Computer Security Group Cambridge Security Protocols Workshop 28th March ‘06. Talk Structure. Real-life Middlemen The Middleman and EMV The customer is cut out of the deal Adding an attorney

merv
Download Presentation

The Man-in-the-Middle Defence (… or – rehabilitating Charlie …)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Man-in-the-Middle Defence(… or – rehabilitating Charlie …) Ross Anderson, Mike Bond Computer Security Group Cambridge Security Protocols Workshop 28th March ‘06

  2. Talk Structure • Real-life Middlemen • The Middleman and EMV • The customer is cut out of the deal • Adding an attorney • Other Middleman Defences – HSMs • The Dining Attorneys Problem • Conclusions

  3. Protocol history • Needham-Schroder – assume principals follow the protocol faithfully • The NS ‘bug’ – if Alice is dishonest, she can cache a ticket and delay the protocol run • We had to change the whole threat model once we started to consider dishonest insiders… • What about e-commerce?

  4. Real Commerce • E-commerce assumes 2 honest parties – buyer and seller (sometimes we add the bank too) • But very often, the threat is not Charlie but Bob – the person you’re deliberately dealing with! • In real life, we use middlemen to represent our interests to those who might harm us – lawyers, tax accountants, priests,… • Often protocols are designed to exclude the middleman • Thankfully, the design is often incompetent

  5. EMV Protocol Loop PIN Issuer Customer Personalisation Centre Card Issuing Bank Acquiring Bank Terminal HSM Merchant

  6. EMV Protocol Loop PIN Issuer Customer Personalisation Centre Card Issuing Bank Acquiring Bank Terminal HSM Merchant

  7. Terminal to Card • With SDA, the transaction and PIN go in clear from terminal to card; card returns a MAC • You can capture PAN and PIN to make a mag-stripe card, or change the amount, or forward the transaction, or … (Mike’s talk yesterday) • Problem: the card represents the bank, and the terminal represents the merchant. Either (or both) can be bent. No-one represents the customer! • But we can fix that …

  8. Meet my Attorney • Our interceptor displays the transaction amount requested. If the customer presses ‘OK’, it then inputs the correct PIN, and writes an audit trial entry • A real-world implementation will be not much bigger than a credit card • It protects you against crooked merchants, and against crooked banks

  9. Other man-in-the-middle defences • Things like firewalls and anti-virus software are familiar – but there’s much more • Hardware Security Modules (HSMs) guard the crypto keys used by banks in EMV, ATM and other systems • An HSM exposes a “Security API” to the bank’s host computer, which aims to permit legitimate uses of the keys but prevent wholesale abuse (e.g. theft of a million PINs). • To a first approximation, all APIs are broken. We’ve broken all of them at least once and we keep finding new breaks. New vulnerabilities are routinely mandated by interbank standards bodies…

  10. Hardware Security Modules

  11. Solution • Put the IBM 4758 in a PC • Run our software on the PC • Put the PC in a tin box with tamper-responding lid switches • Allow through only the protocols, and the parameters, that you actually use • Keep an audit trail on disk • Provide a trustworthy user interface • Both IBM, and we, have to screw up

  12. Composing Middlemen • What if there are multiple interceptors? • If my attorney is next to my card, it protects me from an interceptor between that and the terminal (or hidden in the terminal) • We already have the theory – ‘Cascade Ciphers: the Importance of Being First’ by Maurer and Massey • When ciphers are composed, they are as strong as the last one • Special case: ciphers that commute are as strong as the best one

  13. The Dining Attorneys • How can five interceptors commute? • Easy: the card, the terminal and the attorneys communicate using a dependable broadcast protocol • Any bad advice can be countered with a denunciation • This actually happens – big business deals involve meetings with multiple specialists (lawyers, accountants, bankers, brokers …)

  14. Conclusions • The middleman has had a bum rap in the literature • But he’s ubiquitous in real life • Even a lawyer who’s on trial hires another lawyer! Keeping up with criminal law is a speciality • So is keeping up with viruses, with HSM API flaws, with EMV flaws, with phishing scams,… • Having pluggable middlemen is likely to be cheaper than fixing everything in the world every month • It’s the place to put the security maintainability, and to put the human back into the protocol • Usability and maintainability are the two big problems!

More Related