1
$\begingroup$

My question is related to using cryptography to build clone resistant system.

I am building an embedded system with ARM based commodity hardware board. Thus the intellectual property which makes the product differentiated lies all in software. What kind of cryptographic measures can be used so that the software on my system even if copied out of a genuine product can't be used to run on another board of same type and build a cloned fake?

Basically, some sort of hardware platform authentication is required in software. It should be practically unfeasible to bypass this authentication step by tampering software binaries. What options do I have?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
3
$\begingroup$

That's actually a really interesting question. Mostly because I think there is no really good solution.

However, considering that we are putting more and more computing power into all devices and more and more of their value is derived from the software it seems to be very relevant for the future.

If you want something that can even remotely be called cryptography you should define your security model. Given that you are using a commodity board what is stopping your software from running on a different one of these boards? Clearly nothing, because that's how you are going to produce your devices. So the only option you really have is to keep your software secure in the first place.

I actually think solving this problem is the reason why many devices are IoT devices in the first place. It allows you to put the important parts of the software on the server and authenticate your users when they want to use it. Let's say this is

Option 1: Keep parts of software on your own hardware and restrict access.

Now, there are a lot of other techniques that are somehow trying to achieve your goal...

Option 2: Trusted execution environment (careful, that article is basically advertisement) A way to protect your software from being extracted from the device. Something like Intel's SGX or ARM Trustzone.

Option 3: Make a mess

A combination of the following might give you sufficient security:

  1. Whitebox crypto: Hide cryptographic keys that your software might be using. Afaik all schemes are broken. However there is no shortage of companies trying to sell it to you. (Sad, it doesn't even have its own Wikipedia article.)

  2. PUF: To achieve hardware binding (that's the common term for making something run only on your boards) you use some hard to fake property of the hardware like the initial state of the RAM when turning the device on.

  3. Code obfuscation: Add unnecessary abstraction and redirection and such to your code so that somebody cannot reverse engineer it with reasonable effort and remove all the safeguards you have put in.

Option 2 seems much more solid but a combination of these might help mitigate sufficiently many attacks for you to confidently deploy in a scenario where you don't have a TEE or the option to do things online.

Improve this answer
$\endgroup$
3
  • $\begingroup$ As I understand, ARM trustzone is just a way to partition your processor where small part of the software can run in an isolated domain. Can you provide info about how ARM trustzone can protect software being extracted from the device? $\endgroup$
    – Vakul Garg
    May 10, 2017 at 8:07
  • $\begingroup$ 2) PUF: Isn't initial RAM state used by some people as an entropy source for a TRNG on certain embedded devices? That would automatically preclude it from being a reliable hardware signature. $\endgroup$
    – Paul Uszak
    May 10, 2017 at 10:10
  • $\begingroup$ @PaulUszak The initial state is always different but not that much. So you can either try to extract entropy from the changes or a fingerprint from the constant parts. $\endgroup$
    – Elias
    May 10, 2017 at 13:53
0
$\begingroup$

Implementing copy-protection mechanisms in software always boils down to security by obscurity. You can make your authentication mechanism arbitrarily complex, but if the attacker can read and write the complete software binaries freely, nothing prevents them from reverse-engineering that mechanism and disable the authentication mechanism. Note that if the cost of such reverse engineering is substantial, such copy-protection may be enough. After all, that's how most of commercial PC software is protected.

If you want something more secure, look for hardware security features your board offers. Some chips have write-only memory which cannot be read from outside the chip. You could put your protected bootloader there and make sure the software won't run without this bootloader (e.g. encrypt the software with a key which is stored in the bootloader itself). Sometimes it's possible to program the encryption key directly into the chip, which then is able to run encrypted software. Note that hardware security features may have their own vulnerabilities.

If no hardware security is available, another option is to make it physically hard to extract your software, e.g. by soldering the memory card to the board or covering the (otherwise accessible) interfaces with epoxy compound. Of course, this is also merely a deterrent against attackers who lack sufficient resources and dedication.

Improve this answer
$\endgroup$

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.