Darpa Hacks Its Secure Hardware, Fends Off Most Attacks

Darpa’s SSITH program aims for hardware architecture for IoT that’s immune to the seven major types of hardware hacks

2 min read
Darpa Hacks Its Secure Hardware, Fends Off Most Attacks.
Illustration: iStockphoto

Last summer, Darpa asked hackers to take their best shots at a set of newly designed hardware architectures. After 13,000 hours of hacking by 580 cybersecurity researchers, the results are finally in: just 10 vulnerabilities. Darpa is calling it a win, not because the new hardware fought off every attack, but because it “proved the value of the secure hardware architectures developed under its System Security Integration Through Hardware and Firmware (SSITH) program while pinpointing critical areas to further harden defenses,” says the agency.

Researchers in SSITH, which is part of Darpa’s multibillion dollar Electronics Resurgence Initiative, are now in the third and final phase of developing security architectures and tools that guard systems against common classes of hardware vulnerabilities that can be exploited by malware. [See “How the Spectre and Meltdown Hacks Really Worked.”] The idea is to find a way past the long-standing security model of “patch and pray”, where vulnerabilities are found and software is updated.

In an essay introducing the bug bounty, Keith Rebello, the project’s leader, wrote that patching and praying is a particularly ineffective strategy for IoT hardware, because of the cost and inconsistency of updating and qualifying a hugely diverse set of systems. [See “DARPA: Hack Our Hardware”]

Rebello described the common classes of vulnerabilities as buffer errorsprivilege escalationsresource management attacksinformation leakage attacksnumeric errorscode injection attacks, and cryptographic attacks. SSITH teams came up with RISC-V-based architectures meant to render them impossible. These were then emulated using FPGAs. A full stack of software including a bunch of apps known to be vulnerable ran on the FPGA. They also allowed outsiders to add their own vulnerable applications. The Defense Department then loosed hackers upon the emulated systems using a crowdsourced security platform provided by Synack in a bug bounty effort called Finding Exploits to Thwart Tampering (FETT).

“Knowing that virtually no system is unhackable, we expected to discover bugs within the processors. But FETT really showed us that the SSITH technologies are quite effective at protecting against classes of common software-based hardware exploits,” said Rebello, in a press release. “The majority of the bug reports did not come from exploitation of the vulnerable software applications that we provided to the researchers, but rather from our challenge to the researchers to develop any application with a vulnerability that could be exploited in contradiction with the SSITH processors’ security claims. We’re clearly developing hardware defenses that are raising the bar for attackers.”

Of the 10 vulnerabilities discovered, four were fixed during the bug bounty, which ran from July to October 2020. Seven of those 10 were deemed critical, according to the Common Vulnerability Scoring System 3.0 standards. Most of those resulted from weaknesses introduced by interactions between the hardware, firmware, and the operating system software. For example, one hacker managed to steal the Linux password authentication manager from a protected enclave by hacking the firmware that monitors security, Rebello explains.

In the program’s third and final phase, research teams will work on boosting the performance of their technologies and then fabricating a silicon system-on-chip that implements the security enhancements. They will also take the security tech, which was developed for the open-source RISC-V instruction set architecture, and adapt it to processors with the much more common Arm and x86 instruction set architectures. How long that last part will take depends on the approach the research team took, says Rebelllo. However, he notes that three teams have already ported their architectures to Arm processors in a fraction of the time it took to develop the initial RISC-V version.

The Conversation (0)

Why Functional Programming Should Be the Future of Software Development

It’s hard to learn, but your code will produce fewer nasty surprises

11 min read
A plate of spaghetti made from code
Shira Inbar

You’d expectthe longest and most costly phase in the lifecycle of a software product to be the initial development of the system, when all those great features are first imagined and then created. In fact, the hardest part comes later, during the maintenance phase. That’s when programmers pay the price for the shortcuts they took during development.

So why did they take shortcuts? Maybe they didn’t realize that they were cutting any corners. Only when their code was deployed and exercised by a lot of users did its hidden flaws come to light. And maybe the developers were rushed. Time-to-market pressures would almost guarantee that their software will contain more bugs than it would otherwise.

Keep Reading ↓Show less