- Silicon Labs Community
- Welcome and Announcements
- Silicon Labs Knowledge Base
- 8-bit MCU
- 32-bit MCU
- Bluetooth / Wi-Fi
- Other Products Category
- Optical/RH/Temp Sensor
- Other Products
- Hardware and Software Tools
- Simplicity Studio and Software
- General Discussions and Suggestions
- Chinese Forum
- Software Libraries
- Development Kits
- Reference Designs
- Third Party Tools
- White Papers
- Official Blog of Silicon Labs
- Chinese Blog
07-05-2017 03:51 PM
I'm developing an application where it is absolutely critical that an encryption key is stored securely in the EFM32 microcontroller.
Reason: I need to ensure that nobody can impersonate a device to generate fake measurement data. The reasoning is that if an attacker cannot get a hold of the key, then she/he cannot create the data that needs to be sent to the server. As the server tries to decode the data with the same key, the decryption and CRC checks will fail if the attacker does not know the encryption key. I'm using AES128-CTR mode encryption for this purpose on the AES hardware accelerator on the EFM32.
At production time I program the flash program memory and I lock the debug interface.
As a second step of the production programming I store the device-unique key in the program memory. I have reserved a page in flash memory (NOT the 'user page') for that.
As far as I see this is relatively secure, as when somebody would want to read the key from the flash, she/he would need to unlock the debug interface and would at that time trigger a mass erase of the flash.
Is there somebody who can give me some information on how securely this mass erase is implemented in the chip silicon? When I look at the reference manual, the unlock procedure takes some time (due to the mass erase). Is it by the design of the hardware guaranteed that an attacker cannot trigger the unlock unless the flash memory is completely erased, e.g. by playing with the voltage supply?
Solved! Go to Solution.
07-06-2017 12:39 AM
Because core VDD is regulated, manipulation of VDD would not affect the behavior of the flash.
If VDD drops below the minimum for proper operation, the brown out detector would kick in and reset the device.
The last thing to be erased would be the lock bits page, so even browning out in the middle of debug unlock would mean that if the part reboots, it would still be locked.
The device probably wouldn't behave as expected because the initial stack pointer and PC would be 0xFFFF_FFFF, so the part would just hard fault and do nothing.
I doubt any NVM-based microcontroller can be completely secure, but running from a regulated core supply and internal oscillator is a pretty robust means of keeping a device locked and far less susceptible to lower cost methods of breaching security.