Security Bit & Custom Bootloader

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm working on a custom bootloader that may include some sort of cryptographic control to prevent unauthorized code from being loaded. I've found the flash security bit can prevent reading/programming/erasing other than a full chip erase, which sounds like what I'd want to prevent easy access to any locally stored keys. However, it sounds like setting the flash security bit would also prevent my bootloader from functioning, because in order to update the flash, it would need to erase itself (...problematic...) during the chip erase command.

I do have external memory (SD card) and the 64k of on chip RAM, but it sounds like those aren't of any use because the only way to clear the security bit is via JTAG.

Has anyone done something like this and managed to prevent someone from easily reading the flash, without performing a full security lockdown?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hmm you can't use the chip erase with the bootloader running, but you can erase each pages you want to write from the bootloader, even with the security bit set (as long as flash pages are not locked). With the security bit set, you will prevent all jtag access to erase/read/write the flash.
The bootloader can also run from RAM, meaning you can reprogram the bootloader itself (ie the code loaded in flash, but later copied and executed from RAM) while running from RAM. Take care that any power loss will make the program to crash.

-sma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sma,

Thanks, I wasn't sure if the security bit would prevent the bootloader from playing with flash. I suspect this means that the DFU bootloader would be a huge security hole then, if one forced the DFU bootloader to load, they could just read the flash via that instead of JTAG, no? Is there any way to prevent that, short of removing the Bootloader (currently impossible, since I don't have easy JTAG access on my production boards).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you don’t want the booloader to load, why do you have it in there? You mentioned something about authorised code, so you probably need to extend your bootloader to only communicate with authorised sources, disallowing read and other commands otherwise.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

catweax,

At the moment, mostly as a method of last resort. I'll be the first to admit that I'm not 100% confident in everything working perfectly right away, and I don't want to unnecessarily cut out my only method of salvaging a broken device. Long term though, yes, I could remove the ability to get into the DFU bootloader (at least any obvious methods) and then I would be all set.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

iwoloschin wrote:
sma,

Thanks, I wasn't sure if the security bit would prevent the bootloader from playing with flash. I suspect this means that the DFU bootloader would be a huge security hole then, if one forced the DFU bootloader to load,
they could just read the flash via that instead of JTAG, no? Is there any way to prevent that, short of removing the Bootloader (currently impossible, since I don't have easy JTAG access on my production boards).

No need, the DFU bootloader is designed/implemented to prevent read access when security bit is set.
Plus the DFU bootloader (loaded by Atmel) is protected with the BOOTPROT fuse so you can't erase it from the application, only through JTAG. If security bit is set, you won't be able to read through JTAG nor through the bootloader.

-sma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sma wrote:
If security bit is set, you won't be able to read through JTAG nor through the bootloader.
I don’t think the security bit forbids the bootloader to read the Flash. After all, it is running from said Flash and all MCU-internal read accesses to the Flash should be the same. JTAG-reads are a different matter and they’re not possible with the security bit set.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

catweax wrote:
sma wrote:
If security bit is set, you won't be able to read through JTAG nor through the bootloader.
I don’t think the security bit forbids the bootloader to read the Flash. After all, it is running from said Flash and all MCU-internal read accesses to the Flash should be the same. JTAG-reads are a different matter and they’re not possible with the security bit set.

I haven't looked through the DFU bootloader code yet, but it's possible that the DFU bootloader is checking if the security bit is set and then disallowing a read.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

iwoloschin wrote:
I haven't looked through the DFU bootloader code yet, but it's possible that the DFU bootloader is checking if the security bit is set and then disallowing a read.
That would make sense, but it also means that the bootloader plays an integral role in securing your device.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

catweax wrote:
That would make sense, but it also means that the bootloader plays an integral role in securing your device.

I'm ok with that, so long as the behavior is predictable and reliable. None of this work will prevent a determined person from gaining access, but it prevents a dishonest person from stumbling onto my code. Same as locking the front door when you're out.