Support for zeroizable master key in SNVS on Teensy 4.x

[ckahlo]

Hi there,

we're using the Teensy 4.x on research rockets such as on MAPHEUS 9 - 13 to control experiments and acquire data.
Our last mission was on May 22th, 2023: https://sscspace.com/successful-laun...vity-research/

As we're also doing research for life support systems we're using secure embedded sensor networks. I published a
first example for the laboratory desktop evaluation here: https://github.com/ckahlo/seccid

Additionally we integrated post quantum cryptography for key exchange and secure telemetry this time.

To make a meaningful use out of the security features of the RT 1062 we would like to use the zeroizable master key
(ZMK) inside the SNVS unit to store a masterkey that's generated during PQC key exchange. This master-key then is
used to create sub-keys for sensor networks and secure telemetry. The ZMK has the benefit that it gets deleted (all
zeroed) when tamper detection is triggered or RTC power is lost. So data exchanged before and stored to the SD card
stays secure even if the payload once cannot be recovered.

The use of ZMK is well described in platform/drivers/snvs/fsl_snvs.* and fsl_dcp.* of MCUXpresso SDK and other
places. Detailed links to be added in this thread later - especially checking licensing and non-NDA availability.

To accomplish this a small change in the teensy_secure application is needed to add a DCD instruction allowing the
created application image to write to the ZMK registers.

Thanks and best greetings from ESRANGE,
Christian

[al1c3]

Hi,

I would also greatly appreciate that change and have successfully tried it by patching the binary teensy_secure. It would also be of some benefit, if also the teensy binary would contain the same code for the DCD. I wrote a java version of the teensy_secure which is able to accomplish those things, but makes everything a bit complicated, especially the automatic mode (you have to close the serial port console for sending the reset to bootloader).

Best wishes,
Alice

[PaulStoffregen]

To accomplish this a small change in the teensy_secure application is needed to add a DCD instruction allowing the created application image to write to the ZMK registers.

My best guess is you're asking for teensy_secure to give an optional command line parameter which generate CSF data with the same output as NXP's Code-Signing Tool would if given the "[Unlock]" command with "Engine = SNVS" and "Features = ZMK_WRITE"?

Or maybe I've misunderstood?

[al1c3]

This and maybe also the LP_SWR flag. The hex values are in the cst API docs. Would be really great.

Best wishes,
Alice

[PaulStoffregen]

The hex values are in the cst API docs

Please be more specific. At the very least, show a screenshot similar to msg #3. If your screenshot doesn't have footer, please say which page number and the version of the document (ideally use 3.3.1).

[al1c3]

Hi again,

the following parts of HAB4_API.pdf from docs folder show the right values and how to use them.





The correct Bytes for the unlock command should be:

B2 00 08 1E 00 00 00 03

B2 is for unlock
0008 is total command length (including header and length bytes)
1E means SNVS
00 00 00 03 means bit1 (LP_SWR - Software reset allowed by LP) and bit2 (ZMK_WRITE - Allow writing Zeroizable Master Key)

Best wishes,
Alice

[PaulStoffregen]

Which operating system are you using? Or in other words, if I were to compile a test copy of teensy_secure, which platform should it be for easiest testing?

[al1c3]

I was using Windows x64, but I guess Linux x64 will be as useful as Windows.

[PaulStoffregen]

Here is a teensy_secure build for Windows. So far this is untested. Please let me know if it works for you?

Usage: teensy_secure encrypthex <board> <file.hex> [key.pem]
       teensy_secure encrypthex_unlocksnvs <board> <file.hex> [key.pem]
       teensy_secure fuseino <key.pem>
       teensy_secure testdataino <key.pem>
       teensy_secure verifyino <key.pem>
       teensy_secure lockino <key.pem>
       teensy_secure keygen <key.pem>
       teensy_secure keycheck <key.pem>

[al1c3]

It looks very good

Only thing that gets me wondering is the much faster upload speed than my java tool.

Also: Because teensy.exe ignores the ehex if you chose upload from arduino and has the ehex creation code itself, would it be possible to make use of this somehow even using the automatic workflow?

[PaulStoffregen]

It looks very good

Glad it's working for you.

@ckahlo - Any feedback on the program from msg #9? Does it meet your needs?

Also: Because teensy.exe ignores the ehex if you chose upload from arduino and has the ehex creation code itself...

Teensy Loader does not have the ability to create .ehex files. Only teensy_secure can.

Teensy Loader does notice if you also have .ehex in the same folder when you open .hex. It will automatically use the .ehex file rather than the .hex file if a set of compatibility tests are passed. This automatic choice is the backbone of how upload from Arduino works. Teensy Loader is always told about the .hex file. But if the build process also created .ehex, and the compatibility tests show it should work with the Teensy board connected to Teensy Loader, then the .ehex file is used instead.

[al1c3]

It was some versions ago, but I definitely tried replacing the original teensy_secure by my confirmed working patched teensy_secure and then upload code using Arduino IDE. I found out, the manually generated ehex had the correct csf, while the one uploaded had not. I guess it was on 1.57.2. if I dropped the ehex into the teensy.exe manually, it worked fine. Also, as far as I remember, I found the bootloader code in the teensy.exe file.

[ckahlo]

@ckahlo - Any feedback on the program from msg #9? Does it meet your needs?

Sorry, I needed a bit more time to test. Works as intended and passes differential tests :-)
Thanks a lot Paul!

Best,
Christian

[PaulStoffregen]

Ok, sounds good. I'll queue this up to go into future Teensyduino releases.