Downloaded 12 times
![Comparison with related work
• OAuth for Devices
• Previous work offers OAuth2 models for devices:
• FIOT [8], IGNITE [9], IOT-OAS [1], COMPOSE[14], OAuth1 for MQTT[13], IBM
Watson, AWS IoT
• None of these provide:
• Anonymous Identities
• Clear automated registration processes or
• Personal Cloud Middleware
• Webinos
• Concept of Personal Zone Hub – personal middleware
• Does not address usability of PZH, how to configure and run in a cloud
• Does not support federated identity to the device
• IoT@Work [16]
• A model for anonymous identities for IoT
• No separation of identity management and data sharing systems
• No federated identity models
[n] References refer to the bibliography in the paper](https://image.slidesharecdn.com/oauthingmeetuppresentation-161130183500/75/Anonymous-Individual-Integration-for-IoT-37-2048.jpg)
Uploaded byPaul Fremantle
Anonymous Individual Integration for IoT
This document proposes a new model called OAuthing for federated identity, access control, and data sharing in IoT. It describes the growth of IoT devices and privacy/security issues. The model includes a Device Identity Provider (DIdP) that provides anonymous identities and tokens, a Personal Cloud Middleware (PCM) that runs on behalf of each user to filter data, and an Intelligent Gateway (IG) that routes requests based on identities. It presents the implementation including a device bootloader, and prototype results showing it can support 400 brokers handling 10 messages/second each with low latency. Comparisons are made to related work which don't provide the same anonymous identities, registration processes, or personal middleware capabilities.
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 Anonymous Individual Integration for IoT
Anonymous Individual Integration for IoT
- 1. OAUTHING: ANONYMOUS INDIVIDUALINTEGRATION FORIOT Paul Fremantle School of Computing University of Portsmouth
- 2. Agenda • Motivation andbackground • Previous iterations • Model and architecture • Prototype and results • Comparison with related work and conclusions
- 3.
- 4. Growth of IoTdevices
- 5. 2016 Mirai 620Gbps botnet attackbased on IoT devices 5 minutes from On to Pwned
- 7. Problem statement • Todaymany IoT devices are inherently tied to the manufacturer • I want to share data under my own control with trust • Threats include: • Lack of individual credentials • Hacking of data and passwords • Trust in the company to behave well • Data sharing and privacy • Going out of business
- 8. Privacy By Design •7 key principles • Proactive not Reactive; Preventative not Remedial • Privacy as the Default Setting • Privacy Embedded into Design • Full Functionality – Positive-Sum, not Zero-Sum • End-to-End Security – Full Lifecycle Protection • Visibility and Transparency – Keep it Open • Respect for User Privacy – Keep it User-Centric Cavoukian, Ann, Scott Taylor, and Martin E. Abrams. "Privacy by Design: essential for organizational accountability and strong business practices."Identity in the Information Society 3.2 (2010): 405-413.
- 9. Three layer privacymodel User Sphere Recipient Sphere Joint Sphere Spiekermann, Sarah, and Lorrie Faith Cranor. "Engineering privacy.” IEEE Transactions on software engineering 35.1 (2009): 67-82.
- 10. Overall approach andtimeline • First iteration: FIOT • Tokens on devices, user consent to data sharing • Fremantle, Paul, et al. "Federated identity and access management for the internet of things." Secure Internet of Things (SIoT), 2014 International Workshop on. IEEE, 2014. • Second iteration - IGNITE • Unique identifiers per device, Initial performance data • Fremantle, Paul, Jacek Kopecký, and Benjamin Aziz. "Web API management meets the internet of things." European Semantic Web Conference. Springer International Publishing, 2015. • Third iteration: OAUTHING • Device and User Registration processes • Anonymous identities • Cloud based “personal middleware” • Improved testing and performance data • CIOT
- 11. Contributions of thiswork • OAuthing: a new model for federated identity, access control and data sharing in IoT • A clear manufacturing and user registration process for OAuth2 credentials with IoT devices • An approach for using anonymous identities in IoT while allowing users to share data effectively • Personal Cloud Middleware to ensure trust in the server model • A working prototype of the OAuthing model • Experimental results demonstrating scaling in a cloud environment
- 12.
- 13. Scoping • In Scope •Directly Internet-connected devices • Sample device is based on ESP8266 with wifi • IoT Hub (e.g. Smart Home gateway, Connected Car) • Treat individual sensors as attached to the hub • Treat the hub as a Device • Out of scope in the current model • Implicit Data Transfer • Privacy infringement through scanning • e.g. MAC scanning attacks, ambient devices • Devices with multiple owners • This may be extended in future research • Devices that are not directly connected to the Internet • This may be extended in future research
- 14.
- 15.
- 16. Device Identity Provider(DIdP) • Provides secure anonymous identities to devices and issues tokens that authorize devices or services • Allows users to register their devices • Allows users to consent to share data or commands • Offers the Identity Broker pattern
- 17. Personal Cloud Middleware(PCM) • Each user has a server running on their behalf • Originally proposed in Webinos • Personal Zone Hub (PZH) and Personal Zone Proxy (PZP) • Webinos does not deal with running these in a cloud, locating them, etc • A cloud shadow of the user’s devices • Does not persistently store data • Performs summarization and filtering* • Only distributes data according to user consent • Enhances Trust in the Cloud * Not yet implemented!
- 18. Intelligent Gateway (IG) •Validates tokens against the DIdP • Routes requests based on anonymous identities • Applies dynamic authorization policies • As consented by users • Instantiates PCMs in Docker
- 19.
- 20. Device Lifecycle and Bootloader •The device bootloader implements a well-defined lifecycle • Secure device identity is embedded at manufacture time • User registration process based on QR codes
- 21. Information sharing matrix User Profil e MAC HWID Device ID Device Secret Pseud o-nym Bearer Token Device Data UIdP ✔ DIdP ✔ ✔ ✔ ✔ ✔ Manu- facturer ✔ ✔ Device ✔ ✔ ✔ ✔ ✔ IG ✔ ✔ ✔ Data Recipie nt ✔
- 22. Analysis of thesharing matrix • In order to steal data an attacker needs to attack both the DIdP and IG/PCM • The DIdP doesn’t see any device data • The IG/PCM do not see any real identities • Third-party services don’t inherently know any identities • Users may leak it in other ways • The manufacturer and other services only see data that has consent to share • All third-party services / data recipients are equal
- 23. Addressing the securityand privacy problems of IoT • Default passwords • Each device is configured at manufacturing with a secure id • User control • Clear user registration and ownership model • User’s choice of provider • Personal middleware • Fingerprinting and identification • Anonymous Identities • Device/User shadow protects metadata • Summarising and filtering • Consent • No data is shared without consent
- 24.
- 25. Implementation • OAuthing (DIdP) •OAuth2 support, onbound support for popular UIdPs (Google, FB, Twitter), embedded MQTT broker • IGNITE (IG) • Performant MQTT gateway, with pluggable intermediation, launching of PCMs in Docker, OAuth2 scope validation • RSMB Docker (PCM) • Lightweight containers running in Docker • Device Bootloader and Sample Device • Based on ESP8266 low-cost device chip, implements MQTT/TLS, Device and User registration flows • Third-Party App (TPA) • Simple application to demonstrate consent-based data sharing using MQTT / WebSockets / TLS https://github.com/pzfreo/oauthing https://github.com/pzfreo/ignite
- 26. Digital Ocean LON1region Device IdP: OAuthing DIdP Database: Cassandra oauthing.io 2Gb Droplet Cloud Service Provider: IGNITE Docker Controller: dproxy ignite-iot.net 2Gb Droplet Personal RSMB Brokers Personal RSMB Brokers Personal RSMB Brokers Personal RSMB Brokers Personal RSMB Brokers Personal RSMB Brokers Personal Zone Hub: RSMB MQTT collector Test Manager 4Gb Droplet Stats analyser Test Load Driver 4Gb Droplet 50 virtual clients Up to 10 TLDs per test Key Datacenter Droplet/cloud instance Docker Container Test Environment and Harness
- 27.
- 28.
- 29. Individual anonymous integration •On a 2Gb Digital Ocean droplet • 400 MQTT brokers • Handling 10 messages / second each • Based on pseudonyms • With OAuth2 based consent
- 30. Memory and codeusage on ESP8266
- 31. One Second Clientresults
- 32.
- 33.
- 34.
- 35. Analysis of results •The model can be implemented effectively • The additional latency on data messages is ~1ms • Not noticeable compared to average mobile Internet latencies of 100-1000ms • The “first connect” performance is also acceptable (it takes the device 3-10 secs to associate to Wifi) • The additional memory usage of the bootloader on the device is acceptable • 400 PZH servers can be run on a $20/month cloud server • $0.60/year/user cost can be further reduced with optimization • Supporting each user with 100 devices each communicating every 10 seconds
- 36. Potential Use Cases •Wide: Supporting the EU GDPR • Ensuring full consent for all IoT data sharing • Specific: Connected Medical Devices • Only sharing specific data or averages • Avoiding sharing all data with the manufacturer • Better compliance with regulatory systems • Specific: Industrial IoT • High security and privacy required around smart production lines
- 37. Comparison with relatedwork • OAuth for Devices • Previous work offers OAuth2 models for devices: • FIOT [8], IGNITE [9], IOT-OAS [1], COMPOSE[14], OAuth1 for MQTT[13], IBM Watson, AWS IoT • None of these provide: • Anonymous Identities • Clear automated registration processes or • Personal Cloud Middleware • Webinos • Concept of Personal Zone Hub – personal middleware • Does not address usability of PZH, how to configure and run in a cloud • Does not support federated identity to the device • IoT@Work [16] • A model for anonymous identities for IoT • No separation of identity management and data sharing systems • No federated identity models [n] References refer to the bibliography in the paper
- 38. Further Work • Formalmodels • In one of CSP/Event-B/Tamarin • Implementation of updated model “OAuthing 2” • Detailed threat analysis and threat modeling • Intersection with Blockchains and Distributed Ledgers • Use of blockchain to validate identity, ownership, manage consent, provide an audit trail of IoT lifecycles
- 39.
Editor's Notes
- #21 @startuml start :**Manufacture** (the device is created); :**Client Registration** (the device is registered with OAuThing as a OAuth2 client); :**Purchase** (the device is physically in the hands of a user); repeat :**User Registration** (the user takes ownership of the device and allocates it permissions); :**Use** (the device is now publishing data and acting on user commands); repeat while (reset ownership) @enduml