What DARPA Taught Me About Building Trust into Silicon

By Sajeed Mohammad

The most memorable slide I ever saw in a chip design review didn’t show a floorplan. It showed a target. The Defense Advanced Research Projects Agency (DARPA) program manager running AISS, Automatic Implementation of Secure Silicon, the program that funded my majority of PhD research, had put a target on the board: shrink the time from architecture to security-hardened RTL from years to weeks. He said it to a virtual room of engineers from Synopsys, Arm, Boeing, half a dozen universities, and a separate team whose entire job was to break everyone else’s work.

I think about that target in my current job as a Lead CAD Engineer at Rambus, working on AI-driven chip design methodologies. The commercial industry still treats hardware security the way chip design treated timing closure in the 1990s: a manual craft, done by hand, late, expensively, only when someone important insists.

What the program was actually trying to do

AISS started from an uncomfortable premise, in DARPA’s own words: most of today’s chips are largely unprotected. Not because designers are careless, but because hardware security has always been a manual craft practiced by a few experts at the largest companies, with no common tools in wide use. Meanwhile threats spent a decade moving down the stack, from software into silicon.

The program organized around four major attack surfaces: side-channel attacks, reverse engineering, supply-chain attacks like overproduction, remarking, and recycled parts, and malicious hardware. Its answer was to automate the craft: security-aware CAD tools, security IP libraries, generators, and a cloud infrastructure for managing chips through their lifecycle. The output would be SoC platforms optimized across four axes instead of three: Power, Area, Speed, and Security. Everyone called it PASS, and the acronym was the point: security, promoted from sign-off checklist to a variable the optimizer trades against like any other.

And DARPA does not grade its own homework. The program funded a dedicated independent verification team, effectively a standing red team, tasked with attacking every mitigation the rest of us built. Every quarter, all performers joined a two-day review to demo progress while the red team demoed what they had broken.

1. Put security in the optimizer, not the checklist

The PASS idea is the one I find myself explaining most often to commercial teams, because it reframes the economics. In most production flows today, security arrives at the end as a gate: a review and a checklist. The architecture is frozen, the tapeout clock is running, and every fix costs an order of magnitude more than it would have six months earlier. AISS asked what happens when security is a constraint the tools satisfy from the start.

The program’s vocabulary shows how concrete this got: odometers, lifecycle counters tracking a chip’s age so a recycled part cannot be sold as new. Watermarks proving a chip’s provenance through a supply chain nobody fully trusts. Power-on authentication as the first handshake between silicon and the world. Identity and lifecycle tracking for chips, the way software takes for granted. None of it works as an afterthought.

2. Hire someone to break it

The red team taught me more than the building did. Designing against a spec asks whether the chip does what you intended. Designing against an adversary asks what someone can make it do that you did not intend. Most commercial teams only staff the first question. My own side-channel research drove this home: on-chip performance monitoring units (PMU), the debug counters every designer trusts and ignores, can be repurposed as oracles that leak secrets through power signatures (SPY-PMU, Cryptology ePrint Archive, 2025). Nothing about the PMU is functionally wrong. The vulnerability exists because nobody asked what an adversary could do with it.

On AISS, the adversary had a budget, a schedule, and a slot on the quarterly agenda. Commercial teams cannot all hire a standing red team, but they can do the cheaper version: put someone in every design review whose job is to break the design, not confirm it. Threat modeling is not a document you write before tapeout. It is a habit.

3. You have to boot trust from nothing

My corner of the program was the least glamorous and the most instructive. I co-authored the functional requirements for how the program’s security engine boots its own firmware securely, on the manufacturing floor and in the field. I had previously published on this topic (“Required Policies and Properties of the Security Engine of an SoC,” IEEE iSES, 2021). It sounds narrow until you see the paradox: the security engine is the component everything else trusts, so it must establish trust in itself first, from a cold start, with no one to vouch for it. My published research has explored secure boot architectures in depth (FortBoot, IFIP/IEEE VLSI-SoC, 2024).

That exercise forces you to write down every assumption the boot chain makes: this stage trusts the next stage’s measurement, this fuse setting is assumed correct, this fallback path is assumed unreachable. Each one is a handshake nobody watched. Commercial firmware teams live with dozens of such assumptions because enumerating them is tedious. Attackers enumerate them for you, for free, after release.

Where the commercial world is behind

The gap is hard to miss. Commercial EDA flows optimize three axes. The checklists were written for human-written RTL. And AI is now generating blocks that inherit the blind spots of their training data and prompts. Nobody wrote a security checklist for autocomplete-generated RTL, because until recently that RTL did not exist.

What to do on Monday morning

Borrowing the playbook does not require a DARPA budget. Four things any team can start this week: first, write down your trust assumptions, every handshake in the boot chain, every debug interface left accessible, every third-party block taken on faith. If you cannot list them, you cannot defend them. Second, threat-model one block per project with an attacker’s mindset. Ask what the block can be made to do, not only what it was designed to do. Third, ask your EDA vendor which security properties their flow constructs automatically and which it merely checks. The difference is the whole game. Fourth, treat AI-generated RTL as untrusted input until it passes the same adversarial review you had given third-party IP.

The government is investing in secure silicon because the alternative is shipping chips we cannot really trust. I spent my PhD watching a program try to make trust constructible and automatic, with a red team grading the homework. Commercial teams should borrow the playbook now, before they learn the lesson the expensive way.

About the author

Sajeed Mohammad, PhD is a Lead CAD Engineer at Rambus in San Jose, working on AI-driven design methodologies, formal verification, and hardware security. An IEEE Senior Member, his research on secure SoCs and firmware protection, including work under DARPA’s AISS program, has been cited in the hardware security literature. He has reviewed 150+ IEEE/ACM journal and conference papers and served on the Technical Program Committee of 10+ conferences.

Also Read:

CTO Interview with Dr. Zakir Syed of ClockEdge

Overcoming the Edge AI Power Wall with Low-Voltage Foundation IP

Keysight Advances its Design Software with Agentic AI

Share this post via: