1 / 28

What does ‘Security’ mean for Ubiquitous Applications?

What does ‘Security’ mean for Ubiquitous Applications?. Ross Anderson Cambridge. Outline of Talk. Security can help to control technical complexity, by limiting interaction It can help control complexity of use - security usability will be a big growth area

mignon
Download Presentation

What does ‘Security’ mean for Ubiquitous Applications?

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. What does ‘Security’ mean for Ubiquitous Applications? Ross Anderson Cambridge

  2. Outline of Talk • Security can help to control technical complexity, by limiting interaction • It can help control complexity of use - security usability will be a big growth area • It is also about conflict - about tussles for commercial control, user privacy • First, let’s look at some ubiquitous applications

  3. Ubicomp (1) - Smart Dust • Thousands of motes deployed in a self-organizing network for surveillance • This is in conflict with the interests of the party under surveillance • There may be capable opponents - enemies who deploy ‘black dust’ against your ‘white dust’ • Also privacy issues - e.g. if US law prevents monitoring US citizens without a warrant • Security partly ‘military’, partly regulatory

  4. Ubicomp (2) - RFID • Passive tags returning 128-bit unique ID • Story about ‘refilling your fridge’ - but at heart, RFID is about controlling supply chains • US privacy row - can a third party scan not just what you’re wearing but where you bought it, when and for how much? • Triggered widespread resistance - from trade-policy wonks to fundamentalist Christians • Serious political objection: RFID enables manufacturers to clamp down on grey market trading, in contravention of EU Single Market

  5. Ubicomp (3) - in the Car • Latest cars have 40-50 CPUs, CANBUS, Bluetooth • Closest so far to Ubicomp ideal of computers embedded invisibly everywhere - with a serious attempt to make them usable, automatic etc • Growing problem of feature interaction - multiple administrators / ‘owners’ • Worries about platform vulnerability • From the privacy angle, the combination of GSM, GPS, logging, road pricing and DRM is bad stuff • Also, issues with aftermarket control

  6. Ubicomp (4) - The Digital Home • Vision (e.g. Toshiba U-home) - appliances talk via UWB, 802.11, Bluetooth, IR, RFID • Home gateway talks broadband to the world • But trust management gets complex! • Issues of policy - multiple domains (do teens have privacy from parents and/or vice-versa?) • Issues of practice - how do you mate the access control /DRM systems of multiple platforms? • How can my mother manage all this stuff?

  7. A Possible Framework • One machine - standard computability, complexity theories; programming tools • One person - applied psychology • One person, one machine: HCI • One machine, many people: access controls • One person, many machines (or: many apps) - feature interaction, conflict, more HCI issues • Many people, many machines: more complexity, more conflict, affecting more and more sectors

  8. How can the security engineer help? • First goal: control system complexity from the programmer’s viewpoint • Feature interaction is the fastest-growing source of new problems • We can help ensure that one application only interacts with another via the official interface (compartmented operating systems, ‘Trusted Computing’) • We can also help ensure that the application programming interface can’t be manipulated (API security - see my papers with Mike Bond)

  9. VSM Attack (2000) • Top-level crypto keys exchanged between banks in several parts carried by separate couriers, which are recombined using the exclusive-OR function KP1 Source HSM Dest HSM KP2 Repeat twice… User->HSM : Generate Key Component HSM->Printer : KP1 HSM->User : { KP1 }ZCMK Combine components… User->HSM : { KP1 }ZCMK ,{ KP2 }ZCMK HSM->User : { KP1 xor KP2 }ZCMK Repeat twice… User->HSM : KP1 HSM->User : { KP1 }ZCMK Combine components… User->HSM : { KP1 }ZCMK ,{ KP2 }ZCMK HSM->User : { KP1 xor KP2 }ZCMK

  10. API attack: 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 • Other API manipulation attacks were found on essentially all crypto processors on the market! Combine components… User->HSM : { KP1 }ZCMK , { KP1 }ZCMK HSM->User : { KP1 xor KP1 }ZCMK KP1 xor KP1 = 0

  11. New Research Problems? • Turning TC / API security ideas into working products will be non-trivial • Another black hole: maintainability • E.g. at present most security literature is about bootstrapping into a secure state - once Alice and Bob share a key, we head for the pub! • Bugs in products are not usually fixed - you are expected to buy a new mobile phone every year. But this won’t work for air-conditioners!

  12. More on Maintainability • Parallel: early software engineering work was on producing large programs from scratch; now it’s about evolution. Theses are no longer written on the ‘waterfall model’ but on ‘extreme programming’ • We have almost no literature on security resilience, and on automatic recovery after compromise • Our own tentative ideas: ‘Smart Trust for Smart Dust’, Anderson, Chan and Perrig, ICNP 2004 • But we will need much, much more!

  13. How can we help? (2) • Second goal: control system complexity from the user’s viewpoint • The current bottleneck is security usability • It’s taken 30 years to come up with (barely adequate) ways of managing the millions of bits of security state in a typical company • The home is more complex still! • Meanwhile, consumers have difficulty with VCR programming and basic PC admin

  14. Ubicomp and Usability • U-Vision - embedded devices will be easy to use, thus eliminating the PC’s frustrations • More sober view (Odlyzko) - trade-off between flexibility and ease of use is different for different users (and same user at different times/tasks) • Norman’s ‘human-centered engineering’ assumes mature products (a long way off!) • ‘We will still be frustrated, but at a higher level of functionality, and there will be more of us willing to be frustrated’

  15. Odlyzko’s warning • Home environment is likely to be more complicated than today’s office environment, and home users generally less knowledgeable • We may have to outsource the setup and maintenance of home appliances to experts - that is, remote administration • Users given varying degrees of control, ‘depending on skills and trustworthiness’ • We can already see the beginnings of this in mobile phone and car electronics markets

  16. Perils of Remote Admin • I just don’t want Bill running my home! • His competitors should like it even less! • Even with open standards, there will be severe tensions. Plumbing nightmares will be replaced by call-centre hell • Cynical view: if the equilibrium is set by customers’ frustration tolerance, more usable systems means you can sell more stuff before this point is reached

  17. Market Demand for Usability? • ‘Microsoft has triumphed because it has given us what we asked for: constant novelty coupled with acceptable stability, rather than the other way around. ... People talk simplicity but buy features and pay the consequences. Complex features multiply hidden costs and erode both efficiency and simplicity.’ (E Tenner, ‘The Microsoft We Deserve’, NYT)

  18. Usability and Incentives • User sees his phone banking app not as a Vodafone thing but a Citibank thing • If it works, Citibank gets the credit • If it doesn’t, Vodafone gets the blame • Incentives aren’t right for the app vendor or the platform vendor • Worse - there are half-a-dozen stages in the supply chain. Who’ll do the work?

  19. The Right Abstractions? • Roles, or groups? • Brands? • Locations? • Other restrictions on state? • People? (biometrics, nyms?) • Directories, or file types? • Machine owners, or file creators? • What does it mean to ‘lock the digital front door’?

  20. Scientific challenge • Computer scientists have spent the last 50 years building tools that help developers get a little bit further up the complexity mountain • ‘Risk thermostat’ - 30% of big projects fail, but they are bigger projects each year • But the complexity that now matters most, for building predictably dependable systems, is not from the CPU’s viewpoint but the brain ‘s • What should we design now instead of languages, compilers and CASE tools?

  21. The Broader Aspects • As everyday objects acquire intelligence, it is as if they are under magic spells • Motorola’s phones have magic that stops them working with other firms’ batteries • HP’s printers are under a spell that stops them working with other firms’ ink • Microsoft’s new IRM stops Office documents working with OpenOffice • Where will it end? How should governments regulate a world of magic spells?

  22. Economics of Information Security • Over the last four years, we have started to apply economic analysis to information security • Economic analysis often explains security failure better then technical analysis! • Information security mechanisms are used increasingly to support business models rather than to manage risk • Economic analysis is also vital for the public policy aspects of security

  23. Traditional View of Infosec • People used to think that the Internet was insecure because of lack of features – crypto, authentication, filtering • So engineers worked on providing better, cheaper security features – AES, PKI, firewalls … • About 1999, we started to realize that this is not enough

  24. New View of Infosec • Systems are often insecure because the people who could fix them have no incentive to • Bank customers suffer when bank systems allow fraud; patients suffer when hospital systems break privacy; Amazon’s website suffers when infected PCs attack it • Security is often what economists call an ‘externality’ – like environmental pollution • Security is also increasingly used to support business models by locking in customers, tying products etc

  25. Current Security Economics Research Topics • Understand differences between growing and mature markets (bargains then rip-offs; security ignored then later used to lock in customers) • Why do people say they value privacy but act as if they don’t? • Do we spend too little on security, or too much? • Where are the incentives misaligned, and why? • What’s the appropriate government policy? • Economics and Security Resource Page – www.cl.cam.ac.uk/~rja14/econsec.html

  26. The Soft World • Effects of technology are always overestimated short-term but underestimated long-term • Putting CPUs and comms into every thing costing over a few bucks will change the world • Software will provide ever more of the value • Many industries will become ever more like the software industry • We’ll get the good (flexibility), the bad (frustration) and the ugly (monopolies)

  27. Conclusions • Ubiquitous computing presents many security research opportunities • We can apply existing work in compartmented operating systems, API security, crypto etc • We face serious new challenges in security usability and in maintainability • Economic and policy aspects are also nontrivial - security is a socio-technical system • Understanding the interplay of technical, design and policy issues is the really hard challenge

More Related