Category: Tips on Using our Service

Sending news and update notifications using Messaging API

Posted on

The new Messaging API allows you to easily send notifications to some or all of your end users. For example, it can help you to notify customers running an older version of your application to upgrade as well as keep them updated about the latest news.

Getting Started

It’s quite simple to get started with the Messaging API. The dashboard is available here, which is where you can send the messages. In order receive them in your own app, you can use the GetMessages method. One thing to keep in mind are the two optional parameter, time and channel. These allow you to tell Cryptolens which messages you want to receive. Time is used as a reference when the last message was seen and channel is a way to group those messages. If these are not specified, all of the messages will be returned.

For example, let’s say you want to implement updates notifications. In that case, we can use the code below to ensure that only older versions of the software receive the message. The version itself is specified as a unix timestamp in the currentVersion parameter, which should be the time when you published the release.

var currentVersion = 1538610060;
var result = (GetMessagesResult)Message.GetMessages("token with GetMessages permission", new GetMessagesModel { Channel = "stable", Time = currentVersion } );

if(result == null || result.Result == ResultType.Error)
{
    // we could not check for updates
    Console.WriteLine("Sorry, we could not check for updates.");
}
else if (result.Messages.Count > 0)
{
    // there are some new messages, we pick the newest one 
    // (they are sorted in descending order)
    Console.WriteLine(result.Messages[0].Content);
}
else
{
    // No messages, so they have the latest version.
    Console.WriteLine("You have the latest version.");
}

Console.Read();

You can see the entire tutorial about updates notifications for more details. There is also about notifications.

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.

New AI feature helps optimize software pricing

Posted on

Setting the price for a product you intend to sell is hard, especially when pricing usually changes over time. Cryptolens’ new AI feature helps software providers set the price by analyzing how each individual user uses their software.

Problem with existing pricing models

It is often challenging for software providers to price their product optimally.

A good example that demonstrates this is when you set the price for accounting software. Imagine you have two groups of customers: those that use the software regularly in their profession (eg. accountants helping other companies) and those that only use it once a month (eg. small businesses). It makes sense to have different pricing models for these two groups: professionals can be charged monthly (and are very likely to pay more) and the smaller business can pay per usage (eg. per generated monthly report).

As a result, software providers are able to increase their revenues and capture both customer groups by taking into account the true value the software has for each group, and adjusting the pricing model to meet the needs for each group.

How Cryptolens’ new AI feature optimizes revenue

Cryptolens’ new AI feature analyzes the usage information generated by each user (and the history from previous users) and determines the value a product (and its features) has for each user, and then helps to determine the best pricing model for that particular user or user group.

For example, if the value of the features is higher than the price of the product, it would be reasonable to increase the price. If, however, only a subset of the product’s features are used, a new product based on a subset of the features offered at a lower price could be a solution (or potentially suggest an alternative licensing model such as usage-based model).

The goal is to provide insights on the value of a product and its features for each user, and assist in creating new product offerings with more optimal pricing.

Getting started

In order to benefit from our AI analysis, the following is required:

First, you need to register each time a customer interacts with a certain feature of the product (if you have a licenseKey object, you can call the new RegisterEvent method). For example, when they start the salary module (if it’s an accounting software), you can send FeatureName=”SalaryModule” and EventName=”start”. If they generate a report, you can keep the feature name, but change the event name to “report_generated”.

The second step is to register successful transactions (eg. when the customer buys the software). In that case, you can still call RegisterEvent method, and include the value and currency parameters.

Please get in touch with us if you need any help setting this up. We are currently looking for beta testers and would be happy if you can participate. You can reach out to us at [email protected].

Once enough data is collected, you will be able to see it in the analytics dashboard.

Floating licenses supported out of the box

Posted on

Floating licenses allow your customers to use a license on a limited number of machines simultaneously. For example, they can have your software installed on 100 computers, but only be able to use it on 20 of them at once.

This is similar to node-locked licenses (aka machine code locking) that is part of the Cryptolens for quite some time, with the exception that a license does not have to be deactivated when they are to be used on a new device.

Note: floating licenses are supported since v405 of Cryptolens.Licensing library for .NET. Support for C++ is coming soon.

Examples

Cryptolens Licensing for .NET (new package)

Posted on

You might have noticed that we have changed from being called Serial Key Manager to Cryptolens. As a result, the design language, domains and naming of our products has changed. Now, we are also updating the .NET packages that are used to interact with the Web API. We will describe the changes below (you can also see the release notes)

New package

The new package, Cryptolens.Licensing, is essentially the same as SKGLExtension, with several improvements described below. You can either install it using NuGet or download pre-compiled binaries for the desired framework. Read more here.

.NET Standard

The new library introduces support for .NET Standard 2.0, which means more platforms in the .NET family can use it (eg. .NET Core 2.0). You can see all the supported platforms here. There is still support for .NET Framework 4.0, although most of the new features will be in the .NET Framework 4.6.

License verification on the server

Previously, most of the license validation logic was performed on the client, eg. you had to check expiration, features in the client code. The new Cryptolens client now supports the ability to create rules and perform these checks on the server. The rules are set up using feature definitions on the product page. You only need to set Metadata=True, which will give you access to the license key status. A code example is shown below (this will automatically check that the key has not expired and that it’s not blocked).

var result = Key.Activate(activateToken, new ActivateModel() 
{
    Key = "license",
    ProductId = 3349, 
    Sign = true, 
    Metadata=true
});

if(result.Metadata.LicenseStatus.IsValid)
{
    Console.WriteLine("License is valid!")
}

A good practise is to verify the signature of this license status object, which can be done with VerifySignature. At the moment, this requires .NET Framework 4.6 or .NET Standard 2.0 to work.

3 steps how to protect your software application before release

Posted on

Let’s assume that you have developed a software application (eg. app) that you are about to sell. Then, there are three things you need to consider:

  • Licensing – this is used to keep track of the type of features that end users have bought. A simple example of this when your user has to type a license key to unlock more functionality. When selecting these kinds of systems, it’s important that the system both supports offline mode and is cloud-based. The advantage of cloud-based systems is that they are more scalable and secure (eg. you have full control of all end users).
  • Obfuscation – this is used to make your program binaries (eg. exe and dll files) harder to disassemble. This is especially important for .NET apps, since existing tools make this very simple. A word of warning though: none of the available systems are 100% safe, and even the well-respected systems are being cracked within days of software release.
  • Web API – imagine your algorithm is so important that you don’t want to risk it being leaked. Since obfuscators are never 100% safe (mainly because in the end, the code will be executed on the client machine), the only secure way is to never run this code on client machines that you don’t control. Instead, you can create a Web API method that you host yourself and then allow your program to consume it. In this case, the algorithm is safe at the cost of constant internet access requirement.

To sum up, the first system to consider is licensing, since this will remove the administrative burden of keeping track of the type of rights your customers have to the software. As a bonus, many cloud-based licensing systems support integration with payment processors. In the end of the day, the goal is to ensure payments and license verification are automated, so that you can focus on developing the features that really matter to your customers.

For more information, please see this page.

How to Skip Royalties for Mobile Apps using Software Licensing

Posted on

Problems with App store?

Limited Functionality

One clear problem with any App store is that you’re locked in to use their limited set of licensing models (i.e. ways to sell your app). This is evident when you want to support proper subscription based model (i.e. customers need to pay on a monthly or early basis to continue to use your app). Many big companies, such as Microsoft and Adobe, are starting to charge their customers on a recurring basis, for instance in Office 365 and Adobe Creative Cloud. Now, you no longer buy the “product” but rather the “service”, which means that we want to give our customers a great user experience independent of the platform, may it be a tablet, a smartphone or a PC. Unfortunately, this is very difficult to implement and manage across multiple platforms  if you use built in functionality of the App store (and other app stores) because you’re locked in into their ecosystem.

High Royalties

Not only are you locked in into their ecosystem, they also take 30% of your revenue that you could have used to develop your application further.

Say you sell your service for $100/per month. Then you have to pay $30 per month in royalties, which adds up to almost $400 per year. Note, this is in addition to the fee that you payed to register a developer account.

How is this solved now?

One question that comes into our mind is following: How do companies like Spotify and Uber avoid to pay Apple the 30% transaction fee? The common denominator is that they use a custom licensing component that they maintain themselves. For example, to use Spotify, you need an active subscription (even if the app is free), which you can get outside of the Apple store, for example, on Spotify’s website. So, technically, no transaction occurred in the app itself.

Solution

The idea is to avoid using the built-in functionality of the App store as much as possible. You can do this in the following two ways: either you develop a licensing component from scratch or use a third party.

Building from Scratch

If you have some time at your disposal, you can create a licensing system from scratch or use an open source library, such as SKGL. The advantage is that you get to design it specifically for your needs. Using open-source systems can save you some time, but please keep in mind that you might instead need to spend time on configuring it and possibly extending depending on your requirements.

Using Third Party

The idea here is simple: “Why invent the wheel?”. Software licensing and monetization is such a common problem so there are solutions out there that can do just that.

First of all, they will probably cover many cases and secondly they are also cheaper than doing it on your own (after all, think about the time it would take, which is approx. 2-3 months, and later maintenance).

The critical bit is maintenance. Imagine that your business model changes and you have to restructure your licensing solution. If you use a third party, they most likely have what you’re looking for, so changing won’t be hard. Otherwise, you have to do it yourself from scratch.

Example solution using SKM

In order to get a working licensing component, one way to go is to use SKM – a cloud based licensing as a service. SKM is like a toolbox that contains many of the tools that you would need to set up a licensing system within hours. In comparison to many of the alternative solutions, it’s aim is to be accessible, which includes being affordable and simple-to-use. Moreover, one of the values is transparency and developer friendliness; many of the tools used in SKM are available open source and free of charge.  It’s very simple to get started.

How to keep your start-up safe?

Posted on

When building a start-up company, it might be tempting to overlook some important security aspects. For example, do you commonly use public WiFi networks when you’re on the go? Do you enter your PIN securely? These are just some of the questions. This post aims to give you some basic ideas to think about and potentially to implement in your company. But remember: no matter how strong cryptography you are using – even if it unbreakable – the weakest link is the end user. So, it’s worthwhile to continuously educate the end users (eg. employees) about potential threats, as well as promote an open atmosphere that encourages communication between IT and the end users.

SKM does everything to keep your app as safe as possible, but it’s equally important to keep in mind things you can do to increase security. Remember – in case of uncertainty – always ask!

Office Guidelines

Depending on your office place, you may be exposed to various threats. For example, unauthorized people (eg. visitors, cleaning service, people from other departments) may pass by your desk, and if you happen to have confidential information on the desk, it may no longer be a secret. Or, what if you forgot to lock your PC…?

  • Lock Office & Computer: Always lock your PC when you leave your place. If it is possible, lock the office too.
  • Clean Desk Policy: Don’t leave stuff on your desk, for example, during a lunch break.
  • Personal Devices: Don’t set up your own WiFi or use personally owned devices.
  • Wear Security Badge: Always wear your security badge. When you spot people without one, walk them to security.
  • Never Let Unknown in: Never hold the door for people you don’t know. Be careful with tailgaters, i.e. people that get in right after someone else with access.
  • Printing Confidential Information: Do not print confidential information. Keep in mind that some printers store everything you print.

Password Guidelines

A common mistake is to use the same password on multiple websites. If one website gets compromised, all your other accounts will be endangered.

  • Unique for Critical Services: Although it’s a good practise to keep a unique password for all your accounts, not all websites might be critical to protect. You should, at the very least, have a unique password for your email, banking, and other accounts that contain sensitive information about you or your organization.
  • Two Factor Auth: For those websites that support two factor authentication (2FA), consider using it. Should your password be compromised, there is another level of authentication, one that is not as easily compromised as the password itself (unless you lose your phone, etc).
  • Password Design: The password should contain upper/lower case letters, numbers and symbols. It should not contain words from the dictionary (or their derivative). Eg. Pa$$w0rd is a bad password.

Smartphone Guidelines

A smartphone contains more sensitive information than we think: our email messages, passwords, documents downloaded from the cloud, pictures, personally identifiable information, and more. Therefore, it’s important take great care of it.

  • PIN: Lock the phone with a PIN or a password
  • Encryption: Encrypt the phone and any additional SD storage, if applicable.
  • Remote Wipe: Set up remote wipe and device tracking (eg. Android Device Manager, Exchange).
  • Shoulder Surfing: Prevent shoulder surfing. When entering the PIN, take some distance from others. Think of it as the PIN to your credit/debit card. Would you want people behind you to see it?

On the Go – Traveling Securely

By travelling, you are exposed to many more risks than in the office. Using public WiFi and shoulder surfing are just some of the examples that pose a threat.

  • Public WiFi: Public hotspots are usually not encrypted, which means everyone can see your activity. It’s better to use cellular connection, if applicable, or a secure network. But, always assume everything you do is being tracked.
  • VPN: Use VPN to encrypt all web traffic (eg. when you use a browser).
  • You are being Watched: Any time you are online, assume that you are being watched all the time: all the websites, the passwords, etc are scrutinized by a hacker. When visiting websites, ensure that you only use secure connections, i.e. those starting with https://.
  • Confidential Documents in Hotels: Always keep important documents close to you and don’t leave them openly on the desk. Think ‘clean desk policy’.
  • Your Neighbours: Keep in mind that people around you may intercept your conversations.
  • Unattended Device: Best rule of thumb, ‘don’t leave your device unattended’. This reduces the risk of theft. If you need to leave it, hide it (eg. in a car).
  • Shoulder Surfers: Be careful and take distance from people when entering you PIN, especially if it is used to encrypt the device.

Email Guidelines

A common misconception is to assume that emails are private. That’s far from reality. Emails you send across the internet are in plain text, readable by anyone. Note, internal email communication may or may not go through the internet (i.e. it might stay within the company), however, check this with IT dept.

  • Emails are Insecure: Assume everything you send by email can be read by everyone. Sensitive information should be sent in an encrypted form, for instance using PGP.
  • Security may be Dissolved: Even if you assume that emails don’t leave your company’s server, keep in mind that your colleagues may have their emails on their phones, tablets, etc. It’s enough for the hacker to compromise one of the devices to be able to intercept the communication. Therefore, always encrypt emails.
  • PGP Pitfalls: If you’ve come this far, ensure that you check the fingerprint of the certificate.