[NRF52833] Secure firmware protection method

[Tu Hoang]

Hi everyone,

I have this problem with the firmware protection method in nRF52833. As far as I know, when using secure boot-loader, it can prevent other programmers to flash their own codes to our products without having the public key as well as using the APPPROTECT register to stop the access to debug port . However, this means that every time i need to update the code I have to do it by erase all the code first then flash the whole thing again. This is a little bit too much for me since we produce thousands of unit and if there is any update, the amount of work to Bluetooth OTA them in the field would be tremendous. Also I want to protect our hardware to be used by others.

So I notice that in ESP32 SoC there is a method to secure firmware by flash encryption that is it store encrypting keys inside the SoC in a one time programing block and then the SoC will decrypt the encrypted firmware to run the program (i have tested it in development mode). (it can be seen here  ESP Flash Encryption). So when the key is set, even after a fully erase the flash memory, the eFuse block is till there and other firmware without the key can not be used with the hardware.

So I have 2 questions in mind,

1) Is using Bootloader APP_SIGN_CHECK and APPPROTECT are the only method to protect the firmware? If not can you give me some other methods.

2) Is there a hack or a walk-around to have the equivalent of flash encryption in ESP32? If yes please let me know.

Hope to receive your response soon, good day to you all.

Best regards,

Hoang Ngoc Tu

[Vidar Berg]

Hello,

It's correct like you say that the only way to disable APPROTECT is through an ERASEALL. However, it's not clear to me how this affects your in-field FW updates. Are your end users expected to re-program the chip via the debug interface? If they are, then would it make any difference they had to re-program the entire chip? The ERASEALL operation takes only about 2x longer than it takes to erase one 4K flash page, so I would not expect it to be that much slower than a partial update with sectorerase.

So I notice that in ESP32 SoC there is a method to secure firmware by flash encryption that is it store encrypting keys inside the SoC in a one time programing block and then the SoC will decrypt the encrypted firmware to run the program (i have tested it in development mode). (it can be seen here  ESP Flash Encryption). So when the key is set, even after a fully erase the flash memory, the eFuse block is till there and other firmware without the key can not be used with the hardware.

Looks like this encryption is used for SPI flash. I'm not familiar with the EPS32s, so I'm not sure if it's external flash, or if it's integrated into a SiP package. Either way, I assume the decryption takes place at the SPI interface similar to how it's done on the nRF53 series: Encryption. If that is the case, wouldn't you be able to read the decrypted data as it is being received through SPI anyway (provided the debug interface is kept unlocked)?

1) Is using Bootloader APP_SIGN_CHECK and APPPROTECT are the only method to protect the firmware? If not can you give me some other methods.

The FW image needs to be decrypted before it can be executed by the CPU.

2) Is there a hack or a walk-around to have the equivalent of flash encryption in ESP32? If yes please let me know.

Sorry, I don't understand how encryption of the data is supposed to help. Maybe if you clarify my points above.

Best regards,

Vidar

[Tu Hoang]

Hi Vidag,

Thank you for your answer. I think I can clarify some parts which you have problem with

1) "it's not clear to me how this affects your in-field FW updates" So the thing is we have a lot of configurations done by the end user saved in fds, also our product use Zigbee so it will also need to store some network data needed to be connected after reset. Also because we provide a guarantee service up to 2 years, which we will send our set-up and customer service team to the field to update the firmware if there is any software bug reported, ERASEALL gonna require those people to reconfigure every setup by the end user (which cause a lot of time) and recommission Zigbee all over again ( which is also not good since we sometime have a mesh with about 200 nodes) when a sector erase only gonna update the app section in flash so it will be a lot more convenient. Well, we also have BLE OTA update(since the Zigbee OTA update is not possible due to our code size) but that is also take alot of time since with about 300kb of our firmware it will take about 2 minutes for each device so a direct flash with SWD is still more preferable. So those are reasons I do not want to use APPROTECT.

2) "If that is the case, wouldn't you be able to read the decrypted data as it is being received through SPI anyway (provided the debug interface is kept unlocked)" .  Well, I think you got this wrong, the code in the app section in ESP32 flash is still encrypted and even if it is read from debug port which is UART, it is still need a key to be fully understand, the only time it is decrypted is by the esp execution unit as in here "The ESP32’s flash execution process decrypts the flash memory data when the ESP32’s execution unit tries to read and for the writing process, the flash execution process encrypts the data before writing into the flash memory" .  And another note is that it use the internal flash and not the external flash because everything is still inside the SoC so with normal user or even some engineers that is still not possible for them to get the code. One other thing is that because the encryption key is still inside the eFuse block which can not be erased, when people try to brute-force flash an unsecured firmware in, it will brick the whole SoC. This is another thing that i do not know if NRF52 have or not. 

3) "The FW image needs to be decrypted before it can be executed by the CPU."  Can you elaborate how I can do that since the document you gave me is for nrf53 and all I can find for nrf52 is not really related.

4)"Sorry, I don't understand how encryption of the data is supposed to help. Maybe if you clarify my points above." So i think that if i can encrypt the flash like in ESP32 I can have the same benefits ( another layer of security as well as prevent other to use the hw like in above).

Hope to hear from you soon,

Best regards,

Hoang Ngoc Tu

[Tu Hoang]

Hi Vidag,

Thank you for your answer but I am still unable to understand some points in it.

1) "The only solution I can think of is to decrypt the code in flash and have it executed from RAM". I can understand that part but just do not know how to do it. I would be really appreciate if you could give me some hint or any useful related example on how to do so .

2)"I thought you were referring to the JTAG debug interface.". Sorry if you misunderstand my point but I never refer to JTAG interface for ESP32 since we do not let those pin out. But the point is that the data in the flash is encrypted and it would make it a lot harder for somebody to exploit it by reading the Uart debug port. And i think read the decrypted data is a lot more difficult since it is require a bit of "extra work" to find out where the decrypted data is since no external SPI flash is used. "What's different from this and having our UART serial bootloader on the nRF?" I never dig too deep in UART bootloader but I like I said I did not try to say that it is different but  I just want to add another layer of security in it. So the question is if it is possible for me to achieve the same outcome as in ESP32?

3) "And as far as I can tell, the flash encryption on the ESP32 is only supported for external SPI flash" Well, In the document they said that it was intended for ESP32-off-chip memory but never said that it only work with external flash. In reality, I have done it easily with just the on chip memory every thing is working just fine and a lot of people with on the Internet have done it too. And because we do not know where the decryption happen inside the memory of the CPU so reading it out is pretty difficult. If someone  need to access the firmware they may need to use some method like Fault injection to get the key to decrypt it which is not really that easy.

4) "As I noted above, wouldn't it be the same if you supported DFU over UART on the nRF?" I do not have UART DFU so it is not the same right ? The only type of DFU I have in the bootloader is BLE.

So can you be more specific how i can decrypt the code in flash and have it execute in RAM. Hope to hear from you soon.

Best regards,

Tu

[Vidar Berg]

Hi Tu,

1) This approach does not address your security concern as the decrypted data can be easily read from RAM. It will only complicate your FW design.

2) Then you are not exposing the debug interface. Same as when APPROTECT is enabled on the nrf.

Tu Hoang said:

So the question is if it is possible for me to achieve the same outcome as in ESP32?

Yes, if you add support for DFU over UART to your existing bootloader.

3) off-chip and external memory are the same thing as far as I know. Can you point me to where it stated that you can encrypt internal memory?

Tu Hoang said:

If someone  need to access the firmware they may need to use some method like Fault injection to get the key to decrypt it which is not really that easy.

Maybe. But it is also possible that it can be easily read via JTAG. You may ask espressif if locking down the debug interface is a prerequisite for securing the content on the off-chip flash.

Tu Hoang said:

I do not have UART DFU so it is not the same right

With your current bootloader you will only be able to program the device through BLE.

Best regards,

Vidar

[Tu Hoang]

Hi Vidag,

I do not think that you understand what I ask and the answers you gave me are really vague even when i tried to explicitly explain my situation so I do not think that we should go further but thank you for answering.

So the final thing I want to confirm is that there is no way for Nordic SoC to have some equivalent function like Flash Encryption like in ESP32. Is it correct.

Thank you for your time,

Tu

[Vidar Berg]

Hi Tu,

My problem is that we are not doing an apples-to-apples comparison. First of all, you are not enabling the debug interface on the ESP32, which is basically the same as having APPROTECT enabled on the nRF. Secondly, I find nothing in the datasheet indicating that the ESP supports execution of encrypted code from on-chip memory. And no, the nRF does not support this either.

Again, if you want equivalent function on the nrf, then you need to implement a UART programming interface similar to the one on the ESP32 and keep the debug port locked. The debug lock helps prevent external access to the flash content.

I also fail to see how programming over UART is more convenient than doing it wirelessly. You could have had a custom BLE DFU controller that automatically performed the update for every node within range.

Best regards,

Vidar

[Tu Hoang]

Hi Vidar,

I think that the discussion have gone to far since talking more about ESP32 because it may be off-topic here since me proving that ESP32 can encrypt on-chip memory (since I have done it and a lot of people on the internet have done it too) or explaining to you that its function of flash encryption is really something else than just nRF52 APPPROTECT have nothing to do with the problem that I have asked.

But this one "And no, the nRF does not support this either."  is good enough for me. Since in the beginning I know that STM32 which is also arm-based have a somewhat similar function of encryption with ESP32 so I guess that Nordic SoC may be have it too. But your last reply is enough to answer my question.

My only problem that I have is that I failed to figure out that you misunderstand the term "equivalent function" although i have explained what I mean in detail before. In addition, the way you refuse to answer right on the point in the beginning by giving meaningless suggestion then pointing out that it is not a good pracice is really make me crossed. 

But once again, i appreciate the help you gave me, have a good day.

Best regards,

Tu