Teensy 3.6 firmware cloning protection

[asder]

Greetings to all!
I have bought a Teensy 3.6, and I am concerned about an attacker reading data/firmware from flash, EEPROM and RAM.
I have been searching on the forum for instructions about how to block reading from T3.6 flash, eeprom and RAM once programmed.
I have read https://forum.pjrc.com/threads/35333-Setting-flash-security-byte
but I think it doesn't apply to T3.6, as the processor is different from T3.2

I have some questions:
1) Does that apply for T3.6? Are there any differences?
2) What else can be locked with the T3.6 bootloader? And how?
3) If an attacker desolders the processor, can s/he read from it? How can we prevent this with locking bytes?

Thank you for your time!

 

[GremlinWrangler]

There are several layers here and not an expert on the features listed but:

As configured by default there is no way to use the USB port to extract code unless you added software to do so in the first place, but JTAG port does given it allows debug functions
The Teensyduino attempts to block security settings that will brick the board, since that produces customer service problems so JTAG has to be available
The linked thread is still relevant when it comes to hacking the file to allow actually setting the values you are interested in - make sure you do not use your only prototype to test this with since you will probably brick something getting this right.
To look at the actual features you want the reference manual https://www.pjrc.com/teensy/datasheets.html and searching 'flash security'
The bootloader itself does not lock anything, since it is resident in a secondary chip connected via JTAG and has it's own security to protect PJRC from cloners

The measure you are trying to defeat is someone removing the bootloader, getting into the JTAG port (otherwise physically blocked by the bootloader IC) and using the debug features to extract flash contents or just debug your code
So you would be looking at those flash security bits with view of what security you actually want. The full measure is to lock everything so that JTAG is disabled. Doing this means that the chip is bricked, you can never program it again unless you include user code yourself to trigger some sort of backdoor. Which may be a route you want to take as long as your customers do not expect updates. More normally the bits are set to prevent readback of data via JTAG and to force a full wipe before loading more code, to prevent a mini reverse bootloader being put in that unset the lock bits or just dump the flash out via coms port. This does not prevent someone overwriting your product but will prevent the code being pulled but you can also do updates yourself even of things go badly wrong.

What none of this will prevent is the chip being de-caped and the flash contents read directly, only a limited number of chips include measures to block this sort of attack since it is very expensive to execute, but if your threat model includes state security agencies or multinationals then maybe you need to look at that.

If you do change the Teensyduino values to allow setting the lock bits, make sure your software testing steps for updates includes checking that you are not bricking customer devices which gets expensive fast.

 

[asder]

Thank you a lot! Guess I need to make some tries/errors, as there is no way already documented for 3.6.