Should Software Licensing Always Follow the Latest Trends?

Certificates and JSON Web Tokens are just two of the many technologies I have encountered over the past 23 years at Wibu-Systems working in software protection and licensing. Interestingly, these suggestions did not come from my colleagues but from customers, who asked why we were not using these technologies and suggested that things could be much simpler if we did.

CodeMeter has been on the market for more than 20 years. Our customers – Independent Software Vendors (ISVs) – use CodeMeter to protect applications that often have similarly long lifecycles. For them, continuity, compatibility, and steady improvement are far more important than chasing the latest trends.

Our Motivation

Becoming best-in-class comes from experience and from putting that experience into practice. When we created CodeMeter, and especially the Universal Firm Code, our architecture team already had several hundred years of combined hands-on experience in applied cryptography, particularly in software protection and licensing.

It is therefore no surprise that many of the fundamental principles found in the technologies mentioned earlier were already implemented in CodeMeter long before those technologies even had the names we know today. After all, they all rely on the same cryptographic foundations: symmetric encryption, asymmetric encryption, hash functions, and more.

Of course, it is gratifying to see that CodeMeter has followed a structure similar to JWTs for many years and internally uses certificate chains. But that is no reason to become complacent. Remaining best in class requires constant questioning, continuous practice, and ongoing improvement.

Behind the Scenes

“Encryption is the key.” This could easily describe the guiding principle behind CodeMeter. To effectively protect software against reverse engineering, modification, and piracy, CodeMeter relies on encrypting the application itself, including executable files and data files.

In textbooks, one often finds the following simplified recommendation, for example when sending encrypted emails. If data is to be securely transmitted from a sender (S) to a recipient (R), R first generates an asymmetric key pair and sends the public key to S. S encrypts the data using a randomly generated session key and then encrypts that session key with R’s public key. The encrypted data and the encrypted session key are then sent to R. Only R can decrypt the session key, and therefore the data itself.

Practice vs. Textbook Theory

In software protection, two aspects contradict the standard textbook model:

• First, while the recipient of an email has a strong interest in keeping their private key secret, the user of a software application often has no such incentive.
• Second, if the same email content is later sent to another recipient, a new session key is used. With software, which is often large and distributed through multiple channels, this approach is impractical. It would require providing each user with a separate program encrypted with a different session key.

A Solution Inspired by the Textbook

For this reason, CodeMeter generates a key, similar to a session key, to encrypt the software. In simplified terms, this key is used to encrypt the application, following the same principle described in the textbook example.

However, this key must also be available to the user in order to decrypt and run the software, while at the same time being bound to a license. This is where CodeMeter’s key technology comes into play. By design, every license contains a master key from which many additional keys can be derived. For simplicity, assume one key per license. This key is delivered to the user together with the license – again following the textbook principle.

CodeMeter generates a key pair in the target container. For a CmDongle, this happens during manufacturing. The public key is then sent to the software vendor in the form of a context file. CodeMeter uses this public key to encrypt the license – most importantly, the key contained within it. The license is then delivered to the user, where it is decrypted and securely stored.

With a CmDongle or a CmCloudContainer, this happens inside the dongle or in the cloud, hidden from the user. With a CmActLicense, the process takes place inside CodeMeter Runtime, using hardware properties of the target device to generate the key pair. More details about this mechanism can be found under SmartBind. In the actual implementation, an additional internal mechanism is used for security and performance reasons, which is beyond the scope of this article.

Is the License Genuine?

Securely transferring the keys required to run the software provides a high level of protection. However, another important question remains: Is the license itself genuine?

An attacker could generate an update file and encrypt it with the public key of the target container. The container must detect such a fake and reject it.

To prevent this, updates are digitally signed with a private key. The corresponding public key is stored in the target container and used to verify the signature. Each software vendor has a unique signing key. To ensure that the public key in the container cannot be forged, CodeMeter relies on mechanisms similar to certificate chains.

Is the Target Container Genuine?

A genuine target container will reject a fake update. However, CodeMeter must also avoid issuing updates to a fake container. If this were possible, a fake container could decrypt the data, including the keys it contains.

To address this, CodeMeter again relies on certificate-like mechanisms. With a CmDongle, a certificate for the public key is created during manufacturing and stored inside the dongle. For a CmCloudContainer, this process is securely handled in the cloud using a key pair unique to each cloud system.

For a CmActContainer, the process occurs within CodeMeter Runtime on the user’s target system. From a cryptographic perspective, this is the weakest link in the chain. At this point, the principle shifts to “trick, deceive, and camouflage,” since the standard textbook approach can no longer be applied directly.

JSON Web Tokens (JWT)

Returning to the original question: why not simply use certificates and JWTs: a JSON Web Token consists of a header, payload, and signature. CodeMeter licenses follow a similar structural principle, but use a different format.

In most discussions about JWT people are actually referring to JWS (JSON Web Signature). However, JWS is not suitable for transmitting confidential information such as private keys. For transmitting confidential data, JWE (JSON Web Encryption) is used instead. Best practice is typically to nest a signed JWT inside a JWE so that the data is both signed and encrypted.

In principle, this is exactly the approach used by CodeMeter: the license data (the update file) is both signed and encrypted.

Another key difference is that CodeMeter provides the entire key management infrastructure required for licenses. When using JWE, developers must implement this part themselves. Tokens usually have an expiration date, which requires regular renewal. In offline scenarios, this can complicate things for the user. If the expiration period is set far into the future, revocation becomes difficult. While CodeMeter simulates its own internal clock, tokens in offline scenarios are verified against the system time of the target device. How resistant that is to manipulation is something I leave for the reader to judge.

For very small systems, or systems where encryption is not required, we have already combined CodeMeter with JWT. In these cases, the keys required to generate JWTs are stored within CodeMeter. A usage counter can define the authorization so that only a limited number of JWTs can be generated. This allows the JWT to be created on the user side, even in an untrusted environment. In our projects, the payload typically consists of the device fingerprint and the license information.

Certificates

The principles behind certificates are also used in many areas within CodeMeter. However, certificates themselves are not intended for transporting confidential data, and due to the ASN.1 format, they are often relatively bulky.

In a purely certificate-based solution, a key pair would typically be generated on the target device. The public key would then be sent to the software vendor, who would issue a certificate that adds the device to the set of trusted systems. Licensing, or the equivalent entitlement logic, would still need to be implemented separately.

Binding the certificate to a specific device could be implemented, for example, by storing a device attribute in the certificate’s CN (Common Name) field. Verification on the target device would then typically follow these steps:

• Determine the device property
• Read the property stored in the certificate’s CN field and compare it with the detected value
• Verify that the certificate itself is valid

Ultimately, this reduces verification to two yes/no comparisons. At the machine level, these become conditional jumps (JZ or JNZ) that even a moderately skilled attacker could patch, allowing the certificate to be reused on another system.

With CodeMeter, by contrast, the private key is derived from the device properties themselves, so patching such checks does not enable a working decryption of the protected application.

License Return and Dynamic Data

A key feature of CodeMeter is the secure return of licenses. With a CmDongle or a CmCloudContainer, this process is securely implemented by design.

For a CmActLicense, the license is always replaced with a new one. A continuously increasing generation counter prevents the license file from being reset, and therefore duplicated, after it has been returned. The same mechanism applies to dynamic data such as counters or relative time values. With token- or certificate-based solutions, a revocation mechanism would need to be implemented instead. In offline scenarios, however, enforcing such revocation procedures is extremely difficult.

Blockchain

When I was a child, money was simply a number printed on a piece of paper. It could have been a banknote or an entry in a savings book. Today, for most people, money is simply a number stored in a database on a bank’s server. But what would happen if someone changed that number to zero? Then all of my savings would be gone “overnight.” If you ask a security expert, they might think of a hacker attack. If you ask a skeptic, they might imagine the bank itself doing this on the orders of a government authority. Since I worked in home banking long before joining Wibu-Systems, many years ago, I can say from personal experience that banks protect their back-end systems extremely well. There are backups, redundant copies, and most likely even backups of those backups.

Even if we dismiss such scenarios as unlikely or unrealistic, there are people who cannot stop thinking about them, especially in the context of the 2008 financial crisis. Under the pseudonym Satoshi Nakamoto, the first blockchain was introduced in 2008 in the white paper “Bitcoin: A Peer-to-Peer Electronic Cash System.” The goal was to enable the transfer of digital money without needing to trust a central authority such as a bank. To prevent a digital coin from being spent twice, a central authority normally verifies every transaction. The problem is obvious: you must trust that central authority. Blockchain solves this issue by having all participants collectively maintain the transaction ledger, with transactions cryptographically linked together. Instead of trusting a single entity, the system relies on a consensus mechanism.

If you are wondering what this has to do with software licensing, you are asking exactly the right question. In my opinion: nothing at all. One could argue that blockchain could serve as a tamper-proof ledger for purchases, activations, and similar events. It could theoretically enable the resale of licenses. One might also point to smart contracts and decentralized management. However, in practice, there are several reasons why blockchain is not well suited for software licensing.

Control

As a software vendor, you want to maintain control over the licenses you issue. This includes use cases such as license revocation, recall, goodwill gestures, and various support scenarios. Blockchain, however, is immutable, so any change must be recorded as a new transaction.

Offline Systems

Many software applications operate offline, in machines, factories, or isolated networks. Blockchain typically requires network access and a consensus mechanism. This raises the question: what prevents a user from working with an older copy of the blockchain where the license they want to use has not yet been returned?

Performance and Costs

Blockchain transactions are slow and can incur fees. This makes them difficult to scale and technically unnecessary for licensing scenarios.

Identity is Unclear

Blockchain only states: “Wallet A owns license B,” without linking that wallet to a verified organization, user, or device. As a result, you would still need identity management, hardware binding, and a licensing server on top of the blockchain. All things considered, blockchain is poorly suited for software licensing. The main reason is its architecture. Blockchain was designed to be trustless, whereas licensing explicitly requires a central authority. Vendors must be able to create, revoke, modify, stop misuse, and resolve support cases. As a software vendor, you must always be able to say whether a license is valid. Blockchain makes this difficult because it is append-only, immutable, and without central control.

CodeMeter already incorporates concepts closely related to certificates and JSON Web Tokens. However, it goes beyond these approaches in several important ways:

■ Manipulating the device binding requires far more than patching simple conditional jumps; the private key itself is part of the protection mechanism
■ Secret keys are securely transferred and tightly bound to the target container
■ Licenses can be securely returned
■ Licenses can include usage data such as counters and time-based values
■ With CmDongles and CmCloudContainers, two container types are available whose security exceeds that of CmActLicenses.

 

KEYnote 51 – Edition Spring/Summer 2026