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.

1. OAUTHING:
ANONYMOUS INDIVIDUALINTEGRATION FOR IOT
Paul Fremantle
School of Computing
University of Portsmouth

2. Agenda
• Motivation and background
• Previous iterations
• Model and architecture
• Prototype and results
• Comparison with related work and conclusions

3. MOTIVATION

4. Growth of IoT devices

5. 2016 Mirai
620Gbps
botnet attack based on IoT devices
5 minutes
from On to Pwned

7. Problem statement
• Today many 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 privacy model
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 and timeline
• 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 this work
• 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. MODELAND
ARCHITECTURE

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. IoT today

15. The
OAuthing
Model

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. Device

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
HW ID
Device
ID
Device
Secret
Pseud
o-nym
Bearer
Token
Device
Data
UIdP ✔
DIdP ✔ ✔ ✔ ✔ ✔
Manu-
facturer
✔ ✔
Device ✔ ✔ ✔ ✔ ✔
IG ✔ ✔ ✔
Data
Recipie
nt
✔

22. Analysis of the sharing 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 security and 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. IMPLEMENTATION

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 LON1 region
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. Live demo?

28. 2 minute demonstration video

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 code usage
on ESP8266

31. One Second Client results

32. Stress test results

33. Introspection performance

34. Connect latency

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 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

38. Further Work
• Formal models
• 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. Questions?