7

Suppose I want to give a computer to someone that runs an application. I want to avoid that the program can be copied to another computer or be tampered with. For that, I want to encrypt the folder that contains the program and would like to make it so that only the host OS (Linux) on that device can decrypt it (ie. also avoid moving the disk between computers). There is no TPM in the computer. Secure boot is already running, but is seems that this gets reset when resetting the CMOS. The application requires network, so that is already available.

Is this possible? I don't really see how this can be done, if possible. And it not, how far can I get to make it as difficult as possible?

Improve this question
10
  • 14
    There is no bulletproof way to do this.
    – Thomas Ward
    Oct 25, 2019 at 16:44
  • 4
    This problem is related to the game console problem. E.g. Microsoft spent millions of dollars and countless engineering hours to make the XBox secure against organized crime and commercial pirates. And they were half-successful: it wasn't cracked by an evil syndicate of software pirates … it was cracked by some kid in his basement who simply wanted to install Linux.
    – Jörg W Mittag
    Oct 26, 2019 at 2:33
  • 1
    Copy protection for software has a long, glorious, and thoroughly unsuccessful history.
    – Carey Gregory
    Oct 26, 2019 at 21:33
  • 1
    With no TPM? Good luck. You need TPM-like hardware to achieve this.
    – forest
    Oct 26, 2019 at 22:49
  • 1
    @TheHansinator That's correct. it's just a few and we can control all of the hardware
    – Patrik
    Oct 28, 2019 at 8:24

3 Answers 3

Reset to default
11

No matter what you do, you will need to store an encryption key somewhere, which will then be recoverable. If you require a license server, this could be worked around by hooking or patching the application. You can do things like this to slow down an adversary, but it won't be complete protection. If you really don't want to give out your software, use a client-server architecture with the bulk of the logic on the server side and require authentication from a paid/authorized user (although then you can't prevent the client software from being copied or modified either, but that's usually an accepted risk).

Improve this answer
2
  • 1
    "you will need to store an encryption key somewhere", yes, but that doesn't mean it's recoverable. Modern credit cards store the encryption key in hardware. However, it has to be decrypted to execute, so a determined hacker to intercept it at that stage.
    – Mooing Duck
    Oct 25, 2019 at 23:58
  • 5
    @MooingDuck The question mentions there is no TPM, so where are they going to hide it? Even if it was stored in hardware, software could potentially be coaxed into revealing it.
    – multithr3at3d
    Oct 26, 2019 at 7:44
6

Suppose I want to give a computer to someone that runs an application. I want to avoid that the program can be copied to another computer or be tampered with.

There are commercially available tools that will do this for you. As you have suspected, there is no bulletproof solution that cannot be broken by a dedicated adversary. But, in practice, there are commercially available obfuscaters that may be "good enough" for your purposes.

The commercially available tools can also tie the software to a given hardware by taking a "fingerprint" of the hardware. Again, this is probably spoofable with enough work, but could be "good enough" for your purposes.

One example of a commercially available tool is the ".NET Reactor," (https://www.eziriz.com/dotnet_reactor.htm) which is for use with Windows .NET software. It can obfuscate the software to frustrate reverse engineering and it can tie the software to specific hardware using a hardware fingerprinting method.

Improve this answer
5

One strategy I've seen that is not fool proof but it you read in unique hardware IDs and use that as a key to decrypt the software, if it's moved to another machine, it wouldn't decrypt.

The only problem with this is most of those values can be overwritten and if the attacker knows what hardware these values are being derived from, and reproduce them to effectively 'unlock'/decrypt the software.

Additionally, you have a problem if any of that hardware fails and gets replaced, you now have to cut new software--encrypted with the new combination of hardware IDs for the replaced/new hardware.

Improve this answer
1
  • 2
    +1 for "you have a problem if any of that hardware fails and gets replaced" this is particularly problematic in virtualized environments because hypervisors do things like "transparently" move your live VM to a different compute cluster and suddenly your CPU fingerprint is different.
    – Mike Ounsworth
    Oct 25, 2019 at 20:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .