Security Verification In Semiconductor Development

By Shylaja Sen and Mouadh Ayache

As advanced chips become increasingly embedded in our daily lives, developers must remain vigilant about potential security vulnerabilities. On top of PPA (power, performance and area), the focus in semiconductor development has been on minimizing faults to reduce the possibility of failure in mission mode. No one wants an alpha particle to cause their autonomous vehicle to steer into oncoming traffic. However, security vulnerabilities are now also a major concern, and malicious actions are every bit as dangerous; no one wants someone to take control of their vehicle and intentionally crash it, either.

Designing in security

Chip developers must design in hardware security, which has three key aspects:

• Confidentiality ensures that secrets embedded in the chip, such as the IP design itself, the configuration data, and secret keys, are protected from unauthorized access.
• Integrity focuses on ensuring that the device performs as intended. Malicious modifications such as hardware Trojans are a threat.
• Availability guarantees that the chip remains operational and accessible when needed, which is vital for automotive and other safety-critical applications.

Securing semiconductors under this “CIA triad” is a challenge spanning the entire hardware lifecycle, from architectural design to deployment in the field. Attack surfaces include both hardware and software layers, but the focus for this post is hardware security. Interfaces, memory, and the underlying semiconductor IP can be compromised by microprobing, side channel attacks, hardware Trojans, and other techniques. Attackers may use multiple techniques, including a mix of hardware and software, at the same time.

Further complicating the security challenge is that attacks can occur at any point in the supply chain, from the design phase through fabrication, test, system integration, and deployment. Addressing these challenges requires focus on two areas during semiconductor development:

1. Security-by-design: This involves building security features and functions directly into the chip architecture. These include security IPs, root of trust, encryption/decryption modules, and active security countermeasures to detect and respond to threats.
2. Security verification: The developer needs to ascertain whether the hardware contains vulnerabilities that can be exploited, for example by probing, side channel attacks, or injecting faults. Such an attack happens not through the normal channels of operation, but rather from external action. Risks include data leakage and taking control of a system.

The best way to ensure that a chip design is secure is to perform security verification as part of the development process. This needs to occur in parallel with traditional functional verification, using a combination of analysis, formal, and dynamic (simulation and emulation) technologies. A security verification plan in addition to a functional verification plan is required to ensure that this process is thorough. It must cover three key steps: early vulnerability analysis, data propagation verification, and modeling malicious attacks.

Early vulnerability analysis

Vulnerability analysis can be accomplished by checking for vulnerabilities early during the register transfer level (RTL) design phase. This enables correct-by-construction design practices and enhances security in the final chip. Several types of vulnerabilities can be detected at this stage in the development process, including:

• Data paths
  • Single data transfer paths can be easily exploited, e.g., by using a laser
• Clock and reset paths
  • Clock or reset signals can be tampered with, leading to denial of service and compromised functionality
  • Trojans can be inserted in clock path control logic
  • DFT scan logic can be an access point
• Finite state machines (FSMs)
  • FSM states with undefined transitions may lead to unpredictable design behavior
  • FSMs are vulnerable to laser fault attacks
  • FSMs are a target for hardware Trojan insertion
  • FSM structures can be obtained through an insider or by reverse engineering

The Synopsys VC SpyGlass RTL static signoff platform provides checks for all these types of vulnerabilities. Designers can use this tool to analyze the data flow of sensitive paths in the design, protect wide data buses, and ensure sufficient control bit logic. They can also ensure that clock and reset sources originate from trusted/secure regions as well as control undefined states and transitions to make FSMs more resilient. VC SpyGlass assigns a vulnerability score based on its analysis and provides help in debugging identified vulnerabilities.

Data propagation verification

The second key step in security verification is data propagation verification to check the security of data both at rest and in motion. Designers must ensure that security-critical data cannot be read illegally (confidentiality) or written from an unsecure source (integrity). If data propagates between a secure source and destination or unsecure source and unsecured destination, there is no security issue. However, data propagation from a secure source to an unsecured destination, or an insecure source to a secure destination, could lead to data leakage or integrity violation.

Data propagation verification requires a combination of formal and simulation techniques. Formal analysis can prove that there is no prohibited data propagation, detecting security issues that are hard to find through other techniques. A formal tool supporting this approach must generate properties when possible and enable easy specification of security rules using SystemVerilog Assertions (SVA). After analysis, the tool either proves each property to be satisfied or provides debug information to guide the designers in resolving the vulnerability.

Synopsys VC Formal provides these capabilities using three advanced applications (apps). The Formal Property Verification (FPV) App provides functional security verification for security-related SVA properties. These represent specific use cases where security is a concern, and should be specified in the verification plan. An example of FPV App use is verifying block writes of all ones or all zeroes to key registers in the design.

For sensitive data stored in the secure registers, register read and write privileges must be respected. The Formal Register Verification (FRV) App provides secure register access verification by ensuring that register protection rules are obeyed. It automatically generates appropriate properties based on an IP-XCAT XML register specification.

Finally, the Formal Security Verification (FSV) App checks to see if a particular source can influence a particular destination, regardless of its value, looking for secure/insecure source/destination mismatches that could result in a data leak or data integrity issue. Relevant paths are identified in the verification plan using “any value” SVA properties.

The simulation component of data propagation verification tracks the propagation of data taints through the design. This entails inserting a taint into the design and seeing how far it propagates (permeability), and for how long (permanence), as the design is simulated. The Synopsys VCS simulator include taint propagation (T-Prop) capabilities for just this purpose. This provides a dynamic solution to assess the confidentiality and resiliency of a hardware design at the RTL stage. It supports such use cases as sensitive data tracing, control tracing, and clock diffusion.

Modeling malicious attacks

The final key step in security verification, modeling malicious attacks, aims to determine whether the design is tamper-resilient. Fault simulation lies at the heart of this process. This technique has been used for many years to determine whether test patterns can detect manufacturing defects, or whether fault tolerant safety mechanisms can detect/correct random faults and soft errors. By modeling different types of tampering with accurate and flexible fault models, fault simulation can also assess the impact of malicious attacks such as high-precision bit-flips induced by laser or even a sequence of multiple faults. Beyond physical tampering, remote attacks can exploit architectural features, such as frequency-voltage scaling, to trigger faults without physical proximity.

The Synopsys VC Z01X fault simulation solution supports this flow. It is built on VCS to provide a seamless transition from functional verification to security verification. VC Z01X analyzes fault propagation and validates that attack countermeasures can detect tampering-induced faults. It offers flexible fault models to accurately mimic the wide range of fault attacks common today.

Conclusion

In summary, security is a critical new metric for chips used in a wide variety of applications. Electronic design automation (EDA) tools play a significant role in ensuring that a chip is secure by design, from security-intent-driven architecture exploration through verification and implementation. This is very much an evolving domain, with standards and methodologies being defined. Synopsys is an active member of all relevant standards organizations and provides a complete solution of EDA tools and IP for chip security. To learn more, watch this on-demand webinar: https://www.synopsys.com/webinars/holistic-approach-soc-security-verification.html

Mouadh Ayache is a senior engineer for solutions engineering at Synopsys.