Lizenzwiderruf: einen Schlüssel stoppen, online und offline

Jedes Lizenz-Tutorial lehrt die Ausstellung: einen Schlüssel erzeugen, signieren, übergeben. Weit weniger lehren die andere Hälfte, wo die eigentliche Ingenieurskunst steckt: einen Schlüssel zum Aufhören zu bringen. Ein Kunde erstattet zurück. Ein Schlüssel taucht in einem Forum auf. Eine Rückbuchung trifft ein. Ein Mitarbeiter mit dem Firmenschlüssel geht. In jedem Fall brauchen Sie, dass ein bereits existierender Schlüssel auf der Maschine eines anderen aufhört, Ihre Software zu gewähren. Das ist Widerruf, und er verhält sich online und offline sehr unterschiedlich.

Was Widerruf ist — und was nicht

Eine Lizenz zu widerrufen ist eine signierte negative Aussage: Der Anbieter erklärt Schlüssel K für nicht mehr gültig. Er greift nicht nach etwas auf der Festplatte des Kunden und löscht es; er ändert, was Ihre App schlussfolgert, wenn sie diesen Schlüssel das nächste Mal auswertet. Das ganze Problem reduziert sich also auf eine Frage: Wann wertet die App erneut aus, und erfährt sie rechtzeitig vom Widerruf?

Diese Rahmung ist wichtig, weil sie die ehrliche Erwartung setzt. Widerruf ist nie überall augenblicklich. Was Sie steuern, ist das Fenster zwischen dem Widerruf und dem Totsein des Schlüssels auf einer bestimmten Maschine. Ihre Aufgabe ist, dieses Fenster klein genug für das Risiko zu machen — und nie vorzugeben, es sei null.

Online-Widerruf: beim nächsten Check-in in Sperre fallen

Der häufige Fall ist eine verbundene App. Sie markieren den Schlüssel serverseitig als widerrufen, und das nächste Mal, wenn der Client mit dem Dienst spricht — eine Neuvalidierung, eine Reaktivierung, ein Heartbeat — antwortet der Dienst „widerrufen” und der Client fällt in den unlizenzierten Zustand.

var info = await client.ValidateOnlineAsync(key);
if (info.Status == LicenseStatus.Revoked)
{
    _cache.Clear();          // drop any cached lease so offline validate can't resurrect it
    EnterUnlicensedMode();   // fail closed — never throw and leave features on
}

Das Expositionsfenster ist hier Ihr Recheck-Intervall. Eine an die Maschine gebundene Lease wird meist gecacht, damit die App zwischen den Prüfungen offline funktioniert (Sie wollen nicht bei jedem Start nach Hause telefonieren); genau dieser Cache verzögert einen Widerruf. Ist die Lease 24 Stunden gültig, funktioniert ein widerrufener Schlüssel auf dieser Maschine bis zu 24 Stunden weiter. Verkürzen Sie die Lease, um das Fenster zu verkleinern — um den Preis häufigerer Konnektivitätsanforderungen. Dieser Kompromiss ist die Entwurfsentscheidung: Koppeln Sie die Lebensdauer der Lease daran, wie viel Exposition ein geleakter oder zurückerstatteter Schlüssel tatsächlich kostet.

Eine Warnung: Wenn Sie einen Widerruf erkennen, leeren Sie die gecachte Lease. Sonst kann eine App, die direkt nach dem Widerruf offline geht, gegen die veraltete gecachte Lease weiter validieren, bis diese abläuft.

Das Offline-Problem und die signierte Widerrufsliste

Ein vollständig offline befindlicher oder isolierter Client macht nie einen Check-in, also greift „widerrufen beim nächsten Check-in” nie. Die Antwort ist, den Widerruf zum Client zu bringen, als Daten, denen er ohne Netz vertrauen kann: eine signierte Widerrufsliste (eine CRL im klassischen Sinn). Der Anbieter veröffentlicht die Menge widerrufener Schlüssel-IDs, signiert diese Liste mit demselben privaten Schlüssel, der die Lizenzen signiert, und verteilt sie: mit einem Software-Update, per Management-Tool ausgerollt oder in einer Datei für wirklich isolierte Systeme hereingetragen.

// The list is signed; verify it against the embedded public key before trusting a single entry.
RevocationList crl = RevocationList.Load(path);
if (!crl.VerifySignature(publicKey))
    throw new SecurityException("Revocation list signature invalid — ignoring it.");

if (crl.Contains(incomingLease.KeyId))
    EnterUnlicensedMode();   // known-bad key, even with no network

Die Signatur ist der Kern: Der Client muss die Liste offline akzeptieren, also muss die Liste ihren eigenen Echtheitsbeweis tragen, genau wie die Lizenz. Ein Angreifer, der eine gefälschte oder gekürzte Liste einschleusen könnte, würde einfach seinen eigenen Widerruf löschen. Weil sie signiert ist, scheitert eine beschnittene oder veränderte Liste an der Verifikation und wird ignoriert.

Die Latenz ist hier Ihre Verteilungskadenz: Die Liste erreicht eine Maschine, wenn das nächste Update kommt. Das ist langsamer als online, bedeutet aber, dass eine isolierte Installation nicht dauerhaft wehrlos gegen einen zurückerstatteten oder geleakten Schlüssel ist.

Nach dem Widerruf: Neuausstellung für den legitimen Fall

Nicht jeder Widerruf ist feindlich. Ein Kunde, der aus Versehen rückgebucht hat, oder dessen Schlüssel ohne eigenes Verschulden geleakt wurde, verdient weiterhin, Ihre Software auszuführen. Koppeln Sie den Widerruf daher mit sauberer Neuausstellung: Widerrufen Sie den kompromittierten Schlüssel, stellen Sie einen frischen aus und lassen Sie den Kunden ihn aktivieren. Da der alte Schlüssel auf der Widerrufsliste steht und der neue nicht, koexistieren die beiden korrekt: Der geleakte Schlüssel ist tot, wo immer er sich verbreitet, der neue funktioniert. Widerstehen Sie der Versuchung, „zu entwiderrufen”; ein widerrufener Schlüssel sollte für immer widerrufen bleiben, und der Kunde wechselt zu einer neuen Anmeldeinformation.

Das Fenster bewusst entwerfen

Widerruf erzwingt eine explizite Entscheidung: Wie lange darf ein widerrufener Schlüssel auf jeder Maschine weiter funktionieren? Online ist das das Lease-/Recheck-Intervall; offline ist es die Update-Kadenz plus die CRL. Setzen Sie beide aus dem Risiko, nicht aus Gewohnheit. Ein hochwertiger Unternehmens-Platz, der weiterverkauft werden könnte, rechtfertigt kurze Leases und häufige CRLs; ein günstiges Einzelnutzer-Tool verträgt einen Tag. Der Fehler ist, es implizit zu lassen: eine 30-Tage-Cache-Lease auszuliefern und sich dann zu wundern, dass ein zurückerstatteter Schlüssel vier Wochen später noch funktioniert.

Die Ausstellung bringt eine Lizenz in die Welt. Der Widerruf ist, wie Sie danach die Autorität darüber behalten — und ein Lizenzsystem, das das eine kann, aber nicht das andere, sieht nur fertig aus.