• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 101 subscribers
  • Views 1114 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

C6748 secure secondary bootloader

ReinierC
Expert 2425 points
Other Parts Discussed in Thread: OMAPL138

Good day experts,

My question is with regards to creating a secure secondary bootloader for the secure version of the C6748 DSP.

I have a pretty good understanding of the whole binding process with a secure C6748, i.e. the user selects the CEK (with which the application image is encrypted), puts it in an unencrypted software header, gives it to the secure kernel, which then encrypts it with the KEK (unique to every secure C6748 and unknown to the outside world). At boot time, the secure kernel then decrypts the software header with the KEK, extracts the user defined CEK and uses it to decrypt the application and then boots the application. In this process neither the KEK nor the CEK is revealed and this therefore binds the application to a specific secure C6748 for as long as the CEK is not revealed through some other channel.

However, for a secondary bootloader this process is less clear to me. I need to use the secondary bootloader to boot the main application. I can bind the secondary bootloader application to a specific secure C6748 using the process described above, but how do I bind the actual main application to a specific secure C6748? 

I can't simply embed a chosen main application CEK in the secondary bootloader, since it will be revealed in RAM when the secondary bootloader has booted.

Is it possible to encrypt both the secondary bootloader and the main application image with the same CEK and then use the secure kernel APIs from the secondary bootloader to decrypt the main application image?

Your advice would be greatly appreciated!

  • 0
    TI__Guru** 116020 points

    Hi Reinier,

    Your correct you can`t embed the CEK value into the secondary bootloader as it will be revealed in the RAM when the secondary bootloader is loaded in the RAM.But you can use the CEK in the software header to encrypt your main application. During the process of booting, if you can exit in secure mode, you can read the KEK encrypted CEK value from the software header (present in flash) and use the KEK to obtain the CEK in your secondary bootloader and decrypt your main application using the CEK.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Expert 2425 points

    Hi Rahul,

    This is news to me! Do I understand you correctly that it is somehow possible to output the unique factory programmed KEK of a secure C6748? Is the cornerstone of the security mechanism not that the KEK is never exposed to the developer?

    What would prevent an attacker in the field to simply take over the device and somehow get the device into Secure Supervisor mode and force it to provide the KEK?

  • 0 in reply to ReinierC
    TI__Guru** 116020 points

    Hi Reinier,

    Your correct the KEK value can`t be outputted as the device is in secure state with only secure supervisor privileges to access the KEK. I have modified my earlier response to reflect the strategy you can employ. You will essentially perform secure loading operations similar to that performed by the ROM code where in you obtain the value of the CEK from the software header by decrypting it using KEK in secure state. Then use the CEK value to authenticate and decrypt the main application binary and have loader to load the sections in appropriate location in memory.

    This is a non-trivial effort so I would recommend it may be best if you have a single secure stage boot instead of multi-stage so that the ROM can handle the entire application boot process.


    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Expert 2425 points

    Hi Rahul,

    Thank you for the clarification, I agree a secondary bootloader will be cumbersome.

    I also have a further question: do the C6748 secure kernel APIs provide some mechanism to secure off-chip RAM, i.e. encrypt a piece of RAM with the device specific KEK and all reads and writes to this memory have to go through the secure kernel? 

  • 0 in reply to ReinierC
    TI__Guru** 116020 points

    Hi Reinier,

    The secure kernel APIs allow you to encrypt/decrypt a block of data  that can be either a user defined array or read from memory. Reading the KEK would require the user program to be in secure supervisor state. The memory can be protected using memory protection registers so that you allow access only in secure state with supervisor privileges so if non-secure user code tries to access this code, it would cause an exception.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Expert 2425 points

    Hi Rahul,

    Thank you for the info.

    Would this be possible during the normal execution of an application?

    Can you perhaps please provide me with some example code?

  • 0 in reply to ReinierC
    TI__Guru** 116020 points

    On generic secure C6748 parts, we support only secure boot and don`t generally recommend use of run time security so we don`t have an ready to go example for this entire process. We do have an example that demonstrates decryption of block of data after exiting boot and also an example that demonstrates how binding can be done using secondary bootloader which I may have already shared with you in the past.  Can you please confirm that you have those examples.

    In your usecase, you will need to exit the boot process in secure mode, decrypt your application and then transition to non-secure state before running your application.

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Expert 2425 points

    Rahul,

    Yes, I do believe I have the examples that you are referring to.

    Can you please provide me with the main reasons for not recommending run-time security?

    Secondly, if you transition from the secure to the non-secure state, would the application be able to still access the secure area of the RAM. As I mentioned before, I am looking to secure an area of RAM for run-time usage to store various sensitive information, i.e. this area of remains encrypted in RAM, and reads and writes from and to this area should be decrypted and encrypted by means of the KEK.

    If this approach is not feasible, is an additional secure memory chip the only remaining option? 

  • 0 in reply to ReinierC
    TI__Guru** 116020 points

    Hi Reinier,

    The hardware and software provided from the generic secure C6748/ OMAPL138 device provide limited run time security features. The device doesn`t support all the runtime security APIs of secure kernels , no Trustzone support, Limited IO and memory protection features. Hence we don`t recommend implementing run-time secuirty on these device unless you have a scheme you can come with that utilizes these limited features to satidfy your security needs.

    No after you migrate from secure to non-secure state, you wont have access to secure RAM as you can access it only when you are in secure state. Access to that region will cause a security exception.


    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Expert 1090 points

    Rahul,

    You mention about "example that demonstrates decryption of block of data after exiting boot and also an example that demonstrates how binding can be done using secondary bootloader".  Can I get these example? Thank you.

    Regards,

    Kevin

  • 0 in reply to Kevin Chen9
    TI__Guru** 116020 points

    Hi Kevin,

    I have sent you the examples that youhad requested.

    Regards,

    Rahul