The December 2022 issue of IEEE Spectrum is here!

Close bar

DARPA: Hack Our Hardware

DARPA is running a bug bounty aimed at further hardening new malware-proof architectures

5 min read
Illustration of CPU critical exploit vulnerabilities.
Illustration: iStockphoto

This is a guest post. The views expressed here are solely those of the authors and do not represent positions of IEEE Spectrum or the IEEE.

Thanks to Moore’s Law, the number of transistors in our computing devices has doubled every two years, driving continued growth in computer speed and capability. Conversely, Wirth’s Law indicates that software is slowing more rapidly than hardware is advancing. The net result is that both hardware and software are becoming more complex. With this complexity, the number of discovered software vulnerabilities is increasing every year; there were over 17,000 vulnerabilities reported last year alone. We at DARPA’s System Security Integrated Through Hardware and firmware (SSITH) program argue that the solution lies not in software patches but in rethinking hardware architecture.

In March 2020, MITRE released version 4.0 of its Common Weakness Enumerations (CWE) list, which catalogues weaknesses in computer systems. For the first time, it included categories of hardware vulnerabilities. Among them are: RowhammerMeltdown/SpectreCacheOut; and LVI, which are becoming more prevalent. In fact, a reported 70 percent of cyber-attacks are the result of memory safety issues [pdf] such as buffer overflow attacks—a category of software exploit that takes advantage of hardware’s inherent “gullibility.” These software exploitations of hardware vulnerabilities affect not only the computer systems we use at home, work, and in the cloud, but also the embedded computers we are becoming increasingly reliant on within Internet-of-Things (IoT) devices.

As 5G and IoT proliferation sweeps across the planet, businesses and consumers are benefiting greatly from increased connectivity. However, this connectivity is also introducing greater risks and security concerns than ever before. Gartner forecasts that there will be 5.81 billion IoT endpoints this year, and IDC estimates the number of IoT devices will grow to 41.6 billion in 2025. Despite these staggering statistics, IoT is still in its infancy. I liken it to the Wild West, where companies come and go, regulations and standards are undefined, and security is often an afterthought. This lawlessness can have significant consequences, as we saw in 2016 when the Mirai bot-net attacked domain registration service provider, Dyn. The attack exploited IoT devices like home routers, security cameras, and air quality monitors to perform a denial of service attack that prevented users from accessing major internet platforms and services in the United States and Europe.

Today, the security research community is able to identify many of these cyberattacks quickly, and solutions are distributed to patch the exploited software. These solutions are applied the same way a doctor prescribes medicine to treat a disease. As new diseases are discovered, new medicines must be developed and dispensed. Security researchers are similarly developing new software patches to address newly discovered vulnerabilities. We call this the “patch and pray” mentality.

Every time a new software vulnerability that exploits hardware is identified, a new software patch is issued. However, these patches only address the software layer and do not actually “treat” the underlying problem in the hardware, leaving it open to the creation of new exploits. In the medical field, this type of treatment regime is expensive and doesn’t cure the disease. In recent years, physicians have been advocating preventive medicine to treat the root causes of chronic diseases. Similarly, we need to adapt and find a better way to protect our computer systems. 

Nowadays, embedded computers use multiple pieces of free software or open source utilities that are maintained and updated by the open source community. Conversely, many such computers—with applications in sectors such as Industry 4.0, medical, and automotive—are rarely if ever provided with updated software. They just continue to run old versions with known vulnerabilities. Even though they may use open source components, this slow update cycle is due to devices needing to be requalified to make sure that any updates to the kernel or drivers do not break the system.

 Requalifying a device is expensive and even more costly when a new version of an operating system is involved. Often this is not even possible, since many companies outsource part or all of the development of their underlying hardware and software platforms in the form of licensed intellectual property (IP). These third-party components are usually licensed for a prebuilt function or as binary blobs and black boxes. The original equipment manufacturer (OEM) cannot modify these proprietary software components without additional licenses.

The net result is that individual third-party IP components are often not updated and only support certain versions of an operating system and software stack, further preventing the device that uses them from being updated. Additionally, the cost of supporting hardware devices is so large that many companies outsource technical support and device management to third-party companies who were not involved with the original development. This provides another barrier to updates; bugs can go unnoticed or unreported back to the development team. It’s also possible that the original team might no longer exist or might have moved on to its next project.

Because of these issues, protection from malware often requires a hardware upgrade. Take, for example, the cell phone market. Updates are often slow or nonexistent if you are not using one of the major brands. The market leaders are able to provide updates because they have tight control of their supply chains and enjoy sales volume sufficient to recoup their costs. Even then, they keep this up for only for a few years before the consumer is forced to upgrade. In between these hardware updates, software updates are employed in the form of the “patch and pray” approach.

DARPA’s System Security Integrated Through Hardware and firmware (SSITH) program seeks to break this cycle of vulnerability exploitation by developing hardware security architectures to protect systems against entire classes of the hardware vulnerabilities that these software exploits attack. SSITH’s philosophy: By treating the problem at its root—the hardware—it can end the need for continual “patch and pray” cycles.

With the National Institutes of Standards and Technologies, we have grouped the MITRE CWE database of vulnerabilities into seven hardware classes.  Our research teams have been developing novel methods to stop buffer errors, privilege escalations, resource management attacks, information leakage attacks, numeric errors, code injection attacks, and cryptographic attacks. This approach has shown promising results with minimal impact to power, performance, chip area, and software compatibility. These architectural techniques can be incorporated into the entire range of computer hardware and scale from IoT endpoints to mobile phones to advanced servers and, ultimately, to supercomputers. 

One of the challenges when developing secure hardware is quantifying performance. Since there are no agreed upon standards for doing this, SSITH has developed a security evaluation tool to analyze hardware architectures. This tool quantifies the impacts of security on performance, area, and power consumption while using a battery of synthetic software tests to benchmark the hardware designs for security coverage.

To help further mature the SSITH hardware designs and the security benchmark software, DARPA is conducting its first bug bounty program, entitled Finding Exploits to Thwart Tampering (FETT). Run in partnership with the Department of Defense’s Defense Digital Service and trusted crowdsourced security company, Synack, FETT aims to take a crowdsourced red team approach to test and analyze the initial versions of the SSITH technology. From July to September 2020, members of the Synack Red Team will use their best techniques to attack and stress test this technology. By addressing any discovered weaknesses and vulnerabilities, the SSITH research teams will be able to further harden their novel defenses while making computer hardware safer for everyone.

About the Author:

Keith Rebello is program manager at DARPA’s Microsystems Technology Office.

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