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/