architect “Tom Dick Associates” – could see
how many licenses his competitor – architect
Harry and Partners” – has in use. And again,
the sheer amount of data would be prohibitive.
CodeMeter uses one central database kept
by the ISVs, who have a legitimate interest in
monitoring their licenses. They create licenses
for their users and give each user the right (in
the form of a cryptographic key) to use them,
encrypted by CodeMeter. The keys can only
be decrypted and used by their legitimate
users. The licenses are also signed to prevent
tampering. Using the Blockchain language,
we could call these truly miniature mini-blocks.
The consensus in this case is simple: “The ISV
is always right.”
CodeMeter : Blockchain
1:0
Blockchain for protecting
software?
For ISVs to enforce their licensing models, the
software needs to have a way to check licenses
reliably and securely. The best method for
doing this is encryption: The application or
digital content is encrypted and only users who
possess the right license can access the keys
needed to decrypt it. If possible, the decrypted
software or content should be active in a simi-
larly secure environment, like a dongle, system
service, or the cloud. This means that the end
user never has direct access to the keys.
This is the exact backbone of CodeMeter, which
offers the tools for encrypting software and
other contents as standard.
CodeMeter : Blockchain
2:0
Unambiguous identification
Another important aspect of licensing and soft-
ware protection is the correct identification of
the people entitled to use a license. CodeMeter
does this with a CmDongle, an account in the
CodeMeter Cloud, or a CmActLicense securely
bound to the user’s computer. The software
could only be used if the legitimate user has
the right license ready in one of these three
containers.
CodeMeter : Blockchain
3:0
License Usage Tracking
One interesting use case revolves around
tracking how often a software application or
other digital right, e.g. the right to 3D-print
a certain product, is used. The ISV should be
able to allocate the usage rights and to bill the
user for the actual usage.
Assigning such rights is a typical use case for
CodeMeter, as we have seen in our scenario
above. How does the transaction work in the
other direction? Let us return to our imagined
CodeMeter Blockchain.
We must consider two key questions:
How can we be sure that the user
indeed logs the transaction into
Blockchain?”
Suitable measures need to be put into place
that make sure that users can only access their
software or protected contents if the usage is
logged and billed. With CodeMeter, protection
and usage tracking are intrinsically linked in
the cryptographic system.
What happens if the user is offline?”
In this case, the transaction cannot be trans-
mitted and booked in. The ISV now has a
choice: Should the software be unavailable
in this scenario (risking disgruntled cus-
tomers), or should the lost revenue simply
be accepted? A choice between a rock and
a hard place. One workaround would be the
keeping of a local Blockchain plus delayed
reporting. However, as the local Blockchain is
not reinsured by the presence of other blocks
elsewhere, the most recent blocks could be
removed without the manipulation, becoming
visible in the distributed ledger.
CodeMeter offers two options for tracking
licenses: A tamper-proof counter built into the
license itself can be used to track how often it
has been accessed. The counter works even in
offline scenarios and would later report back
to the ISV. If pre-paid licenses are used, the
simple count-down could even work without
that report.
The other option would be a log file created
and protected by CodeMeter with Blockchain-
type methods.
CodeMeter : Blockchain
4:0
Working offline
An essential element of the Blockchain is that
its data is always current and duplicated across
the members of the ledger. This means the
connection is always-online. For many industrial
environments, this can be a deal breaker.
channel is only needed for post-paid models
which can again happen by file transfer.
CodeMeter : Blockchain
5:0
Borrowing and transferring
licenses
A final use case we need to consider is the
ability to lend and borrow licenses. For this
purpose, the license must be transferred from
a license server to a local device, where it
should be ready for use even without standing
connection to the license server. After a
certain period has expired, the license should
revert to the server.
To do so, CodeMeter transfers special mini-blocks:
The ISV creates a license with a defined and
restricted scope, which is activated at the user
by the license server.
If the ISV allows licenses to be borrowed,
CodeMeter has a special protocol for trans-
ferring this block to another computer, specifi-
cally in a secure CmContainer. The new block
is signed by the license server and encrypted
for the target container. The borrowing is
recorded in the history on the license server,
so that the license automatically reverts when
the lending period expires. The block is also
invalidated when the license is returned.
Compared to Blockchain, the license blocks
used by CodeMeter can be cut back and the
history deleted after the license has been safely
returned. This makes sure that the amount of
data used in the process and the performance
of the machines involved stays at the optimum
level and that the solution scales to meet its
demand.
CodeMeter : Blockchain
6:0
Conclusion
CodeMeter was tailored specifically with the
requirements of software protection and licens-
ing in mind. There is one central entity (at the
ISV) creating and managing the licenses. The
amount of data held by the end user is kept to
a minimum. Offline use and offline transfers
are explicitly an option. Licensing and protec-
tion are inseparable from the cryptographic
processes. And some of the familiar methods
from Blockchain are used where it makes
genuine sense to do so.
CodeMeter offers an opportunity to transfer
and to use licenses offline. This can be done by
an encrypted update file and dongle. A back-
9