0
$\begingroup$

There is a device which has three software running on it, the main purpose is the control of some machinery.

  1. a GUI front-end, running on a single-board computer with easily accessible storage (hard disk or SD card, etc.)

  2. a back-end, running on the same SBC as the above.

  3. a microcontroller which drives the hardware, and communicates solely with the back-end. The messages between #2 and #3 are short, in the range of 10 to at most 50 bytes.

Income is solely made by manufacturing and selling the device itself. However, the majority of the development costs are made up by developing the software #1 and #2.

The threat model is someone making a physical clone of the device, implementing their own version of software #3, and stealing software #1 and #2. For our threat model, for the attacker to read the memory (either volatile or non-volatile) of the microcontroller in #3 is to be considered impossible. Wiretapping the communication between #2 and #3 is to be considered easy.

This looks like a standard case of software protection dongle, with its obvious drawbacks: if it's only "check for the presence of the dongle", even if it's based on sending randomly generated code encrypted by the public key on one end, and decrypting it with the private key on the other end, it's easy to defeat with a single change in a single jump instruction to bypass the "if". Anything more would require very complicated solutions, like executing some code meant to be executed in #1 or #2 in the microcontroller instead.

Instead, I'm considering the following:

  • The microcontroller, obviously, will hold the private key of an asymmetric encryption.
  • The commands sent from #2 to #3 will be encrypted by the public key.
  • The replies (mainly status messages about the states of the controlled machinery) sent from #3 to #2 will be encrypted with the private key.

Does this scheme has critical drawbacks? Are there better alternatives?

I can see the following problems:

  1. It doesn't secure #1 at all. (Maybe it could be done by routing it through #2 but it would make it needlessly complicated)

  2. There are not too many types of messages and the messages are relatively short. Especially replies could be attacked, as the state of the machinery is visible, so by wiretapping one can see what kind of message gets generated in which state of the machinery. Yes, the messages could be padded, but not by orders of magnitude (it would reduce bandwidth), and adding random junk seems to be like a form of security through obscurity.

$\endgroup$

1 Answer 1

2
$\begingroup$

This question may be more suitable for other forums (https://security.stackexchange.com/ ?) This is not about cryptography.

I don't think cryptography will help you to secure the devices to protect your IP to the extend you'd like. Once you hand over the hardware to the 3rd party, there isn't much you can do.

Please do not count this as an answer, as it won't help you to achieve your goals. This "answer" should help you to clarify some options

stealing software #1 and #2... change in a single jump instruction to bypass the "if"

So you are already assuming the SBC running the frontend could be fully read and the software modified (this is often so). If you give the adversary this power, you cannot do much about it. In that case "obfuscation" is the best what I can see (any better idea?).

or the attacker to read the memory (either volatile or non-volatile) of the microcontroller in #3 is to be considered impossible

That's a very strong assumption.. though you've linked a "secure microprocessor", maybe you've already have something like that in mind (smart card with crypto features? hms?)

The commands sent from #2 to #3 will be encrypted by the public key. The replies (mainly status messages about the states of the controlled machinery) sent from #3 to #2 will be encrypted with the private key.

Encryption is done with public keys, you could decrypt with a private key. So the microcontroller and the frontend both need each its own keypairs (private and public). PKI encryption will blow the message a lot, it is very performance expensive.

However - when you already came to an assumption that the adversary could read everything off the frontend (including the private key), the adversary could inpersonate the frontend and read/decrypt the messages anyway (accessing the private key of the frontend).

$\endgroup$
1
  • $\begingroup$ I'll move it to security.se, thank you (unless there is a cryptographical solution for the case where the microcontroller and the SW #3 are guaranteed to be secret). For your information, reading the microcontroller is considered impossible according to the threat model. That means, the read protection is sufficient for the task, given the market, the competitors, and the value of the IP. (the expected opponents are not government-level or expected to be equipped with electron microscopes, for example.) $\endgroup$
    – vsz
    Oct 16, 2017 at 9:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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