I have worked with a number of IoT development kits that get connected to cloud-based services, and the process is pretty much the same in terms of linking devices together. There is a way to set up an account on the cloud and then an entry must be created for the device under test. There are usually some keywords, passphrases, or other forms of identification involved that must be set in the device or obtained from the device and entered in the cloud. This essentially provides the secure link information to the software.
Of course, the developer needs to know what URLs are involved in the sign-up process, as well as what information is involved. The process works and is not bad for a developer, but definitely isn’t much fun for a customer.
Intel’s Secure Device Onboard (SDO) is an automated service is designed handle this linkage of IoT devices to cloud services in a secure, standardized fashion (Fig. 1). Everything starts with a device that is given an Enhanced Privacy ID (EPID) when it is created. The EPID is essentially a private crypto key that can be used to generate secure credentials. A device and EPID are paired with a 128-bit Globally Unique Identifier (GUID). GUIDs have been used for a long time to identify everything from an object to a software service. A device’s GUID is effectively its public name while the EPID is the secret.
The process starts when a board or device is created using a chip that has been programmed with the EPID. A digitally signed certificate is created that is essentially an electronic tracking document. Updated certificates can be created as a device passes through a supply chain. Eventually a certificate is given to the Intel SDO Onboard Service, along with information about what IoT management platform should manage the device.
Once a device is installed and connected to the internet, it uses a standard uniform resource locator (URL) to reference the Intel SDO Onboard Service. The Intel service in turn finds that IoT management platform will support the device and provides this information to the device, along with contacting the management platform. The device is given information about how to contact and engage the management platform. At this point the device works directly with its management platform and the SDO Onboard Service is no longer involved. The SDO service discards the information associated with the device since it is no longer needed.
Of course, all these exchanges are using digitally signed packets, with the device using its EPID to start the process. The certificates that have been exchanged through the process have a public key that can be used to verify this information. Likewise, the updated certificates are signed as well using private keys, so a service can know that the final certificate associated with the registration of a device have been provided by a known entity.
The advantage of this approach is twofold. First, the user does not have to do anything other than obtain a device and connect it to the internet. Of course, they will have to set up an account with a service so they can utilize and manage the device, but they do not have to deal with passwords, or even with the device itself from a configuration perspective. Second, all the transactions are digitally signed, and there is no exchange of secrets or even the need for encrypted links unless there is a reason to hide the actual process from the rest of the world.
Intel has signed up quite a few companies, from silicon providers to equipment providers to IoT platforms (Fig. 2). The EPID silicon providers deliver microprocessors and system-on-chip (SoC) hardware with an EPID programmed into them. Secure boot capabilities and matching EPID support software for the initial communication with the Intel service is provided.
The process could be implemented with a difference intermediary, or a vendor could provide this service themselves, but it is not necessarily a simple thing to do or manage. There are also advantages to using a common service instead of managing and linking devices directly. For example, Intel’s approach allows a device to target different IoT services, such as a temperature sensor or a switch. The devices would need to use/provide a standard generic interface, but the same type of device could be incorporated into solutions from different IoT service providers.
The key to using Intel’s services is in the URL used by the software that is programmed into the device. Though this is independent of the EPID, developers working Intel will be using Intel’s server URL. It might seem that this would be a single point of failure, but only if Intel somehow lost the URL programmed into all the devices. Also, this URL is only needed for the initial connection between the device and the service provider that will ultimately manage the device. It would also be needed if the device needed to be reprovisioned, or if a factory reset is performed.
Intel’s Wind River is also supporting this platform. Wind River’s Helix Device Cloud support allows developers to use its services to create applications and management tools that work in conjunction with the EPID/SDO registration system. Helix addresses all the other IoT-related services, from over-the-air updates to device management and reporting.
Intel’s approach assumes that all security is managed between the device and the ultimate management service. It also assumes that any gateways or routers simply provide routing services. What is missing is any communication with these routing devices that could provide added levels of security and management, such as restricting communication between a device and only known and approved services in the cloud. Any variance would be detected and flagged as an error. Of course, this requires routing devices with added intelligence and a protocol for working with managed devices, but that is an issue for another day.
Intel’s SDO provides a solution to a problem that all IoT devices encounter. It becomes more important as the number of devices grows, since even minor chores for setting up a device can increase the complexity of the system and the potential confusion for customers and the potential for errors that could cause security holes.
