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.

[al-dpopowich]

Thank you so much for the "flow chart". That helps. For my customer (Acme in my above example), I am told that I may not assume an internet connection at all, only that files can be transferred, so a tool like Relay (which I love) may not even be possible for me in this situation.

In the end, given that "fingerprints" for docker images are at best ephemeral (e.g., after taking down a container and restarting one loses the CID, so you'd have to store the original CID in some obfuscated way), and given that no matter what, it's complex, I'll go with something like my original idea.

Would this project be interested in my solution? I'm imagining a single python script.

You need to open the ngrok URL on a mobile device and scan the QR code.

I did. When I open the URL, the app asks for permission to use my camera and when granted, that's all there is...a page showing my active camera.

[ezekg]

Thank you so much for the "flow chart". That helps. For my customer (Acme in my above example), I am told that I may not assume an internet connection at all, only that files can be transferred, so a tool like Relay (which I love) may not even be possible for me in this situation.

In the end, given that "fingerprints" for docker images are at best ephemeral (e.g., after taking down a container and restarting one loses the CID, so you'd have to store the original CID in some obfuscated way), and given that no matter what, it's complex, I'll go with something like my original idea.

Would this project be interested in my solution? I'm imagining a single python script.

An internet connection is not needed for Relay. Relay serves license files on a local network, not via the internet. It's meant to be run in 100% air-gapped environments; it has no dependency on the internet — that's the entire point of Relay. If there's no local network, then Relay won't work, and you will need to do something like that aforementioned air-gapped activation flow, which requires human intervention.

Your solution requires trust on the client machine, so I'm not interested in it. It's impossible to fully trust the client, and any trust of the client in an offline environment, i.e. via obfuscation, will eventually be thwarted. In your solution, the client has the private key, so can generate unlimited activation requests in the worst-case, and I never assume best-case scenario i.r.t. licensing, only worst-case.

Your solution just adds complexity on top of the air-gapped flow I outlined using a machine file with a random fingerprint.

I did. When I open the URL, the app asks for permission to use my camera and when granted, that's all there is...a page showing my active camera.

Use the camera to scan the QR code, per the instructions.

[al-dpopowich]

An internet connection is not needed for Relay.

OK. Read through your flow again. Got it now. I was thinking the Relay server was on both networks, a gateway, as it were. The name through me.

Your solution requires trust on the client machine, so I'm not interested in it. It's impossible to fully trust the client, and any trust of the client in an offline environment, i.e. via obfuscation, will eventually be thwarted.

No disagreement here. But that will also be true of Relay. Any solution that is fully run on the client's host/network can be thwarted, no? A little wireshark snooping and what's to stop a client from writing their own server to deliver false-positive results, allowing them to up their licenses? It's a matter of how hard you make it for them.

That said, were Relay available now, I'd be taking it out for a test drive.

Use the camera to scan the QR code, per the instructions.

I'm not sure what more I can say. My camera turns on, but does nothing. There are no instructions on that page, no buttons, no nothing, just a div with my camera view. I see no way from there to scan the QR code. I tried it with both chrome and firefox browsers on my android device. And if I use my phone's QR scanner, it gets a text file, but have no idea what to do with it from there.

[ezekg]

Any solution that is fully run on the client's host/network can be thwarted, no?

Yes — anything run client-side can be thwarted. But Relay, using cryptography, does make it challenging. There are audit logs available in Relay if you do have a suspect client. These can be compared to your own application logs to see the whole picture.

That said, were Relay available now, I'd be taking it out for a test drive.

It'll be in beta within the next couple weeks. I'll ping you.

[ezekg]

Keygen Relay is now in beta: https://keygen.sh/docs/relay/

GitHub: https://github.com/keygen-sh/keygen-relay