Lizenz-Schluessel & Token-Version

Aufbau eines Lizenz-Tokens

Jede Aktivierung erzeugt ein RS256-signiertes JWT (Phase 1+) mit folgenden Claims:

• iss: sellx-central
• aud: sellx-hub
• sub: license_id (UUID)
• subscription_type: perpetual | subscription | trial | all_inclusive
• token_version: monoton steigende Ganzzahl, Standard 1
• hardware_fingerprint: sha256(machine_guid || sql_instance || install_path)
• exp: bei perpetual = +10 Jahre, bei subscription = Subscription-Ende

Zusatz-Payload (nicht im JWT, sondern separat in Central persistiert): Master-Key-Seed (HKDF-Secret), DPAPI-encrypted mit dem Hardware-Fingerprint als Entropy. Daraus leitet der Hub pro Plugin den AES-256-Key fuer die Query-Entschluesselung ab.

Token-Version & sofortige Revocation

Im Gegensatz zu exp (Ablaufdatum) ist token_version ein sofort wirksamer Revocation-Mechanismus:

• Ops setzt im Admin-Portal token_version einer License inkrementell hoch.
• Naechster Heartbeat des Hubs liefert das alte JWT; Central antwortet 403 LICENSE_REVOKED (JWT-Version < Central-Version).
• Hub triggert automatische Re-Activation mit neuem RSA-Token. Hardware-Binding bleibt erhalten (gleicher Fingerprint).
• AuditLog-Eintrag license.token_version_incremented mit altem/neuem Wert und Operator.

AES-Key-Derivation (HKDF-SHA256)

Der Master-Key-Seed wird pro Plugin zu einem eigenen AES-256-Key abgeleitet. Drei Inputs:

IKM (Input Key Material)  = Master-Key-Seed (DPAPI-entschluesselt, 32 Byte)
Salt                        = Hardware-Fingerprint (SHA-256, 32 Byte)
Info / Context              = plugin_id (UTF-8-String)
HKDF-Extract + HKDF-Expand  = 32 Byte Output (AES-256-GCM-Key)

Pilotkunde #1: HMAC-zu-RSA-Migration

Pilotkunde #1 hat in Stage 0 einen HMAC-Mock-Token erhalten (Vor-Central-Deployment). Beim ersten Heartbeat nach Stage-1-Start erkennt Central dies automatisch und signalisiert dem Hub einen Migrations-Pfad — ohne Kunden-Aktion.