Is there a process for secure firmware install/upgrade for device made offshore?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hi
Recently more and more companies want to add security (authentication and/o
r encryption) to their devices firmware install/update process. Typically t
his is done by storing a secret encryption key in bootloader or elsewhere i
n internal MCU flash. This should work if bootloader is installed in secure
 facility by trusted people. But then manufacturing is outsourced/offshored
 and then what? I do not want to send my precious key to China. So, I wonde
r whether it is possible to design an algorithm or process for secure firmw
are installation and updates while initial firmware is installed by a facto
ry in China. Typically my devices have JTAG, some other port (UART, etc) an
d often wireless (WiFi or Bluetooth). Note: moving all newly manufactured d
evices to a secure location and reflashing via JTAG would be too expensive.
 This problem seem to be very common now, there must be some common solutio
ns, are there? If pure software solution is not possible, are there some ha
rdware assisted solutions? I guess if a chip would include a hardcoded inac
cessible private key and assymetric decryption module, this would solve thi
s problem, would it? Are there such chips?

Thank you

Re: Is there a process for secure firmware install/upgrade for device made offshore?
On 6/23/2017 9:34 PM, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

What are you trying to guard/protect against?  "Factory" being able to
create unlicensed updates for your product?

Are you expecting to distribute unencrypted (though *signed*) updates
to your users?

How complex is the device (i.e., you;ll be giving your manufacturer the
binary image of the code to install in the virgin devices)?

Reflashing via JTAG (at a "secure location") isn't the *only* option.
(Hint:  how will your end users install updates?)

All you need (to allow you to NOT trust your manufacturing source)
is a "secret" that isn't available to them, or your users.

Re: Is there a process for secure firmware install/upgrade for device made offshore?
Quoted text here. Click to load it

1. Reverse engineering
2. Hacking
In resent years there were too many scary news about baby monitors and tedd
y bears, usb dongles and hard drives, networks routers and switches being h
acked and used to spy on their users, steal their data or infect computers.
 Many of these hacks became possible because original firmware was reverse  
engineered and/or hacked firmware was installed. Companies that developed t
hose insecure devices got very bad publicity. People are afraid to use devi
ces. We need to find some best practices and follow them.

Quoted text here. Click to load it
your users?

Requirements vary. Recently many of my clients began demanding encryption (
at least those who understand the threat). And I advise them to use both au
thentication and encryption as much as microcontroller capabilities allow.  
Luckily, recently more and more microcontrollers include hardware encryptio
n modules. The question is where to hide the secret key to use for encrypti
on/decryption.

Quoted text here. Click to load it
inary image of the code to install in the virgin devices)?

Again it varies, but recently I see more and more devices that only include
 bootloader and some basic firmware and then perform firmware upgrade upon  
first connection. Of course, this firmware upgrade can be done by anybody -
 end user or manufacturer or hacker.

Quoted text here. Click to load it
secret" that isn't available to them, or your users.

Yes, this was my original question, how to store a secret on a device that  
is manufactured in China?

Re: Is there a process for secure firmware install/upgrade for device made offshore?
On 6/24/2017 3:27 PM, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

If your product is "trivial", there is no need to "decompile the code";
just reinvent the design from its apparent specifications/functionality.

If your product is complex, you probably won't be able to do much more
than *copy* the design as it quickly becomes impractical to reverse
engineer *big*/complex designs (even with knowledge of the toolchain
used in their development).

There are "things" you can do to confound counterfeiters (folks that
nominally copy a design with minimal changes -- like changing the
copyright notice to reflect "their" ownership of it, etc.).  But,
you always have to balance the effort (and inconvenience) of
introducing these as they don't *directly* contribute to the
overall functionality/reliability of your product (indeed, they
may *worsen* reliability!)

Moral of story:  make a great product that people WANT to copy!
(whether that is by cloning the implementation *or* by duplicating
the functionality)

Quoted text here. Click to load it

The problem, there, is an attitude towards "security" as a "bolt-on"
aspect of a product's design instead of an inherent, "first-class" design
goal.

HP made a "secure web console" (I draw your attention to the word "secure"
in THEIR choice of product name!).  This was essentially a one-port terminal
server that you'd connect to the serial (console!) port of the system to
be administered.  An outward facing network interface on the device hosted
a web interface that allowed "administrators" to "log in" to the device and
have the sorts of capabilities afforded to "operators" sitting in the
data center alongside the machine being controled (i.e., the PHYSICAL acccess
that is usually essential to secure administration:  control who has
access to the physical machine to limit the attack surface).

So, from a browser, you could type on a virtual console AS IF you were seated
at a TTY a few feet from the machine.

Unfortunately, the implementation relied on a simple substitution (Caesar)
cipher to send the user's keystrokes from the browser to the remote SECURE
web console device.

Thus, when the administered machine sent it's "login: " prompt out to the
secure web console, that was forwarded to the remote user seated at the web
browser interface.  When he typed "root" followed by "mysecretpassword",
that text was sent to the SECURE web console as "sppu" and "nztfdsfuqbttxpse"
(for example).  Anyone sniffing packets would see this and trivially
decode the plaintext to be "root" and "mysecretpassword".

I.e., DESPITE the product being marketed with security in mind, the focus was
more on getting the web server in the device to operate with a reasonably
portable browser interface.  Security ended up sacrificed to meet those other
goals, instead.

Having default passwords has got to be the stupidest idea that ever came
to this market.  REQUIRE the user to set up an initial password BEFORE
allowing the device to operate.  If the user forgets the password, RESET
erases the password and restores the device to its "as shipped" configuration
(deliberately destroying any "sensitive" information that the user may have
forgotten was present on the device -- therefore, "Press RESET before
disposing of this device to safeguard its contents!") rendering it unsable
until a NEW password is specified.

[I suspect default passwords and account names represent the biggest
attack vector in most embedded devices.  Even MS got smart and realized
"Administrator" is a bad name for an ENABLED account!]

Beyond this, you have exploits that are consequential to sloppy or
poorly tested code (buffer overruns, stack overflows, etc.).  Adding
a secure update mechanism won't protect against these sorts of exploits.
And, an exploit that can hide "in RAM" (or in some aspect of the machine's
state) doesn't need to alter the "ROM image" -- it just needs to be able
to persist for some amount of time (which is usually easily done with
24/7/365 devices)

[Once an exploitable device is discovered, it can be targeted for periodic
"reinfection" even if it happens to cycle power (or otherwise purge the
exploit) often.]

Quoted text here. Click to load it

Are you willing to impose a particular choice of devices on your customers
(i.e., all of your designs)?  Or, are you happier imposing a particular
*process* on them (thereby giving you more leeway in how you approach
the designs)?

Quoted text here. Click to load it

That's how I have approached this.  I distribute a "ROM image" that allows
the manufacturer (domestic or foreign) to ensure the device HARDWARE will
perform as I intend.  This exercises ALL of the hardware (in concert with
a suitably designed test fixture) even if the "release software" doesn't
(currently) use some portion thereof.

I.e., if the devices pass the final inspection, I have some high degree
of confidence that the manufacturer has built them properly.  And, the
manufacturer can likewise be reassured (no fear of me rejecting a lot due
to some criteria that I impose *after* delivery).

A side-effect of this is the manufacturer never sees my production code.
Instead, he has code (a binary image) that is designed to test a particular
piece of hardware in a particular test fixture.  It may have *NO* value
when used with a modified test fixture or on different hardware.

[Note that there is nothing to prevent said manufacturer from counterfeiting
these devices!  He knows what parts they contain, how they are wired,
what "software" resides in them, etc.]

I receive the devices and subject them to the same "acceptance test" that the
manufacturer (theoretically!) applied as his "final test".  If devices pass
the final test (my "acceptance test") but fail to meet some other aspect
that I require of the design, then (clearly) my test procedure needs to
be revised/upgraded.

A "passing" device is then reprogrammed, serialized and recorded as "ready
(for sale)".

After the sale, the user "introduces" the device to his system at which point
it is tailored to his needs, keys/certificates installed, etc.

All of the "post manufacture" processes use protocols that are typically
NOT routed -- so, they require the device to be present on the same subnet
as the companion/programming device.  Additionally, the individual initiating
the action must "press a button" to activate this process.

So, a hostile actor can't usually gain virtual access to the device (unless
he suborns another host on that subnet and installs an appropriate set of
services to mimic the legitimate "programming" ones).  Also, he needs to have
those in place to anticipate the "button press" AND has to hope the /bonafide/
services aren't running (as they would detect this conflict).

This isn't foolproof.  But, it greatly reduces the attack surface to one that
SHOULD be more manageable:  keep a secure "programming station" (even if
that means booting off R/O media, etc.)

Quoted text here. Click to load it

Add it after the manufacturing process is complete.  If it isn't a "shared"
secret common to ALL of your devices, then having one instance of it exposed
(accidentally, social engineering, etc.) doesn't compromise ALL of your
products (of that particular model).

Re: Is there a process for secure firmware install/upgrade for device made offshore?
Quoted text here. Click to load it
Personally I have no chance of working on "trivial" devices since they are  
developed entirely in China. Of course, it will be nice if makers of those  
"trivial" devices (like those USB dongles that got hacked few years ago) wi
ll follow good secure processes as well.

Quoted text here. Click to load it
I am not sure my clients want that. I heard of many innovating companies th
at died as soon as chineese outfits managed to copy their design.

Also defense against reverse engineering is needed not only to prevent copy
ing, but to protect some other secrets, for example, an encryption or authe
ntication key or some secret method that give them business advantage (dete
ction of counterfeit printer cartridges comes to mind).

Quoted text here. Click to load it
 to operate.

And how can we securely send this password? It is easy to send password to  
a Web site (using HTTPs and private key on the server), but a lot of device
s allow local connection between devices or between a device and PC or smar
tphone. And here we come back to the same original question: how can we sec
urely store a private key on a device?

Quoted text here. Click to load it
(buffer overruns, stack overflows, etc.).
Quoted text here. Click to load it
loits.

Yes, I know that security through obscurity is a bad security, still it is  
much easier to find code susceptible to buffer overruns by reading disassem
bly than just by black box testing.

Quoted text here. Click to load it
s (i.e., all of your designs)?
Quoted text here. Click to load it
ing you more leeway in how you approach
the designs)?

No, I cannot force them to use a different microcontroller only because of  
security (we are not making ATMs machines).
Usually I am writing the code and writing a doc on how to install it. If a  
device is low volume and per-unit cost is  not so important I can require t
hat bootloader (along with secret key) along with JTAG programmer  is only  
installed on more or less secure PC on company premises. But for more or le
ss high volume devices they want to do the whole process in China.

Quoted text here. Click to load it
y (for sale)".

This is what I called "moving all newly manufactured devices to a secure lo
cation and reflashing via JTAG " in my original question (replace JTAG by W
iFi, BT, Serial, does not matter).  Alas, many startups have no resources t
o do that. They want to outsource everything.

Re: Is there a process for secure firmware install/upgrade for device made offshore?
On 6/24/2017 7:26 PM, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

Then my solution won't work for you.

Having worked in industries where counterfeiting was BLATANT and very
costly (~25% of your market share, thousands to tens of thousands of
dollars per lost sale), I can tell you that you will find yourself
spending a fair bit of time chasing dragons -- and, unless you can grow
WINGS, they'll always be a step ahead of you!

[Unless, of course, you're designing products that NO ONE WANTS!]

You'll have PROOF of a supplier having explicitly copied your product.
By the time you get yourself in front of a judge to slap an injunction
on them or have their cargo seized at the local port (assuming you know
where it is!), they'll have folded up shop and restarted under the
name "Joe's Garage Shop #x" -- where <x> increases by one each iteration.

*YOU* will be devoting your energies to trying to thwart and detect
their infringements while they'll be diverting their energies into learning
how to copy your designs FASTER.

You outsource "everything" then you also have implicitly outsourced
your product security/integrity/quality -- and with it, your reputation.

Good luck!

Re: Is there a process for secure firmware install/upgrade for device made offshore?
Add a Dallas chip with a unique id in every product?


Re: Is there a process for secure firmware install/upgrade for device made offshore?
On 6/25/2017 2:37 AM, Bill Davy wrote:
Quoted text here. Click to load it

That just gives you a serial number.  Do you plan on releasing
software updates (images) *tied* to specific serial numbers?
I.e., what is there that causes S/N 12345 to work but not 54321?

[I.e., you can use the device's MAC for a S/N]

What's to stop someone from downloading images for two different
serial numbers (perhaps because he legitimately OWNS two devices
each with different S/N's) and comparing the images to isolate the
location of the serial number and any other diff's (e.g., CRC)?
Armed with that, how hard would it be to create a NEW image
for some other S/N?  (Or, elide the S/N check entirely?)


Re: Is there a process for secure firmware install/upgrade for device made offshore?
Am 25.06.2017 um 00:27 schrieb snipped-for-privacy@gmail.com:

Quoted text here. Click to load it

The answer to that is as simple as it is depressing: you don't, because  
you can't.

As the saying goes: three can keep a secret if two of them are dead.

And installing the secret yourself is not a solution either, because  
then you will effectively no longer be manufacturing in China.  You'll  
be buying unfinished product from China.  If you can afford the extra  
shipping and delay, plus the local work and taxes, good for you.  But if  
you could, why were you going the "Made in China" route to begin with?  
And what makes you so sure your local employees can be trusted with the  
secret so much more readily than the Chinese?

And that's before we consider how you expect your overseas contractors  
to meaningfully _test_ freshly produced devices which have to refuse to  
run any but authenticated software, while they don't have the secret key  
to do the authentication.

Any firmware upgrade mechanism is an attack vector first, and a useful  
feature second.

Re: Is there a process for secure firmware install/upgrade for device made offshore?
Don, I appreciate your pessimism and despair.
Still, imagine that more and more devices are made just like I said: on a s
mall budged, with almost everything outsourced except (hopefully) engineeri
ng. So, we must find some ways to retain control, otherwise everything will
 be hacked (which is not hacked already) and we will not be able to make or
 use any electronics. I really wish a solution will be found. Anybody?
Thank you

Re: Is there a process for secure firmware install/upgrade for device made offshore?
On 6/24/2017 9:59 PM, snipped-for-privacy@gmail.com wrote:
Quoted text here. Click to load it

It's not pessimism; it's a realistic attitude given the capabilities
available to even "small players", nowadays.  "Kids" de-encapsulate
chips in college labs and microprobe die, etc.

Quoted text here. Click to load it

Imagine you have a device that lets you "hide" a key in it.  Who's going to
push the buttons, copy the files, or <whatever> to actually *hide* the key?
You're outsourcing EVERYTHING!

Do you trust the supplier to do the "secret key encoding" -- but NOT trust him
to actually *see* the key he is encoding into the devices?

Do you find a second firm to do the keying -- and hope these two firms never
"compare notes"?

What if you add a component containing the key to the design AFTER it has
been manufactured.  Who "adds the component"?  A third firm?

Do you buy custom silicon with the key already hidden inside?  Then, hope that
secret is never leaked/revealed/sold/etc. (i.e., have BETTER security over
your IP than the likes of the NSA, Sony, many multinational banks, etc.) by
a disgruntled employee, etc.?

And, WHEN it is disclosed/discovered (by some technique that you've not yet
heard about), do you get NEW silicon with a different key?  And, at the same
time, allow clients to be able to PICK the microcontroller core that they want
embedded in that silicon?

Do you suddenly stop making products when someone "cracks" your system?
And, not resume until you've come up with another "uncrackable" approach?

And, of course, you no doubt expect all of this to be inexpensive as these
"startups" don't have the re$ource$ for that, either?

You either have to trust *some* supplier OR be willing to take on some
of the trusted activities yourself.  How does your client know that
*YOU* can be trusted?  Maybe you hid a backdoor in THEIR product?!

Quoted text here. Click to load it

Invest your time in making better products -- so no one wants the last
generation product.  Design your products with security in mind from the
start, not bolted on as an afterthought.  Be an Engineer, not a Rent-a-Cop.

IFind people that you trust -- if you need them to be trustworthy -- in
much the same way that you hire people to be *competent* (at some skill)
when THAT is your need!

Quoted text here. Click to load it



Re: Is there a process for secure firmware install/upgrade for device made offshore?
MCU manufacturers will typically install firmware for you.
Given you are using a chip with a "secure" key/firmware,
have the manufacturer install the key/firmware,
and forward the parts for assembly.  

That's a common solution...
Won't help if the chip's "security" is weak...

Hope that helps,
Best Regards, Dave

Re: Is there a process for secure firmware install/upgrade for device made offshore?
On 6/25/2017 7:59 AM, Dave Nadler wrote:
Quoted text here. Click to load it

At best, this limits you to a small subset of the available devices
(OP claimed he "cannot force them to use a different microcontroller
only because of security").  Any device that *appears* to be secure,
today, just hasn't seen enough attention to be hacked (or, the hack
hasn't been widely published).

But, it also means the "release software" has to include ALL of the support
software necessary to effectively test the ENTIRE device -- even the
parts that aren't (yet!) used.  You can't install "manufacturing firmware",
verify/troubleshoot the device's complete functionality and then overwrite
it with "release" software intended for retail with any assurance that
the device (of undisclosed capabilities) will be field-upgradeable to
some future set of capabilities/functionality at a later date!

    "I downloaded the 1.0.1 update from your website and it appears
    to have installed successfully.  However, the device doesn't work
    as claimed in the 1.0.1 Release Notes..."

If the device includes a complete set of diagnostics, then you have to
either document their presence, *hope* no one accidentally invokes them
*or* selectively disable them prior to shipment.

    "I don't know what I did but the device is now just sitting there
    with the power light alternating between red and green.  And, it's
    making a funny buzzing noise..."

Finally, you've now sacrificed some flexibility in how quickly you can
implement changes to the manufactured devices.  I.e., a bug discovered
in the codebase installed by the manufacturer can't be corrected in stride;
any already programmed devices have to be returned to the manufacturer for
reprogramming.  And, you have to wait for the manufacturer to deliver
replacement components that have the "fixed" firmware contained within.

Or, require the END USER to do the upgrade as soon as he unboxes the device:

    "Cripes!  I haven't even had a chance to plug the thing *in* and
    and they're already telling me it's got a bug and needs to be
    upgraded..."

Re: Is there a process for secure firmware install/upgrade for device made offshore?
On Sunday, June 25, 2017 at 1:44:02 PM UTC-4, Don Y wrote:
Quoted text here. Click to load it

Yep. Your mileage may vary.

Quoted text here. Click to load it

Nope. The securely loaded firmware can contain a secure bootloader/key.
The manufacturer can load (encrypted/secure) diagnostic firmware,
then release firmware after test.
Depending on the application/cost, plenty of micros have adequate
flash for both functions so such hoop-jumping may not be required.

Re: Is there a process for secure firmware install/upgrade for device made offshore?
On 6/25/2017 12:43 PM, Dave Nadler wrote:
Quoted text here. Click to load it

So, you're going to ship the assembled, tested device BACK to the manufacturer
(of the MCU) to have release software installed?  :>  Then, back to the
manufacturer (of the assembled device) for *final* test (cuz the OP
doesn't trust the manufacturer of the assembled device to install the
code/secrets)

Quoted text here. Click to load it
OP's *customer*/client is going to choose the device.  OP has
claimed he can't *impose* a selection based on these "security criteria".

If you want a solution for a *specific* problem, then you pose THAT
problem, not the "general case" as suggested in the OP.

Re: Is there a process for secure firmware install/upgrade for device made offshore?
On Sunday, June 25, 2017 at 4:13:33 PM UTC-4, Don Y wrote:
Quoted text here. Click to load it

Of course not. Please read my post a bit more carefully...
The use of encrypted firmware coupled with a micro preprogrammed
with bootloader and key means the manufacturer can load firmware,
without being able to clone the product.

That is what the OP is looking for, no?

Re: Is there a process for secure firmware install/upgrade for device made offshore?
On 6/25/2017 1:18 PM, Dave Nadler wrote:
Quoted text here. Click to load it

I understood your post.  You're missing the point that the "release
keys" are present in the devices -- all the devices -- that the
manufacturer encounters.  He (or a third party "post retail"
adversary) can leisurely purchase some number of these devices
and examine them in fine detail -- possibly DESTRUCTIVELY -- to
extract *THAT* (singular) secret.

Armed with this ONE secret, he now holds the keys to your kingdom.
Every unit sitting in your warehouse along with every unit that
YOU'VE ALREADY SOLD!  (Do you issue a world-wide recall of all
previous units to ensure the SECURE BOOT SECTOR is updated as
well as the "release software?)  Once the horse has left the stable,
ALL of your product (maybe even product *line*, depending on
how much you've leveraged that boot code and key set) is at risk.

By contrast, I can't even tell you what the private keys for my
devices are.  *They* generate them and tell me what their PUBLIC
keys are.  Buy a second unit and its keys will be different.
Try to REPLACE the first unit with the second without first
"introducing it" to my system and the new unit won't work.
STEAL (reverse engineer) the keys from a unit and you've gained
*exactly* one unit -- the rest of the population remains secure.

Quoted text here. Click to load it

He wants to protect against reverse engineering (which can lead to
counterfeiting and/or devices being pwned).  Are you *sure* the
"secure boot loader's" contents can't be inferred by operating the
device at reduced voltages?  Monitoring Icc (having characterized
some number of OTS devices that you bought from the same vendor)?

Once someone figures out how to hack *one* of these devices, then
ALL are vulnerable.  If every instance of that device purchased
for your application contains the same code/key image, then all
of your application devices are compromised by any successful attack
against *one*.

And, you'll never know if the order for *one* unit that you received,
today, was for a genuine user's interest *or* for a hacker who is
eager to crack your device.

Apple couldn't seem to keep their iPhone secure.  MS couldn't
keep their XBOX secure, etc.  And, these are people with REALLY
DEEP pockets ("Gee, why didn't they just buy these cheap MCU's
that the OP is using?!")

Re: Is there a process for secure firmware install/upgrade for device made offshore?
On Sunday, June 25, 2017 at 4:53:29 PM UTC-4, Don Y wrote:
Quoted text here. Click to load it

You are missing the point.
We all know security of these things can be beaten at a cost.

If I understood the OP correctly, he's looking for common methods
of getting the cost high enough to make it hard to clone/reverse.
Which is the question I answered...

Please, enough now...

Re: Is there a process for secure firmware install/upgrade for device made offshore?
On 6/25/2017 2:05 PM, Dave Nadler wrote:
Quoted text here. Click to load it

And, that cost is LOW and headed LOWER!

20 years ago, the idea of deencapsulating or microprobing a die was
an esoteric attack.  Now, you can use a lab at your local university
to do so.

20 years ago, monitoring power supply currents or analyzing bus signals
and tracing tens/hundreds of thousands of bus cycles would require a
REALLy high end logic analyzer or DSO.  Today, you can buy them for
"lunch money" at surplus auctions.

Brute force attacks on 48 bit keys were unheard of.  Now, you
can get get your neighbor's WiFi password in 24-48 hours time
without him ever knowing you've been snooping on his transmissions.

Planning your development strategy around something that you *think*
is unaffordable/impractical -- especially in an era where folks will
make their tools/expertise available "for free" or "in kind" -- is
simply foolhardy.

Unless, of course, you design your product -- and the expectations
of the folks who BUY THEM -- around a very short product lifetime:
    "Please discard your baby monitor after your child's first
    birthday as there is a high probability that the SECURITY
    in its design will be compromised by that time... and we'll
    probably NOT be supporting it at that time -- so, any
    security flaws will be BAKED IN thereafter!"

WTF incentive did folks have to hack BABY MONITOR?  Yet, they *did*!
Do they like listening to babies crying?  Cooing?  Mothers talking
to their infant children?  etc.

I know a guy who *hand* disassembled 48K of ASM for a video game
"just because".  And, in doing so, identified all of the copy protection
mechanisms that had been added to the code to prevent its unintended
alteration.  Had he been *financially* motivated, what damage could
he have done by publishing that information?  (video games were $2K
devices and a few hundred kilobucks, per game, to design; imagine being
able to clone that game and save those hundreds of kilobucks of
development cost!)  Imagine how he'd do that, today, with the sorts
of tools that are CHEAPLY available.

The OP seems to think "reputation" and "product control" are important.
Is he only interested in the short term??

If you don't want folks reverse engineering/hacking/pwning your products,
then design a product that NO ONE WANTS!

Quoted text here. Click to load it


Re: Is there a process for secure firmware install/upgrade for device made offshore?
Don wrote:
Quoted text here. Click to load it

Who are *They*?  So, Don, your solution is to generate a unique private key for each device, find some trusted *They* to install them and then generate a unique firmware upgrade for each device using a unique public key. Did I understand you correctly?

Dave wrote: "MCU manufacturers will typically install firmware for you. "
Well, this is obviously impractical in many cases. Big chip makers do not talk to small startups like us. Often we just buy chips from a reseller.
What I wonder is whether MCU makers can install private keys during initial manufacturing and then publish public keys.  
If a unique key per each device is not practical, then, may be, one key per 1000 or something like that.
Then they can implement a decryption module using this hard coded key.
I see that 10 years ago there were patents for encrypted JTAG. Do you know whether anybody tried implementing it?

Site Timeline