Frequently Asked Questions

The FAQ is a work in progress and is continuously updated based on questions we receive by mail.

Platform

Expiration date

When you create a new license, you are asked to set when it should expire. On the product page, every license has a field called Expires. The question is, how can we create licenses that never expires?

It turns out that expiration date will not affect the validity of a license by default. For example, all code snippets provided in the key verification tutorial assume that a license is time-unlimited.

This may feel a bit counter-intuitive and we are continuously working on improving the APIs to make this more trivial.

For now, if you see that a code-example contains a call to the activate method (which all examples do at the moment), it means that you need to check the expiration date even if you get a successful result. A way to do this is to call HasNotExpired (depending on the library) or simply check the Expire field. If you plan to support both time-limited and time-unlimited licenses, you can use one of the feature flags as a way to distinguish this. Please read more here.

Blocking expired licenses

In order to ensure that licenses stop working after that they have expired, you can select “Block Expired Licenses” when editing feature names. Expired licenses will be blocked within an hour.

Starting countdown upon activation

If you do not know when your customers will activate the license for the first time but you still want them to use it for a set number of days, you can enable trial activation.

Plan ahead

You may noticed that you can edit feature definitions in each product. They can be used as a way to help you to keep track of what each feature flag means and they also help our platform understand how to display a certain license in a meaningful way (eg. if F1 stands for a time-limited license and it’s not enabled for a certain license, there won’t be an option to prolong it).

Recently, we have added support in our Web API that takes into account the feature definitions and adjusts the response sent to the client. Our plan is to integrate this into all client APIs so that you can have most of the license logic set up in the dashboard.

Maximum number of machines

Maximum number of machines is a way to specify how many unique machine codes can be added to a certain license (using the Activate method). When the limit is reached, no more machine codes will be added. There are two special cases that is important to keep in mind:

Setting to zero

Setting maximum number of machines turns this feature off, i.e. machine codes will not be added to the license. It means users will be able to run the software on any number of machines.

Decreasing the value

Let’s say you had maximum number of machines set to 10 and one customer has used up the machine code quota, i.e. they have activated on 10 computers. If you decrease this value to something less than 10, eg. 5, all of the activated machines will still work. That’s because the platform does not know which machine codes should work and which should not. If you would like to remove some of the machines codes, you can click on the yellow button next to each license and remove the machine codes in from the list.

How access can be restricted

There are two ways you can restrict the number of machines that can use a license:

  1. Node-locked: Either you restrict a license to a certain number of machines indefinitely (i.e. until they are deactivated)
  2. Floating: or you allow a license to “float” between different machines, as long as at any one point this upper bound of machines is never exceeded

For trial keys, it’s better to use the first approach whereas for paid licenses, either approach will work fine, although floating licenses will be more convenient for your customers and remove the hassle of license deactivation.

Protocols

Cryptolens uses two different protocols to deliver license key information to the client during activation:

  • .NET compatible (aka LingSign): if you use C# or VB.NET (unless you use Unity/Mono specific methods, in which case Other languages protocol is used)
  • Other languages (aka StringSign): if you use C++, Java or Python

Most of the clients have methods that allow to load a license key object from file or from String. For example, LoadFromFile (.NET), LoadFromString (Java) or load_from_string (Python).

Client APIs / SDKs

Machine code generation

Machine codes are used to uniquely identify an end user instances, i.e. a machine code is a device fingerprint. The way it is generated depends on the SDK and the platform, which is listed below:

.NET

Prior to v4.0.15, machine codes have used the following code to gather device specific information and later hash it using either SHA1 or SHA256. The problem with this method is that it is Windows specific and requires System.Management (which is not supported in Mono when integrating with Unity). To solve this, we opted for platform specific methods to retrieve the UUID. You can read more about how to migrate here. Depending on the platform, the following shell calls are made to retrieve the UUID:

Windows

cmd.exe /C wmic csproduct get uuid

Mac

system_profiler SPHardwareDataType | awk '/UUID/ { print $3; }'

Linux

Note, the method below requires root access.

dmidecode -s system-uuid

Java

In Java, the following method is used.

Python

In Python, similar to .NET, we opted for UUID, which can be provided by the OS. You can see the source code here. Note, the machine code will not be the same as in .NET.

C++

In C++, we use the same method that was used in .NET prior to v4.0.15. The source code can be found here. We are working on shipping a platform independent version in the next release.

Plan ahead

Our plan is to introduce a platform independent method to retrive the UUIDs, in order to ensure that machine codes are the same for all SDKs.

Protecting RSA Public Key and Access Tokens

If we take the key verification tutorial as an example, there are three parameters that are specific to your account: RSA Public Key, Access Token and ProductId. The product id is not a se

RSA Public Key

The RSA public key is used to verify a license key object sent by Cryptolens. This is especially useful if you want to implement offline activation since we don’t want any of the properties (eg. features and expiration date) to be changed by the user.

Note: the RSA public key can only be used to verify a license key object, the private key that is used for signing is stored on our server.

Access Token

An access token tells Cryptolens who you are (authentication) and what permissions are allowed (authorization). In other words, it can be thought of as username and password combined, but with restricted permission.

It’s recommend to restrict access tokens as much as possible, both in terms of what it can do (eg. Activate or Create Key) and what information it returns (read more here). For example, you should preferably only allow access tokens used in the client application to Activate a license key. The permission to Create Key should only be accessible in applications that you control, eg. on your server.

So if you have a restricted access token, the chances that an adversary will be able to do any harm is minimal. For example, the worst that an adversary can do is to activate more devices (up to a certain limit), which can be fixed quite easily in the dashboard.

GDPR

General Data Protection Regulation (GDPR) is a new data protection framework that will take effect the 25th of May, 2018. If you plan to do business with European companies or individuals, you need to be compliant with GDPR. Failure to comply can in the worst case lead to fines up to €20 million or 4% of global annual revenue, whichever is higher.

Please take a look at our security page for more information.

Third Party licenses

A list of third party licenses for the C++ client can be found here.

What is SKGL?

Please read this article.