How to secure your IoT infrastructure
Rapid developments in the Internet of Things (IoT) are transforming the way we live and work. Connected devices are found in every vertical market, from manufacturing to healthcare to retail. We are moving beyond the concept of big data and toward the implementation of massive IoT. Data is flowing through connected devices at unprecedented rates.
Ubiquitous connectivity is an evolving design challenge. The way we secure IoT endpoints is constantly changing but remains essential in an IT network. Although many of the security solutions forged in the IT sector are transferrable to IoT devices, the resources inside IoT devices are still much more limited than traditional IT equipment.
Building a root of trust is the foundation of security. Trusted connections employ encryption based on public and private key infrastructure. A trusted connection is also fundamental to secure device provisioning and software updates.
IT infrastructure benefits from a common software platform to implement security. This common platform does not exist in IoT. There is a sharp transition from IT to IoT. Some may call this the edge. Bridging this transition introduces additional challenges.
Security in IoT needs to be simple enough to run on constrained devices but robust enough to meet IT standards. This combination of simple but secure is essential for scalability, which is the underlying tenet of massive IoT.
IoT device-level security
The hardware and software used to implement security in IoT endpoints varies. This variety brings system integration challenges. The network could require multiple security regimes, hardcoded for each type of device. This scenario of dedicated and differing security policies does not support simple scalability in massive IoT.
The level of security implemented will also vary, from basic to best-in-class. A basic level of security may be low in cost and complexity, but relatively high in risk. It will probably not feature a secure element and use off-the-shelf cryptography libraries.
This is normally the level of security included with development kits designed to provide IoT connectivity at the proof-of-concept stage. It is intended to be simple, but is not production-hardened or designed for scalability.
Using software-based security methods is a better solution, lowering the risk but raising complexity and having a proportionately higher cost. This level of security can scale and is appropriate for production. As a software-based solution, it offers some flexibility and might be a solution adopted at a later stage in a project.
The best solutions are based on hardware secure elements. Hardware secure elements are physical devices designed into IoT endpoints at the board level. Adding hardware-based security is more complex and, with additional components, it has a higher cost. But it offers the lowest associated risk. Hardware secure elements need to be designed-in at the concept stage of an IoT project.
The security continuum
IoT security varies from basic to best. The best security uses a hardware secure element designed onto the PCB of the IoT endpoint.
Scaling up in IoT
The ‘pick 2’ dilemma many OEMs face
It can be difficult to develop a security solution that doesn’t sacrifice either risk, time or cost in favor of the other two.
In many IoT applications, large-scale deployment of connected endpoints is fundamental to the business model. This scaling-up involves more than simply putting more devices into service.
Even if every endpoint is identical, they will differ in one very important way. The online identity of every device must be unique. This uniqueness is managed through identity management. Just like people, IoT endpoints have identities that need to be protected from fraudsters. Identity management is becoming the cornerstone of IoT security.
Identity is managed using digital certificates. Because of the security risk associated, digital certificates are typically issued by an independent trusted partner, or Certificate Authority (CA). Certificates are only exchanged when both parties are sure who they are talking to. This authentication is normally handled using a public key infrastructure (PKI). Keys are used to encrypt and decrypt identities, which provides the authentication needed before certificates can be issued or exchanged between the cloud service and the endpoints.
Your IoT strategy needs to include a robust method for associating digital certificates to your devices, and your devices to your customers. As you scale up, this becomes more complex as your customer base expands and your product offering evolves.
Managing security at this level can result in a dilemma for OEMs. It can mean choosing between lowering their risk of a security breach, reducing the time it takes to implement security, or minimizing the cost of adding the right level of security to their IoT solution.
The Identity of Things
Managing the security of IoT endpoints that employ hardware secure elements is complex. Each secure element has a unique identity. The identity can be read electronically, as OEM needs to know this identity.
In a production environment, identities of pre-secured designs are established by the manufacturer and can be onboarded to the cloud via a common “manifest file,” “white-list” or more technical means such as “attestation.”
Most semiconductor manufacturers, with or without hardware secure elements, will use a different approach to creating a unique device identity for their connected products. These methods vary by manufacturer. OEMs need to understand and accommodate each one at a device level.
This creates what many OEMs are currently experiencing and can be described as a device-first approach to security. It makes allocating and managing certificates more complex than it would ideally be if all semiconductor manufacturers used the same methodology.
Certificates and dynamic identities
The concept of an identity in IoT devices is also evolving. All secure devices come with some form of static identity that is applied at the manufacturing stage. This can be seen as a birth certificate for the device. Like all birth certificates, it is either immutable or very unlikely to be updated.
This baseline identity is useful. It allows certificates to be associated with devices based on the device’s identity. However, if the identity is immutable and it is bound to an OEM, it may present further operational hurdles.
Some of an OEM’s devices may be reallocated to a different customer during the product’s lifetime. This means the certificate will also need to move with the end customer. Also, some end customers may have a security regime that requires certificates to be rotated on a regular basis. Rotating certificates bound to an immutable identity can also be an operational hurdle.
To address these hurdles, IoT technology leaders are developing the dynamic identity. A dynamic identity is secondary to and works in parallel with a static identity. It allows for second, third or more identities that are renewable and modifiable. Instead of being bound to the OEM, a dynamic identity is bound to an end customer through a cloud platform.
Dynamic identities remove the hurdles associated with reallocation and certificate cycling. Conceptually simple, the technology is now being developed to support dynamic identities in a secure IoT infrastructure. This will help OEMs manage, at scale, the traceability of devices and transfer of custody, throughout the product’s lifecycle.
Identity-first security
Device-first security takes the perspective of the IoT device’s design. Using technology that supports an identity-first approach to IoT security tackles some of the hurdles OEMs encounter when deploying and managing endpoints at scale.
Massive IoT needs to be simple, secure and scalable. An identity-first approach makes no assumptions about the design and is less dependent on how security has been implemented.
There are specific challenges and solutions to massive IoT that an identity-first approach addresses:
- Simple: Every secure IoT device needs to have a certificate associated with its identity, and that certificate needs to be allocated to that device. These are two separate but closely linked steps. The challenge is to accommodate the different approaches to secure device identity allocation taken by different semiconductor vendors.
The solution is to use a technology that recognizes these differences and has been designed to provide abstraction between the hardware and the application providing the certification and identity allocation. This may sound simple, but it is not something any semiconductor vendor needs to consider on an industrywide scale. This challenge is compounded because the semiconductor vendors provide the interface OEMs need to use. A better solution would be to use an interface that has been developed by a third party with an industrywide approach.
- Secure: Ironically, if there were no security threats in IoT, then allocating certificates would be as simple as creating an internet connection and transferring a file. And if all devices had the same security requirements, allocating certificates at scale and securely would already be simple. Neither of these scenarios reflect the reality. At a low level, the secure elements designed by different semiconductor manufacturers take a significantly different approach to establishing a secure connection. There are commonly agreed security measures used across the IT and embedded industries. Each company’s intellectual property around security is unique. However, Avnet, through ongoing collaboration, is developing ways to standardize security management across a variety of silicon manufacturers.
Adhering to these protocols is necessary to make secure connections. The solution is to use a technology layer that understands the different protocols developed by each semiconductor vendor. That layer will abstract out the different protocols used to implement common security measures. But that technology layer also needs to be secure, so it must be trusted by the semiconductor vendors and developed in cooperation with their individual technologies.
- Scalable: Making it simple to establish a secure connection between a cloud platform and an IoT endpoint is aided by a trusted abstraction layer. The massive IoT requires this to happen at scale. Furthermore, it needs to scale to both many devices and many customers. This doubles the challenge but more accurately reflects the reality of massive IoT. OEMs with a value-added product offering or service will aim to offer that solution to many different customers.
The solution is to use a technology that supports this business landscape. At a low level, each IoT device will need to have an identity and a certificate, but also be associated with a specific customer. Identical products, differentiated only by their identity, could be sold to customers who compete in the same market. Managing this allocation at scale requires technology that resides both in the endpoint and the cloud platform, and that can negotiate certificate allocation and, over a longer period, customer reallocation.
Secure device management
The IoTConnect® solutions suite from Avnet provides the technology abstraction layer needed to make massive IoT simple, secure and scalable. By partnering with both semiconductor vendors and cloud providers, Avnet can provide secure device management based on recognized security protocols that work seamlessly with hardware from multiple semiconductor vendors.
Part of the solution includes key stores. These manifests represent pre-provisioned identities that include serial numbers, keys, certificates and more. These key stores can be allocated to a customer before the device is manufactured.
IoT device lifecycle management
Following an identity-first approach to security, the lifecycle of an IoT device starts before it is manufactured and is managed through to decommissioning.
The secure device management (SDM) flow starts with the key stores, which are imported in bulk from and associated with specific secure hardware elements from semiconductor manufacturers. A key store can accommodate hardware elements from multiple vendors who use different protocols.
Key stores are assigned to devices, and the devices are allocated to cloud services. When powered up for the first time, the device is authenticated by the cloud service. In a static environment, the devices are allocated their cloud connection parameters. In a dynamic environment, those parameters may be updated at a later stage in the product’s lifecycle.
During operation, the static or dynamic credentials are used to authenticate the device whenever it communicates to the cloud service.
Currently, Avnet’s IoTConnect SDM solution supports identity-first security using static identity management. Preloaded identities are injected at the manufacturing stage and bound to an OEM. This approach doesn’t preclude dynamic allocation from being used in the future.
Avnet is now developing its dynamic identity management solution to provide renewable and modifiable identity allocation. This will provide greater support for OEMs and their customers who need these features.
