Issue with Node-Locked License and License Key Authentication

[philipp-schmidt]

Hi, thanks for this great product, for open sourcing it and for opening up discussions here. We are currently evaluating keygen with the intent to go with Keygen Cloud eventually.

One of our license models is a node-locked (single machine) license for both online and offline (air-gapped) installations.

For online evaluation we provide a license key to the customer. The software will use the key to connect to the license server, activate a machine with a hardware-unique fingerprint if no machine was currently activated and then ultimately verify the license key via API. The user does not have to bother with the machine fingerprint at all.
For offline installations, the machine (fingerprint) is displayed by the software, sent to us by the customer and manually added + linked to a new license key. The customer receives a license key and the "machine file certificate" in return and activates the software which will proceed to evaluate in an offline manner.

The current license policy therefore is:
max machines: 1, strict: true, protected: false (device activation by software), require fingerprint: true, authentication strategy: license keys

With all this in mind, how can we prevent the customer from doing the following steps to circumvent the 1 max machine limitation in the online case:

Use the license key to deactivate any currently active machine, check in a new machine, checkout the new machine license, repeat

We need protected: false to allow our software to handle the machine activation in the online case. But in combination with the ability to checkout machine file certificates directly via the API with the license key, this allows the customer to circumvent the limitations. Are we missing something? Thanks!

[philipp-schmidt]

Or to formulate it a little different:

With the machine file certificates being a valid snapshot of the machine + license at time of checkout and the users being able to deactivate and activate a machine up to a limit of 1, what prevents them from generating as many valid machine file certificates as they want using a single license key?

[ezekg]

I believe these issues are being tracked in keygen-sh/keygen-api#442 and keygen-sh/keygen-api#696. On our Ent tiers, you can utilize custom permissions to disable the license's ability to checkout license files by removing the license.check-out and machine.check-out permissions.. Right now, custom permissions are not available on our Std tiers. Outside of that, you can listen for webhooks, e.g. machine.checked-out, to log and monitor this type of behavior and manually suspend licenses belonging to bad actors.

[philipp-schmidt]

Thanks for clarifying this @ezekg
Is there a particular reason the license and machine checkouts are subject to the permissions system to begin with? Intuitively I would have expected this to be a license / policy property. After all, checking out a license for valid offline use does considerably change the license model.
If I understand it correctly, neither "global" changes to the permission matrix nor rate limiting will fix the issue completely if we plan to implement both online and offline usage while enforcing an "exactly one" machine restriction.

My expected behaviour: calling machine.check-out with a license key authentication should always be allowed, but whether this will actually return a signed license file should depend on the settings for the particular license or policy. Similar to how machine.create is always allowed in the permission matrix, but the outcome will depend on whether protected: false is set.

[ezekg]

Everything is subject to the permission system — there are default permissions, and everything (users, admins, products, licenses, etc.) must abide by their configured permissions. I'm a little confused i.r.t. your expected behavior, though — checking out a machine with license authentication is already allowed under default permissions. In addition, machine activation as a license is already allowed under default permissions as well — the protected flag in this case doesn't effect licenses authenticating, only users.

I'm still a little bit lost on what your actual question/concern is, sorry. If you could describe your use case and summarize a bit, that'd be very helpful. I've read your post a few times and I'm still a bit unsure of what you're actually wanting.

[philipp-schmidt]

Hi, yes I was confused about the protected flag on licenses / policies. I was under the impression it disables machine activation via license key authentication if set to true (but it's only the case for users). And I was therefore wondering why we couldn't have a similar flag for machine checkout. It makes no sense though, I see that now, thanks for clarifying!

The use case is this: we want to allow machine activation via license key authentication, so the customer can just enter the license key they bought into our software and our software will take care of activating the machine -> convenient to the enduser. We also want to allow offline installations though, therefore the software would accept an optional machine file certificate and do offline verification. In this scenario the customer would tell us the machine fingerprint and we would provide a license key and machine file certificate.

My issue so far was that with authentication strategy set to LICENSE, the customer could technically do a machine file certificate checkout themselves with any license key. And because they can also activate / deactivate machines, they could technically abuse this and generate an infinite amount of valid licenses.

It took me a while, but I think there is a solution which does not require changing permissions: separate policies for offline and online licenses. Offline licenses have their authentication strategy set to NONE, and the software has to verify that this is the case. That way it is guaranteed that the machine file certificate checkout took place server-side by an admin. I'm looking into that now.

Thanks for the patience @ezekg ;)

[ezekg]

Great solution. Let me know if you hit any snags.