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?