The Next Generation of Software License Dongles

Built for Your Industry

Licensing fails differently on an offline shop floor, in a recording studio and on a clinical network — so we wrote up how KeyNub fits each industry where a license dongle earns its keep:

CAM & CNC · CAD & BIM Plugins · Industrial Automation · Machine Vision · Measurement & Test · Automotive Diagnostics · Medical Software · Scientific Software · GIS & Geospatial · Audio Plugins · Broadcast & Media · Video Surveillance · Simulation & Training

Designed for Modern Software Protection

Local verification. No license server. No phone-home.
Built by software engineers, for software companies.

Questions We Get Asked

Do I Need to Install a Driver?

No. The dongle is a vendor-defined USB HID device, so Windows, Linux and macOS talk to it with their built-in drivers: no INF file, no kernel module, no vendor service. On Linux, a one-line udev rule makes the device accessible without root.

Does Licensing Work Offline?

Yes. Verification is a local exchange between your application and the dongle: a certificate chain to KeyNub’s root plus a live challenge-response. There is no activation server, no license server and no account, so licensing works on air-gapped machines and on the factory floor, and nothing depends on a server of ours.

Can a Dongle Be Copied or Emulated?

The key pair that identifies a dongle is generated inside its secure element and cannot be read out, so there is nothing to copy onto another device. Every check is a live challenge-response against that key, so a recording of an earlier check does not replay, and the SDK verifies the dongle’s certificate chain to KeyNub’s root before it trusts the answer.

Can a Customer Patch My Application?

A dongle cannot stop somebody who has your executable from editing it. What the SDK is designed for is to make that pointless: you route data your program needs through the dongle’s app-data encryption, so removing the check removes the data. The integration guide walks through the pattern.

Which Languages and Platforms Are Supported?

Bindings and runnable samples for 43 languages, from C, C++, .NET, Python and Java to LabVIEW, MATLAB, Delphi, Rust, Go and Elixir, with packages on NuGet, PyPI, npm, Maven Central, crates.io and many more registries. The native library runs on Windows, Linux and macOS, on x64 and ARM64.

How Much License Data Fits on a Dongle?

1 MB of encrypted storage, organised as named records that your issuing tooling writes and your application reads. Records can be read only through an authenticated session between your application and the dongle.

Who Can Write Licenses to a Dongle?

Only the holder of the dongle’s write key. Each dongle arrives with a factory write key that you replace with your own once, when it arrives; from then on only your key can write, erase or increment. That key belongs in your issuing tooling, never in the application your customers run.

What Happens When a Customer Loses a Dongle?

The license lives on the dongle, so the replacement is a new dongle written with the same records from your issuing tooling. Nothing has to be deactivated anywhere, because nothing was registered anywhere.

Is the SDK Open Source?

The bindings, the samples and the C ABI header are Apache-2.0 on GitHub. The prebuilt native library ships under separate binary license terms. The security architecture is described on this site.

Where Is KeyNub Developed?

In Munich, Germany, by AB-Tools GmbH, which also provides the support. Hardware, firmware, secure-element provisioning and the SDK are developed in house.

How Does KeyNub Compare with CodeMeter or Sentinel HL?

Fact by fact, on two pages sourced from the vendors’ own documentation: KeyNub compared with CodeMeter and KeyNub compared with Sentinel HL. Both cover form factors, drivers and runtime, the security element, storage, SDK licence, languages and server components, and map the concepts for a migration.