New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Readout protection should be enabled by default for added security #6
Conversation
|
Consider different case. You wanted to test your board and try to run various apps and examples and you accidentally locked SWD. Now you want to develop your own app and debug it with open source tools like OpenOCD or Black Magic Probe. You are going to have some trouble because these tools are not able to unlock SWD. You will need proprietary tools like J-Link for it. |
|
As far as I understand, it's easy to force the Tomu back into the bootloader by shorting the two contacts on the top. You can re-flash the chip from there if you accidentally locked SWD. I understand that some people will want to play around with the Tomu board or use it for development, but I think the majority will use it as a cheap, open-source and open-hardware U2F token. I fear people will miss out on this step and never put the chip into readout protection. |
|
I think there is some confusion. The "Enable Readout Protection" is, perhaps, a misleadingly named variable. What it does is prevent the ability to enter Toboot and flash new firmware. It permenantly installs this u2f program. With Readout Protection disabled, users can enter Toboot and flash new firmware by shorting the pins, as @gl-sergi mentioned. Regardless of the value of Readout Protection, the block where the keys are stored is always erased when a new program is loaded. In that way, you can't pull out the keys by loading a smaller program and dumping flash. Of course, regardless of the value you can extract it with SWD, which is one reason the case is clear. |
|
@xobs Thanks, I understand now. I'm not sure this really works then, as I've been flashing my Tomu with the Readout Protection flag on and I can still access Toboot by shorting the pins... |
|
That is correct. You can still access Toboot by shorting the pins, and you can flash new software. You cannot read out the current firmware, only write new firmware. And thanks to https://github.com/im-tomu/chopstx/blob/efm32/u2f/platform.c#L50 any firmware you flash won't have access to the keys, because they will be erased prior to your software getting written. |
|
Ah, I believe I am the one who is confused. Yes, this prevents attaching SWD, and doesn't prevent entering Toboot. That is a different flag. Perhaps it is a good idea to disable SWD, then... |
|
It would be pretty sweet if the readme provided info how to check if readout protection is enabled on the flashed firmware. To increase trust. |
|
Here is official kb article https://www.silabs.com/community/mcu/32-bit/knowledge-base.entry.html/2016/01/13/programmaticallyver-WX4l |
|
Any more thoughts on this? If you don't want to merge it, please close the PR. Otherwise, I'd really like this to be merged. |
|
It's a good change. Thanks for the patch! |
When I first flashed my Tomu, I went over the instructions quickly and didn't see the part about the readout protection.
I think having it on by default makes for more secure defaults and will help others not to make the mistake I made by inadvertence.