Firmware security (20732)

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
legic_1490776
Level 5
Level 5
25 likes received 10 likes received First like received

I have two related questions

(1) Is there any way that I can place a security key in an area of the EEPROM that will not be overwritten in an OTA?  (And thus also the key does not need to be included in the OTA image)?  Currently I am writing it into the NVRAM on the first boot-up, which means it need not be included in the OTA image, but I wondered if there is a more convenient way to do this.

(2) Is there a way to prevent someone from dumping the firmware image from our device?  I noticed the "DFU key" in the BTP file - if I customize this key, would this prevent someone who did not have that key from dumping the firmware?

0 Likes
1 Solution
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

Any 'unused/unallocated' area should be OK to use. See the typical EERPOM/SF layout in ws_upgrade.c. The first 40 bytes at EEPROM offset 0 is used by the firmware. The next important location is 0x100. So one possible location is between 0x28 and 0xFF. You should also be able to carve out another such unused location by moving VS, DS1 and/or DS2 in ws_upgrade.c (and also in the .btp file in Platforms/*/*.btp, see comments in ws_upgrade.c). But this may not always be portable across all WICED Smart chips (as of now, you should be OK doing it this way with 20732, 20736 and 20737 SoCs and S modules, but this may change in the future).

You should be able to use BOOLEAN bleapputils_eepromRead(void* buf, UINT32 offset, UINT32 len) from bleapputils.h

DFU key is not used in 2073x family of chips. So this will be ignored by the FW. There is no way to prevent someone from dumping the FW/app stored in the EEPROM.

View solution in original post

4 Replies
asridharan
Employee
Employee
10 comments on KBA 5 comments on KBA First comment on KBA

Any 'unused/unallocated' area should be OK to use. See the typical EERPOM/SF layout in ws_upgrade.c. The first 40 bytes at EEPROM offset 0 is used by the firmware. The next important location is 0x100. So one possible location is between 0x28 and 0xFF. You should also be able to carve out another such unused location by moving VS, DS1 and/or DS2 in ws_upgrade.c (and also in the .btp file in Platforms/*/*.btp, see comments in ws_upgrade.c). But this may not always be portable across all WICED Smart chips (as of now, you should be OK doing it this way with 20732, 20736 and 20737 SoCs and S modules, but this may change in the future).

You should be able to use BOOLEAN bleapputils_eepromRead(void* buf, UINT32 offset, UINT32 len) from bleapputils.h

DFU key is not used in 2073x family of chips. So this will be ignored by the FW. There is no way to prevent someone from dumping the FW/app stored in the EEPROM.

Thanks, Arvinds,

One followup: If we knew that we were never going to load/upgrade again over UART (only over the air), is there some way to permanently disable to boot loader, say by overwriting some part of the ROM? 

Or is protecting the firmware fundamentally impossible because it's always possible to access the eeprom directly using the SDA/SCL lines?

0 Likes

> is there some way to permanently disable to boot loader, say by overwriting some part of the ROM?

I can't think of a way to do this, especially when someone has physical access to the device. Nothing can be written to the ROM because this is a mask ROM (in the silicon). There may be some (external) HW methods to achieve this - one thing that comes to my mind is pads that can be broken off the board after being programmed in the factory (but someone could always cut traces and solder wires to SCL/SDA/HCI UART).

0 Likes

Thanks, this makes sense.

0 Likes