How To Protect Your Firmware: 5 Mistakes To Avoid

Lock with digital icons projected on top

You put a massive amount of time, energy, and cost into developing your firmware. As such, protecting your firmware should be a top priority. The best way to protect your firmware is to follow good design practices throughout your development process. You might already have a set of practices in place, but there are a few key things you should avoid to ensure your firmware stays secure.

Want to protect your firmware? We’re sharing key mistakes that could expose your firmware to security risks. Not sure if your firmware is protected? Request a Professional Health Check

5 Mistakes That Can Jeopardize Your Firmware Protection

1. Don’t leave debug ports enabled for release builds

Debug ports can be very helpful when developing firmware, but when it comes time to release firmware, they 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. Validate applications before executing

Using a bootloader that validates the application in read-only memory (ROM) before allowing execution to jump to the application ensures that only the intended application is executed. This will prevent attackers from trying to spoof your application with their own malicious version. Using a cyclic redundancy check (CRC) is better than nothing.

    3. Don’t use unsigned and unencrypted firmware updates

    Always sign your firmware updates. This 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 your firmware should be unencrypted is your processor’s memory while it’s running.

    4. Don’t send sensitive data between ICs unencrypted

    Attackers can probe the communication lines between integrated circuits (ICs) on your printed circuit board (PCB) and sniff all traffic. To prevent attacks, encrypt all sensitive data before sending it across communication lines.

    Related: Keep Hackers Out With Proper Connected Device Security

    5. Don’t leave flash unlocked

    Most processors have a mechanism that disables debuggers from reading the contents of flash. This prevents the attacker from simply attaching a debugger and reading out your firmware from flash. This protection is not ironclad, and attackers could circumvent this precaution with enough time and energy. Think of it as locking your door; it’s not enough to keep out a master lockpick with unlimited time and resources, but it will keep out most people.

    Next Steps

    Don’t leave your firmware’s security to chance! Our talented Dojo Five engineers can help you with all aspects of your Embedded firmware journey. We are always happy to help with interesting problems that need solving, from security audits to firmware development. 

    If you are interested in bringing your project to the next level, let’s schedule a call with our team. Or, you can check out EmbedOps, our CI build platform.

    We look forward to hearing from you! -D5

    Discover why Dojo Five EmbedOps is the embedded enterprise choice for build tool and test management.

    Sign up to receive a free account to the EmbedOps platform and start building with confidence..

    • Connect a repo
    • Use Dev Containers with your Continuous Integration (CI) provider
    • Analyze memory usage
    • Integrate and visualize static analysis results
    • Perform Hardware-in-the-Loop (HIL) tests
    • Install the Command Line Interface for a developer-friendly experience

    Subscribe to our Monthly Newsletter

    Subscribe to our monthly newsletter for development insights delivered straight to your inbox.

    Interested in learning more?

    Best-in-class embedded firmware content, resources and best practices

    Operating room filled with medical devices

    IEC-62304 Medical Device Software – Software Life Cycle Processes Primer – Part II

    Part I provides some background to IEC-62304. Part II provides a slightly more in-depth look at some of the specifics. The IEC 62304 Medical Device Software – Software Lifecycle Processes looks into your development processes for creating and maintaining your software. The standard is available for purchase here. So what activities does the standard look at? Here are some of the major topics. For any given topic, there will be a lot more specifics. This will look at a few

    Read More »

    How to Port Your Software from Raspberry Pi to Arduino Pro

    This article is for technical leaders or managers with an existing prototype based on the Raspberry Pi who need to migrate to a more production-ready platform like Arduino Pro. Individuals about to build their first prototype with Raspberry Pi who would like to craft their firmware to more easily port to an Arduino Pro as their product scales will also find this helpful. After reading this article, you should feel confident identifying which tier of product growth you are in,

    Read More »
    The homebrew homepage

    Make Homebrew Do Your Dirty Work (MacOS/Linux)

    Just recently, I have been moved over to MacOS (not a personal choice, mind you), and I’ve been learning about some of the really cool features and programs it has to offer. The one I want to share today is Homebrew, as I’ve used it time and again, and it has just made my life so much easier while grabbing new programs and setups. Some of the reasons it’s great: The Proof For example, I have an svg file that

    Read More »