Re: [Iot-onboarding] UX concerns with BRSKI

[Ted Lemon <[e-mail]>]

Wouldn’t it be simple enough for the devices to just not be responsive until installed?

Sent from my iPhone

> On Sep 1, 2019, at 13:07, Michael Richardson <[e-mail]> wrote:
> 
> 
> 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 =-
> 
> 
> 
> -- 
> Iot-onboarding mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iot-onboarding