Locking Down IoT at the Source | Part 2 : Design, Secure Manufacturing & Provisioning

In Part 1 [https://www.epsprogramming.com/podcasts/locking-down-iot-at-the-source-how-vulnerable-is-your-manufacturing-part-1/], we dove deep into the escalating threats facing IoT devices – from sophisticated supply chain attacks to the challenges posed by new regulations and AI, highlighting why securing the billions of connected devices is critical. 

Now, in Part 2, we shift from the 'why' to the 'how.' We reveal the practical steps and powerful tools available to implement robust embedded security right from the start. ============================= 

Ciara: For a relatively low cost, you are protecting yourself from brand and reputational damage. You're protecting your brand. Additionally, it's not just about preventing the leaking of consumer data; ransomware attacks represent very costly liabilities that could often be avoided. 

Beyond these cost considerations there seems to be a more fundamental issue with how security is approached in product development. Malcolm, you and I have discussed in the past how connected devices should ideally be designed with security at their core. Yet, security is often implemented as an afterthought. Why do you think this is the case? 

Malcolm: I fundamentality think it comes down to complexity. In the past implementing security has often required deep knowledge and specialized resources, which are typically not inexpensive. Effectively, a significant investment is required. Also, companies may not fully understand all the available solutions that can help them, which we'll discuss shortly. 

And, referencing Shawn's earlier point, we are trying to simplify this process, and I believe we've certainly succeeded in doing that. But it's understandable why companies might be scared about it. When you consider encryption, the different types available, how they fit into legislation [https://www.epsprogramming.com/blog/secure-your-iot-future-navigate-the-e15-million-compliance-challenge/], what specific encryption methods are required, and what kinds of identities need to be embedded in a product, it can quickly become a vast area requiring significant investment. So what we’re trying to do is to simplify that and make the entire process much more straightforward. 

Ciara: Shawn, the same question for you. Considering the importance of removing the complexity involved in securing embedded devices [https://www.epsprogramming.com/services/embedded-security], what are your thoughts on this? 

Shawn: Building on what Malcolm just said, we often see customers feeling apprehensive simply because they know they need some security. Regulations either already exist, or they know regulations are coming, so they want to get out in front of it. But the questions remain: What should we do? What are the best practices? 

The onus then falls on the company to determine their security strategy. They might be a medical device manufacturer, a consumer electronics company, or involved in avionics. They excel at creating valuable products in their respective fields, but they aren't necessarily security experts. Now they're being asked to tackle this additional problem, and this can create fear and maybe a little bit of avoidance around it. 

So, what we've seen is people trying to approach this by saying, "We're just going to develop devices like we normally do, and then we'll add some bolt-on security at the end, like signing and encrypting the firmware." And, you know, that's okay, but it's not really the best approach. What we really want are security solutions that are simple and scalable. 

Scalability is a problem most people don't even realize they have until they hit manufacturing. Then they suddenly realize, "I have a secure provisioning problem." In other words, how do I generate keys and certificates? How do I get them onto the device securely? And how do I do it in a way that guarantees I'm communicating with a genuine device and not some hacker? 

So, making security simple and easy for development teams to use is absolutely crucial. But here's the really interesting thing: we have a concept we like to call "security from inception." If you put security in from the very beginning of your project, you're essentially threading it through the project's DNA. 

What this allows your developers to do is use some of those security assets while they're developing the application. And they'll think of incredibly inventive ways to use those tools in their toolbox to further secure the application. 

So, let's say, for example, they get a message from another device that's supposedly from the same company. But you don't necessarily trust that. How do you know it really is? Well, there's an API where you can check the authenticity of signed messages. There's also an API where you can sign messages yourself, and others can check their authenticity by verifying who signed your end certificate. 

And trying to add all that complexity yourself is daunting, to say the least. But if you have a security solution that makes things like this simple, easy, and scalable, I think that addresses one of the big barriers to adoption. If we can get past that barrier – which we believe we have with our Embedded Trust tool – it gives people the capability to thread that security through the DNA of their project. And then, I think the avoidance issue will simply go away at that point. 

Ciara: Okay, really interesting. I guess getting into the meat of the solution, what does securing an embedded device actually look like? 

Malcolm: We've joined up with Alan and Kira, we've effectively got a three step solution that we that we work with. 

1. Design 
2. Transfer 
3. Provisioning 

These are three very distinct areas where we support customers, guiding them through that transition from design, to transfer, and then to provisioning. 

Design: If you think about the design process, that's all about supporting the firmware engineer in an OEM company. They need to think about: How do I encrypt that function? How do I encrypt that data? What kind of identity do I need to set up in the HSM? How do I set up an HSM for production? This is all handled by the tools Shawn just mentioned from IAR [https://www.iar.com], called Embedded Trust or ESecIP [https://www.epsprogramming.com/security/esecip/]. That solution is delivered as a package to support the customer, backed by great support from IAR. 

Transfer: The transfer process, then, is about what that design tool outputs. This is effectively an encrypted file containing the entire customer project, and importantly, it's locked to one specific hardware security module (HSM) located in our programming centers. Within EPS programming centers, we have high-volume programming machines with integrated security points and HSMs. Only that specific HSM is able to read the data created back at the OEM. 

At that point, the HSM takes control, meaning there's no visibility for anyone in the factory or during the transfer process itself. Secure credentials and secure firmware are then injected uniquely into each microcontroller, making the process extremely secure. You know, even if one device were somehow hacked – which would be very unlikely – the same process would have to be repeated for the very next device. So, it really stamps out cloning and related security threats as well. 

Importantly, during that design stage, you also specify exactly how many devices you want produced. So, if you want to produce a thousand devices, you tell the software during the design stage that you need a thousand. That number is then transferred all the way through to the provisioning stage. 

Then, once we've provisioned those thousand devices, the machine will effectively stop and indicate that the requested quantity has been fulfilled. To produce more, we have to go back and get reauthorization from the OEM. This makes the whole counterfeit threat very avoidable. 

Shawn: Yeah, I've talked to a number of customers who try to put a single symmetric key across every single device in a particular SKU. The problem, which they sometimes don't realize, is that this actually creates a class attack vector. If that one key gets compromised, somebody can attack the entire product lineup. 

But as you alluded to, Malcolm, if you're using different keys for every single device, it enables you to create devices that are uniquely authentic and have unique identities, so you can identify them individually. Compromising one device doesn't allow a class attack because you'd have to compromise every other device separately. 

And, you know, what our solution does is it makes security easy. So, I'll give you a few more details on how it makes security easy, because I think we've cliffhanged you enough! Essentially, when you go to create security, you create what we call a "security context." We provide a nice little wizard program that lets you select the specific device you're using. Based on that device selection, it shows you all the security options available for it. 

So, for example: Do you want to disable JTAG? Do you want to disable external memory access? All the policies and lockdown procedures available for that device are presented in a simple, click-like interface where you can set exactly what you want. Additionally, that security context contains the PKI (Public Key Infrastructure) used to sign the certificate for an individual device, as well as all the keys needed to authenticate any firmware uploaded to the device. 

So, it provides keys for power-up validation, keys to authenticate incoming software updates, and keys to authenticate the firmware image currently on the device. It also gives you the ability to keep multiple images. For example, if you have a functional safety device, you might need to keep an encrypted copy of the last known good firmware, just in case something happens to the current firmware, ensuring you have a version ready to boot. 

All of that is contained within that security context, configured through a very simple wizard. And when you create that context, it then instructs the Embedded Workbench – our compiler, assembler, linker, and debugger tool – to generate the secure boot manager. It automatically pulls in all the necessary source code to build it, and it builds and works right out of the box. 

And the really cool thing is, even though it works out of the box, there's probably some "secret sauce" you want to add during device startup – maybe to check things like enabling DDR or performing some power-on self-tests for the device. Because the code for the secure boot manager is delivered to you in source form, you can add to or modify that source code as needed, adding that last 10 to 20 percent to make the secure boot manager exactly what you want. 

But here's the really cool thing that most people don't think about. We just went through this with COVID and the era of silicon shortages, where you might not be able to get the silicon device you originally planned for and suddenly have to switch manufacturers. What does that do to your security posture? Well, if you're using the silicon vendor's specific security solution, you basically have to completely rip that out and re-architect everything. But you know what happens if you're using Embedded Trust? It adds about 15 to 20 minutes worth of work. 

Because you can completely recreate that security context, it will pull in the correct source files for your new device. Then you can compile it, build it, and in about 15 minutes, you're ready to rock and roll. The only thing left is testing it to make sure it still does exactly what you want and to satisfy yourself that it's doing everything it needs to. 

But basically, it takes something that could cause a schedule hit of anywhere from a few weeks to several months – trying to change microcontrollers from a security perspective – and shortens it down to 15 minutes plus whatever testing time you want to put in, maybe a few days. 

So, it drastically simplifies the security solution. And as I mentioned, it gives you that secure API – that security toolbox – which developers can access from the secure boot manager. This lets them get at the security assets to authenticate messages or verify things coming from the OEM, ensuring they really are coming from the OEM. 

Encrypting data stored on the device is another key aspect. Some of the medical device manufacturers we work with are particularly interested in this – encrypting data in such a way that you'd need physical access to the device and would have to compromise the microcontroller's physical security to actually get to that data. So, even if someone could somehow access that data over the internet, without the keys, what good is it? It really diminishes the value of the data to an attacker. 

These are just some of the ways we approach it. Our solution can also leverage any hardware accelerators available on the device to speed up encryption or hashing operations. By default, though, we deliver everything in source code form. This allows for full auditing and accountability, and it also makes the solution incredibly portable across different architectures. But if you do want to use the crypto blocks on the microcontroller for hardware acceleration, that's a pretty simple and straightforward thing to enable as well. 

That's really what we mean when we talk about making security simple and scalable for everyone. And, as Malcolm mentioned earlier, and I think we're probably about to get into it, the manufacturing aspect is really one of the more interesting parts of this whole process.