Teensy 4.0 code security?

Hi Paul, today I received the Teensies you promised to send. Thank you very much for it. I did not yet have time to check the fuses, but I will do in the next couple of days. I will keep you updated about the HAB topic.
 
Hi Paul, today I received the Teensies you promised to send. Thank you very much for it. I did not yet have time to check the fuses, but I will do in the next couple of days. I will keep you updated about the HAB topic.

Any progress on this ? Luck with the fuses and leaving them working?
 
Hi all,

I am new to the group, but I also want to migrate to Teensy 4 family.
For some time I am also waiting for the code security on Teenst 4.0 or 4.1.
How is your progress working?
How long would it take you think, we will have the security?
Please give us a feedback...
Thanks..
 
Hi all,
besides a lot for work for my job and spending some time with my family I took some effort to make progress on this but right now with not too much success. Before really getting dirty hands on the fuses, we need a way to reliably reprogram the chip even if security is enabled. The first idea was to get the IMXRT into serial boot mode in order to talk with it by NXPs tools implementing the Serial Download Protocol (SDP). One way to get the IMXRT into serial boot mode is via 2 IO-pads (BOOT_MODE[1:0]) of which 1 is connected to GND and the more important one (BOOT_MODE[0]) is connected to the boot-chip. Unfortunately the boot-chip seams to drive this line always with HI and I don't know if and how this can be changed, so by default the selected boot mode is always "Boot from Fuses".
Another way to get into the serial boot mode is by call to the ROM API, which generally works. Meanwhile I bought a MIMXRT1060-EVK to get somewhat deeper insights using a debugger and running a tiny image calling this ROM API the board runs in serial boot mode. Once in this mode I can command the ROM bootloader to return the contents of some addresses via NXP's SDPHost tool.
Comparing the schematics of the MIMX1060-EVK with the Teenssy 4.0 shows, that the related USB port as well as the UART1 are accessible via the same pads on the teensy (USB-Port is the propagated one and UART1 is accessible via board-pads 24 and 25). Unfortunately I do not get the Teensy 4.0 into the serial boot mode. At least, I do neither see the expected USB device IDs nor am I able to let the SDPHost talk with the ROM bootloader via UART. So I don't know whether there is some intervention by the boot-chip on the Teensy.

Due to those problems I need to take step 2 first which is to implement some boot protocol which lets me update my application even if the HalfKay injected by the boot-chip is no longer working due to enabling security. I already took some effort on this, but didn't make much progress.
If I could get some help with that, we could push this and get to the actual security stuff. The basic concept here is to have a secondary bootloader residing in the first part of the external flash together with the flash config which is rather static and will not change with SW updates. With security enabled, this is the executable image, which will be verified and authenticated by the ROM bootloader by means of High Assurance Boot (HAB). This bootloader in the first version will listen on a dedicated UART for some time waiting to receive a command. If nothing is received during the short time frame it will verify and authenticate application using the ROM API and in case of success execute the application. Via commands sent through the UART one can program a new application image which will reside in another part of the external flash. For the flash erasure and programming it will again make use of the ROM API, which I already verified to work. For sake of security the protocol needs besides the programming commands also commands to authenticate/authorize the user/host tool for writing a new image, but this doesn't need to be implementied in the initial step.
For the protocol to run properly also a host tool is needed, which is what I struggle the most at the moment.

NXP has some implementation of a secondary bootloader in the MCUExpresso SDK which I had a look at to get some inspiration, but the code looked rather complicated with a lot of nested structures containing callback functions and I don't know if it will support some kind of user authentication feature.

So that's the current state here. Any suggestions, questions, ideas to make better progress?

Regards
 
Hi,

i think Paul could send you a T4 board with bootloader removed and without any fuses set.
Would that help? Did you ask him?

I have a Teensy 4.1 here which somehow seems to have the PJRC bootloader disabled. It identfies itself as
"NXP SemiConductors Inc "
"SE Blank RT Family "


I have no idea how that happened - it was in my drawer for some weeks.
Code:
[B]

    =========================== USB Port4 ===========================

Connection Status        : 0x01 (Device is connected)
Port Chain               : 3-4
Properties               : 0x01
 IsUserConnectable       : yes
 PortIsDebugCapable      : no
 PortHasMultiCompanions  : no
 PortConnectorIsTypeC    : no
ConnectionIndex          : 0x04 (Port 4)
CompanionIndex           : 0
 CompanionHubSymLnk      : USB#ROOT_HUB30#5&668d9cd&0&0#{f18a0e88-c30c-11d0-8815-00a0c906bed8}
 CompanionPortNumber     : 0x08 (Port 8)
 -> CompanionPortChain   : 3-8

      ========================== Summary =========================
Vendor ID                : 0x1FC9 ([COLOR=#ff0000]NXP Semiconductors[/COLOR])
Product ID               : 0x0135
USB version              : 2.00
Port maximum Speed       : High-Speed (Companion Port 8 supports SuperSpeed)
Device maximum Speed     : High-Speed
Device Connection Speed  : High-Speed
Self Powered             : yes
Demanded Current         : 100 mA
Used Endpoints           : 2

      ======================== USB Device ========================

        +++++++++++++++++ Device Information ++++++++++++++++++
Device Description       : USB-Eingabegerät
Device Path              : \\?\USB#VID_1FC9&PID_0135#6&2adb531f&0&4#{a5dcbf10-6530-11d2-901f-00c04fb951ed} (GUID_DEVINTERFACE_USB_DEVICE)
Kernel Name              : \Device\USBPDO-7
Device ID                : USB\VID_1FC9&PID_0135\6&2ADB531F&0&4
Hardware IDs             : USB\VID_1FC9&PID_0135&REV_0101 USB\VID_1FC9&PID_0135
Driver KeyName           : {745a17a0-74d3-11d0-b6fe-00a0c90f57da}\0045 (GUID_DEVCLASS_HIDCLASS)
Driver                   : \SystemRoot\System32\drivers\hidusb.sys (Version: 10.0.19041.1  Date: 2019-12-07)
Driver Inf               : C:\WINDOWS\inf\input.inf
Legacy BusType           : PNPBus
Class                    : HIDClass
Class GUID               : {745a17a0-74d3-11d0-b6fe-00a0c90f57da} (GUID_DEVCLASS_HIDCLASS)
Service                  : HidUsb
Enumerator               : USB
Location Info            : Port_#0004.Hub_#0002
Location IDs             : PCIROOT(0)#PCI(0801)#PCI(0003)#USBROOT(0)#USB(4), ACPI(_SB_)#ACPI(PCI0)#ACPI(GP17)#ACPI(XHC0)#ACPI(RHUB)#ACPI(PRT4)
Container ID             : {8057b38e-31b4-11eb-8ec8-7085c2b760d5}
Manufacturer Info        : (Standardsystemgeräte)
Capabilities             : 0x84 (Removable, SurpriseRemovalOK)
Status                   : 0x0180600A (DN_DRIVER_LOADED, DN_STARTED, DN_DISABLEABLE, DN_REMOVABLE, DN_NT_ENUMERATOR, DN_NT_DRIVER)
Problem Code             : 0
HcDisableSelectiveSuspend: 0
EnableSelectiveSuspend   : 0
SelectiveSuspendEnabled  : 0
EnhancedPowerMgmtEnabled : 1
IdleInWorkingState       : 0
WakeFromSleepState       : 0
Power State              : D0 (supported: D0, D3, wake from D0)
 Child Device 1          : HID-konformes, vom Hersteller definiertes Gerät
  Device Path            : \\?\HID#VID_1FC9&PID_0135#7&23cc8a4e&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030} (GUID_DEVINTERFACE_HID)
  Kernel Name            : \Device\000009fb
  Device ID              : HID\VID_1FC9&PID_0135\7&23CC8A4E&0&0000
  Class                  : HIDClass
  Driver KeyName         : {745a17a0-74d3-11d0-b6fe-00a0c90f57da}\0046 (GUID_DEVCLASS_HIDCLASS)

        +++++++++++++++++ Registry USB Flags +++++++++++++++++
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\1FC901350101
 osvc                    : REG_BINARY 00 00

        ---------------- Connection Information ---------------
Connection Index         : 0x04 (Port 4)
Connection Status        : 0x01 (DeviceConnected)
Current Config Value     : 0x01 (Configuration 1)
Device Address           : 0x01 (1)
Is Hub                   : 0x00 (no)
Device Bus Speed         : 0x02 (High-Speed)
Number Of Open Pipes     : 0x01 (1 pipe to data endpoints)
Pipe[0]                  : EndpointID=1  Direction=IN   ScheduleOffset=0  Type=Interrupt
Data (HexDump)           : 04 00 00 00 12 01 00 02 00 00 00 40 C9 1F 35 01   ...........@..5.
                           01 01 01 02 00 01 01 02 00 01 00 01 00 00 00 01   ................
                           00 00 00 07 05 81 03 40 00 04 00 00 00 00         .......@......

        --------------- Connection Information V2 -------------
Connection Index         : 0x04 (4)
Length                   : 0x10 (16 bytes)
SupportedUsbProtocols    : 0x03
 Usb110                  : 1 (yes, port supports USB 1.1)
 Usb200                  : 1 (yes, port supports USB 2.0)
 Usb300                  : 0 (no, port not supports USB 3.0) -> but Companion Port 3-8 does
 ReservedMBZ             : 0x00
Flags                    : 0x00
 DevIsOpAtSsOrHigher     : 0 (Device is not operating at SuperSpeed or higher)
 DevIsSsCapOrHigher      : 0 (Device is not SuperSpeed capable or higher)
 DevIsOpAtSsPlusOrHigher : 0 (Device is not operating at SuperSpeedPlus or higher)
 DevIsSsPlusCapOrHigher  : 0 (Device is not SuperSpeedPlus capable or higher)
 ReservedMBZ             : 0x00
Data (HexDump)           : 04 00 00 00 10 00 00 00 03 00 00 00 00 00 00 00   ................

    ---------------------- Device Descriptor ----------------------
bLength                  : 0x12 (18 bytes)
bDescriptorType          : 0x01 (Device Descriptor)
bcdUSB                   : 0x200 (USB Version 2.00)
bDeviceClass             : 0x00 (defined by the interface descriptors)
bDeviceSubClass          : 0x00
bDeviceProtocol          : 0x00
bMaxPacketSize0          : 0x40 (64 bytes)
idVendor                 : 0x1FC9 (NXP Semiconductors)
idProduct                : 0x0135
bcdDevice                : 0x0101
iManufacturer            : 0x01 (String Descriptor 1)
 Language 0x0409         : "NXP      SemiConductors Inc "
iProduct                 : 0x02 (String Descriptor 2)
 Language 0x0409         : "SE Blank RT Family "
iSerialNumber            : 0x00 (No String Descriptor)
bNumConfigurations       : 0x01 (1 Configuration)
Data (HexDump)           : 12 01 00 02 00 00 00 40 C9 1F 35 01 01 01 01 02   .......@..5.....
                           00 01                                             ..

    ------------------ Configuration Descriptor -------------------
bLength                  : 0x09 (9 bytes)
bDescriptorType          : 0x02 (Configuration Descriptor)
wTotalLength             : 0x0022 (34 bytes)
bNumInterfaces           : 0x01 (1 Interface)
bConfigurationValue      : 0x01 (Configuration 1)
iConfiguration           : 0x00 (No String Descriptor)
bmAttributes             : 0xC0
 D7: Reserved, set 1     : 0x01
 D6: Self Powered        : 0x01 (yes)
 D5: Remote Wakeup       : 0x00 (no)
 D4..0: Reserved, set 0  : 0x00
MaxPower                 : 0x32 (100 mA)
Data (HexDump)           : 09 02 22 00 01 01 00 C0 32 09 04 00 00 01 03 00   ..".....2.......
                           00 00 09 21 00 01 00 01 22 4C 00 07 05 81 03 40   ...!...."L.....@
                           00 04                                             ..

        ---------------- Interface Descriptor -----------------
bLength                  : 0x09 (9 bytes)
bDescriptorType          : 0x04 (Interface Descriptor)
bInterfaceNumber         : 0x00
bAlternateSetting        : 0x00
bNumEndpoints            : 0x01 (1 Endpoint)
bInterfaceClass          : 0x03 (HID - Human Interface Device)
bInterfaceSubClass       : 0x00 (None)
bInterfaceProtocol       : 0x00 (None)
iInterface               : 0x00 (No String Descriptor)
Data (HexDump)           : 09 04 00 00 01 03 00 00 00                        .........

        ------------------- HID Descriptor --------------------
bLength                  : 0x09 (9 bytes)
bDescriptorType          : 0x21 (HID Descriptor)
bcdHID                   : 0x0100 (HID Version 1.00)
bCountryCode             : 0x00 (00 = not localized)
bNumDescriptors          : 0x01
Data (HexDump)           : 09 21 00 01 00 01 22 4C 00                        .!...."L.
Descriptor 1:
bDescriptorType          : 0x22 (Class=Report)
wDescriptorLength        : 0x004C (76 bytes)
Error reading descriptor : ERROR_INVALID_PARAMETER (due to a obscure limitation of the Win32 USB API, see UsbTreeView.txt)

        ----------------- Endpoint Descriptor -----------------
bLength                  : 0x07 (7 bytes)
bDescriptorType          : 0x05 (Endpoint Descriptor)
bEndpointAddress         : 0x81 (Direction=IN EndpointID=1)
bmAttributes             : 0x03 (TransferType=Interrupt)
wMaxPacketSize           : 0x0040
 Bits 15..13             : 0x00 (reserved, must be zero)
 Bits 12..11             : 0x00 (0 additional transactions per microframe -> allows 1..1024 bytes per packet)
 Bits 10..0              : 0x40 (64 bytes per packet)
bInterval                : 0x04 (4 ms)
Data (HexDump)           : 07 05 81 03 40 00 04                              ....@..

    ----------------- Device Qualifier Descriptor -----------------
Error                    : ERROR_GEN_FAILURE

      -------------------- String Descriptors -------------------
             ------ String Descriptor 0 ------
bLength                  : 0x04 (4 bytes)
bDescriptorType          : 0x03 (String Descriptor)
Language ID[0]           : 0x0409 (English - United States)
Data (HexDump)           : 04 03 09 04                                       ....
             ------ String Descriptor 1 ------
bLength                  : 0x3A (58 bytes)
bDescriptorType          : 0x03 (String Descriptor)
Language 0x0409          : "NXP      SemiConductors Inc "  *!*CAUTION  trailing space character
Data (HexDump)           : 3A 03 4E 00 58 00 50 00 20 00 20 00 20 00 20 00   :.N.X.P. . . . .
                           20 00 20 00 53 00 65 00 6D 00 69 00 43 00 6F 00    . .S.e.m.i.C.o.
                           6E 00 64 00 75 00 63 00 74 00 6F 00 72 00 73 00   n.d.u.c.t.o.r.s.
                           20 00 49 00 6E 00 63 00 20 00                      .I.n.c. .
             ------ String Descriptor 2 ------
bLength                  : 0x28 (40 bytes)
bDescriptorType          : 0x03 (String Descriptor)
Language 0x0409          : "SE Blank RT Family "  *!*CAUTION  trailing space character
Data (HexDump)           : 28 03 53 00 45 00 20 00 42 00 6C 00 61 00 6E 00   (.S.E. .B.l.a.n.
                           6B 00 20 00 52 00 54 00 20 00 46 00 61 00 6D 00   k. .R.T. .F.a.m.
                           69 00 6C 00 79 00 20 00                           i.l.y. .

[/B]
I asked Paul about that phenomen, but got no answer.
 
Last edited:
Hi @FrankB - I had a T4.1 report that for awhile when my code had screwed up the USBBoot data.... As I working on it.

I recovered mine by doing the 15 second or so hold down program button until it reprogrammed the chip.

Note I was also running into it when I think I may have had a short on the soldering of the FlexSPI2 chip to sort of bottom of T4.1
 
Hi Kurt, interesting! Yes I guess it would work to do the 15-Sec reset. But I don't want to try it :) I have enough working T4s...
Do you remember which pins were shorted?
 
Hi Kurt, interesting! Yes I guess it would work to do the 15-Sec reset. But I don't want to try it :) I have enough working T4s...
Do you remember which pins were shorted?

Sorry no. But I might try to reproduce it ;) It was actually with my T4.1 with a castellated extension soldered on to the memory chips area, and going out to a breadboard, where I then jumpered in a Flash chip with what should be QSPI wiring... Will try that again in the next couple of days. I have so new castellated boards plus memory chips boards sitting at my Mailbox in town. Plus 3 shiny new T4.1s to experiment with.
 
I asked Paul about that phenomen, but got no answer.

I don't manage to read every forum message. I try, but especially this year while we're running short-staffed, a lot of other things pull on my available time. I can't read & reply to everything. Please try to understand and don't take it personally. It's not you. It's me.


I had a T4.1 report that for awhile when my code had screwed up the USBBoot data.... As I working on it.

Yup, that's what causes it. If NXP's ROM can't understand the first 512 bytes about how to initialize the flash memory, or if it can't parse the IVT and boot data fields (which are normally the beginning of your program) then it runs its own little bootloader and you see that HID device appear.
 
i think Paul could send you a T4 board with bootloader removed and without any fuses set.
Would that help? Did you ask him?

I got a few boards with most fuses not burnt. Anyway the boot-chip is still in place. I think it is not of much help to have a T4 without the boot-chip if it is not intended to be sold this way. With the boot-chip removed it's nearly like the MIMXRT1060-EVK so I can stick with this board for some tests. But what we need is a solution which works for the complete Teensy as it is intended to be sold.

On the other hand, contemplating about that more deeply, this might be not to far from a potential solution. For a really secured Teensy, sooner or later the JTAG access will be disabled and thus the boot-chip's function will be questionable. But I think the boot-chip will also do some power management.

If at least one could ask the boot-chip to drive BOOT_MODE[0] LO uppon request! In order to enter the serial boot. I do not really understand, why this isn't going to work via the ROM API.


Code:
[B]

    =========================== USB Port4 ===========================

...

      ========================== Summary =========================
Vendor ID                : 0x1FC9 ([COLOR=#ff0000]NXP Semiconductors[/COLOR])
Product ID               : 0x0135

...

[/B]
I asked Paul about that phenomen, but got no answer.

That's very intresting. It's exactly the USB ID expected for the serial boot!
 
Yup, that's what causes it. If NXP's ROM can't understand the first 512 bytes about how to initialize the flash memory, or if it can't parse the IVT and boot data fields (which are normally the beginning of your program) then it runs its own little bootloader and you see that HID device appear.

Ok, I will try this out as a way to get into the serial boot mode.
 
Ok, I will try this out as a way to get into the serial boot mode.

If it helps I can send you my Teensy 4.1 - it is one of the first 4.1 beta-test boards, hand-written serial-#. 40
But I fear - as soon as you flashed the first working program it's just a normal T4.1 again :)
 
Just tried it.
Indeed - very easy to put the teensy into the "NXP Bootloader mode".
Just compile "Blink" for AVR Nano and use the Teensy loader in manual mode to upload the avr hex-file. (The goal is just to create & use a hex file the Teensy can not understand). Done.
 

Attachments

  • NXP Bootloader.ino.zip
    1.2 KB · Views: 77
Last edited:
But I fear - as soon as you flashed the first working program it's just a normal T4.1 again :)

Yes, indeed! I modified a hex-file so that the IVT is no longer contained and programmed it with the teensy_loader_cli. My T4 entered serial boot mode and I was able to talk with it via the SDPHost tool. By playing arround and having a clother look at the documentation I found out that SDPHost is only able to program the target RAM, internal and external, but not the flash. So that means, in order to program the flash, a secondary bootloader is necessary anyway.

Also, the T4 enters the serial boot only directly after programming the corrupt image. Once the T4 is powered again the expected USB ID doesn't appear anymore, which has presumably the same unknown reason that caused the T4 not to enter the serial boot mode when requested via ROM API.
 
An other question:
Which tool can we use to sign and encrypt the image? I hope NXP has such a tool for download? Then, does it ouput a HEX-File, or do we need to create a new HEX File?
HAB without encryption isn't that useful for us, I think. So we need to enable that, too.
 
So far I have only used the authentication features, not encryption. The CST documentation mentions encryption, but it's not clear (at least to me) what CST can do there.

NXP's documentation mentions a "key blob" in many places. My limited understanding is this "key blob" needs to be created on the actual hardware IMXRT and can't be done only on your PC. Many of the finer details are still unclear to me.

Another minor detail is the memory mapping. I believe the decryption hardware makes the plaintext appear in a different memory area. The data which appears at 0x60000000 is the ciphertext. So even if we had all the answers in place for encrypting the data, that memory remapping and adjustments in the linker scripts and startup code would also be needed.
 
There are several "new" appnotes, from summer.
Have you seen them?

Such as

AN12604 Implement second bootloader on i.MXRT10xx series
AN12901 DCP-How to do Key Management
AN12852 How to Enable the On-the-fly Decryption
AN12681 How to use HAB secure boot in i.MX RT10xx
AN12800 i.MX RT10xx Fuse Provisioning for Security

with downloadable software.

As my English leaves me sometimes, it is very challenging for me to read & understand them :(

https://www.nxp.com/products/proces...b=Documentation_Tab&linkline=Application-Note
 
There are several "new" appnotes, from summer.
Have you seen them?

AN12681 yes, the others no.

To be honest & realistic, I'm not going to read any of those soon, nor do anything more on encryption right now. My main priority right now is website updates and a long list of stuff for 1.54-beta6 and eventually a 1.54 release. And answering forum questions...


As my English leaves me sometimes, it is very challenging for me to read & understand them

I also have a very hard time reading much of NXP documentation, and English is my only non-computer language!
 
An other question:
Which tool can we use to sign and encrypt the image? I hope NXP has such a tool for download?

NXP has several tools for all kind of purpose. The challenge here is to find the one which fits with Teensy and probably with the Arduino stuff. My impression is, that the more you seek the more tools you find but all have their ods. I think the key is to understand how things are working under the hood and to choose wisely which tool or set of tools to use.
Sure, encryption is another topic, which needs to be solved and I definitely will also address this feature. But as my experience lies in HAB and authenticated boot, I will firstly work on this. If I remember correctly form the iMX6 setting the board to secure also influences the way how the processor derives its unique encryption key.
 
There are several "new" appnotes, from summer.

Thank's for the hint. I just collected the new ones. Already know AN12681 and had a short look look at AN12604 and the linked SW. So yes, it's actually all there, but it takes time to identify and understand the core functions and migrate them into another environment. Similar project files can be found in the MCUExpresso SDK but the examples are strucured and packed in a way, that they work out of the box just for the chosen evaluation kit. The interested readers job is then to study the application notes and examples to be able to identify the relevant and pieces and cut them out for their desired purpose.

Reading the application notes as entire document does give you a first overview and hopefully a basic understanding of a certain feature and which components are involved. Really helpfull do they get non before you read dedicated pieces when you got stuck examining an implementation. When I get into such a situation I often think to remember that I have read something about a certain thing but do not really remember where, so I start scanning my "data base" of application notes and personal notes taken from time to time and find something helpful after hours of re-reading.

So it's really good to have them, but the are by far not the philosopher's stone and you will find a lot of redundant information without getting the tiny little piece you are missing.

I will take them for reference.
 
I looked at AN12604 and its code. Seems there's some magic buried inside AN12604SW/sw12604/tools/image_generate.exe. Sadly, couldn't find image_generate source code, or Mac or Linux versions.
 
Tim reminded me about the HAB Log in OCRAM.
As I currently work on antoher topic and once again stumbled across the cache: Don't forget the cache here ... ;) You may read wrong data..
 
Last edited:
Back
Top