Signaturschlüssel für Lizenzen rotieren, ohne Kunden auszusperren

Ein Lizenzschlüssel ist eine Aussage — „dieser Kunde besitzt die Pro-Edition, 3 Plätze, bis nächsten März” — und Ihre App glaubt diese Aussage aus genau einem Grund: Sie wurde von einem Schlüssel signiert, dem Ihre App vertraut. Dieser Signaturschlüssel ist die Wurzel des gesamten Systems. Alles Nachgelagerte — die Editionen, die Platzgrenzen, der Ablauf, die Leases, die eine aktivierte Maschine offline laufen lassen — erbt sein Vertrauen von diesem einen Schlüssel. Das ist auch der Grund, warum das Rotieren beängstigend wirkt: Ändern Sie die Wurzel, riskieren Sie, jede Lizenz zu entwerten, die Sie je ausgestellt haben.

Das müssen Sie nicht. Dieser Beitrag zeigt, wie Sie einen Keyright-Signaturschlüssel ohne für den Kunden sichtbare Ausfallzeit rotieren: was der Schlüssel tatsächlich schützt, warum ein naiver Tausch alle aussperrt, wie überlappendes Vertrauen den Übergang nahtlos macht, und wie Leases und Offline-Dateien entscheiden, wie lange die Überlappung dauern muss.

Was der Signaturschlüssel tatsächlich schützt

Keyright ist offline-first. Wenn Sie eine Lizenz ausstellen, signiert der Dienst eine kanonische Nutzdaten-Aussage mit dem privaten Signaturschlüssel Ihres Produkts und gibt eine kopierbare Schlüsselzeichenkette zurück. Ihre App bettet nur den passenden öffentlichen Schlüssel ein. Zur Validierungszeit prüft die App die Signatur lokal — ohne Netzwerk — und vertraut erst dann der Stufe, dem Ablauf und der darin enthaltenen Platzzahl. Die Aktivierung fügt ein zweites signiertes Artefakt hinzu: ein kurzlebiges, an die Maschine gebundenes Lease (standardmäßig 14 Tage), ebenfalls von diesem Schlüssel signiert, das eine aktivierte Maschine offline weiterlaufen lässt, bis das Kulanzfenster des Lease abläuft.

Der Schlüssel leistet also viel tragende Arbeit, und er ist in Software eingebettet, die Sie bereits ausgeliefert haben. Das ist genau die Eigenschaft, die Sie aus Sicherheitsgründen wollen — die Vertrauenswurzel sitzt im Client, nicht auf einem Server, den ein Angreifer per Social Engineering austricksen könnte — und genau die Eigenschaft, die Rotation zu einem Entwurfsproblem statt zu einem Knopfdruck macht.

Warum der naive Tausch ein Desaster ist

Stellen Sie sich vor, Sie vermuten einen Leak des privaten Schlüssels. Der naheliegende Zug: ein neues Schlüsselpaar erzeugen, neue Lizenzen damit neu signieren, einen App-Build verteilen, der den neuen öffentlichen Schlüssel einbettet. Fertig?

Nein. In dem Moment, in dem dieser Build einen Kunden erreicht, scheitern jede vom alten Schlüssel signierte Lizenz und jedes Lease an der Prüfung auf seiner Maschine. Die Signatur passt nicht mehr zum eingebetteten Schlüssel, also fällt ein zahlender Kunde, der letzte Woche aktiviert hat, beim nächsten Start auf die kostenlose Edition zurück. Sie haben eine vorsorgliche Rotation in einen feldweiten Ausfall verwandelt.

Das Scheitern ist strukturell: Die App vertraut genau einem Schlüssel, und Sie haben ihn unter noch gültigen Artefakten weggetauscht. Die Lösung ist, eine Zeit lang zwei Schlüsseln zu vertrauen.

Überlappendes Vertrauen: die eine Idee, die es sicher macht

Jedes Keyright-SDK prüft eine eingehende Lizenz oder ein Lease gegen einen primären öffentlichen Schlüssel und gegen eine Liste zusätzlicher öffentlicher Schlüssel. Wenn irgendein vertrauenswürdiger Schlüssel die Signatur verifiziert, wird das Artefakt akzeptiert. Das verwandelt eine harte Umstellung in ein Überlappungsfenster.

Hier ist das .NET-SDK im Normalbetrieb — ein Schlüssel:

var keyright = new KeyrightClient(new KeyrightOptions
{
    Product = "my-app",
    ServiceUrl = "https://license.example.com",
    PublicKeyBase64 = "<current public key>",
});

Und hier ist es mitten in der Rotation. Der neue Schlüssel ist primär; der ausscheidende Schlüssel fährt in AdditionalPublicKeysBase64 mit:

var keyright = new KeyrightClient(new KeyrightOptions
{
    Product = "my-app",
    ServiceUrl = "https://license.example.com",
    PublicKeyBase64 = "<NEW public key>",
    // Keep the old key valid through the rotation window:
    AdditionalPublicKeysBase64 = new[] { "<previous public key>" },
});

Eine vom alten Schlüssel signierte Lizenz verifiziert weiterhin (sie passt zu einem zusätzlichen Schlüssel). Eine vom neuen Schlüssel signierte Lizenz oder ein Lease verifiziert ebenfalls (sie passt zur primären). Niemand verliert eine Stufe. Die beiden Schlüssel koexistieren genau so lange, wie vom alten signierte Artefakte noch im Umlauf sind — und dann entfernen Sie ihn.

Die Rotation, Schritt für Schritt

1. Rotieren Sie den Schlüssel im Dienst. Jedes Produkt besitzt seinen eigenen Signaturschlüssel. Ein authentifizierter Aufruf rotiert ihn; der alte Schlüssel wird als vorheriger Schlüssel aufbewahrt, sodass Sie noch sehen können, was er signiert hat, und die Antwort reicht Ihnen den neuen einzubettenden öffentlichen Schlüssel:

curl -X POST "$BASE/admin/products/my-app/signing-key" \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"rotate": true}'
# → { "signingPublicKey": "<NEW public key>", ... }

(Dasselbe liegt im Dashboard unter dem Reiter Signing key des Produkts — Rotation, Import und die Liste vorheriger Schlüssel stehen in dessen Advanced-Bereich.) Danach verwenden neu ausgestellte Lizenzen und neu signierte Leases den neuen Schlüssel. Bereits ausgestellte Lizenzen bleiben unverändert: Ihre Signaturen wurden zum Ausstellungszeitpunkt erstellt und ändern sich nicht rückwirkend.

2. Verteilen Sie einen Build, der beiden Schlüsseln vertraut. Fügen Sie den neuen Schlüssel als PublicKeyBase64 und den ausscheidenden zu AdditionalPublicKeysBase64 hinzu, wie oben. Veröffentlichen Sie ihn über Ihren üblichen Kanal. Von da an akzeptieren Clients Artefakte, die von einem der beiden Schlüssel signiert wurden.

3. Lassen Sie die Leases den neuen Schlüssel ins Feld tragen. Sie müssen niemandem hinterherlaufen. Da eine aktivierte Maschine ihr Lease bei Annäherung an den Ablauf erneuert, holt sich jeder Online-Kunde ganz natürlich innerhalb eines Kulanzfensters ein neues Lease unter dem neuen Schlüssel — standardmäßig 14 Tage. Nach ein paar Fenstern ist im Wesentlichen jedes aktive Lease im Feld mit dem neuen Schlüssel signiert.

4. Entfernen Sie den alten Schlüssel. Sobald kein vom alten Schlüssel signiertes Artefakt mehr aktiv sein kann — jedes von ihm signierte Lease ist abgelaufen, und keine eigenständige, von ihm signierte Offline-Datei ist noch im Einsatz — verteilen Sie einen Build, der ihn aus AdditionalPublicKeysBase64 entfernt. Jetzt wird nur noch dem neuen Schlüssel vertraut. Die Rotation ist abgeschlossen, und falls der alte private Schlüssel geleakt war, ist alles, was er signiert hat, für einen Angreifer nun wertlos.

Was die Länge der Überlappung festlegt

Die Überlappung kann nicht kürzer sein als das langlebigste Artefakt, das der alte Schlüssel signiert hat. Drei Fälle:

• Online aktivierte Maschinen bewegen sich im Takt Ihrer Lease-TTL (standardmäßig 14 Tage). Ein Kulanzfenster nachdem der Dienst die Schlüssel gewechselt hat, hat sich im Wesentlichen jeder neu geleast.
• Lange offline betriebene Maschinen, denen ein Offline-Lease mit langer TTL (standardmäßig 365 Tage) ausgestellt wurde, bleiben beim alten Schlüssel, bis dieses Lease abläuft. Wenn Sie solche haben, beträgt Ihre Überlappung ein Jahr, nicht zwei Wochen: planen Sie dafür.
• Eigenständige Offline-Lizenzdateien erneuern sich überhaupt nicht; sie bewegen sich im Takt Ihrer Releases. Ein Kunde auf einer abgeschotteten Installation hält den alten Schlüssel vertrauenswürdig, bis er einen vom neuen Schlüssel signierten Build übernimmt. Behalten Sie den alten Schlüssel in der Liste, bis Sie bestätigt haben, dass diese Kunden migriert sind.

Die Faustregel: Behalten Sie den alten öffentlichen Schlüssel in AdditionalPublicKeysBase64, bis das letzte von ihm signierte Artefakt abgelaufen oder ersetzt ist, und entfernen Sie ihn dann im nächsten Release. Es gibt keine Strafe dafür, ihn etwas länger zu belassen, und eine echte dafür, ihn zu früh zu ziehen.

Wenn der private Schlüssel wirklich geleakt ist

Rotation richtet das künftige Vertrauen neu aus, aber ein geleakter privater Schlüssel bedeutet, dass ein Angreifer Lizenzen fälschen kann, denen Ihre aktuell ausgelieferte App noch vertraut — bis sie einen Build übernimmt, der dem alten Schlüssel nicht mehr vertraut. Kombinieren Sie Rotation daher mit Widerruf. Keyright kann eine signierte Widerrufsliste veröffentlichen, und die Online-Aktivierung erlaubt es Ihnen, bestimmte geleakte Schlüssel zu töten, sodass eine aktivierte-aber-widerrufene Maschine bei ihrer nächsten Lease-Erneuerung auf die kostenlose Edition zurückfällt. Für eine bestätigte Kompromittierung lautet die ehrliche Abfolge: rotieren, den Doppelschlüssel-Build schnell verteilen, die bekannten schlechten ausgestellten Schlüssel widerrufen und die Überlappung so aggressiv verkürzen, wie es Ihre Offline-Kunden zulassen.

Und denken Sie an die Grenze, die für jede clientseitige Lizenzierung gilt: Die Prüfung läuft auf der Maschine des Nutzers, also kann ein entschlossener Angreifer mit einem Decompiler versuchen, die Prüfung ganz herauszupatchen. Genau deshalb ist Keyright formatkompatibel mit Nebula.NET — Sie obfuskieren und härten das Assembly, das den öffentlichen Schlüssel einbettet und die Prüfung durchführt, sodass es echten Aufwand kostet, sie herauszupatchen. Der Signaturschlüssel ist die kryptografische Wurzel; die Obfuskierung schützt den Code, der sie durchsetzt.

Die Umsetzung

Signaturschlüssel-Rotation in Keyright ist eine serverseitige Operation mit einem einzigen Aufruf plus eine clientseitige Änderung von einer Zeile, sicher gemacht durch überlappendes Vertrauen und getaktet durch die Lebensdauer Ihrer Leases. Erzeugen oder rotieren Sie einen Schlüssel über den Reiter Signing key des Produkts (oder den signing-key-Endpunkt), betten Sie den neuen als PublicKeyBase64 ein, behalten Sie den ausscheidenden in AdditionalPublicKeysBase64 für ein Lease-Fenster — länger, wenn Sie Offline-Dateien ausliefern — und entfernen Sie ihn dann. Siehe den Integrationsleitfaden für das .NET-SDK für die genauen Optionen und die Seite Sicherheit & Leases dafür, wie Leases Ihre Überlappung bestimmen, oder die Keyright-Produktseite für das Gesamtbild. Der kostenlose Plan reicht, um eine vollständige Rotation von Anfang bis Ende zu proben, bevor Sie sich darauf verlassen.