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.
2. The user activates another license for the
old, allegedly lost CmContainer. CodeMe-
ter License Central recognizes that the
container has been blacklisted and locks
the licenses.
3. 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 impossi-
ble 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. CmActLi-
censes 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.
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 CmContain-
er, 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 down-
load 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.
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
9