CodeMeter vs. Blockchain
Germany’s federal government recently released its “Blockchain Strategy” to great fanfare. Judgement is still out on whether this strategy will become part of the great IT success story of the new federal ID or the electronic patient’s card. One thing is sure: Blockchain has become such a hype that even the slow-moving world of federal politics is taking note. No wonder, then, that more and more software developers or other owners of digital assets, such as the IP in 3D printers, are asking us about Blockchain and its potential.
Does CodeMeter use Blockchain technology?
CodeMeter is a DRM system for software and digital contents tried and tested by millions of users since its launch in 2002. By comparison, while research into the cryptographic protection of blocks has been going on in some form since 1991, Blockchain has only recently become a practical, viable technology. This makes CodeMeter its older brother. It also relies on related cryptographic processes and even uses mini-block technology in some aspects: Both technologies developed in parallel and share some family traits from their origins.
What is Blockchain?
The special idea behind Blockchain is that the data (all data) is not kept at one central location like a bank vault but spread out across the Internet on a so-called distributed ledger on many computers.
A member of the chain can then enter a transaction into the ledger. Since all other members on all links of the chain have to have the same Blockchain, the end product is an unalterable consensus log.
Data in Blockchain cannot be altered at a later point, making it essentially forgery-proof.
The data is also visible to all members, making the Blockchain transparent. There is also an option to encrypt data, but this is not the standard practice.
How do we establish consensus?
One very popular consensus method is called the “proof-of-work”. It relies on solving a cryptographic operation that needs a certain amount of time. For cryptocurrencies like Bitcoin, so-called miners” do this job. After the task has been accomplished, the new block is added to the chain. If there are several Blockchains to choose from, the longer chain wins the race. A miner who holds more than 50% of the computing power in the chain could, in theory, manipulate the chain after the fact.
Solving cryptographic tasks is a computing-intensive challenge. What makes it even worse is that many miners will be working in parallel and only the first past the post will have the right to add a new block. This type of consensus stands on very shaky ground from an environmental standpoint, as it wastes masses of energy by design.
Blockchain for checking licenses?
Let us imagine how Blockchain could be used for licensing purposes. This is the home turf of Wibu-Systems with our solution that is favored by thousands of publishers (Independent Software Vendors, or ISVs) and millions of users.
Let us now use Blockchain for CodeMeter. Blockchain would be kept in identical copies at all ISVs. Company “A-CAD” could, for instance, see how many licenses company
B-CAD” has created. Even if the data is kept in encrypted form, this would not be a good idea, as every member of the chain would, at the very least, see the number of transactions happening around them and draw their own conclusions. Let us ignore the problem of the sheer amount of data that all ISVs and their users have to keep and keep updating.
The imaginary scenario obviously takes us nowhere. Let us instead imagine a scenario with one Blockchain per ISV. Again, one end user – say, 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 similarly 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 software 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 transmitted and booked in. The ISV now has a choice: Should the software be unavailable in this scenario (risking disgruntled customers), 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.
CodeMeter offers an opportunity to transfer and to use licenses offline. This can be done by an encrypted update file and dongle. A backchannel 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 transferring this block to another computer, specifically 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 licensing 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 protection are inseparable from the cryptographic processes. And some of the familiar methods from Blockchain are used where it makes genuine sense to do so.
KEYnote 38 – Edition Fall 2019