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]

You say my ideas are complex, yet you point me to that QR code example. 😉

I'm missing something. Let's say I have an app that is distributed as docker images. The user of the app is fully offline (air-gapped). For them to be able to use the app they will need a license-file. If I'm not worried about node-locking, I can:

1. Create a license. Checkout license and email the license-file and license-key.

2. Customer uses some internal means (e.g., usb-stick) to move the files to the target device.

3. By bind-mounting or other volume mgmt, the docker container will have access to the license-file and key.

4. Container is run.  App can see files and validates license. Trumpets call, the sun shines, life is good.

Can you provide a simple set of steps like this for node-locking in offline mode? Bonus points if the app is shipped as a docker image.

Thank you so much!

This is right. Like I said, the same flow for node-locking especially for Docker images gets complex, because the flow always requires a human to facilitate the flow. That's why we're working on Relay, because the alternative is complex because the problem is complex. Ideally, we get rid of the human altogether during the flow outside of onboarding/setup.

Like the air-gapped activation example shows, the current flow looks like this:

1. The application will prompt for the end-user's license key.
2. The application will "fingerprint" the air-gapped device.
3. The application will somehow display the fingerprint to the end-user.
4. The end-user will activate the license key + fingerprint out-of-band using an "activation portal" e.g. via a mobile phone.
5. The activation portal will perform a license validation API request for the license key, scoped to the fingerprint.
6. The activation portal will activate the fingerprint when required.
7. The activation portal will checkout a machine file, containing an encrypted license and machine object.
8. The end-user will download the machine file and transfer it to the client e.g. via USB drive.
9. The application will cryptographically verify the machine file using Ed25519.
10. The application will decrypt the machine file using AES-256-GCM.
11. The application will run normally.

What Relay will do is simplify the above to:

1. The vendor downloads Relay on the end-user's private network.
2. The vendor loads Relay with N signed/encrypted license files (allowing N nodes on the local network).
3. The vendor starts the Relay server on the local network.
4. The application will request a license file and key from Relay (e.g. from port 1234 on the local network).
5. The application will cryptographically verify the license file using Ed25519.
6. The application will decrypt the license file using AES-256-GCM.
7. The application will run normally.

In the case where there are N nodes already running, Relay will return an error and the application can fail to boot.

We get rid of the human (outside of setup), paving the way for a wider range of use cases.

Here's an example: https://github.com/keygen-sh/air-gapped-activation-example

Btw, does this actually work? When I use ngrok and go to the url, it asks to start my camera, then...nothing happens...just a page with my camera on.

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

[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.