Prevent internal ROM code from being read in imxRT1064

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Prevent internal ROM code from being read in imxRT1064

863 Views
Davidino
Contributor IV

Goodmorning,

I write you since we're close to move from development to production phase with iMXRT1064 processor. For information we are not going to encrypt or sign the image, we want to load it as it is.

But in order to protect code, we want to prevent anyone from reading its content via JTAG or via USB (using for example NXP Boot Utility).

I have some questions:

  1. Is this approach correct and safe?
  2. Is it correct to state that following https://www.nxp.com/docs/en/application-note/AN12419.pdf, I can set the JTAG in secured mode so that a secret response key is needed for connecting/reading/writing/debugging to the processor?
  3. Concerning the serial mode, if I burn eFuses SDP_READ_DISABLE does it prevent from reading the internal flash memory?  Or it only concerns SOME/ALL eFuses?
  4. There are many eFuses that needs to be locked to become permanent. If they aren't, can they still be write back to 0?

Thank you.

Best Regards,

Davidino

0 Kudos
1 Reply

841 Views
mjbcswitzerland
Specialist V

Hi Davidino

Since the QSPI flash is inside the package it is not possible to access it via external pins and so storing unencrypted code is still very save (in comparison to when in external QSPI flash, which could be read very simply) but is is not completely safe against access - i understand one technique is to grind away the package until internal access points can be made, but the majority of those with an interest in obtaining code stored within would probably already decide not to bother trying. But there may still be someone with the right equipment and experience who will potentially be able to do it. Whether the protection is adequate must be decided by yourself.

Even when using on-the-fly decryption this can be simply bypassed if JTAG or SWD is possible since the debugger will 'see' the decrypted (plain-code) and so can do a dump of the decrypted content and this make the on-the-fly decryption mechanism completely worthless. Therefore it is imperative to disable JTAG/SWD to avoid this simple access path. It can be completely disabled (one-shot that can not be reversed) if you know that the delivered boards will not need to be debugged. If your debugger supports the encrypted debugging mechanism you can also set the JTAG interface to this mode and it will then only work with debuggers supporting the method and with the correct secret keys.

Programming eFUSES means changing bits from '0' to '1'. Once set they can NEVER be reset again.

Also the ISP allows code to be read back (if on-the-fly decryption enabled it will read back the encrypted content which is protected, if not it will read back the plain code). This means that you need to also disable ISP completely or at least setting that allows the read-back.
When the code is stored encrypted the read-back of the key register has to be disabled or else the AES128 key is visible, which allows simple decryption back to plain code.
In your case you may need to test what eFUSEs work best - possibly it will not be necessary to completely disable ISP but beware that ISP allows programs to be written to RAM where they can execute and dump flash content (encrypted or non-encrypted) to an interface, which would work around security - even on-the-fly decryption security - if not blocked.

Regards

Mark

0 Kudos