Hardware security verification must go beyond functional testing

Imagine you’re an attacker staring at a billion-transistor system-on-chip (SoC). You don’t care whether the design boots Linux, passes simulation, or meets its performance targets. Your objective is far simpler. Find the one flaw nobody thought to look for.

It might be an undocumented debug port or path. Maybe it’s a configuration error between hardware and firmware. Sometimes it’s a perfectly legitimate sequence of operations that exposes sensitive information in a way the original team never anticipated. A single overlooked weakness is all it takes.

This is why testing for unexpected data paths is crucial. Source: Arteris

Design teams focus on proving that a chip operates according to its intended specifications. Security assurance requires answering a different set of questions to identify the conditions that could violate security objectives. As the above figure illustrates, security verification must test for unexpected data paths that could expose sensitive information, not only confirm that intended paths operate correctly.

Beyond intended behavior

Security verification starts from a different premise. The concern is not whether a protected asset reaches the encryption engine, but whether information associated with that asset can reach an unauthorized destination. A debug interface may unintentionally expose sensitive information, or firmware may fail to clear a memory location after a key has been used. Otherwise, legitimate operations can also interact to create an unexpected path through the system.

Achieving that level of assurance requires security requirements that can be verified throughout the design, measured for coverage, and evaluated across complex hardware-firmware interactions. Those requirements provide the basis for determining whether security objectives continue to hold as the complete system evolves.

Functional security verification evaluates whether a design matches its specification. Engineers derive tests from defined requirements and use them to demonstrate that data, control signals, and system transactions occur as designed.

For example, testing can confirm that an encryption block obtains a key from memory, receives it within the required timing constraints, and completes the requested operation successfully. Those results establish functional correctness, but they do not by themselves address unintended information paths or residual sensitive state.

Find the weakness, not the exploit

One of the biggest misconceptions in hardware security is that engineers should focus on finding vulnerabilities, which rarely manifest as a single, obvious flaw. On the other hand, a weakness is an underlying design condition that can allow security protections to be circumvented, creating multiple opportunities for exploitation in complex designs.

That is why security verification begins by identifying weaknesses rather than individual security exposures. By addressing the underlying conditions, security teams can eliminate entire categories of exposure, reducing risk far more efficiently.

Security weaknesses often emerge through interactions among hardware blocks, firmware, and system configuration. A block-level functional test may confirm that temporary storage holding a cryptographic key is cleared when commanded. After integration, however, firmware may omit or mistime the command, leaving the key resident longer than intended. The block passes in isolation, but the integrated system violates the security objective.

Rather than creating a separate test for every possible vulnerability, a more effective approach is to define the security condition that must hold. A cryptographic key should be cleared when it’s no longer needed. It should never reach an unauthorized block or cross a security boundary except under explicitly approved conditions. Verification then determines whether that condition holds throughout the design.

Information flow at system scale

Information-flow analysis traces critical design assets across a chip as the values carrying their information pass through logical and sequential transformations or intermediate storage locations. Rather than checking only for an expected value at a specified point, the method preserves traceability over time even when the original value no longer appears intact. This visibility helps reveal leakage paths and unexpected security behavior.

Security rules used in simulation at the block and subsystem levels can be carried into emulation for full-SoC hardware, firmware, and software verification. This scalable, repeatable approach also supports third-party IP assurance across the design supply chain. A security monitor generated for a component can then be reverified at the full-chip level, providing evidence that security requirements remain satisfied through integration and configuration.

Security coverage

Security coverage answers a basic question about whether the design was tested well enough. For each security rule, the metric indicates how thoroughly the existing test suite exercised the relevant logic. A passing result carries limited weight when that activity was minimal. The analysis can locate RTL that has not been exercised sufficiently and direct additional testing to those areas.

The resulting data allows teams to track progress and make informed decisions. Coverage does not turn dynamic analysis into exhaustive proof. It shows how much evidence supports signoff and where gaps remain. As regulatory requirements and customer expectations continue to increase, teams need objective evidence of what was verified.

A different way to think about verification

The semiconductor industry has become exceptionally good at proving that designs work. So, the next step is to verify that security objectives are maintained under most relevant conditions. That requires a shift in mindset, from relying on assumptions to defining security requirements, verifying them, and measuring coverage.

Take, for instance, Cycuity, which provides the software needed to put this methodology into practice. The Cycuity Radix platform integrates with existing simulation and emulation environments, allowing teams to verify security requirements, detect security violations, and measure coverage as part of their normal verification flow. Cycuity Radix-S supports simulation-based verification, while Cycuity Radix-M extends the approach to emulation, helping teams evaluate security at full-chip scale.

Security verification is its own discipline, one that must go beyond functional testing to assess whether security objectives are maintained across the integrated system.

John Elliott is a security applications engineer at Arteris, bringing over 35 years of experience in electronic design automation (EDA). His work centers on security assurance for hardware designs, helping designers identify and mitigate security vulnerabilities in semiconductor devices before they are manufactured.

Related Content

• IoT security: Challenges and solutions
• Torture-testing your new SoC’s security quotient
• Hardware Root of Trust Essential for AI Chip Integrity
• Lockdown! Random Numbers Secure Network SoC Designs
• Hardware Security Requirements for Embedded Encryption Key Storage

The post Hardware security verification must go beyond functional testing appeared first on EDN.