Hardware Reference
In-Depth Information
system, how many inputs (or votes) should be needed before your device makes a
decision? (Hint: One is usually not enough.)
Don't
ship a binary blob! You are already shipping open source hardware, so why
restrict the software? A binary blob doesn't make your product any more secure.
This fallacy essentially relies on “security through obscurity.” If your device is
popular, it will be reverse engineered.
Do
have a secure and reliable firmware updating mechanism. You might hope that
your device will be used in 5 years, but how will users update the firmware?
Inevitably, a vulnerability will be found, and users will need to update the device.
Also, can your device be updated without using the Internet? Can users update it
even if your company no longer exists? (Hint: The answer should be yes.) Con-
sider generating an asymmetric key pair and signing your firmware updates so that
users and devices can trust the updates.
Do
let users have control of the device. The users bought your product; they should
be able to run their own software on this device. Plus, the users want to be able to
perform any maintenance themselves if there is a problem or a critical vulnerabil-
ity they want to fix. Even if you are signing your firmware, provide an option for
the users to upload their own. As Jim Gettys says, “Friends don't let friends run
factory firmware.”
Do
add integrity checking mechanisms to your communication protocols, even
between ICs. A glitch on one wire can make a difference between a high and a
low. What happens if the data is used with the one wrong bit? At a minimum, con-
sider adding a cyclic redundancy check (CRC) to each message, to ensure that the
intended message is the delivered message. Consider what happens when a fault is
detected.
Do
consider who else can access the data on the device. Adding a logger to your
device is great, but don't make it easy for other parties to access the data if the user
wants to keep it private. You have a responsibility to protect users' data.
Do
use a static code analysis tool on your firmware. C is a popular language for
embedded development, but it's very easy to make a programming mistake that
results in an exploitable loophole. There are free (for open source projects) static
analysis tools, such as Coverity Scan, that will scan your code and catch your mis-
takes.
Happy hacking!
