Faire tourner vos clés de signature de licence sans bloquer vos clients

Une clé de licence est une affirmation — « ce client possède l’édition Pro, 3 postes, jusqu’en mars prochain » — et votre app croit cette affirmation pour une seule raison : elle a été signée par une clé en laquelle votre app a confiance. Cette clé de signature est la racine de tout le système. Tout ce qui vient ensuite — les éditions, les plafonds de postes, l’expiration, les leases qui permettent à une machine activée de fonctionner hors ligne — hérite sa confiance de cette unique clé. C’est aussi pourquoi la faire tourner fait peur : changez la racine et vous risquez d’invalider chaque licence que vous avez jamais émise.

Vous n’êtes pas obligé. Cet article détaille comment faire tourner une clé de signature Keyright sans aucune interruption visible pour le client : ce que la clé protège vraiment, pourquoi un échange naïf bloque tout le monde, comment la confiance chevauchée rend la transition fluide, et comment les leases et les fichiers hors ligne décident de la durée que doit avoir le chevauchement.

Ce que la clé de signature protège vraiment

Keyright est offline-first. Quand vous émettez une licence, le service signe une charge utile canonique d’affirmations avec la clé de signature privée de votre produit et vous renvoie une chaîne de clé copiable-collable. Votre app embarque uniquement la clé publique correspondante. Au moment de la validation, l’app vérifie la signature localement — sans réseau — et ne fait confiance qu’alors au niveau, à l’expiration et au nombre de postes qu’elle contient. L’activation ajoute un second artefact signé : un lease de courte durée (14 jours par défaut) lié à la machine, lui aussi signé par cette clé, qui est ce qui permet à une machine activée de continuer à fonctionner hors ligne jusqu’à ce que la fenêtre de grâce du lease s’épuise.

La clé fait donc un gros travail porteur, et elle est embarquée dans un logiciel que vous avez déjà distribué. C’est exactement la propriété que vous voulez pour la sécurité — la racine de confiance est sur le client, pas sur un serveur qu’un attaquant pourrait manipuler par ingénierie sociale — et exactement la propriété qui fait de la rotation un problème de conception plutôt qu’un appui sur un bouton.

Pourquoi l’échange naïf est un désastre

Imaginez que vous soupçonnez une fuite de la clé privée. Le réflexe évident : générer une nouvelle paire de clés, re-signer les nouvelles licences avec elle, distribuer une build de l’app qui embarque la nouvelle clé publique. Terminé ?

Non. À l’instant où cette build atteint un client, chaque licence et chaque lease signés par l’ancienne clé échouent à la vérification sur sa machine. La signature ne correspond plus à la clé embarquée, donc un client payant qui a activé la semaine dernière retombe à l’édition gratuite à son prochain lancement. Vous avez transformé une rotation de précaution en une panne généralisée sur le terrain.

L’échec est structurel : l’app fait confiance à exactement une clé, et vous l’avez changée sous les pieds d’artefacts qui sont encore valides. Le correctif est de faire confiance à deux clés pendant un temps.

Confiance chevauchée : la seule idée qui rend cela sûr

Chaque SDK Keyright vérifie une licence ou un lease entrant par rapport à une clé publique primaire et par rapport à une liste de clés publiques supplémentaires. Si une clé de confiance quelconque vérifie la signature, l’artefact est accepté. Cela transforme une bascule brutale en une fenêtre de chevauchement.

Voici le SDK .NET en fonctionnement normal — une clé :

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

Et le voici en pleine rotation. La nouvelle clé est primaire ; la clé sortante voyage dans AdditionalPublicKeysBase64 :

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>" },
});

Une licence signée par l’ancienne clé valide toujours (elle correspond à une clé supplémentaire). Une licence ou un lease signés par la nouvelle clé valident aussi (ils correspondent à la primaire). Personne ne perd de niveau. Les deux clés coexistent exactement aussi longtemps que des artefacts signés par l’ancienne sont encore en circulation — puis vous la retirez.

La rotation, étape par étape

1. Faites tourner la clé sur le service. Chaque produit possède sa propre clé de signature. Un appel authentifié la fait tourner ; l’ancienne clé est conservée comme clé précédente pour que vous puissiez encore voir ce qu’elle a signé, et la réponse vous remet la nouvelle clé publique à embarquer :

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>", ... }

(La même chose vit dans le tableau de bord sous l’onglet Signing key du produit — la rotation, l’import et la liste des clés précédentes sont dans sa section Advanced.) Après cela, les licences nouvellement émises et les leases nouvellement signés utilisent la nouvelle clé. Les licences déjà émises sont inchangées : leurs signatures ont été faites au moment de l’émission et ne changent pas rétroactivement.

2. Distribuez une build qui fait confiance aux deux clés. Ajoutez la nouvelle clé comme PublicKeyBase64 et la clé sortante dans AdditionalPublicKeysBase64, comme ci-dessus. Publiez-la par votre canal habituel. À partir de là, les clients acceptent les artefacts signés par l’une ou l’autre clé.

3. Laissez les leases porter la nouvelle clé sur le terrain. Vous n’avez à courir après personne. Comme une machine activée rafraîchit son lease à l’approche de l’expiration, chaque client en ligne re-prend naturellement un lease sous la nouvelle clé dans une fenêtre de grâce — 14 jours par défaut. Après deux fenêtres environ, essentiellement chaque lease actif sur le terrain est signé par la nouvelle clé.

4. Retirez l’ancienne clé. Une fois qu’aucun artefact signé par l’ancienne clé ne peut encore être vivant — chaque lease signé par elle a expiré, et aucun fichier hors ligne autonome signé par elle n’est encore en service — distribuez une build qui la retire de AdditionalPublicKeysBase64. Désormais seule la nouvelle clé est de confiance. La rotation est terminée, et si l’ancienne clé privée avait fuité, tout ce qu’elle a signé ne vaut maintenant plus rien pour un attaquant.

Ce qui fixe la durée du chevauchement

Le chevauchement ne peut pas être plus court que l’artefact de plus longue vie que l’ancienne clé a signé. Trois cas :

• Les machines activées en ligne avancent au rythme de votre TTL de lease (14 jours par défaut). Une fenêtre de grâce après que le service a changé de clé, essentiellement tout le monde a re-pris un lease.
• Les machines longtemps hors ligne à qui on a émis un lease hors ligne à TTL long (365 jours par défaut) restent sur l’ancienne clé jusqu’à l’expiration de ce lease. Si vous en avez, votre chevauchement est d’un an, pas de deux semaines : prévoyez-le.
• Les fichiers de licence hors ligne autonomes ne se rafraîchissent pas du tout ; ils avancent au rythme de vos versions. Un client sur une installation isolée maintient l’ancienne clé de confiance jusqu’à ce qu’il adopte une build signée par la nouvelle. Gardez l’ancienne clé dans la liste jusqu’à avoir confirmé que ces clients ont migré.

La règle empirique : gardez l’ancienne clé publique dans AdditionalPublicKeysBase64 jusqu’à ce que le dernier artefact qu’elle a signé ait expiré ou été remplacé, puis retirez-la à la version suivante. Il n’y a aucune pénalité à la laisser un peu plus longtemps, et une vraie à la retirer trop tôt.

Si la clé privée a réellement fuité

La rotation réoriente la confiance future, mais une clé privée fuitée signifie qu’un attaquant peut forger des licences auxquelles votre app actuellement distribuée fait encore confiance — jusqu’à ce qu’il adopte une build qui ne fait plus confiance à l’ancienne clé. Associez donc la rotation à la révocation. Keyright peut publier une liste de révocation signée, et l’activation en ligne vous permet de tuer des clés fuitées précises afin qu’une machine activée-mais-révoquée retombe à l’édition gratuite à son prochain rafraîchissement de lease. Pour une compromission confirmée, la séquence honnête est : faites la rotation, distribuez vite la build à double clé, révoquez les clés émises mauvaises connues, et raccourcissez le chevauchement aussi agressivement que vos clients hors ligne le permettent.

Et souvenez-vous de la limite qui s’applique à tout le licensing côté client : la vérification tourne sur la machine de l’utilisateur, donc un attaquant déterminé avec un décompilateur peut tenter de retirer le contrôle par patch. C’est précisément pourquoi Keyright est compatible au niveau du format avec Nebula.NET : vous obfusquez et durcissez l’assembly qui embarque la clé publique et effectue le contrôle, afin que le retirer par patch coûte un effort réel. La clé de signature est la racine cryptographique ; l’obfuscation protège le code qui l’applique.

La mise en place

La rotation de clé de signature dans Keyright est une opération d’un seul appel côté serveur plus un changement d’une ligne côté client, rendue sûre par la confiance chevauchée et cadencée par la durée de vie de vos leases. Générez ou faites tourner une clé depuis l’onglet Signing key du produit (ou l’endpoint signing-key), embarquez la nouvelle comme PublicKeyBase64, gardez la sortante dans AdditionalPublicKeysBase64 pendant une fenêtre de lease — plus longtemps si vous distribuez des fichiers hors ligne — puis retirez-la. Voyez le guide d’intégration du SDK .NET pour les options exactes et la page sécurité et leases pour voir comment les leases décident de votre chevauchement, ou la page produit Keyright pour le panorama complet. Le plan gratuit suffit pour répéter une rotation complète de bout en bout avant d’en dépendre.