Sécurité et modèle de lease

La version honnête de la façon dont Keyright sécurise les licences — ce que la cryptographie protège et ne protège pas, et comment fonctionne la lease. Si vous évaluez Keyright pour un produit réel, lisez cette page avant de livrer.

Qu’est-ce qui est réellement sécurisé — la clé, ou autre chose ?

La clé de licence (LIC-…) n’est qu’un identifiant, pas le secret. Elle ne porte aucun droit et n’accorde rien par elle-même. Ce à quoi votre application fait confiance, c’est le document signé que le service renvoie à l’activation — la lease (en ligne) ou un fichier de licence signé (hors ligne). Les deux sont signés avec la clé privée RSA-2048 de votre produit, qui réside uniquement sur le service d’émission et est stockée chiffrée au repos (AES-256-GCM sous une clé de chiffrement de clés ; en production, le service refuse de démarrer sans elle). Votre application n’embarque que la clé publique correspondante et vérifie la signature (PKCS#1 v1.5 / SHA-256).

Donc :

• Une clé divulguée permet à quelqu’un de tenter une activation contre votre limite de sièges — rien de plus. Il ne peut pas s’accorder un niveau supérieur, davantage de sièges ni une expiration plus lointaine, car tout cela se trouve dans la charge utile signée qu’il ne peut pas produire.
• Si une clé fait l’objet d’abus, vous la révoquez (tableau de bord ou /admin/licenses/{id}/revoke). Les révocations se propagent immédiatement en ligne, et hors ligne via une liste de révocation signée que le client consulte.
• Votre application ne fait jamais confiance à une chaîne de clé qu’elle n’a pas vue signée par le service. Elle échoue en mode fermé : pas de signature valide ⇒ pas de licence.

Pourquoi une licence mono-poste ne peut pas tourner sur deux machines — même hors ligne {#seats}

Deux contrôles indépendants, et c’est celui hors ligne qui compte :

1. Application des sièges côté serveur (en ligne). L’activation compte les machines distinctes par rapport au nombre de sièges. Une nouvelle machine au-delà de la limite reçoit SeatLimit. Réactiver la même machine est idempotent, donc ne gonfle jamais le compte.
2. Liaison par verrouillage par machine (fonctionne sans réseau). Chaque lease/fichier hors ligne signé est lié à une empreinte de machine (KRM1:…) dérivée d’identifiants matériels/OS stables, salés et hachés. L’empreinte est à l’intérieur de la charge utile signée ; ainsi, lors de la validation, le client recalcule l’empreinte de cette machine et vérifie qu’elle correspond. Copiez une lease hors ligne sur une seconde machine et la validation renvoie MachineMismatch — la signature est correcte, mais ce n’est pas cette machine.

C’est pourquoi le hors ligne ne devient pas une faille : une lease hors ligne est générée pour un seul identifiant de machine (et confirme malgré tout un siège lors de son émission), elle ne peut donc pas être partagée. Keyright tolère le changement d’un composant « souple » (p. ex. le renommage d’une machine) pour que la maintenance ordinaire ne bloque pas un utilisateur légitime, tandis que l’ancre matérielle doit toujours correspondre.

Comment lire « incassable »

Soyez précis sur les deux menaces distinctes :

• Falsification / altération — c’est cryptographiquement verrouillé. Personne ne peut créer une licence valide, monter de niveau, ajouter des sièges ou repousser une expiration sans votre clé privée, et cette clé ne quitte jamais le serveur. Modifiez un seul champ d’une lease ou d’un fichier de licence et la signature RSA ne se vérifie plus, donc le client le rejette. En ce sens, les documents sont infalsifiables et toute altération est détectable.
• Un attaquant déterminé sur une machine qu’il contrôle entièrement est un problème différent, et aucune bibliothèque de licences ne le résout à elle seule. Quelqu’un capable de patcher votre binaire compilé peut, en principe, contourner la vérification if (!info.IsValid) elle-même — c’est vrai de tous les produits de licence, parce que la vérification s’exécute sur son CPU. Keyright rend la licence infalsifiable ; protéger le code qui applique la licence est une couche distincte. Associez Keyright à Nebula.NET (obfuscation, anti-tamper, chiffrement des méthodes) quand cela compte. Nous préférons vous le dire plutôt que de prétendre qu’une signature arrête un débogueur.

Autres questions fréquentes sur la sécurité, la stabilité et le passage à l’échelle

• Stabilité / résilience hors ligne. La validation est locale et sans état — après l’activation, votre application ne dépend pas de la disponibilité du service pour continuer à fonctionner (c’est tout l’intérêt de la lease). Une panne du service ne laisse pas en plan les clients activés pendant leur fenêtre de grâce.
• Évolutivité. Le service d’émission est sans état par requête et évolutif horizontalement ; le chemin critique (/v1/activate, /v1/validate) est une opération de signature plus une vérification de sièges. Comme les clients valident hors ligne entre deux activations, vous ne recevez pas une requête à chaque lancement de l’application.
• Isolation multi-tenant. Chaque tenant possède sa propre clé de signature et les données sont isolées par tenant, de sorte que la clé ou les licences d’un éditeur ne peuvent jamais vérifier ni toucher celles d’un autre.
• Résistance aux abus. Les endpoints clients sont limités en débit ; les endpoints d’administration exigent un jeton et sont délimités par rôle (Read < Write < Manage < Own) avec une piste d’audit.
• Manipulation de l’horloge. Les essais et les expirations sont vérifiés par rapport à un horodatage persistant de première observation ; reculer l’horloge système est détecté (ClockTampered) plutôt que récompensé.

---

La lease, expliquée

Pourquoi émettre une lease ?

Une lease est un jeton de grâce signé et de courte durée (par défaut 14 jours) que le service renvoie à l’activation. C’est l’équilibre entre deux mauvais extrêmes : contacter le serveur à chaque lancement (fragile, peu respectueux de la vie privée, cassé dès que votre service a un hoquet) ou faire confiance à une machine pour toujours après une seule activation (incontrôlable). La lease permet à une machine activée de fonctionner hors ligne pendant la fenêtre de grâce, puis de revérifier.

Le produit doit-il revenir vers Keyright pour renouveler la lease ?

Oui — mais de façon invisible, et seulement occasionnellement. Le modèle recommandé est d’appeler ActivateAsync au démarrage : quand la machine est en ligne, cela rafraîchit silencieusement la lease de 14 jours (idempotent, aucun siège supplémentaire) ; quand elle est hors ligne, le SDK continue de valider avec la lease en cache. Une machine normalement connectée se renouvelle donc sans que personne ne s’en aperçoive, et les 14 jours sont simplement la durée pendant laquelle elle peut rester complètement hors ligne avant de devoir joindre le service une fois. Vous pouvez élargir ou réduire cette fenêtre (KEYRIGHT_LEASE_TTL_DAYS) pour arbitrer entre la tolérance hors ligne et la rapidité avec laquelle une révocation ou un changement de sièges prend effet.

Que se passe-t-il si une machine passe hors ligne après l’activation ?

Elle continue de fonctionner jusqu’à ce que le leaseExpiresUtc de la lease soit dépassé — la fenêtre de grâce. Reconnectez-vous à tout moment avant cela et la lease est rafraîchie pour une nouvelle fenêtre. Si la fenêtre s’écoule sans contact, Validate() renvoie Expired (« reconnectez-vous pour revalider ») et votre application échoue en mode fermé. Pour les machines qui resteront hors ligne longtemps ou définitivement, ne comptez pas sur la lease de 14 jours — émettez une lease hors ligne à TTL long (365 jours par défaut) ou livrez un fichier de licence hors ligne autonome. Voir Activation et désactivation.

Un utilisateur peut-il simplement modifier le fichier de lease pour la prolonger indéfiniment ?

Non. L’expiration (leaseExpiresUtc) fait partie de la charge utile signée, ce n’est pas un réglage séparé. Modifiez-la — ou le niveau, les sièges, la liaison à la machine, quoi que ce soit — et la signature RSA ne correspond plus, donc le client rejette la lease avec SignatureInvalid et retombe en mode sans licence. Il n’existe aucun champ qu’un utilisateur puisse basculer. Reculer l’horloge pour se replacer dans une ancienne fenêtre n’aide pas non plus : c’est précisément ce que la détection de manipulation de l’horloge attrape. La seule façon d’obtenir une lease plus longue est que vous en émettiez une.

Comment fonctionne l’activation hors ligne, en un paragraphe ?

La machine hors ligne émet son empreinte ; vous (avec une connexion et un jeton admin) générez une lease liée à cette empreinte avec le TTL de votre choix ; la machine l’importe et valide localement jusqu’à l’échéance du TTL, sans aucun réseau. C’est le même mécanisme de lease signée que l’activation en ligne — simplement livré à la main plutôt que par HTTP, et lié à exactement une machine pour qu’elle ne puisse pas être partagée. Pas à pas : Activation hors ligne / isolée (air-gapped).