Securing the Internet of Things

More Related Content

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.
• 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.
• 15.
• 16.
• 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.
• 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.
• 24.

  Crypto Borrowed from ChrisSwan: http://www.slideshare.net/cpswan/security-protocols-in-constrained-environments/13

• 25.
• 26.
• 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.
• 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.
• 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.