Intel’s Support For FIDO Device Onboarding

How do you get a brand new device out of its box and securely configured on your network without having to do more than plug it in and turn it on? Now how do you do this for thousands or millions of IoT devices?

Intel reckons the solution, or at least part of it, is something called FIDO Device Onboard, and I’m inclined to agree with them.

FDO is

“An automatic onboarding protocol for IoT devices. Permits late binding of device credentials, so that one manufactured device may onboard, without modification, to many different IoT platforms.”

Intel is part of an alliance called FIDO that wants to solve the password problem. You may know them from the little security keys some people use for multi-factor authentication. I have a Yubikey, and it’s great, particularly for website that support Webauthn.

This alliance of manufacturers and cloud providers and a bunch of other tech companies has come up with the FDO standard for doing secure device onboarding based on some earlier work Intel did on a thing called Secure Device Onboard. Instead of starting from scratch, the alliance took over the concepts from Intel and improved and changed them to turn it into FDO, which is an open standard with supporting open-source code.

You might already be familiar with server provisioning using stuff like PXE boot or Jumpstart, and it’s a similar idea. But onboarding of PCs is fairly simple by comparison, because with IoT there are lots of different hardware platforms, operating systems, interfaces, all kinds of things. It’s a more complex problem than standardising Windows Server installs for your datacentre.

The idea is to be able to ship a device to the install location without having to first ship it to a central configuration lab. Someone at the site installs it and plugs it in, and the device then connects to some network-based service (could be cloud, could be a private service) and automatically gets configured.

How It Works

There’s an ownership voucher concept that functions as a key, and a rendezvous service that the IoT device knows to look for which functions a bit like DNS. The cloud that will configure the IoT device receives the ownership key when the device moves through the supply chain and gets purchased by the end customer, and uses it to register itself with the rendezvous service. This is a bit like putting your public key out on all the known keyservers so if anyone wants to know what the key is for a given email address, or the email address that matches a key, it’s easy to find out.

When the device is powered up for the first time, it looks for the rendezvous service and asks it who its owner is (as defined by the ownership voucher), and then talks to its owner’s configuration cloud (or local network service) and authenticates. Then configuration takes place over a secure channel between the device and the owner, doing all the setup the device needs that is specific to that device owned by that customer.

I recommend watching Intel’s video from XFD6 to get a walkthrough of the process with a handy diagram.

It’s a fairly straightforward process (the complexity of the cryptographic software and rendezvous lookup/handoffs notwithstanding) that uses a bunch of well understood concepts to build something that we genuinely need. It looks like something that will definitely happen and I can see it being the way we just all accept as the way IoT device onboarding happens. And it won’t take much to have it be everywhere very quickly. A few major cloud providers and IoT device manufacturers adopting it will quickly get everyone else simply using it.

If it works as well as it seems it should, there won’t be any big advantage to using your own proprietary supply chain onboarding process any more. It’s just be a huge amount of additional cost, and you’ll be incompatible with everyone else. There’ll be a strong incentive to adopt the industry standard that will be hard to ignore.

The alliance is working with the LF Edge Foundation (a directed fund of the Linux Foundation) to build an open-source reference implementation for the software part of FDO, so you’ll have something that actually works in practice, not just some paper spec.

Why This Matters

The manufacturer of the device doesn’t need to know the end-user who will purchase the device. That decouples the ends of the supply chain, which makes them more flexible and resilient. Tightly coupling the build of the device from where it ends up makes it more fragile. What happens if your device gets lost in transit? You can’t just swap it for any other one, you need one built for that customer. What if the device is deliberately intercepted and stolen to pretend to be you? Harder to do if it’s not configured until it gets installed in the secured location. You just own a blank device, well done.

It’s much more like getting a phone: every iPhone is the same until it gets configured by you. You can just build lots of identical iPhones, and pre-ship them to locations where they’re needed, you can have spares, all kinds of things become easier to manage because you have more options to suit the varied needs of your operations.

Late binding means you can make a choice about carrying inventory. You could still manufacture devices just-in-time if you want, and only maintain very low levels of inventory for efficiency, risking delays and stockouts if something goes wrong with the JIT process. Or you could decide to carry safety stock so you can keep customers happy while you work to resolve any supply chain issues.

And if you’re trying to ship thousands, or millions, of IoT devices to customers all over the world, you need this level of flexibility because your customers will have different ways of doing things. Some of your VARs or retailers will want to carry inventory, some won’t. The FDO standard allows for both, which is cool.

Standards are very useful when they address the common use-case, but above that you need flexibility to adapt. You want a common standard you can rely on as being the same everywhere, and it needs to be good enough to build upon, but is flexible enough that you can build almost whatever you want on top of it.

It’s still early in the process, but Intel believes things will mature very quickly and we’ll start to see people build out ecosystems of products that work with this standard quite quickly. I tend to agree, and I look forward to making some major improvements on what is currently a massive binfire of IoT security and device management generally.