What Identity Systems Can and Cannot Do

Ross Anderson

Cambridge

Outline of talk

• Do identity systems solve the right problem?• Will they affect behaviour in adverse ways?• What benefits can we get from better naming

mechanisms for distributed systems?• How well do the component technologies work –

separately and together?• What are the research challenges?

Historical background

• Drive over last 10-15 years to identify and track people (and things) using PKI, tamper-resistant hardware, biometrics, database checks

• Yet Baltimore failed, and Verisign almost did! • I predicted failure – for reasons set out later• Yet the effort’s intensified since 9/11• No doubt some apps will work, others won’t.

What can we learn from previous failures?

Historical background (2)

• UK government has tried repeatedly to reintroduce ID cards since Churchill abolished them (NHS, welfare, …)

• Peter Lilley, who tried in 1993, learned that police didn’t want them (knew who the bad guys were but didn’t have evidence), nor the spooks (ditto but didn’t know intentions). Asylum seekers already have them

• ID fraud – well, that’s actually libel…

Cynical views

• ID cards were very useful for splitting the Tory front bench in the run-up to the election

• They grab a huge empire for the Home Office in terms of Whitehall systems

• There’s a huge lobbying push from vendors• Dick Clarke on displacement activities• The ‘security-industrial complex’ (Robert

O’Harrow, Washington Post)

Lessons from PKI

• Idea: people and things have many electronic identities. Build an infrastructure to join them up. Thanks to the browser wars, it was an oligopoly from the word go

• Eventually you’d pay Verisign $5 every two years to renew the cert in your toaster!

• Governments raced to pass electronic signature laws and e-commerce directives

• But the public didn’t buy, and neither did anyone else outside a few niche markets

Lessons from PKI (2)

• Would you sign the following?

I agree to be unreservedly liable for all signatures that are verified by the key that I now present to you and I will underwrite all the risks taken by anyone as a result of relying on it

(see Bohm, Brown and Gladman, at www.fipr.org)

Economics of Information Security

• Liability-dumping undermined PKI• … and ATM security in the UK: banks blamed

customers for fraud – then got careless!• Medical record systems were designed for

convenience of administrators, not privacy of patients – leading to HIPAA

• It’s extremely hard to protect a system which one party defends, while another pays the cost of security failure

Economics of Infosec (2)

• In the last five years, this subject has grown rapidly to include many topics:– Economics of bugs and the patching cycle– DRM, accessory control and competition policy– Cooperation and conflict in networks– Why people say they want privacy but won’t pay for it– What sort of mechanisms might stop spam

• Many fascinating insights – and the fifth annual workshop (WEIS 2006) will be held in Cambridge, June 26-28 2006

Distributed System Issues

• Many things can scale badly – consistency, synchronisation, fault tolerance, failure recovery and naming

• Often a global naming system can cause as many problems as it solves

• Why should a bank use an external PKI when account numbers already exist? Even linking up account numbers is hard enough!

• What are names for, anyway?

What’s in a Name?

• Recognition starts out relative:– Evolutionary game theory: social cooperation

emerges when we recognize people who cooperated / cheated in the past

– Property: is the David E Bell who bought this house 14 years ago the D Elliott Bell who is now trying to sell it?

• When is it worthwhile to make it universal?

What’s in a Name? (2)

• Names may not be all in one place, so resolving them brings all the problems of a distributed system

• Names imply commitments, and often a name at one level is an address at the next. Addresses change, and stuff breaks (‘The GCHQ Protocol’)

• Human names are rarely unique, and carry all sorts of cultural baggage (the Trosttádottir case)

• Even surrogates are hard: Icelanders have one SSN, Americans can have several, while German ID card numbers change when you renew them

What’s in a Name? (3)

• Keep linkages short to minimise error and obsolescence: KA -> Ross Anderson -> sysadmin of ‘rake’isn’t as good as KA -> sysadmin of ‘rake’ -> Ross Anderson

• In general you should not be naming and authenticating people but roles: ‘Officer of the watch’, ‘Manager of the Cambridge branch’

• And expect to end up needing more names than you thought (IP; 13->16 digits for credit cards)

What’s in a Name? (4)

• Remember the big push for multifunction smartcards 10 years ago?

• My perspective (from an electricity meter project) – we could do it technically but the client couldn’t cope with liability issues, plus control of card upgrade, standards and so on

• Cardis 94 discussion – Philippe Maes said the initiative was being killed by arguments about whose logo went on the card

Revocation

• ‘The useful lifetime of a public-key certificate is inversely proportional to the number of things it’s good for’

– Kent’s law

• Revocation is often the hard problem, and when it is, it can be very hard indeed

Component technologies (1)

• ‘Tamper resistant’ products are much less awful than 10 years ago

• Size matters! Exploding complexity and a lengthening tool chain push up attack costs

• The toughest target we’ve seen was the Magic Gate (accessory control) chip on the Playstation

• One lesson: randomize everything and don’t give the attacker a single entry point! (See my SPW 2004 paper on ‘The Dancing Bear’)

Component technologies (2)

• The servers that track people or things have different problems

• Databases tracking people aggregate and leak personal information – a data protection crunch is coming sometime

• Databases tracking things can get big – tens of billions of cartons of a typical consumer good – and can undermine trade and competition policy

Component technologies (3)

• We’re about to see how well biometric systems stand up to large-scale field use. This ain’t obvious!

• Manuscript signatures awful in lab, but fine in practice

• Fingerprint systems were trusted completely by the UK police force for 50 years – until the McKie case here in Edinburgh

• Iris scanning did fantastically well in lab tests, but recent UK Passport Office trials showed worrying levels of failure-to-enrol and failure-to-match

Biometrics + cards + crypto

• How can we combine component technologies so that the system fails as gracefully as a component failure permits?

• Example: iris biometric can maybe be observed, password can maybe be guessed, smartcard can maybe be stolen and used – or with lower probability reverse-engineered

• How can you make a secret (such as a key) depend as robustly as possible on all three?

Biometrics + cards + crypto (2)

• Iris codes can have say 10% of bits different between observations of same eye

• So serious error correction is needed• Also some means of revocation• Various previous attempts didn’t work• My student Hao Feng set out to build a

system that did work – with me and John Daugman (inventor of iris scanning)

Iris code statistics

How it works

• Some random errors, and some burst errors (e.g. from eyelashes, specular reflections)

• Design the coding carefully to suit, add in a password, do the computation in a smartcard

• Security analysis neither simple nor conventional!

Protection goals

• If biometric known, have full benefit of token + password + liveness test if any

• If token stolen, need to get biometric – and there’s still a password retry counter

• If token reversed, it’s still hard to get either key or biometric from the locked code

• Full details: H Feng, R Anderson, J Daugman, ‘Combining Crypto and Biometrics Effectively’

Laser Surface Authentication

• Invented by Russell Cowburn at Imperial (formerly of Cambridge :-)

• Idea: scan the surface of paper or other packaging and get a unique code – which is much the same as an iris code (the error properties differ)

• Identify already-seen objects by database lookup, or use objects to carry unique keys

• Do what RFID does but cheaper (it works on existing packaging) and more securely (you need to swap the package, not just the chip, to spoof)

A microscopy image of paper

A microscopy image of a plastic card surface

100nm

Atomic Force Microscopy

A typical paper scan

-1.5

-1

-0.5

0

0.5

1

0 5 10 15 20 25 30 35 40

Change in reflectivity (%)

Position (mm) -1

-0.5

0

0.5

1

21.5 22 22.5 23 23.5 24 24.5 25

Change in reflectivity (%)

Position (mm)

-1

-0.5

0

0.5

1

21.5 22 22.5 23 23.5 24 24.5 25

Change in reflectivity (%)

Position (mm)

Cross correlation between 2 scans

0.3

0.4

0.5

0.6

0.7

0.8

0.9

-5000 -2500 0 2500 5000

Fraction of bits matching

Positional shift (μ )m

Different documents

0.3

0.4

0.5

0.6

0.7

0.8

0.9

-5000 -2500 0 2500 5000

Fraction of bits matching

Positional shift (μ )m

5

Same document

Results of a small scale trial

0

5000

10000

15000

20000

25000

30000

0.02370.059240.094790.13030.16590.20140.2370.27250.30810.34360.37910.41470.45020.48580.52130.55690.59240.6280.66350.69910.73460.77010.80570.84120.87680.91230.94790.9834

different_1_500 histogram bin 5 11:32:07 09/07/2004

B

C

fraction matching

0

5000

10000

15000

20000

25000

30000

0.02370.059240.094790.13030.16590.20140.2370.27250.30810.34360.37910.41470.45020.48580.52130.55690.59240.6280.66350.69910.73460.77010.80570.84120.87680.91230.94790.9834

same histogram bin 5 18:15:39 25/08/2004

C

C

fraction matching

0

5000

10000

15000

20000

25000

30000

0 0.2 0.4 0.6 0.8 1

different_1_500 histogram bin 5 11:32:07 09/07/2004

B

B

fraction matchingFraction of blocks matching

Cou

nt

0

20

40

60

80

100

120

Count

Uniqueness factor

102 109 1023 1041 1066 1093 10127

• 500 different items

• 125,000 different pairs

• 100% identification

= different objects paired

= same object rescanned

Where next?

• Rather than universal identity run by the government, we should expect multiple identities tailored to the application, which we link up only when needed

• We will need different tools in different applications

• Usability, maintainability and robustness will be of particular importance

Conclusions

• Identifying principals – from machines and roles to people and things – is interesting, important, and complex. Simplistic solutions won’t work

• There are many issues with components, with system design, and with higher-level stuff like incentives and liability

• I reckon the research frontier for the next five years will place more emphasis on usability, maintainability and robustness