Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: Cannot get Lockable Teensy 4 to pass tests and lock

  1. #1

    Cannot get Lockable Teensy 4 to pass tests and lock

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

    Code:
    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
    Code:
    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

  2. #2
    Senior Member+ mjs513's Avatar
    Join Date
    Jul 2014
    Location
    New York
    Posts
    8,134
    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.

  3. #3
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,214
    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.

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

  5. #5
    Junior Member
    Join Date
    Nov 2021
    Posts
    8
    I am getting this response using Teensyduino 1.56 and Teensy loader 1.56 on a Teensy 4.1:

    Code:
    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.

  6. #6
    Senior Member+ defragster's Avatar
    Join Date
    Feb 2015
    Posts
    15,866
    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.

  7. #7
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,214
    Quote Originally Posted by tompilot View Post
    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.

  8. #8
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    26,214
    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.

  9. #9
    Junior Member
    Join Date
    Nov 2021
    Posts
    8
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •