Questions about Intended Usage, How Keys & Lib Work

[Ben Snell]

Hi,

First off, thank you so much for such a wonderful open-source project. It seems unique in this space--I haven't been able to find anything else quite like it.

Secondly, I have a few questions about how the project works. I've read through the documentation / Wiki, past Github issues, posts to this forum, but I just can't wrap my head around why / how it works in regard to a few points. Perhaps I've glossed over something crucial. I would greatly appreciate your clarification.

For reference, I'm intending on using this library to protect a single piece of C++ software (let's call this software Foo here) using hardware identification. I've been developing this software on Windows in Visual Studio. I successfully integrated the C API and static library into this application and I have had success in generating and checking licenses. My concern now lies in:

1. Reproducibility: I would like to be able to (A) Provide releases of the compiled open license manager lccgen.exe to other team members who may need to generate new licenses for Foo in the future, and (B) Re-compile this software at some point in the future if the releases no longer work, yet retain any important files/libs/keys that are required for being able to continue to generating new licenses for Foo.

--> My question here is: What, of all files that are generated on compiling lccgen.exe, are needed to continue generating licenses for Foo in the future? If I needed to re-compile this executable, what files would I need to "carry-over" (public + private keys, etc?).

2. Security. Obviously, this project has security at top of mind. Otherwise, what purpose would it serve? It appears to me that the only files that need to be included in Foo's Visual Studio project include licensecc.h, licensecc_properties.h, and datatypes.h. None of these files have sensitive or unique information from project to project, other than LCC_PROJECT_NAME. However, changing this value doesn't affect the loading of the license, so this makes me wonder:

--> What purpose does it serve to have the LCC_PROJECT_NAME macro defined in licensecc_properties.h?

I also wonder as to whether is anything unique about the static library licensecc_static.lib. This leads me to ask these questions:

--> Can this library be freely distributed and used by others without worry of it containing potentially sensitive baked information?

--> If I compiled lccgen.exe separately on two computers, could their licensecc_static.lib files be used interchangeably?

A separate question I have about terminology revolves around the definition of "Project." I see some conflicting definitions of this term in posted questions and documentation. According to your glossary, a project is defined as follows (with my questions, comments interspersed):

"A project corresponds to one application where the licensing system need to be integrated."

- This leads me to believe that "Foo"  could be considered one project. 

- It also seems like Foo should have its own folder (with its own keys) in the open-license-manager/projects directory. The naming of this directory "projects" leads me to believe that a single compiled open-license-manager repository can store multiple projects. It seems like additional projects can be generated using the lccgen.exe project init command. It seems like multiple licenses can be generated for each of those projects using the same lccgen.exe executable by simply changing the project it is pointed to using the --project-folder option.

- The files generated by the lccgen.exe project init command include the private_key.rsa and public_key.h. The public key file contains a macro called "PRODUCT_NAME", which makes me wonder what the difference is between "project" and "product" here?

- The Wiki page titled "Issue Licenses" contains the sentence "You can re-configure the project with the LCC_PROJECT_NAME cmake variable to create a new project." This makes me wonder whether the lccgen.exe contains any baked project name information? 

"...Each project has its own private key and its own folder where licensecc is compiled."

- This directly conflicts with the logic above. It suggests that for each project like Foo, a different lccgen.exe must be compiled. Is this true?

"...Currently we support only one project per (build) machine. This is especially true in Windows, where the private key has the same name for all the projects."

- I still don't understand what this means.

I also have a question about using the environment variable LICENSE_DATA with a base64-encoded license. Currently, the license generator does not seem to support exporting a license as base64, even though it is an option. I have tried providing just the license's "sig" field as the value for this environment variable, but it doesn't seem to load it. I saw commits recently disabling this functionality because it conflicts with other functions. Is this true? If so, why?

Thanks so much. Apologies for all the questions. I'm just trying to wrap my head around this.

My best,

Ben

[Ben Snell]

Also, one last thought regarding usage of keys:

At first, I thought public_key.h was supposed to be compiled with the application Foo, as a means for the licensecc_static.lib function acquire_license() to decrypt the signature. This made sense to me at the time, since it seems like it would prevent a 3rd party from generating new licenses using open-license-manager and placing them alongside Foo's executable. However, Foo can be compiled and it can decrypt the license (.lic) file without the presence public_key.h header file. This makes me wonder then:

1. What allows the licensecc_static.lib to decrypt the license.lic file, if it does not have access to either of the public or private keys that generated the license file in the first place?

2. What prevents a third party from replacing Foo's license file with one they have generated themselves from their own fork of open-license-manager?

Thanks again!

Ben

[Gabriele Contini]

Hi Ben,

Your questions are welcome, and yes documentation is lacking, sorry. 

Let's split the reproducibility in two parts:

Licensecc is evolving and sometimes i break the backward compatibility. if you want a reproducible build you should fork and tag the code. An official release should come "soon", but how this soon is i'm still not sure. I would like to add a couple of features... so maybe it will take few months.

Your understanding of project below is correct if you replace the word "compiled" with "source":

- This leads me to believe that "Foo"  could be considered one project. 

- It also seems like Foo should have its own folder (with its own keys) in the open-license-manager/projects directory. The naming of this directory "projects" leads me to believe that a single compiled (---- change in: source ---)open-license-manager repository can store multiple projects. It seems like additional projects can be generated using the lccgen.exe project init command. It seems like multiple licenses can be generated for each of those projects using the same lccgen.exe executable by simply changing the project it is pointed to using the --project-folder option.

A project is a container for all the customization of `licensecc` (the c++ library) needed for Foo, in a special way a project contains a public key, a private key and some settings. After you create a project you can compile `licensecc`-library.  As you expect `licensecc`-library will include the public key (public-key.h) from that project (see signature_verifier.cpp line 20) so: one licensecc-static.lib - compiled library per project. Though the licensecc source repository can be used to host multiple projects (you can choose in the cmake configuration).

(A) Lccgen + 'Foo'-project files give you the possibility of generate licenses for 'Foo'-executable. So you can compile lccgen, distribute your 'Foo'-project (especially the private key) and other people can generate licenses. 'lccgen' doesn't carry the private key itself; it reads it from the project, so you can compile 'lccgen' once for all the different projects you have.  ("lccinspector" is per-project, it carries the public key to verify licenses)

Conceptually at a minimum lccgen.exe + project + licensecc 'src' folder are the things needed to recompile licensecc library and generate licenses.

About security `licensecc`-library includes public-key.h so you have one licensecc_static.lib per project. 'Foo' has its own one, if you have another executable 'Bar' and you want different licenses for this you'd better generate another lccgen 'Bar'-project and compile a new licensecc_static.lib (for Bar). the two versions can't be exchanged. license verification will fail otherwise.

...Currently we support only one project per (build) machine. This is especially true in Windows, where the private key has the same name for all the projects."

This limitation was removed about one year ago. Thanks for pointing it out i'll update the docs.

PRODUCT... ignore it for now there were a couple of renames... a planned development is to give the possibility to activate multiple part (features) inside 'Foo', but it's still incomplete.

I hope I answered your questions, let me know if still have doubts. 

Gabriele

[Leopold Kuttner]

I had many of the same questions, this was very helpful, thanks! When the details are settled, an edited version of this would be a great addition to the documentation.

Ben, I think you might find my example project for license issuance via a client-server architecture interesting. You can find it here in the forum. Feel free to get in touch.