Thoughts on allowing T4.1 lockable to run ehex but not permanently locking

S

strud

Well-known member
I have a product I want to sell commercially soon andafter some discussion here previously I will distribute the firmware as an ehex.

All seems well and I have the product running an ehex just fine, but I realise that if I do not perform the final locking process it can still run a normal non-encrypted hex file. (correct?).
If this is the case, it might be an option I want to run with since it would allow a customer to run their own code ie normal hex file (assuming I am comfortable with them doing that).
Is anyone elese deploying a product with this option?

Obviously it leave one more open to 'issues' and complaints as running non-vetted code on the product could cause any and all problems......

However that flexibility might be quite attractive to some.

The other option is to fully lock any of the teensy boards I sell and make it an option to buy the board without one ie customer supply their own.

Interested in your thoughts.
 
If it's not locked then it defeats the purpose of using encryption, since they will be able to decrypt your code and redistribute it.
 
Hi jmarsh, is that because the key is kept in the location that is locked off? If so this is of course a big oversight on my part.... :-(
 
Once the 'LOCK' step #2 is taken it requires properly encoded eHex.
In the intermediate state where the KEY is burned in it can run either unencrypted HEX or eHex.

In case that the Teensy can run either - and shipping your eHex won't expose the KEY and a user running their own HEX the KEY cannot determine the KEY as it is not readable IIRC. But issues with production hardware and USER HEX would not be under your control.
 
hi defragster, just to confirm, the key is written to within memory (fuses?) in the main processor prior to locking, so is there any way without going to extreme lengths that the key could be extracted? I understand JTAG is still enabled until the final lock process is undertaken. Is there anyway to read the fuses that contain the key via JTAG?
 
If you distribute unlocked hardware programmed with encrypted code, there are multiple ways an attacker could capture a decrypted copy of your code, without needing your key to do so. Lockable Teensy is only secure when locked.

Capturing your key would be much harder, maybe even impossible. I really can't discuss the details, because NDA with NXP.

But if an attacker already captured all your code, they probably have little interest in your key. It would enable them to create new .ehex files as if they came from you. Maybe that's also a concern. But the most common desire with commercial products is preventing competitors from copying or reverse engineering. If they can extract the code from unlocked hardware, they don't have any need for your key.
 
strud said:
Hi jmarsh, is that because the key is kept in the location that is locked off? If so this is of course a big oversight on my part.... :-(
Click to expand...
I'm not completely sure if the key is inaccessible, but (similar to what Paul said) even if it's hidden they could still run their own code on the device to use it as an oracle to decrypt your program - because the key is there, the device can use it but just won't disclose it. Then they can modify and/or redistribute your program (in unencrypted form) as much as they like.

There's some vague mention in the reference manuals about tamper detection and the MCU being able to wipe the key if tampering is detected, but I'm not sure of the implementation details.
 
jmarsh said:
to wipe the key if tampering is detected
Click to expand...

That feature is definitely not supported.

The way it would work, if we supported it, is your key would be stored in special RAM which requires continuous power from VBAT. If the battery dies or becomes disconnected, the key is lost. Likewise if the tamper detection wipes the key. This high risk feature is meant for a pretty niche group of applications where security is of such high priority that you would want the product to self destruct. Think the opening scenes of Mission Impossible. ;)
 
You must log in or register to reply here.
Back
Top