Locking Down IoT at the Source | Part 3: How HSMs and Automation Are Revolutionizing Secure Manufacturing
Listen to previous editions here:
Ciara: You’ve both talked at length there about making security simple and easy. I guess when we’re talking about scalability, that naturally brings us to manufacturing at scale. Focusing specifically on the manufacturing environment, which presents its own unique security challenges, using secure manufacturing facilities is one of the more common ways to address those threats.
Malcolm, what makes a manufacturing environment truly secure?
Malcolm: That’s a really good point, Ciara. And, you know, effectively, the transfer process we talked about earlier is really the crux of it. We actually encrypt everything that’s being transferred from the OEM. So, that design process essentially wraps everything up, encrypts it, and locks it specifically to one device – the HSM – in our factories that can decrypt it. That HSM is then able to re-encrypt uniquely for each device or create a unique identity for each one.
I think it’s important to state at this point, too, that we’re actually dealing with this at the chip level. Obviously, there’s manufacturing at the PCB level, and there’s manufacturing at the chip level. We’re able to do this at the chip level on our high-volume programming machines because the IAR HSM can interact directly with each individual chip as we place them on the programming machine.
So all the encryption that gets put onto the device is actually locked down to each unique device ID that we read. We put the chip in the programming machine , read its device ID, and send that securely to the HSM. The HSM then encrypts all the information it’s been instructed to encrypt, based on that ID, and sends it back to our programming machine to provision the chip.
This is all done at extremely high speed through a completely automated process. So, at that point, the output from us is a pre-provisioned microcontroller. We can then ship this completely locked-down, secure microcontroller to the contract manufacturer or the OEM’s own manufacturing location.
Schedule a Free Consultation with our Security Expert
Ciara: I think one of the important words you used there was “completely automated,” because I guess as soon as you have people involved, you’re introducing risk. So it’s crucial that anything people do have access to is fully protected. This naturally brings us to the idea of zero-touch provisioning, which seems like it would address that human risk factor in manufacturing. So, what role does the HSM (hardware security module) play in this zero-touch approach?
Malcolm: Effectively it’s about taking people out of the loop again. If humans are involved with anything, there’s ultimately a risk because you can’t manage a person to the level needed to completely avoid them being targeted by a malicious actor. It’s all about making sure the staff in the factories aren’t exposed to any risk. This makes it impossible to, say, bribe them to get hold of a firmware file that could be maliciously attacked. All a person in the factory could potentially get their hands on is what we call a PPKG file from IAR, which is completely encrypted and can only be read internally by the hardware security module.
I think it’s important to mention at this stage that on top of the protection provided by the hardware security module, our factories are also ISO 27001 certified. This means our locations are secure in their own right. We also have additional processes in place, like biometric access to our machines, that we take advantage of as well.
Ciara: Shawn, do you have any points to add on that regarding the HSM or zero-touch provisioning?
Shawn: One question we sometimes get which Malcolm alluded to earlier, is about the encryption. When you send a production package from the OEM to the manufacturer, it’s encrypted so that only the HSM can decrypt it. And this is a FIPS-certified HSM; it has the full meshing, potting, and everything needed so that if someone tries to tamper with the HSM, the box actually erases itself.
So your firmware images and your PKI only exist in an encrypted format on flash within the HSM. Only during actual production time do they get decrypted into RAM to run and generate the keys and certificates for any device you might be using.
The question then arises, “Well, what about the connection between the HSM and the chip itself? How do I protect that? Do you guys take care of that?” And the answer is yes, we do. Different silicon manufacturers have different ways of approaching this. For example:
- ST has their SFI (Secure Firmware Installation), which we work with.
- Renesas has their TSIP, and pretty much everyone has their own method.
But we actually work with each of these methods to secure what we like to call the “last inch,” making sure you’re not talking to a hacker at the end of the programming head, but rather to a real, legitimate device from the silicon manufacturer.
That’s part of the zero-touch policy we talk about. And of course, some people will raise the question, “Okay, if I’m using a legacy microcontroller, can’t you just sand off the top of the chip and read the flash?” And the answer is absolutely. But that’s why there are technologies like TrustZone from ARM that provide hardware tamper resistance to further secure the device.
True security is really a marriage between hardware and software. But even if you’re using a legacy device, we can enable a good level of protection. We can make it so that someone basically needs physical access to the device to compromise it. And when you start using higher-end microcontrollers – higher-end in terms of the security level they provide today – you can even make physical access something that doesn’t really buy you all that much. Because then you might need really expensive equipment, like a focused ion beam, just to read the flash!
So again, what you’re doing is basically ratcheting up the effort required for someone to hack into the device, making it more likely they’ll just give up. They’ll either find an easier target or realize that, as they say, “the juice isn’t worth the squeeze.” But yeah, that’s really a great point Malcolm brought up, and I just wanted to add that extra bit on how we secure that last inch.
Ciara: The HSM sounds impenetrable, and it’s smart to add all these layers of protection on top of each other so that attackers just avoid you and move on to the next potential target.
Looking towards the future of embedded security adoption, how long do you think it will be before embedded security becomes standard practice across the industry? I’ll ask that of you first, Shawn.
Shawn: Shawn: That’s a really interesting question because I kind of see some people trying to get into security. But again, as I mentioned, sometimes they’re just trying to use the same symmetric key across all devices and thinking, “Okay, now we’re secure.” That’s a pretty low bar they’ve just cleared to say they’re implementing some level of security.
I think as more regulations come out – like GDPR in Europe, and soon a special version of GDPR dealing with medical devices, plus the FDA now having cybersecurity regulations for medical devices – it’s becoming unavoidable. It seems like in Europe, IoT devices were the tip of the spear, and then GDPR really brought it to the forefront.
In the US it looks like medical devices will be the tip of the spear, followed fairly closely by automotive. As we look at 5G technologies, automated driving, and how much it depends on communication between cars, authentication and hardware-based HSMs for automotive devices are going to become much bigger deals.
So I see adoption happening relatively quickly because people are getting to the point where they can no longer avoid it. They realize the regulation is either already here or imminent. We’ve actually talked to certain customers, for example, in the consumer electronics space, whose European vendor told them flat out, “We will not sell your product because it doesn’t have any security.” They were trying to hide behind the argument, “Well, we don’t collect personally identifiable information.”
And their vendor basically said, “I don’t care. We have this thing called GDPR. We’re not taking any risks, so we’re just not going to sell your product.” That’s when this particular company – a multi-billion dollar company, by the way – suddenly realized, “We have a security problem we need to address.” And that’s when they really wanted to get ahead of it and find those simple, scalable solutions we’ve been talking about.
So, I think 2025 is really going to be the year where security hits practically everyone. They might think they’re addressing it by clearing that low bar initially, but they’ll probably realize as legislation evolves that they need to up their security game. Unique identity and unique asymmetric keys are going to become the standard benchmark everyone has to meet. So, I think this is going to be a really breakthrough year for security in that regard.
Ciara: Yes I agree. When you’re talking about medical devices or automotive, where there’s a true risk to human life, that really increases the impetus to engage with and implement security for IoT systems. And we can see that shift happening, with hackers moving from targeting IT systems towards targeting IoT systems.
There was recent research from Forescout, backed by the IoT M2M Council, indicating that the number of vulnerable IoT devices has increased by 136%. This highlights that major shift from hackers going after IT to targeting IoT. Given this shift, to finish up, what are the immediate steps manufacturers should take to protect their products and, most importantly, their end customers? I’ll ask that of you first, Malcolm.
Malcolm: Yes, and just as we’re talking, I was thinking about what we call a secure element, which is essentially a hardware security engine. When you think about people taking action, many actually did take action by putting secure elements on their boards. But it’s a scary fact that a lot of those secure elements aren’t actually switched on. That’s often because the provisioning process for those secure elements is really quite complex. Again, putting something unique into a high-volume product isn’t a simple thing to do.
What we do kind of solves two problems there:
- First – we can achieve an extremely high level of security without necessarily needing that separate secure element;
- And second – we’re able to provision unique credentials into each device in high volume.
Thinking about your direct question there, the immediate step is really about taking on board the solutions that are out there – the ones we’re putting out there to help customers fix this complicated problem.
To go back to our three-step approach:
- We have design tools that enable you at the design stage;
- We enable you to securely transfer the necessary files, and then
- We enable you to provision that unique information onto each device.
Our scope on this is broadening; we’re already doing this with several customers, and everyone’s experience so far has been extremely positive.
I’d just really recommend that manufacturers research what we’re doing here at IAR and EPS Global. Reach out to us when you need support, because the solution is there to help. It’s not expensive when you consider the potential costs if you don’t put security in place. And the quality of what we’re doing is extremely high. So, yeah, reach out to us.
Ciara: Perfect. And Shawn, your final thoughts on immediate steps manufacturers should take?
Shawn: Shawn: I would just add to that our Embedded Trust solution can also target secure elements if you feel that’s what you want to do, maybe to try and retrofit some security onto an existing hardware design. There are some design challenges with that, like making sure the bus on the PCB can’t be sniffed – so there are potential side-channel attacks. But, you know, we have experience with that and can help you understand the different things you need to think about.
There’s also another aspect. Some people might be thinking: “Well, I’ve had this hardware design out there for years. I really need security, but I don’t want to completely redo everything we’ve done, especially certifying the existing firmware.” For that situation, we actually have something that’s part of Embedded Trust called ESecIP. This is a late-stage security addition that allows you to retrofit an authenticated boot onto a device.
Now, ESecIP is a bit different from the full Embedded Trust in that while it does give you authenticated boot, it doesn’t provide the ability to do firmware updates. However, it can at least give you that authenticated boot and buy you time as you work on a more robust security design for your next implementation.
So as Malcolm said, the security solutions aren’t very expensive. I like to say that good security is hard, but if you’re using really good tools, security becomes way simpler and easier. It’s also really beneficial when you have a trusted entity in the security game.
IAR Systems has filed over 30 different security patents related to our products and services, all aimed at helping customers tackle these challenges. But at a minimum, if you’re trying to roll your own security, you absolutely need asymmetric keys on each device to provide unique identity. These asymmetric keys then allow you to generate symmetric session keys for things like firmware authentication or passing messages back and forth. Those two elements – unique identity via asymmetric keys and secure communication via symmetric keys – along with hash functionality for signing data or firmware, basically form the crux of what you need.
It can seem a little challenging and maybe a bit scary, but when you use the right tools and have security experts in your corner for a relatively inexpensive price, you can check that security box confidently, knowing you have a world leader supporting you. Combining that with the manufacturing, programming, and provisioning capabilities of EPS Global means that when your C-suite asks, “What are we doing about this security thing?” you can confidently say: “We’ve already checked that box. We’ve got it taken care of.”
Ciara: And they’ll probably say, oh, great! On to the next thing.
Shawn: They’ll say, all right, thank you. Yes, exactly.
Ciara: That’s a really positive way to finish off this podcast, Shawn and Malcolm. Thank you both so much for your valuable insights. It’s clear that embedded security is no longer optional but absolutely essential for product integrity, brand protection, reputation, and regulatory compliance.
While the challenges we’ve discussed exist – particularly around implementation complexity and perceived cost – security solutions are readily available that can simplify and scale the process, protecting devices throughout their entire lifecycle. The manufacturers who act proactively on security will not only meet their regulatory requirements but will also gain a significant competitive advantage in an increasingly security-conscious market.
I’d like to thank you both for joining me today on The Critical Lowdown, and we’ll speak again soon.
