Summary of how SDKs can be protected using Cryptolens Licensing.
Software Development Kit (SDK) licensing is when you distribute a component, usually a library, that is later going to be integrated as a part of another commercial solution.
In many ways, licensing an SDK or a desktop software is quite similar. In both cases, you will have to send a license key to your customers in order for the software to work. Many of the licensing models for desktop apps can be used in SDKs, although there are some that will be more suitable for SDKs. However, we need to keep in mind that end users are almost always different individuals, and the information that is stored in a license key will be shared with all end users (see the Privacy section) unless configured otherwise.
There are two ways of protecting SDKs. Either we keep track of each new device that uses the SDK (which requires internet access) or we allow developers to have unlimited number of end users, as long as it is their own application that uses the SDK (does not require access to the internet).
The choice depends on both the platform and the licensing model you would like to support:
If your SDK will have access to the internet, you can protect it in two ways: by registering every end user of the SDK or by counting each time it is installed.
As with desktop apps, we need to perform a key verification before the user of the SDK gains access to the methods. A license key field can be a part of the constructor, a method or a config file stored alongside the SDK. If you only want to contact Cryptolens only once, you can save the response from Key.Activate
and use it instead of contacting Cryptolens. Please read more here.
A useful way to ensure that you retain control of all end user instances is to enable node locking.
For example, you can have different pricing tiers for the number of end users your customers can have (eg. 1 end user for trials, 10,000 for standard and 1,000,000 for enterprise), or you can charge for each new 1000nd activation. In the first case, you can simply enter the upper bound in maximum number of machines field. In the second case (where you charge for each 1000nd activation), you can set some upper bound (eg. 10,000) as the maximum number of machines, which you later increase as they start to reach this limit. For billing purposes, a script can be used to count the number of new activations since last time checked.
Instead of keeping track of each end user instance, we can instead count the number of installs and then charge for them. This can be done quite easily with data objects, which you increment each time a new install occurs (and recording this on the end user machine to not count the same machine twice).
If your SDK won’t have access to the internet, we can protect it by restricting which applications can call its methods, ensuring that only the applications that were developed by your customers can use the SDK. This is accomplished by storing the identifier of the application inside the license file, either inside the “Machine code” field or as a data object.
In this model, you can charge per developer or per application.
When you use the offline mode approach to protect your SDK, end users are not required to contact Cryptolens. However, to get a signed certificate, developers using the SDK need to contact Cryptolens. The signing utility will send the machine code of the device that requests a certificate, which allows you to enforce node-locking. For example, you can limit how many devices can be used for signing that use the same license key.
Depending on the platform, there will be different ways to retrieve the identifier of the application. If you have developed a mobile SDK, you can use the application/bundle id as a way of identifying the application. The distribution process will be similar to the one below:
When implementing SDK licensing, you have to assume that information in the license key (eg. notes field, activated devices, customer info) will be shared amongst all end users. In most cases, they will not see this, but we always have to assume they can, as this is technically possible.
A key verification call translates to a call to Activate. This method supports data masking using the feature lock field, available when creating a new access token. If you scroll down to License Key, you will see the fields that can be hidden. If possible, please hide all information unless there is field that you really need.
Note, all fields in a license key can be seen by all end users, unless data masking is used.
We will illustrate how SDKs can be protected on a class that contains helper methods for various mathematical operations, MathHelpers
. This class contains three methods that require different features to be true:
Abs
- requires F5 to be set to trueFactorial
- requires F6 to be set to trueFibonacci
- requires F7 to be set to trueWith this setup, you can easily customize the permitted methods in the dashboard for each license key.
From the customer perspective, SDK usage will depend on if we use the track all devices approach or offline mode.
The customer (developer using the SDK in their approach) will need to supply a license key to unlock functionality.
Since the customer has already provided the license key when signing the assembly, it will not be required when initializing the class.
Depending on the license key, some methods may or may not work.
As can be seen in the previous section, the license check occurs in the constructor when the customer provides us with the license key. In the track all devices approach with end user tracking, the code for this is essentially the same as the one in the key verification tutorial. The only difference is that we have added some code to take into account the expiration date and the features.
The permittedMethods
variable is a Dictionary<string, bool>
and we use it to track what methods the customer has access to.
If the license key verification was successful, we just need to add an if-statement that checks this before the method is executed.
Summary of how SDKs can be protected using Cryptolens Licensing.
Software Development Kit (SDK) licensing is when you distribute a component, usually a library, that is later going to be integrated as a part of another commercial solution.
In many ways, licensing an SDK or a desktop software is quite similar. In both cases, you will have to send a license key to your customers in order for the software to work. Many of the licensing models for desktop apps can be used in SDKs, although there are some that will be more suitable for SDKs. However, we need to keep in mind that end users are almost always different individuals, and the information that is stored in a license key will be shared with all end users (see the Privacy section) unless configured otherwise.
There are two ways of protecting SDKs. Either we keep track of each new device that uses the SDK (which requires internet access) or we allow developers to have unlimited number of end users, as long as it is their own application that uses the SDK (does not require access to the internet).
The choice depends on both the platform and the licensing model you would like to support:
If your SDK will have access to the internet, you can protect it in two ways: by registering every end user of the SDK or by counting each time it is installed.
As with desktop apps, we need to perform a key verification before the user of the SDK gains access to the methods. A license key field can be a part of the constructor, a method or a config file stored alongside the SDK. If you only want to contact Cryptolens only once, you can save the response from Key.Activate
and use it instead of contacting Cryptolens. Please read more here.
A useful way to ensure that you retain control of all end user instances is to enable node locking.
For example, you can have different pricing tiers for the number of end users your customers can have (eg. 1 end user for trials, 10,000 for standard and 1,000,000 for enterprise), or you can charge for each new 1000nd activation. In the first case, you can simply enter the upper bound in maximum number of machines field. In the second case (where you charge for each 1000nd activation), you can set some upper bound (eg. 10,000) as the maximum number of machines, which you later increase as they start to reach this limit. For billing purposes, a script can be used to count the number of new activations since last time checked.
Instead of keeping track of each end user instance, we can instead count the number of installs and then charge for them. This can be done quite easily with data objects, which you increment each time a new install occurs (and recording this on the end user machine to not count the same machine twice).
If your SDK won’t have access to the internet, we can protect it by restricting which applications can call its methods, ensuring that only the applications that were developed by your customers can use the SDK. This is accomplished by storing the identifier of the application inside the license file, either inside the “Machine code” field or as a data object.
In this model, you can charge per developer or per application.
When you use the offline mode approach to protect your SDK, end users are not required to contact Cryptolens. However, to get a signed certificate, developers using the SDK need to contact Cryptolens. The signing utility will send the machine code of the device that requests a certificate, which allows you to enforce node-locking. For example, you can limit how many devices can be used for signing that use the same license key.
Depending on the platform, there will be different ways to retrieve the identifier of the application. If you have developed a mobile SDK, you can use the application/bundle id as a way of identifying the application. The distribution process will be similar to the one below:
When implementing SDK licensing, you have to assume that information in the license key (eg. notes field, activated devices, customer info) will be shared amongst all end users. In most cases, they will not see this, but we always have to assume they can, as this is technically possible.
A key verification call translates to a call to Activate. This method supports data masking using the feature lock field, available when creating a new access token. If you scroll down to License Key, you will see the fields that can be hidden. If possible, please hide all information unless there is field that you really need.
Note, all fields in a license key can be seen by all end users, unless data masking is used.
We will illustrate how SDKs can be protected on a class that contains helper methods for various mathematical operations, MathHelpers
. This class contains three methods that require different features to be true:
Abs
- requires F5 to be set to trueFactorial
- requires F6 to be set to trueFibonacci
- requires F7 to be set to trueWith this setup, you can easily customize the permitted methods in the dashboard for each license key.
From the customer perspective, SDK usage will depend on if we use the track all devices approach or offline mode.
The customer (developer using the SDK in their approach) will need to supply a license key to unlock functionality.
Since the customer has already provided the license key when signing the assembly, it will not be required when initializing the class.
Depending on the license key, some methods may or may not work.
As can be seen in the previous section, the license check occurs in the constructor when the customer provides us with the license key. In the track all devices approach with end user tracking, the code for this is essentially the same as the one in the key verification tutorial. The only difference is that we have added some code to take into account the expiration date and the features.
The permittedMethods
variable is a Dictionary<string, bool>
and we use it to track what methods the customer has access to.
If the license key verification was successful, we just need to add an if-statement that checks this before the method is executed.