Authenticate 2021: FDO, Vouchers, & Authentication

@youtube

In this video, Bill Leddy of LoginID (VP Authentication and Identity), speaks at the Authenticate 2021 conference about FIDO Device Onboarding (FDO), vouchers, and authentication.

Try LoginID’s FIDO2 Passwordless Authentication Platform for Free HERE

Transcript Below:

David: Thank you for coming to our next session. This one is called FDO, vouchers, and authentication. I would like to welcome Bill Leddy who is VP of authentication and identity at LoginID.

Problems with Critical Infrastructure

Bill Leddy (BL): So, problems, critical infrastructure. We have a lot of exposed critical infrastructure that is subject to attack and IoT devices can be a source of those attacks pretty easily. I’m sure everyone is familiar and remembers the Mirai Botnet attack, ‘admin, admin’ for account and password. Not a good security policy.

These weak low end IoT devices were used to create an attack. This attack was basically launched by college kids who weren’t even trying to be all that bad. It wasn’t very stealthy, it wasn’t even that targeted, and it wasn’t a state actor.

Start thinking about what a state actor could do. This could lead to biblical, apocalyptic proportions. Living dead walking the earth, cats and dogs living together, all those things that have been previously mentioned maybe even in movies.

That may sound like fear porn, really, but maybe not that much because in addition to the Mirai Botnet attack, there were state sponsored attacks including power outages in the Ukraine grid, the Stuxnet attack. Then there were some financially motivated attacks, the continental pipeline, the meat packers, and other things like Wanna Cry.

Imagine that you’re dealing with attackers that are financially motivated or are state actors that can be subject to responding attacks, then maybe they’re rational. But if you have someone that’s just a total terrorist and wants to take the whole thing down, you’re living in a different world.

If you look at the presidential policy directive on the right side, you’ll see all these critical infrastructure things. Think about all the devices that are connected to those systems and how many of those do you think are secure? And we all would pretty much have the same guess.

There is a federal program called FedRAMP that looks at what it means to securely connect to federal systems in the US. There are similar things elsewhere in the world. But, basically, how are we going to secure this infrastructure, and the government is part of this solution. They have a lot of the infrastructure and the regulations to make this stuff happen.

The Device Onboarding Problem

Problem number two, and this was alluded to slightly in the previous talk, on the consumer side some of these devices are so complex that only an 8 year old child could figure it out. I don’t know if anybody over 30 has even got a chance.

In the commercial space, think about all the lights that are in this building. If these are smart light bulbs, how do you get them configured to all be the same? How do you tell they are all attached to the same system? How do you make onboarding easy, so they can easily be managed?

In industry, think about refineries down along the coast, on the gulf coast, with all the remotely operated valves that are in those systems and the difficulty in maintaining them and securing them. And then think about all the movement towards manufacturing and robotics and everything else. How do we make this stuff secure going forward?

When I say onboarding, I don’t just mean secure but also easy to onboard. The previous speaker had a slide about the cost of these things. The cost of the installation of a lot of these things and the maintenance is a lot more expensive than the cost of the device itself, particularly on the low-end side of these devices.

Trust in The Supply Chain

The next problem is trust in the supply chain. We are hearing more and more about this across a lot of different industries. You may have something that is being built in a factory in a country that may be friends this week and then not so friendly next week and maybe should not fully be trusted.

That device that gets manufactured is going to go through multiple levels of distribution, be it a warehouse, and ultimately end up at a retailer who sells it to an owner. Then the owner is going to want to connect that to an IoT management system.

Through the supply chain, who can you trust? Maybe you shouldn’t trust anybody too very much.

FIDO Device Onboarding (FDO) Overview

So, FDO, Fido Device Onboarding, which was kind of explained by Gary and David in the previous talk. Basically, what happens is, when a device is initialized at the factory, a private key is stuffed inside the device and the FDO client is stuck in the device also. So, you’ve got somebody to talk to and it has the ability to prove it is who it says it is.

Then it goes through the supply chain and hopefully ends up in some users hand. Here I say consumer, but it could easily be a commercial or industrial setting. Once the device wakes up, it goes to the rendezvous service, which I view as a dating service, and goes and asks ‘who’s my mother and how should I get configured?’

When it gets that information back, it goes and talks to the onboarding service that’s assigned to it to configure the device. As part of this process there are a wide variety of onboarding services and there will probably be a wide variety of rendezvous services. Those rendezvous services will be configured into the device at the same time that the Fido Device Onboarding stuff is put in at the factory so it knows where to look for endpoints that can be used for the rendezvous hookup.

The thing that’s interesting if you look into the FDO spec is vouchers, which are an important part of this, are pretty much not addressed in the FDO spec. It’s kind of intentional, it’s a hard part of the problem, and the scope the IoT working group bit off is pretty substantial. But, the fact that it’s not in the FDO spec makes it a good opportunity for all of us to think about.

FDO Service Info

One interesting thing the FDO spec has is something called service info. This basically allows custom services to be installed. At the same time that you’re installing that FDO client, at the factory, and essentially that private key, at the factory, you can also put in some custom services. Those services are installed at the factory, but it allows for updates later.

If you have a smart client sitting out on the FDO device, you now have a secure channel where you can talk to it. So, when the onboarding service wakes up, there are a couple of things that will happen. First, it will say ‘who is my preferred owner? My preferred owner’s favorite color is this, preferred temperature is that, time zone is this’. There’s a personal configuration for that owner.

But, the onboarding service could also start populating that device with personality. At the factory, you could build a very generic device and not know who it's going to. When the owner takes possession of that device, it starts talking to the right onboarding service and starts personalizing it for that owner, or for the applications that owner is most interested in.

This is pretty powerful, once you start understanding what this does. You can have a really dumb device at the factory tat gets a lot smarter once the owner takes control of it. You don’t need to have a complex software system installed at the factory, it can be pretty stupid at the factory and can get a lot smarter later because you have a secure path to talk to the thing.

IoT Management is an Identity Problem

To me, IoT is actually an interesting identity problem. We’ve all sat in offices under light fixtures. Imagine that light fixture was installed by a contractor in a building that’s owned by your employer and that building is maintained by a management company. You and your coworkers are sitting underneath that light fixture. Who gets to control that light fixture? Is some guy 6 states away, or should you, from your smartphone, be able to control that?

Based on your attributes tied to your identity and the attributes of that IoT device, we should allow people sitting near that light fixture to select what they want to do. This is where identity and IoT coming together gets really interesting. There are a lot of interesting use cases to look at going forward as IoT gets more broadly deployed.

Solution Based on Standards

Today we have FIDO2 authentication, we have FDO, which is just coming to life now, and we have OpenID. These three things together make for a powerful opportunity to combine digital identity verification, IoT, and be able to manipulate the ownership of IoT devices. Starting with FDO, because you have this initial hook into the device at the factory and then through its life cycle till it arrives at the user.

We can build some pretty powerful things with this and the FIDO alliance is responsible for 2 out of 3 of these. Then, OpenID and decentralized ID are being worked on in other arenas.

Voucher Management

When vouchers initially get created when the device is manufactured, that voucher is created at a voucher management system and installed at the factory. Each time it moves through the supply chain there is an individual associated with an organization who smiles for the camera, swipes a finger, whatever, but uses FIDO authentication to propagate the movement of these IoiT devices through the supply chain.

This allows traceability to see how this device has been moved along from one spot in the supply chain to the next as you go through multiple levels of the supply chain. You use digital identity verification and strong authentication to help secure the supply chain as these things move through.

At the end of the supply chain, you have an owner. The owner, based on identity, could have a preferred IoT management console and automatically hook up their IoT device into their preferred management console and do that quite seamlessly. You know who the owner is, you know what the preferred IoT console is. There’s not 500 IoT that just show up, so you can make this very smooth for the consumer experience as well as for industrial and commercial settings.

Demo

So, we’ve got a little demo and what you’ll see in this demo is a power regulator that’s an IoT device that’s running the FDO protocol. What it will first do is it powers on, then it will reach out to the rendezvous service, then the rendezvous service will tell it where it’s onboarding service is. Then that rendezvous service will populate that device with what it needs to know, then the device will come online and show up in an IoT console.

Demo: In this demonstration we will present usability of the FIDO2 device onboarding standard in industrial enterprise and consumer scenarios. On the left we can see the standard European DIN rail breaker board with three main breakers. One for each electric face and three smaller 16M breakers for separate lines.

To the right of them we have two LoginID developed 210 to 240 volts voltage meters that are FDO enabled. The first meter has already been onboarded via FDO to LoginID’s AWS console. We can see on the right that it already thinks there is a device and if we go to our MQTT test client, we can see the device is sending voltage readings to our service extension topic.

We are now turning on our second device, we can see that it’s loading, the meter is fresh out of the factory, it only has the address of the Rendezvous service, an FDO credential, and a special WiFi configuration. It does not have any AWS configuration or any other kind of information. It will receive all that when onboarding via FDO.

If we look in the top left, we can see that the device has successfully connected to the preconfigured Rendezvous service and has received the address of the device. If you look to the central left, you can see that it has successfully onboarded via the device onboarding service.

The onboarding service, on the fly, via its broker, was able to generate fresh AWS ID credentials and inject them using the service and full extension profile. If we now turn our attention to the right, we can see that the device was able to connect to the AWS MQTT server and is now sending voltage readings to the specified service info extension topic.

If we look at the things dashboard, we can see that another device was added. What this demonstrates is that FDO is able to fulfill three important criteria: control, configuration, and job resource management.

Control is the ability to take over the device by having cryptographic proof of device ownership, a voucher. No voucher, no device. The second, is configuration, the device can literally be configured by turning it on.

This is important for larger industrial and commercial deployment. Most of the IoT attacks today are based on simple credential stuffing and reuse. This issue is unavoidable as long as each IoT device must be configured manually.

Lastly, is job resource management. Instead of having pre-allocated infrastructure protecting such information that is costly and dangerous, you can simply set up the necessary resources on the fly. No cameras, no licenses, no servers. Vice versa.

The all hands nature of FIDO2 device onboarding means that we can connect devices on the fly to our management consoles that have no touch steps, which is really important in consumer and enterprise scenarios. Like in this home assistant demo, where our voltage meters have been automatically added, which enables us to have graphical visualizations of our readings.

We hope that you have enjoyed this demonstration. If you would like to learn more about FIDO2 device onboarding, please visit FDO.cloud.

BL: What we saw there was an IoT device with an FDO client onboard, power up, go find the rendezvous service, the rendezvous service told it where the onboarding service was, then configured the IoT device, the IoT device started doing its thing. There’s a little bit more work here hooking it up to the AWS IoT console but, basically it was populated into the IoT console and ready to use.

The point here is that FDO works, it’s live today, and I’ll talk a little more about our rendezvous server here in just a minute. FDO works, there’s a real world example, and this was done using our code, not the open source stuff.

The Future of IoT

What is the future of IoT, what does IoT look like going forward? I think there’s some very interesting things, especially when you connect IoT with identity. One use case I like to talk about is, can I use my smartwatch to buy gumballs from your IoT device?

You can either provision payment tokens into this device individually, or if they’re coupled with identity, you can have the transaction occur in the cloud. My wallets in the cloud, your wallets in the cloud, and we do the transaction in the cloud without the transfer of tokens. There’s some pretty interesting things going forward around payments with IoT devices.

IoT ownership is something that I’ve been interested in. If I lose my laptop, if I lose something, if someone claims ownership of something, I can prove that I have ownership of that device because I’ve attached it to my identity. If I ever want to transfer that, if I want to give something to my kids, or I want to sell my car, I can now transfer ownership from my identity to someone else’s identity.

This is the interesting part where if we can tie together FIDO authentication, FDO, and identities, there’s a pretty interesting world out there, looking forward. There’s some fun stuff waiting for us as we build this stuff out.

What are the Benefits?

So, what’s the benefit of this? Well, first up is we get to secure the ecosystem, secure the infrastructure, which is pretty well needed. We can create much better consumer experiences, not just for the consumer, but also for commercial and industrial IoT management. We can align identity, authentication, and all the other standards that are coming along.

Call to Action, Get Involved

Call to action, get involved. I’m sort of echoing what Gary said at the end of his presentation. There’s work to do here. The FIDO Alliance and the IoT working group have been doing a great job. There’s a lot more things to layer on here on top of this. A good place is the FDO spec.

The FDO spec is available online for free, no charge, go get it. Have some fun reading. Join the FDO working group. We have set up FDO cloud as a rendezvous server and it’s our commitment to keep that up. Anybody can use that for free. Anybody can come and register their onboarding service and hook up their onboarding service with what we have done.

We just want to make that available as an endpoint so that anyone making an IoT device, will probably point at multiple rendezvous servers, but we have one there that we intend to keep up and the performance that we’re seeing is quite excellent. We’re expecting quite good scalability.

I view this as where FIDO Alliance was, maybe 8 years ago, we’re getting started, there’s a lot of fun stuff coming. But, it’s going to take a collection of companies. There’s a few companies in a working group now, but they’re more of the chip guys, the Intels, the Qualcomms, ARMS. We need the next layer, the application providers, the device makers, and we need to move up the stack to pull these pieces together.

Feel free to shoot an email to fdo@loginid.io. If you want to have more conversations, we’re looking for partners more than customers, necessarily. How do we build out this ecosystem, make it secure, make it scalable? So you can send an email to that or send an email to me personally.

Question and Answer

I think we have a few minutes for questions, David?

Audience Member: I think one of the challenges is this space, or any space like this, is who is going to be the first large mover? Do we have anybody saying ‘yeah we’re going to do this’?

BL: This is an invitation for all those companies to come along. But, you have to remember the evolution of the FDO spec. Basically, Intel, Qualcomm, they see the need for this. I have to say this right so it doesn’t sound like I’m inviting terrorist attacks, but we’re one event away from the federal government going ‘we have to fix this’. We may have an ‘aha’ moment and everyone will get serious about this.

Otherwise, I think it's incremental, but, incremental is good. There’s a lot of places where we have to build out the infrastructure, but we’re having some interesting conversations with some large companies. I think we’ll see the innovation from the little guys, then we’ll see the adoption from the big guys.

Audience Member: What about the anti-tampering checks in each of the supply chain stages on type of knowing which entities the device flows through and looking for tampering as part of the onboarding service?

BL: I think that’s above my paygrade and outside the current FDO specifications. But it’s an interesting question and please bring your question and join the IoT working group and I think it will be really interesting to put that into context. Unless there’s some other industry standards that can help us.

One of the things that the FIDO alliance has done really well is say ‘here’s what we’re doing, and there’s other standards that we bump up against too’. So, if there’s other standards in that space we should probably figure out how to hook up to those.

Audience Member: I didn’t get a chance to talk about this, but in some of the talks yesterday, in the context of FIDO and FIDO2, the speakers talked about the importance of attestation. That is where a device actually establishes its security state to a relying party. Attestation informs an underpinning of the FDO protocol. I didn’t really discuss that in my talk, but if you go through the spec, you can see that there.

So, if there has been tampering in the supply chain, presumably the device owner would get an indication of it. Actually the rendezvous service can actually get an indication of it too. When I mention the device having to establish the authentic part of it as part of its security state, the rendezvous service can’t verify the device's security state. It won’t even direct the device back to the device owner to complete the onboarding process.

Audience Member: Second, which is kind of related, is the voucher system authoritative? If a bad actor exists in one step of the supply chain, can they submit malicious vouchers? How is a voucher bound to the device?

BL: It’s bound at the time of manufacture.

Host: Thank you