First, I disagree with Jari's original analysis of the problem. The
Internet security problem is not limited to IoT:
* The use of TLS in most protocols is subject to downgrade attack
* DNSSEC zones are being signed but virtually no-one is changing
behavior based on signature verification results.
* Only 0.1% of email users have enabled an end-to-end security
solution and most of those use it less than 1% of the time.
* We still use passwords as these are the only ubiquitous
authentication mechanism that is compatible with every protocol.
* The set of secure SMTP authentication mechanisms that are supported
by every widely used email client is the null set, as is the
intersection between the set of secure authentication mechanisms
supported by the default clients on many widely used platforms and
many of the major mail services.
* It takes an expert user over 15 minutes to configure Thunderbird to
use an S/MIME certificate. To configure OpenPGP it is necessary to
download a plugin.
And I could go on and on and on.
So what is different about IoT?
I think the big difference is that in IoT it is impossible to ignore
the usability problem that cripples most IETF security protocols. With
the new EC curves we can now do public key crypto on 16 bit and even 8
bit devices (just don't do it too often). But we are still constrained
by the affordances of the devices:
* IoT devices don't always have display capability
* IoT devices often don't have a keyboard device.
Once we recognize the fact that our principal constraints are
usability constraints, we can develop an architecture that addresses
the problems of the IoT world and also the Internet in general.
We are not going to be able to configure cryptography or any other
settings on an IoT device. But we have a variety of protocols that can
be used to connect an IoT device to a 'secure console' where
administration takes place:
* Device has an LED status light and a QR Code with the SHA-2 digest
of a public key printed thereon. Administrator connects device through
a mobile app that uses the camera.
* Device has an SD Card with a site specific O/S build that includes
the 'connection authentication key' of the site. This is then used
together with the MAC address to bootstrap a connection.
Now I am not going to go through the math or the protocol here, but
those of you with crypto knowledge will know how to solve those use
cases. Configuring wireless is harder than wired of course as you have
to configure the WiFi settings. But that could be sorted with a change
to the WiFi specs to add a standardized 'calling channel' SSID.
This is the set of problems I think I have solved with the
Mathematical Mesh. If you go to my Web site http://prismproof.org/ you
will see a demonstration of the Mesh in action. First a Mesh profile
is created on one machine. The profile manager automatically adds in
S/MIME configuration data to the email account on the first machine
(will be OpenPGP as well in the future).
Then a second machine is connected to the profile. This is initially a
completely blank machine with no email account settings at all. When
the machine is connected to the Mesh profile (using mutual
authentication, naturally), all the email account settings are copied
into the second machine.
The problem of connecting up a lightswitch or a light is essentially
the same. I am using the same exact approach to connect up components
within my robots. My plans to motorize my dalek prop involve three
separate controller boards, one for the base, another for the
shoulders with the gun and manipulator arm, a third for the eyestalk
and lights on the dome. The controller boards all exchange secure
messages with a controller hub.
http://prismproof.org/