0
\$\begingroup\$

Consider a microcontroller with self-programmable flash, for example some ATSAM MCU.

I put a bootloader on it, which has the additional capabilities of receiving programs, ex. using USB, in whatever format I use, and storing them in a given part of the flash. It then allows execution of these programs. This is public and anyone can use that feature.

In some given part of the flash, that the bootloader won't overwrite, there's data (could be the bootloader code itself) that I really don't want anyone to be able to read.

Is it possible to somehow protect that flash area from a program loaded through the bootloader that would simply try to read it and report it however they want, ex. using USB ? Are there specific features enabling this ?

For the record I'm coming from the Arduino world and new to the actual MCU world. Thanks.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Your title says "protect from write", but your text says "protect from read". Those are two quite different things. (Yes, most micros let you protect from writes, at least for certain blocks. No, most wouldn't do what you want, although a sufficiently fancy one with an MCU and some matching trickery in your bootloader might do the job). \$\endgroup\$
    – TimWescott
    Jan 8, 2021 at 1:31
  • \$\begingroup\$ Does the bootloader itself have to be able to read it? There are features like this for things like encryption keys where the goal is that nothing should be able to retrieve the key except for whatever hardware is using it. If the bootloader itself can access it, then your problem is a lot harder since anything that compromises the bootloader automatically gains access. \$\endgroup\$ Jan 8, 2021 at 3:18
  • \$\begingroup\$ @TimWescott My mistake, I edited accordingly \$\endgroup\$ Jan 9, 2021 at 17:34

4 Answers 4

0
\$\begingroup\$

You need a MCU with security features for this, standard MCUs such as the SAM you mentioned do not provide these kind of security features.

If you have a custom bootloader that allows anyone to upload and execute any code/program they wish, even if it limits uploading to only areas allowed by you, in a standard MCU, nothing prevents that program from doing whatever it wants, like reading the whole memory and send it out via some interface, or erasing the bootloader, or whole memory, and lock you out of it.

Though, the SAM series seem to have boot loader protection fuse bits, so it will disable erasing your custom bootloader, as there is no way to disable that via software mechanisms.

\$\endgroup\$
3
\$\begingroup\$

No, you cannot implement memory access control in Arduino microcontroller firmware. Maybe with a different platform, if you use a sufficiently secure system, but that's a major design consideration. You will have to take into consideration how important the thing you're trying to protect is.

The problem with inventing your own security system is that you have to get it right every single time, but an attacker only has to be right once. They only have to find a single weakness that you didn't think of. There is an industry group called Payment Card Industry Security Standards Council or PCI SSC which has been working on this problem for years... they are concerned about real criminals trying to break into financial terminals to steal real money, and all points of the supply chain are potentially vulnerable.

It's a very hard problem, and one that can't really be addressed very well without having a secure microcontroller to begin with. The company I work at makes security devices used in point-of-sale terminals (credit card readers); see appnote-4809 and deepcover embedded security solution guide (Full disclosure: I am an applications engineer at Maxim Integrated, which manufactures secure microcontrollers, among other things.)

In your case, you are only trying to control read/write access to some part of memory, but there's a conflict between the requirements of having "access controlled memory" and the requirements of allowing new firmware to run in a "bare metal" (eabi) environment, with no operating system and no supervisor. Anyone can load any code through your bootloader. There is no way for the Arduino chip to tell whether the code is "good" code or "evil" code. The Arduino bootloader is not designed for any kind of security at all, it is only designed for the convenience of being able to load new firmware in-circuit without the need for an external device programmer. The only Arduino security consideration is, don't let anyone "evil" near your hardware.

One idea to consider is to "lock down" your bootloader such that it will only accept firmware updates that have been signed with a suitable crypto key. You would then need to have some kind of system that reviews the candidate firmware, looking for any "evil" features like attempts to access certain memory addresses, before approving the firmware by signing it with your secret key. That's pretty far out of what you can do with an Arduino though, I don't know of any crypto libraries that work on an Arduino. You might consider upgrading to an Arm processor if you need that kind of security. See mbed.org for more details. However there are still more problems...

Consider also how the bootloader got into the chip in the first place. If your Arduino is the classic Atmel/Microchip ATmeta328 microcontroller, then the initial bootloader was programmed in using an external device programmer connected to a 6-pin header with SCK, MISO, MOSI, RESET, VCC, and GND. As long as that device programming header is available, then no matter what your bootloader does, an attacker could connect to those signals with an external device programmer, and load their own firmware directly. (This is not only an Arduino platform issue; most microcontrollers have an equivalent in-circuit debugging or programming interface. ARM core CPUs have CMSIS/DAPLINK which is used for firmware loading, and JTAG is also commonly used.)

There are frequently questions on this site where people ask how to reprogram various boards, whether garage door openers or washing machines or calculators or anything with any kind of microchip on it. So if your hardware is released in the wild, it's likely at some point someone will try to read or write your microcontroller's firmware. Most commercial products take the precaution of using microcontrollers that can lock against firmware being read out easily, by setting a one-time programmable "fuse" bit.

Even if you designed a custom PCB without that in-circuit programming header (and used ATmega328 chips that had firmware loaded prior to assembly, using a socketed external device programmer), all of the device pins are still exposed on the ATmega328 chip itself. A determined attacker with access to the hardware, could still contact those pins with a device programmer and gain control to execute arbitrary code on your board. It might be possible to shield against that type of physical attack by using epoxy potting compound to coat the chip with mechanically tough and electrically insulating material. This adds cost and also makes it impossible for you to update your own bootloader. And even that might not be enough to keep someone determined out.

That's just one small trace of the kind of nightmares a security researcher treads through. Every aspect of the system is potentially vulnerable to some kind of attack, if the attacker was lucky or determined enough. Add more armor against that particular type of attack, and now you have the cost and inconvenience of carrying that armor all the time. And even so, there are still vulnerabilities. So there is always consideration of cost versus benefit.

Ultimately, no matter how foolproof a system seems to be, someone always discovers some weird abnormal test case. See this recent question on stackoverflow meta: https://meta.stackoverflow.com/questions/404302/are-whitespace-only-display-names-allowed and its linked question which has a blank title consisting only of Unicode left-to-right and non-blanking-space characters, _____ and also discussed on meta here.

\$\endgroup\$
1
  • \$\begingroup\$ This Defcon talk is also interesting in terms of people going to absurd lengths to reverse engineer chips, including visually reading masked ROM from a decapped die to extract game ROMs... (1:02:00). \$\endgroup\$ Jan 8, 2021 at 9:26
0
\$\begingroup\$

For ATSAM MCUs you can write protect the bootloader area and the EEPROM emulation area with a register setting. For example for SAMD21 and SAMD51 the BOOTPROT register is used for that.

For data security use some kind of encryption.

\$\endgroup\$
0
\$\begingroup\$

If you are asking how to protect the bootloader portion of flash, on some ATSAM there is the BOOTPROT flag. You can set how many bytes you want to protect from the fuse options in Atmel Studio.

If you don't want people to overwrite the data you downloaded from USB, that might be a little bit trickier. At startup the bootloader decides whether to execute the bootloader code or the application code. If it enters in the bootloader section, you are able to erase the program section, thus erasing the data you have dumped from USB. You can enter the bootloader mode either if there is no data in the program section of memory, you hold some pins low/high or you set a flag in the NVM (that the bootloader will check at startup).

So I would suggest to protect the pins that allow you to access bootloader mode and set the flag to enter in bootloader via some sort of authentication. That way, you will be able to still reprogram the chip (what's the point of having a bootloader if this is not a need), but other people will not be able to access it and erase/read your data.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.