Hardware Reference
In-Depth Information
B.
Open Source Hardware Security Do's and
Don'ts
Josh Datko
So you are building open source hardware that will change the world? Ideally, it will be used
by thousands—if not millions—of users, and everyone will have one—if not two—of your
devices! You might not think that your device needs to be secure, but if people depend on
it and make decisions based on the data the device presents, then it needs to be secure and
reliable. Adding security to your OSHW project after it's deployed is too late; you need to
think about this issue before your hardware ships.
The following tips are geared toward embedded OSHW devices that run firmware,
whether in a FPGA, a microcontroller, or a CPU. More complete resources are listed in this
appendix. Here are some basic do's and don'ts that can help make your device more secure
and reliable:
Don't
store a hard-coded password or key in your firmware. First of all, your firm-
ware is open source, right? Even if it's not, this step provides almost no extra secur-
ity because your firmware can be disassembled and it's trivial to find fixed strings.
Don't
roll your own crypto algorithm. It easy to convince yourself that your crypto
is unbreakable. The thinking goes like this: “I'm the smartest person I know and I
can't break this, so nobody can.” This kind of assumption almost never turns out
well. Instead, you should use an academically reviewed algorithm from a well-
maintained crypto library. There are also dedicated hardware integrated circuits
(ICs) that will implement these algorithms and provide a random number generator
for you.
Don't
hide the plaintext key on your system. This is slightly better than a hard-
coded password, but not by much. If the first step is to load a key from an EEPROM
over I2C, then all it takes is a logic analyzer to watch that traffic and discover the
key. Read
Hacking the Xbox
(listed in the Resources section) to see why this ap-
proach doesn't work.
Do
consider denial of service attacks. Reliability and security engineering share
similar features. Consider cases like what happens when your device receives too
many messages. Does it need redundant power supplies? If it's part of a distributed
