Rtl Security Review

RTL Security Review

Purpose

Review RTL designs for security vulnerabilities including access control gate bypasses, insecure FSM transitions, timing-dependent information leakage, and unintended data paths.

Scope Constraints

Reads RTL source files (Verilog/SystemVerilog/VHDL), testbenches, and security policy documents. Does not modify RTL files or execute simulation. Does not access proprietary IP blocks outside the review scope.

Inputs

• RTL module(s) under review (Verilog/SystemVerilog/VHDL)
• Security policy specification (what access controls should be enforced)
• Trust boundary definitions (which interfaces are exposed to untrusted agents)
• Intended FSM behavior and state transition rules

Input Sanitization

No user-provided values are used in commands or file paths. All inputs are treated as read-only analysis targets.

Procedure

Step 1: Identify Security-Critical RTL Modules

Enumerate all modules that enforce security policies: access control checkers, permission registers, firewall/filter logic, key storage, crypto engines, interrupt controllers, debug interfaces. Classify each by the trust boundary it enforces.

Step 2: Check Access Control Gates

For each access control module, verify:

• All paths through the logic respect the access policy (no bypass paths)
• Default-deny: unrecognized requests are blocked, not passed through
• Access checks happen before data is forwarded (no time-of-check/time-of-use gaps)
• Reset state is secure (permissions are restrictive, not permissive)
• Lock bits cannot be cleared once set

Step 3: Verify FSM Transition Security

For each security-relevant FSM, verify:

• All state transitions are explicitly defined (no implicit transitions via default cases)
• Invalid input in any state leads to a safe/error state, not an exploitable state
• State encoding resists fault injection (Hamming distance, one-hot vs binary)
• Reset enters the most restrictive state
• Glitch-sensitive transitions have synchronization or filtering

Step 4: Review Timing Paths

For each security-critical path, verify:

• Security checks are on the critical path (cannot be bypassed by timing)
• No combinational paths that could glitch during clock transitions
• Multi-cycle paths have proper handshaking (no window where unchecked data is visible)
• Clock domain crossings near security logic have proper synchronization

Step 5: Check for Information Leakage

Review the design for unintended information paths:

• Shared buses or interconnects that expose data across trust boundaries
• Debug/test interfaces that bypass access controls
• Error responses that leak internal state
• Power/timing side-channels in security-critical operations
• Scan chains that expose key material or security state

Compaction resilience: If context was lost during a long session, re-read the Inputs section to reconstruct what system is being analyzed, then resume from the earliest incomplete step.

Output Format

Module Security Classification

Finding Table

FSM Security Summary

• [FSM name]: [State count] states, [Transition count] transitions — [Issues found]

Handoff

• Hand off to microarch-analysis if microarchitectural side-effects are discovered during RTL review.
• Hand off to physical-design-security if physical implementation changes are needed for security.

Quality Checks

• All security-critical modules are identified and reviewed
• Access control gates are verified for bypass paths
• FSMs have no implicit transitions through default/wildcard cases
• Reset state is verified as secure for all security-relevant registers
• Debug interfaces are checked for access control bypass
• Timing paths through security logic are verified
• Information leakage paths are enumerated and assessed

Evolution Notes