6

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.

  • 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
  • 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
  • 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 1 '15 at 16:05
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.

  • 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 4 '15 at 14:01
  • I just edited my original question to add some more background for my incentives. – Kozuch Sep 4 '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 6 '15 at 9:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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