Hardware Based IP Protection

If you must share your IP -- *all* of your IP -- then there's little you can really do. I've seen customers "steal" fully disclosed designs (industrial applications) without batting an eyelash -- pay for system #1 and reproduce it, exactly, multiple times thereafter (saving a few hundred kilobucks each time).

You can create a unique component that is essential to your design's operation and sell those for the price of the component plus royalty figure (to them or to yourself). But, as they WILL know what's *in* that component, you have to rely on the cost/effort of fabricating it ("second sourcing" it) to be high enough to discourage their doing so.

In the past, we did this with full customs as the price of admission was pretty steep and the amount of expertise required made it impractical for folks who weren't dedicated to that sort of technology.

If you're going to try to do the same with a "readier" technology, then expect the customer to hire out for someone to replace that effort for a fixed (relatively low, compared to a full custom design) one-time cost.

In a couple of cases, I've had to "share" the entire design with "partners". You can still hide critical details but it gets harder. E.g., I can publish a recipe for baked goods and fail to mention something that makes a notable difference in the outcome; it's absence wouldn't be obvious from inspecting the recipe nor would it's need likely be determined from *making* the recipe.

Folks often look at designs with "school boy" eyes and don't see little details that can be exploited. Like wire has resistance, gates have finite switching times, software modules are placed in memory in certain relationships, etc. If you can leverage any of these in a design, folks will go crazy trying to figure out why their "copy" of your implementation doesn't perform the same as yours.

To cover the possibility of "if my company can't", offer to put the IP in escrow against that possibility. It's how I answer the "what happens if you get hit by a bus" question.

A smart customer should *want* you to continue to be the supplier (just as they would want me to continue to support a product) as you already know the "unwritten details" of making it happen. Taking over *for* you should be something they dread -- esp if it means losing your skillset on future product offerings.

Ask yourself how YOU would tackle a job from that customer where the stated goal was "IC27 is no longer available; can you re-engineer the design to not need it?"

Like I said, I'm fine with them making the boards. In fact, that's my ideal situation, they do all the work, and I get the royalty. I don't think they would "steal" the design, so much. I'm looking for a way to have accountability (in the fiduciary way), so I can verify they are paying for all the units they make, without needing to be intrusive into their operations.

??? They are in the equipment business. They would have designed this themselves, but they don't want to pay to reinvent the wheel when I can do it for essentially free to them. They also have a time frame and are already respinning their own boards.

They won't know what's in the part, if they don't ask. I will turn over to them various files as "IP". But I don't think they will bother with digging through the files until they need them. Will they fully understand what they are looking at? Probably not.

Not sure what you are talking about here.

They can change some parts, but that won't relieve them of the financial aspects, so why bother?

That is useless to me. I'm not trying to get out of giving them the IP. I'm trying to assure I have accountability of the units they produce. I have no idea how this is typically handled in licensing agreements. No company wants to open their books wide. How does anyone verify all use of a license is being reported?

I'm not thinking they want to ice me out, but I don't want it to be easy for them. I want to know how many units they are building.

Yet you don't trust them to tell you "we made N of these"? Why not just sell them the bare boards -- if you don't think they're out to screw you?

If you want to ensure 'N' is an accurate assessment of their "usage of your design" (royalty), then you need to be a gatekeeper for something that is related to N, in some way.

When I was doing video games, we designed a custom BLTer. This added a lot of value to the product so made sense from THAT financial aspect. It did double duty at preventing counterfeiters from STEALING our game designs (a very common practice to see your game in a semi-generic cabinet with just enough of the software changed so that it announces itself as "SomeOther Game").

As it was possible that the BLTer could fail (unlikely) and need to be replaced, after the sale, we stocked them as spares -- priced at exactly the price of the entire game! (cuz a counterfeiter could always buy entire games if they wanted to acquire the BLTers) But, when you returned the "defective" BLTer, we issued a huge refund so that the replacement BLTer only cost you a "reasonable" amount.

Other networked products would "phone home" to report their existence -- tunneling under common protocols (DNS being one of the easiest). But, this requires the device to need/want internet connectivity to function.

Still others wouldn't accept updates unless they were legitimate products (vs. copies).

Then that's a different market than those that I've addressed. Imagine a newspaper stealing your design for printing presses... now they have to be in the printing press business to support the printing press that they "copied" from your design!

Yet, they're already "in the business" (but unable to understand your design)?

Again, would they bother to clone your bare PCBs? Or, the choke used in your power supply?

I.e., how much can they be trusted -- if not COMPLETELY?

Doing a full custom in the late 70's was a high hurdle to meet. A counterfeiter could analyze the code and deduce what was being done *in* the chip. Could even deencapsulate it and look at the die.

But, that's a lot of work. And, takes a lot of time. Games have short shelf lives so if you had to possibly repeat this exercise for each new game release and design a "chip emulator" (even if you didn't actually go to a foundry to design a drop-in replacement) for each, you'd keep missing the market window.

OTOH, if it was a PAL/GAL -- or other COTS solution -- that you just had to reverse engineer and burn copies, that's relatively easy -- in time and money.

DataI/O - FutureNet used to lock their products with PALs that implemented small DFA. Their software would push data at the PAL, clock it and then read the PAL's outputs. If not what they expected, they knew the product was unlicensed.

It takes about 30 minutes to reverse engineer such a "key" given the complexity of PALs of that era (no "buried state"). And, another 30 minutes to copy the software. For an hour of your time, you've got a few kilobucks of "licensed" software.

It boils down to what their goal is and what you fear them doing. If you aren't afraid that they'll hire someone to "work around" your *hold* on them, then you can do damn near anything... sell them UL labels to slap on their product and count the number of labels you sell!

If, OTOH, they decide they want to be free of their obligation to you, then they may be willing to spend monies to defeat your scheme (whatever it may be).

I've had clients who didn't have access to the source code for their product(s). This gave the designer leverage over them for future work. When they got tired of being in that position, I'd get a call and the job of reverse engineering the code. "Oh, and while you're at it, can you make the following changes?"

I've had clients who were locked into buying a key (significant) component from the designer as a means of ensuring he remained in the loop. "How can we come up with an alternative for that component (and cut him out of the loop)?"

Again, if you're just wanting some low-cost, low-effort way of getting *a* number from them periodically, pick something that is really easy for you to supply (low risk of failures) and price it reasonably -- cost + royalty. So, the only incentive they have to come up with an alternative is to cheat you out of your royalty (which you don't consider to be a problem).

Trust. You can periodically look at items coming off their production line and see if the S/N is 9999 but they've only claimed 234 units produced. If they want to keep on your good side, they shouldn't want to screw you.

An early client once told me, "We WANT you to make money, Don. Otherwise, you won't want to work with us. And, we're going to make *more* money off of the work you do for us so why should we want to cheat you?"

If you can find "something" that you can semi-uniquely supply THAT ADDS VALUE to the design, then supply that. E.g., preprogramming (and testing!) MCUs saves that effort for them (assuming you don't program in situ). Or, the devices you mentioned in your initial post -- *if* they are comparable in cost (DM+DL) *or* add some value that would be hard to add, otherwise.

But, this works both ways. You are trying to place yourself in the critical path. So, make sure they won't later complain because

Sorry, I don't understand what you are suggesting. Do you mean instead of selling them product? I think they prefer I sell them functioning boards. Trying to control things by selling them bare boards is probably the worse possible way to manage this. The pcb is probably the easiest part of the design to duplicate.

If you mean when they want to take over production, I'm pretty sure they will simply refuse and built the boards from the Gerbers I sent when we agree to the deal.

That's why I'm looking at designing in custom parts from places like Greenpak. I need to find out if the parts will *only* have my markings and not Greenpak markings. If they will sale these through distribution, so no one reports they are even Greenpak parts, this may work well. It's a custom part for my company, and that's all they need to know as long as the lead times are not a problem.

Warranty failures are our responsibility. I'm not sure what you are saying about this. We don't have many warranty failures, nearly zero other than a connector problem where they returned 8 units once.

We don't have the phone home option. Our board has too little "smarts" to phone home and no connection to do so. Ironic, in that we are part of an IP network. Even if we could figure out how to hijack packets, the IP systems are mostly self contained and not connected to the real world.

I never said they *couldn't* understand it. I was told my my contact, that they talked to their own people about spinning their board to replace mine (just to make it clear, my current board can't be built anymore without a respin, due to component EOLs). No one knew much about what it needed to do, so they punted. Sure, they could figure it out. It's not *that* complex. But I put some many months into designing, debugging, and qualifying the board. Then I developed a fairly rigorous test procedure to assure they are working fully when they are shipped.

Yeah, they could do it, but they realized it's better for them to let me do it and continue buying from me, unless I make that too painful. It's hard to get an idea of what "painful" means. The people who would do the design, are removed from the people I'm dealing with. That can work to my advantage, since the "build" group has already said to let me do it.

I'm trying to simply include a part, that will give me visibility into how many units they make/sell. I don't know how they would build units without "cloning" my board. I think you are off on some tangent.

Where did I say I didn't trust them? I'm trying to figure out accounting.

Good thing I'm not using PALs. I thought PALs were a thing, for about 15 minutes in the early 80, or maybe late 70s. I hardly even saw them on the market.

You aren't really grasping the issue. There is no "hold", in a technical sense. I have a design that I will let them build if they can't get product from me. I need to negotiate what "can't get" means in a measurable way. Their CM has sent POs with a requested "on dock" date prior to the date of the PO! That's a high bar to clear! So this will need to be a negotiation. I had a round of negotiations previously and ended up with a thoroughly f*cked up agreement.

The agreement we sign will have to require them to pay royalties on any product they sell that is substantially similar, i.e. a derivative product. "Substantially" will need to be well defined, but I used an opamp output circuit with a synthetic impedance. That is a key feature, since they needed to drive some higher voltages, close to the 12V rail, into a 50 ohm load. To get the 50 ohm output impedance and a wide output voltage range required this special circuit, or something very similar. I'm not sure they still need that, so maybe this is not such a great detail to rely on.

That's always possible. It can be hard to get around the contractual details however. If this does occur to them, it will be somewhere down the road. I think, in general, this is not a company that has any interest in screwing their suppliers.

Any protection scheme can be defeated. I'm looking for something that raises a higher bar than a handshake.

Perhaps I've not explained it well. That's what I've been talking about with the Greenpak device. I've identified two of them. If I can get them without any reference to Greenpak or Renesas, and with a custom part number, then sold through a distributor, I can at least know how many they are buying... perhaps. I think there would need to be a small royalty on the parts, just so I get an accounting of all sales quantities. This gives me the visibility into the production of this design.

How do I get that visibility? They could be reporting to me they have sold SN 1234500 to 1234599, meanwhile, in another group, sold SN 1234600 through 1234699 without reporting it, because the left hand doesn't know the right hand exists!

I was in a company who got fined by the government, because one group asked for a quote from TI on a DSP, which came back at a lower price than a quote on the same part for a production run. The government claimed defective pricing since every part of the company should know about the others!!! That's why companies have rules about how things are done. The larger the company, the more the rules.

You keep talking about cheating. I've never said I was worried about cheating. I don't think multibillion dollar companies "cheat" very much.

You aren't worried that they will be making boards (presumably, including purchasing components to do so).

You aren't worried that they will "steal" your design -- layout a different board, make some component changes, etc. and "call it their own".

But, you *don't* trust them to accurately tell you how many of them they made/sold. Their accountants are crooks? Their manufacturing facilities don't know how many they shipped? If they are not incompetent, then clearly you have a trust issue.

What is the minimum level of trust that you will be satisfied with?

You claim it would be too easy to clone a bare board -- that suggests you don't trust them to buy them from you, exclusively.

You claim you don't think they would bother to figure out what's inside these "house partnumbers" that you are buying COTS and "customizing" -- despite having all of the information they need to do that (or hire someone else to do that for them).

Clearly, there is something between these two approaches that would be a high enough hurdle for them to assuage your "concerns" as to the accuracy of their reporting. Only *you* can determine what that level would be.

Exactly. Doubly so for someone reading a USENET post.

If you opt to provide BARE PCBs to them (and COUNT the number of boards that you thus ship as a means of tracking their production), would you worry that they might clone the (bare) boards to avoid paying you? If you are selling the bare boards for the cost of the board plus your royalty, then the only incentive they would have to clone them would be to cheat you -- there's no *money* to be saved as you are selling the *board* at cost! (even if they could get a better price for the board by combining it with other orders, their savings wouldn't be "big numbers")

OK. So, you DO trust them.

So, you pick up the phone on the first of each month and call their accounting department and ask, "How many units did you sell/make last month?" You *KNOW* he will be honest with you. And, he must know what his business is selling else they'd never survive an audit. So, just accept the figure he provides, thank him and write up an invoice.

Do you think the devices you are using are magically more difficult to reverse engineer?

But, we already know that you trust them. So, they will dutifully tell you of any product that they feel is substantially similar. Their lawyer will be very precise (based on your contract) in quantifying what that means -- to them. He'll also want to make sure they don't misreport the numbers and expose them to a lawsuit.

And you're hoping their engineers aren't smart enough to notice what you are using. Or, if they do, that they are too lazy to take steps to buy the same part you are buying and customize them in-house.

Or, that they wouldn't consider something as "unethical" as that!? (but shooting bare boards doesn't insult their sensibilities!)

So, you're worried about incompetence? That a multibillion dollar company doesn't have mechanisms in place to keep track of what they've sold?

I know (firsthand) of a $10B that did exactly that! Foolish decision, on their part, as it forced them into a business that they didn't want to be in (because word gets around as to how they "operated" which makes others cautious about selling them products!)

Figure out what you think they would be willing to do ("morally") to deprive you of an accurate count -- intentionally or unintentionally. Then, target your solution to that level of "suspicion" (if you object to the notion of "mistrust").

If you trust them, then selling bare boards -- or UL labels -- seems an ideal solution. Very little investment on your part. And, they

Sometimes I have trouble making myself clear. No, I'm not worried they will out and out steal my design, such as rolling it into the motherboard, my board plugs into. Nope. I have all confidence if they wanted to do that, they would simply do it and not need to worry with figuring out how my design works. I have complete confidence they would see stealing my design as the complex, risky and expensive way of doing it. How do I know? I've been told they already looked at that option and rejected it.

I really don't know what to make of you. You seem like a fairly intelligent guy, but you don't seem to know much about large companies. I've been dealing with this outfit for 14 years now and I've seen so many examples of people only seeing their portion of the elephant. They have managed to raise the price of my board, not once, but twice! Not me, but THEY raised the price. I'm not going to correct them for sure. Even at the management level, they only see, what they can see from their cubical. The highest managers simply never look down, so they don't even know I exist!

That would be an 11.

That's a strange thought process. I don't follow at all, and I don't think I care about an explanation.

I never said any such thing. You are reading what you want to read. Try reading what I actually write.

So? Do you somehow think I am asking you to make my business decisions?

Yeah, I'm sure.

I really must be terrible at explaining things. In the first post I said, "They also want all IP so they can make the boards themselves if my company is unable to." If you failed to read and understand that, you will not understand that the customer does not want to buy PCBs from me. They want to have the option, if I fail to deliver in a timely manner, of building the boards without me.

They don't say they want to buy PCBs from me. They would want to build the boards themselves, which would mean they want to buy *all* the parts and have me out of the schedule. Is that clear?

When ifs and ands are pots and pans, there'll be no need for tinkers.

What you write here, makes no sense. Perhaps you forgot to type a sentence or two?

Trust, but verify. I've seen these guys make so many mistakes. Only an idiot would suggest I need to do nothing to double check on their use of my design.

Why would I compare this to that??? You seem to have gone off the deep end here. Strawman arguments.

Again, you fail to understand the difference in trusting a company, and expecting them to not make mistakes.

What makes you think they would even try to understand what I designed. If they are taking over production, they will be building the units, not worrying with how they work. One thing I've learned, is that I am good at test sometimes, because the problem is such that an intimate knowledge is a big benefit. Other times, it just gets in the way. Production folks don't try too hard to figure it all out. They just find the repetitive production problems and try to get the failure rates low enough, that they can toss out units that don't pass test. I got to see that first hand with my current CM. Their senior guy can fix anything, once he's worked with it a bit.

Yeah, if they can't figure out that they paid X a year ago and ordered a few units with a mod at a higher price, then pay the higher price when they try to reorder the basic board...

Their system integrator didn't want me to charge them the 2% late payment fee, so he said raise the price by 2% and give them 60 day terms, so they can pay past the 30 days and their customer will pay the 2%.

There are no UL labels and they would have no reason to buy bare boards from me. But thank you for the conversation, even if it had little to do with my original question.

And didn't I just say that in the sentence above? Here, I'll repeat it in case you missed it: "You aren't worried that they will "steal" your design -- layout a different board, make some component changes, etc. and "call it their own". I am spelling out what *I* have taken from your comments. I have no idea if you are right or wrong -- nor do I care. I am simply restating what I think you have claimed.

And, using that to explain why my suggestion "fits" with those assumptions. As below:

I've worked for firms with 4 to 90,000 employees -- but never more than

So, you *don't* trust them. One minute you do, the next you don't.

Let's make this real simple.

You "don't have faith in their ability to accurately pay you what you are due". Call that mistrust, incompetence, paranoia, <whatever>. I don't care WHAT you call it.

Based on that, you want some way to reassure YOURSELF (they don't seem to be the ones complaining about "accounting", here) that you are getting what you are due.

The only way you can be assured an accurate count is if they have to include something that YOU control (and can count!) in each device produced.

But, you don't want to do too much work -- e.g., you don't want to have to produce the *product*!

I advocated supplying something ESSENTIAL to the product (something that they can't decide they can omit) like the *bare* PCB. I reason this to be easy to do *correctly*. Take very little effort on your part (you just call the board house and have them run another lot). Relatively low investment (you could likely afford to produce large quantities and just "schedule delivery" at whatever rate they choose).

But, you're afraid they could just make their own bare boards and distort

If you *trust* them (not to intentionally try to "cheat" you or to be bad at counting), then there would be no reason for them to find an alternate supply of bare boards. *You* are the sole vendor for that part in the BoM.

INSTEAD, you think you need to sole-source a higher-tech component in the hope that they can't/won't *discover* it's just an XYZ2000 purchased from ABCCo.

This seems inconsistent. Answer (to yourself) what your response would be if the customer "discovered" that you were just using rebranded XYZ2000's in your design -- esp if you had included any markup beyond the price they (with their MUCH greater buying power!) could obtain the same parts. Would you be just as fearful that they might source their own parts as you suspect they would the bare PCB's I'd suggested?

Browse the FCC database and notice how many folks have sanded part numbers off of the prototypes submitted. Do you really think no one knows (or can find out) what those parts are? Especially if given schematics for the boards?

You seem to be talking yourself into a conclusion that you want instead of actually being interested in what others have done.

Go for it! You may get lucky! At least you'll know who to blame...

But *do* expect someone to sort out what you've done; and, wonder what they'll do with that knowledge! Will they think less of you (as a supplier? as a person?) for your deception? Or, will they (someone) take it as a challenge to show how they can make "your" chip from a COTS device and a bit of (automated) labor?

I'm sorry, I do appreciate having someone to bounce ideas off, but you seem to have gone out on some tangent that I don't get.

"But, you don't want to do too much work -- e.g., you don't want to have to produce the *product*!"

I have no idea where you are getting THIS! I believe I have said explicitly (if I haven't, I'm saying it now), I much prefer to manufacture the boards and sell them. I believe this will get me the most profit. I also believe I can set up manufacturing so that I will not need to be involved in any significant way. What I do right now, is to receive a PO from a customer, get a quote from my CM, relay the schedule to my customer and accept the order. My CM then makes the products, and drop ships to my customer. I have to prepare the paperwork for the shipment and invoice the customer.

The current order had huge complications because one part is pure unobtainium now, because the factory burned down. When I got the order last year, we could still buy them at high prices. Eventually, the prices became absurd and the last reel was tarnished to the point we rejected them. So no more of the old boards, ever.

The new design will be essentially the same with a different FPGA and the unobtainium part. A couple parts that are no longer required will be deleted. Other parts may be replaced with easier to find alternatives and/or second sources. I did a bunch of that on the original board, which is what let me make it for 14 years.

The new board will have a new test fixture based on the customer's product itself. In fact, if they wanted, we could combine testing of their mother board with our daughter cards and provide them with complete units, saving them the work of integration.

There will be no shortage of work to get these units in production. But that's where the work ends for me. After that, I only need to push paper. I can even remove myself from that, but getting a royalty from my CM and letting them take the orders and handling all the paperwork themselves.

I'm sorry that I can't make myself clear to you. I think we've had this problem before. You do have a very active imagination, but once it turns to a thought, it is hard to put on the right path again.

One of the simple ways is a single unreadable programmable component that you retain control of and supply one per unit made. Once you share your secrets with a third party they can clone the thing as they wish.

The other is require an activation code that only you can supply for each unit. I have often done that for bespoke software. How sophisticated it needs to be depends on the size of the market and the level of attack you anticipate being levelled against it.

It seems that someone has cracked the MS Office keys.

Even bespoke chips offer only limited protection against those with very deep pockets. Cameca ion probes can be used to read back a chip mask set layer by layer if you are determined and have deep enough pockets.

I used to know a firm in Silicon valley that specialised in it. We supplied MS kit to them and sometimes shared software components.

The other bespoke trick is to include code that exploits a known defect or quirk in the target hardware platform so that any attempt to change it will result in performance problems or non-functionality.

I recall one based on the timing difference of TEST vs AND on x86 and another based on a page zero exploit on the 6502. Deliberately designing in a race condition vulnerability for any cloners to fail on. One of them was entirely accidental but proved incredibly effective!

Right. If the customer wants *all* your IP then it seems better to charge appropriately up-front than to worry about royalties.

Sort of like if your girlfriend or wife tells you "I'm going to be going out for a bit with Larry from the office next door on Fridays. Just a friendly sort of thing, I'm not interested in him romantically. But he's just very handsome, funny, and rich, too!"

You can hope for the best, but probably best to assume the worst

There are some markets where this isn't possible; where you *must* disclose a design in its entirety (e.g., regulated industries). Or, where some assurances must exist of continued availability of the design documents even in the face of your (or your company's) demise.

But, usually, the customers there aren't interested in going into the equipment business against you. Rather, their interests lie elsewhere... USING your equipment to achieve some other goal in which they are expert.

If you are designing a product for *them* to peddle (as opposed to designing a product for them to *use*), then they need to be able to support it.

I give non-exclusive license to customers so I don't lock myself out of my own work. E.g., I'd hate to have to reinvent every design just to ensure I don't step on some portion of a design I've done for a previous client. They have to trust me not to reproduce "their" product for someone else (which would be pretty unlikely, esp in light of below). If they object, I ask them if they want me to reinvent everything I may have done for PRIOR clients before incorporating it into *their* design? (do they want to make the project artificially more complex, costly and time-consuming? Ah, I thought not!)

I'm not keen on "ongoing relationships" with clients. I give them a hold over me in the event of a *flaw* in my design/implementation. But, ONLY so. No, I'm not interested in making endless changes to the product for you. Or, coming up with version 2 (god, what a colossal bore that would be!). Or, possibly working on some similar product -- I'm off learning something (technology or skillset) entirely new, and exciting! THEY chose to plant their feet in a particular market; there's no reason for me to follow along!

If you *think* you've found a discrepancy between the specification and my implementation, I will try to reproduce it using *my* codebase (no, I'm not going to hope that the code you give me is truly *as designed* without the "benefit" of your subsequent modifications) on *my* prototype. If I can't reproduce it -- but can, readily, on YOUR (current) hardware and (current) software, then it seems reasonable to assume it's YOUR problem -- and, no, I'm not interested in helping you find it. That's a job for your employees! "S*it work". THEY created the problem (cuz it doesn't exist in my release) so let THEM find/fix it!

So, I don't want a hook into them anymore than I'd give them a hook into me! "Let's each move on" Hopefully, you'll make a shitload of money on the product and speak well of me to others (when asked *or* without prompting)

The OP is learning the downside of continued reliance on a contractual relationship for payment. I just make sure their final check clears and wish them all the success in the world -- or not. "Not my problem" as I don't want to rely on their ability to market, their assessment of what the market really wants/needs, the efforts of their competitors, etc.

Perhaps not that dark.

I *expect* people to alter, evolve, etc. my design AFTER I am "done". I suspect they will learn -- from their market -- of changes and additions that would make THEIR product more marketable, etc. So, I wouldn't expect to find *my* implementation in production, later.

This is especially true of proof-of-concept projects where the goal wasn't to produce a saleable product but, rather, demonstrate that a technology was practical and how it could be exploited. SOMEONE ELSE will figure out how to package it, *after* me.

I don't want to be in a position where I'm hounding a client over their use/misuse of a past work ("Hey, you have to pay me if you want to use that code in a different product's design!" Note that things like RTOSs and custom I/O subsystems can have great "repeat use appeal") -- or, an accounting of how many units they've built!

Just like I don't want them hounding me for yet-another-change to the product/project.

"Live long and prosper"!

Yes. Dallas (?) made some "unique 1-wire coins" that had individual codes that you could recognize in software -- with a suitable polynomial. This allowed you to ship a coin as an activation token for your product. Or, as a REactivation token (e.g., for timed licensing)

I install encryption keys *after* the manufacturing test code has been used to verify the device's proper operation. So, I can farm out production and never divulge any of my codebase to the manufacturer "Feel free to copy my design! Sell your units at half of the price I charge for the genuine article! Sadly, my code won't run on YOUR copies!" (your customers may not yet know it but soon will! "I'm sorry, but I don't have a record of your purchase so why do you expect me to support you? Contact the vendor from which you purchased your unit for support...")

But, if they can read the source code, then they can *see* what you are doing. if they want to eliminate that (artificial) dependency ("to cheat you"), they can easily do so.

OTOH, if the project is big and you were wise enough NOT to have a

Will they notice that object foo and object bar overlap -- defined during the *link* stage? (so, no explicit reference to this fact in the sources) Will they remember that memftnA() handles overlapping objects in one particular way while memftnB() behaves differently? (e.g., memcpy vs memmove). Or, will they gloss over those little details because they THINK they know more than they really do! And, in the process, miss a data relationship you've deliberately encoded into the product?

The true challenge is doing this when "everything" is disclosed. I.e., when someone can read the code that checks the token and see how validity is confirmed. They can just bypass this check and defeat the reliance on that code.

You can build a service into your "system" and require the device to provide a credential in order to access that service. But, same problem. And, how do you deter cloning of a "legitimate unit" (watch to make sure two of the "same" unit never accesses the service multiple times, concurrently?)

ISTR Sun used to broadcast queries on a high-numbered port to try to identify other local nodes that might be sharing a license, "illegally".

I thought most license hacking was being done by sharing "known good" keys *or* patching binaries to disable the validation tests. (of course, the latter can be made very difficult without access to sources)

It used to be that you could just obfuscate the devices being used. But, undergrads at local universities can now take photomicrographs of die and identify manufacturer markings that way. The equipment is already in place along with folks skilled in the techniques. "Have your *kid* do it..."

Yawn.

We used to (re: the video game competitor across town) come up with "clever" ways of packaging the MPU or other key components to discourage folks from seeing what was inside (via xray, solvent, etc.) Burying BBRAM with factory loaded "keys" in a potted module. Embedding "wires" that *looked* like they connected X to Y. Embedding plastic conductors that would dissolve with attacks on the encapsulant. Etc.

But, you can beat most of these with a little patience. Esp if your (e.g., counterfeiting) business depends on doing so! And, esp if your adversary relies on a single solution for all his protection needs!

The full custom raised the bar considerably. It was a relatively common practice; you'd be at a design center and notice other competing firms in the next cubby. (Express an interest in their work -- just not TOO much interest!)

If you were smart/strategic, you made the custom DO something beyond just deterring counterfeiting.

E.g., Atari (?) had a vector-graphics processor that only drew

But, beyond novelty, you have to work to find a NEED for that capability!

OTOH, having the ability to scale and rotate objects in real-time opens doors that are similarly challenging yet represent real value!

There was an Aussie firm that specialized in reverse engineering around the video game heyday.

But, for things like video games, you typically only had to reverse engineer a couple of games to extract the core hardware systems that were reused over and over. And, if copying the software was just a matter of dumping some ROMs, *you* could offer a "universal kit" to unscrupulous "operators" with deep pockets but short arms.

"Here's some artwork/decals for the UNIVERSAL cabinet and here are the ROMs for the new game!"

How do you, as a legitimate developer/manufacturer, compete with that -- esp when it's YOUR IP that they are peddling?!

Exactly. But, you're relying on the adversary not knowing about this. Hence my "school boy" comment, up-thread. They can *look* at the design (hardware and software) and THINK they understand it. They then make minor changes (to add their functionality or disguise their theft) and wonder why it suddenly doesn't work anymore!

Again, in video games (the most common place I encountered these mechanisms), you'd do things like "draw" the game's name on the screen. This would end up leaving the equivalent of "the drawing cursor" (a purely invisible software construct) pointing to a particular spot in display memory. 10,000 opcode fetches later, you could casually verify that it was at the expected place. The thinking being that a counterfeiter would change the text being "drawn" which would have the side effect of leaving the cursor somewhere *else*. Ooops! All those opcode fetches later, the drawing event is ancient history.

The trick to all such schemes is to never have a line of code that says: if (!everything_ok()) crash(); because it becomes a behavioral marker for folks to determine when they have successfully "beaten" your scheme. Instead, you factor the test into your normal behavior: result = intfunction() + everything_ok() result1 = activity1(result) activity9() result2 = activity2(result1) etc. with the expectation that everything_ok() will yield a specific value "normally". If the incorrect value of everything_ok() results in a minor change in behavior (e.g., the player's character's speed increases a bit more than expected or the direction of a projectile doesn't accurately represent a pure reflection off a surface), then the player (who is initially the counterfeiter checking his work) doesn't notice it. Until these effects compound and leave the player angry because "the machine cheated" (or crashed).

But, WHEN did the effects first manifest?

You can do this by quietly leaving the CY in a particular state and (also quietly) relying on that fact some number of opcode fetches (or subroutine calls) later. Or, some operation partially completed (e.g., knowing when task switches will occur and peeking inside a partially completed operation to use a "half baked" value -- despite this being the sort of behavior one is taught NOT to do!)

I've used schemes like relying on bus capacitance to "hold" a value for a specific number of machine cycles so any alterations to the value being held or the code executed between points A and B would result in "incorrect data" being present on the (floating) bus. "Load" the bus differently and all bets are off.

With a distributed system -- or any multiprocessor -- there are lots of opportunities to hide "information" in the interactions between them by exploiting temporal relationships that you can "fail to document" (and identifying them from an examination of the code is painful).

The problem with all such schemes is that they add cost to the development cycle (and possibly material costs and/or performance hits). Ideally, you want to add *capabilities* to a design while you are protecting it. So, your "cost" results in gains and not just "overhead".

When it came time to "install" the JapZappers (coding hacks designed to complicate counterfeiting by running continuous checksums over the code and injecting the results of their computations into the code's actions, as above), you had to be extra careful because the lack of a go/nogo "everything_ok()" test meant you could never reassure yourself that you had done this correctly. YOU were a victim of the same stealth that you were using to make the counterfeiter's verification of his hack impossible!

Putting these sorts of things in place to trip up a *partner* is doubly difficult because, in theory, you are working together and aren't on the lookout for such subterfuge. But, as devices get increasingly complex (complex: too big to fit in a single brain), it gets easier to do so -- esp against "average" engineers (who may be trusting as well as lacking in detailed observation skills)

It's actually a delightfully challenging mindset! One that many folks are incapable of adapting "with gusto".

E.g., I don't share my baking recipes. Well, I *appear* to but always omit certain critical details that have a big impact on the resulting product. I've spent decades (literally hundred of iterations) "perfecting" some of them and the idea of just giving away all of that effort/experience doesn't sit well with me (I'll bake something FOR you but I'm not going to teach you how to reproduce my efforts! I'll show you how to make something *close*, but it will always be a disappointment when you consult your memory of my version! :> ).

I have become *so* good at hiding details that colleagues wives will ask to WATCH me bake something during an offsite, "there" or here. ("Yours always tastes so much better than when *I* make it!") and fail to notice the critical bits, beyond "ingredients". Despite watching me measure ingredients, checking the temperature of the oven, timing the bake, etc.

"Ah, but did you notice WHICH eggs I pulled out of the egg carton? Don't they all *look* the same? And, when I removed the chalazae, did you notice how much of the yolk/whites I removed (as a side-effect) in the process?

Did you notice the cavalier manner in which I measured certain ingredients (when did I use a level teaspoon vs. a heaping one?) Which were cold vs. room temperature? How much I let certain things thaw (while you thought I was just "busy doing something else")?

Did you notice how long I let the mix sit at certain points, while I appeared to be busy fetching other ingredients out of the refrigerator? (The chemistry continues despite my apparent lack of interest.) Or, which rack I placed the items on? Or, how large the portions? Did you happen to note how humid it was on that day? Or, the temperature in the house as I was letting them cool?

"Gee, these taste really good! Now I *know* how you make them" (yes, *exactly* as I told you -- cuz you've missed all of these other undocumented details and will continue to miss them when you next attempt to reproduce what you've observed! But, you'll get frustrated and won't ask to watch me a second time! :> )

Most of the projects I've worked on in my (relatively short with respect to design, I worked in the music biz for most of my 20s and early 30s) career have been fairly simple ones that I've felt comfortable enough saying "Pay me the agreed price and the design is yours to do with as you will" and handing off. It's the terms a number of clients tend to prefer, I charge them one-time-big-price and they seem comfortable with that.

But I'm starting to encounter situations with more complicated projects that as you say, incorporate significant building blocks I've used before, where I don't want to give away the farm.

Do you have a set of contracts you use for different situations? I should probably consult a contract lawyer to draw something better up than what I've been using.

when say it is easy you obviously never did anything like it....

they have the source so they can just remove any "activation" checks

I think it's easier. You charge enough to make it worth your while. THEY know what it will cost them. If they go on to make big money on the product, so be it. They'll have been happy to have worked with you. If the product flops, its hard for them to rationalize that they paid you too much (they knew the price, up front).

I like fixed cost contracts and not time-and-materials. It lets me plan WHEN a project will be over. And, I've heard too many gripes from clients about other experiences where the project just dragged on and on (and cost more and more!).

Sure, it can drag on and on because the client couldn't make up his mind as to what he wanted. But, the consultant should have some discipline to *focus* the client else it sure looks like the consultant is *bleeding* the client.

My contracts are simple: a list of deliverables (schematics, number of prototypes -- I get to keep one, specification, source code -- if any, test/acceptance criteria), a license to use the design elements, a hook to ensure I will "promptly" repair any defects in the design identified after sign off, indemnification against any patent/license infringement that may occur, payment amount and schedule, client will purchase and own any tools *I* deem necessary for me to perform that work, etc.

If I am being asked to reverse engineer something, I make the client assert his ownership of the technology that I'm being asked to reverse engineer.

Not a lot of flowery language but, rather, more of a bulleted list. I don't think reading a contract should be difficult and require lots of nitpicking over what something "really" means. I've not found any client lawyer who objected to anything enough to throw a monkey wrench in the deal.

I'm usually dealing with technical people and their focus is on getting the job done, not wasting time hashing and rehashing documents (cuz that takes time and costs money, even if you don't see a figure associated with it). Make this look too much like a

and neither of those does anything because they have the source and can easily remove any checks

customers don't have the source so they can't remove the lock and it is permanently connected to the internet so can be remotely disabled

and totally irrelevant to the topic

...

Exactly my original point - unless the secured device implements some critical function, the design can be changed to eliminate the need for it.

Ricky is still approaching this as an engineer, not a business-man. Don and I have both been telling him that you can really only approach this problem with trust and contracts, not hardware. Unless he makes all the hardware himself.

CH

We have handled that using Escrow services. Simply archive a virtual machine with all the design files and lock it in the safe at an escrow agency, and write the appropriate agreement dictating under what conditions they can open the safe and to whom they should give a copy of the contents.

Exactly right. Consider their motivational model, and write suitable contracts. Locked hardware is just an invitation for them to break it.