2
\$\begingroup\$

Problem

A small company is trying to outsource manufacturing to a small 3rd party factory. The products are consumer grade electronic devices and do not require any special certification besides CE and FCC class B (although I don't think it's relevant to the problem).

The factory is required to pay a certain fixed royalty to the company per every manufactured device.

In order to collect the royalty, the company needs to have a reliable way of telling how many devices have been manufactured in a given amount of time.

Conditions

  • Manufactured devices run non-trivial firmware provided by the company.

  • The devices are also equipped with a trivial custom bootloader.

  • Devices have no means of communication with the company on their own (not connected to the Internet, cellular networks, etc).

  • Every manufactured device undergoes a certain automated testing procedure, which involves the device to be connected to a PC that runs a special-purpose software developed by the company. This software also flashes the firmware.

  • Device's microcontrollers have globally unique 96/128-bit ID. Actually, the microcontrollers are STM32F0, STM32F1, STM32F4 and LPC11C24, if that helps.

  • Projected quantities are up to 500 devices monthly in total.

  • Shipping any hardware between the company and the factory is not feasible.

Assumptions

  • The factory is a legal and reasonably honest business, they will not go at great lengths in order to exploit the process for their benefit.

  • Number of manufactured devices equals the number of sold devices; amount of defect products is negligible.

Solution

One of the first solution that comes to mind is to extend the testing software mentioned above so that it follows the following algorithm:

  1. Once the device is connected and before the main firmware is flashed, the application requests the company's web API (possibly via secure protocol), sending it the unique ID of the device.
  2. Upon reception of such a request, the company's server stores the unique ID in a database (with some metadata such as date/time, etc).
  3. Once the confirmation is received, the firmware will be loaded.

This seems to provide the company with required data.

The drawbacks are obvious: the application can be patched in plenty of ways, the host PC can redirect the queries to a third-party server, the factory can disregard the testing application completely and implement their own alternative instead, etc. Not to mention that the manufacturing will halt if the company's web API is down, although it shouldn't be a frequent problem nowadays.

Questions

  1. What approaches to the problem exist in the industry?

  2. Can a more reliable solution be implemented with OTP memory (some of the listed MCU have it, other products can be equipped with a dedicated OTP chip, although it is undesirable because of cost efficiency reasons).

  3. OTP/cryptography aside, is there an obvious way to improve the described solution that I'm missing?

\$\endgroup\$
7
  • \$\begingroup\$ They have to pay you to manufacture your product?? \$\endgroup\$
    – Passerby
    Commented Oct 3, 2015 at 16:22
  • \$\begingroup\$ Yes, since they also sell it. The only income our company has is the royalties from licensed manufacturers (we're fabless). \$\endgroup\$ Commented Oct 3, 2015 at 16:31
  • 1
    \$\begingroup\$ Look up trusted platform chips \$\endgroup\$ Commented Oct 3, 2015 at 18:16
  • 2
    \$\begingroup\$ That's how for a long time at least apple enforced their compatible accessory program. You had to buy a tiny chip from them that the software checked. There are general market trusted platform chips out there as well. \$\endgroup\$ Commented Oct 3, 2015 at 18:19
  • 1
    \$\begingroup\$ Legal rather than electronic technology, but usually such licensing contracts include an audit provision. \$\endgroup\$ Commented Oct 3, 2015 at 22:45

1 Answer 1

1
\$\begingroup\$

Provide the manufacturing company with a fixed number of preprogrammed microcontroller. Many first and third party distributes provide a programming service. Because the firmware is non trivial the factory would not be able to produce any more product then the chips they have.

\$\endgroup\$
1
  • \$\begingroup\$ Preprogrammed MCU are not an option, unfortunately, since the factory will have access to binaries. Should have mentioned that in the list of conditions. Also, this approach seriously complicates the logistics. \$\endgroup\$ Commented Oct 4, 2015 at 9:50

Not the answer you're looking for? Browse other questions tagged or ask your own question.