Révocation de licence : faire cesser une clé, en ligne et hors ligne

Tous les tutoriels de licence enseignent l”émission : générer une clé, la signer, la remettre. Bien moins enseignent l”autre moitié, là où se trouve la vraie ingénierie : faire cesser une clé. Un client se fait rembourser. Une clé apparaît sur un forum. Une rétrofacturation arrive. Un employé détenant la clé de l”entreprise s”en va. Dans chaque cas, vous avez besoin qu”une clé qui existe déjà, sur la machine de quelqu”un d”autre, cesse d”accorder votre logiciel. C”est la révocation, et elle se comporte très différemment en ligne et hors ligne.

Ce qu’est la révocation — et ce qu’elle n’est pas

Révoquer une licence est une déclaration négative signée : l”éditeur déclare que la clé K n”est plus valide. Elle n”atteint ni n”efface rien sur le disque du client ; elle change ce que votre app conclut la prochaine fois qu”elle évalue cette clé. Tout le problème se réduit donc à une question : quand l”app réévalue-t-elle, et entend-elle parler de la révocation à temps ?

Ce cadrage compte parce qu”il pose l”attente honnête. La révocation n”est jamais instantanée partout. Ce que vous contrôlez, c”est la fenêtre entre la révocation et la clé devenue morte sur une machine donnée. Votre travail est de rendre cette fenêtre assez petite pour le risque, et de ne jamais prétendre qu”elle est nulle.

Révocation en ligne : échouer fermé au prochain check-in

Le cas courant est une app connectée. Vous marquez la clé révoquée côté serveur, et la prochaine fois que le client parle au service — une revalidation, une réactivation, un heartbeat — le service répond « révoquée » et le client échoue vers l”état sans licence.

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
}

La fenêtre d”exposition ici est votre intervalle de revérification. Une lease liée à la machine est en général mise en cache pour que l”app fonctionne hors ligne entre les vérifications (vous ne voulez pas appeler la maison à chaque lancement) ; ce même cache est ce qui retarde une révocation. Si la lease est valide 24 heures, une clé révoquée continue de fonctionner jusqu”à 24 heures sur cette machine. Raccourcissez la lease pour réduire la fenêtre, au prix d”exigences de connectivité plus fréquentes. Ce compromis est la décision de conception : liez la durée de vie de la lease au coût réel d”une clé fuitée ou remboursée.

Une mise en garde : quand vous détectez une révocation, videz la lease mise en cache. Sinon, une app qui se déconnecte juste après la révocation peut continuer à valider contre la lease en cache périmée jusqu”à son expiration.

Le problème hors ligne et la liste de révocation signée

Un client totalement hors ligne ou isolé ne fait jamais de check-in, donc « révoquée au prochain check-in » ne se déclenche jamais. La réponse est d”apporter la révocation jusqu”au client sous forme de données auxquelles il peut faire confiance sans réseau : une liste de révocation signée (une CRL, au sens classique). L”éditeur publie l”ensemble des ids de clés révoquées, signe cette liste avec la même clé privée qui signe les licences, et la distribue : avec une mise à jour logicielle, poussée par un outil de gestion, ou portée dans un fichier pour les systèmes vraiment isolés.

// 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

La signature est le point crucial : le client doit accepter la liste hors ligne, donc la liste doit porter sa propre preuve d”authenticité, exactement comme la licence. Un attaquant capable d”injecter une liste falsifiée ou tronquée supprimerait tout simplement sa propre révocation. Parce qu”elle est signée, une liste rognée ou altérée échoue à la vérification et est ignorée.

La latence ici est votre cadence de distribution : la liste atteint une machine quand arrive la prochaine mise à jour. C”est plus lent qu”en ligne, mais cela signifie qu”une installation isolée n”est pas définitivement sans défense face à une clé remboursée ou fuitée.

Après la révocation : réémettre pour le cas légitime

Toute révocation n”est pas hostile. Un client qui a rétrofacturé par erreur, ou dont la clé a fuité sans faute de sa part, mérite toujours d”exécuter votre logiciel. Associez donc la révocation à une réémission propre : révoquez la clé compromise, émettez-en une nouvelle et laissez le client l”activer. Comme l”ancienne clé est sur la liste de révocation et la nouvelle non, les deux coexistent correctement : la clé fuitée est morte partout où elle se propage, la nouvelle fonctionne. Évitez la tentation de « dé-révoquer » ; une clé révoquée devrait rester révoquée pour toujours, et le client passe à une nouvelle identité.

Concevoir la fenêtre à dessein

La révocation force une décision explicite : combien de temps une clé révoquée peut-elle continuer à fonctionner sur chaque machine ? En ligne, c”est l”intervalle de lease/revérification ; hors ligne, c”est la cadence de mise à jour plus la CRL. Fixez les deux selon le risque, pas par habitude. Un siège entreprise de grande valeur qui pourrait être revendu justifie des leases courtes et des CRL fréquentes ; un outil mono-utilisateur bon marché peut tolérer un jour. L”erreur est de le laisser implicite : livrer une lease en cache de 30 jours puis s”étonner qu”une clé remboursée fonctionne encore quatre semaines plus tard.

L”émission met une licence dans le monde. La révocation est la façon dont vous gardez l”autorité dessus ensuite — et un système de licences capable de l”un mais pas de l”autre ne fait que paraître achevé.