What DARPA Taught Me About Building Trust into Silicon
Source: https://semiwiki.com/eda/374529-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.
내가 칩 설계 검토 회의에서 본 가장 인상적인 슬라이드는 플로어플랜(floorplan)을 보여주지 않고 '과녁'을 보여주었다. 내 박사 학위 연구의 대부분을 지원한 DARPA(미국 국방고등연구계획국)의 AISS(Automatic Implementation of Secure Silicon, 안전한 실리콘 자동 구현) 프로그램 매니저는 칠판에 과녁을 그려놓았다. 그 목표는 아키텍처에서 보안이 강화된 RTL(Register Transfer Level)까지 걸리는 시간을 '몇 년'에서 '몇 주'로 단축하는 것이었다. 그는 시놉시스, 암(Arm), 보잉, 반두 개의 대학, 그리고 다른 모든 팀의 작업물을 해킹하는 것이 임무인 별도의 레드팀(red team) 소속 엔지니어들이 가득 찬 가상 회의실에 대고 그렇게 말했다.
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.
현재 램버스(Rambus)에서 AI 기반 칩 설계 방법을 연구하는 수석 CAD 엔지니어인 나는 지금도 그 과녁을 종종 떠올린다. 상용 업계는 여전히 1990년대의 타이밍 클로저(timing closure)를 다루던 방식으로 하드웨어 보안을 대하고 있다. 즉, 수작업으로, 늦게, 큰 비용을 들여, 누군가 높은 사람이 강력하게 요구할 때에야 마지못해 처리하는 식이다.
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.
AISS는 DARPA의 표현을 빌리자면 불편한 전제에서 출발했다. 오늘날의 칩 대부분은 사실상 무방비 상태라는 것이다. 설계자들이 부주의해서가 아니라, 하드웨어 보안은 항상 대기업 소수의 전문가들이 수작업으로 수행하는 영역이었고 널리 쓰이는 공통 도구가 없었기 때문이다. 그 사이 위협은 소프트웨어에서 실리콘으로, 스택의 더 깊은 곳으로 내려오는 데 10년이라는 시간을 보냈다.
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.
이 프로그램은 사이드 채널 공격(side-channel attacks), 리버스 엔지니어링, 과생산·리마킹·재활용 부품 등의 공급망 공격, 그리고 악성 하드웨어라는 4가지 주요 공격 표면을 중심으로 조직되었다. 그에 대한 해답은 바로 수작업의 자동화였다. 즉, 보안 인식이 탑재된 CAD 도구, 보안 IP 라이브러리, 제너레이터, 그리고 칩의 수명주기를 관리하기 위한 클라우드 인프라였다. 그 결과물은 기존의 3대 축(P·A·S, 전력·면적·속도)이 아닌 4가지 축(P·A·S·S, 전력·면적·속도·보안)을 모두 최적화한 SoC 플랫폼이 될 터였다. 모두가 이를 PASS라고 불렀고, 이 약어 자체가 핵심이었다. 보안이 최종 승인(sign-off) 체크리스트에서 벗어나 최적화 도구가 다른 변수들과 마찬가지로 트레이드오프를 거치는 하나의 변수로 격상된 것이다.
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.
또한 DARPA는 자기가 낸 숙제를 자기가 채점하지 않았다. 프로그램은 전담 독립 검증 팀, 즉 상설 레드팀을 지원하여 우리가 만든 모든 방어벽을 공격하는 임무를 맡겼다. 매 분기마다 모든 참가 팀들은 2일간의 리뷰에 참석해 진척 상황을 시연했고, 레드팀은 자신들이 무엇을 뚫었는지 시연했다.
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.
PASS 아이디어는 내가 상용 팀들에게 가장 자주 설명하게 되는 개념이다. 경제학적 구조를 완전히 재정의하기 때문이다. 오늘날의 대부분의 양산 플로우에서 보안은 마지막 단계의 관문, 즉 검토와 체크리스트로 다가온다. 아키텍처는 이미 동결되었고 테이프아웃 시계는 돌아가고 있으며, 이 시점의 수정 비용은 6개월 전에 비해 자릿수가 달라질 정도로 비싸진다. AISS는 도구들이 처음부터 끝까지 충족해야 하는 제약 조건으로 보안이 자리 잡는다면 어떤 일이 벌어질지 질문을 던졌다.
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.
이 프로그램의 용어들은 이것이 얼마나 구체적이었는지를 보여준다. 오도미터(odometers, 주행거리계), 즉 재생 부품이 신제품으로 둔갑해 팔리지 않도록 칩의 나이를 추적하는 수명주기 카운터. 아무도 완전히 신뢰할 수 없는 공급망 전반에 걸쳐 칩의 출처를 증명하는 워터마크. 실리콘과 세상 사이의 첫 번째 악수 역할을 하는 전원 투입 인증. 소프트웨어가 당연하게 여기는 칩의 신원 및 수명주기 추적 기능들. 이 중 어느 것도 사후약방문식으로는 작동하지 않는다.
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.
레드팀은 설계하는 법보다 더 많은 것을 가르쳐주었다. 사양서에 맞춰 설계하는 것은 칩이 의도한 대로 작동하는지 묻는 것이다. 반면 공격자의 관점에서 설계하는 것은 누군가 그것을 의도하지 않은 방식으로 어떻게 오동작하게 만들 수 있는지 묻는 것이다. 대부분의 상용 팀들은 첫 번째 질문에만 인력을 배치한다. 나의 사이드 채널 연구는 이를 여실히 보여주었다. 모든 설계자가 신뢰하고 또 무시하는 온칩 성능 모니터링 유닛(PMU, 디버그 카운터)이 전력 시그니처를 통해 비밀을 유출하는 오라클(oracle)로 악용될 수 있다는 것이다(SPY-PMU, Cryptology ePrint Archive, 2025). PMU 자체에는 기능상의 결함이 전혀 없다. 이 취약점은 아무도 "공격자가 이걸로 무엇을 할 수 있을까?"라고 묻지 않았기 때문에 존재한다.
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.
AISS에서 공격자에게는 예산과 일정, 그리고 분기별 의제 속 한 자리가 주어져 있었다. 상용 팀들이 모두 상설 레드팀을 고용할 수는 없지만, 더 저렴한 버전은 실행할 수 있다. 모든 설계 검토 회의에 디자인을 '확인'하는 사람이 아니라 '부수'는 것을 임무로 하는 사람을 한 명씩 배치하는 것이다. 위협 모델링은 테이프아웃 전에 작성하고 끝내는 문서가 아니라 하나의 습관이다.
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).
프로그램에서 내가 담당했던 영역은 가장 화려하지 않으면서도 가장 교훈적인 곳이었다. 나는 프로그램의 보안 엔진이 제조 공장과 필드에서 자체 펌웨어를 안전하게 부팅하는 방법에 대한 기능 요구사항을 공동 집필했다. 나는 이전에 이 주제에 대해 논문으로 발표한 적이 있다("Required Policies and Properties of the Security Engine of an SoC," IEEE iSES, 2021). 이 역설을 마주하기 전까지는 사소해 보일 수 있다. 보안 엔진은 다른 모든 것들이 신뢰하는 핵심 구성 요소이므로, 아무도 보증해 주는 이가 없는 상태에서 냉랭한 콜드 스타트(cold start) 속에서 먼저 자기 자신에 대한 신뢰를 확립해야 한다. 내 발표 연구는 보안 부트 아키텍처를 깊이 있게 탐구한 바 있다(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.
이 실습은 부트 체인이 만드는 모든 가정들을 강제로 적어 내려가게 만든다. 이 단계는 다음 단계의 측정을 신뢰하고, 이 퓨즈 설정은 올바르다고 가정하며, 이 예비 경로는 도달 불가능하다고 가정하는 식이다. 이 중 대다수는 아무도 감시하지 않은 채 이루어지는 악수(handshake)들이다. 상용 펌웨어 팀들은 그것들을 나열하는 작업이 지루하기 때문에 수십 가지의 이러한 가정들을 안고 살아간다. 공격자들은 출시 이후 여러분을 대신하여 그것들을 아주 무료로 낱낱이 나열해 준다.
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.
격차는 쉽게 눈에 띈다. 상용 EDA 플로우들은 여전히 3개의 축만 최적화한다. 체크리스트들은 인간이 작성한 RTL을 위해 만들어졌다. 그리고 이제 AI가 학습 데이터와 프롬프트의 맹점을 고스란히 물려받은 블록들을 생성해 내고 있다. 자동 완성으로 생성된 RTL에 대해서는 보안 체크리스트를 작성한 사람이 아무도 없다. 최근까지 그런 RTL이 존재하지 않았기 때문이다.
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.
이 플레이북을 빌려오는 데 DARPA의 거대한 예산이 필요한 것은 아니다. 어떤 팀이든 이번 주부터 당장 시작할 수 있는 네 가지가 있다.
- 신뢰 가정들을 적어라: 부트 체인의 모든 악수 과정, 접근 가능한 상태로 방치된 모든 디버그 인터페이스, 맹목적으로 가져다 쓴 모든 제3자 블록을 기록하라. 나열할 수 없다면 방어할 수도 없다.
- 공격자의 시각으로 블록을 위협 모델링하라: 프로젝트당 하나의 블록을 골라 그것이 원래 설계된 용도가 아니라 '어떤 짓을 하도록 만들 수 있는지' 자문해 보라.
- EDA 벤더에 물어라: EDA 벤더에게 그들의 플로우가 어떤 보안 속성을 자동으로 구축해 주는지, 그리고 어떤 것을 단순 '검사'만 해주는지 질문하라. 그 차이가 판을 가른다.
- AI 생성 RTL을 신뢰하지 마라: 제3자 IP에 적용했던 것과 동일한 적대적 검토 과정을 통과할 때까지, AI가 생성한 RTL은 신뢰할 수 없는 입력으로 취급하라.
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.
사지드 모하마드(Sajeed Mohammad, 박사)는 산호세에 위치한 램버스(Rambus)의 수석 CAD 엔지니어로서 AI 기반 설계 방법론, 형식 검증(formal verification), 하드웨어 보안을 연구하고 있습니다. IEEE 시니어 회원인 그의 안전한 SoC 및 펌웨어 보호 관련 연구(DARPA의 AISS 프로그램 산하 연구 포함)는 하드웨어 보안 문헌에 자주 인용되고 있습니다. 그는 150편 이상의 IEEE/ACM 저널 및 컨퍼런스 논문을 심사했으며, 10개 이상의 컨퍼런스에서 기술 프로그램 위원(TPC)으로 활동했습니다.
