Your chance to try and chime in on Manufacturer Usage Descriptions, a way to protect IoT devices.
You may recall that I am working on a mechanism known as Manufacturer Usage Descriptions (MUD). This is the system by which manufacturers can inform the network about how best to protect their products. The draft for this work is now about to enter “working group last call” at the IETF. This means that now would be a very good time for people to chime in with their views on the subject.
In the meantime, MUD Maker has also been coming along. This is a tool that generates manufacturer usage descriptions. You can find the tool here.
MUD isn’t meant to be the whole enchilada of IoT security. Other tools are needed to authenticate devices onto the network, and to securely update them. And manufacturers have to take seriously not only their customers’ needs, but what risk they may impose on others, as Mirai reminded us. Had MUD been around at the time, it’s possible that Mirai would not have happened.
It’s hard – but not impossible – for Things to connect to a home network in some sort of automated fashion.
What’s the right way to connect a Thing to your home network? Way back in the good old days, say last year, in order to connect a device to your home network, you could do it easily enough because the system had a display and a touch screen or a keyboard. With many Things, there is no display and there is no keyboard, and some of the devices we are connecting may themselves not be that accessible to the home owner. Think attic fans or even some light bulbs. A means is needed first to tell these devices which network is the correct network to join, and then what the credentials for that network are. In order to do any of this, there needs to be a way for the home router to communicate with the device in a secure and confidential way. That means that each end requires some secret. Public key cryptography is perfect for this, and it is how things would work in the enterprise.
WPA2 Enterprise makes use of individual keys and a flexible means to authenticate individuals and devices. It looks a little like this:
EAP stands for Extensible Access Protocol, and it is just that. There are many different authentication mechanisms available with EAP. One method called EAP-TLS calls for both sides of the communication to transmit a certificate in an authentication transaction that contains their identities as certified by someone. Initially, a device may be certified by its manufacturer, but then later it would use a certificate that is certified by the local network system.
One challenge is getting the device certificate to be known by the network. One simple method to do this is to have an application tied to a camera that scans a QR code that points to a URL containing a signed copy of the device’s identity or certificate. For instance, the QR code to the right encodes this URL:
which in turn gets you a certificate. The next challenge is whether the device should trust the network. In the enterprise, there is a new approach being developed known as Bootstrapping Remote Secure Key Infrastructures (BRSKI) (sometimes pronounced “brewski”). In this case the manufacturer tells the device that the network is the correct one to join by essentially providing the device the network’s operational trust anchor. This allows the device to validate the network’s certificate.
That’s something of a tall order even in the enterprise, but one that is worth aiming for. If the home can leverage a service offered either by a service provider or by a new fangled home router company, if THEY can authenticate the home, and the manufacturer can authenticate them, then we have ourselves a ball game. More work needed to get all the elements in place.