As threats evolve faster, protecting security algorithms from design through manufacturing and across the supply chain is becoming more difficult.
Key Takeaways:
Security algorithms reside in multiple levels of the supply chain, and while that can help make systems more secure, it also can make it more difficult to keep everything synchronized.
Algorithms touch everything, from the individual processing elements in a multi-die assembly to the software that runs on them, and the interactions between systems of systems. The challenge is keeping track of all of these various elements amid different update and upgrade schedules that may involve multiple vendors, different workloads, and unique architectures.
“From a hardware designer’s perspective, security algorithms are no longer just abstract math sitting in software libraries,” said Scott Best, senior director of silicon security products at Rambus. “They are instantiated directly in silicon as tamper-resistant protocol accelerators, root-of-trust blocks, and secure execution environments.”
The required hardware IP blocks are integrated at design time and are subsequently relied upon throughout the device’s lifecycle. “This goes from secure provisioning steps during manufacturing (e.g., ones that bind identity and keys to each device) through mission-mode operation, to secure debug and RMA,” Best explained. “In mission-mode deployments, those algorithms that are anchored in hardware are relied upon for a wide variety of secure operations, protecting data at rest, in motion, and in use.”
Cryptographic algorithms and the security services and features built upon them are anchored in hardware roots of trust. “The chip design process takes on the order of months/years,” said Nicole Fern, principal security analyst at Keysight EDA. “A part can exist in the field for decades, especially in automotive and military applications.”
Because security algorithms reside in multiple levels of the semiconductor design ecosystem, understanding how they work together and interact is critical. “To unravel the intricacies of security during product phases, it is important to classify security as well-defined services/missions,” said Sylvain Guilley, chief technology officer and co-founder at Secure-IC, a Cadence company. “Then, the rationale is very simple. There is a need for security algorithms each time a mission encounters a risk.”
According to Guilley, some of these risks include:
There are also risks in device decommissioning. “We don’t want a ‘kill switch’ attack,” Guilley said. “This command must be authenticated. We notice here that some missions are interdependent. We need a proper chip identification. Otherwise, a single signed command can still terminate all the devices in one fell swoop. And identity itself needs a proper initialization.”
Building cryptographic agility into hardware
Many chips and SoCs are still designed without a built-in hardware root of trust, secure identity, and scalable update/remediation support, making it difficult to verify, patch, and defend downstream systems over their full lifecycle.
Keeping security algorithms up to date, especially in products with long lifecycles, requires anticipating such future threats as quantum computing. That allows them to be addressed at the design architecture, and implementation stages. “Taking quantum computing as an example, hardware accelerators to support post-quantum cryptographic (PQC) algorithms are already being included alongside support for RSA and ECC,” Keysight EDA’s Fern said.
Being able to securely update firmware and issue patches for ROM and microcode is critical to keeping systems up to date. “Doing this in a secure fashion requires a root of trust that can support authentication, attestation, and anti-rollback flows,” she said. “Therefore, device provisioning and firmware signing flows must also implement best practices to protect critical assets such as signing keys and other secrets injected into the device before deployment.”
Part of the challenge here is ensuring that algorithms can be easily updated, said Reed Hinkel, director, strategic programs, security, processor, wireless, and NVM at Synopsys. “How do you create the secure identity, the immutable identity? How do you create a secure boot? How do you enable that and provide the methods to create the environment for being able to bootstrap firmware securely in an encrypted fashion on devices? [At Arm,] we advocated for that in the industry and adopted a lot of it. Unfortunately, it didn’t get used in the way that it should have been — voluntarily — and that’s kind of what caused the whole CRA (Cyber Resilience Act) movement, which is good for the industry. But that’s where the United States is probably a little bit further behind, because we don’t mandate a regulatory structure. Many manufacturers that care about their products do the right thing and know how to do it. They enforce it correctly. Anyone who has a supported computer for work has a remote management system service, and it keeps it updated and protected, does virus scans, and uses anti-malware, etc. There are some startups providing this service for IoT or edge devices, and they’re working with a lot of the semiconductors, but they’re applying things late. They’re coming in on a platform that may not have the hardware root of trust that they need, and this is where we believe PUF technology can create the root of trust for secure device management.”
Developers can also go through the supply chain and ask where a device has been and what was done to it. “Was it tested? Was firmware implemented? You can digitally track that whole system,” Hinkel said. “There have been efforts here. One of the first was that NIST undertook this whole issue around the software bill of materials and mandated, for certain things, the software bill of materials that makes sure you’re at least aware of bugs. You can scan the bill of materials, and if somebody says that the XYZ component was breached, it needs to be remediated, then you could at least go out and scan all your devices and say, ‘This was the bill of materials that went into this set of devices. I know these are going to need to be remediated in some way.’ This is, more or less, how we handle all the triggers to mandated updates, depending on severity. Severity determines whether you do an immediate or delayed update. The longer-term goal is to enable the same kind of tracking for hardware bills of materials, including SoC hardware within a system. An SoC bill of materials could go all the way down to the cryptographic components, allowing system reports to show exactly which crypto is in use and what may need remediation, and these are the kinds of things that we need to do. The industry naturally avoids doing it because it adds cost. It doesn’t add perceivable, immediate gratification to their customers. But when ransomware causes real disruption, and people can no longer use their devices, they will care deeply.”
The problem is that most consumers will just throw a device away and start over, because they won’t pay the ransom on a low-value device, and won’t really care until they’re locked out of a $2,000 phone.
“This is why companies like Apple and Samsung invest so heavily in security,” Hinkel said. “An iPhone likely includes $80 to $100 worth of security features because they see the value in building trust. Rather than competing only on price each year, they position the phone as a device you can run your life on—and for that to work, users have to trust it. They need to prevent breaches that would either compromise that trust or create the perception that the device is not secure.”
The same is true for the hyperscalers. “Hyperscalers have to do it because if they want to run government workloads, they must comply with multiple government regulations and guidelines that mandate these security measures,” he said. “As a result, they’ve had to develop ways to meet those requirements, which include FIPS-certified (Federal Information Processing Standards) algorithms, certified cryptographic modules, firmware signing, secure firmware updates, and bills of materials. The core issue is how to remediate systems quickly. In large data centers, manual updates are not practical, so updates must be deployed remotely, securely, and with as much automation as possible. That is why solutions are being built, such as Caliptra, through the Open Compute Project Foundation. Caliptra is essentially a TPM-like (Trusted Platform Module) security block that can be built directly into a chip, enabling government-accepted firmware signing and automated updates. The same principle applies in vehicles. For example, modern cars already rely on this kind of coordinated update process behind the scenes. Instead of pushing separate updates to each component, manufacturers now send fully tested update packages that are distributed across the system, which avoids version mismatches and reduces failures.”
This kind of mechanism ensures each component is running the correct version, updates anything that is not current, and prepares the system so the operating system or hypervisor can run immediately. That speed matters because some operators have only a short window to update systems before they must take servers offline. Post-quantum cryptography is also becoming a requirement. In the United States, federal workloads are expected to run on post-quantum-capable platforms by 2029, which is why Microsoft, Google, AWS, and others are updating their next-generation servers so that all internal components also support post-quantum security. Many are using open-source solutions like Caliptra to help meet those requirements.
However, that solution is designed for the data center use case, not for IoT devices. Hinkel expects to see similar initiatives for IoT in the future, some of which Synopsys may be involved in. “We are already very involved in Caliptra because, even with open-source components, companies still need help integrating, supporting, and verifying them to ensure they are suitable for production systems. Many organizations that need to adopt this technology do not have deep security expertise, or they prefer to focus their time on their core business.”
When it comes to embedded devices, specific situations require focused approaches.
“Today, in an embedded device like a home router or network hub that uses AI or other security features, security updates on those devices are usually not mandatory, so the homeowner effectively becomes the IT administrator,” noted John Weil, vice president of IoT and Edge AI processor business at Synaptics. “Some vendors offer automatic updates, but many still require manual installation. For years, the semiconductor and software industries have provided ways to deliver incremental patches or even fully replace device software to meet current security standards. The challenge is that responsibility often stops with the vendor. They release the fix, but it is up to the user or operator to install it. Governments are still debating whether that model should change. Consumers see this all the time. A TV prompts you to update its firmware, but it rarely appears at a convenient moment, so many people delay it. Then there is the fear that the update could fail or break the device, leaving the average homeowner unsure what went wrong or how to fix it. That is why some people resist continuous updates, even though any connected product can become a security risk. And that risk is only growing more complex.”
On the algorithm side, the industry already uses a wide range of cryptographic methods in both hardware and software. The next big shift is to post-quantum security. “The post-quantum threat is no longer science fiction,” Weil said. “It is likely to become a real issue within our lifetimes, and possibly within our careers. Some researchers are publishing estimates on the post-quantum timeline and when that level of computing power could become broadly accessible. A few years ago, I would have said the capability existed only at such a small scale that it was mostly limited to nation-state actors. I no longer think that is true. The field is advancing quickly, and tasks that once might have taken months to crack could eventually be done in seconds or minutes.”
This means security algorithms, including post-quantum cryptographic security algorithms, must always be up to date. However, the level to which those must be kept updated depends on the threat model.
“Devices that generate, store, or transmit data are at the greatest risk,” Weil said. “That includes both data at rest and data in transit. If someone can compromise a device handling data in transit, they may be able to capture that data now and decrypt or exploit it later. Looking ahead, the biggest early risks are likely to be communication systems and critical infrastructure networks. Any system that supports remote decisions, commands, or control could have its behavior altered if it is not protected. Those are the areas where post-quantum safeguards will matter most. There is a great deal of work to do. In some ways, this reminds me of Y2K. Back then, many people feared that aging systems would fail all at once — from power grids to factory equipment. I do not know what the worst-case version of this looks like, but as with Y2K, enough people are thinking about it early that I believe we can reduce the risk before it becomes severe. What worries me most is data theft happening now. If sensitive data is exposed because basic security was not in place, no one in the industry can undo that later. Once that data is out, it remains vulnerable. These concerns are real, but fortunately, the major semiconductor companies are already working on them.”
Industry sea-change with PQC
Still, the security standards process can be slow-moving and yet highly deliberate, Rambus’ Best noted. “Cryptographic protocols that are promoted to NIST standards are generally longer-lived than the operational lifetime of most microelectronic systems. However, the security community is currently going through a generational sea-change with the adoption of quantum-safe protocols. It is a highly dynamic time for new protocol adoption. Keeping current with these emerging standards means designing for change at the hardware level. The best approach is to build cryptographic agility into the silicon, where root-of-trust architectures rely on updatable bitfiles, firmware, and modular algorithm support rather than hardwiring a single scheme. That way, when standards evolve, or new threats emerge, microelectronic vendors can securely adapt fielded devices without costly silicon re-spins.”
From the supply chain side, this also includes a chain of custody. “This is important in the context of chiplets, where there are multiple owners (a chiplet exists as a standalone chiplet in the first place), and then it is a constitutive element of a chiplet system,” said Secure-IC’s Guilley. “Also, when provisioning, we allow for multiple keys. Hence, if one key is compromised, we have backups. Regarding algorithms, we implement crypto-agility. For provisioning, those algorithms can be selected by an OTP flag.”
Apart from provisioning, which is an immutable service, other missions are updatable, and switching algorithms is part of the FW configuration, which decides on the selected “cryptographic mechanism” (algorithm + mode of operation + key size), and keeps it in its context. Consequently, an update of hardware crypto-algorithms is done by firmware update over the air (FUOTA).
For chip architects and engineers, the first step is to look at the entire system. “At the design stage, the use of third-party IP is already a supply-chain issue,” noted Jason Oberg, fellow, security solutions at Arteris. “If you are building a root of trust and buy an AES core from an unknown vendor just because it is cheap — or download one from the internet — you introduce risk immediately. You need a way to validate that the IP is trustworthy and secure.”
There is also concern — especially in government circles — about tampering during manufacturing, but given how complex these devices are, that is less likely than other risks. “A more realistic threat is theft,” Oberg said. “Someone steals the chip or die, repackages it, and sells it as something else. That creates counterfeit products, IP theft, and rebranding concerns. Export control is another major issue, especially when it comes to preventing sensitive technology from reaching adversaries.”
Step one is recognizing the breadth of the problem. “There is no single solution because the right controls vary at each stage of the supply chain. Our work focuses on the design side, where we think the most practical security gains can be made by ensuring third-party IP is secure. That is the priority because the design stage is much easier to attack than the manufacturing stage,” Oberg said. “Someone could steal a chip and reverse-engineer it or create counterfeits, but that is a different kind of threat. A more direct attack is to insert a flaw during design so it can be exploited later in a data center, vehicle, or defense system. Planting a malicious bug in RTL code is far more feasible than trying to alter the chip during fabrication, which is why we focus so heavily on design-side supply-chain security.”
Related Articles
IC Security Threats Spike With Quantum, AI, And Automotive
Post-quantum cryptography emerges as the top concern, followed by AI and automotive complexity.
Security Requirements And Penalties Grow For Chipmakers
The cost of designing chips and IP will increase, and companies at fault for breaches will be liable for damages.
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply