💻 computer science

Assertain: Automated Security Assertion Generation Using Large Language Models

Assertain is an automated framework that leverages large language models with self-reflection refinement to generate accurate SystemVerilog security assertions from RTL designs, significantly outperforming GPT-5 in vulnerability coverage and flaw detection while reducing manual verification effort.

Original authors: Shams Tarek, Dipayan Saha, Khan Thamid Hasan, Sujan Kumar Saha, Mark Tehranipoor, Farimah Farahmandi

Published 2026-04-03

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Shams Tarek, Dipayan Saha, Khan Thamid Hasan, Sujan Kumar Saha, Mark Tehranipoor, Farimah Farahmandi

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are building a massive, incredibly complex digital city called a System-on-Chip (SoC). This city has millions of tiny houses (circuits), roads (data paths), and security guards (logic gates). As these cities get bigger and more interconnected, it becomes nearly impossible for human architects to manually check every single door, window, and wall for hidden weaknesses.

Traditionally, if you wanted to secure this city, you'd have to hire a team of experts to write thousands of specific rules (called Security Assertions) like: "If the front door opens, the alarm must sound," or "No one can enter the vault without a key." If the humans miss a rule, a hacker can sneak in. If they write a rule wrong, the security system might crash or ignore real threats.

Enter "Assertain": The AI Security Architect.

This paper introduces Assertain, a new tool that acts like a super-smart, tireless AI architect. Instead of waiting for humans to write every rule, Assertain automatically writes the security rules for your digital city. Here is how it works, broken down into simple steps:

1. The "Cheat Sheet" (Knowledge Mapping)

Imagine you are trying to find all the weak spots in a castle. Instead of guessing, you have a giant encyclopedia of known castle weaknesses (called CWE, or Common Weakness Enumeration).

What Assertain does: It looks at your digital city's blueprints (the RTL design) and asks, "What kind of building is this? Is it a bank? A communication tower?"
It then cross-references this with a list of threats you are worried about (like "Can someone steal the keys?" or "Can someone eavesdrop?").
By combining the building type and the threat, it creates a Target List of exactly which weaknesses to look for. It doesn't waste time checking for "fire" in a building made of water; it focuses on the real risks.

2. The "Drafting Phase" (Context-Aware Generation)

Now, the AI needs to write the actual security rules.

The Problem: If you just ask a standard AI, "Write a security rule for this," it might hallucinate (make things up). It might say, "Check the blue door," when there is no blue door in your design.
The Solution: Assertain acts like a strict editor. It feeds the AI the entire blueprint of the city, line by line. It tells the AI: "You are a master security engineer. Look at these specific wires and switches. Write a rule that fits exactly what exists here."
It generates a massive list of potential rules, trying many different angles to make sure it doesn't miss anything.

3. The "Self-Correction" (Refinement)

This is the magic trick. Even smart AI makes mistakes.

The Process: After the AI writes a draft rule, Assertain runs it through a Self-Reflection check. It compares the rule against the actual blueprints again.
The Filter: If the rule says, "Check the red wire," but the blueprint only has a green wire, Assertain deletes that rule. It fixes the grammar, ensures the logic makes sense, and makes sure the rule is actually executable by the verification tools.
Think of it as a spell-checker that doesn't just fix typos, but also checks if the sentence makes sense in the real world.

Why is this a big deal? (The Results)

The researchers tested Assertain on 11 different digital designs (like a password checker, a memory unit, and a communication chip). They compared it to a standard, powerful AI (GPT-5) working alone.

More Rules, Better Rules: Assertain found 61% more correct security rules than the standard AI.
Catching Hidden Flaws: It found 67% more deep architectural flaws.
Real-World Example: In one test, the AI noticed that a password system didn't change its "challenge" code, making it easy to hack. It wrote a rule to catch this. In another, it noticed a security guard could accidentally act as both the boss and the prisoner at the same time, and wrote a rule to stop that confusion.

The Bottom Line

Assertain is like hiring a tireless, hyper-observant security consultant who never sleeps. It reads the blueprints, knows the latest tricks hackers use, and automatically writes the perfect security guard instructions for your digital city.

It doesn't just check if the city works; it checks if the city is safe against things we haven't even thought of yet. This saves human engineers from writing thousands of boring, error-prone rules and helps us build hardware that is secure by design, not just by luck.

1. Problem Statement

Modern System-on-Chip (SoC) designs are becoming increasingly complex, amplifying hardware security risks. Traditional verification methods face significant bottlenecks:

Manual Bottleneck: Writing security-centric SystemVerilog Assertions (SVAs) requires deep domain expertise and manual effort, which is time-consuming and error-prone.
Scalability Issues: Traditional Assertion-Based Verification (ABV) struggles to scale with growing design complexity and evolving threat landscapes.
LLM Limitations: While Large Language Models (LLMs) show promise in code synthesis, existing approaches for security property generation suffer from:
- Hallucinations: Generating assertions referencing non-existent signals or using invalid syntax.
- Lack of Threat Awareness: Failure to map design behaviors to standardized vulnerability classes (e.g., CWE).
- Context Inconsistency: Assertions that are not executable by formal verification tools due to semantic mismatches.

2. Methodology: The Assertain Framework

The paper proposes Assertain, an automated framework that integrates RTL design analysis, Common Weakness Enumeration (CWE) mapping, and threat model intelligence. The framework operates in three distinct phases:

Phase I: Knowledge Mapping (Semantic Alignment)

This phase grounds the generation process in reality by aligning design and threat contexts to a standardized ontology (CWE).

Structural Alignment ( $M_{rtl}$ ): An LLM classifies the input RTL design into predefined hardware categories (e.g., "Memory Components," "Communication Interfaces"). This maps the design to a static knowledge base of representative CWEs, preventing the LLM from hallucinating vulnerability mappings.
Threat Vector Integration ( $M_{threat}$ ): User-defined threat models (e.g., "Side Channel Attack") are normalized and mapped to specific CWE identifiers via a lookup database.
Context Intersection: The target search space ( $C_{target}$ ) is defined as the intersection of structurally implied weaknesses and threat-derived weaknesses. This ensures generated properties are strictly relevant to the specific attack surface.

Phase II: Context-Aware Generation

An LLM is deployed to generate candidate assertions based on the target weaknesses.

Prompt Engineering: The prompt includes three layers of context:
1. Role: Expert hardware security engineer.
2. Vulnerability: Definition and examples of the specific CWE.
3. Design: Full RTL source code (verbatim) to ensure signal binding accuracy.
Iterative Synthesis: The LLM is queried $N$ times per weakness to maximize coverage. It outputs structured triplets (Security Scenario, Natural Language Property, Candidate SVA) in a Markdown table format.
Rule-Based Constraints: The prompt enforces strict syntactical and behavioral rules, including:
- Mandatory use of antecedent-consequent formats (|->, |=>).
- Strict timing logic (synchronous vs. combinatorial).
- Signal integrity checks (only existing RTL signals).
- Prevention of vacuous (trivially true) properties.

Phase III: Self-Reflection Refinement

To mitigate hallucinations and ensure executability, a refinement module processes the raw candidate assertions ( $P_{raw}$ ) against the full RTL source ( $D$ ).

Verification: Extracts valid identifiers (wires, regs, ports) from the RTL and verifies that all signals referenced in the assertion exist in the design ( $Signals(a) \subseteq Signals(D)$ ).
Filtering: Removes assertions referencing undefined signals or macros.
Synthesis: Emits a clean, compilable .sva file with proper headers, type declarations, and error messages.

3. Key Contributions

Unified Framework: First framework to unify structural RTL analysis with threat model intelligence via design-aware CWE mapping.
Self-Reflection Mechanism: Introduces a novel "generate-then-refine" loop where a second LLM pass validates signal existence and syntax against the source code, significantly reducing hallucinations.
Architectural Gap Analysis: Unlike traditional verification that checks if RTL matches a spec, Assertain generates "negative tests" to evaluate if the design adheres to ideal security principles, identifying architectural gaps (e.g., lack of glitch protection, replay vulnerabilities) even if the current RTL is functionally correct.
Comprehensive Coverage: Generates both security-centric and functional properties, covering a wide range of CWEs from information leakage to fault tolerance.

4. Experimental Results

The framework was evaluated on 11 representative hardware designs (including AES, MIPS, UART, and SoC subsystems) and compared against a baseline using GPT-5 directly.

Performance Metrics: Assertain outperformed the baseline GPT-5 by:
- 61.22% in the number of correct assertion generations.
- 59.49% in unique CWE coverage.
- 67.92% in architectural flaw detection.
Specific Findings:
- Assertion Quality: Achieved near 100% syntactic correctness in most cases, whereas the baseline struggled with hallucinated signals in complex designs (e.g., SoC_Subsystem).
- Flaw Detection: In the MIPS design, Assertain detected 15 architectural flaws compared to 8 by the baseline. In the Store_Unit, it doubled the detected flaws (15 vs. 9).
- Case Studies: Successfully identified critical issues such as:
  - Replay Attacks: Lack of challenge rotation in password verification.
  - Fault Tolerance: Inability of FSMs to recover from illegal states (SEU).
  - Confused Deputy: Role isolation failures in I2C controllers.
  - Glitch Resistance: Lack of debouncing on control lines.

5. Significance

The Assertain framework represents a paradigm shift in hardware security verification. By automating the translation of high-level threat intents into rigorous, executable formal properties, it:

Reduces Manual Effort: Drastically cuts the time required for security property specification.
Expands Coverage: Uncovers subtle architectural weaknesses and emergent vulnerabilities that manual inspection or standard functional verification misses.
Ensures Executability: The self-reflection mechanism guarantees that generated assertions are syntactically valid and semantically consistent with the design, making them immediately usable in Formal Property Verification (FPV) flows.
Future-Proofing: Provides a scalable solution to keep pace with the increasing complexity of SoCs and the sophistication of modern hardware threats.

The paper concludes that Assertain significantly advances the state-of-the-art by moving beyond simple code generation to automated security architecture definition, effectively acting as an automated security architect that defines the "to-be" state of hardened systems.