Secure Electronics Design — Hardware and Firmware Security
Before we begin
No part of this story is sponsored. All opinions expressed are of my own.
Designing a secure electronic product is an involved process right from the drawing board. The biggest challenge in electronics security is that: Hardware and Firmware engineers don’t have insight into security challenges. Very few security engineers have intimate knowledge about hardware and firmware.
This story is a compilation of hardware and firmware design choices that builds a solid security foundation in your product. It is to be noted that I am not a security engineer by profession. This story is not to be considered as security advice. If you’re looking for professional and holistic security advise your here are some of your options:
Use a security chip
If the keys are stored in the non-secure flash(Either external or on the MCU), it’s relatively easier to extract them using Side-Channel Attacks and Power analysis. There are dedicated hardware tools like ChipWhisperer built specifically to retrieve secrets from the IC. A determined attacker can also decap the MCU where keys are stored. If the same key is shared across all devices, one exposed device makes the complete product line vulnerable.
Thus, if your product is required to do any crypto operations, a security solution similar to Infineon or Microchip offers a lot of value for about 50 cents(US). Some solutions like Optiga Trust M provides EAL6+ Certified hardware and are designed to be resistant against most common attacks. For Trust M, if you can place an order for more than 20k units, Infineon also provisions keys in their secure facility for little/no price. Trust M also supports shielded I2C connection between the host(MCU) and Trust M, making the scalable attacks impractical.
If your MCU(s) pins can be probed or soldered onto, they can be exploited to know more about your system. If the pins are below the chip, it’ll make probing difficult. So, it’s worth the additional price we’d have to pay for BGA Assembly.
Use Blind and buried vias for routing
While you’re fanning out, try using blind and buried vias, combined with Via in Pad(ViP). This makes the probing even more difficult. Note that ViP and Blind/buried vias increases your PCB/PCBA cost.
If the vias are under the IC and on the ground plane, it’s recommended that you fill them with Epoxy/Copper. Else, solder paste may get sucked into them, resulting in the poor solder joint. More info on how to approach ViA can be found here.
Of all the PCB Fab houses that can do via filling and ViP, PCBWay and Eurocircuits have online calculators that you can use to understand the price difference with ViP, blind, buried vias and without them.
Remove debug interface
Warning: Proceed with this step only if you’re sure that you can retrieve the device, should the application is corrupted. The boot-loader should be intact even if the application is corrupted. In the code, you should lock the boot-loader from write access to prevent it from being overwritten by the application. Also, make sure you can jump to the boot-loader during the boot sequence, without application. You’ll probably need an additional push button or an external source that can send signal or commands to jump into the boot-loader during device boot.
Debug interface can be used to reprogram the device, in the field, with unauthorized firmware. If you didn’t lock the access to the port in the firmware, it can also be used to read-back the code from the device. Read-back code can also be used to partially reconstruct the actual code, exposing your company’s IP.
Loading the firmware without the JTAG interface can be done using IC Gang Programmers. You may also outsource this work to companies like HiLo.
Some of the advantages this approach provides are:
- You can also keep the firmware away from your contract manufacturer(s)
- Saves some board space and reduces the BOM cost slightly
Remove test points
Test points shall be one of the first things the attackers shall try to make use of to know more about the system. It’s always advisable to remove most, if not all, the test points from your PCB.
10 Security Goals
Disable JTAG Access — Readback protection
Most of the controllers have an option to disable access to debug port from the software. Make sure you do this, even if you don’t physically have a debug port on your PCB. Disabling access makes extracting firmware from the MCU difficult.
Often, this gives a false sense of security. Generally, controllers are not fault-tolerant. A determined attacker can do Fault Injection to disable this feature.
This is why you NEVER store keys on your controller’s insecure flash. God help you if you share the same key across all your devices.
Pairing with the security chip
For some security chips, you can pair the main controller with the chip by transferring the per-shared secret that you need to persistently store on the controller/external flash.
This offers some degree of protection against an attack where the main controller itself is replaced with the controller with a malicious controller(of the same make) with a custom firmware written by the attacker. Since they wouldn’t know the pre-shared key (Remember? You disable read access by enabling read-back protection), the security controller refuses to communicate with the malicious controller without the pre-shared key.
And yeah, generate the pre-shared key using a TRNG during run time. It’d be a shame if the pre-shared key is hard-coded in the firmware.
Logs are a treasure-trove of information, showing the inner workings of the code. Logs can be used to precisely time fault injection attacks, among thousands of other things.
That’s why you should disable the logger module when you’re nearing production. Also, remove the pins from the PCB.
Phew! That’s the end of this story. I hope you learnt a thing or two on how to get started designing secure electronics. As I mentioned earlier, this isn’t security advise. Just a bunch of my learning as I designed electronics.