Tag: sdk

Offline SDK protection in .NET with software licensing

Posted on

A common way to distribute functionality is by creating an SDK that can be consumed by developers inside their own application. The advantage of shipping functionality as an SDK is that you can focus on improving the core algorithms without the need of creating a separate GUI for a specific use-case.

Cryptolens already offers a way to protect SDKs and today we would like to introduce a new way that was specifically developed for .NET libraries that are permanently offline or where a perpetual licensing model is preferred.

How it works

The idea behind the new SDK licensing technique is to require developers to sign the application that will use your SDK with a special utility. When this is done, a new file with the certificate will be created in the same folder, which can later be verified when the SDK is called. This ensures that only authorised developers can develop applications that use your SDK.

Inside the SDK, you only need to call Helpers.VerifySDKLicenseCertificate() with your RSA public key, and it will make sure that the certificate is valid. A nice feature of this method is that it also returns a LicenseKey object, which you can use to decide which features should be available, etc. You can see a demo of this here.

In order to sign an assembly, developers can use a special utility that is available open-source on GitHub. Developers need to provide their license key and the assembly signing utility will automatically send their machine code so that you can control which developer machines can perform the signing operation.

Getting started

To get started, please check out the tutorial for SDK developers on the following page. All the helper tools and demo projects are available open-source in our GitHub repo.

How to protect SDKs with Software Licensing in .NET

Posted on

Software Development Kits (SDKs) are a great way to give your users the ability to build on top of the functionality offered by your library/package. From a licensing perspective, desktop apps and SDKs are quite similar, which we will go through in this article. We will first take a look at the applicable licensing models and then skim through some example code. You can jump directly to the tutorial here.

Licensing Models

SDK licensing is special since the developer of the SDK (the customer) is not its end user. Instead, it’s their customers that will be the end users. In this article we focus on “node-locked” and “pay per install” licensing models (you can read about all applicable licensing models here).

Node-locked is equivalent to “pay per machine”, which essentially means that each time a new machine activates the license, this is recorded so that it can be taken into account when you charge the developers (your customers). Each user will be able to re-install the app that uses the SDK any number of times, without affecting the counter.

Pay per install is similar to “pay per machine”, with the only difference being that fingerprints of the end user machines are not recorded. Instead, a counter is used that increment whenever the SDK is first launched. With this model you get a bit less control of end user instances, but since the fingerprints (aka machines codes) are not tracked, the subscription cost for Cryptolens will reduce significantly (since you are only paying per license key).

In both of the models above, you could create multiple plans for your customers that depend on the actual usage of the SDK. Eg. 1-10 could be a testing tier, 10-10,000 could be another pricing tier, and so on.

Example

From a developer standpoint (eg. your customer), the license key will have to be specified to unlock functionality of your SDK. You could potentially have different pricing tiers depending on the methods that your customers will use. Below is an example of class initialisation that requires a license key to work.

var math = new MathMethods("FULXY-NADQW-ZAMPX-PQHUT");

Console.WriteLine(math.Abs(5));
Console.WriteLine(math.Fibonacci(5));

To see all the code, please take a look at the entire tutorial.

Obfuscation

If you have algorithms in your SDK that you want to be 100% secure from reverse-engineering, we would recommend to create an API endpoint for them hosted in the cloud. Most of the cloud providers support “server less” functions, eg Azure Functions and AWS Lambdas. These are quite simple to setup. Your server less functions would require a license key and potentially a machine code to return a successful response. On the client side, you could use libraries such as RestSharp to access your API endpoint. We will cover this in a future article.