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 1980s (ATM networks, POS, other embedded systems)

– a PhD 1992–4 on protocols, followed by work on algorithms / protocols / hardware security in 1990s

– Focus more on systems / software / security economics / usability since

• This is a personal view

The story so far

• 1970s – Diffie-Hellmann, RSA, Needham-Schroder

• 1980s – Early theory (GMR, BAN); complex crypto (elections, remailers, digital cash); real deployment (ATM networks)

• 1990s – 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 i3300)

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 …

HostPC or Mainframe

Security ModulePCI Card or Separate Module

Security API

VDU

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

SourceHSM

DestHSM

KP1

KP2

Repeat twice…

User->HSM : Generate Key ComponentHSM->Printer : KP1HSM->User : { KP1 }KM

Combine components…

User->HSM : { KP1 }KMK ,{ KP2 }KM

HSM->User : { KP1 xor KP2 }KM

Repeat twice…

User->HSM : KP1

HSM->User : { KP1 }KM

Combine components…

User->HSM : { KP1 }KM ,{ KP2 }KM

HSM->User : { KP1 xor KP2 }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.

• 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!

Combine components…

User->HSM : { KP1 }KM , { KP1 }KM

HSM->User : { KP1 xor KP1 }KM

KP1 xor KP1 = 0

Case study 3 – crypto infrastructure

• 1990s – 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, DigiNotar, 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 – 155Mbit/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 (IPv6?) 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, long-term 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 and manage the evolution of protocols that hold together complex socio-technical systems

• Evolution crypto algorithms crypto libraries crypto processors crypto frameworks