• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 458 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TM4C123GE6PM: Tiva USB DFU bootload with encrypted bitstream

Robert Valentine
Prodigy 205 points
Part Number: TM4C123GE6PM
Other Parts Discussed in Thread: EK-TM4C123GXL, EK-TM4C1294XL

Hello,

I've been reading the TivaWare Boot Loader User's guide - SPMU301E April 2014 - Revised April 2020 document (link below).  I noticed that it looks like there is a way to handle an encrypted image/bitstream for the Tiva part, but it looks like it requires #define configuration statements.  This info can be found on page 44 described by the define for "BL_DECRYPT_FN_HOOK".  Because this is a #define does this mean that you can only decrypt with a flash boot loader and  not the ROM?

I'm trying to figure out how to do the following.

1. Encrypt my production CCS binary file output so the binary I send to customers is encrypted.

2. Load this encrypted binary via the USB interface using the DFU.  A big question here is, can this be done with the ROM boot loader code or do I need to write my own bootloader to handle this, or use bl_config.h and bl_config.c?  

Does anyone have any comment/advice that could help me get my mind pointed in the correct direction and be confident in the path I choose for my development?

Boot loader user's guide:

https://www.ti.com/lit/ug/spmu301e/spmu301e.pdf?ts=1682875717794&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTM4C1294NCPDT

Thanks

  • 0
    TI__Guru**** 190806 points

    Hi Robert,

    Robert Valentine said:
    Because this is a #define does this mean that you can only decrypt with a flash boot loader and  not the ROM?

    Your understanding is correct. The decryption is only possible for the flash bootloader, not the ROM. Please also note that the bl_decrypt.c file is only a placeholder. It is empty right now. User can put in the required decryption algorithm. TivaWare flash bootloader and ROM bootloader have no understanding of how the bitstream is encrypted.

    You need to uncomment the below #define in bl_config.h file. 

    //*****************************************************************************
    //
    // Enables the call to decrypt the downloaded data before writing it into
    // flash. The decryption routine is empty in the reference boot loader source,
    // which simply provides a placeholder for adding an actual decryption
    // algorithm. Although this option is retained for backwards compatibility, it
    // is recommended that a decryption function be specified using the newer hook
    // function mechanism and BL_DECRYPT_FN_HOOK instead.
    //
    // Depends on: None
    // Exclusive of: None
    // Requires: None
    //
    //*****************************************************************************
    //#define ENABLE_DECRYPTION

    //*****************************************************************************
    //
    // Allows an application to perform in-place data decryption during download.
    // If hooked, this function will be called to perform in-place decryption of
    // each data packet received during a firmware download.
    //
    // void MyDecryptionFunc(unsigned char *pucBuffer, unsigned long ulSize);
    //
    // This value takes precedence over ENABLE_DECRYPTION. If both are defined,
    // the hook function defined using BL_DECRYPT_FN_HOOK is called rather than the
    // previously-defined DecryptData() stub function.
    //
    //*****************************************************************************
    //#define BL_DECRYPT_FN_HOOK MyDecryptionFunc

  • 0 in reply to Charles Tsai
    Prodigy 205 points

    Hi Charles,

    Does this mean customers have to write their own flash bootload algorithm or is there a default/template flash bootloader provided by TI?

    Also, are there decryption algorithms customers can copy/use from driverlib or something or do we have to write our own decryption algorithms from scratch (leveraging the AES internal peripheral I'm assuming).

  • 0 in reply to Robert Valentine
    TI__Guru**** 190806 points

    Hi Robert,

    Robert Valentine said:

    Does this mean customers have to write their own flash bootload algorithm or is there a default/template flash bootloader provided by TI?

      Please refer to the Serial flash bootloader example at C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c123gxl\boot_serial as a starting point. This flash-based bootloader is to be loaded to address 0x0 by JTAG interface. After the bootloader is loaded and run, it will download the example firmwareC:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c123gxl\boot_demo1 to address location 0x2800. Please run these examples to have a feel for it. The bl_config.h for this bootloader has been configured for UART. This is a good template for you to start and modify for USB. You just need to add the hook for your decryption. 

    Robert Valentine said:
    Also, are there decryption algorithms customers can copy/use from driverlib or something or do we have to write our own decryption algorithms from scratch (leveraging the AES internal peripheral I'm assuming).

    The TM4C123 ROM bootloader does not do the decryption for you automatically but flash bootloader can optionally be configured to do so. With that said, TM4C123 does have the AES algorithm stored in the ROM that users can use. Please refer to TM4C123 ROM user's guide for details at https://www.ti.com/lit/pdf/spmu367. 

     

  • 0 in reply to Charles Tsai
    Prodigy 205 points

    Hi Charles,

    Thank you this is very helpful.  For a USB bootloader would I need to develop a full application using the usblib driver library to boot, enumerate and support a link to software where the software application would use something like hid or bulk to send over the encrypted image?  I assume this is a dumb question and the answer is yes, but just making sure I'm not missing something that would make this development much easier than developing a custom USB bootloader from scratch.

    I am guessing the concept is that a customer would develop a small, but fully capable USB application using usblib to receive, decrypt and write the image data to the correct address.  This is just more involved than the UART because you have the whole usb driver library to deal with?

  • +1 in reply to Robert Valentine
    TI__Guru**** 190806 points

    Hi Robert,

    Robert Valentine said:
    For a USB bootloader would I need to develop a full application using the usblib driver library to boot, enumerate and support a link to software where the software application would use something like hid or bulk to send over the encrypted image? 

    There is already a USB bootloader example. Please refer to the C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c123gxl\boot_usb example. The only difference between boot_usb and boot_serial is the configuration in the bl_config.h file. You can do a diff between these two examples and notice that USB bootloader has been enabled as well as the pins associated with USB functionality are defined. 

    You can run the boot_usb bootloader with the application boot_demo1.c. The boot_usb example already takes care of all required USB initialization so, if the application itself doesn't need to use the USB controller, there is nothing to be done in boot_demo1. 

    For a more realistic USB application that will jump back to the USB bootloader you can refer to  C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_usb. Note this is an application example for TM4C129 device. This example jumps to the ROM bootloader rather than flash bootloader. But you can easily port to TM4C123 and modify for flash-based bootloader. In this boot_demo_usb application, it becomes a composite USB device supporting a mouse via the Human Interface Device class and also publishing runtime Device Firmware Upgrade (DFU) capability.

  • 0 in reply to Charles Tsai
    Prodigy 205 points

    Thank you Charles!