Protecting your firmware is a very important topic, especially when you take into account the massive amount of time, energy, and cost that goes into developing it. The best way to protect your firmware is to follow good design practices throughout your development process.

You may know what to do, but are you familiar with what not to do in protecting your firmware?

Take a look at our “5 Don’ts When Protecting Your Firmware”:

  1. Don’t leave debug ports enabled for release buildsDebug ports can be very helpful when developing firmware, but when it comes time to release firmware debug ports should be disabled. This is especially true if you have a built-in command-line interface (CLI) that allows for interaction with your system. There is no reason to offer up free information to the attackers.
  2. Don’t execute an application without validating it firstThe use of a bootloader that validates the application in read-only memory (ROM) before allowing execution to jump to the application will ensure that only the intended application is executed. This will prevent attackers from trying to spoof your application with their own malicious version. Even a simple cyclic redundancy check (CRC) is better than nothing.
  3. Don’t use unsigned and unencrypted firmware updatesSigning your firmware updates allows the device to verify the update is from a trusted source. The device should only have access to the public key and protect it from modification. Be sure to check if your processor has a secure key storage module.

    Encrypting your firmware updates will protect your firmware from being reverse engineered/analyzed. This includes any keys or secrets that it contains. Check to see if the processor has hardware-accelerated encryption which can save both time and power. The only place that your firmware should be unencrypted on is your processor’s memory while it’s running.

  4. Don’t send sensitive data between ICs unencryptedAttackers will be able to probe on the communication lines between ICs on your printed circuit board (PCB) and sniff all traffic. So before sending sensitive data across communication lines it should be encrypted.
  5. Don’t leave flash unlockedMost processors allow for some sort of mechanism to disable the ability for debuggers to read the contents of flash. This will prevent the attacker from simply attaching a debugger and reading out your firmware from flash. This protection is not ironclad and with enough time and energy, an attacker could circumvent this safety precaution. Think of it as locking your car door, it will not keep out a master lockpicker with unlimited time and resources but it will keep out the large majority of people who you don’t want in your car.

    If you’d like to make sure your firmware is secure, reach out! At DojoFive, we have talented engineers on hand ready to help you with all aspects of your EmbedOps journey. We are always happy to help with interesting problems that need solving, from security audits to firmware development. You can reach out at any time on LinkedIn or through email!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.