IoT Mobile App/Device/Field Gateway and Cloud Identity &

Security architecturePrepared By Vinod Wilson

Architect, Crestron Electronics

Agenda

• Communication Strategy

• Current Architecture• Problems in current architecture

• Multiple IDPs

• Usability

• Synchronization

• Identity / Authentication / Authorization ( IAM & IRM )

• Cloud Capabilities

• Proposed Solution

Communication Strategy

• Cloud First

• Mobile First

• Offline First

• Offline First

• Mobile First

• Cloud First

Problems in Security architecture

• Strategy changed from Offline-First to Cloud First• User Experience

• User has to wait for 10 minutes to really connect to any device

• Multiple IDPs

• Identity• Identity and Access Management (IAM)

• Roles & Group policy

• Roles & Group policy per device

• Identity Relationship Management (IRM)

Identity

• Identity = set of attributes related to an entity [iso 29115]

Entity Identity6’ 5” TallGrey Hair Man

Work

Husband

Father

Women

Mother

Daughter

Wife

Girl FriendFriend

Boss

Collegue

Identity is Context DrivenFor each context, the attribute differs

Identity1

Identity2

Identity3

Evolution of Identity

Employees

Consumers

Employees &

Partners

Things

PerimeterPerimeter

Federation

Perimeter-less

Federation

Cloud / SaaS

Perimeter-less

Federation

Cloud

SaaS

Mobility

Attributes

Context

Stateless

Relationships

What Identity Layer provides

• Is the user that got authenticatedWho

• Was he authenticatedWhere

• Was he authenticatedWhen

• Was he authenticatedHow

• Attributes he can give youWhat

• He is providing themWhy

Authentication

• The best usability for authentication is never asking you to authenticate, just knowing who you are.

• Authentication involves Trade-offs

Usability

Authentication

• Traditional NTLM / Kerberos authentication

• Claims based Authentication• Protocols

• OpenID Connect

• Attribute & Cryptography

• Authorization• OAUTH 2.0

Claims based Authentication

How OAuth Was Born?

My Brand New Ferrari

Let me Park it

sir!Parking Key

Allow the owner to provide limited authorization to valet attendants

OAuth was created to solve the same core issue online

Claims based Authentication

OAUTH

OAuth2 Client Profiles

• Web Application

• User Agent

• Native

OAuth2 Client Profiles

Web Application User Agent Native

OAUTH Authorization Grant

Mechanics of Token Validation

• Verify that it is well-formed• Token must be digitally signed

• Verify that it is coming from the intended authority• Signature verification

• Issuer value

• Verify that it is meant for the current application

Access control & Policy Management

• Access Control Models• Mandatory Access Control (MAC)

• Discretionary Access Control (DAC)

• Role-based access control (RBAC)• Do not take into account additional parameters such as

• Resource information,

• Relationship between the user (the requesting entity) and the resource, and

• Dynamic information e.g. time of the day or user IP, geolocation coordinates

• Attribute-based access control (ABAC)• XACML (eXtensible Access Control Markup Language)

• UMA(User Managed Access) Profiles for OAUTH 2.0

• In other words selective sharing

User-Centric

Web Application Access Control

if (User.IsInRole("Role01") || User.IsInRole("Role02") || User.IsInRole("Role03"))

{

return RedirectToAction("Secure", "Home");

}

else

{

return RedirectToAction("Index", "Home");

}

1. Roles & Group policy per device

2. Change the user role Dynamically

1. Change the role in the token or get a new token from AS with a changed role

2. Manually apply the logic of role change

Identity Problems in IoT

Unreasonably large number of relationships among an unreasonably largenumbers of people and things

Identity Relationship Management ( IRM )

• Person-to-Person

• Thing-to-Thing

• Person-to-Thing

Identity Relationship Management ( IRM )• Relationships must be scalable

• Actors, Attributes, Relationships, AdministrationScalable

• In a traditional IAM scenario, we pass actionable information to the back-end for a classic request-response authorization modelActionable

• PYNG-HUB was made by CrestronImmutable

• Temporary

• PermanentTransferable

• Single-party Asserted, Multi-party AssertedProvable

• Must all parties in a relationship acknowledge they are in a relationship?Acknowledgeable

• Can either party revoke a relationship?

• Does this imply the idea of cascading deletes?Revocable

Identity Relationship Management (IRM)

• In an IRM (and IoT) world• There is little to no connectivity to a backend authority

• That a back-end authority simply does not exist

• Does a protocol exist today?

• NO

• But anything is happening to address this issue?

• YES

So Far - Recap

• Identity

• Authentication

• Access & Policy Management

• Identity relationship management ( IRM)

Multiple IDPs and Synchronization Problem

Azure AD

Cloud ServiceCloud App Service

Authentication

• Traditional NTLM / Kerberos authentication

• Claims based Authentication• Protocols

• OpenID Connect

• Attribute & Cryptography

• Authorization• OAUTH 2.0

Synchronization – Microsoft Sync Framework

Synchronization

• History• Microsoft Sync Framework

• 1.0 Published on 2006

• 1.0 SP1 Published on 4/12/2010

• 2.1 Published on 8/18/2010

• Sync Framework 4.0 October 2010 CTP

• STOPPED

• Azure AD Hybrid problem• Azure AD Connect Preview

• 24 Mar 2015

What others have to say on Identity/Authentication/Authorization?

Security Challenges within IoT Systems

• Designed to operate autonomously in the field with no backup connectivity if primary connection is lost

• The IoT entities will generally not be a single-use, single-ownership solution

• central security management user interface • To enable the homeowner to manage who has the capability to access their home

• Can be used to control other IOT devices that have API’s

• If every IOT device in your home has its own security management web interface, it won’t scale

• Using a central policy decision point (UMA Profile for OAUTH 2.0), people can manage in one place which policies apply to what, without having to go to the web admin page of every device

CISCO IOT Security

• The IoT/M2M endpoints must be fingerprinted by means that do not require human interaction. Such identifiers include• RFID

• Shared Secret

• X.509 Certificates

• MAC Address of the endpoint

• Some type of immutable hardware based root of trust

Third-Party System comparison

• Philips Hue Lighting System• Offline-First

• Away from Home authentication

• Single IDP

• SmartThings Hub• Cloud-First

• Away from Home authentication

• Single IDP

Philips Hue Lighting System

• The bridge communicates directly with the LED bulbs using theZigBee protocol, which is built upon the IEEE 802.15.4 standard

Bride registering with the cloud service

• id (a unique id is assigned to every physical bridge manufactured),

• internal IP address, and

• MAC address (identical to the id)

Controlling Lights via the Website Interface

This website is served from internet

Is button Pressed?

GET /en-US/user/isbuttonpressed HTTP/1.1

Host: www.meethue.com

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3) AppleWebKit/536.28.10

(KHTML, like Gecko) Version/6.0.3 Safari/536.28.10

Accept: */*

DNT: 1

X-Requested-With: XMLHttpRequest

Referer: https://www.meethue.com/en-US/user/linkbridge

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Cookie:[DELETED]

Connection: keep-alive

Proxy-Connection: keep-alive

HTTP/1.1 200 OK

Content-Type: application/json; charset=utf-8

Cache-Control: no-cache

Expires: Thu, 01 Jan 1970 00:00:00 GMT

Set-Cookie: PLAY_FLASH=;Path=/;Expires=Thu, 01 Jan 1970 00:00:00 GMT

Set-Cookie: PLAY_ERRORS=;Path=/;Expires=Thu, 01 Jan 1970 00:00:00 GMT

Set-Cookie: [DELETED]

Vary: Accept-Encoding

Date: Mon, 29 Apr 2013 23:30:06 GMT

Server: Google Frontend

Content-Length: 4

true

Request Response

Complete setup

GET /en-US/user/setupcomplete HTTP/1.1

Host: www.meethue.com

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_3)

AppleWebKit/536.28.10

(KHTML, like Gecko) Version/6.0.3 Safari/536.28.10

Accept: text/html,application/xhtml+xml,application/xml;

DNT: 1

Referer: https://www.meethue.com/en-US/user/linkbridge

Accept-Language: en-us

Accept-Encoding: gzip, deflate

Cookie: [DELETED]

Connection: keep-alive

Proxy-Connection: keep-alive

HTTP/1.1 200 OK

Content-Type: text/html; charset=utf-8; charset=utf-8

Cache-Control: no-cache

Expires: Thu, 01 Jan 1970 00:00:00 GMT

Set-Cookie: PLAY_FLASH=;Path=/;Expires=Thu, 01 Jan 1970 00:00:00 GMT

Set-Cookie: PLAY_ERRORS=;Path=/;Expires=Thu, 01 Jan 1970 00:00:00 GMT

Set-Cookie: PLAY_SESSION="[DELETED]-%00ip_address%3A[DELETED]__[DELETED]

;Path=/

Vary: Accept-Encoding

Date: Mon, 29 Apr 2013 23:30:08 GMT

Server: Google Frontend

Content-Length: 47369

[DELETED]

app.data.bridge = {"clientMessageState":[DELETED],"config":{"lights":{"15":

{"name":"Bathroom 2","state":{"bri":254,"effect":"none","sat":144,"reachabl

e":true,"alert":"none","hue":14922,"colormode":"ct","on":false,"ct":369,"xy

":[0.4595,0.4105]},"modelid":"LCT001","swversion":"65003148"

Request Response

Bridge Now available

Sending commands to the bridge

• The token obtained from the previous step is being sent to the bridge directly along with the commands.

• In Local network• Commands are directly sent to the bridge

• When Away from Home• Commands are sent via the cloud

Controlling Lights Using the iOS App

GET /api/[username MD5 Hash of MacID] HTTP/1.1

Host: 10.0.1.2

Proxy-Connection: keep-alive

Accept-Encoding: gzip, deflate

Accept: */*

Accept-Language: en-us

Connection: keep-alive

Pragma: no-cache

User-Agent: hue/1.1.1 CFNetwork/609.1.4 Darwin/13.0.0

HTTP/1.1 200 OK

Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0

Pragma: no-cache

Expires: Mon, 1 Aug 2011 09:00:00 GMT

Connection: close

Access-Control-Max-Age: 0

Access-Control-Allow-Origin: *

Access-Control-Allow-Credentials: true

Access-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETE

Access-Control-Allow-Headers: Content-Type

Content-type: application/json

[{"error":{"type":1,"address":"/","description":"unauthorizeduser"}}]

Request Response

Identity / Authentication

POST /api HTTP/1.1Host: 10.0.1.2Proxy-Connection: keep-aliveAccept-Encoding: gzip, deflateContent-Type: application/x-www-form-urlencodedAccept-Language: en-usAccept: */*Pragma: no-cacheConnection: keep-aliveUser-Agent: hue/1.1.1 CFNetwork/609.1.4 Darwin/13.0.0Content-Length: 71

{"username":"[username DELETED]","devicetype":"iPhone 5"}

HTTP/1.1 200 OKCache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0Pragma: no-cacheExpires: Mon, 1 Aug 2011 09:00:00 GMTConnection: closeAccess-Control-Max-Age: 0Access-Control-Allow-Origin: *Access-Control-Allow-Credentials: trueAccess-Control-Allow-Methods: POST, GET, OPTIONS, PUT, DELETEAccess-Control-Allow-Headers: Content-TypeContent-type: application/json

[{"success":{"username":"[username DELETED]"}}]

Request Response

Away From Home setup

Away from home setup complete

GET /en-US/api/getaccesstokenpost HTTP/1.1

Host: www.meethue.com

Referer: https://www.meethue.com/en-US/api/getaccesstokengivepermission

Proxy-Connection: keep-alive

Accept-Encoding: gzip, deflate

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Cookie: [DELETED]

Accept-Language: en-us

Connection: keep-alive

User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 6_1_4 like Mac OS X)

AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10B350 Safari/8536.25

Request

SmartThings

The SmartThings Hub uses the ZigBee protocol to communicate

with the nearby devices

SmartThings Statement

• We made the decision at SmartThings to support a “Cloud First” approach for our platform. This means that in our initial release, there is a dependency on the Cloud. SmartApps run in the SmartThings Cloud, so for everything to work, your hub does need to be online and connected to our cloud. This will generally be the case, even when we implement hub-local capabilities as described below.

• We believe in a “connected” service where local capabilities in the hub are meant to improve performance and insulate the customer from intermittent internet outages. We do not plan to support a perpetually disconnected mode.

• We made the decision to limit SmartApps to the Cloud in our first release because it allowed us to focus on the experience of writing the applications and less on the mechanics of deploying that logic locally to the hub.

• That said, we are actively considering implementation scenarios whereby we can distribute SmartApps to—and execute SmartApps locally on—the SmartThings Hub.

• In all cases, we recognize the critical scenarios where a loss of communications with the SmartThings Cloud could have a degrading impact on critical, local use cases, and are being deeply thoughtful on how we minimize the risk of disruption.

Proposed Solution

• If in case the control system also acts as a Identity Provider, other than the central cloud Identity Provider, then for offline-first scenario it is better to cache the credentials in the control system

• Currently there is no standard way to synchronize the cloud IDP and Control System IDP, hence synchronization of identity information between the control system and the cloud should be done using versioning

• UMA profiles should be considered for issues related to IRM