PIC32MZ - Flash Access Permissions

Noggin
...
However, am I correct in my understanding that a programmer (PICkit4, ICD4, RealICE, etc) could still just erase the device and load in a new bootloader?

Yes

Even if this is true, we may still be able to go this route but disable the ability to reprogram the PIC by simply removing the ICSP header (or DNP some resistors).

ok, if they assume the "bad actor" won't simply add it back.

ricok, if they assume the "bad actor" won't simply add it back.

Absolutely. I've asked for clarification on what the requirements are, and they're very nebulous. One of the issues is that there are a dozen or more  agencies in different countries we have to satisfy and they haven't standardized on much. We can do pretty much whatever we want, but we have to convince them that we've done a reasonable job of making it difficult for someone that wants to modify the system. So that means I have to convince our compliance officer that we've done our due diligence. The good news is that our compliance officer is very intelligent, and I think a former software engineer.
 
I think I've figured it out though. The board that is currently in the field doesn't have a bootloader, so the regulatory agencies don't care that it can be reprogrammed with physical access to the board because it is buried in the system. This argument has been made and has been accepted.
 
I think the problem with my solution is that someone could get into an unprotected area of the system, unplug the USB cable, plug it into their own system, load in a bad application, then plug the USB cable back into the PC. Doing something like this in the unprotected area of the system wouldn't raise eyebrows because it could be done during normal maintenance of the machine. So I think all we need to do is argue that the bootloader is a "good actor" that we can trust (just like the firmware on the current board in the field is a trusted good actor) and simply sign the application files so the bootloader will only accept them with a proper signature.
 

NKurzmanClass B libraries are included in harmony. If you’re using harmony you can use them to verify the CRC of your code. If you are not using harmony you should be able to find the old class B library app note which should have the code.

Thanks, I'll take a look at those. We're already verifying the CRC of the application space on boot and erasing it if it has changed. We're also doing some validation on the .hex file as we bootload it to guarantee that we didn't miss a line, received the entire file, etc. I'll see what else the Class B libraries has up its sleeves and see if it is something we should incorporate.
 
Thanks to both of you guys! I think I'll be able to make an argument for our current solution if I lock the bootloader space and require the bootload files to be signed.

boatbodgerOne issue you may have is that you would need the bootloader to check the signature *before* the new program is blown to the flash.

Is that true? I've seen that claim made in another thread I was reading where someone was making a secure bootloader, but I don't think it is something I necessarily need. The bootloader I already have is capable of recovering from power cycles, reboots, corrupted applications, partial bootloads, and a handful of other things. One of the final checks that is completed is that the PC sends down an SHA256 hash of the entire bootload file that the bootloader should have received. If it sent down a private-key-encrypted SHA256 hash generated at compile time, the bootloader could use a public key to decrypt it and verify the hash. If verified, it would complete the bootload and launch the application.
The only reason we'd need to check the signature *before* the program is blown in is if we couldn't recover from a partial or interrupted bootload, right? I just want to make sure I'm not missing something about file signing.