Looking for advice regarding code/product security

Status
Not open for further replies.

TnF

Member
Hello Paul. I hope you are reading this.

I've developed a solution to let's say a niche problem i am having (using your Teensy's as development boards;p) and since i've made all this trouble i am thinking on giving my chance launching a crowdfunding campaign for it.
I have done several projects in the past of much more complicated and expensive products/solutions (i'm a mechanical engineer by trade), but i didn't see enough marketing potential on those since were much more specific.

In fact i have a full working product with 3d printed case, custom pcb, etc and i could easily make 100pcs by hand to sell if i wanted to. But i don't see me going through all this trouble for such a small amount. From my previous experiences i can judge a 500pcs min to 2500pcs max potential for a one month crowdfunding campaign for this product. This will require me to move the design to mass production which opens a few improvement possibilities.

However this is not what worries me. I know if this product launches successfully the Chinese will make a clone out of it. I guarantee it, i've dealt several times before with them with my past developments.
I believe this is what happened with Teensy 2.0 if my memory serves me well.

I know there is no absolute security but there are solutions to make it difficult enough for them to spend the time and funds needed to reverse engineer it. Hardware wise i pretty much cannot do anything about. PCB is easy to reverse engineer and even if you pot the whole thing with epoxy it's just a matter of time to clean it. So the only protection i am left with is software:

Obviously the first line of defense is fuses and lock bits. These can be bypassed with optical fault injection but if they go through this trouble let it have it. Any solutions to mitigate would increase the product cost by a long shot. And i want my product to be cheap, i want as many people to have it because it means less potential market for them.

Secondly i could write some bootloader that encrypts/decrypts the firmware, and/or uses some key or checksum to verify that the user uses a genuine product; no reason to go into much detail here because it's not what worries me most. It's this instead:

- I want the FW to be user updatable; meaning a bootloader will have to be flashed at the assembly line with some sort of test program so the boards can be checked for functionality before moving to final assembly and then shipping to the customer.
- You would say this is a no-no since they will have my bootloader but the problem it doesn't make financial sense for me to having to import the product here, get taxed on it (since i am not a company) and then re-export it with even higher postage costs than what would be if shipped directly out from China.

Thus some kind of solution must be found and even though i thought about some other software solutions are not 100% secure. Which leaves the only other solution that you have implemented; having a pre-flashed microcontroller with a secured bootloader like what you have done with the Teensy 3.x+ with MKL02 chip and custom bootloader. I am assuming that you get them pre-programmed by yourself, or have even ordered them with pre-written ROM and you ship them to your assembly house to be installed on the final boards.

You don't need to go into detail on the inner workings of Teensy, just looking for some advice from someone much more experienced than i am.

ps. My product doesn't have much need for processing power so i have a huge selection of micro's i could use since the popular ones have jumped in price by a LOT during the last year, but i want to stay with either AVR or STM32, or even both, as they are the ones i have experience working with.

Kind regards
 
Obviously Paul, can give you a lot more information, although not sure about AVR or STM32...

But I know that for T4 and T4.1 Paul has setup a few beta boards with a beta version firmware and settings of the IMXRT chip to support security. I believe with the latest released version of Teensyduino,
and for sure with current beta releases. there is a new menu item under tools, for Teensy 4 security.

With this, you can create a new key. With this key you can create sketch with this key to program one or more T4s or T4.1s with this keys and another sketch locks this Teensy.

It there is a key defined on your machine, when you build a program it will create a .hex file as well as a secure version .ehex

For those teensy boards that are locked, you can only upload new programs that are the .ehex that have right key.

Again I have no idea when this new firmware will be released. But I am testing running with a locked T4 and T4.1 for different sketches and so far everything appears to work fine.
 
Ok, I've read this lengthy message again, rather than just a quick skim.

Teensy 3.x isn't a viable solution, since the code updating process needs to transmit the firmware unencrypted over USB. Even if you create your own update program (similar to Teensy Loader) which uses encrypted files, any untrusted party performing a firmware upgrade could capture the USB communication.

The upcoming lockable Teensy 4.x does provide secure firmware update by untrusted parties. All sensitive data in the EHEX files is encrypted. It is end-to-end encrypted, in the file, over the USB cable, in the flash memory chip, and between the chip chip and processor. Decryption happens on-the-fly inside the processor.


- You would say this is a no-no since they will have my bootloader but the problem it doesn't make financial sense for me to having to import the product here, get taxed on it (since i am not a company) and then re-export it with even higher postage costs than what would be if shipped directly out from China.

Buying T4 bootloader chips and sending them off an untrusted CM is only a viable option if the finished product can be programmed with your encryption key by a trusted party. The security model just does not work without a trusted party to write the key into fuse memory and lock the chip into secure mode.

Buying a lockable Teensy 4.0 or 4.1 (when we start selling the lockable boards) could work, if you can embed the entire Teensy board into your product. To do this securely, you (or a party you trust) would need to get the Teensy boards and program your key into the fuse memory, and then lock security. That's 2 steps for every Teensy (assuming you will skip the optional verify step after you've done a few boards and feel comfortable with the process). Teensy Loader's "Auto" mode makes this pretty easy... just set up the first file and plug each board into the USB cable and press its button. Each board takes just a few seconds. You'd probably do them all with FuseWrite, then set up Teensy Loader Auto mode with LockSecureMode and plug each board in again and press the button. If you spend 30 seconds on each board (mostly open bags and realist time to move stuff around), you can do 120 per hour per person. Then you would send the locked Teensy boards to your untrusted CM. You could give your CM a copy of Teensy Loader and your encrypted EHEX file, to have them load the final firmware. Once shipped to customers, you can publish new EHEX files which anyone can write to the boards. EHEX programming is secure as long as your previously ran both FuseWrite and LockSecureMode.

But the entire security model depends on you or someone you trust running the FuseWrite and LockSecureMode programs. If you manufacture PCB with the bootloader chip, you must arrange for a trusted party to do those steps. If you embed a lockable Teensy, you could do those steps yourself before sending the boards to be used in your products.
 
Obviously Paul, can give you a lot more information, although not sure about AVR or STM32...

But I know that for T4 and T4.1 Paul has setup a few beta boards with a beta version firmware and settings of the IMXRT chip to support security. I believe with the latest released version of Teensyduino,
and for sure with current beta releases. there is a new menu item under tools, for Teensy 4 security.

With this, you can create a new key. With this key you can create sketch with this key to program one or more T4s or T4.1s with this keys and another sketch locks this Teensy.

It there is a key defined on your machine, when you build a program it will create a .hex file as well as a secure version .ehex

For those teensy boards that are locked, you can only upload new programs that are the .ehex that have right key.

Again I have no idea when this new firmware will be released. But I am testing running with a locked T4 and T4.1 for different sketches and so far everything appears to work fine.


That is a very nice feature, but if i didn't clearly explained it i am trying to keep the cost as low as possible; Using a Teensy of the shelve would make the device double or even triple my target cost. Now if i was making a small volume production under 100 units yes this could be a possibility but this microcontroller is WAY WAY overkill for this application.


Ok, I've read this lengthy message again, rather than just a quick skim.

Teensy 3.x isn't a viable solution, since the code updating process needs to transmit the firmware unencrypted over USB. Even if you create your own update program (similar to Teensy Loader) which uses encrypted files, any untrusted party performing a firmware upgrade could capture the USB communication.

The upcoming lockable Teensy 4.x does provide secure firmware update by untrusted parties. All sensitive data in the EHEX files is encrypted. It is end-to-end encrypted, in the file, over the USB cable, in the flash memory chip, and between the chip chip and processor. Decryption happens on-the-fly inside the processor.




Buying T4 bootloader chips and sending them off an untrusted CM is only a viable option if the finished product can be programmed with your encryption key by a trusted party. The security model just does not work without a trusted party to write the key into fuse memory and lock the chip into secure mode.

Buying a lockable Teensy 4.0 or 4.1 (when we start selling the lockable boards) could work, if you can embed the entire Teensy board into your product. To do this securely, you (or a party you trust) would need to get the Teensy boards and program your key into the fuse memory, and then lock security. That's 2 steps for every Teensy (assuming you will skip the optional verify step after you've done a few boards and feel comfortable with the process). Teensy Loader's "Auto" mode makes this pretty easy... just set up the first file and plug each board into the USB cable and press its button. Each board takes just a few seconds. You'd probably do them all with FuseWrite, then set up Teensy Loader Auto mode with LockSecureMode and plug each board in again and press the button. If you spend 30 seconds on each board (mostly open bags and realist time to move stuff around), you can do 120 per hour per person. Then you would send the locked Teensy boards to your untrusted CM. You could give your CM a copy of Teensy Loader and your encrypted EHEX file, to have them load the final firmware. Once shipped to customers, you can publish new EHEX files which anyone can write to the boards. EHEX programming is secure as long as your previously ran both FuseWrite and LockSecureMode.

But the entire security model depends on you or someone you trust running the FuseWrite and LockSecureMode programs. If you manufacture PCB with the bootloader chip, you must arrange for a trusted party to do those steps. If you embed a lockable Teensy, you could do those steps yourself before sending the boards to be used in your products.

Paul, thanks a lot for your reply. Your new Teensy will certainly be effective in what i am doing but like i've replied to KurtE above due to target cost constraints it would be prohibitive to use a Teensy directly into this specific device.
However the concept is similar to what i came up with after thinking about it more yesterday (before i read your reply) and should ideally go like this:

- Use a single microcontroller on the device (again keep costs low), that is shipped it to me where i burn a custom bootloader that contains a decryption key and i fully secure it with the fuses and lock bits. Then the chips are re-reeled and send to the assembly house.
- After final pcb assembly the one-way encrypted user FW can be uploaded to the device, and final testing before assembly can be performed on the device. There is no reason to lock this program area since this FW will be publicly available.
- Upon power-on, the bootloader reads the FW from the program area and decrypts it into RAM where it is then run.

Obviously there are a couple of "issues" here. First is finding a microcontroller that is cheap and has appropriate instructions/capability to decrypt the code in a reasonable amount of time (under 10s), and have enough ram to store the program and run it without hitting a brick wall. My device doesn't need any ADC's so maybe i could find something that is reasonably cheap and capable of this (example atmega32u4 has a cheaper version without ADC's as atmega32u2)

The other issue is that the device is still open to attack by decapping and performing an optical injection attack but i don't think anyone would go though all this trouble for it (considering i haven't seen any counterfeits of your very popular Teensy 3.2); the only way to prevent this is using some kind of hardware protection using specialized methods; i remember i saw an EEVblog video in the past of some device made by an Israeli company that had embedded all kinds of traps, one of which was an internal battery that kept the FW or encryption key in RAM and would cut power after any sort of attempted intrusion :D But then you go into military protection stuff where budget is thrown out of the window :rolleyes:
 
Not sure if this form is the right forum to ask if you don't want to use a teensy..?
Tried to ask Apple about Andriod? :)
 
Well, you did come to a forum about Teensy to ask your security question!

I'm pretty sure the reality of today's microcontroller market is parts you would consider "reasonably cheap" lack the capability for strong security (not just specific ciphers which run slowly, but overall system security), especially with regard to cryptographic authentication.

If BOM cost is of such overriding importance that your thought process is a willingness to do without traditional security features like authentication, I believe you would do well to recognize from the beginning that the security of whatever you create will very likely rely on obscurity & secrecy of its algorithms and implementation. So many people have a very reflexive response to "security though obscurity", and indeed it a very bad plan for mass market products, but maybe a pragmatic choice for something where you're only going to manufacture 100 units? But of course you should never speak to anyone of your specific implementation choices in that case, especially not on a public forum.
 
Let me also mention that there are also very capable programmers everywhere in the world.
If the product is interesting enough, and promises enough erning$ , there will be a clone.
They will rewrite the software if necessary if they can't copy it. No problem. If possible, they'll even use better, cheaper hardware.
 
Not sure if this form is the right forum to ask if you don't want to use a teensy..?
Tried to ask Apple about Andriod? :)

Well, you did come to a forum about Teensy to ask your security question!

I'm pretty sure the reality of today's microcontroller market is parts you would consider "reasonably cheap" lack the capability for strong security (not just specific ciphers which run slowly, but overall system security), especially with regard to cryptographic authentication.

If BOM cost is of such overriding importance that your thought process is a willingness to do without traditional security features like authentication, I believe you would do well to recognize from the beginning that the security of whatever you create will very likely rely on obscurity & secrecy of its algorithms and implementation. So many people have a very reflexive response to "security though obscurity", and indeed it a very bad plan for mass market products, but maybe a pragmatic choice for something where you're only going to manufacture 100 units? But of course you should never speak to anyone of your specific implementation choices in that case, especially not on a public forum.

Let me also mention that there are also very capable programmers everywhere in the world.
If the product is interesting enough, and promises enough erning$ , there will be a clone.
They will rewrite the software if necessary if they can't copy it. No problem. If possible, they'll even use better, cheaper hardware.

Thanks for the replies. I didn't meant to come up as rude; like i've said i've been using Teensy for development from the 1st time i bought one, and i've even considered it using it in a product i didn't go through to make mass production (it was a specialized customizable keyboard running QMK). However i decided to ask my question here because Paul is the only person i know that has a small microcontroller based product that has successfully avoided getting counterfeited and thought i could get some advice before tipping my legs into quicksand (as in i cannot go back if i make a mistake now). I hope it is more clear now.

My product will definitely not be as successful as Teensy, so maybe i am worrying too much, but believe me i know how Chinese businesses hassle. If you make it easy for them, even if they don't mean to gain that much they will take advantage of it. I know a business that paid for a custom injection mold and batch run, of their own design and had an agreement not to allow them to re-sell their product elsewhere. After a few months guessed what happened. They started selling it to anyone. And it's not even Chinese; i know another business that had the same thing happen with aluminium extrusion design (and no, they didn't copy it, the same company started selling their extrusions to other people). If you think China alone is a huge market mostly inaccessible to the outside world; they don't import what they can make there. So it's inevitable if there is demand for them to steal your design one way or another and you cannot do nothing after it happens.

In the end i am not making an iPhone and i am not Apple. Cost is key and i actually find it more challenging and rewarding trying to optimize for this sales-to-cost curve. I hate spending resources on non-essential/non-functional stuff. DRM for example. But when other parties don't play fair they are not leaving me much of an option here. However, if it gets eventually copied i will open source the whole design. I know it will not matter at that point but it's all about sending a message.
At least if i can make my idea happen successfully, it would be a small taste of personal victory even if i eventually get forced out of the market.
 
Availability of Lockable Teensy

Hi Paul,

You wrote in an answer:
> Buying a lockable Teensy 4.0 or 4.1 (when we start selling the lockable boards) could work
What is the expected availability of the lockable Teensy?

Thanks,

Zsolt
 
Status
Not open for further replies.
Back
Top