Tom Phinney writes:
> That would be all well and good for an industry standard, such as 
> WirelessHART (which itself mandates a different secure way to do that 
> initial provisioning). But it's unlikely to be acceptable for something 
> that purports to be a communication standard, since mandating a specific 
> type of auxiliary provisioning channel is unlikely to be acceptable to 
> the wider community.

Most commonly devices currently either automatically trust the first
network they connect to, and can receive initial configuration from
that network.

For example lots of wifi devices will create their own wifi-network
for configuration. I.e. you connect to this "config" network take http
connection to some ip-number in there, and then you get web page where
you can config the device. During that process you install admin key
and provide other network setup information. All this is stored on the
stable storage and after that the device boots up normally using the
stored network setup.

If you need to do that again (reprovision) you press some button or
something during the bootup and it will reset all configuration.

Another setup is that devices just boot up and join the first network
they can see, and then you can for example use some application in
your phone, which will search those devices from the network and allow
you to do the initial configuration for them.

Or the devices might come with a code that you use to log in the
vendors cloud service, and install the configuration there, and then
when the device boots up it always connects to that cloud service to
download the configuration.

The problem with wifi setups is that before you can do the last two
ways of configuration you need to get credentials for the network,
i.e. you need the wifi network key before you can connect to the net,
which is why the first setup might be there in addition to the last
two...

For IoT in home environments I would think the best option would be to
have raw public key on the device, and during the initial bootup the
device joins whoever is there, and tries to download configuration
from some server from there. During this process it authenticates
himself with that raw public key, and the server can then either
accept it directly or it can match it against the list of raw public
key fingerprints configured to it (i.e. they might have been printed
to the side of device in QR code, or they might be distributed using
email or some other electronic method).

During this initial provisioning the device cannot authenticate the
network, but network can authenticate the device. Once the initial
provisioning is done, the device stores the network authentication
information to the stable storage (for example the fingerprint of the
JCE) and after that for later bootstratps it can authenticate the
network too. 
-- 
[email protected]

_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to