Identity in IoT: Put a Stamp On It
By Derek Hornacek| Software Engineer |
As the Internet of Things (IoT) continues to expand, the goal of secure, reliable identity management for devices needs to be top priority. Devices must have a unique identity to interact securely with back-end systems and possibly other devices or mobile applications. Imagine a world where your smart home devices couldn’t distinguish between your commands and your neighbor’s. All of a sudden your neighbor is opening your garage door and turning your lights on and off. This is an exaggerated example of course, and unfortunately something more practical would likely involve bad actors exploiting these security flaws.
In the embedded world, this unique device identity is sometimes referred to as a device stamp (as in you “stamp” the device permanently during manufacturing). Today we’ll dive into what device stamps are, why they’re essential, and how they influence both the development and production stages of IoT products.
Perhaps AI will someday give our devices a different kind of “identity crisis”. Thankfully, today is not that day.
Anatomy of a Device Stamp
So we know a device stamp acts like a digital fingerprint for each device, but what does this look like? Device stamps can hold many shapes and sizes, and this concept is certainly not unique to the IoT space. In some embedded spaces, a device stamp might be as simple as a serial number, and indeed that is a crucial component for creating unique, trusted devices. When we start creating products that need to communicate with mobile applications, other devices, and cloud systems, the need for additional resources in our device stamp becomes apparent.
A typical device stamp that we use on projects here at SpinDance may include:
- Serial Number
- Company/Product Name
- Device public/private keypair and accompanying x.509 certificate (for TLS connection)
- Proof of Possession (used during provisioning products with mobile apps)
- Another public key (also used for authentication while provisioning products with mobile apps)
- Device barcode information
That’s a bit more resources to keep track of! And we definitely want to keep track of these. We normally keep these grouped in their own separate partition that is only for the device stamp. This is a nice way to logically separate the stamp and avoid any accidental overwrites when flashing firmware.
This is also something we want to automate ASAP within the development process. Constructing this manually, even for a developer device, is tedious and error prone. At the very least, we recommend creating a simple shell script to generate and flash these device stamps.
Device Stamps & Manufacturing
While a script should suffice for developers, this also begs the question of stamp generation during manufacturing, which will likely require a much more scalable and robust method of generating device stamps. The problem is, not all manufacturing processes are created equal. Companies of different sizes and industries could have wildly different manufacturing steps. Consider the following scenarios:
- Company A: Has an IoT product ready for manufacturing. They are a smaller company and must outsource the manufacturing of their product. They have chosen a remote company in a different country across the globe that has no internet access, so all stamps must be generated in the factory. Because of the distance and outsourcing, the customer’s number one priority is making the stamp flow as secure as possible. Their goal is to protect the secrets being generated and stamped in the factory, as there is less trust with an outsourced manufacturer. The customer’s main concern is securing the local generation of secret keys from the manufacturer’s, so that no keys are traced. To help with this tradeoff of bolstering security, they are willing to sacrifice some speed in the process.
- Company B: Has an IoT product ready for manufacturing. They are a large international company with the resources and preference to do all of their manufacturing in house. Because of this, their chain of trust during manufacturing is much different. Their main priority is speed of production. The customer’s facilities also have secure internet access, so stamps can be generated in a cloud environment and securely transferred to a factory.
We can start to see just how different these processes can be. Company A’s stamp generation could involve external hardware authentication devices, such as a Yubikey, for the x.509 certificate generation. Company A will also want any keypairs (for communication or encryption) generated on the device itself, rather than a host computer that flashes it to the device. Company A will also want flash encryption turned on immediately after the device is stamped to help limit the possibility of exploitation, which can take extra time that some customers might prefer to do at a different stage in manufacturing.
Company B has the ability to manufacture their products in-house. Not only that, but with a secure internet connection, they can also use a deployed cloud service to generate stamps for them. To take it one step further, it would be much easier to scale out this method to create stamps in bulk. This might require some extra bookkeeping as well, but in the sense of manufacturing speed, it would be far more preferable to create batches of stamps, ship them to the factory, and then simply flash away.
We have seen a few customers with different use cases like these at SpinDance, checkout this great write up from our own Jonathan Rand about security during manufacturing and provisioning, which goes into greater detail some experiences we’ve had around these topics.
Ongoing Management
Of course, stamp security doesn’t stop at the point of manufacturing. It’s great practice to have a policy for rotating out device stamp secrets whenever possible. This can be beneficial on a scheduled basis, but also having the ability to recover in case of catastrophe, such as a compromised root or sub-CA certificate.
However, managing device stamp security throughout the product life cycle is no small feat. It requires careful planning, policies, and infrastructure to ensure that updates are applied correctly and securely, and is a blog post for another day.
Conclusion
Device stamps are a small and necessary piece of IoT products. They are not only necessary for unique devices, but they force us to start considering bigger pictures in products we create. By understanding the role they play, you can ensure that your devices are secure, and your manufacturing processes fit your needs.
Whether you’re just beginning your IoT journey or looking to optimize your existing processes, incorporating device stamps into your strategy early and often is key to ensuring your product’s success.