• AVR Freaks

Hot!PIC32MZ: How do you encrypt/validate hex file to update firmware?

Author
RodoPIC
Senior Member
  • Total Posts : 173
  • Reward points : 0
  • Status: offline
2019/03/28 10:06:52 (permalink)
0

PIC32MZ: How do you encrypt/validate hex file to update firmware?

Hi all,
I'm interested in how you guys encrypt/validate a hex file that will be sent via USB to a product with a PIC32MZ . I'm new to PIC32MZ and the whole firmware update thing (via bootloader). I got the answer about how to transmit the hex file but then someone raised a good point so I thought I ask the question in a separate thread.
Thanks
#1

8 Replies Related Threads

    Jim Nickerson
    User 452
    • Total Posts : 5947
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: online
    Re: PIC32MZ: How do you encrypt/validate hex file to update firmware? 2019/03/28 10:14:22 (permalink)
    4 (1)
    For validation I make use of the DMA CRC mode.
    #2
    NKurzman
    A Guy on the Net
    • Total Posts : 17344
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: PIC32MZ: How do you encrypt/validate hex file to update firmware? 2019/03/28 10:19:50 (permalink)
    4 (1)
    Encryption and validation are not the same thing.
    Do you Need Encryption? What strength?
    Validation of what? the Hex file is complete and correct?  Or that the Hex file is program on the PIC correctly?
    #3
    jdeguire
    Super Member
    • Total Posts : 456
    • Reward points : 0
    • Joined: 2012/01/13 07:48:44
    • Location: United States
    • Status: online
    Re: PIC32MZ: How do you encrypt/validate hex file to update firmware? 2019/03/28 10:30:28 (permalink)
    4 (1)
    The end of each record is a checksum that is set up such that adding up all bytes in the record (after converting them from ASCII), including the checksum byte, will output a value whose lowest byte is 0. You should verify the checksum of each record as you read it.  Our bootloader takes the records as-is in ASCII and it handles all of that on its own.  If you plan on parsing the file externally and sending down the raw data, you should probably send down your own checksum for each chunk of data to send.
    #4
    Jim Nickerson
    User 452
    • Total Posts : 5947
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: online
    Re: PIC32MZ: How do you encrypt/validate hex file to update firmware? 2019/03/28 10:30:58 (permalink)
    4 (1)
    Some time ago I posted about using DMA CRC on a PIC32MX795
    https://www.microchip.com/forums/FindPost/825019
    #5
    RodoPIC
    Senior Member
    • Total Posts : 173
    • Reward points : 0
    • Status: offline
    Re: PIC32MZ: How do you encrypt/validate hex file to update firmware? 2019/03/28 11:09:56 (permalink)
    0
    NKurzman
    Encryption and validation are not the same thing.
    Do you Need Encryption? What strength?
    Validation of what? the Hex file is complete and correct?  Or that the Hex file is program on the PIC correctly?




    More like "this is a valid file" (received by the PIC32MZ) and not some file someone generated with garbage and added the correct checksum at the end of each record in the hex file. 
    For the strength of encryption .... that's a tough one... enough to discourage someone with "low" skills from trying? What would you guys think would be "enough". My products would be just consumer stuff, no life depends on it. 
    #6
    Howard Long
    Super Member
    • Total Posts : 672
    • Reward points : 0
    • Joined: 2005/04/04 08:50:32
    • Status: offline
    Re: PIC32MZ: How do you encrypt/validate hex file to update firmware? 2019/03/28 12:20:29 (permalink)
    5 (2)
    In my bootloader code which I’ve used on PIC24 and PIC32, I use a modified AES block encryption algorithm, which allows me to send a series of blocks each fitting neatly into a USB HID packet.

    I distribute the firmware as an encrypted blob .bin file with an CRC embedded in it in an absolute place at the end of flash memory.

    I write and commit the data to flash as it comes in, I do not validate it against a CRC at this stage.

    When the device boots, it always goes into the initial booloader anyway before handing over to the applkcation. Before it hands over to the application, it does the CRC flash check. If the flash CRC check fails, it simply doesn’t enter the application and sits in the bootloader waiting to be reflashed.

    Here are a few back doors to keep it in the bootloader too, such as unmanaged exceptions, a hardware reset that isn’t a POR, a software reset from the application and a watchdog timeout.

    With tens of thousands of devices out in the field, not once have I had one bricked because of a bad firmware upload.
    #7
    Larry.Standage
    Moderator
    • Total Posts : 896
    • Reward points : 0
    • Joined: 2011/12/30 09:50:47
    • Location: 0
    • Status: offline
    Re: PIC32MZ: How do you encrypt/validate hex file to update firmware? 2019/03/28 12:32:42 (permalink)
    4 (1)
    You're going to need to analyze the "attack vectors" for your product. Remember that there is more than just changing the code on the product. There's also the question of cloning the product, if you feel that is a risk.
    If you want a "valid file", there's the question of a valid source vs. just a valid file. A valid file could be checked with a checksum, but by then the program has already been programmed (unless you're using alternate flash panels).
    A valid source would require some kind of authentication or keys that would be used to decrypt the file as it is transmitted.
     
    That's just scratching the surface of product security.
    #8
    Howard Long
    Super Member
    • Total Posts : 672
    • Reward points : 0
    • Joined: 2005/04/04 08:50:32
    • Status: offline
    Re: PIC32MZ: How do you encrypt/validate hex file to update firmware? 2019/03/28 14:39:40 (permalink)
    4.67 (3)
    That is true, I had a PIC24 based product hacked, I assume by fiddling with undocumented programming configs such as Vpp.

    While I was royally pi**ed off at the time, the perp never got very far in the end due to other less technological protections, notably an NDA and further agreement I had with a single source supplier of a key part in the product.

    You’re frankly wasting your time with patents etc IMHO unless you have lots of spare time and money to spend on professionals and a legal team, and really intend to spend a lot of time, effort and money going after any nefarious characters. A patent isn’t worth anything unless you’re prepared to enforce it.

    You also have to weigh up the cost of development and user hassle if your protectin mechanism becomes unreliable or over complex. There’s a very significant cost in support and returned items, and especially the latter you want to avoid at all costs.
    #9
    Jump to:
    © 2019 APG vNext Commercial Version 4.5