• AVR Freaks

Hot!PIC32MZ - Flash Access Permissions

Author
Noggin
Junior Member
  • Total Posts : 112
  • Reward points : 0
  • Joined: 2008/07/07 14:49:34
  • Location: 0
  • Status: offline
2021/01/15 14:20:01 (permalink)
0

PIC32MZ - Flash Access Permissions

I am on a project which utilizes a PIC32MZ1025DAK176. The PIC has a bootloader and an application loaded in flash. The end product is to be used in a regulated field. Part of the regulations requires us to be able to validate that the bootloader and application are valid. Our method of validation is somewhat flexible, we just have to be able to convince them that our method of validation is solid.
One method of achieving this would be to have a read-only, write once bootloader that is "known good." We could argue that the bootloader is written at the factory and cannot be written again. It looks like there are configuration bits that would allow us to specify the amount of memory set aside for the bootloader and some more configuration bits that would make it so that only the bootloader (or maybe nothing?) could write to the bootloader space. This would prohibit any potential bad actor from bootloading in an application that could compromise the bootloader.
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? 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).
#1

6 Replies Related Threads

    ric
    Super Member
    • Total Posts : 29860
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: PIC32MZ - Flash Access Permissions 2021/01/15 21:01:50 (permalink)
    0
    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.

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #2
    NKurzman
    A Guy on the Net
    • Total Posts : 19144
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: offline
    Re: PIC32MZ - Flash Access Permissions 2021/01/15 22:19:12 (permalink)
    4 (1)
    Class 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. Alternately you can build a project in harmony that just has the class B stuff, and copy it out.

    This may be one way to achieve your goal.
    #3
    Noggin
    Junior Member
    • Total Posts : 112
    • Reward points : 0
    • Joined: 2008/07/07 14:49:34
    • Location: 0
    • Status: offline
    Re: PIC32MZ - Flash Access Permissions 2021/01/16 06:35:35 (permalink)
    0
    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.
     
    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.
    post edited by Noggin - 2021/01/16 06:42:06
    #4
    boatbodger
    Super Member
    • Total Posts : 147
    • Reward points : 0
    • Joined: 2011/03/27 15:39:07
    • Location: 0
    • Status: offline
    Re: PIC32MZ - Flash Access Permissions 2021/01/16 08:45:06 (permalink)
    0
    One issue you may have is that you would need the bootloader to check the signature *before* the new program is blown to the flash.
    I think if I had this problem, I would enhance the bootloader so that it uses something like a NONCE exchange (as used in SIP registration), meaning that only somebody with the knowledge of the shared secret and your bespoke loading tool would be able to persuade the bootloader to accept the software load.
    I think if you do that, combined with some checks on file signature you'd have a pretty robust argument to the various regulators.
     
    I can't see an easy way to guard against somebody with physical access to the board simply erasing the PIC and starting again, but it sounds like you have already made and won that argument.
     
    Sounds like an interesting project!
    Chris
    #5
    Noggin
    Junior Member
    • Total Posts : 112
    • Reward points : 0
    • Joined: 2008/07/07 14:49:34
    • Location: 0
    • Status: offline
    Re: PIC32MZ - Flash Access Permissions 2021/01/16 09:50:49 (permalink)
    0
    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.
    #6
    cirilo.b
    Junior Member
    • Total Posts : 59
    • Reward points : 0
    • Joined: 2020/09/08 18:40:42
    • Location: 0
    • Status: offline
    Re: PIC32MZ - Flash Access Permissions 2021/01/16 14:24:29 (permalink)
    0
    A lot depends on what specific requirements you're trying to meet, but in general when you program at the factory both the bootloader and app must at least be subject to a hash check (md5 would do) before programming just to verify that you are programming officially released firmware. If you must check boot and app with each start of the instrument then the bootloader needs to perform a hash over the boot flash and confirm that nothing has changed (no intentional or unintentional change to memory) and the application has to do the same for the program flash.   On top of that, field updates (in the most stringent cases) should be authenticated (or better also encrypted) using something like AES-GCM and a shared secret.  For the self-check on start, there are some challenges with storing the expected hash - it would have to be at a fixed location (and be the same location regardless of field updates) and when processing that location some fixed value will have to be assumed. Obviously you cannot process the actual hash value or you would have a different hash.
    #7
    Jump to:
    © 2021 APG vNext Commercial Version 4.5