Teensy 4.0 Secure Firmware Updating

Status
Not open for further replies.

AshPowers

Well-known member
Hi All!

I have developed a couple of products based on this device and I would like to make it possible to offer firmware updates for the product that customers can reflash the T4 to enable new product features/optimizations/etc as they are developed.

Both of the products are used in conjunction with a laptop connected through the USB port and a Windows based UI has already been developed to go with them.

Is there a way to compile the code within the Arduino/Teensyduino IDE and export the compiled version to a file and use my Windows app to upload the compiled program to the T4?

I am sure this is documented somewhere but I'm struggling to find the right group of search keywords.

Thanks!
 
Can the Button be pressed or Program pin activated? Might work to just ship Teensy.exe - the TeensyLoader.exe with the HEX file. Then in Teensy.exe "File / Open HEX File" and press button.

TyCommander - (aka/formerly TyQt) - linked on the forum and on Github might work easily to see the attached Teensy - as long as the Serial port not active/connected - it has GUI means to upload a named file.
 
As far as finding the HEX file - in the IDE

> Ctrl+Alt+S : put the hex in a local folder for EXPORT
> Ctrl+K : Open local folder
 
Can this firmware updater be made to work even if the board has their USB ID changed away from "Teensy" text?

How would I go about making the change?
 
Can this firmware updater be made to work even if the board has their USB ID changed away from "Teensy" text?

How would I go about making the change?

As long as you can push the button the bootloader will make a healthy Teensy respond to program.
 
As long as you can push the button the bootloader will make a healthy Teensy respond to program.
My use case is somewhat different, I need "secure firmware updating" feature, as the topic title says --

Specifically:
-- I need to prevent the user from being able to use Arduino IDE to update the firmware.
-- I would like to be able to program a Teensy 4.0 without needing to push the button -- since it'll be embedded inside a product case.

Basically, I could make a custom change to an updater such as TeensySharp to decrypt an encrypted firmware file, while installing onto a device no longer recognized directly by the Teensyduino profiles of Arduino IDE.

Basically, providing downloadable "firmware upgrades" (new Teensy 4 programs) that are automatically installed in a small-batch niche commercial product that uses unmodified Teensy units.
 
I wondered when the title was going to come back into it.

If the button is pushed the bootloader chip will format and overwrite when commanded over USB. And the external flash is separable from the CPU.

p#2 indicates TyCommander as a good way to program a Plugged in Teensy that has active USB Serial. Some effort could edit that behavior password perhaps.
 
No. Teensy 4.0 is not using the encryption features.

We may at some point in the future (not likely until at least 2021) support encrypted firmware. But that is no simple matter. These powerful features come with many dangers if used improperly, including lots of ways to permanently brick your Teensy. When (if) we do support encryption, it very likely will be a different board and the changes will (probably) not be possible as a software update to existing boards.

All of the design that has gone into Teensy 4.0's bootloader and uploading process has revolved around making Teensy safe for experimentation and preventing boards from becoming bricked.
 
Specifically:
-- I need to prevent the user from being able to use Arduino IDE to update the firmware.
-- I would like to be able to program a Teensy 4.0 without needing to push the button -- since it'll be embedded inside a product case.
AFAIK, these two requirement contradict each other (from a technical stand point of view)
You cannot inhibit upload to user and reserve rights to yourself. For TD there is no difference between you and other users.
So, first requirement cannot be satisfied, while keeping second.

"not pressing button", that is easy, you simply bring program pin out of product case.
Also, you do not need to press button, if program has responsive USB. i.e. it is not crashed.

Also, If you modify Teensy HW, I do not consider that a Teensy anymore.
 
No. Teensy 4.0 is not using the encryption features.

We may at some point in the future (not likely until at least 2021) support encrypted firmware. But that is no simple matter. These powerful features come with many dangers if used improperly, including lots of ways to permanently brick your Teensy. When (if) we do support encryption, it very likely will be a different board and the changes will (probably) not be possible as a software update to existing boards.

All of the design that has gone into Teensy 4.0's bootloader and uploading process has revolved around making Teensy safe for experimentation and preventing boards from becoming bricked.

That is what I remember from prior posting.

@WMXZ : Indeed that is how it is. Editing CORES to remove USB jump to bootloader could be finagled with a special command and password, but it the Button/Program line is dropped low - it will go into program mode. And the flash is not secured - except it will be wiped when programmed and ideally only readable if not part of Teensy (remove FLASH or Bootloader MCU).
 
AFAIK, these two requirement contradict each other (from a technical stand point of view)
You cannot inhibit upload to user and reserve rights to yourself. For TD there is no difference between you and other users.
So, first requirement cannot be satisfied, while keeping second.
Then reinterpret, in a light-security POV that simply only discourages casual hackers (not determined institutional hackers or large-corporation hacker). I'm willing to live with that.

- A minor change such as a device ID change to not realize I'm using industry standard Teensy's. This would require an experienced programmer to modify the Teensyduino add-on to make it recognize the connected device; and
- I would do Windows-app-level encryption (e.g. encryption key built into TeensySharp) to decrypt an encrypted file into a memory-based HEX file. This would not be as cryptographically secure, but sufficient casual-hacker security for my needs.

Also, If you modify Teensy HW, I do not consider that a Teensy anymore.
That is on the table too. Even if it's a one-pin change. There is a consideration going on about using the Teensy schematic and purchasing the bootloader chips instead, in an all-in-one circuit board.

We only deal in dozens of units, to low hundreds of units, which makes Teensy perfect for us. Theoretically we were 10,000-unit-quantity outfit, I'd just bypass the Teensy and come up with a chinese microcontroller design (and attendant disadvantages) but I am pretty fond of the Teensy and want to continue supporting the Teensy, and we absolutely love the 600Mhz performance of the 4.0 which has opened some new frontiers. Over the years, the three of us (in two countries) combined purchased a several dozen Teensy units in separate orders over the years.

I'll settle for nominal/minimal security that protects against most casual hacking, etc. The kind of hacking that a Windows Visual Studio developer (who's a novice at Arduino) might do to try to figure out if the firmware can be replaced on our product to use our product for unsafe/unaudited uses where we can't trust the data.

Certainly, I'll still have to have the Open Source Legal Disclosure screen which (upon careful readings) may still inform users it's at least superficially Teensy derived, but would still discourage casual hacking attempts. (Like novice Visual Basic or C# programmer who has no microcontroller experience other than an Arduino blinky).

Since I'd rely solely on Windows 10 serial driver, no other drivers are needed, and most users wouldn't even know it's a Teensy powered device unless they dug into the Open Source Legal Disclosure print in an About screen. And those casual users trying to load Teensyduino from that discovery of information, would not be able to easily install unauthorized firmware on the data to try to send fake/unsafe/unauthorized/unlicensed/unaudited/whatever data. (There are additional good reasons that I'm not at liberty to disclose here -- examples such as light security protects a company's legal liability and lower insurance costs because it satisfies an insurance company's checklist -- and/or sufficient protection against potential blameability on fraudulent data in order to satisfy a client's scientific-integrity audit trail checklist -- or a hobbyist that needs a few more months of commercialization headstart before Chinese hackers copycats the super-niche product....).

I am not saying these are the actual reasons, but there are externally-forced reasons why we need at least light security.

If they're determined enough to break the security, fine by me, but at least we've covered our bases -- even if it's barely more than symbolic security; it's "good enough" to satisfy a client that is demanding it. I would prefer stronger security, but I'll settle for basic security for now, so we can keep using the wonderful Teensy's for now.

So studying this further, this is something that is doable:

-- Factory ship with USB serial pre-enabled and disable Teensy recognition via changing the USB ID's. Threafter, it's permanently in USB serial mode (if chain of firmware upgrades remain uninterrupted) and upgradeable without pushing the button, simply via the TeensySharp "StartHalfKay()" programming command that allows upgrading without pressing the button.

-- A minor change to Teensy so that it's not recognized by standard Teensy environment (but the Windows 10 serial driver) without a minor edit to the Teensy environment. But still recognized by a slightly modified copy of TeensySharp.

-- TeensySharp can thus, be modified by me, to read an encrypted on-disk file, and decrypt to a standard HEX (in-memory) that can be loaded onto the Teensy (unencrypted), with TeensySharp edited to recognize the modified ID no longer recognized by Teensyduino (without editing).

True, it won't be fully secure from determined hackers, but sufficient to protect from casual-hackers and brickings.

Would this work?
 
Last edited:
I think in principle that should work without problem. You can easily change the VID/PID of the Teensy in the USB files. The TeensySharp uploader needs to know the VID / PID only for finding the Teensy. It will try starting HalfKey on any Serial device you throw at it. However, you need to be aware that as soon as somebody presses the program button the Teensy will appear as HalfKay device on the Bus and can be programmed by standard uploaders. So, working around your protection scheme might be as easy as opening the case and pressing the program button...
 
I think in principle that should work without problem. You can easily change the VID/PID of the Teensy in the USB files. The TeensySharp uploader needs to know the VID / PID only for finding the Teensy. It will try starting HalfKey on any Serial device you throw at it. However, you need to be aware that as soon as somebody presses the program button the Teensy will appear as HalfKay device on the Bus and can be programmed by standard uploaders. So, working around your protection scheme might be as easy as opening the case and pressing the program button...
Hmmm. So just exacto-knife the circuit trace for the button for the initial units (after initial programming).

Theoretically, bricked units if any, can just be reprogrammed inhouse (by jumpering).

And if later scaling up quantities that warrants custom board design (schematic + purchased bootloader approach), it would bypass that (just omit the button, use solder contacts).

Most customers don't know a soldering iron -- the few I know are just breadboard Arduino newbies (basically scientists/researchers that needed to create a jerryrigged circuit off a YouTube video for various other projects). A small portion of our audience seems sufficiently curious to probe our product superficially but not determined enough to risk the loss of product or loss of warranty.

Those people likely won't bother oscilloscoping or physically modifying our devices -- being pre-attached to other expensive electronics costing more than the Teensy itself -- risking the warranty of our commercial device). Metaphorically, the mainstream concept equivalent is the thought of hacking a washer-dryer machine by adding your own custom firmware to the dryer machine behave differently with the digital buttons pad -- it's possible, but it's not worth the risk/effort of damaging the microcontroller (angry customer posting bad review, despite it being their fault of attempted mod), burning the house down with an overheated motor triggered by unauthorized non-Maytag firmware (the reputational and liability fallout factor, insurance factor, etc), or bricking the entire machine in an attempted firmware tweak to uselessness & expensive to ship back to the factory. (The mysterious RMA that wastes resource, the cost factor).

The chief difference to this metaphor is our small-business has been building a new toaster-sized not-a-toaster contraption (device/apparatus) that has a USB cable that connects to a computer for data recording purposes, in a niche market full of novice Windows App programmers (to process the data), and that produces ... "systemic firmware risks" that we want to have at least some modicum of lightweight protection from, to satisfy our externally-mandated checklist. I'm not allowed to disclose the unannounced product at this time, but hope the situation is communicated adequately.

If they want to "jailbreak" our device, fine, but at least we've covered minimum externally-forced security pre-requistes (as explained in previous post)

We love the Teensy that saved our time and allowed us to make better applications / better firmwares rather than focussing on debugging an electronics circuit at our small-batch scale for our tiny business.
 
Last edited:
That would work of course. Just make sure that you never distribute a buggy firmware which crashes the USB stack since this will brick your device without the program button rescue ring :)
 
That would work of course. Just make sure that you never distribute a buggy firmware which crashes the USB stack since this will brick your device without the program button rescue ring :)
Thanks for the sage warning. Noted.

So I'll still have the random-chance cosmic-ray bit-flip bricking problem ;)
Or the flash-memory data-retention expiry problem (10-years-ish at 55C).

If we need to ramp up for the later full custom-board solution, undocumented jumper pins may be able to get a greenlight go-ahead, for one-on-one support use, for these extenuating circumstances during extended support phases.

-- Knock on wood we don't distribute a disastorously buggy firmware, and have to baby sit customers through a manual reset or RMA process... --

Ha.
 
Last edited:
OK, I have put some time here on the suggestions posted.

The HEX file export can be opened within the Arduino IDE and the source code is clear as day. When I said "secure" I was referring to not having to expose the source code in the process as I have hundreds of hours in the development.
TeensySharp is a C# API and I have written the windows UI for this product in VB6.

I imagine I could encrypt the firmware files to be sent to customers and the UI be able to decrypt it, write that out to a hex file and call a command line for the TeensyLoader?... followed by wiping the hex file? I know what I stated here is terribly crude and there are far better solutions to this.

I don't need vault-level protection with this product but distributing human-readable source code updates is out of the question.

What is involved with writing the programming sequence for the Teensy 4 into my Windows UI?

The programming button is not available for the end user to press in this product. The Arduino/TDuino IDE does not require that button to be pushed to program the unit so what is involved in writing that into my UI? This would be the simplest way as the firmware updates can be encrypted, decrypted by my UI, and then written out to the T4 within my UI.
 
Last edited:
re:
What is involved with writing the programming sequence for the Teensy 4 into my Windows UI?

The programming button is not available for the end user to press in this product. The Arduino/TDuino IDE does not require that button to be pushed to program the unit so what is involved in writing that into my UI? This would be the simplest way as the firmware updates can be encrypted, decrypted by my UI, and then written out to the T4 within my UI.

The link in post #3 :: github.com/luni64/TeensySharp
 
tycmd will more than likely suffice for what I need with this product. Thanks!

I would still like an answer as to what the methodology is to put the T4 into programming mode and how to write to it's program memory space. Where can I find these details?
 
I would still like an answer as to what the methodology is to put the T4 into programming mode

If your Teensy is in Serial mode you'd set the Baud rate to 134 to start the bootloader



and how to write to it's program memory space. Where can I find these details?

Basically you need to
  1. Start the boot loader (see above)
  2. -> Teensy appears as a HID device.
  3. Write HID reports with a defined structure to it.

You find the report structure in the sources for TeensySharp (C#), the Teensy CLI uploader (C) and TyCommander (C). All are on github just have a look at the details. If you search the forum you will find posts doing that in Rust as well.
Here a post using a T3.6 as uploader https://forum.pjrc.com/threads/47783-Teensy-programs-Teensy. Sources included in post.

Hope that helps
 
Last edited:
Status
Not open for further replies.
Back
Top