Preventing sharing of commercial GDL objects

[BenjiDev]

An author of a GDL object might want to sell it while also preventing buyers from sharing it with others. How is it done?

A GDL object cannot make HTTP requests and, to my knowledge, does not have access to any crypto libraries.

I have some ideas, but there may exist simpler solutions already:

The GDL author creates a C++ Add-On and sets up a license server. The sole purpose of the Add-On is to communicate with the license server, since the GDL object itself cannot make HTTP requests.

The flow:

1. A GDL object is placed, and the Add-On gets notified through ACAPI_Notify_CatchNewElement.

2. The Add-On queries the license server using:

   • a unique ID for the GDL object (essentially a product ID)
   • the Graphisoft user ID

   The server responds with a signed license (for example containing expiry date etc.). The important part is that the license is signed with the license server’s private key (for example using RSA).

3. The Add-On writes the license as a string parameter into the GDL object.
4. The GDL object verifies the license signature internally using the public key of the license server, validates the contents of the license, and disables itself (for example by not drawing any geometry) if the signature or contents are invalid.

Since a GDL object can be password protected, a user would not be able to simply remove the license check from the script itself. And you cannot easily edit the GDL code outside of ArchiCAD either.

The problem is step 4.

How would you realistically verify RSA signatures inside a GDL object? It does not seem very feasible to implement RSA verification manually in GDL.

The simpler alternative would be to let the C++ Add-On perform the license validation and then simply write an is_valid parameter into the GDL object. However, that seems insecure because someone could create a fake Add-On that just writes is_valid = true without checking any license.

Operating system used: Windows

[Lingwisyer]

Do you manually create it @Ben Cohen , or do you have some automated way?

[BerndSchwarzenbacher]

I'd be careful with using a macro object for this. I think a "malicious" user could easily replace the macro with their own and just unlock all your objects.

[runxel]

I know, but what would be the alternative?

I clearly would not like the overhead to have every object doing it's own validation.

Actually, thinking about this a bit longer: An additional secret that's returned as well and validated in the object might do the trick.

[BerndSchwarzenbacher]

Yeah it's very annoying to add that code part to every single object and basically have to recompile the whole library for each customer.

I also thought about additional secrets, but I always failed to actually make it work. Every way I can think about, it's always relatively easy to replace either the object or the macro and get to the secret this way.

[Lingwisyer]

Even if either gets duped, would not the actor would be required to know what is being requested in order to fish the secret?

[runxel]

---

@Lingwisyer  schrieb:

Even if either gets duped, would not the actor would be required to know what is being requested in order to fish the secret?

---

I think so too. One would need to know the order and the contents of the returns. That's a bit far fetched imho.

[Piotr Dobrowolski]

Regarding licensing macro...it can be kind of safe if the "on/off" switch was not on the parameters list, but in "returned_parameters" - as it cannot be sniffed with schedule setup.

[Davor P]

Like Lucas suggests - macro works - I tested this quite a bit. You could solve it with a "worker" mac or PC that polls every x minutes. If an order comes through it can insert company ID to xml and convert to password protected gsm. Then upload somewhere where you serve download link to customer.
Also @BerndSchwarzenbacher - highly recommend for anything add-on related.