Am 25.06.2017 um 00:27 schrieb jhnlmn@gmail.com:> Yes, this was my original question, how to store a secret on a device that is manufactured in China?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.
Is there a process for secure firmware install/upgrade for device made offshore?
Started by ●June 24, 2017
Reply by ●June 25, 20172017-06-25
Reply by ●June 25, 20172017-06-25
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
Reply by ●June 25, 20172017-06-25
On 6/25/2017 7:59 AM, Dave Nadler wrote:> 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...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..."
Reply by ●June 25, 20172017-06-25
On Sunday, June 25, 2017 at 1:44:02 PM UTC-4, Don Y wrote:> 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).Yep. Your mileage may vary.> But, it also means the "release software" has to include ALL of the support > software necessary to effectively test the ENTIRE device...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.
Reply by ●June 25, 20172017-06-25
On 6/25/2017 12:43 PM, Dave Nadler wrote:> On Sunday, June 25, 2017 at 1:44:02 PM UTC-4, Don Y wrote: >> 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). > > Yep. Your mileage may vary. > >> But, it also means the "release software" has to include ALL of the support >> software necessary to effectively test the ENTIRE device... > > Nope. The securely loaded firmware can contain a secure bootloader/key. > The manufacturer can load (encrypted/secure) diagnostic firmware, > then release firmware after test.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)> Depending on the application/cost, plenty of micros have adequate > flash for both functions so such hoop-jumping may not be required.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.
Reply by ●June 25, 20172017-06-25
On Sunday, June 25, 2017 at 4:13:33 PM UTC-4, Don Y wrote:> So, you're going to ship the assembled, tested device BACK > to the manufacturer > (of the MCU) to have release software installed?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?
Reply by ●June 25, 20172017-06-25
On 6/25/2017 1:18 PM, Dave Nadler wrote:> On Sunday, June 25, 2017 at 4:13:33 PM UTC-4, Don Y wrote: >> So, you're going to ship the assembled, tested device BACK >> to the manufacturer > (of the MCU) to have release software installed? > > Of course not. Please read my post a bit more carefully...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.> 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?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?!")
Reply by ●June 25, 20172017-06-25
On Sunday, June 25, 2017 at 4:53:29 PM UTC-4, Don Y wrote:> ...A really huge number of words about a point already covered....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...
Reply by ●June 25, 20172017-06-25
On 6/25/2017 2:05 PM, Dave Nadler wrote:> On Sunday, June 25, 2017 at 4:53:29 PM UTC-4, Don Y wrote: >> ...A really huge number of words about a point already covered.... > > You are missing the point. > We all know security of these things can be beaten at a cost.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!> 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... >
Reply by ●June 25, 20172017-06-25
Don wrote:> 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.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?
