Skip to content

Erste Schritte

Sicherheit & das Lease-Modell

Wie Keyright-Lizenzen abgesichert sind: was ein Schlüssel tatsächlich ist, warum eine Einzelplatzlizenz nicht auf zwei Rechnern laufen kann — auch nicht offline —, was „manipulationssicher“ wirklich bedeutet und wie genau der kurzlebige signierte Lease funktioniert — Verlängerung, Offline-Betrieb und warum das Bearbeiten einer Lease-Datei ihn nicht verlängern kann.

Die ehrliche Version davon, wie Keyright Lizenzen sicher hält — was die Kryptografie schützt und was nicht, und wie der Lease funktioniert. Wenn Sie Keyright für ein echtes Produkt evaluieren, lesen Sie diese Seite, bevor Sie ausliefern.

Was wird eigentlich abgesichert — der Schlüssel oder etwas anderes?

Der Lizenzschlüssel (LIC-…) ist nur ein Bezeichner, nicht das Geheimnis. Er trägt keine Entitlements und gewährt für sich genommen nichts. Das, dem Ihre App vertraut, ist das signierte Dokument, das der Service bei der Aktivierung zurückgibt — der Lease (online) oder eine signierte Lizenzdatei (offline). Beide werden mit dem privaten RSA-2048-Schlüssel Ihres Produkts signiert, der ausschließlich auf dem Issuing-Service liegt und im Ruhezustand verschlüsselt gespeichert wird (AES-256-GCM unter einem Key-Encryption-Key; in der Produktion verweigert der Service den Start ohne einen solchen). Ihre App bettet nur den passenden öffentlichen Schlüssel ein und prüft die Signatur (PKCS#1 v1.5 / SHA-256).

Also:

  • Ein geleakter Schlüssel erlaubt jemandem, eine Aktivierung gegen Ihr Platzlimit zu versuchen — mehr nicht. Er kann sich weder ein höheres Tier noch mehr Plätze noch ein späteres Ablaufdatum verschaffen, denn all das steckt in der signierten Nutzlast, die er nicht erzeugen kann.
  • Wird ein Schlüssel missbraucht, widerrufen Sie ihn (Dashboard oder /admin/licenses/{id}/revoke). Widerrufe verbreiten sich online sofort und offline über eine signierte Widerrufsliste, die der Client prüft.
  • Ihre App vertraut nie einem Schlüssel-String, für den sie keine Signatur des Service gesehen hat. Sie verhält sich fail-closed: keine gültige Signatur ⇒ nicht lizenziert.

Warum eine Einzelplatzlizenz nicht auf zwei Rechnern laufen kann — auch nicht offline {#seats}

Zwei unabhängige Kontrollen, und die Offline-Kontrolle ist der wichtige Teil:

  1. Serverseitige Platzdurchsetzung (online). Die Aktivierung zählt unterschiedliche Maschinen gegen die Platzanzahl. Eine neue Maschine jenseits des Limits erhält SeatLimit. Das erneute Aktivieren derselben Maschine ist idempotent, bläht den Zähler also nie auf.
  2. Node-Lock-Bindung (funktioniert ganz ohne Netzwerk). Jeder signierte Lease bzw. jede Offline-Datei ist an einen Maschinen-Fingerabdruck (KRM1:…) gebunden, der aus stabilen Hardware-/OS-Kennungen abgeleitet, gesalzen und gehasht wird. Der Fingerabdruck steckt in der signierten Nutzlast; bei der Validierung berechnet der Client den Fingerabdruck dieser Maschine neu und prüft, ob er übereinstimmt. Kopieren Sie einen Offline-Lease auf eine zweite Maschine, liefert die Validierung MachineMismatch — die Signatur ist in Ordnung, aber es ist nicht diese Maschine.

Deshalb wird Offline nicht zum Schlupfloch: Ein Offline-Lease wird für eine Maschinen-ID ausgestellt (und bestätigt beim Ausstellen weiterhin einen Platz), er lässt sich also nicht teilen. Keyright toleriert die Änderung einer „weichen“ Komponente (z. B. das Umbenennen einer Maschine), damit gewöhnliche Wartung einen legitimen Benutzer nicht aussperrt, während der Hardware-Anker immer übereinstimmen muss.

Wie „unknackbar“ zu verstehen ist

Seien Sie präzise bei den zwei unterschiedlichen Bedrohungen:

  • Fälschung / Manipulation — das ist kryptografisch geschlossen. Niemand kann ohne Ihren privaten Schlüssel eine gültige Lizenz erzeugen, ein Tier anheben, Plätze hinzufügen oder ein Ablaufdatum hinausschieben, und dieser Schlüssel verlässt den Server nie. Ändern Sie ein einziges Feld in einem Lease oder einer Lizenzdatei, und die RSA-Signatur lässt sich nicht mehr verifizieren, also weist der Client sie zurück. In diesem Sinne sind die Dokumente fälschungssicher und manipulationserkennend.
  • Ein entschlossener Angreifer auf einer Maschine, die er vollständig kontrolliert, ist ein anderes Problem, und keine Lizenzierungsbibliothek allein löst es. Wer Ihre kompilierte Binärdatei patchen kann, kann im Prinzip die Prüfung if (!info.IsValid) selbst umgehen — das gilt für jedes Lizenzierungsprodukt, weil die Prüfung auf seiner CPU läuft. Keyright macht die Lizenz fälschungssicher; der Schutz des Durchsetzungscodes ist eine separate Schicht. Kombinieren Sie Keyright mit Nebula.NET (Obfuskation, Anti-Tamper, Methodenverschlüsselung), wenn das eine Rolle spielt. Wir sagen Ihnen das lieber, als so zu tun, als hielte eine Signatur einen Debugger auf.

Weitere häufige Fragen zu Sicherheit, Stabilität & Skalierung

  • Stabilität / Offline-Resilienz. Die Validierung ist lokal und zustandslos — nach der Aktivierung hängt Ihre App nicht davon ab, dass der Service erreichbar ist, um weiterzuarbeiten (das ist der ganze Sinn des Lease). Ein Ausfall des Service lässt aktivierte Kunden innerhalb ihrer Kulanzfrist nicht im Stich.
  • Skalierbarkeit. Der Issuing-Service ist pro Anfrage zustandslos und horizontal skalierbar; der heiße Pfad (/v1/activate, /v1/validate) ist eine Signaturoperation plus eine Platzprüfung. Da Clients zwischen Aktivierungen offline validieren, fällt nicht pro App-Start eine Anfrage an.
  • Mandantenisolation. Jeder Mandant hat seinen eigenen Signaturschlüssel, und die Daten sind pro Mandant isoliert, sodass der Schlüssel oder die Lizenzen eines Anbieters nie die eines anderen verifizieren oder berühren können.
  • Missbrauchsresistenz. Client-Endpunkte sind ratenbegrenzt; Admin-Endpunkte erfordern ein Token und sind rollenbasiert beschränkt (Read < Write < Manage < Own), mit Audit-Trail.
  • Uhrmanipulation. Testversionen und Ablaufdaten werden gegen einen persistierten First-seen-Zeitstempel geprüft; das Zurückstellen der Systemuhr wird erkannt (ClockTampered) statt belohnt.

Der Lease, erklärt

Warum überhaupt einen Lease ausstellen?

Ein Lease ist ein kurzlebiges, signiertes Kulanz-Token (Standard 14 Tage), das der Service bei der Aktivierung zurückgibt. Er ist der Ausgleich zwischen zwei schlechten Extremen: bei jedem Start nach Hause telefonieren (fragil, datenschutzunfreundlich, bricht, wenn Ihr Service kurz hakt) gegenüber einer Maschine nach einer einzigen Aktivierung für immer vertrauen (unkontrollierbar). Der Lease lässt eine aktivierte Maschine für die Kulanzfrist offline laufen und prüft dann erneut.

Muss das Produkt zu Keyright zurückkehren, um den Lease zu verlängern?

Ja — aber unsichtbar und nur gelegentlich. Das empfohlene Muster ist, ActivateAsync beim Start aufzurufen: Ist die Maschine online, aktualisiert es stillschweigend den 14-Tage-Lease (idempotent, kein zusätzlicher Platz); ist sie offline, validiert das SDK weiter gegen den zwischengespeicherten Lease. Eine normalerweise verbundene Maschine verlängert also, ohne dass es jemand bemerkt, und die 14 Tage sind schlicht die Zeit, die sie vollständig offline bleiben kann, bevor sie den Service einmal erreichen muss. Sie können dieses Fenster erweitern oder verengen (KEYRIGHT_LEASE_TTL_DAYS), um Offline-Toleranz gegen die Geschwindigkeit abzuwägen, mit der ein Widerruf oder eine Platzänderung wirksam wird.

Was passiert, wenn eine Maschine nach der Aktivierung offline geht?

Sie arbeitet weiter, bis das leaseExpiresUtc des Lease überschritten ist — die Kulanzfrist. Verbinden Sie sich jederzeit vorher erneut, und der Lease wird um ein weiteres Fenster verlängert. Verstreicht das Fenster ohne Kontakt, liefert Validate() Expired („zur erneuten Validierung wieder verbinden“), und Ihre App verhält sich fail-closed. Für Maschinen, die lange oder dauerhaft offline sein werden, verlassen Sie sich nicht auf den 14-Tage-Lease — stellen Sie einen Offline-Lease mit langer TTL aus (Standard 365 Tage) oder liefern Sie eine eigenständige Offline-Lizenzdatei aus. Siehe Aktivierung & Deaktivierung.

Kann ein Benutzer die Lease-Datei einfach bearbeiten, um sie unbegrenzt zu verlängern?

Nein. Das Ablaufdatum (leaseExpiresUtc) ist Teil der signierten Nutzlast, keine separate Einstellung. Ändern Sie es — oder das Tier, die Plätze, die Maschinenbindung, irgendetwas —, und die RSA-Signatur passt nicht mehr, also weist der Client den Lease als SignatureInvalid zurück und fällt auf unlizenziert zurück. Es gibt kein Feld, das ein Benutzer umschalten könnte. Die Uhr zurückzustellen, um in einem alten Fenster zu bleiben, hilft ebenfalls nicht: Genau das fängt die Uhrmanipulationserkennung ab. Der einzige Weg zu einem längeren Lease ist, dass Sie einen ausstellen.

Wie funktioniert die Offline-Aktivierung, in einem Absatz?

Die Offline-Maschine gibt ihren Fingerabdruck aus; Sie (mit Konnektivität und einem Admin-Token) stellen einen an diesen Fingerabdruck gebundenen Lease mit der TTL Ihrer Wahl aus; die Maschine importiert ihn und validiert lokal, dauerhaft bis zur TTL, ohne Netzwerk. Es ist derselbe Mechanismus des signierten Lease wie bei der Online-Aktivierung — nur von Hand statt über HTTP zugestellt und an genau eine Maschine gebunden, sodass er nicht geteilt werden kann. Schritt für Schritt: Offline-/Air-Gapped-Aktivierung.