Is anything missing in the offline software licensing plan?

Question

I'm working on a piece of software written in VB.NET for Windows machines (mainly Windows Server). I have some understanding of cryptography and security, but I want some good old fashioned peer review on the method I'll be using to license and activate the software.
This method needs to work offline so the software can be installed on computers that aren't connected to the internet. For computers that are connected to the internet I will probably do more checks to insure the license is valid.

In general my offline licensing plan is:

• Distribution:
  • Executable is embedded with the licensing server's asymmetric public key
  • Upon sale of the program, a license key is generated.
  • Key is stored in the license server database along with its limitations (e.g. which version of the program it licenses and what features it includes)
    (I may also tie this to a user account)
  • License key is given to the user at sale
• Activation:
  • Have the user enter the license key on the intended computer
  • Generate a recreatable hardware key from the motherboard and/or other components' MAC address to uniquely identify the computer which will run the software
  • Generate an "activation file" that contains: the hardware ID, license key and software version number
  • Copy activation file to an internet-connected machine and upload it to the licensing server (via a website or something)
  • Licensing server checks to see that the license key has not been used and that it is valid for that version of the software
  • If accepted, licensing server generates a "license file" containing the hardware ID of the now registered computer along with the limitations of the license
  • This license file is signed by "encrypting" it using the license server's private key (not for secrecy of the message, but to verify origin)
  • The license file is copied back over to the offline machine and put in the proper place
• License Check:
  • When the program starts and before it uses certain features, the program uses the embedded public key to "decrypt" the license file (which would verify the source)
  • The programs checks to see that the hardware key inside the file matches the hardware key it generates from the machine
  • The program checks that its version and the feature(s) being requested are included in the license

Reasons I think this works:

• Since the license key is only generated once sold, the number of "guessable" unactivated keys that exist will be relatively small
• Hardware key is registered with the license server along with the license key so that it wont accept the same license again for a different machine
• License file is signed by the licensing server's private key, so the embedded public key can be used to prevent spoofed license files
• The license file contains the hardware ID that was used to obtain it, so it can't be copied to another machine

Weaknesses I am aware of:

• Having to copy the activation and license files to/from the computer (when it isn't connected to the internet) could be a bit of a hassle.
• Is it even possible to generate a reliable hardware ID if the program is being installed on a VM?
• The embedded public key in the executable could potentially be swapped out to allow for license file spoofing
• The software version number in the executable could potentially be modified somehow to allow it to use licenses intended for a previous version
• The code itself could potentially be modified to bypass the license checks
• Anyone intending to move the software to another computer would require a new license key (not that I would necessarily make them buy a new key)

Question:

Is there any advantage to an arithmetically generated key vs a purely random one? I know some keys have digits that add up to other digits so you can easily spot an obviously fake or mistyped key, but doesn't that just limit the number of actual keys valid keys and so make it easier (statistically) to guess a real one?

Final thoughts:

I would appreciate anyone who can punch holes in the security of the above.
I would also appreciate any recommendations regarding license key length, the process of generating hardware IDs (and how I would do so on a VM) and any way I could discourage or make it difficult for someone to tamper with the executable to modify the license check code or public key.

Answer 1

You're trying to invent a perfect DRM. That doesn't exist, and will never exist, because of one fundamental rule: Anything your software does, the person running it can use and change. Even if you added a password prompt that you had to go in and enter the password to validate it, the software is doing the password check, so the person running it can change it.

Instead of developing this system that sounds like a nightmare for legit users to use -- which will drive away customers, either to piracy or alternate products -- just... don't. Accept that you'll have some losses to piracy. If you're targeting a business market, probably not that many, but you'd have to do proper market research to find out.

As for specific flaws with your plan, though... well, you've hit almost all the ones I've thought of. You just don't seem to realize they're gamebreakers, as opposed to mere inconveniences. Let me explain why:

• "A bit of a hassle" is an understatement. Why is that computer disconnected from the internet? In the most extreme case, it may literally be a capital crime, treason, to take information off it, if the computer handles classified information. In most cases, it's probably not that bad, but very possibly a breach of policy.
• Nope. Not even slightly. If I had to guess, I'd say the first cracked copy of your software would just be an internetless VM image, with the software all set up and everything, and probably the clock set back just for good measure.
• Yup, that's very possible, and probably easier than you think. If they just straight up tried every single contiguous sequence of bits that's the right length, that'd be at most about a 2⁴⁰ search space, which is big but not unmanageable for an offline, properly parallelized attack. Of course, they're far more likely to just examine the process's memory and get the public key from that, to sidestep any obfuscation you try to put in place. Because they own that memory. They can do what they want with it.
• "Somehow", yes, like how games with DRM are constantly cracked by modifying them "somehow". That's vague on purpose; DRM is cracked in so many ways it's impossible to explain all the ways. The executable is on their machine, so they can do whatever they want to it.
• Yes, see previous point.
• Your worry makes me think this software is expensive. Given that, it's pretty unreasonable to demand that anyone moving computers pay you for the privilege of moving their property onto another computer. Sure, you can write it into the TOU to make it technically legal depending on jurisdiction, but it's still morally questionable at best. Should people be punished for running your software in industrial environments? For their cloud hosting's datacenter being constructed poorly? For using cloud hosting at all?

You did miss a couple of things I want to point out, though:

• That's not how public key cryptography works. Public key encrypts, private key decrypts. You use "sign" and "encrypt" interchangeably; those are not interchangeable. And either way, whichever one decrypts is on the customer machine, and therefore... see above. You also can't just swap the public and private keys; the public key isn't meant to be unguessable.
• Your hardware ID scheme is inherently unreliable, not just because of VMs. MAC addresses, first of all, only identify network cards, not all hardware in a device. Second of all, it's extremely easy to spoof your MAC address -- Windows literally offers it as a built-in option. I sure hope that's extremely well documented, or you're going to screw over a lot of people. Third of all, there are a ton of legitimate reasons to swap out hardware.
• Your scheme makes no allowances for demos or test installs. I'm curious how you plan to sell this software to anyone, if they have to just... take your word for it that it's great, with no chance to try it out in any way before use, and have to throw away money to even see if it's compatible with their system, train their employees, etc. Not a great solution.

TL;DR: Don't try to invent perfect DRM. Save your customers some trouble. If you need to make up the extra money, offer support plans.

---

Sorry if that came off as rude. In the first version of this, I went out of my way to be polite, but... it was about twice as long. (Which means that, yes, this is concise for me.)