7

Is there a way of locking a Linux system to work with a specific (pre-defined) hardware only? I am developing a commercial product and want to make it a bit harder for someone to clone the whole working system so I am thinking of tying the SW and HW together so that one would need special SW image for a given HW.

My exact scenario is an embedded board (Raspberry Pi 2 with Raspbian) that boots from an SD card. The problem is the SD card can be easily exchanged between boards so I would like the SD card to only work with a single particular board. I will be using a custom binary (which I compile myself from C++) to provide the functionality of the product. I could simply check for specific HW ID (RPi serial number or MAC address) from my binary but that would still leave room for someone to fake those HW IDs on an OS level and then start my binary on top of it.

I guess encrypting the whole system may provide a bit more protection but the key (be it a SW password or a HW ID) has to be saved there too for the system to boot so if an "attacker" finds it he will decrypt the system image anyways? The system works in read-only mode.

What is the best protection I can get on a system with exchangeable main storage? I guess an embedded storage may be a bit harder to read but probably again won't provide 100% protection?

EDIT:

Regarding my reasons for the protection: my scenario is an embedded computer vision device that has no direct UI (image output to display or monitor) but only does an acoustic beep warning in certain cases. I don't mind SW piracy as long as it at least brings some say "product promotion" or marketing (like it is the case with pirated Microsoft Windows for instance - even when pirated it helps to promote the product since it is branded and the logos are all over the UI) - but this simply is not my case. Cheap Chinese clones of ELM 327 chip are good examples of embedded SW piracy - the SW was read out from the PIC controller and is now sold very cheaply.

Community
  • 1
Kozuch
  • 209
  • 1
  • 7
  • 1
    I believe that would've violated the GPL, which requires freedom of use and source code, so no it wouldn't be possible even if it's technically possible. The other way around though, locking machines so it would only run certain software that you've cryptographically sign, is certainly possible, it's called secure boot. Look up about UEFI. – Lie Ryan Aug 30 '15 at 10:54
  • Tying an OS to a certain hardware is usually done using TPM chips. Have you already checked in this direction? BTW @LieRyan concerns regarding the respect of the GPL seems valid though as long as you intend to sell your device. There was large affairs in France years ago concerning ISP's Linux-based home routers, ISP's being requested to publish their source-code. – WhiteWinterWolf Aug 30 '15 at 11:02
  • I looked into TPM a bit but I am a real beginner in the security area... No idea if RPi has a TPM. Another way may be a USB HW key, which may bring additional cost but should they work I would consider one. On a GPL note - I plan to comply to all licenses but it does not matter if you encrypt a binary, the licensing terms will not change with encrypting... – Kozuch Aug 30 '15 at 11:07
  • @WhiteWinterWolf Isn't it locking the hardware to an OS that's done with TPM? Here s/he's talking about locking the OS to the hardware. Which can't be done in a perfect way, but s/he just wants a good enough way. – user253751 Aug 30 '15 at 11:26
  • @immibis I think locking HW to SW or SW to HW is the same thing for me in the end since one can not work without the other... am I right? For others a bit more on licensing - selling RPi as a commercial product should not be a problem at all as long as you do not modify the system image (Raspbian) that the RPi fondation provides - the do distribute all the sources along already... my custom SW (the binary) has no GPL dependecies so I do not need to distribute the source code of my custom software. Even if you modify the system image, you just distribute the code with your product and it is OK. – Kozuch Aug 30 '15 at 11:32
  • @immibis: You make the OS, or at least part of it, to be stored on an encrypted partition for which the keys are handled by the TPM chip. The OS being not bootable without these keys, it cannot be booted on another environment. – WhiteWinterWolf Aug 30 '15 at 11:32
  • @Kozuch: In my last comment I mentioned the OS, but following your last note this should also be applicable to your software: you could indeed store it (and possibly it's data) on a dedicated encryption partition, leaving the Rasperry system untouched. – WhiteWinterWolf Aug 30 '15 at 11:36
  • @WhiteWinterWolf: As I wrote in my question encrypting part of the system only (dedicated partition etc.) makes more space for attacker since s/he could manipulate with the OS to fake things like MAC etc., which I do not want. Surely a TPM or some other dedicated HW security solution would be best but that is a question of cost - I am trying to go with RPi now but also like to think about some affordable custom HW design if it would help to make the whole "appliance" more secure against hacking. My problem is I need a lot of computing performance - muticore ARM with NEON or other SIMD at best. – Kozuch Aug 30 '15 at 11:44
  • As a side-note, a similar system is used on Mac OSX where a few OS drivers files loaded at boot time are actually encrypted. The main difference though is that the decryption key is just read by the OS from a special chip only present on genuine Apple hardware, so is exposed to anyone knowing how to query for it, where TPM chip may offer more security features. – WhiteWinterWolf Aug 30 '15 at 11:46
  • 1
    Other idea: SD-Card allow a password feature to protect their content from being accessed without providing the right password (the password being checked by the SD-Card firmware). It seems that Windows phones use this feature to associate the card to the phone. Would such a feature be usable on Raspberry's? (this would achieve a similar scheme as XBox where the hard-disk was attached to the game console using an ATA password protection). – WhiteWinterWolf Aug 30 '15 at 11:50
  • I fear such simple password protected card (=encrypted?) will not be usable with RPi because it has closed source firmware (BIOS) so could probably not decrypt it easily. But again, we need a key for decription... I am just trying to find a protection level with best value for me in terms of cost vs. performance. My plan is to only implement some basic protection and not leave it completely open so that at least some effort must be made to clone the device. I will probably secure my binary by checking SN or MAC first and will try to encrypt most of the OS later. – Kozuch Aug 30 '15 at 12:01
  • 1
    @Kozuch: locking HW to SW isn't the same as locking SW to HW. With TPM/secure boot you can lock the hardware so that it only runs cryptographically signed OS, this improves security as the machine would resist to being reflashed with unauthorized OS. Locking the OS so it runs only on specific machine is a much more difficult and is of questionable security benefit. Determined people would always be able to find a way to dump the OS after it has been decrypted, probably using hardware debugging features. – Lie Ryan Sep 01 '15 at 16:05
  • @Kozuch: http://archive.fortune.com/magazines/fortune/fortune_archive/2007/07/23/100134488/index.htm?postversion=2007070910 – symcbean Sep 02 '15 at 22:52

1 Answers1

5

The short answer is "No, there's no way to lock software to a specific piece of hardware that cannot be broken.". You're essentially talking about implementing some form of DRM, and tying your software to a specific HW. The brute force approach is simply to go into your code and modify it to stop looking for the HW check. This is one approach that software crackers have taken for decades to defeat copy protection. Many have tried to block crackers. All have eventually failed.

The long answer is you might be able to stop some set people from using your software for some length of time on unapproved hardware. Security doesn't have to be perfect to be useful. A set of handcuffs can be picked with a paperclip, but they still have some marginal use.

After reading your edited response, the threat model sounds like it's professional reverse engineers who want to clone your product. That essentially means you're doomed from a stopping reverse engineering perspective.

I'm not familiar with the example you have of the ELM327, but the wikipedia entry leads me to believe it's look a chip from 1976, so it's no longer protected by patent, and isn't copyright-able. You can't protect your invention from being cloned after the IP rights have run out. Someone invented the pencil with an eraser on it and had the rights to sell it exclusively for many years, but anyone can produce a pencil with an eraser on it now because the IP ran out a long, long time ago.

I'd say by far your best weapon against commercial cloning is intellectual property laws. File patents,and make sure your software has the appropriate copyrights applied to it in the various districts. Contact a good IP lawyer. It'll only really become an issue if your product is successful, so you'll have money to pay lawyers to fight any IP infringement.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • Thanks for your answer. Did you mean that if there is a way to get (read out) the SW from the HW in some way (like taking out the SD card or reading a HW flash memory directly from an on-board chip), then the software can be modified to run on different HW? If so, one measure may be to try to make the HW break before SW readout or simply make the readout as annoying as possible... a "mechanical" measure like potting the whole electronics or its part with a compound comes on my mind in such case... – Kozuch Sep 04 '15 at 14:01
  • I just edited my original question to add some more background for my incentives. – Kozuch Sep 04 '15 at 14:13
  • Thanks for your edited answer. I rather referred to the ELM 327 1.0 which was said to have "no copy protection implemented" and the code was allegedly extracted from the chip - this is the same thread that I fear. Elm Electronics was founded in 1998 but you are right the PIC18F2480 probably had no IP protection at that time already so Elm essentially only sold SW (loaded on the PIC) and I am not sure whether they had (or even could have) their SW patented. But you are most likely right about the intellectual property laws - they may be the best way to go. – Kozuch Sep 06 '15 at 09:49