Re: [m2m-iwg] Consumer device security (was: M3DA presentation)

[T-Rob <t.rob.wyatt@xxxxxxxxxx>]

Rick,

How about this for user experience...

User signs onto a local web-based dashboard and enters or scans the unique 
ID of the device.

User powers up the device and presses the WPS button on the router.

The device is now provisioned locally.  The dashboard is populated with 
the device details including version, supported behaviors, etc.

If there is network connectivity, the dashboard is also populated with 
vendor information. 

Depending on the device type, the dashboard may also now display options 
to send data to the vendor and/or receive data from the vendor.  These 
options could include graduations in the granularity or types of data and 
even the ability for the vendor to send control commands for some device 
types.

Depending on device type, the dashboard may offer options to send data to 
3rd parties.  For example, a dimmable bulb might offer to participate in 
discretionary load control by exchanging data with the power company.

On the local network, the device publications can be subscribed by any 
authorized user app or device.


In this scenario, the gateway device isn't vendor specific but just an 
MQTT app running on the local network in a set-top box, game console, NAS 
drive, PC or whatever.  There's a little bit of magic in the provisioning 
in that the DHCP server has to be set up ahead of time to internally NAT 
the MQTT port to the MQTT broker.  The device just uses the DHCP address 
as the MQTT address for pre-provisioning.  Also, the device ID has to 
match the expected X.509 certificate identity.  Other than that, it's 
mainly a matter of defining the topic schema so devices know how to query 
for provisioning details. 

There's also no reason all devices have to go to the *same* MQTT broker, 
or that the broker be local.  Any device that doesn't find a local broker 
or the DHCP address isn't NATted will connect to the default address 
programmed by the vendor.  So the degrees of functionality are:

1) No network:  Device behaves like dumb version of same category device.

2) Current technology WPS router, no local NAT, no local MQTT broker: 
Device connects to vendor who provides additional functionality, web app, 
phone app, etc.

3) Device finds local MQTT broker, attempts to register, fails: Same as 
#2.  If device is registered, owner receives exception notice.

4) Device finds local MQTT broker, successfully provisions: Bob's your 
uncle.


-- T.Rob


m2m-iwg-bounces@xxxxxxxxxxx wrote on 03/18/2013 12:39:13 PM:

> From: Rick Bullotta <rick.bullotta@xxxxxxxxxxxxx>
> To: m2m Industry Working Group <m2m-iwg@xxxxxxxxxxx>, 
> Cc: "m2m-iwg-bounces@xxxxxxxxxxx" <m2m-iwg-bounces@xxxxxxxxxxx>
> Date: 03/18/2013 12:39 PM
> Subject: Re: [m2m-iwg] Consumer device security (was: M3DA presentation)
> Sent by: m2m-iwg-bounces@xxxxxxxxxxx
> 
> I think the other important question to ask instead is whether this 
> is indeed an optimal connected device model (each device connected 
> directly) or does it make more sense to leverage a more intelligent 
> "gateway" that can deal with a higher degree of security (read: more
> capability required to implement it) than a "dumb" device on a 
> local, isolated network...
>