Lost licenses – What now?
"My dog ate my dongle." What sounds like a poor excuse is actually the start of a true story I like to tell. Or almost true, because the dog did not eat the dongle, but a piece of paper with the dongle password. Whatever the dog ate, the story illustrates how people can lose licenses or license containers, or access to their license containers.
With CodeMeter, license containers are called CmContainers and come in the form of separate hardware (CmDongle), encrypted license files bound to a known device (CmActLicense), or user accounts in the cloud (CmCloudContainer). Independent software developers can choose which CmContainer types to provide to their users; they can mix and match CmContainer types to their liking, let their users decide, or set specific rules, such as regional restrictions.
Depending on the CmContainer, licenses might get lost in several ways. In all of these scenarios, developers will want to help their users quickly and ideally automatically, without need for any manual action on their part. At the same time, they want to avoid the potential outcome that the users or “finders” of the lost license have access to more licenses than they legitimately own.
Automatic Replacement
CodeMeter License Central plays a key role for automating this process. As the developer, you decide whether users are allowed to replace licenses in another CmContainer (irrespective of the type in question) and how often the users can do so by themselves. The restriction can be a finite number of licenses or an enforced wait period before trying another recovery. If you know that your user base typically replaces their hardware e.g. every three years, a replacement at the start of the period and again after two years would be a reasonable timeframe that keeps the need for support down. You can, of course, allow additional license replacements manually at any time to show your goodwill where you believe it warranted.
When using CmActLicenses, you can also put in place certain rules for replacing licenses in a new CmActLicense on the same device. Again, you define the initial number and the minimum hold period before another license replacement is allowed. You can also choose the hardware properties that show whether the user is still using the same machine. This reduces the risk of a continued fraudulent use of the old, allegedly lost CmActLicense. Even if a lost license was used alongside its replacement, it would normally be bound to the same computer, which constitutes no real threat for single user licenses. This allows you to be more liberal with the restrictions than you would be with license replacements in any other CmContainer. Again, you have the power to authorize manual replacements at any time.
Automating the manual authorization process via SOAP is an appealing option. In this case, you would not allow any automatic replacement, and instead ask the user to contact a portal that checks the criteria defined by you before deciding whether the user is entitled to an automatic replacement. If this is the case, the replacement can be released transparently via SOAP, using a completely automated workflow.
Blacklist
When using automatic license replacements in a new CmContainer, you can either allow the process for the entire existing CmContainer or only for the specific licenses to be recovered.
You can also put the affected CmContainer on a blacklist, using one of three options for applying the blacklist to the old CmContainer:
- CodeMeter License Central can generate an automatic update (as a honeypot trap) that enacts the block. Your software will regularly check via the Internet whether any automatic updates are available. If the honeypot update is imported, it locks all licenses in the old CmContainer.
- The user activates another license for the old, allegedly lost CmContainer. CodeMeter License Central recognizes that the container has been blacklisted and locks the licenses.
- You export the blacklist and integrate it in the next version of your software. Should the user try to use the new version with the old “lost” CmContainer, your software locks all of your licenses in that container.
Sample code is available for scenarios (1) and (3). The latter option (3) even allows you to set a time-delayed lock, which hides the link between the version update and the blacklist-ing and makes it more likely that the dishonest user contacts your support team. After all, it is in your interest to record such cases, so that the user can be contacted and persuaded to buy a new license. The record is kept automatically in cases (1) and (2).
A less radical option would be to withdraw the old replaced license. As in cases (1) and (2), an automatic update would be created and rolled out by your software or imported in response to any action by your user. In this case, you would only remove those licenses that were replaced in a new CmContainer but were obviously not lost and are still available in the old CmContainer.
Checkpoint Licenses
The blacklist mechanism described above requires the information to be transferred back to the user. But what if an unscrupulous user keeps operating the old CmContainer in the privacy of his home computer, cut off from the Internet and possible updates? This is virtually impossible in our age of IoT, IIoT, and cloud applications, but CodeMeter License Central also packs a technical solution for these unlikely cases.
Licenses can also be configured as checkpoint licenses. These are perpetual licenses from the user’s point of view, but technically fitted with an expiry date, which is a period of time, defined by the developer, from the licenses’ first activation. As long as the licenses remain valid, the period is renewed regularly. This is done by returning and reactivating the license as the checkpoint draws closer. The expiry timer is then reset, and the license works as if nothing has happened.
Should a user keep using the old CmContainer offline, the licenses within will expire and become worthless. The secure virtual clock built into the CmContainer makes it impossible to set back the clock for the licenses. These checkpoint licenses do not need a permanent Internet connection, but simple checks back at regular intervals. Sample code is again available.
CmDongles
CmDongles can break. This is unlikely with an MTBF (Mean Time Between Failures) of several million operating hours. CmDongles can also be destroyed by force, even if their robust design, especially of the CmStick/B and CmStick/C Basic, makes this a rare event. In either case, there is little to worry about when replacing the CmDongle if the user returns the damaged piece.
It is a different story if the CmDongle has physically disappeared, possibly thrown out by mistake with an old computer or stolen, in all likelihood by a common thief who mistook it for a memory stick. This used to be quite rare and is even rarer now that flash memory and storage have become cheaper than ever before. It is very unusual for a CmDongle to be deliberately stolen. In such cases, it often pays to put the lost CmDongle on a blacklist. There have been stories about CmDongles suddenly turning up again at the first mention of a potential blacklisting.
CmActLicenses
Licenses can be moved between computers by returning them to CodeMeter License Central. Valid licenses can also be parked in the cloud, specifically again in CodeMeter License Central, if a computer needs to be reinstalled. CmActLicenses could only be lost if the entire computer has disappeared or if the hard drive they are stored on is reformatted. This rarely happens by accident, because migrating to a new computer is a complicated process that is usually planned well ahead of time. If it does happen, automatic replacements and blacklisting can take care of the process, either by replacing the lost license in a new CmContainer if the old computer has indeed been discarded or by replacing the CmContainer on the same computer if the system has ‘only’ been reinstalled.
It can happen that licenses break. This might be the case if the user changes too much of the computer’s hardware. There are almost no false positives – the license seeing a change where none has occurred – because of the robustness and tolerance for errors built into CmActLicenses. In normal office settings, it has become unusual for users to open up and tinker with their computers. Modern computers pack a lot of power at low prices, which has turned customization into a hobby for IT enthusiasts and gamers. Broken licenses are therefore a very unlikely occurrence.
The same goes for invalid licenses. These can occur if the license file and the values hidden in the computer do not match up, e.g. because the user has manually changed a file or if another software has written over these values. The hidden values are, however, kept in several redundant copies, again making this event very unlikely to happen.
Both for broken and for invalid licenses, the best solution is to replace them in a new CmContainer, combined with a blacklist mention.
CmCloudContainer
CmCloudContainers live in the Wibu-Systems cloud and cannot be lost by definition. CmCloud Containers are bound to known users who can access them with a credential file. It can happen that these credential files are lost or stolen. In both cases, the users could download a new credential file from their license portal, which invalidates the old access details. You can find more about CmCloudContainer in this issue of the KEYnote magazine.
KEYnote 39 – Edition Spring 2020