ThingsCon Amsterdam 2016 - Spec the Stack workshop

29
Spec the Stack Trusted layers for IoT Michelle Thorne & Martijn Thé ThingsCon Amsterdam 2016

Transcript of ThingsCon Amsterdam 2016 - Spec the Stack workshop

Spec the Stack

Trusted layers for IoT

Michelle Thorne & Martijn Thé ThingsCon Amsterdam 2016

Intros

Michelle Thorne

● Mozilla Open IoT Studio

● Internet optimist● Open source

activist● @thornet

Martijn Thé

● Software Engineer @ Pebble

● IoT optimist● Background in UX● [email protected]

Workshop Overview

Draw an object you trust. And then one you don’t.

What earns your trust?Why do you trust it?Why not?

Discuss.

Put your creator hats on.

As a creator, I need [...] to make trustworthy IoT.

Discuss.

The state of the stack(s) as we understand it.

What does the stack tackle?

● Device on-boarding

● Device & Service discovery

● Ways of automating/integrating the inputs & outputs from various devices

● “Built-in” user interface

● Bridging between “transports”(WiFi ⇔ Bluetooth ⇔ Zigbee ⇔ …)

● ...

Security?

● Privacy● Access control (both user access and

other-device access)● What is exposed to the internet?● Does it assume that devices on your

local network are all trusted?● Reliability: what are the failure modes?

Where does the system “live”?

● 3rd-party-owned cloud servers vs the device that you own itself

● Data ownership?

Who is the target audience?

● Notion of “IoT” is super broad: Agricultural sensor nets? Smart home? Medical devices? Smart city infra?

● Consumer Electronics○ Ease of use, i.e. friendly

on-boarding○ Small, simple network○ ...

● Enterprise○ Configurability (at the cost of

usability)○ Large scale○ Multi-site/network deployments○ …

● Open Connectivity Foundation (OCF) and its stack “IoTivity” seems to have momentum.

● 3 standards consortiums have been merged into OCF this year or have announced a working relation with OCF.

● See Notes handout for more details.

Converging Consumer

Electronics IoT stacks

Reflect on what’s already out there.

Where from here?

Thank you!

Notes

The Physical Web / Eddystone

● “Walk up and use anything”● Built into Android 7 lock screen● Built into Chrome iOS lock screen widget● Thing uses Bluetooth to broadcast URL to web page that is the interface of

the thing● Smartphone (app/OS itself) scans for broadcasts and shows titles of the

HTML pages on the lock screen.● Only a device+UI discovery mechanism, nothing more.

https://google.github.io/physical-web/

Also https://flyweb.github.io/

BLE Broadcast

GEThttp://

Source: https://youtu.be/1yaLPRgtlR0

W3C’s Web of Things

● “Web Things” are uniquely identifiable by an http(s) URI● URI points to web service implementing a well-spec’d REST-style HTTP API

to get (meta)data, invoke actions, …● The web service could be implemented on the Thing itself, on a proxy

device on the LAN, or in the cloud.● User interface (HTML page) is optional. (Are they assuming a “one size

fits all” browser/app to control all devices?)● Discovery, security and many other concerns: work in progress… ?

https://www.w3.org/WoT/

https://www.w3.org/2016/09/IoTW/white-paper.pdf

CoAP (Constrained Application Protocol)

● HTTP/REST “replacement” for devices that are too resource-constrained to run TCP + HTTP + TLS.

● Built on top of UDP + DTLS.● Proxies that translate CoAP<=>HTTP/REST to make these devices accessible

with any HTTP client and partake in the Web of Things.● Q: Client authentication? Access control? See IoTivity, which builds on

top of CoAP and addresses these things.

http://coap.technology/

UPnP (Universal Plug and Play)

● Covers: addressing, device discovery, device/service description, control/actions, event notifications and optional URL to user interface (web page).

● “Big” footprint: built on IP + HTTP + XML/SOAP● By default no authentication. History of security vulnerabilities.

Supposed to be fixed in newer stacks.● “UPnP is generally regarded as unsuitable for deployment in business

settings for reasons of economy, complexity, and consistency”*

* https://en.wikipedia.org/wiki/Universal_Plug_and_Play

IoTivity (sponsored by Open Connectivity Foundation)

● Covers: device discovery, extensive service functionality, security provisioning and access control.

● Application message routing through devices that can bridge multiple PHY technologies (i.e. bridging WiFi ⇔ ethernet ⇔ Bluetooth).

● Security is an integral part of the stack.● Leveraging CoAP-REST for inter-device connectivity.● Free, open source Java/C/C++ reference implementations.● Quite new (1.0 released in Dec ‘15), not many deployments in the wild.● IoTivity is supported by the Linux Foundation.

https://www.iotivity.org/

● Covers: new device on-boarding, device & service discovery, notifications, events and actions APIs, optional app-level authentication and access control, UI control panel service.

● Like IoTivity: Application message routing through devices that can bridge multiple PHY technologies (i.e. bridging WiFi ⇔ ethernet).

● “On event X take action Y” rules engine built into AllJoyn Router library, running locally, not in the cloud.

● Open source Linux Foundation project● Battlefield tested (in use in 250M products worldwide**)

* https://allseenalliance.org/framework/documentation ** http://bit.ly/iot-overview-2016-aaron-vernon

AllJoyn

iot.eclipse.org

● Loose collection of open source projects + protocol implementations in the IoT space, ranging from smart home to industrial sensor nets.

https://iot.eclipse.org/

“Proprietary” Frameworks / Stacks● Apple Homekit – https://developer.apple.com/homekit/

○ Device makers need to partake in Apple Homekit program (under NDA) and buy authentication chips from Apple to make their devices work with HomeKit.

● Samsung SmartThings – http://developer.smartthings.com/ ○ Focusses on the “business logic” between devices. Offers an API to

tie devices with different connectivity technologies into the SmartThings ecosystem.

○ Most scenarios require devices to be connected to the internet and SmartThings servers (directly or through a SmartThings Hub) in order for automations to work.

● Zigbee – http://www.zigbee.org/ ● Nest Weave –

https://developers.nest.com/documentation/weave/weave-overview/ ● Google Weave & Brillo – https://developers.google.com/weave/● …

Open Connectivity Foundation (formerly known as OIC)

● Both Alljoyn/AllSeenAlliance and UPnP/UPnP Forum recently merged into OCF.● Goal seems to be to make these (previously competing) stacks interoperate

with each other. It’s unclear at this point how this is going to work exactly.

● The Thread Group (802.15.4 based IP mesh network protocol, backed by Google/Nest) also announced a “liaison agreement” to work together.

● OCF members include Samsung, Intel, Microsoft, Qualcomm, GE, MediaTek, Cisco, Electrolux, …