Node-locked offline license files with docker

[al-dpopowich]

Preface: I know the best we can do in offline licensing is obfuscate, especially for interpreted languages like python; who can stop a customer from tweaking the code to skip license validation altogether? Solution: We trust our customers. Have them sign contracts. We make it hard to subvert the process. We obfuscate. That said...

I have been writing/supporting a webapp software suite that my customer hosts in the cloud. They sell subscriptions to their customers for use of the webapp. But they have a few customers who will not use their software in the cloud and demand a behind-the-fence solution. They want to ship docker images and have them (ideally) node-locked. This is similar to #149, and as discussed there, there's no facility keygen can provide to prevent the 3rd party from copying the distribution and license-file to other hosts. Add to the mix that you cannot ID a docker container.

So here's an idea I'd like feedback on:

Let's say my customer is Acme and their customer is Customer...

1. Acme ships distribution to Customer with no license-file.
2. Customer runs script to generate an activation-request. This process:
   1. generate RSA key pair
   2. generate random 64 bytes (e.g., os.urandom(64))
   3. store the private-key and randomness in a very obfuscated way. {{hand waving here}}
   4. using private-key, sign the randomness as the activation-request.
   5. the activation-request and public-key are packaged and Customer sends it back to Acme.
3. Acme stores activation-request along with public-key securely.
4. Acme runs script which verifies signature of activation-request then using the public-key, encrypts the activation-request.
5. Acme generates a license for Customer and in the metadata places:

   machine: {encrypted-activation-request}

6. Acme does a checkout of the license and delivers the generated license-file to Customer.
7. Customer installs license-file.
8. When distro runs, in addition to normal validation of license, it will look at the metadata to complete validation:
   1. machine must be present.
   2. the private-key must be able to successfully decrypt the value.
   3. the decrypted value must match the original randomness.

Yes, we're still obfuscating, but depending on the sophistication therein, we can make it really, really hard for a single customer to copy the distro to their subsidiaries' sites.

Thoughts on this scheme?

[ezekg]

We've been working on a product for this exact use-case: https://github.com/keygen-sh/keygen-relay (spec)

Still a WIP, but at the very least a beta should be out soon.

[ezekg]

Thanks for the additional context. Relay is designed to license a single air-gapped environment, not multiple environments all air-gapped from each other. Relay needs some way to manage the air-gapped nodes collectively, and that's not possible when the environments can't communicate with a single Relay.

Relay would work if each environment was licensed separately, which is more typical, but that doesn't seem to be the case.

In this case, yes, Relay doesn't seem like a good fit and your solution seems fine.

Let me know if you need anything else. 👍

[al-dpopowich]

Relay would work if each environment was licensed separately, which is more typical, but that doesn't seem to be the case.

Exactly. But in our customer's case (or any case in which relay is used?), I don't see what can stop the end-user from copying relay + application to another network and "stealing" a license.

[ezekg]

I'm not really sure what you're looking for here, to be quite honest. The vendor is typically the one responsible for setting up Relay in the air-gapped environment, and if the customer is tampering with Relay or copying Relay in attempts to bypass their licensing restrictions, then internal audits into the customer environment should surface that behavior and it should be dealt with like any other breach of contract. I don't really think this is something Relay needs to be concerned with — in this scenario, the customer is a bad actor. Preventing this behavior from bad actors in a way that doesn't require internet access or an intermediary that has internet access is hard, or even impossible. Relay is meant to be an automated, stand-alone solution that is in sharp contrast to manual activation flows like you've outlined, because that flow doesn't work for containerized environments — esp. with autoscaling.

For example, assuming you're the vendor, an onsite tech of yours would install Consul and Relay into the customer's environment, load Relay with n licenses, and your application instances would claim licenses from Relay via Consul, e.g. http://relay.service.consul. Preventing the customer from sabotaging the Relay is out of scope of our current project goals.

[al-dpopowich]

We definitely have differing opinions on what is too manual! Having the customer send back a license-request to be processed, encrypted and signed (all with one go of running a script) is too manual, but having an onsite tech to configure and install is not? 😁

[ezekg]

I think it's less of differing opinions and more that Relay is solving a different problem.

Your flow is more akin to what people already use machine files for — they make a 'license request', which at minimum consists of a fingerprint — packaged up however you see fit signed/encrypted/w/e. — and that fingerprint is then activated as a machine via the API using a 'portal', and then a machine file is checked out for the new machine. That machine file is then distributed and installed onto the air-gapped device. This flow requires a human to fulfill the 'license request', i.e. it's manual.

This manual fulfillment is problematic if you imagine GitHub wanting to license a 100-node k8s cluster of GitHub EE to a customer. The customer obviously doesn't want to use all 100 nodes if they don't need to, so these nodes need to autoscale. But going through that manual 'license request' flow every time k8s wants to autoscale doesn't make sense There are infinite manual tasks here: a 'license request' that needs to be fulfilled for every new node — and this is the problem Relay is trying to solve.

With Relay, you could set up Relay once with 100 licenses, inside of the k8s network, and the nodes could autoscale up to 100 nodes, all enforced by Relay. There a 1-time manual task here: setup Relay on-site and then that's it until the contract changes.

There's nothing wrong with your approach if it works for your use-case. People have been using machine files to successfully facilitate 'license requests' like that ever since we introduced them — in fact, that's why we designed machine files!

We'll work on improving our messaging with Relay. It's very early stages right now.

(By all means, feel free to implement and share your approach, since I think you originally asked if sharing it via a Python script would be helpful. I'm sure others would love to see it, including myself!)