Teensy 4.0 code security?

PaulStoffregen said:
I'm planning to make it rename the file(s) for your previously created key(s), so nothing ever gets overwritten. But if you click it many times, you'll end up with many key files! Only the one named "key.pem" actually gets used.

In future versions I might support other (better?) ways to manage keys. Optional password protection is high on the list of missing features. But keeping it simple for now.
Click to expand...

Excellent, thanks !!

Mark J Culross
KD5RXT
 
Will visual micro be compatible with all this? Would I just need to create the keys from the arduino tool and then work as normal?
 
Unless Visual Micro is implementing all of the small details of Arduino's 3rd party hardware spec regarding platform.txt, it will probably need an update. Likewise for PlatformIO and other systems.

The good news is the encrypt step is done with a simple command line program (no Arduino IDE needed), so they should be able to pretty easily add it to their build process. They probably won't make that sort of change until 1.55 is officially release.

When I publish 1.55-beta1, you can do it too. Just grab the new "teensy_secure" program and create a script or other way to run it as you like. Like all Arduino stuff, you can see how Arduino runs it by turning on verbose output in File > Preferences. If you run it without any args, it'll print usage info. All you need to get the .ehex file is that utility, your key.pem file, and the .hex file you want to encrypt.

But you can't just encrypt any arbitrary .hex file. It must conform the conventions Teensyduino uses on Teensy 4.x, including the 1K memory align which 1.54 added, and a linker script bug fix I recently committed. The .hex file must have the "csf" placeholder at the end. That's where the digital signature is written.
 
PaulStoffregen said:
This could be done, but probably won't be added anytime soon.
Click to expand...
Well, I guess one has not to use encryption.
To summarize,
at the moment, there is no way to know which program is on Teensy. (e.g. one that has been programmed 2 years ago)
in future, when encrypting code, we will not know which key was used to encrypt the program (pressing generate key twice is too easy)

OK, we all should document all actions in order to professionals, but I was hoping that modern SW development would help.
So back to last century manual logs.
 
You're making wrong assumptions about how it (doesn't) work. I did build in a mechanism for Teensy Loader to verify the public key hashes match before erasing the old code and loading the new .ehex data. This work has taken months because it is designed to carefully check for errors and try to handle wrong usage gracefully.

I'm not promising every aspect of the user experience will be seamless. We are starting this as a beta test afterall.

But on the matter of knowing which program is stored in Teensy's flash memory, that part is on you. If you want to be able to later check, it's your responsibility to give your code some sort of distinctive behavior.
 
PaulStoffregen said:
You're making wrong assumptions about how it (doesn't) work.

....

But on the matter of knowing which program is stored in Teensy's flash memory, that part is on you. If you want to be able to later check, it's your responsibility to give your code some sort of distinctive behavior.
Click to expand...
Noted and no objections

Edit: as the Teensy loader has all information (serial number and program name), I will see if I can modify cli loader to log the information (date, time, program, teensy type, teensy ser number) of every upload
 
Last edited:
Is the security enforced at the JTAG (program) level, or at the boot (runtime) level? I'm wondering if updates could still be done via SD card or via the OTA "Flasher", so long as the ".ehex" file had been built with the correct encryption key.
 
The final secure lock step (which can't be done on standard Teensy, only possible on the upcoming lockable model) permanently disables JTAG and permanently enforces requirement for encrypted code at boot.

You can still write to flash while your program runs. But if the flash doesn't contain a complete properly encrypted program when you power cycle or soft reboot, the chip will run from NXP's ROM and will refuse to boot your program.
 
Teensyduino 1.55-beta1 is now available.

https://forum.pjrc.com/threads/67989-Teensyduino-1-55-Beta-1

Even if you don't have one of the lockable hardware beta boards, you can still run it, generate a key and compile to get .EHEX files... and just generally see how it will work.

Again, if the beta test is looking good after a few weeks, we'll probably open the beta hardware up to more people. Contact me directly in the first or second week of September if you want to be able to order a few lockable boards to join in the beta test.
 
I'm confused. Is this a Dice (Riot) design? (root-of-trust bootloader, shared secret, double hash, "signs/authorizes the update" sorta thing)? Or is this a "root-of-trust bootloader, symmetric key, hex is encrypted, flash image is stored encrypted and decrypts to ram, executes from ram, only updates or runs if the hex decrypts correctly sorta thing?
 
I sucessfully run all 3 steps to secure the Teensy and it worked without issues so far. The steps are easy to follow quite self explantory and work very well. So from my point of view Paul did really great stuff.
 
PaulStoffregen said:
Wow, so many cryptography phrases tightly packed into a question... which I don't really understand.
Click to expand...

thought that as well ... and anything you understand may be under NDA for details ...

In general though it seems the last part described it for the most part - not sure of symmetric key - but everything in HEX for program and data is placed encrypted in flash, and the device has the needed key stored internally and is not readable.

On power up code and data can come to RAM as it is decrypted - some CODE and DATA will remain in FLASH and be decrypted on reference.
 
I am planning to begin documentation soon. Please keep in mind we only just started beta testing yesterday.

Regarding the questions in msg #112, we are using a subset of the chip's security features. NXP's reference manual has a high-level summary of all the features in chapter 7 on pages 175-184.

For code security, we using HAB (pages 177-180) which checks a signature appended to program, and the Bus Encryption Engine (page 184) which provides on-the-fly AES-128-CTR decryption.

Regarding the questions about trust, the mechanism is a hash of your public key gets burned into the chip's fuse memory. This is the specific info from page 180:

screenshot.png

When the signature is verified, its public key is checked against this hash stored in the fuses. HAB decides whether to trust the identity of the public key used to sign the firmware based on whether it matches that hash stored in the fuse memory.

You'll see PKI and X509 certs are mentioned on this list. While they are present, at least as we're implementing security on Teensy, that PKI stuff is effectively unused.
 
Thanks for the reply. For reference, many industry people start with the "NIST standard" - NIST Special Publication 800-193. Lot's of jargon, all centered around the idea of a "root of trust", some part of the system you know is safe. NIST doesn't give a solution, it just has the requirements of a solution. Lately, a IoT project called RIoT created a NIST-compliant design. It's now called DICE. (https://www.microsoft.com/en-us/research/project/dice-device-identifier-composition-engine/)
NIST and Commercial National Security Algorithm Suite (CNSS) show AES 128 as deprecated (AES 256 is considered the norm now). SHA2 SHA-256 and less are deprecated, SHA-384 is now the minimum.
This can be a fairly deep rabbit hole.
 
Documentation is now available on the website.

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

You may wish to scroll to the "Encryption Details" section.


DeweyOxberger said:
.... all centered around the idea of a "root of trust", some part of the system you know is safe. .... It's now called DICE. (https://www.microsoft.com/en-us/research/project/dice-device-identifier-composition-engine/)
Click to expand...

How NXP's hardware fuse memory manages the "Unique Device Secret" is a topic covered in their security reference manual, which NXP only makes available under non-disclosure agreement. I really can't comment on those sorts of details which might pertain to the DICE "power-on latch" or similar hardware mechanisms.

But I will say I've never seen any reference to "riot" or "dice" in any of NXP's documentation. As far as I know, there is no provision for the "Cryptographic One-Way Functions" or "Tying Key Derivation to Software Identity" mechanisms of using derived keys.


NIST and Commercial National Security Algorithm Suite (CNSS) show AES 128 as deprecated (AES 256 is considered the norm now). SHA2 SHA-256 and less are deprecated, SHA-384 is now the minimum.
Click to expand...

The practical reality is we must use the cipher NXP's hardware Bus Encryption Engine supports, which is exclusively AES-128-CTR.

Likewise for authentication, NXP's High Assurance Boot (HAB) pretty much dictates design choices for code signing and establishing trust.


This can be a fairly deep rabbit hole.
Click to expand...

Yes, indeed.

But again, I want to emphasize that nearly all the cryptographic design choices are not up for debate. The silicon is fixed and we have to use the features NXP implemented in the hardware.
 
Last edited:
@PaulStoffregen:

As a thought experiment, I'm wondering if the following would be possible:

1) Elsewhere (security document/description) it is covered that the key fuses start at '0' & are programmed to '1'
2) You have a locked Teensy which has the originator's key hash programmed into it, which ensures that only updates from the originator can be loaded
3) Could you "reprogram" the key bits so that all key fuses are set to '1'
4) With this key hash of all 1's programmed into the previously locked Teensy, could you now load your own code that has been signed with a key that has a hash of all 1's (such a key may take some time to generate/find, but should be theoretically possible) ??

Mark J Culross
KD5RXT
 
kd5rxt-mark said:
3) Could you "reprogram" the key bits so that all key fuses are set to '1'
Click to expand...

Nope. Once secure mode is locked, only code signed by the proper key can be run. To write to any fuses, you would need the program which performs those write to be signed by the original key.

Once written and locked, AES128 key bits can't be altered, even by an authorized program. But an authorized program might be able to write to the public key hash bits (causing the chip to never boot up again).


4) With this key hash of all 1's programmed into the previously locked Teensy, could you now load your own code that has been signed with a key that has a hash of all 1's (such a key may take some time to generate/find, but should be theoretically possible) ??
Click to expand...

I'm pretty sure this also isn't feasible. I believe this is called a preimage attack, where you seek to find any input data which gives a particular hash output. But not just any input bytes will do, it must be a byte stream of the proper length and format to be used as a RSA-2048 public key, so it's probably much harder than the definition of a preimage attack, where data of any arbitrary length & format is considered a success.

But if you could perform such a preimage attack against SHA256, you probably wouldn't need to bother with changing any fuse bits. You would just find a byte stream (suitable as a RSA public key) which gives the same hash has the original public key rather than searching for data which gives an all-1s hash.
 
@PaulStoffregen:

OK, thanks for the clarification of your reply. I understand that I missed at least one key point: writing the key bits on a locked Teensy has to be done by a program signed with the current key.

Mark J Culross
KD5RXT
 
PaulStoffregen said:
But an authorized program might be able to write to the public key hash bits (causing the chip to never boot up again).
Click to expand...

I believe there is a lock bit for the SRK hash also, that when burnt doesn't allow to change any single bit of the SRK hash. The reason I believe that is that all the IMX processors have the rather same layout of the fuse memory and within the iMX6's SRM this fuse is documented while in the iMXRT SRM this fuse is marked as reserved. And I do not believe that NXP did subtantial changes to the HAB related fuse mechanism, so that most propably this fuse is also active on the iMXRT wit the same function.
 
Starting today, we're making lockable beta test boards available to more people. These are not the original beta. It is a release candidate with all previously discovered issues fixed.

If you'd like to get some of these boards, please email me directly and I'll send you a special link to order some.

We're targeting a full release later in November. If you'd prefer to wait for a final release which isn't called "beta", it should be only a couple more weeks.
 
You must log in or register to reply here.
Back
Top