Much of the discussion around the Internet of Things (IoT) focuses on the sheer number of things and the volumes of data they’ll generate. Some even discuss security. But of much greater concern is the foundation on which trust is built in this increasingly complex environment – identity. And identity in the IoT isn’t users and passwords in the enterprise identity and access management sense; it’s an integration of devices, data and services, along with a user or two, that needs to result in confidence in all of that data and activity.
Like many parts of the IoT, the history of identity starts with machine-to-machine (M2M) identity techniques that are often tied to a communications service provider. The heavy reliance on mobile networks for much of M2M’s connectivity drove SIM-card-based device identity.
That was sufficient for identification and was a reasonably robust mechanism. It requires a fair amount of resource support in the device and, of course, a mobile provider to be the ultimate identity provider. There are many use cases where this will work well, but the much larger world of the IoT won’t be constrained by these limits.
Smaller, resource-limited devices that don’t connect via mobile networks need support, and the more complex data flows require protection, too. Suitable identity capability has to extend from the device to the end consumer of the data that it generates.
Challenges in IoT device design include the requirements for data protection and device security. Device security is a complex problem. The trustworthiness of the hardware and software and their combined execution need assurance. Trusted platforms are achievable, but will depend on the resources available to the device. Small sensor systems may have cost constraints that preclude the use of more sophisticated or robust hardware. Varying degrees of trustworthiness will have to be balanced with the nature of the data that the devices generate.
The first steps in this pursuit are being accomplished by systems that build trust by extending the factors that assure identity.
Because many IoT devices have geolocation information, the two-factor authentication combination of something one has and something one knows can be extended to include additional context of location and even behavior. These can be used to provide additional verification of device identity.
In cases where location isn’t a data resource, it can be inferred through device relationships with gateways or smarter devices. Imagine having your smartphone vouch for your water meter.
There are a number of approaches to larger-scale identity, and some of the most successful have relied on public key infrastructures to manage the trust relationships required. Kerberos is one of the best known and most widely deployed, but it has challenges in scaling to the level required for IoT. It has the potential to federate identity across systems, but has limitations in extending to larger numbers of devices and data.
Identity for the IoT will have to provide device and data attestation. It will need to also protect the data generated as it passes through a long chain of users and service providers. Data generated by IoT systems will be distributed through publish and subscribe mechanisms that will allow the selective use of different data types and sources as they suit different applications.
That puts an additional requirement on data-protection functionality to allow for selective and even anonymous transfer of information.
There are efforts under way from vendors of IoT platforms, as well as collaboration around extended cryptographically based approaches. Intel, Microchip and Atmel are working together on a proposed standard called Enhanced Privacy Identification. It’s based on work on Direct Anonymous Attestation, a cryptographic means of signing data anonymously that was adopted as part of the Trusted Computing Group’s Trusted Platform Module version 1.2 specification.
It allows a trusted third-party verifier to attest to the validity of a signature without revealing the identity of the signer. This creates privacy enhancements as part of the trust framework that it establishes. Like other mechanisms of its type, it’s computationally intensive and may not be suitable for the smallest of devices, but it builds in functionality to limit the maximum memory and compute footprint needed.
The ability to limit the size of a certificate revocation list that must be checked to ensure validity is one example of these design features that tackles a historical problem with big trust environments.
In order to capitalize on the benefits of IoT deployments, there has to be trust in the devices and data that compose them. Identity forms the foundation of that trust and will come in many guises. The breadth of device types and data varieties in IoT presents challenges to any single method, but enough options are available to start grappling successfully with them today.