[Iot-onboarding] UX concerns with BRSKI

[Michael Richardson <[e-mail]>]

Hi, I have been discussing UX issues with BRSKI and various IoT onboarding
schemes with Scott Jenson of Google's Android IoT team.  He is now on this
list, and I wanted to share his notions.

He wrote:

sj> I'm going to assume that my aspirations line up with ANIMA/BRSKI but not
sj> completely. My goal is to figure out how to build the following flow:

sj>   - You install a large number of devices in a location
sj>   - They power up, auto connect to WiFi (or your favorite wireless transport)
sj>   - They are validated and secure endpoints are set up
sj>   - The devices are NOT allowed on the network yet (for Wifi, they could be on a subnet)
sj>   - Each device points to a schema so it's clear what each wants to do (light, switch etc)
sj>   - The user is informed of these devices en masse
sj>   - The user can see who they are from and that they have been validated
sj>   - With a button push, they are allowed on the network
sj>   - (further discussion about auto configuring the lights to be controlled by the switches)

I think that this goal was well within what many others want to do.
There are some details that need sorting out.

sj> Thanks for that. Without more market research, it would be foolish to say
sj> anything too strong but both cases seem likely to have UX problems

sj>   - Sales channel integration: potentially lots of logistical challenges
sj>   (e.g. inventory, last minute router changes, etc)
sj>   - No sales channel integration: 'first one wins' (this one seems the
sj>   most problematic)

sj> What I'm trying to solve is the "HomeDepot" use case where you buy your 30
sj> switches from HomeDepot and it 'just works' when you turn them on.
sj> Obviously this has no sales channel integration.

This is indeed a common case.
And the lack of sales channel integration makes it difficult
Eliot has a presentation which is linked from:
     https://www.connections.iiesoc.in/2018-abstract

sj> You're actually asking quite a bit of the device makers to support BRSKI
sj> (which I support btw) I wonder if it's time to make the ROUTERS actually
sj> have some additional smarts.

I agree that a BRSKI client is additional functionality, and that in some
cases this is an issue of code space in some devices.  For any device built
around the Google Android IoT platform (which is an RPI scale device) that's
just an issue.  The issue if time-to-market, and this is where reference
libraries come into play.
I expect to finish a reference client library in RUST this fall, with
the goal of fitting into RIOT-OS scale platforms.  Whether it wil have DTLS
or just EDHOC remains to be seen.

sj> Would it be possible to have these smart
sj> devices somehow tell the router who they are before they turn on? Here are
sj> some thoughts:

sj>   - All devices have an NFC in the packaging

Many of us have significant problems with NFC. (or BTLE).
It's just pushing the onboarding problem to a different layer!

Some years ago (2012!) the conversation we had at one workshop about what
would happen if someone walked through HomeDepot and collected the NFC from
all devices.  There was a bit of a gap of onboarding understanding, but
the attack was what if attacker collects control information on hundreds of
thousands of lightbulbs... consider if most of the lightbulbs were smart
bulbs which were purchased by people who didn't have smart lighting systems,
because cost of making smart lightbulbs was not more than dumb bulbs (after
marketing and distribution, etc. costs), so the attacker somehow retained
control over the bulbs.

{Then attacker turned them *ALL* on at the same time, and then 2 minutes
later, turned them all off.  Wait five minutes, and turn them back all on and
off again. Apparently, this can break the electrical grid as turbines turned
on, and then had nowhere to send the power.}

So, summary is that I'm skeptical about the NFC solution.
The security proposes of "near" seem to fail given an equipped attacker.

sj>   - You tap this on the router. For the next X minutes, any device of that
sj>   type is captured and an exchange with each device allows this
sj>   cert/code/etc

.. or you tap it with your phone, which has an API into the router.

sj>   - This works for families of devices so you only need to tap 1 of the 30
sj>   switches you bought

this is a problem if you have some devices, and your neighbour has some devices.
It sounds like a nice idea, but without sales channel integration to know
which of the 29 devices are also on the same sales receipt, it's gonna fail.
An annoyance, I agree.

sj>   - There is nothing stopping this from being an app for that router, that
sj>   way your phone taps the box, not the router

:-)

sj>   - Your same exchange with the MASA occurs, this just makes sure the
sj>   right Router wins
sj>   - If you're willing to make this only use a phone tied to the router, a
sj>   QRCode could work as well.

Yes, I prefer this, and this is the direction WiFi Alliance's DPP has gone.

sj>   - This implies things could work without internet initially, you just
sj>   need the router to be powered on

many would like this.

sj>   - This same app could show the 'families of devices' that are available
sj>   and waiting for confirmation. This is a good prompt for what you should be
sj>   scanning.(or what you've forgotten)

I think it is reasonable for the router to get a list of devices that are
trying to connect, and then you can have a list on the phone devices to
"find".  It's like the egg hunt on Easter Morning.

sj>   - The only downside is that you might see nearby devices that aren't
sj>   yours. However with the coming RTT spec in Wifi 802.11az there is a good
sj>   change to order them so the neighbors are clearly further away.

That's a good idea, but given that the upstairs apartment can be closer than
the third bedroom of my apartment, not always going to work.

sj> What do you think? Is it asking too much to change the routers? I assume
sj> they have to change already to support the BRSKI protocol. I'm just
sj> throwing out an NFC reader and/or an app to act as one. (both are more
sj> expensive clearly)

APP wins.


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-