Cannot get Lockable Teensy 4 to pass tests and lock

[donperryjm]

Step 1. Generate Key - Done
Step 2 Fuse write sketch gave me this response:

Writing public key hash
Okay: public key hash is good :-)

Decryption key was previously written & locked, so
it can not be directly verified, but the following
test will confirm whether decryption works.


Testing Bus Encryption Engine
Success: ciphertext decryption test passed :-)

Notice: JTAG is still enabled

Notice: Secure mode is not yet set, unencrypted
        programs are still allowed to run

Not sure what that means but on to step 3

AT this point i tried to load my own EHEX file into teensy loader and hit upload. THen I did this:

Step 3: Verify Sketch

Verify secure code is running properly

Fail: Bus Encryption Engine is not active
Fail: Encryption region starts at wrong address
Fail: Program data is not within encrypted region
Fail: title_function() is not in encrypted region

[mjs513]

A little confused.

In your Step 2 it says that the T4 you are using already has a key that was previously written:

Decryption key was previously written & locked, so
it can not be directly verified, but the following
test will confirm whether decryption works.

So when you go and run the verify sketch with a new key its going to fail because one was already written to the T4.

At least that is my understanding.

[PaulStoffregen]

That result sure looks like your board got programmed with the HEX file, not EHEX.

First, check Teensy Loader version with Help > About in the small Teensy Loader windows. If older than 1.55, quit and let Arduino restart it on your next Verify or Compile. Older versions don't know about EHEX files.

If that doesn't solve everything, use Teensy Loader's Help > Verbose Info. It will tell you more detail about the board it's detecting.

[donperryjm]

All good now. Was using an older version of teensyloader. Not sure how lol.

[tompilot]

I am getting this response using Teensyduino 1.56 and Teensy loader 1.56 on a Teensy 4.1:

Writing public key hash
Okay: public key hash is good :-)

Decryption key was previously written & locked, so
it can not be directly verified, but the following
test will confirm whether decryption works.


Testing Bus Encryption Engine
Error: ciphertext decryption did not match plaintext!
  plain:  48 A7 8E 47
  cipher: 7E B0 87 89
  dcrypt: 7E B0 87 89

Error: JTAG can not be disabled

Error: Secure mode can not be set

Teensy ends up in the "fast blinking" mode.

A few days ago i generated my own key.pem, successfully did fuseWrite to three brand new Teensy 4.1 boards and could also successfully verify the sketch. My Teensys are non-lockable. I can also upload and run my generated .ehex firmwares to these three boards.
Today, i tried to fuseWrite the key to some other Teensy 4.1 boards (same batch of Teensys, also brand new) but it failed as shown above. I did NOT generate another key, the same key as before was used (/Users/myusername/Documents/Arduino/key.pem).
Any idea why this might happen?

Using OSX 12.0.1 Monterey on Apple M1.

[defragster]

Was this generated from an unaltered 'Secure Teensy' section provided sketch.INO?

Paul will have any real answer - but just notes on what the text says as read ...

Not sure what 'Writing public key hash' entails? Is that suggesting bootloader would have seen it as valid and matching? Open Loader 'Verbose' and capture the upload messages.

Assuming this text is correct: "Decryption key was previously written & locked, so"
> The T_4.1 was 'previously' locked.

But suggests that sketch was built with a different encryption key in use.

Or perhaps Key #1 was overwritten with Key #2 resulting in jumbled combo key bits - but the 'latest' Secure Sketches as written work to prevent that.

Confirm the IDE's 'sketchbook' path with the expected key.pem is being used on the machine building the .eHex.

[PaulStoffregen]

Today, i tried to fuseWrite the key to some other Teensy 4.1 boards (same batch of Teensys, also brand new) but it failed as shown above....
Any idea why this might happen?

Best guess is an old Teensy 4.1, manufactured before about June 2021. You said "also brand new", but does that mean recently purchased, or could these be older boards which simply haven't been opened?

This is explained on the code security page under "Bus Encryption Engine on Standard Teensy"

https://www.pjrc.com/teensy/td_code_security.html

Lockable Teensy's secure mode is required to securely protect your code.

Standard Teensy 4.0 & 4.1 manufactured before June 2021, and all MicroMod Teensy can not use the key in fuse memory for code decryption. If you run the fuse write sketch, the encryption test will fail when the Bus Encryption Engine (BEE) is turned on.

Newer Standard Teensy 4.0 & 4.1 have configuration where the Bus Encryption Engine can decrypt code. But encryption alone without secure mode is not secure. JTAG remains enabled, and HAB authentication is not required. Use of encryption for code without secure mode is like locking your door but leaving a window wide open. Teensy Loader is not able to detect the capability of standard Teensy 4.0 or 4.1 boards, so it will not upload the EHEX file, even to the newer boards which are capable of running EHEX files. As a workaround, you can delete the HEX file and rename the EHEX file to HEX. But remember, running EHEX this way is not secure!

Only Lockable Teensy provides strong code security, and only when secure mode has been permanently locked. Uploading code from Arduino to Lockable Teensy still works as with Standard Teensy, as long as you have the correct key.pem.

Basically, before code security support started back in June 2021, all Teensy 4 boards shipped with a fuse setting that didn't allow the Bus Encryption Engine to work. From only the info I can see so far, my best guess is may be using one of those earlier boards.

[PaulStoffregen]

But perhaps that page has slightly outdated info "Teensy Loader is not able to detect the capability of standard Teensy 4.0 or 4.1 boards". More precisely, it can't detect the security capability of boards with bootloader version 1.05. But Teensy Loader 1.56 (which didn't exist when those words were written) will upgrade any 1.05 board to 1.07. When it encounters boards with bootloader 1.07, it can detect security state.

However, that still doesn't help the Bus Encryption Engine test to pass on older boards. The fuse config is permanent.

And no matter what is done, boards which aren't locked into secure mode are never considered secure, no matter what you do with encryption. As the documentation says, using encryption without secure mode is the equivalent of locking your door but leaving a window open.

You only get good security with Lockable Teensy, and only after the final step to permanently lock secure mode.

[tompilot]

Thank you both for your quick response!
In the meantime, it turned out that something with my existing PlatformIO installation collided: PlatformIO also opens an instance of TeensyLoader for programming, and for some reason the version of that TeensyLoader was 1.55 instead of 1.56 which i did not notice before.
In parallel to PlatformIO, i also had Teensyduino 1.56 open, but which used the same instance of TeensyLoader 1.55 that was previously opened by platformIO. This is what produced the error message from my post above.

--> Closing PlatformIO, closing TeensyLoader 1.55 and letting Teensyduino open TeensyLoader 1.56 solved the problem.

The good news is that i did not "waste" any Teensy boards with miswritten fuses, i could upload my key to all testboards and can run my encrypted firmware now.
Anyways, it appears that Teensyduino does not check if the version of TeensyLoader is the same.

@Paul FYI: I purchased 105 Teensy 4.1 boards directly from you (PJRC) in September 2021, it says batch Code 26289 on the plastic bag. So these are probably post-June 2021, as encryption works on them. And yes, the bootloader gets an update when flashing the FuseWrite sketch on a "brand new" (= pull out of the bag) Teensy 4.1. Uploading FuseWrite with TeensyLoader 1.55 does not update the bootloader.

[ted]

Hello,

Can you please help us out how what we are doing wrong?

Please find attached the picture.

Also we are not sure if we have a teensy 4.1 with lock or not? How can we check that?





Ted

[PaulStoffregen]

"Error: Secure mode can not be set" means you have standard Teensy.

Aside from this error message, here are a few ways you can tell which Teensy type you have.

1: The printing on the anti-static bag is different, white on standard, black for lockable.



2: The lockable boards have this stamp on the main chip.



3: In Teensy Loader, Help > Verbose Info shows which type of hardware is detected.

03:11:25.611 (loader): secure mode can not be locked: this is Standard Teensy

03:13:24.516 (loader): secure mode is locked: this is Lockable Teensy

For lockable Teensy which in original condition (3rd step not yet run to permanently lock secure mode) you will see "secure mode is not yet locked, but can be locked: this is Lockable Teensy".

[ted]

Hello Paul,

Thank you for your quick response.

I understand now how to identify which version it is.

But I am a bit confused now.

Are there any hardware chip differences? Eg needs a different RT1062? or it has an other kind of bootloader?
I am asking because we would like to make our own pcb.
Do we have to order other type of bootloader with lock function?

On you site all you write is:
"Secure mode may be used with IC_MKL02Z32_T4_QFN16 sold starting November 1, 2021."

Also on your site we can order one type. So this one is already with lock?
https://www.pjrc.com/store/ic_mkl02_t4.html

Thanks!

Ted

[BriComp]

I believe Locked Teensy T4.1s are only available BUILT from PJRC.

[defragster]

Production Teensy 4.x's ship with fuses locked that ensure long happy unbricked life.

The 1062 MCU is the same Production or Locked, the diff is the Fuse settings.

Looking at the ic_mkl02_t4.html link text it seems a DIY chip initializes a 1062 MCU without setting or locking bits leaving it open to being made lockable - except those needed to put Bootloader chip in control and applying a Ser#.

With that DIY ic_mkl02_t4 and a fresh 1062 MCU it can be made Lockable or not depending on the use of the Teensy Security sketch and end user process.

[PaulStoffregen]

If you build your own PCB using the T4 bootloader chip, it will work as lockable Teensy.

If you want your custom board to work as standard Teensy, do not run the LockSecureMode sketch, and run the small program shown on the T4 bootloader page under "Disabling Boot Configuration Changes".

[ted]

great, thank you for the informations.