Hardware-locked (node-locked) licensing explained

What node-locking is, and what it is not

Node-locking ties a license to devices, not to people or networks. A license for one device can be moved to a new computer, but not used on two at once. It differs from floating licensing, where a pool of seats is shared by whoever is using the program at the moment, and from named-user licensing, where a person signs in.

Velsigil implements node-locking with a device limit per plan or license. It does not offer floating seats.

Where machine IDs come from

Operating systems already keep a per-installation identifier that applications can read without administrator rights. Velsigil’s SDKs use these:

All four SDKs (C#, C++, Python and Node.js) derive the same hardware ID from it:

machineId = platform machine id, trimmed and lowercased
hwid      = lowercase hex SHA-256("vx-hwid-v1:" + machineId)
hwidHash  = SHA-256(hwid)        // what the server stores and shows

Other schemes combine hardware serial numbers instead: disk, network adapter, processor or motherboard. Combining components makes an ID harder to fake, but it also changes when a part is replaced or an adapter is added, which turns hardware upgrades into support requests.

Stable vs unique

A good device identifier stays the same for the life of a device and differs between devices. Real machines do not always cooperate:

• Reinstalling the operating system generates a new machine ID, so the computer counts as a new device.
• Cloned disk images and virtual machine templates can share one machine ID, so several machines may look like one.
• Containers may get a different machine ID on each start.
• Mobile devices and game consoles have no machine ID the SDKs can read.

For these cases, an application can override the hardware ID with any stable value of 8 to 256 printable characters, for example a value it generates once and stores, or Unity’s SystemInfo.deviceUniqueIdentifier on mobile. It must stay the same for the device: a new value is a new device.

Why hardware IDs are not enough

A machine ID is not a secret. Anyone who has a license key and can read the ID of an activated machine can make another computer report the same ID. A hardware ID therefore identifies a device; it does not prove which device is asking.

Velsigil adds a device secret. On the first successful activation, the server issues a random 32-byte secret once and stores only its SHA-256; the SDK saves it on the device and sends it with every later validation, deactivation and download. A copied key with a spoofed hardware ID but without the secret is visible: the server counts a secret mismatch and raises a device_secret_mismatch security event. Copying the secret as well requires access to the original machine’s stored data.

Strict and non-strict binding

With strict device binding off (the default), a device that presents a wrong or missing secret still validates, but it gets no new secret and every request keeps recording mismatches, so it stays flagged until it is reset. This tolerates users who wiped the application’s data.

With strict binding on, a mismatch is a hard block: the server answers device_verification_failed until the seller or the customer resets or removes the device. The next validation then creates a new activation with a new secret.

Device limits, activation limits and cooldowns

The maximum number of devices comes from the plan (1 by default) and can be overridden per license. Hitting the daily activation limit raises a device_churn event, and more than 10 IP addresses per license within an hour raises suspicious_activation. Detectors flag; they never ban a license automatically.

Moving to a new computer

“I got a new PC” is the most common support request in node-locked licensing. Give customers a way to handle it themselves:

• Deactivate first. The application calls deactivate on the old computer, which frees its slot. This works for pending, active and expired licenses; a suspended, revoked or banned license keeps its devices.
• Self-service in the portal. Customers sign in to the customer portal with their license key and remove one device or reset all of them, subject to the reset cooldown. Resets are refused for suspended, revoked or banned licenses.
• Support staff can remove a device, reset all devices, or revoke a single device in the panel.

The reset cooldown keeps self-service from becoming a way to rotate one key across many computers.

Revoking and blacklisting devices

Removing a device frees its slot, and the device can activate again. Revoking a device is stronger: that hardware ID cannot activate on the license again until staff restore it, and the SDK deletes its stored offline lease at the next signed answer (device_revoked). Banning a license can also blacklist every device on it and the customer’s email address for the product. Blacklists cover hardware IDs, IP addresses or ranges and email addresses, globally or per product.

Privacy: only hashes leave the device

The hardware ID an SDK sends is already a hash of the machine ID, and the server stores and shows only a second hash of it. The panel and validation logs never show the raw machine ID, and webhook payloads never contain full hardware IDs or raw license keys, though they may contain the customer’s email address. By default, IP addresses are anonymized after 7 days and validation logs are kept for 30 days; the seller can change both under Settings > Retention.