Une clé révocable qui n’est pas un kill-switch

Un fournisseur qui peut révoquer une licence à distance dispose, par construction, d’un canal vers le système du client. Pour la plupart des logiciels, cela n’a rien de remarquable. Pour une infrastructure souveraine — un déploiement qu’une institution exécute sur son propre matériel, éventuellement air-gapped — c’est une contradiction : le canal même qui permet la révocation distante instantanée est celui qui brise la promesse de souveraineté.

La tension, dite clairement

Vous voulez deux choses qui s’opposent. Vous voulez que l’institution détienne son propre système sans canal de contrôle extérieur. Et vous voulez des droits d’usage qui peuvent expirer ou être retirés. Une conception naïve résout la tension en ajoutant un canal — et perd discrètement la première propriété pour gagner la seconde.

Résolvez-la par un certificat signé, vérifié localement

L’alternative consiste à faire du droit d’usage un certificat de droits d’usage signé que le déploiement vérifie localement. L’institution ne détient que la clé publique nécessaire à sa vérification. Il n’y a pas de canal entrant ; il y a un document que le système lit. La révocation, lorsqu’elle s’applique, est une déclaration signée que l’institution peut importer — connectée ou à la main — non une commande distante.

Ce que la révocation peut, et ne peut pas, toucher

La ligne qui rend cela sûr est simple. La révocation bloque les nouvelles actions sensibles. Elle ne bloque jamais l’accès de l’institution à ses données, et n’empêche jamais l’institution d’arrêter le système. Un droit qui pourrait verrouiller une institution hors de ses propres enregistrements, ou l’empêcher de déclencher son propre arrêt d’urgence, ne serait pas une clause de licence — ce serait la backdoor que la conception cherchait à éviter.