Programmable options could have big impact on supply chain readiness.
Security credentials traditionally have been provisioned during chip manufacturing, often as a final part of the testing process. That’s starting to change.
Logistics management can be improved by pushing that process out — even as far as the on-boarding process. And simpler on-boarding can hide most of the details from the user.
“The IT approach to provisioning IoT devices has primarily been manual, or required multiple human touches,” said Simon Rance, head of marketing at ClioSoft. “But multi-touch on-boarding isn’t getting us to the promised 50 billion connected devices by 2020, which has come and gone. Looking at why, retrospectively, it screams the need for a secure and privacy-driven zero-touch on-boarding methodology for IoT devices.”
On-boarding can involve both the access network and the application, and different approaches treat these differently. Some schemes are dedicated to the network or specific security chips. Others are more open. It’s not clear which version(s) will take hold.
“More IoT chipmakers are securely provisioning device keys and certificates in the supply chain and establishing strong bindings between device data and the keys used to authenticate the devices,” said Joe Gow, senior director, product management at Rambus. “While this provides a basis for identity assurance of devices, it also requires IoT service providers to manage security services to verify devices before providing tokens and certificates used to onboard the devices to their platform.”
Provisioning and on-boarding
Manufacturing, shipping, and deploying connected devices has become more complex than the far simpler processes required for getting older unconnected devices up and running. Connected devices need to phone into a server somewhere to announce their existence, prove that they’re legitimate, and set up the secure communication paths needed for ongoing operation.
While specific terms and interpretations may vary, traditionally there have been two important steps in establishing this first connection:
• Provisioning refers to the injecting of security credentials into a device. Historically this has been done at chip manufacturing, before the device ships.
• On-boarding refers to an end user setting up a new device. It leverages the provisioned credentials. Some industry folks will refer to this as the end user “claiming” a specific device or “commissioning” the device.
That on-boarding process often has been cumbersome and error-prone. “In the IoT world, the one thing that stands out is how dissimilar devices are,” noted Richard Kerslake, general manager, industrial controls and robotics at Intel and co-chair of the FIDO IoT working group at FIDO Alliance. “You’ve got all kinds of hardware, all kinds of operating systems, and most of these things don’t even have displays.”
Finding approaches that accommodate the range of applications and price points is challenging. “On devices that have no user interface, credential management becomes a challenge,” said Alper Yegin, senior director of standards and advanced technology development at Actility, and technical committee chair and board vice-chair at the LoRa Alliance.
This is partly because on-boarding can refer to two separate but important things — joining a local access network to get to the cloud, and then registering with applications and services hosted in cloud servers. Technically speaking, those are two different processes. But efforts are underway to hide that detail from the user.
While there may be a motivational aspect of this for home users, it’s a huge productivity issue for so-called “massive IoT” installations. A city may install a huge number of parking meters, while a utility may install a huge number of water or electric or gas meters.
Kerslake noted these devices may take 20 minutes, on average, to set up. “If you took 10,000 devices, it would take two years of effort based on analysis that was done back in 2017,” he said. For millions or billions of devices, the math doesn’t work.
The LoRa Alliance also pointed out that the credentials needed to set up devices historically have been sent by e-mail or some other means that required installers to enter them manually. That takes time, and it’s error-prone. Any time a device doesn’t simply start working, there is likely to be a big delay as the installer tries to figure out what went wrong.
Greater supply-chain flexibility
Another challenge for IoT device makers involves limited flexibility and ecosystem tie-in. Early implementations focused on getting devices into the market in the easiest way. That would mean signing up for specific chips to use in the systems, picking a single cloud provider, and tying in a few fixed services. This has resulted in closed ecosystems.
It’s possible to create devices for multiple ecosystems, but in order to do so, manufacturers have to configure their devices in the factory. Ones intended for, say, Ecosystem A, which uses AWS for the cloud, would be provisioned with credentials and software that aligned with the requirements of Ecosystem A. The same device also might be usable in Ecosystem B, which might use Azure, but it would need different credentials and slightly different software to engage with the Azure API instead of the AWS API.
These two otherwise identical devices, once provisioned, would have to be treated as separate stock-keeping units (SKUs), complicating inventory and logistics. There is a desire to be able to offer “generic” devices that could be configured after purchase.
“We’re trying to address the lower price points of IoT devices without having to develop ecosystem-specific SKUs for each closed ecosystem,” said Giridhar Mandyam, chief security architect at Qualcomm and co-chair of the FIDO IoT working group at FIDO Alliance.
All of this has created the motivation for a much easier process for on-boarding — one that proponents are referring to as “zero-touch.” The idea is that the installer pretty much doesn’t have to do anything substantial to set up a new device.
But security and a wide range of use cases can make that challenging. There are different ideas on which credentials should be injected when. There are also different ideas about what various data-center servers do and store in the process.
These can be difficult things to invent from scratch for any company wishing to market an IoT device. Instead, services are being developed and offered that bake in this capability. Examples include:
The role of the cloud
On-boarding has a device checking into some service in the cloud. In this case, “cloud” can be public or private, and it can be on-or off-premise. “In many parts of the industrial world, the idea of data leaving the factory causes heart palpitations,” said Kerslake. “So we needed a solution that work either way. If you want to keep it completely locked down inside a facility, it needs to work. If you have cloud access, it needs to work.”
What varies by system is the way servers connect and talk to each other when a device joins the network. “In our core network, we have a distinction between the network server and join server,” said Yegin. “The network server is where the LoRaWAN link layer runs.”
A device checks in via the join server, which checks the credentials. It then hands the connection over to the network or application server, which knows more about the user. “The application payload will come with a device ID, which is authenticated by the network and compared against the local database for finding the matching device context,” said Yegin.
The FDO approach, meanwhile, has a “rendezvous service” within a server. It authenticates the device on first power-up and then forwards it on to the appropriate application server. The application server then sets up for future connections that bypass the rendezvous service.
Because these servers hold lots of secrets, they must by extremely secure. But minimizing the secrets and their proliferation can also help. For instance, FDO’s rendezvous service would not likely be an attractive target. “We want to provide the minimum amount of information for the rendezvous server,” said Qualcomm’s Mandyam. “It determines that the device is authentic and redirects it to the device owner. That’s it.”
Fig. 1: Chips used in IoT devices may end up talking to any of a variety of clouds. Provisioning and the software stack must give flexibility as to which cloud services will be used. Source: NXP
Provisioning isn’t an all-or-nothing event. There can be a wide variety of credentials for identity, network access, and application platform access. But it’s important to know when the various credentials are injected into chips or systems. There are four possible events where provisioning is possible — at chip manufacturing, at system manufacturing, at system shipment, and at on-boarding.
Provisioning at the chip factory
Traditional provisioning uses a hardware security module (HSM) or some other highly secure platform both to inject credentials into a chip and to forward the credentials, along with the chip identity, off to a database where the information can be retrieved when the device eventually checks in.
The chip itself might be a secure element, some other standalone hardware root of trust (HRoT), or a microcontroller with a built-in HRoT. The device identity may be injected or a root key may be established in hardware by something like a physically unclonable function (PUF). But it’s critical that the identity be unique.
This scenario sends the chip to a system builder with credentials in place. This is where the SKU burden originates. If devices can be provisioned only at this stage of manufacturing, then they have to get all of the needed credentials, and that destines the device for a single system builder and end-use ecosystem. The same device for a different system builder or ecosystem would have to be provisioned – and stored and shipped and tracked – separately, with its own SKU.
Fig. 2: If full credentials are injected during chip manufacture, then different chips targeting different ecosystems must be tracked as separate SKUs. Source: Bryon Moyer/Semiconductor Engineering
This is resulting in a desire to postpone full provisioning. In a late-provisioning (or “late-binding”) scenario, the identity would still be loaded early. But network- and/or application-oriented keys may be deferred until later.
Provisioning at system build
Traditionally, when ordering pre-provisioned chips, a system builder will need to “register” the identities of these chips as belonging to them. This is done through a document often referred to as a “manifest.”
Microchip, for example, makes the manifest available through its e-commerce site. It also may be visible to a distributor or, if the system-maker so decides, to a contract manufacturer.
An order for 10,000 devices would come with a manifest that has the 10,000 serial numbers, which then can be uploaded to the cloud. “It’s called multi-account registration,” said Xavier Bignalet, product marketing manager, secure products business unit at Microchip. “It allows you to take the list of certificates and repackage them into the manifest file. Amazon ingests it into their servers.”
Provisioning at system build means that the chips themselves can be “generic” when shipped. The credentials set is completed without complicating the chip-stocking logistics. But if all credentials are loaded at system build, things get more complicated because a system could be used for more than one ecosystem. Consequently, differently provisioned systems would have to be stocked with their own SKUs to ensure that the right systems go to the right users.
Fig. 3: If full credentials are injected at system build, then different systems targeting different ecosystems must be tracked as separate SKUs. Source: Bryon Moyer/Semiconductor Engineering
Provisioning at system shipment
If credentials that target a specific ecosystem are loaded just before shipping, those systems can be stored generically in a warehouse. They get their final personality only when being sent to a store or user who has ordered it for a specific purpose.
This is the latest that a device could be bound to a service before it ends up in a user’s hands. Even so, it doesn’t need all of the credentials for that service. An FDO voucher, for example, is loaded before shipment, and a copy is sent to the rendezvous service. The voucher may appear similar in concept to the manifest, except that a manifest is used by the system builder. The voucher is unique to a system and is used by the installer.
This approach allows the number of SKUs to remain small. Waiting until system-build to inject application credentials allows a single chip to populate many different systems without having to track chip or system SKUs separately.
Fig. 4: If injection of credentials is postponed until shipment, then temporary credentials can be used, with full credentials loaded during on-boarding after the connection has been established with the target ecosystem. Source: Bryon Moyer/Semiconductor Engineering
Provisioning when on-boarding
On-boarding is where the device is introduced to the network for the first time. With older systems, the device will have credentials that will be compared against the credentials in the cloud. If they match, then the device is accepted. But things are different if some of the credentials have been deferred.
There is a trend toward providing final credentials over-the-air, both at on-boarding and later in the lifecycle, if needed. Done properly, elements of the on-boarding process can be divorced from the details of the final application credentials.
This means, upon receipt, the system will have a bare set of identity credentials, and possibly some temporary credentials that allow the system onto the network the first time. Once connected and authenticated, the final application server can download any operational credentials the device will need.
Those operational credentials can vary widely by application, but if done through a level of indirection, the on-boarding infrastructure need not bother with those details. For example, with the FDO approach, the rendezvous service needs to know only the bare identity and which ecosystem to target. After authenticating and forwarding it to the application server, it leaves the process and needs no knowledge of what specific further credentials will be injected at that time.
“We set up a secure tunnel, and then all kinds of credentials can be sent down that tunnel,” explained Intel’s Kerslake.
Easier on-boarding
Efforts are also underway to simplify the on-boarding process. “How do you take an IoT device regardless of what it is and how it’s connected and then connect it to a target cloud or platform?” asked Kerslake. “And how do I do that in a way that’s automated and as secure as possible?”
These zero-touch approaches may involve QR codes for consumer devices. In many cases, that QR format is set by the system builder or seller. LoRaWAN has a standard public QR code format that system builders can use, rather than inventing their own. “Anyone can build a QR reader application,” said Yegin. “And then the extracted information can be injected into any network server.”
Fig. 5: The LoRaWAN on-boarding procedure for systems using a secure element. A standard QR code format simplifies the process for consumers. Source: The LoRa Alliance
The Zigbee Alliance also is looking at simplifying on-boarding. “The Project CHIP team is focused on developing as simple and seamless a method as possible for provisioning, including methods like QR codes, Bluetooth, and soft AP [WiFi access point],” said Chris LaPré, solutions architect at the Zigbee Alliance.
For infrastructure-related installations, QR codes don’t seem to be as prevalent. With FDO, for example, the device immediately contacts the rendezvous service on first power-up. The provisioning happens silently over the air, and the installer can move to start a new installation even before the prior one has completed. Their goal is roughly one minute for each installation.
Of course, the system has to get onto the network first, and FDO doesn’t handle that explicitly. How it works depends on the transport network. “Certain classes of devices will be connected upon first power-up (e.g. cellular-enabled IoT devices),” said Mandyam. “For devices that lack connectivity out-of-the-box, it is expected that the manufacturer or third party can provide an application that can assist the user to manage the connectivity. In addition, connectivity can be managed through the use of existing complementary and standardized solutions such as Easy Connect,” which uses QR codes to connect WiFi devices to access points.
Fig. 6: The FDO provisioning and on-boarding process. Operational credentials are loaded after the final step. Source: The FIDO Alliance
NXP allows early or late binding. For the latter, the cloud will be pre-provisioned with the device credentials. Because this is a captive system, the device also can be preloaded with the on-boarding registration URL. So the device will check in and be matched with the credentials already in the server. Additional credentials then can be loaded into the device.
“When you power on a device for the first time, it connects to our service,” said Philippe DuBois, vice president, general manager of secure edge identification at NXP. “Then we can configure different clouds, applications, sounds and actions, certificates, and even change identities.” Exactly when the device pings in is up to the system software. “On-boarding is triggered by a simple API call on the device, so the device software can decide when to trigger this API call,” he added.
Fig. 7: NXP’s EdgeLock 2Go on-boarding process. Provisioning can be early or late. Source: NXP
LoRaWAN uses the network authentication to vouch for the device at the application level as well, saving a step. “We’re able to bootstrap application layer security from network layer access authentication,” said Yegin.
In this model, the authentication serves only to vouch for the identity of whomever is logging in. Whether or not they’re allowed to connect to a specific application is an authorization question. “You have this access control list that identifies my device based on the device ID that I used to get authenticated,” clarified Yegin.
Provisioning over the lifecycle: over-the-air updates
FIDO is trying to cover a wide range of use cases. Three examples are:
These all involve over-the-air injection of new credentials throughout the life of the system, which is a common theme for future-oriented implementations. “Provisioning can happen through the lifecycle of the device for adding new credentials when new services must be enabled, renewing existing credentials or for managing a change of ownership or the decommissioning of the device,” said DuBois.
Over-the-air updates are often touted as important for adding new features, improving the way devices work, and improving security by updating code. But they literally can change the identity of the device, depending on how that identity is derived. Even if the identity isn’t changed (because, perhaps, it’s derived from a PUF), the credentials can be completely renewed or replaced. This provides a way to recover from compromised credentials or to refresh the system for a new user.
OTA security considerations
But OTA updates are not without their challenges, as evidenced by the recent SolarWinds breach.
“There needs to be some type of verification of code prior to deployment,” said John Hallman, product manager for trust and security at OneSpin Solutions. “What’s common practice is to put the update into some type of sandbox environment and let users test out the new updates and run it in that isolated environment prior to releasing it into a real-time environment. With SolarWinds, there was a two-week period it was there. There is no standard time frame for how long that should last, and it varies from company to company. But being able to do that transparent, independent assessment prior to deployment is very key.”
But even that isn’t perfect. “With this attack they actually broke into SolarWinds and put malicious code into the update,” said Jason Oberg, CTO of Tortuga Logic. “That’s a tough thing to prevent, because it was really exploiting the issue at the source. So the whole infrastructure has authenticating it, and it seemed to work.”
Solving this issue isn’t simple, and in security nothing lasts forever. But new techniques are being applied, such as using AI to identify aberrations. “AI will help optimize specific problems, and it can be self-learning,” said Helena Handschuh, security technologies fellow at Rambus. “It can decide if a behavior is normal or not.”
OTA issues can affect devices regardless of the on-boarding approach, but it’s essential to understand the risks involved in all of these.
Conclusion
Of the approaches, FDO appears to provide the broadest coverage. “It’s a true open industry standard that’s now being supported by every major platform and operating system on the planet,” said Andrew Shikiar, executive director and chief marketing officer at the FIDO Alliance.
In addition, the Linux Foundation has a project under the LF Edge umbrella called “secure device onboard,” or SDO (using the name Intel coined). While FIDO is doing the spec, SDO is a software implementation. “We hope to have an alpha version of the code in April and a production-quality release roughly this summer,” said Kerslake.
Each of these on-boarding approaches has its own unique details, but they are all converging towards a more flexible way of managing credentials and inventory while simplifying installation. These steps may serve to remove some of the friction that has been holding the IoT back.
“As the IoT ecosystem matures, we are seeing a move toward standards that may enable wider adoption of identity assurance, supply chain integrity assurance, and secure provisioning of IoT platform credentials,” said Gow. “This approach to platform verification seems to be a direction that will continue in some form as service providers continue to monetize the data from IoT devices, and as the risks and associated costs of security breaches continue to grow.”
 |
 |
 |
 |
 |
 |
Good coverage of a very critical aspect! Helpful.