IoT Mashup - Security for internet connected devices - Lyle


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Good morning everyone.Thanks for being here.I wanted to talk about security of internet-disconnected devices, but apparently that wouldn’t be interesting.
  • My nameMy affiliation – webinos and OxfordI’ve been part of the team working on the security and privacy architecture in webinosBefore that, I completed a doctorate in trusted computing and web servicesI’m leaving, so here’s a slightly more useful set of contact detailsDo email me, talk to me on Twitter
  • I’m going to start by telling you what you probably already know. But lets be honest about it: IoT security is a really hard problem. Give yourselves a pat on the back if you’re working on this stuff, I reckon there are some fundamentally difficult issues surrounding it.Indeed, I’m going to start by talking about challengesThen I’m going to talk about specific IoT threats and attacks. Then I’m going to drop into a few technologies. Probably a frustrating number, that definitely wont cover the things you are interested in.
  • To highlight the fun that can be had in this subject, I want to show you what happens when the Internet of Things happens by mistake.This is *old* now – but essentially this website searches for IP cameras in places like car parks, offices, and so on.
  • With a presentation about security, it’s very easy to fall into some classic traps.So here’s what I’m not going to say. If you catch me saying any of these points, please throw something at me…
  • 1) Wireless communication – lots of wifi devices in IOT, all broadcasting all communication.2) Physical insecurity – In many scenarios, the devices are placed in areas where the owner isn’t in physical control or possession. E.g., sensors places in public locations, or in buildings with lots of people nearby.3) Constrained devices – the “internet connected devices” may be too constrained to enforce security controls or do heavy-weight cryptography. Constrained in terms of power, bandwidth, memory…4) Healthcare, cameras, etc.5) No clear standards, so no defence in using a “best practice” solution. Everything is adhoc. Can’t stand on the shoulder of any giants.6) The fact that you have lots of different devices, means that you have a ‘weakest link’ problem. The weakest device may be an attack surface to compromise the rest of the system7) IOT involves people, hardware, software, systems, businesses, and more. It isn’t a software problem, and doesn’t have just software solutions.8) Chances are, your IOT system is also a Web system. At least for control. You’ve therefore got all the classic web threats to deal with – XSS, CSRF, content injection, etc. You’ve also got attackers from across the world.9) Security would be easier if we could identify all security principles, all the things, ahead of time. But in IOT we can’t.10) Adding security functionality costs more, and is inconvenient. Buying sensors and constrained devices with encryption coprocessors is expensive and hard. The most secure way is not the default.
  • We’re going to find out a lot of ways *not* to do it.We’re going to need to share experiences, experiment, and feed back information. If security isn’t going to be your big selling point, then you need to make it a collective task. That’s a good argument for openness.We could argue that this is like the 90s, or the dot-com bubble. Lots of great technology, huge potential, but also all the same naivety and lack of security thinkingWe needs to apply our current security and privacy attitudes to IOT, not the ones we had 10-20 years ago.
  • Having talked about why it’s hard, lets think about the threats we’ll have to deal withThese are threats specifically around IOT, largely take from the IETF core working group, and a document written by Garcia-Morchon et al.
  • Anyone could steal or modify a thingAnyone could replace a particular thing with an alternative modelA manufacturer could “clone the physical characteristics, firmware/software, or security configuration of the thing”.
  • An attacker with physical or remote access could plausibly update or modify firmware - there’s a proof-of-concept exploit for routers through web browsers for thisThe software you deploy to the device could be decompiled to obtain any keys or credentials it holds.The software is likely to be vulnerable to Denial of Service attacks. These might be used to make it malfunction.
  • Rerouting traffic – exploit the network protocol to make the connection via your node look more favourable, thus gathering traffic from all sources. A useful attack if you only control a small part of the network.
  • There are security challenges at all of the following stages…
  • Don’t let uncertainty behind attackers stop you from making progressIn webinos, we came up with a set of personas – descriptions of archetypal people – describing potential attackers (script kiddies, etc)Realism: the ‘global passive adversary’ model is not appropriate. How much of your network might any one attacker gain access to?Don’t push people towards modders – the mobile industry and car industry has taught us that removing simlocks helps fund more serious fraud.
  • Web-friendly notions of sharingInternet-based access point for each personal zone User-as-owner modelPolicy-driven access controlLimitations - Not really suited to constrained devices! We think it actually might work well, but this wasn’t the original design - One device has one owner. Only.
  • CoAP – a protocol designed to be easy to integrate with the web, but suitable for constrained devicesDTLS – TLS but for UDP not just TCPIpsecSizzle – work in 2005 to have constrained devices use SSL. Works with ECC and Identity Based EncryptionHIPS – new global namespace, layer of abstraction between the transport and IP layer. Identify endpoints by their host identifiers (HIs), a public key. HIP Diet EXchange (DEX) - fewer cryptographic primitivesUcode - 128-bit fixed length identifier used to identify objects
  • Capabilities?
  • It should be obvious that IOT is current a voyage into the unknownThere’s way too much uncertainty and new technology floating aroundGeneric solutions wont help that much – it’s a systems problemThe only way progress will be made is through sharing results, making data and reports open, and collaboration. Please take this opportunity.
  • IoT Mashup - Security for internet connected devices - Lyle

    1. 1. Security for Internet- connected devices John Lyle, University of Oxford
    2. 2. Welcome!  John Lyle  ResearchAssistant at the University of Oxford  Member of the webinos project  Email:  Twitter: @jplyle
    3. 3. What I’m going to say 1. Internet ofThings security is hard! 2. There are some good reasons for this. 3. There are new (ish) threats. 4. There are some new technologies to play with.
    4. 4. The Insecurity ofThings
    5. 5. What I’m not going to say 1. Security is really important. 2. This is how to exploit [ insert popular technology product ] 3. I have the following silver bullets… 4. Anything about privacy
    6. 6. Why is IOT security difficult? And is there anything we can do about it?
    7. 7. Because… 1. Wireless communication 2. Physical insecurity 3. Constrained devices 4. Potentially sensitive data 5. Lack of standards 6. Heterogeneity: weakest link problem 7. A systems, not software problem 8. Classic web / internet threats 9. Identity management & dynamism 10. Inconvenience and cost
    8. 8. But really… It’s because we don’t know how to do it. Yet.
    9. 9. Threats to IOT systems Adapted from "Security Considerations in the IP-based Internet of Things“ - Garcia-Morchon et al.
    10. 10. The physical devices  Can be stolen  Can be modified  Can be replaced  Can be cloned
    11. 11. The software  Can be modified (firmware / OS / middleware)  Can be decompiled to extract credentials  Can be exhausted (denial of service)
    12. 12. The network  Eavesdropping  Man-in-the-middle attacks  Rerouting traffic  Theft of bandwidth
    13. 13. Securing the whole lifecycle  Design  Production  Bootstrapping  Monitoring  Reconfiguration and recovery  Decommission
    14. 14. Who are the attackers? And what do they want?
    15. 15. We don’t know, but…  Make assumptions to make progress  Use Attacker Personas for consistency  Realistic attacker models  Organised crime?  Curious end users? Modders?  Service providers?
    16. 16. The state of the art Some of it, at least.
    17. 17. The webinos approach  TLS and a device PKI  Attribute-based access control  Web identity and authentication  “Personal zone” model
    18. 18. Protocols and identifiers for constrained devices  CoAP:The ConstrainedApplication Protocol  DTLS: DatagramTransport Layer Security  IPsec  Sizzle – SSL with EllipticCurve Cryptography[1]  HIPS: Host Identity Protocol  HIPS-DEX  ucode [1]Gupta,V.; Millard, M.; Fung, S.; Zhu,Yu; Gura, N.; Eberle, H.; Shantz, S.C. "Sizzle: a standards-based end-to-end security architecture for the embedded Internet," Third IEEE International Conference on PervasiveComputing andCommunications. pp.247,256, 8-12 March 2005
    19. 19. Thoughts to leave you with.  Many new technologies and protocols are being developed  IOT requires systems security Share your results!
    20. 20. Any questions? John Lyle /