Design for Security

Any product is a potential target. The DEF CON security conference showcases potential errors in your hardware designs.

I attended DEF CON 25 last weekend. Though the nature of the conference has been changing over the years, the conference is about network security at its core; it also is referred to as “the world’s largest hacking convention”. This results in talks and demonstrations discussing the role of preparing for and preventing intrusions into computer systems. Sometimes this involves penetration testing to test for all manner of vulnerabilities. So why was I there as a hardware engineer?

Hardware Prevalence

Over the past few years, there has been an increasing focus on security for non-server-based hardware devices; both at DEF CON and in the larger security industry. This has happened for a few reasons:

  • As network security improved at a high level, attacking the hardware itself has provided another vector for attack.
  • The prevalence of low level hardware devices including the forthcoming “internet of things”
  • The prevalence of wireless in many of these devices, providing even more ways to capture information that could create new ways into systems.

Off the shelf

Most of the talks at DEF CON focus on attacking hardware that’s already in the market. This makes sense. It’s the devices on the market that pose the most immediate threat, because they are sitting on networks as potentially bad actors. The security consultants will seek to first test these devices to make sure they aren’t spewing malicious instructions to other devices on the networks. This already happened on a large scale last October, when IP security cameras were found to have been infected; the cameras carried out a coordinated attack on specific IP addresses, creating an overload known as a DDOS attack.

Levels of Abstractions

So what’s really going on with this hardware? The list of devices that were vulnerable was considerable. But they also had something in common: they were all relatively high powered devices. The devices under attack were often running a flavor of linux and were then attacked via their web interface.

It’s the interface

Most of these devices also had a webserver on board for running an administrative interface. Users could log in to an IP camera or a router and configure the interface. This also means that researchers looking to gain access to these devices could also use these interfaces for traditional web attacks. Using unpatched vulnerabilities in PHP and Apache provided very easy interfaces.

If at first you don’t succeed…open the case

Of course, not every device had a web server, nor was it improperly secured from a web perspective. But that doesn’t mean it’s a truly secure device. Researchers often move to physical attacks, looking to gain access to devices via programming methods and/or programmatic interfaces such as the JTAG chain or an available serial interface. With techniques like bit fuzzing and side channel attacks, it’s possible to pull out potential issues. If you can convince a device to dump its firmware, that is a prime target to analyze for vulnerabilities. Hard coded private keys are something that allow the researcher to later authenticate, either posing as the device in question or talking back to the device in question.

Secure your hardware

The above summary of how I see the security world demonstrates that I am a device security beginner. Most of the time at the conference, I was confused about why changing a power rail of a device might end up in some kind of vulnerability (the side channel attack). But the point is, it doesn’t matter if you don’t understand how someone might attack your device. If you have a commercially successful product, it could potentially be used to interrupt network service, give up personal information of your users or result in down time of the thing you’re trying to do. For engineers designing industrial equipment (my past work), this can have large implications. Factory shutdowns or even catastrophic failures of infrastructure (think power plants) were a topic of the Industrial Control System (ICS) Village, one of the subsections of the conference.

Hire it out

The first time I encountered the security world, I didn’t quite understand how the participants got paid. That sounds glib, but it seemed like people prodding devices and networks with no real end goal, often with no one telling them to do it. I later learned that discovering network vulnerabilities and ethically reporting them back to companies can result in future contracts to help secure those devices. Whether or not you agree with the method, they are well versed in understanding the problems your device or network has.

Hiring a security consultant should be on your design checklist. It might seem obvious for a network connected device, such as a box with an ESP8266 or other connectivity on board. But this is especially true if you have a device running an OS and operating on a network and interacting as though it’s a computer (again, think of an IP camera with an onboard OS)

Make it simpler

The prevalence of development boards and platforms means design engineers will have “ready to go” resources for their project. If you want a project that has a touch interface screen, it’s tempting to user a higher powered processor that is capable of not just sending back data to the cloud, but also interacting with the user on a TFT screen. However, one presentation was talking about the GGMM E3 Smart Speaker (a Kickstarter campaign) that utilized a development kit as the base design. Once they discovered the vulnerability in this design, the research team found that 75+ other products had the same vulnerability, having used the same kit.

Simplify, simplify, simplify

In a feature driven world, it’s hard to say that a device should forego a feature that’s “already included”. But there are real consequences with including features and connectivity that is not properly understood or audited, as shown above. Hardware designers (and their firmware and software teams) should selectively allow access to features, both in custom builds of Android, linux or any other OS.

Many people reading here are working on smaller, embedded applications. This does not absolve you from thinking about how to secure your device. In reality, reprogramming and redeploying your device may be simpler than a larger device. You might think you are free to mark your JTAG pins without consequence, but this creates even less friction between opening your design and allowing it to be reprogrammed.

Next year

I recommend DEF CON for hardware creators, simply to broaden your worldview about what is possible and why you should consider security when designing your product. As a hardware designer among the regular crowd of security researchers and hackers, I found myself marveling at their ingenuity and tenaciousness when deconstructing problems and trying to gain access to systems. This not only encouraged me to do better work, but also to try to ensure future product designs are immune to some of the most common methods of intrusion.

If you decide to go to future DEF CON, I think you’ll find similar tools and methods that changes how you think about security. The mindset around creating secure hardware will force you to more creatively view potential hardware pitfalls and take steps to secure your product.

Leave a Reply

Your email address will not be published. Required fields are marked *