Firmware security and protection

[xrstokes]

I've developed an IOT device and now I'm concerned about security. Uses ethernet, tls and mqtt to upload cloud data. Checks a directory on the web for firmware updates. The mqtt is well sanitized and i'm not extremely worried about attack vectors coming from a compromised IOT device. I'm more concerned about software IP theft and attacks on the IOT devices themselves that would damage their operation. I’m also not after perfect security, just enough to be an enormous pain in the *** to anyone who gets the idea to try. The data sent and received apart from the firmware itself isn’t private in any sense.

I have not setup or implemented IAP yet for firmware updating so I have some questions about that. Does IAP erase and replace the entire firmware or only the piece after where IAP runs? Can I have a persistent key saved on the chip [stm32f427] that survives the IAP so that firmware would not have to ship with it? All devices have sd cards.

Delivering the firmware unencrypted is not an option because it could include credentials. There are other layers of defence that would make leaked credentials not critical but annoying. So, some sort of encryption is required for the firmware as that seems the easiest attack vector [at least what I would use]. Firmware is not always delivered over ethernet and in some case would be delivered by sd card. So, protecting the key used to unpack the firmware seems to be the game at foot I keep coming back to. I know this would be easier if I moved over the stm32L4 and that isn’t off the cards here if I MUST. The budget is there to add a crypto chip like the following and this is where I’m leaning towards. https://www.digikey.com.au/product-detail/en/microchip-technology/ATECC608A-SSHCZ-T/ATECC608A-SSHCZ-TCT-ND/7928237

Can someone please explain how one would use such a chip to implement protection of the firmware during the IAP procedure. Or am I totally off the reservation because data can be sniffed on the i2c bus. I might add that the quantities are low, and we handle loading the firmware for every unit shipped.

I know this is a lot to ask. I’ve been reading for days and can’t get my head completely around it. Thanks in advance.

[KnarfB]

You might want to check https://www.st.com/en/secure-mcus/stsafe-a110.html

[xrstokes]

That requires the stm32L4 as well. looking for a solution that will work with the F4.

[KnarfB]

Why? Both are crypto co-processors and I2C slave devices. STSAFE can work with any MCU. Within the MCU you have, of cause, only the MCU specific features available.

There was a discussion here >1 year ago "AES-128 encryption for firmware image" without any crypto hardware for STM32F0 which might help you.

For IAP, you typically have a resident bootloader in one part of the flash which for updating downloads, decrypts and stores the firmware in other parts of the flash. You can secure the firmware by read-out protection and anti-tamper as suggested by @prain​ as a basic measure. You can leave extra flash sectors for storing the key material in the MCU or use a crypto co-procesor for storing the key material in an extra secured chip.

[xrstokes]

Is the bootloader changed with the OTA firmware update or is it static. Basic stuff I'm sure but i've managed to end up neck deep in coding without some basic knowledge because my background is in managed code.

[prain]

First of all try to know more about​ problem. does the attacker have access to your hardware (to use logic analyzer or so)? or you just need to protect communication medium from attack?

providing encryption for medium is easy and there are many ways to achieve. you don't need any external hardware.

but if attacker has access to your hardware, things are more complicated. you may need to use tamper mechanism to protect the firmware.​

[xrstokes]

Ok, I think found what i need and it's a whole dollar to add it. https://www.youtube.com/watch?v=cbOuo-wL2Ms

It has 16 key slots, I can use it to store an oem key for secureboot, a device key pair for authentication and an encryption key for decrypting the firmware during the flash procedure. Any trap here i've missed?