Download as PDF, PPTX
Uploaded byWSO2
Securing IoT Applications
This document discusses securing the Internet of Things (IoT). It notes that IoT devices differ from traditional devices in ways that impact security, such as limited ability to update firmware. It recommends not relying on security through obscurity and discusses practical crypto implementations for small devices. The document also covers securing communication protocols like MQTT, CoAP and DTLS, as well as approaches like OAuth2 for authentication without passwords on devices. It describes a demonstration of using OAuth2 with MQTT to limit a device's access to an API by giving it a revocable token rather than a static password.
More Related Content
Similar to Securing IoT Applications
![[Roundtable] Choreo - The AI-Native Internal Developer Platform as a Service](https://cdn.slidesharecdn.com/ss_thumbnails/choreo-deck-250328074645-511dded7-thumbnail.jpg?width=640&height=640&fit=bounds)
Securing IoT Applications
- 1. Securing the Internet of Things Paul Fremantle CTO, WSO2 (paul@wso2.com) PhD researcher, Portsmouth University (paul.fremantle@port.ac.uk) @pzfreo
- 2. About me • CTO and Co-‐Founder WSO2 – Open Source Middleware plaLorm • Part-‐Mme PhD looking at security • Working in Apache for 14 years • Working with Cloud, SOA, APIs, MQTT, IoT 2
- 3. Firstly, does it maQer?
- 6.
- 7.
- 9.
- 10. So what is different about IoT? • The longevity of the device – Updates are harder (or impossible) • The size of the device – CapabiliMes are limited – especially around crypto • The fact there is a device – Usually no UI for entering userids and passwords • The data – O_en highly personal • The mindset – Appliance manufacturers don’t think like security experts – Embedded systems are o_en developed by grabbing exisMng chips, designs, etc
- 11. Physical Hacks A PracMcal AQack on the MIFARE Classic: hQp://www.cs.ru.nl/~flaviog/publicaMons/AQack.MIFARE.pdf Karsten Nohl and Henryk Plotz. MIFARE, LiQle Security, Despite Obscurity
- 13. Or try this at home? hQp://freo.me/1g15BiG
- 14.
- 15. Hardware recommendaMons • Don’t rely on obscurity
- 16. Hardware recommendaMons • 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 • Don’t rely on obscurity
- 17. Hardware RecommendaMon #2 • Unlocking a single device should risk only that device’s data
- 18.
- 19. Crypto on small devices • PracMcal ConsideraMons and ImplementaMon Experiences in Securing Smart Object Networks – hQp://tools.ieL.org/html/dra_-‐aks-‐crypto-‐sensors-‐02
- 20.
- 21. ECC is possible (and about fast enough)
- 23. Crypto Borrowed from Chris Swan: hQp://www.slideshare.net/cpswan/security-‐protocols-‐in-‐constrained-‐environments/13
- 24. Won’t ARM just solve this problem?
- 25. Cost maQers 8 bits $5 retail $1 or less to embed 32 bits $25 retail $?? to embed
- 26.
- 27. SIMON and SPECK hQps://www.schneier.com/blog/archives/2013/07/simon_and_speck.html
- 28. Datagram Transport Layer Security (DTLS) • UDP based equivalent to TLS • hQps://tools.ieL.org/html/rfc4347
- 29.
- 31. CoAP • Constrained ApplicaMon Protocol – hQp://tools.ieL.org/html/dra_-‐ieL-‐core-‐coap-‐18 – REST-‐like model built on UDP – Californium project coming soon to Eclipse IoT • No authenMcaMon or authorizaMon – Relies on DLTS or data in the body
- 32.
- 33. MQTT • Very lightweight messaging protocol – Designed for 8-‐bit controllers, SCADA, etc – Low power, low bandwidth – Binary header of 2 bytes – Lots of implementaMons • MosquiQo, Paho, RSMB and MoqueQe 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)
- 34. MQTT • Relies on TLS for confidenMality • Username/Password field
- 35. Passwords • Passwords suck for humans • They suck even more for devices
- 36.
- 38. Why OAuth2? • Widely implemented • PreQy good – Of course there is never 100% agreement – Or certainty with security protocols • Not just HTTP: – hQp://tools.ieL.org/html/dra_-‐ieL-‐kiQen-‐sasl-‐ oauth-‐12 – OAuth2 used with SSL
- 41. Why FIAM for IoT? • Can enable a meaningful consent mechanism for sharing of device data • Giving a device a token to use on API calls beQer than giving it a password – Revokable – Granular • May be relevant for both – Device to cloud – Cloud to app
- 42. Two aspects using OAuth with IoT • On the device – Tokens are good – LimiMng the access of the device • On the cloud – Puvng users in control of their data – Just good current pracMce • Demo with MQTT – But not just for MQTT – Also for the cloud, CoAP, and other protocols too
- 43. Demo components MosquiQo (Open Source MQTT Broker) AcMng as “Resource Server” MosquiQo_py_auth mqQ-‐oauth2.py IdP WSO2 IdenMty Server ESB IntrospecMon API Refresher.py Arduino CreateToken.py 1 2 3 4 5 6
- 44.
- 45. Lessons learnt • MQTT and 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 implementaMons behave differently (e.g. changing the refresh token every Mme 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)
- 46. What I haven’t covered enough of
- 47. Summary • Think about security with your next device • We as a community need to make sure that the next generaMon of IoT devices are secure • We need to create exemplars – Shields – Libraries – Server so_ware – Standards
- 48.