Remove decryption key after boot?

[bennxp]

I'm planning on using secure boot to encrypt my boot image for the i.MX RT 1062 processor. However, I will be executing unencrypted / unsecure code from the sdcard and I'm wondering if it is possible to revoke the decryption key from memory prior running code on the sdcard so I can protect my boot image code. The flow would be:

Boot from encrypted flash (0x6000000)
Run secret_function()
Remove decrpytion key (execute in RAM)
Execute SD CARD code

This way if the SD Card code tried to read from 0x60000000 it would not get the decrypted flash code with the secret_function.

Is this possible? Or is there a better way to protect my boot code when I'm allowing execution (after boot) of untrusted code.

Thanks!

[jeremyzhou]

Hi,
Thank you for your interest in NXP Semiconductor products and for the opportunity to serve you.
According to your reply, after MCU boot from the external flash which contains the encrypted code, load another application code from the SD card to internal RAM prior to jumping to this application code, isn't my understand right?
If yes, it's possible actually.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bennxp]

Yes, you are exactly correct on what I want to do. I would boot off the encrypted flash and that code would read the (unencrypted) code off the sdcard, copy it to memory and then execute it. Since the sdcard's code is not encrypted / trusted, I'm wondering if there is a way to prevent it from accessing the decrypted binary data on the encrypted flash chip. 

You said that is possible, how do I go about doing that? 

Thanks,

Ben

[jeremyzhou]

Hi,
Thanks for your reply.
1) How do I go about doing that?
-- In general, at first, you need to create an unencrypted demo that can read the bin file or other files that contain a code, then copy the code to RAM to execute.
next, set the secure boot for the above-unencrypted demo.
Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[bennxp]

Thanks for the reply. Maybe I'm not understanding correctly, but if I use secure boot to boot my encrypted flash image and in that code, read from the (unencrypted) sdcard, copy the sdcard data to memory and then execute that code from the sdcard, then the code from the sdcard will have the ability to read memory addresses 0x60XXXXXX and have access to the decrypted binary image of the flash. 

Is that not correct? And if it is correct, how can I prevent the sdcard code from reading the unencrypted flash image?

Thanks,

Ben

[mjbcswitzerland]

Ben

You can't stop any code that runs on the processor having access to the decrypted content of the QSPi flash.

The idea is that you don't allow any code to run that you don't know where it is from, whether encrypted or not. That is where authentication comes in and so adding authentication checking before allowing any such code to operate means that you are effectively ensuring that only trusted code can run.

As comparison: if you fully secure code to run in QSPI using on-the-fly decryption but you allow someone to smuggle malware into that code (that is, you don't have full control and knowledge of what it is actually doing) your compete system is just as compromised, even if all of the technical steps are correct.

The fact that you install a second code that can access the content of the first, whether encrypted or not, doesn't compromise as long as you can be absolutely sure that it doesn't do anything that you don't want it to be doing with it. If it is "possible" to load and operate code that you haven't fully under your control you have already lost - so this is where you must close the security hole by never allowing the system to accept executing any code that can't be proven to be from a trusted source and and can't be proven to have not been manipulated.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key

[mjbcswitzerland]

Hi

The key(s) used for security are stored in eFuses that are set as unreadable so no code running on the processor can access them.

Allowing un-trusted code to run on the processor could however allow them to enable the same decryption and thus decrypt secure code content - using the keys - but it still wouldn't actually know the key.

It is best to add authentication to any code that runs in plain code form and not allow it to start if that authentication can't first be verified.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1062.html

- Complete Turn-Key Boot loader concept including XiP on-the-fly decryption, clone protection or AES256 protected RAM execution:
-- Boot Loader concept flow chart: https://www.utasker.com/docs/iMX/Loader.pdf and usage reference https://www.utasker.com/docs/iMX/uTaskerLoader_TestDrive.pdf
-- Serial Loader features: https://www.utasker.com/docs/uTasker/uTaskerSerialLoader.pdf
-- Building the loader with MCUXpresso: https://www.utasker.com/docs/iMX/MCUXpresso.pdf (and video guide https://youtu.be/p_eUGo6GypY ) - the guide document explains how to use with any application (eg. SDK) and to enabling its operation with On-The-Fly decryption in 5 minutes
-- Building the loader with IAR: https://www.utasker.com/docs/iMX/IAR.pdf (and video guide https://youtu.be/XPCwVndP99s )
-- Building the loader with VisualStudio and GCC: https://www.utasker.com/docs/iMX/GCC.pdf (and video guide https://youtu.be/0UzLLSXABK8 )
Video Guide to encrypting NXP SDK examples to run from XiP memory using on-the-fly decryption and uploading with the µTasker loader: https://www.youtube.com/watch?v=5iT7KP691ls&list=PLWKlVb_MqDQEOCnsNOJO8gd3jDCwiyKKe&index=10
Video Guide to encrypting NXP SDK examples to run at optimal speed in internal RAM and uploading with the µTasker loader:
https://www.youtube.com/watch?v=fnfLQ-nbscI&list=PLWKlVb_MqDQEOCnsNOJO8gd3jDCwiyKKe&index=11
Video Guide for Embedded Artist OEM Module for i.MX RT 1062 showing precise secured application operation analysis: https://youtu.be/o7hQbOqhJoc