Developers of Internet of Things (IoT) products know the importance of security to protect personal or industrial data, and typically employ encryption technologies to address that. But with the enormous volume of communication from these products to cloud-based services, a new security challenge has emerged. Cloud service providers are requiring a two-way trust model based on strong identity to ensure that only authorized devices are accessing their services—and they’re considering charging risk premiums for connections made by devices without this capability. Strong identity is a digital certificate based on a non-readable private key that is generated internally in tamper-resistant, secure hardware. By building a strong identity certificate into their devices, IoT developers can address this new security challenge while also improving manufacturing logistics, reducing costs, and improving customer satisfaction.
IoT presents new security challenges
Internet security using keys and certificates for online transactions is well-established. When consumers shop online, for instance, they can confidently submit payment information based on trust that the information is going to the intended site and not a different domain spoofing that website. This is because relevant digital certificates that enable verification of the domains are embedded in web browsers. The browser makers themselves don’t have to interact with every domain owner, but go through Certificate Authorities (CAs) to obtain certificates that will vouch for the website. The website owners then register their domains with the CAs who verify them. This one-way trust model protects consumers so they can interact with websites for e-commerce, banking, etc. with confidence.
The IoT wholly adopts this model, but because the players are now predominantly autonomous objects, there is a critical new element. Just as it is important for consumers to have confidence in the websites they access, it is now equally important for the cloud to know it is receiving data from and sending instructions to the right “Thing.” Many unpleasant hacking scenarios are possible if this trust is absent, from turning off a home’s security system to taking over a car in motion. The trust model now needs to be two-way, or mutual, in order for cloud providers to be confident that they are communicating with the right connected Thing.
The proliferation of IoT products is largely responsible for this shift. Cloud services providers are increasingly in possession of enormous volumes of sensitive data. This makes them increasingly attractive to hackers, and therefore liable to data-breach incidents. Providers are reacting to the enormous volume of communication from IoT devices to their cloud-based services with new requirements for strong identity so the devices can’t be spoofed and cloud providers can restrict traffic only to trusted devices (see Figure 1). This also protects cloud providers’ business models, which rely largely on connection volumes that must be accurately tracked in order to charge for their services. Only strong identities that resist cloning can provide the assurance of accurate tracking and billing. But the shift also protects the IoT OEM. Cloned, substandard devices can damage customer satisfaction and brand equity, and could even be used for denial-of-service attacks on the OEM’s cloud services, making it difficult for customers’ legitimate devices to connect. The two-way trust model has become critical for IoT device developers.
Figure 1: The compromise of any device on the cloud network can allow an adversary to gain access and cause havoc. (Source: Microchip Technology)
Makers of IOT devices need to follow similar steps that traditional website owners do to establish a chain of trust through an established third party. For websites, a company or person typically only needs to create and register one or a few domains and the infrastructure to easily achieve this is in place. But IOT devices present a different challenge. Every single device—every smart bulb or connected medical device or industrial machine—must have its identity uniquely registered and the infrastructure to do this is still in development. This requires the developer to obtain certificates that prove the identity of the device and the cloud application that interacts with it.
Certificates and keys
Security is based on transactions involving keys and certificates. Keys can be generated, but certificates typically need to be created based on a trusted Root Certificate. A certificate proves the identity of a device, an OEM, or a cloud application that interacts with a device and proves that a device belongs on the network and wasn’t cloned during manufacturing. In the IoT, a certificate is the digital artifact that attests to the authenticity of a device and the cloud service that it interacts with. The certificate is signed by a trusted authority, such as a CA, using its private key. A certificate will typically contain the public key of the signer as well as application-related data, such as license or brand information, that helps an application manage device functions and privileges (see Figure 2).
Figure 2: A certificate contains a content section and a signature. (Source: Microchip Technology)
There are two ways of obtaining a root certificate. The most common is to use a CA such as Symantec or GlobalSign. If a certificate chain terminates in a certificate from a CA, then the system is considered trustworthy. These public root certificates allow for broader device interoperability, since any devices, clouds, and networks with which the device interacts will recognize the CA. Public root certificates, however, do have costs associated with them.
To avoid that cost, it is possible for developers to create their own root certificate – a so-called self-signed root. Because a self-signed root isn’t well recognized by others, it limits potential interoperability and usually applies to a closed ecosystem of devices that are recognized by each other, but not by anyone outside the ecosystem.
With a certificate created, the following development flow (see Figure 3) must be followed:
A certificate for each device (“Device Certificate”) signed by the OEM building the device
The OEM’s certificate (“Signer Certificate”) signed by a CA
A public Root Certificate from a CA
A certificate for use in the cloud to ensure that, when the device contacts the cloud, the cloud and device can authenticate each other.
Figure 3: A defined high-level provisioning flow must be followed. (Source: Microchip Technology)
To provision devices, the developer creates a device key pair and then creates and loads all the necessary certificates into the device. This is done on individual security chips before they’re soldered to a board. A hardware secure module (HSM) is typically used to generate a key pair unique to each device. Once the keys are in the device, a Device Certificate must be created, which contains the device public key and is signed by the signer private key. It may also include other application-specific information. (A white paper on “How to Create Root and Other Certificates for IoT Devices” provides detailed instructions.) The downside to this approach includes the overhead costs to secure the private key, which can be substantial.
Software versus hardware security trade-offs
Developers of IoT devices know the importance of security to protect the data that their devices generate. But in today’s highly competitive markets, their efforts to save on bill of material (BOM) costs can lead them to depend on cryptographic software techniques rather than specifying a hardware security device.
Cryptography in non-dedicated hardware, however, introduces new costs due to the significant logistics of handling security keys in the manufacturing chain. And even with the most rigorous handling protocols, these techniques suffer from a fundamental weakness: They cannot protect the identity of the end device from being cloned. This can only be achieved with strong identity enforced by a tamper-resistant, dedicated security hardware device.
As the industry matures, tamper-resistant security chips for the IoT must also evolve to include the ability to internally generate a key pair in which the sensitive key remains permanently unreadable. This will protect the private key from view while streamlined manufacturing logistics offset the per-unit costs of the hardware component. While these logistics costs may not appear in the product’s BOM, they can have a dramatic impact on the profitability of the IoT product. Closer integration between security device manufacturers and cloud service providers will also simplify the process for IoT manufacturers.
Once certificates and keys are established, there are additional complexities in protecting these assets from generation through distribution. This includes ensuring that keys never get exposed—and how to handle it if they do. This is another IoT process that is evolving from how security is managed for websites.
In the context of website domain names, managing certificates’ lifecycle involves the entire infrastructure. Certificate Authorities traditionally supported this in the form of a Certificates Revocation List (CRL), which is essentially a black list of “bad” certificates that have been compromised or cloned. If a legitimate website finds itself on a CRL due to a security breach, the process of gaining a new certificate is largely a clerical inconvenience since the identity in question (the website’s domain name) is simply data that can be accessed and updated online by an authorized person.
However, the IoT again raises new challenges. Unlike websites domain names, where addressing a revoked certificate may involve a phone call and re-provisioning of the site’s identity with a new private key, revoking the certificate of an IoT device is significant. Now an entire installed base of “Things” – washing machines, thermostats, industrial sensors, etc. – can no longer connect to cloud services, and will typically require physical intervention to re-provision. This concern may tempt IoT product developers to allow for remote self-generation of a new verifiable identity within the IoT product, but unless this is handled by a tamper-resistant security device, then the developer has simply designed in another security vulnerability.
Of course, if an OEM deployed IoT services in a private cloud for which the certificates are rooted with a Certificate Authority, it can procure CRL services as well. This involves maintaining an online database, so there are costs involved in this approach, and use of a CRL has yet to become the norm in the IoT. Again, closer integration with cloud services providers could include the ability for certificates to be freely registered and revoked, which is the essence of certificates’ lifecycle management.
IoT drives the need for internally generated certificates
Strong identity is becoming critical for developers of any kind of IoT device, for security as well as cost and logistics reasons. More and more, cloud service providers are requiring a two-way trust model based on verifiable digital certificates. These must be internally generated by a tamper-resistant, secure hardware component inside the IoT device to ensure that only authorized devices are accessing their services. By building these certificates into their products, IoT developers can improve manufacturing logistics, reduce costs, and improve customer satisfaction. Ultimately, this capability must be built into security devices to make the process more manageable.