KeyNub protects software licenses with hardware cryptography, not with obscurity. This page describes how the dongle is built, what it guarantees, and — just as importantly — what no license dongle can do. Nothing here is confidential: the protection is the key inside the secure element, not secrecy about how to talk to it.
The guarantee, stated precisely
Every mechanism below serves one guarantee: a genuine KeyNub dongle, with this serial number, is attached to this machine right now, and the data your software just received came from it. That is a strong statement, and it is deliberately narrower than “this software is licensed”. The difference is where your integration does its work, and it is covered further down this page.
Keys that cannot be copied
Each dongle contains a hardware secure element that generates its own ECC NIST P-256 key pair internally. The private key is never exported and there is no command that reads it — not for you, not for us, and not for an attacker holding the device. Copying a dongle would mean extracting a key that never leaves the chip that made it.
Every check is a live challenge-response
The dongle carries an X.509 device certificate issued by the KeyNub root CA. The root’s public certificate is compiled into the released SDK, so verification works out of the box and there is no trust root for your application to supply, manage or ship. The certificate also carries the dongle’s serial number and batch, so your software can confirm that a genuine dongle is one of yours. To prove it holds the matching private key, the dongle signs a fresh 32-byte challenge that your software generates. Nothing is compared against a stored value, so a recorded exchange cannot be replayed later.
Encrypted on the wire, at rest, and on the internal bus
Once the device is verified, your software opens an encrypted session: P-256 ECDH to agree keys, HKDF-SHA256 to derive them, and AES-256-GCM on every message, key-confirmed and replay-protected. The 1 MB of license storage is encrypted under a key derived inside the secure element, so reading the flash memory directly yields ciphertext. So does probing the internal bus between the microcontroller and the secure element, which is itself encrypted with an I/O protection key.
The code an attacker can reach is isolated in hardware
Everything your software sends arrives as USB traffic that has to be reassembled and parsed. A USB stack and a parser are the largest and most defect-prone code in any device, and on the KeyNub they are also the only part an attacker can reach at all. So that is the code that is fenced off from everything that matters.
It runs in a separate world of the Arm Cortex-M33 processor, established by Arm TrustZone: unprivileged, with its memory non-executable and its own code read-only. That world is granted its own RAM, the USB controller and a timer. Every other address and every other peripheral is denied in hardware — the secure element’s bus, the license storage, the flash memory, the firmware-update path and the one-time-programmable memory included. Anything it needs from the protected side it has to request through a small, fixed set of gateway calls, which validate every pointer they are handed.
The practical effect is that a memory-safety defect in the code that parses your traffic cannot be escalated into key extraction. It would yield control of a world that can talk to USB and cannot read a key.
You do not have to take our word for it. The dongle reports this over the protocol, and the SDK surfaces it on every binding, so your own code can ask. The firmware does not derive the answer from how it was built — at boot it asks the hardware how an access from the isolated world would be attributed, for the keys, the storage and its own memory, and reports what the hardware said. A build whose containment is not what it claims does not set it.
Counters that cannot be rolled back
Two monotonic counters are implemented in secure-element hardware and can only ever be incremented. Restoring a disk image or reverting a virtual-machine snapshot does not reset them, which is what makes them dependable for activation counts and trial consumption.
What a license dongle cannot do
We would rather state this plainly than have you discover it later. A dongle cannot stop somebody patching your executable, and it cannot stop them replacing our library with a fake one that always answers “yes”. Both attacks happen on the customer’s own machine, inside your own process, where no hardware has any reach. Any vendor claiming otherwise is selling you something that does not exist.
This is why we recommend one integration pattern above all others: put dongle-derived data on your critical path. Have the dongle unwrap the key to configuration, model data, calibration tables, rules or content that your software genuinely cannot run without. A fake library can return “licensed” easily enough — what it cannot do is produce data it does not have.
Our integration security guide covers this in full, including the anti-pattern to avoid and a table of what each attack actually achieves.
Check it for yourself
The bindings, the samples and the C ABI header are published under Apache-2.0 at github.com/AB-KeyNub/KeyNub-SDK, so you can read exactly what the library does before you buy anything. The prebuilt native libraries ship under separate binary license terms.
The full specifications, including the security architecture summarised above, are in the KeyNub datasheet (PDF).
