Making OSHW design a viable occupation: The OSHW product "Introducer"

[EEEnthusiast]

A method to prevent un-authorised clone is to use a dedicated crypto authentication chip. The Atmel ATSHA204A is such a device and it is very cheap (< $0.4) . The creator can program his personal unique keys into the device which can be authenticated in firmware or application software. The firmware or the application program has to be closed source for this to work.

[EEVblog]

A method to prevent un-authorised clone is to use a dedicated crypto authentication chip. The Atmel ATSHA204A is such a device and it is very cheap (< $0.4) . The creator can program his personal unique keys into the device which can be authenticated in firmware or application software. The firmware or the application program has to be closed source for this to work.

They could still do a pointer jump around the routine though if they can read the binary.
The 121GW multimeter firmware binary for example was dissembled and changes made to the routines by someone on this forum, all without the source code.
Of course, the open source purist will have a heart attack if you try and protect your design like this.

[EEVblog]

Easiest way to do that is to put your name, your company logo, your Trademark name etc on it. If it has any of those things and it's not from an authorised reseller then it's an illegal clone.

Partially agree. Will work for most, but not for all.
Many people is just too lazy to check, who is authorized and who is not.

Of course, there is no one solution to any of this.
Even though I try to crack down on people using my uCurrent name, I know there are still people out there selling it. You can't play whack-a-mole forever.

[nuclearcat]

A method to prevent un-authorised clone is to use a dedicated crypto authentication chip. The Atmel ATSHA204A is such a device and it is very cheap (< $0.4) . The creator can program his personal unique keys into the device which can be authenticated in firmware or application software. The firmware or the application program has to be closed source for this to work.

And you will get manufacturing process + BOM a lot more expensive for nothing. If you rely exclusively on this - you have weak spot, as soon as they find way to extract private keys (not only chip, might be in logistics/manufacturing process), you are doomed.
Also i dont like idea adding to product something, that users will pay for, and it is not really useful to anything else than product authenticity verification. I might understand it for something that is critical, like cryptocurrency tokens, but stuff measurement equipment - no.
Most common way - you just need to get to make unique token for each device, preferable linked to ID of MCU or peripherals(and other ID's that are too expensive to change/make same as yours), that are hard to change (like STM32 Unique ID). Keep an eye in each unique part of your manufacturing that you can use for this purpose. Sometimes it is even specific to your manufacturer PCB impedance or trace width
And keep registry of this parameters, and especially unique ids for manufactured devices.
If you dont trust factory - you can have secondary step in token deployment, for example generating second signature on first use. E.g. you can have second signature for same serial number/initial token.
And you dont need to deploy firmware with full verification of token from first moments, you can do it later. Especially that part which rely on ID of hardware First you might just insert unique token and keep it.
Then you add part that will verify it. Most likely they will think "ah this fool trying to defeat us" and will spend resources to decap MCU and copy one of signatures in all their clones.
Most important part - they will invest in that $$$.
Then, you wait best moment and can blacklist it in new firmware/activation. They lost their investment. Most likely they will give up and curse you a bit.
Next bullet - in new firmware release or activation add procedure to verify if token match unique ID's.
If you keep hurting them, no sane person will keep spending money on that and find easier product to clone.

[EEEnthusiast]

The ATSHA204A keys cannot be read back so easily. The creator typically programs these devices and releases them to the assembly house. So they do not have access to your keys. The advantage is that the authentication happens offline without any internet. The firmware will just not work if it does not find the right key. Also the ATSHA204A has a unique ID which is random. That helps you to track every device out there, if you want to.

As you mentioned, the second step of signature verification can be helpful too...

[OwO]

If the firmware just does a if(!checkGenuine()) { halt } that's extremely weak even if the firmware is closed source. Most popular MCUs like stm32 have had their code protection features broken many years ago. That kind of control flow will be very obvious in a debugger, no source code needed. All they need to do is look at the path of execution that the code takes on a genuine device and compare it to their clone.

At the very least you need to make sure the code path executed is almost identical when a clone is detected, and only use variable or register values to disable functionality (e.g. add lots of noise, slow down the UI, etc etc). You don't need a separate authentication chip; the unique chip id on the mcu itself is good, but absolutely don't do something like if(chipid != expectedChipid) isClone = true. Each firmware is unique and tied to the chip id. Have various parts of the code "bleed" data from the chip id into variables, and have other parts of the code "bleed" data from the firmware unique data area into variables. At some point some code will tie the two together and generate values that are affected by both the chip id and your firmware unique data. Keep lots of these variables around, the key here is to not let cloners find all the variables, once a variable is found finding the "correct" value is trivial. Have these variables then affect other variables, for example through checksumming parts of memory, through buffer overflows that "inadvertently" write to unrelated variables. Finally write code that would cause broken functionality if any of these variables aren't the right value.

You can do this even on open source software if you apply the right techniques, see "how to write unmaintainable code": https://github.com/Droogans/unmaintainable-code

[nuclearcat]

The ATSHA204A keys cannot be read back so easily. The creator typically programs these devices and releases them to the assembly house. So they do not have access to your keys. The advantage is that the authentication happens offline without any internet. The firmware will just not work if it does not find the right key. Also the ATSHA204A has a unique ID which is random. That helps you to track every device out there, if you want to.

As you mentioned, the second step of signature verification can be helpful too...

Whole purpose of secure chips is to make sure secret part of key - safe. Programming at creator side create expensive and complicated loop on logistics.
You need to get this chips (pay separately for shipping from distributor), program them somehow on mass scale at your home/company(do you value your time?), insert in acceptable way for factory (so their P&P will be happy).
And you need to be sure factory will accept it.
Many factories wont, first headache dealing with your custom shipment, rather than using their own stock and suppliers they have well established logistic procedures, and what if you didnt stored those chips properly and they will have too high percentage of boards that wont pass QC? Who will pay for it?
All this will end in significantly more expensive device.

[T3sl4co1l]

Don't forget all the other techniques that can be employed:



In a FOSS context, this at best amounts to a verification that the hardware is as expected.  You could test for marginal behavior of the MCU itself, or peripherals or other components.  Might also catch out poor tolerance components, Ali specials and the like.  A POST but not so much for functional integrity as security.

Interesting upshot: if such edge cases can be demonstrated and employed effectively, it at least forces the copycats to use legitimate parts.  You don't get the money, but your customers at least get a quality product (if their copies work at all).

Also, if you employ these techniques defensively -- detecting copies currently being sold -- you won't be able to restrict earlier versions, but you can lock out users from subsequent updates unless they get legit hardware.

All in all, the economy of such techniques is rather poor: all it takes is one little trick to defeat a given measure, while taking exponentially more effort to construct each measure.

Related: it would be cool if it were easy to embed security measures into the PCB.  Unfortunately, PCB geometry isn't easy to read directly with electrical signals -- a VNA, sampling scope, even SDR perhaps (a missed opportunity on the nanoVNA?), but everything else, no such luck.

Well, sort of.  If you could measure the charge coupling between irritatingly overlapped traces (making an intentionally poor layout), you could do a sort of analog capacitive-touch matrix out of mundane signals.  Catch: you need analog sensing to do it...

Tim

[ebastler]

Don't forget all the other techniques that can be employed:

In a FOSS context, this at best amounts to a verification that the hardware is as expected.  You could test for marginal behavior of the MCU itself, or peripherals or other components.  Might also catch out poor tolerance components, Ali specials and the like.  A POST but not so much for functional integrity as security.

I would think that such techniques are more of "academic" interest, since they have significant downsides:

• You already mentioned the amount of work to implement a verification measure which, once you have put it out there, is often easily defeated.
  
  
• You make your product less stable/robust than it needs to be, because you artificially impose tighter tolerances. (Product would still work, but fails the authenticity verification.) This may catch up with you if you underestimate component tolerances or operating conditions, say temperatures, in the legitimate product. And it is bound to really piss off those legitimate customers when the next software/firmware upgrade makes their gadget fail...
  
  
• And finally, even disabling illegitimate devices can make you rather unpopular (whether that's fair or not). End users have paid for their unit, and may not even realize it is a pirated copy. They won't hate the shady dealer or the pirate, but you. Remember FTDI, or the TL866 programmer...

[T3sl4co1l]

Part of that can be mitigated with production test.  Nothing too onerous, so as to cost excessive time/labor, but enough to catch the outliers.  Maintain customer confidence with a simple return or exchange policy.

And yes, even I have been a victim of that; just last month, Windows once again decided it knew better than me and updated my Prolific USB-serial driver.  The dongle as far as I know is legit brand name, just old; they obsoleted their own hardware to spite the counterfeiters.  I keep a hard copy of the correct, working drivers on hand... (and, fortunately it doesn't get bricked like that one FTDI case did IIRC).

Tim

[rhb]

Most popular MCUs like stm32 have had their code protection features broken many years ago.

It may have been cracked, but it's also been fixed.  No one has succeeded in getting the FW out of the F***Tech FY-6600 despite a *lot* of effort.  My V 3.0 borked itself.  After 9 months of promises I got a replacement V 3.1 front panel which I was going to use to compare spectral purity to my Keysight 33622A.  When I powered it up to do that it borked itself again!

What do shops charge to clone board files?

Reg

[galileo]

It seems that quite a few people here view open source as a tool for marketing and a form of virtue signalling.
The goal, one of them at least, of open source philosophy is to get a better product. In software that is self evident.
In hardware the goal is the same but the turn around time is greater and there are far fewer people that have the
knowledge and resources to contribute.
The business side of things: Dave's advice is on the spot. There are some unique challenges but nothing that
closed source projects haven't faced. Closed source projects get "cloned" and everyone does it, from large manufacturers
to small shops in Shenzhen.

[rhb]

My personal interest is user supportability.  I've got a vast amount of Tek and HP gear most of which has full component level repair data available and ROM dumps are readily available for lots of gear.

Eventually the old gear will become unsupportable and the current OEM practices make repair almost impossible for current products.  Certainly impractical.

People have to earn a living.  If they do not, most will either die or self destruct.

Except for the financial conundrum, I can't see why OSHW can't be an occupational option for those who want to pick their design projects.  No great fortune at the end of the rainbow.  No special virtue.  Just a job where someone is able to design things which someone else will take care of turning that work into the money to support the designer.    That's how traditional business works.

Reg

[floobydust]

Everyone's forgotten a supposed benefit to OSHW, is the community. Where a group works on the project- not these one-man band projects which we are seeing. With more resources it allows bigger, more complex designs. It's how corporations do product development.

The big thorn(s) seems to be designers willing to put 100's of hours of work, $$$$ FREE into something only to see it ripped off and Copy Co. making profit.
Or the design group has one member rip off the work and IP only to start some venture of their own/money maker. So you would need some legal agreement upfront and the cash to act on it.

The tools - schematic/pcb CAD software are incapable of external group design. Solo work only please. Mentor and Altium fell flat on that when we wanted to have designers across the globe working on a project. That fantasy also died due to different corporate IT departments unwilling to open parts of the servers to other branches across the globe.
Unlike a compiler/linker which can put all software modules together.

I got a chuckle out of KSGER T12 soldering stations, the controller is copy-protected. It outputs a few hex words (unique hardware ID) and you run a key-gen (on a PC) to generate a passcode, which gets saved to EEPROM. It's not perfect but I guess thwarts the locals. Russians wanted Cyrillic text on menus, disassembled the firmware and figured it all out. Quite the trip through the STM32 object code to find the annoying subroutine call.

[galileo]

User supportability is a worthy cause, shame that most manufacturers these days are basically relying on
planed obsolescence as an aditional revenue stream.

OSHW designers are in the same place OSS developers were 2 decades ago. ATM most individual designers
can do OSHW designs as something that will get them further contracts down the line. Venturing into the business side is
a whole new can of worms.

My personal interest is user supportability.  I've got a vast amount of Tek and HP gear most of which has full component level repair data available and ROM dumps are readily available for lots of gear.

Eventually the old gear will become unsupportable and the current OEM practices make repair almost impossible for current products.  Certainly impractical.

People have to earn a living.  If they do not, most will either die or self destruct.

Except for the financial conundrum, I can't see why OSHW can't be an occupational option for those who want to pick their design projects.  No great fortune at the end of the rainbow.  No special virtue.  Just a job where someone is able to design things which someone else will take care of turning that work into the money to support the designer.    That's how traditional business works.

Reg

[galileo]

Barrier to entry into the community is higher, and creating the community is more complex than the typical OSS project, but it can be done.
For example openhpsdr project that has quite a few sub modules
and the commercial side of that project: apache labs.
High end gear, 3K USD range ...

Everyone's forgotten a supposed benefit to OSHW, is the community. Where a group works on the project- not these one-man band projects which we are seeing. With more resources it allows bigger, more complex designs. It's how corporations do product development.

[floobydust]

Did it work out? I looked and it's (opensdr) is under the TAPR Open Hardware License (“OHL”) that seems to be from 2007.
"Some of the HPSDR projects supported by TAPR required a six-figure investment" 

"John Ackermann, N8UR, is the author of the TAPR Open Hardware License. John is an attorney who specializes in software licensing. He was assisted by a number of both active developers and lawyers who reviewed innumerable drafts and provided valuable feedback."

His 'Toward Open Source Hardware'  article is interesting read.

[galileo]

It has been a fairly thriving community for years now, that produced many designs and the comerciall product
based on those designs is a top of the class product so I don't see a problem, am I missing something?

Did it work out? I looked and it's (opensdr) is under the TAPR Open Hardware License (“OHL”) that seems to be from 2007.
"Some of the HPSDR projects supported by TAPR required a six-figure investment" 

"John Ackermann, N8UR, is the author of the TAPR Open Hardware License. John is an attorney who specializes in software licensing. He was assisted by a number of both active developers and lawyers who reviewed innumerable drafts and provided valuable feedback."

His 'Toward Open Source Hardware'  article is interesting read.

[rhb]

I had a conversation this morning.  I won't go into the details as I've signed an NDA.   But the gist of my response was:

Do you want to design HW or run a company?  Trying to do both is a recipe for misery.  Some people manage it well, but many don't.  Which side of the dillema dominates you?

Perhaps the solution is products which are proprietary for a period sufficient to recover the NRE costs and only then become open source.  I don't know the answer.  I'm just saying we should look for one.  Tek and HP were founded by engineers.  They are now run by accountants and marketing.  Open source is the only way I can see to fight that.

Reg