Security & Threat Model

We publish the threat model.

Most licensing products describe defenses without naming the attacks they actually defend against. RockyGuard maps every concrete attack we know of to its specific defense and the residual risk that remains. The table below is the same one published in Customer_Documentation Sec 9.6 — verbatim. No marketing version, no soft version.

Design principles

Public key only on the customer side

Your application embeds the public key. The signing private key never leaves your build infrastructure. There is no shared secret a customer or attacker could leak.

Fail closed

Every uncertain state returns a documented LicenseStatus. Empty fingerprints, missing anchors, missing .sig file, malformed JSON, expired clock — every case has a defined fail-closed path. The library does not silently grant access on unexpected inputs.

Documented residual risk

The table below names every concrete attack we know of, the defense, and what the attacker can still attempt. We do not claim defenses we do not have. The "memory dumping is out of scope" row is a feature, not an oversight.

No phone-home except for time

The library makes one kind of outbound network call: anonymous HTTPS to a rotating pool of public hosts (google.com, microsoft.com, cloudflare.com, and others) to verify the wall clock. No telemetry. No license-check beacons. No customer data leaves the customer's machine.

Threat model

Nine attacks. For each, the specific defense in the library and what an attacker can still attempt after the defense is applied. The "Mitigation" column tells you what your application or operations team should add on top of RockyGuard to close the residual gap.

Threat 1

License file tampering

Attack

Editing dates, machine fingerprint, features, or feature flags inside the JSON payload after it has been signed.

Defense

Ed25519 / RSA-SHA256 signature over the payload, verified at LicenseVerifier::load() against the public key embedded in your application.

Residual risk & mitigation

None for the file itself: any byte change invalidates the signature and load() returns SignatureInvalid. Residual: an attacker who steals your signing private key can sign anything; mitigation = keep private.pem on a secure machine and rotate keys per the versioning policy if compromise is suspected.

Threat 2

Keygen / counterfeit license generator

Attack

Building a tool that produces fake licenses your verifier accepts.

Defense

Ed25519 / RSA private key required to sign a valid payload; public-key-only verifier on the customer side.

Residual risk & mitigation

None: the verifier cannot produce a valid signature without the private key. Same private-key custody mitigation as above.

Threat 3

Patching or cracking the shipped binary

Attack

NOP-out the license check; redirect verification to always return Valid; replace the public key with the attacker's.

Defense

Binary integrity self-check on shared-library builds: rockyguard.sig is verified at load against the binary's SHA-256.

Residual risk & mitigation

Residual: an attacker who modifies BOTH the binary AND the .sig in coordinated fashion bypasses the integrity check. Mitigation: ship the application's own integrity check (code signing, executable signature) so the OS / loader detects pre-launch modification before RockyGuard gets a chance to run. Static-library builds embed the library code directly into your executable, raising the bar further.

Threat 4

Clock rollback

Attack

Set the system clock back to before the license expiry date so the license is treated as still valid.

Defense

Multi-location time anchors (file + Windows registry where applicable) cross-checked against current clock; HTTPS time-anchor pool consulted on first run and 10% of subsequent runs.

Residual risk & mitigation

Residual: a determined attacker on a fully air-gapped machine who deletes ALL anchor locations AND rolls the clock back gets one false-pass at first run (documented in API Reference Sec 6.6). Mitigation: ship to non-air-gapped customers when possible; for air-gapped fleets, issue shorter-duration licenses so re-issuance forces clock truth on a regular cadence.

Threat 5

MITM on the floating-server connection

Attack

Intercept and forge checkout / heartbeat / checkin responses between the floating client and floating server.

Defense

Optional TLS encryption (use_tls + tls_ca_cert_path); REQUIRED Ed25519 payload signature on every server response (server_public_key_pem).

Residual risk & mitigation

Residual without TLS: passive sniffer can capture the session secret issued at checkout and forge subsequent HMAC-authenticated requests. Mitigation: enable TLS in production deployments; pin the server cert via tls_ca_cert_path. With TLS + server_public_key_pem set, the residual is essentially zero.

Threat 6

Server spoofing

Attack

Stand up a rogue floating server that pretends to be the real one and grants seats to clients pointed at it.

Defense

Client verifies every server response against server_public_key_pem.

Residual risk & mitigation

Residual: if server_public_key_pem is left empty (Development-only configuration), the client trusts any server. Mitigation: never ship Development-only configuration to end users; embed the production server's public key in the client at build time.

Threat 7

Eviction / heartbeat forgery

Attack

A peer who learns another client's client_id evicts that client from a floating-license seat or forges heartbeats on its behalf.

Defense

Per-checkout session secret issued by the server; HMAC-authenticated heartbeat / checkin requests bound to that secret.

Residual risk & mitigation

Residual without TLS: session secret travels in cleartext during the checkout response and a sniffer can capture it. Mitigation: enable TLS; the captured-secret window closes.

Threat 8

Hardware fingerprint forgery

Attack

Run a license bound to one machine on another machine that mimics the original's MAC address, CPU id, disk serial, and motherboard serial.

Defense

Four independent component hashes; configurable threshold (default: 2 of 4 must match).

Residual risk & mitigation

Residual: a sufficiently determined attacker can spoof MAC and CPU id; spoofing all four including motherboard serial is much harder. Mitigation: keep the default threshold of 2 unless customer hardware constraints force you to lower it; consider raising threshold to 3 for high-value licenses.

Threat 9

Memory dumping / runtime extraction

Attack

Attach a debugger or kernel module to the running host process and read the parsed License struct directly out of memory.

Defense

Out of scope: a library cannot defend against attackers with kernel-level access to the host process.

Residual risk & mitigation

None: the License struct lives in process memory after load() succeeds. Mitigation: this is an operating-system / hosting-environment problem, not a library problem. RockyGuard accepts this; if your threat model includes attackers with kernel-level access, license enforcement at the application layer is the wrong defense.

What RockyGuard does not do

We are deliberately scoped. Some things licensing products are sometimes asked to do, that we do not:

×DRM / content protection. RockyGuard enforces license validity, not media access controls.
×Anti-debug / anti-disassembly. A determined reverse-engineer with kernel access can defeat any user-space measure. We do not pretend otherwise.
×Telemetry or activity reporting. The library does not phone home. Customer-side analytics is your job, not ours.
×Cloud-managed licensing. Verification is offline; the floating server is a LAN deployment you run in your customer\'s environment.

If your threat model requires defenses outside that scope, RockyGuard is not the right fit. We would rather tell you that on the security page than discover it three months into a deployment.

Read the source documentation

The full security treatment, including per-mechanism implementation detail, is in Customer_Documentation.txt Section 9.

Browse docs Talk to us