Cryptology where is the new frontier Ross Anderson

Cryptology – where is the new frontier? Ross Anderson Cambridge

Where are the big challenges? • If you’re starting research in crypto and security, where are the interesting problems? • Are there any particular opportunities for India? • My background: – industrial crypto in the 1980 s (ATM networks, POS, other embedded systems) – a Ph. D 1992– 4 on protocols, followed by work on algorithms / protocols / hardware security in 1990 s – Focus more on systems / software / security economics / usability since • This is a personal view

The story so far • 1970 s – Diffie-Hellmann, RSA, Needham. Schroder • 1980 s – Early theory (GMR, BAN); complex crypto (elections, remailers, digital cash); real deployment (ATM networks) • 1990 s – Modern primitives (DC/LC, AES); deeper and wider theory (e. g. theorem provers); better engineering (DPA, tamper resistance); wide deployment (SSL/TLS, GSM, pay-TV, smartcard payments, prepayment meters…); crypto wars

Keep growing outwards…

Emerging trends 2001– 10 • Security economics: with multiple stakeholders, you need to get the incentives right • Usability: no-one reads manuals any more and you can’t fix stuff by ‘educating the user’ • Scale: the security protocols that form the backbone and sinews of distributed systems have to work at global scale • Strains are showing in payment systems, smart grids, and core infrastructure like CAs, DNS, BGP

Case study 1 – banking protocols • EMV (‘Chip and PIN’) deployed in Europe and elsewhere • ‘Liability shift’ – disputes charged to cardholder if pin used, else to merchant • Changed many things, not always in the ways banks expected!

Fraud in the UK since EMV

Crypto shifted the landscape… • It caused the fraud to find new channels • Card-not-present fraud shot up rapidly • Counterfeit took a couple of years, then took off once the crooks realised: – It’s easier to steal card and pin details once pins are used everywhere – You can still use mag-strip fallback overseas – Tamper-resistance doesn’t work

Tamper-proofing the PED • In EMV, PIN sent from PIN Entry Device (PED) to card • Card data flow the other way • PED supposed to be tamper resistant according to VISA, APACS (UK banks), PCI • Evaluations follow Common Criteria • Should cost $25, 000 per PED to defeat

Tamper meshes (Ingenico i 3300)

But it just didn’t work! • PEDs ‘evaluated under the Common Criteria’ were trivial to tap • CC sponsors wouldn’t defend the brand • APACS said (Feb 08) it wasn’t a problem… • In July 08, ‘new’ terminals found to be sending card and PIN data to Karachi

A normal EMV transaction

The ‘No-PIN’ attack (2010)

Fixing the ‘No PIN’ attack • In theory: might block at terminal, acquirer, issuer • In practice: may have to be the issuer (as with terminal tampering, acquirer incentives are poor) • Barclays introduced a fix July 2010; removed Dec 2010 (too many false positives? ); banks asked for student thesis to be taken down from web instead • Real problem: EMV spec now far too complex • With 100+ vendors, 20, 000 banks, millions of merchants … everyone passes the buck (or tries to sell ECC…)

Case study 2 – API security • Consider an application programming interface (API) through which people work with sensitive data • Used in ATMs, CAs, metering systems … VDU Security Module PCI Card or Separate Module Security API Host PC or Mainframe I/O Devices Network

Hardware Security Modules

API Attacks • A typical HSM has 50– 500 API calls! • We found that evil combinations of API calls, or API calls with wicked data, can very often break the security policy • E. g. HSM transaction defined by VISA for EMV for encrypted messaging between a bank and a chip card • Send key from HSM to card or other HSM as {text | key} – where text is variable-length • Attack – a bank programmer can encrypt {text | 00}, {text | 01}, etc to get first byte of key, and so on • API vulnerabilities can turn up in multiple products, so are important to find – but are still hard to find formally

VSM Attack • Keys are stored outside the HSM encrypted under master keys • Some of these are exchanged between banks (or between a bank and an ATM) in several parts and recombined using the exclusive -OR function KP 1 Source HSM Dest HSM KP 2 Repeat twice… User->HSM : Generate Key Component HSM->Printer : KP 1 HSM->User : { KP 1 }KM User->HSM : KP 1 HSM->User : { KP 1 }KM Combine components… User->HSM : { KP 1 }KMK , { KP 2 }KM User->HSM : { KP 1 }KM , { KP 2 }KM HSM->User : { KP 1 xor KP 2 }KM

Idea: XOR To Null Key • A single operator could feed in the same part twice, which cancels out to produce an ‘all zeroes’ test key. Combine components… User->HSM : { KP 1 }KM , { KP 1 }KM HSM->User : { KP 1 xor KP 1 }KM KP 1 xor KP 1 = 0 • PINs could be extracted in the clear using this key by treating it as a terminal master key • Implicit type system was not well designed or understood!

Case study 3 – crypto infrastructure • 1990 s – attempts by NSA etc to control crypto, then to license CAs • Also, browser vendors restricted the number of root certificates, making CAs valuable • Now hundreds of CAs can all break your security • Comodo, Digi. Notar, FC… • In short, this system is completely broken. What can we do to fix it? • The forces which broke the system are still in play

Security economics • Has become a thriving field of study since 2001 • Big systems now have many stakeholders. If Alice does the maintenance but Bob pays the cost of failure, they’ll probably fail • Protocols: initial costs and maintenance costs often borne by different players • Also: features get added till they break. They’re not regulated by the state, and don’t belong to a company – a classic governance failure • CAs do belong to a company but race to the bottom

Security economics (2) • The information industries have a tendency to monopoly (because of network effects, low marginal costs, technical lock-in) • In market races, you have to appeal to complementers (e. g. app developers), so security is usually an afterthought • As we get software everywhere, many more industries will become more like this • What will happen once we each have 100 worn/ implanted CPUs? What issues would excite a parliament of cyborgs?

Case study 4 – Homeplug • Homeplug AV – 155 Mbit/sec powerline comms (e. g. DSL router to wifi repeaters) • Encryption mostly used for separation • Key management from ‘Resurrecting Duckling’ • On power-up, either enter AES key manually • Or: initial key sent in the clear, then device locked • Secure against later passive attack; OK for 99% of users as no remote exploits • Next – keys for kit in electricity substations

… and suicide bombing • Local mechanisms can also do revocation! • Example: in ad-hoc network, how does a mote remove a neighbouring mote who misbehaves? • Old answer: have a voting system • New answer: “I’m Alice and I hereby declare that Bob and I are both dead” • This can be optimal – if action is local – and the economics of mote creation and subversion are in the right ranges

Case study 5 – the Internet interconnection infrastructure • Inter-X study for ENISA on the resilience of the Internet– with Chris Hall, Richard Clayton and ENISA staff • So far, the Internet has survived major incidents like 9/11 and Katrina – but it’s ever more critical • Things that could break the Internet include external failure (solar storms), organisational failure (oligopoly), bugs (IPv 6? ) and attacks (e. g. router malware doing route hijacking) • BGP SEC project trying to fix this

Securing BGP • Idea: routers sign route announcements, RPKI certifies who owns which IP addresses • ASes can’t get local, incremental benefit • Route filtering also has poor incentives • Routing tables kept confidential • Will ASes buy spare capacity to help competitors? • So can’t map topology even to buy diversity… • 11 recommendations now European policy

Recommendations • 1: Independent body to investigate major incidents and report on them publicly • 2: Collect consistent, comprehensive, longterm network performance data • 3: Research better metrics for resilience of complex multi-layer networks • 4: Develop secure inter-domain routing with decent incentives for deployment

Recommendations (continued) • 5: Research incentives to improve resilience at the AS level • 6: Sponsor and promote good practice in network management • 7: Sponsor independent testing of routing equipment and protocols • 8: Conduct regular pan-European exercises and war games on the interconnection infrastructure

Recommendations (continued) • 9: Start figuring out the regulatory options in the event of transit market failure (which has already started to happen since our report came out!) • 10: Promote public debate on policy and mechanisms for traffic prioritization • 11: Work towards a resilience certification scheme so that corporate purchasers can identify dependable service providers, and to encourage deployment of BGPSEC etc

The policy debate • US academics involved in key escrow, export control, wiretapping law, privacy, copyright … • UK academics: crypto licensing, export control, surveillance law, privacy, competition, copyright, ID cards … • India? Blackberry … then the ID project … now web censorship … • If academics are to help shed light on policy issues, what sort of tools might be helpful?

India’s competitive advantage? • Where can Indian researchers best compete? • Hint: Britain graduates 12, 000 programmers a year, India hundreds of thousands • Also: many new apps from ID and elections through prepay systems and phone banking • Many of the problems of large scale, usability and incentives need to be tackled in domestic systems • India is a natural place for academics to help develop cryptographic engineering 2. 0

The Research Opportunity • The online world and the physical world are merging; this will cause dislocation for years • The great systems architects of the coming generation will have to understand many things, from cryptology and operating system security to game theory and microeconomics • They’ll need the tools to understand manage the evolution of protocols that hold together complex socio-technical systems • Evolution crypto algorithms crypto libraries crypto processors crypto frameworks