Downloaded 616 times
Uploaded byPaul Fremantle
Securing the Internet of Things
The document discusses the security challenges in the Internet of Things (IoT), highlighting issues such as device longevity, limited capabilities, and the lack of security expertise among appliance manufacturers. It recommends using secure hardware practices, cryptography, and the OAuth2 mechanism for authentication to improve device security. The author emphasizes the need for the community to ensure the next generation of IoT devices is designed with security as a priority.
More Related Content
![IoT Security: Cases and Methods [CON5446]](https://cdn.slidesharecdn.com/ss_thumbnails/j1-2016-con5446-security-160927112335-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Securing the Internet of Things
Securing the Internet of Things
- 1. Securing the Internetof Things Paul Fremantle CTO, WSO2 (paul@wso2.com) PhD researcher, Portsmouth University (paul.fremantle@port.ac.uk) @pzfreo Paul Madsen* Technical Architect, PingIdentity (pmadsen@pingidentity.com) @paulmadsen *Paul M helped me with the initial content, but I take responsibility for anything you don’t like in this slide deck.
- 3. About me • CTOand Co-Founder WSO2 – Open Source Middleware platform • Part-time PhD looking at security • Working in Apache for 14 years • Working with Cloud, SOA, APIs, MQTT, IoT 3
- 4. Firstly, does itmatter?
- 7.
- 8.
- 10.
- 11. So what isdifferent about IoT? • The longevity of the device – Updates are harder (or impossible) • The size of the device – Capabilities are limited – especially around crypto • The fact there is a device – Usually no UI for entering userids and passwords • The data – Often highly personal • The mindset – Appliance manufacturers don’t think like security experts – Embedded systems are often developed by grabbing existing chips, designs, etc
- 12. Physical Hacks A PracticalAttack on the MIFARE Classic: http://www.cs.ru.nl/~flaviog/publications/Attack.MIFARE.pdf Karsten Nohl and Henryk Plotz. MIFARE, Little Security, Despite Obscurity
- 14. Or try thisat home? http://freo.me/1g15BiG
- 15.
- 16. Hardware recommendations • Don’trely on obscurity
- 17. Hardware recommendations • Don’trely on obscurity • Don’t rely on obscurity • Don’t rely on obscurity • Don’t rely on obscurity • Don’t rely on obscurity • Don’t rely on obscurity • Don’t rely on obscurity
- 18. Hardware Recommendation #2 •Unlocking a single device should risk only that device’s data
- 19.
- 20. Crypto on smalldevices • Practical Considerations and Implementation Experiences in Securing Smart Object Networks – http://tools.ietf.org/html/draft-aks-crypto-sensors-02
- 21.
- 22. ECC is possible (andabout fast enough)
- 24. Crypto Borrowed from ChrisSwan: http://www.slideshare.net/cpswan/security-protocols-in-constrained-environments/13
- 25. Won’t ARM justsolve this problem?
- 26. Cost matters 8 bits $5retail $1 or less to embed 32 bits $25 retail $?? to embed
- 27.
- 28.
- 29. Datagram Transport LayerSecurity (DTLS) • UDP based equivalent to TLS • https://tools.ietf.org/html/rfc4347
- 30.
- 32. CoAP • Constrained ApplicationProtocol – http://tools.ietf.org/html/draft-ietf-core-coap-18 – REST-like model built on UDP – Californium project coming soon to Eclipse IoT • No authentication or authorization – Relies on DLTS or data in the body
- 33.
- 34. MQTT • Very lightweightmessaging protocol – Designed for 8-bit controllers, SCADA, etc – Low power, low bandwidth – Binary header of 2 bytes – Lots of implementations • Mosquitto, Paho, RSMB and Moquette from Eclipse – Clients: • Arduino, Perl, Python, PHP, C, Java, JS/Node.js, .Net, etc • Plus an even lighter-weight version for Zigbee – MQTT-SN (Sensor Network)
- 35. MQTT • Relies onTLS for confidentiality • Username/Password field
- 36. Passwords • Passwords suckfor humans • They suck even more for devices
- 37.
- 39. Why OAuth2? • Widelyimplemented • Pretty good – Of course there is never 100% agreement – Or certainty with security protocols • Not just HTTP: – http://tools.ietf.org/html/draft-ietf-kitten-sasl- oauth-12 – OAuth2 used with SSL
- 42. Why FIAM forIoT? • Can enable a meaningful consent mechanism for sharing of device data • Giving a device a token to use on API calls better than giving it a password – Revokable – Granular • May be relevant for both – Device to cloud – Cloud to app
- 43. Two aspects usingOAuth with IoT • On the device – Tokens are good – Limiting the access of the device • On the cloud – Putting users in control of their data – Just good current practice • Demo with MQTT – But not just for MQTT – Also for the cloud, CoAP, and other protocols too
- 44. Demo components Mosquitto (Open SourceMQTT Broker) Acting as “Resource Server” Mosquitto_py_auth mqtt-oauth2.py IdP WSO2 Identity Server ESB Introspection API Refresher.py Arduino CreateToken.py 1 2 3 4 5 6
- 45.
- 46. Lessons learnt • MQTTand MPU / I2C code is 97% of Duemilanove – Adding the final logic to do OAuth2 flow pushed it to 99% – No TLS in this demo is a big issue • Different Oauth2 implementations behave differently (e.g. changing the refresh token every time you refresh) • Need to be able to update the scope of token if this will work for long term embedded devices • The refresh flow should not really go via the Resource server – Easy fix • MQTT should have a well defined model for sending a message to just one client (securely)
- 47. What I haven’tcovered enough of
- 48. Summary • Think aboutsecurity with your next device • We as a community need to make sure that the next generation of IoT devices are secure • We need to create exemplars – Shields – Libraries – Server software – Standards
- 49.