Attacks against hardware are becoming much more commonplace. Tools aren't just limited to folks with fat wallets. Starving students and low-budget attackers can now obtain discarded or surplus equipment from universities or swap meets. There are loose-knit communities of enthusiasts looking to hack or modify anything with electrons running through it. The basic hardware hacking skills are easy to learn and people are more than willing to share their techniques. You're just not safe if you're relying solely on hardware products for your security.

What I've learned in my years as an electrical engineer is that designers just don't think about security. Luckily, after years of poking, prodding, and begging, it seems to be getting a little bit better. Vendors are listening to security concerns. Products are beginning to implement security features to prevent against IP theft or compromise. However, it costs time and/or money to research and manufacture security mechanisms into a product and most companies would rather just bear the risk of a potential attack.

My research deals with hardware attacks and common classes of problems. Sure, we could pick any current, state-of-the-art product, be it hardware or software, and likely find a security problem with it. But, learning from history is arguably more important, no matter what field or industry you're in. The problem is, it hardly ever happens. People just don't seem to care about the past. I'll try to do my part to ensure that no lessons of poor hardware design and embedded security are lost to the computer security community.

The beauty of this is discussing the various approaches that made these attacks successful. You can then take these approaches and apply a similar process to newer devices of your particular interest. Of course, I will only touch the tip of the iceberg at Black Hat, but it will sufficiently enlighten you to the ways of a hardware hacker.

The ubiquitous USB socket may hold the key to unlocking all sorts of digital disorder.

At the lowest level, the USB protocol, can be attacked just like current and past TCP stack attacks. Take a look at the USB 1.1 specs. If you find that document painful, try this.

Above the protocol level is the driver level, where there is, I believe, a tremendous probability to find buffer overflows. Consider the design process for a new USB widget. First, the hardware developer selects a few chips to build the device. Next a software developer creates the firmware to run the device. Finally, another developer creates a driver, if needed for the target platform.

How many times has this happened? The hardware guy tells the firmware guy that the device has a 64 byte buffer to transmit data up to the PC. The firmware guy then creates the device's API around that buffer size. Finally, the widget's API is handed to the driver developer who sees that only a 64 byte buffer is needed for incoming data.

int widget_RX_Data(void)
{
char RecvBuf[0x40]; //Smith in HW says this is the limit for the XXXyyy123 chip.
...
}

Can you say BOOM? Somebody is just asking for a stack overflow with that code.

If you think that it is not a problem, because that faulty code is only ever accessed by the device that identifies itself as the widget that the driver was explicitly designed for. You are very wrong, my device can select that same ID, but it won't play nicely with the driver.