Question on protection bits for bootloader

[loupan]

I would appreciate it if someone could confirm my understanding of the protection bits.

The following background (and assumptions I have made) may be useful in understanding what I am trying to accomplish..

I have a decoder in the bootloader so that I can provide encrypted hex files to end users for updates while still keeping the code secure.

With that background, it seems to me that I want to do the following:

1. Protect the code section from “external” reads to prevent someone for reading the program’s object code with a programmer, for example.

2. Protect the boot section from “external” reads to prevent someone for reading the bootloader’s object code with a programmer for example, since that would possibly allow one to determine the encoding scheme, which could then be applied to the encoded hex file, which is readily accessible.


3. Protect the code section from “external” writes to prevent someone from overwriting all or part of the program memory space, which would then potentially allow one to read out the bootloader hex code using read_program_memory() and printf() instructions.

4. Likewise, protect the boot section from “external” writes to prevent someone from overwriting the bootloader block, which would then potentially allow one to read out the program code using read_program_memory() and printf instructions.


There seems that there is no need to protect the fuses from reads or writes since the protection states of the fuses can only be changed from “protect” to “unprotect” with a complete erase of the chip. However, protecting these from reads and writes seems to have no down side.

Likewise, it seems that there is no need for any of the other protection flags to be enabled (such as protection from table reads). Also, for my application, securing the data section of eeprom is not a concern.



With the above background, and assumptions, it appears that I need to set protection for only four flags:


// PROTECT - Program memory is protected from reads
// WRT - Program Memory is Write Protected


// CPB - Boot Block memory is Protected from reads
// WRTB - Boot block memory is write protected


If I have missed the boat on any of the assumptions, or if there are other security holes that I have not considered, I would appreciate your comments.

Thanks in advance,

loupan

[PCM programmer]

My suggestion is to read the threads on the Microchip forum on this topic.
Use this search string in Google:

[loupan]

Thanks PCM

I am still a bit confused.

Can you help on these two specific points?

1. // WRT - Program Memory is Write Protected
// WRTB - Boot block memory write protected

Am I correct in assuming that the write protection for the above fuses applies to external writes, as would apply when an external programmer is being used (vs. Write_program_memory() writes)?



2. If one is attempting to secure the object code of both the application and the bootloader, even assuming that reads of the boot block and program blocks, using an external programmer, have been protected with ""CPB" and PROTECT" respectively, isn't it correct that one must also guard against someone using an external programmer to overwrite the boot block for example, with code that contains read_program_memory() + printfs to effectively read the application object code and print it out on the serial port, or likewise, use an external programmer to overwrite the first application block (that the bootloader jumps to when not invoked to do its bootload function), and if this code contains read_program_memory() and printf's of the bootloader block, wouldn't that allow one to read the object code of the bootloader?

If the concerns in (2) are legitimate, it seems that both the boot block and program memory blocks must be "write protected" as well as "read protected".

I'm not sure if my confusion is based on unfounded paranoia, or a misunderstanding. But all of the different protect fuses must be there for a reason. I have not seen a cogent discussion of how and why all of the protection bits would be used, or why they are needed. Some are more obvious than others.

Thanks again,

Regards,
loupan