Transcript slides - Indocrypt 2011

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, NeedhamSchroder
• 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 …
VDU
Security Module
Host
PCI Card or Separate Module
PC or Mainframe
Security API
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 exclusiveOR function
KP1
Source
HSM
Dest
HSM
KP2
Repeat twice…
User->HSM
: Generate Key Component
HSM->Printer : KP1
HSM->User
: { KP1 }KM
Repeat twice…
User->HSM
: KP1
HSM->User
: { KP1 }KM
Combine components…
Combine components…
User->HSM
: { KP1 }KMK ,{ KP2 }KM
User->HSM
: { KP1 }KM ,{ KP2 }KM
HSM->User
: { KP1 xor 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.
Combine components…
User->HSM
: { KP1 }KM , { KP1 }KM
HSM->User
: { KP1 xor KP1 }KM
KP1 xor KP1 = 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
• 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, 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 and manage
the evolution of protocols that hold together
complex socio-technical systems
• Evolution crypto algorithms  crypto libraries 
crypto processors  crypto frameworks