 Hello, thanks for joining this presentation. I'm Patrick Aertrecht and I'm planning to talk about onboarding of edge devices and a protocol to do so in a secure manner. First of all, I'm going to talk a bit about what onboarding is and why it's special at the edge. Then I'm going to talk about the protocol that has been defined to solve this securely and then I'll try to do a quick demo of the implementation that we have made. So let's start with what people would call traditional device onboarding to get an idea of what I'm talking about. The main thing is when you have a new device and I'm going to use the term device, but usually that is a computer. After it's delivered, you will have to get the operating system installed and some initial configuration for it to actually start doing the task that it's purchased to perform. Some of the initial configuration could be the IP address setting as a key. So the administrator can access it and credentials to access the VPN. So the steps for that normally would happen during onboarding is a company purchases a device from a manufacturer and the manufacturer then ships that device to the IT department. Where after they receive the device, they have to then install the operating system usually by a master image. After that, they perform configuration and then they ship the devices out to in this case a factory because my example is for example a factory controller. So after it shipped to the factory, someone in the factory has to receive the device, put it physically in its place, turn on the device and then it will take it into service. Note that the only parts where the IT department comes in is installing and configuration, but because the IT department is involved in there, that does mean that the process becomes significantly more complicated because you have twice the amount of logistics for sending it and the IT department has to touch every single one of the devices. So which ways could we shorten this and get rid of the logistics overhead? One of the initial ways could be that instead of sending it out to a IT department, the factory or the manufacturer sends it directly to the factory where it's supposed to be used and then someone on the factory floor will install the master image, so the operating system and perform the initial configuration. The disadvantage of that is that you now need knowledgeable people on-site in the factory because they now have to actually perform the installation and initial configuration phases of the device. Unfortunately that doesn't scale very well because in the other case you just need someone to physically connect the device and press the power on button. What if we move the phases to the other side? So instead of shipping a bare-bones device from the manufacturer to the factory, we instead have the manufacturer install the master image and we provide them with the initial configuration for the devices and have them ship it out to the factory. So the problem with that is that you now have to trust the manufacturer because you have to actually send the credentials for a VPN configuration for example and the manufacturer has to now get processes in place for individualizing devices and knowing exactly which device to send where. This also means that they cannot easily keep stock or that if they do have stock before they send it out they'll need to first unpack the device, individualize it, repack it and send it to the factory. So the main problems with this approach, with both of these approaches are basically you have many devices because a factory can easily have a couple hundred devices in just one factory but that's just one example. You could for example have it in user's homes or like Smart City in light poles and again in both of these cases you have to trust the person who is installing the actual device with the credentials for the VPN and other information and otherwise you have the logistics of shipping the device twice first to the IT department and then out to the factory floor or the user's home. In order to try to solve these challenges we have defined or a protocol has been defined by called FIDO device onboarding so I'll now talk a bit about that. It's a standard by the FIDO Alliance some of you might know the FIDO Alliance because they also specified FIDO 2 which is the successor for U2F for example and as part of FIDO device onboarding the main thing is that you have something what's called late binding so that means that the actual binding of the device to a management system happens after shipping on first boot but without the need for someone to physically configure that on the device so in the factory as I already said I'm going to use the term device as just any device and in the terms of FIDO device onboarding there's a term owner which is basically the final owner of the device so the company that owns the factory that tries to install the system so a new overview of how it works first of all the manufacturer produces the device as normal but instead of putting in a customer specific image they put in a FIDO device onboarding client binary and additionally they perform a device initialization phase as that's called in FIDO as a result of FIDO device initialization you end up with two different files or resources there's the ownership voucher which is used for which is outside of the device and sent along with the device I'll show that up later and there's the device credential which is stored in the device so after they produce these items so they perform the device initialization phase then they physically ship the device out at some point to a customer they also record the fact that the device has been sold and to whom it has been sold in the ownership voucher the ownership voucher keeps track of who has owned a specific device in any phase of its life so if they for example sell it to a reseller the manufacturer would add the reseller as an item or as the next owner in the device and then when the reseller sends resells the device to someone else they add the final owner of the device into the ownership voucher and at the final stage the manufacturer sends out the ownership voucher to the customer and in this case they would send the ownership voucher to the IT department but the device itself will be shipped to the factory note that these two are very different locations theoretically after this someone in the factory can physically install the device and press the power button or just physically install the device and then the IT department can put the ownership voucher into their management system so that their management system is aware that this device is now owned by this company and it will at some point in the near future start to show up and then at some point later the people on the factory floor turn on the device after it's physically installed as soon as the device gets turned on it will then take care of the rest of the process it will determine where its current owner is it will then retrieve the actual deployment image for this device and its configuration all from the IT management system so I've mentioned this ownership voucher a couple of times now what's all in it so the ownership voucher is basically a signed record of ownership of the individual device so every device that is produced has its own unique ownership voucher the ownership voucher contains for example a globally unique identifier for the device and it contains a link to the rendezvous server that is used by the device rendezvous server is used later on in the protocol to find out who the owner of a device is at any point in time it contains some device information so that when you ask the owner of a device to look at the ownership voucher for example the serial number will be registered in it so you can easily see which one it is and then the public key of the manufacturer will be initially registered there will be an HMAC computed over that by a key that is stored in the device and never leaves the device this is used by the device in order to make sure that it doesn't have to store the ownership voucher but it can later on verify the ownership voucher it sent as part of the protocol so that it can trust the ownership voucher and then the ownership voucher exists of one or more entries where every entry indicates a resale of the or a further sale of the device so in this case for example the device would have been sold twice once to a reseller and once to a IT department and in both cases the individual entry is signed by the previous owner so the manufacturer signs the statement that the reseller now owns it and later on the reseller signs a statement that the factory IT department now owns the device this way when you look at the ownership voucher you can actually verify and who owns the device at this particular moment also this only includes their public keys obviously and then there's the other side of the story the device credential this is stored in the device it can be stored as a file or in another location like non-violetile RAM like firmware basically that contains the same device unique identifier it contains the same run-of-the-server hostname and it contains for example a SSID for a wireless network that is to be used for the actual onboarding if there's no Wi-Fi network and it's connected via a wire that entry doesn't have to be there they suggest examples it also contains the public key of the manufacturer and the actual HMAC secret so in the previous page the ownership voucher I said that the header part is signed by an HMAC secret this is where it stores it and the device has a unique device key which together with the which has a chain so a certificate chain that was shown in the ownership voucher just below the header HMAC that can be used later for verifying that this device is in fact the correct device as expected so as part of the FIDO device onboarding protocol after these are set up and the device is sent to the factory and then turned on we start in the middle flow the device reads the device credential and it connects to the network either via Wi-Fi or via wired and at some earlier point the owner management system will have informed the run-of-the-server of the manufacturer of where the owner management system is waiting because at the point at the moment of sale the device doesn't know yet where the owner will be so the owner management system tells a run-of-the-server about it and then just waits for the device the device after it's connected to the network will contact the same run-of-the-server and ask it where is my current owner after it gets that information from the run-of-the-server it will then connect to the owner if the owner hasn't checked in with the run-of-the-server yet it will actually wait until the owner has done so after this it will connect to the owner it will prove that it is the correct device by signing a statement with its device key the owner will prove itself by signing a statement with the last key of the ownership voucher and after that the owner management server provides the configuration for the device which the device then stores for example putting in place an SSH key and putting in place an IP address configuration and after that is sent the owner management system reports the device as onboarded the device removes its device credential and the entire FDO protocol is done and no longer in use on this device so let me give a very quick demo of just the command line that we made for this of our implementation so this is the site of the manufacturer client the manufacturer client basically tell gets informed where the manufacturing server is located so the manufacturer would be performing this part on the device and after this is performed it creates a device credential on the device and the manufacturing server will have a ownership voucher so if I look at the device credential you will see that that contains an HMAC secret it contains device information so the serial number or in this case the word test device the grid and it will contain the rendezvous info so the URL of the rendezvous server when I look at the manufacturing server we get an ownership voucher which contains the items as I previously discussed note that the entries part currently is empty so in this case the manufacturer is reselling it to the owner and after they perform the ownership voucher extension then we can dump the ownership voucher again and now it will be the exact same but the difference will be that there is now an entry because the device has been sold and this is actually fully signed entry after that the owner recorded this into his management system and then the next step is waiting for the device to come online when it performs that in this case we have a Linux app which performs the client implementation it retrieves the device credential from in this case the file system it could also be from NVRM or other places it performs rendezvous and then it gets the address of the owner onboarding server performs owner onboarding protocol and at the very end it's done the client is now terminated and the device credential is gone and in this case it has put in place a authorized key on the file system of this device so that's the whole protocol as we have implemented it so I would like to thank you all for listening here's the link to the open source implementation for this protocol it's in Rust and tomorrow there's also a talk by Antonio about building an operating system for the Edge where he will go into more detail about other parts of a Edge operating system thank you very much for listening