Lab 01 — Hardware Fingerprinting + Ed25519 Offline License System

Phase: 11 — Security & Licensing | Difficulty: ⭐⭐⭐⭐⭐ | Time: 6–8 hours Language: Python (embedded pure Ed25519 — zero deps) | Hardware: none

Concept primer: ../WARMUP.md Ch. 2–5. Defensive/licensing scope; every technique is taught with its defeat condition.

Run

python solution.py        # keygen, fingerprint, issue, verify offline, attack tests

(Self-contained: a pure-Python Ed25519 is embedded so it runs offline with no pip install — exactly the air-gapped constraint this phase is about.)

0. The mission

Build the offline-licensing core sovereign customers require (WARMUP Ch. 4):

  • Hardware fingerprint — a stable machine ID from multiple hardware attributes, with fuzzy matching so legitimate changes (a swapped NIC) don't lock the customer out (WARMUP Ch. 3).
  • Ed25519-signed license — binds customer/features/expiry/fingerprint; signed not encrypted (WARMUP Ch. 2, 4).
  • Offline verification — with the embedded public key, no network, plus a grace period and clock-rollback resistance.

1. What the output shows

== keys & fingerprint ==
issued license for 'Acme Defence' bound to fingerprint 7f3a...c91 (8 GPUs, expires 2027-01-01)

== happy path ==
verify on the licensed machine: VALID (features ok, fingerprint matches, not expired)

== attack / robustness tests ==
tampered license (1 byte flipped)        : REJECTED (signature invalid)
license presented on a different machine : REJECTED (fingerprint mismatch)
one hardware component swapped (NIC)     : VALID   (fuzzy match: 4/5 still agree)
three components changed                 : REJECTED (fuzzy match: 2/5 — different machine)
clock rolled back before high-water-mark : REJECTED (rollback detected)
expired but within grace period          : VALID   (grace honored)
expired beyond grace                     : REJECTED (expired)
requesting more GPUs than licensed       : REJECTED (feature/quota)

defeat condition (stated honestly): an attacker with root + the binary can patch
out the verifier call site. Licensing = economic+legal deterrent; attestation
(Phase 11 Lab 02 / WARMUP Ch. 8) is the hardware-rooted strong answer.

Every row is a test; each teaches a mechanism and its limit.

2. Reading order (solution.py)

  1. The embedded Ed25519 (_ed25519 section) — you don't need to grok the curve math; know it gives sign(priv,msg) / verify(pub,msg,sig) (WARMUP Ch. 2).
  2. hardware_fingerprint + fuzzy_match — multi-attribute ID and N-of-M matching (WARMUP Ch. 3).
  3. issue_license (private key) and verify_license (public key, offline) — the sign/verify flow + grace + rollback check (WARMUP Ch. 4).
  4. The attack tests — and the defeat-condition note.

3. Extensions

  1. Air-gap challenge-response activation (WARMUP Ch. 5): the box emits fingerprint+nonce; an "activation service" returns a signed response bound to them; the box verifies offline. Add replay protection via the nonce.
  2. Revocation: a signed revocation list for connected deployments; discuss why it's hard air-gapped (hence short terms + re-activation).
  3. Feature gating: enforce per-feature entitlements and a max-GPU quota at "runtime" (simulate a platform asking "may I use FP8 on 6 GPUs?").
  4. Key rotation: support multiple public keys (key IDs) so you can rotate the signing key without invalidating all licenses at once.

4. Common pitfalls

  1. Encrypting instead of signing — a license needs integrity+authenticity, not secrecy; signing with a public verifier is correct (WARMUP Ch. 2).
  2. Brittle single-hash fingerprint — one hardware change locks the customer out; fuzzy N-of-M is the engineered answer (WARMUP Ch. 3).
  3. Trusting the system clock — rollback gives free perpetual licenses without a monotonic high-water-mark (WARMUP Ch. 4).
  4. Claiming it's uncrackable — always state the defeat condition; the value is raised cost + legal evidence, with attestation as the strong tier.

5. What this lab proves about you

You can build the licensing core that turns a hardware-agnostic platform (Phase 09) into a sovereign-deployable product — signed, offline, hardware-bound, robust to legitimate change and basic attack — and you threat-model it honestly, which is what makes a security claim credible in front of a regulated customer.