Anatomie d'une clé de licence signée : pourquoi elle ne peut pas être falsifiée

Demandez à quelqu”un comment fonctionnent les clés de licence et vous entendez souvent « l”app envoie la clé à un serveur, le serveur vérifie si elle est valide ». Ce design existe, mais il a une dépendance dure : pas de serveur, pas de validation. Un meilleur design rend la clé auto-prouvante — elle porte ses propres claims et une signature cryptographique, et l”application la vérifie hors ligne avec une clé publique qu”elle distribue déjà. Rien de l”authenticité ne dépend d”un appel réseau. Comprendre ce qui vit dans une telle clé, et pourquoi elle ne peut pas être falsifiée, est la fondation de tout schéma de licensing robuste.

Une clé est un payload de claims signé

Une clé de licence moderne n”est pas un identifiant aléatoire ; c”est un petit ensemble de claims plus une signature sur ces claims. Les claims sont les faits que la licence affirme :

{
  "product": "acme-pro",
  "tier": "enterprise",
  "licensee": "acct_8f21",
  "seats": 25,
  "expiry": "2027-10-04T00:00:00Z",
  "features": ["sso", "audit-log"]
}

À elle seule, cette payload n”est que des données — n”importe qui pourrait la taper. Ce qui en fait une licence est la signature ajoutée : une valeur calculée à partir de la payload avec une clé privée que seul votre serveur de licences détient. La clé que votre client colle est la payload et la signature ensemble, encodées dans une forme compacte et collable.

La séparation privée/publique est tout le truc

La raison pour laquelle la clé ne peut pas être falsifiée est la cryptographie asymétrique. Il y a deux clés, et elles ne sont pas interchangeables :

• La clé privée vit seulement sur votre serveur de licences. C”est la seule chose qui peut produire une signature valide.
• La clé publique est embarquée dans votre application, distribuée à chaque client. Elle peut vérifier une signature mais ne peut pas en produire une.

Dériver la clé privée de la publique est calculatoirement infaisable pour les algorithmes utilisés (comme Ed25519 ou ECDSA sur P-256). Donc un attaquant qui a votre application — et a donc la clé publique — ne peut toujours rien signer. Il peut lire la clé publique toute la journée ; cela ne l”aide pas à forger une nouvelle clé ni à altérer une existante, car la vérification échouera dès qu”un seul octet de la payload ou de la signature change.

Voici la forme de la signature sur le serveur et de la vérification dans l”app, avec Ed25519 :

// SERVER (private key never leaves here): sign the canonical claims bytes.
byte[] payload = CanonicalJson(claims);                 // stable byte encoding
byte[] signature = SignEd25519(payload, privateKey);     // 64-byte signature
string licenseKey = Base32(Concat(payload, signature));  // what the customer gets

// APP (ships only the public key): verify before trusting any claim.
var (payload, signature) = SplitBase32(licenseKey);
if (!VerifyEd25519(payload, signature, PublicKey))        // embedded public key
    throw new InvalidLicenseException("signature invalid");

var claims = ParseClaims(payload);
if (claims.Product != "acme-pro") throw new InvalidLicenseException("wrong product");
// expiry, tier, seats, features are now trustworthy — they were signed

L”ordre compte : vérifiez la signature d”abord, puis lisez les claims. Un claim que vous n”avez pas vérifié est une entrée contrôlée par l”attaquant. Une fois que VerifyEd25519 renvoie true, chaque champ de la payload est connu comme étant exactement ce que votre serveur a signé — inchangé et authentique.

Pourquoi autonome bat « confronter à une liste »

Comme les claims et la signature voyagent ensemble et que la clé publique est déjà dans l”app, la vérification est entièrement locale. Aucun aller-retour serveur n”est nécessaire pour savoir qu”une clé est authentique et non modifiée — ce qui rend possible la véritable activation en environnement isolé et hors ligne. Un design de liste sur serveur ne peut pas faire cela : il doit joindre le serveur à chaque vérification, donc une machine hors ligne, une coupure réseau ou un endpoint de validation mis hors service deviennent tous des pannes pour les clients payants.

Les clés autonomes passent aussi à l”échelle trivialement. Il n”y a pas de ligne de base de données à chercher par validation ni d”endpoint à garder en ligne pour l”authenticité ; les mathématiques sont l”autorité. Vous pouvez aussi contacter un serveur périodiquement — pour honorer la révocation ou rafraîchir un lease — mais c”est une amélioration par-dessus une clé déjà prouvablement authentique, pas un prérequis pour lui faire confiance.

À quoi ressemble une clé falsifiée ou manipulée

Considérez les deux choses qu”un attaquant pourrait essayer. Altérer un claim — passer tier à enterprise ou pousser expiry d”une décennie — change les octets de la payload, donc la signature ne correspond plus et VerifyEd25519 renvoie false. Fabriquer une clé entière exige de produire une signature qui vérifie contre votre clé publique, ce qui exige la clé privée qu”il n”a pas. Les deux échouent à la même vérification. C”est la preuve de manipulation qu”un design chaîne-aléatoire-plus-base-de-données n”a pas : là, la chaîne ne porte pas de claims, donc le serveur est la seule chose qui sait ce que la clé signifie, et la clé elle-même ne prouve rien.

Détails pratiques qui comptent

Quelques spécificités séparent un jouet d”un schéma de production :

• Encodage canonique. Signez une représentation en octets stable des claims, et vérifiez sur les octets exacts reçus. Si votre sérialiseur JSON réordonne les champs ou varie les espaces entre la signature et la vérification, les clés valides échoueront. Une forme canonique (ordre de champs fixe, pas d”espaces incidents) évite cela.
• Rotation de clés. Vous voudrez un jour faire tourner la clé de signature. Distribuez l”app capable d”accepter plus d”une clé publique — l”actuelle plus des prédécesseurs récents — pour que les clés signées avant une rotation continuent de vérifier. Intégrez cela dès le premier jour ; l”ajouter après est pénible.
• Algorithme moderne, taille adéquate. Préférez Ed25519 ou ECDSA P-256 aux choix hérités ; ils donnent des signatures et clés courtes avec une sécurité forte. Évitez de faire votre propre signature ou d”utiliser un MAC symétrique dans le client (voir ci-dessous).
• Encodez pour les humains là où les clés sont tapées. Si les clients collent des clés à la main, une forme base32 groupée (XXXX-XXXX-…) avec un checksum attrape les fautes de frappe avant même que la vérification ne tourne.

Ce que la signature ne fait pas

La signature est la fondation, pas tout le bâtiment. Deux limites à clarifier. D”abord, une signature prouve l”authenticité, pas l”exclusivité — une clé signée est authentique quel que soit le nombre de gens qui la copient, donc signer ne fait rien pour arrêter le partage. C”est le travail de l”activation et de la liaison d”appareil, posées par-dessus. Ensuite, ne mettez jamais le secret de signature dans le client. Tout le schéma repose sur le fait que la capacité de signature soit réservée au serveur ; si vous « simplifiez » en utilisant un secret symétrique (une clé HMAC) embarqué dans l”app pour qu”elle puisse à la fois signer et vérifier, alors quiconque extrait ce secret — et il peut être extrait — peut forger des clés illimitées. La signature asymétrique existe précisément pour que le client ne détienne que le pouvoir de vérifier, jamais de créer.

Ensemble, une clé de licence signée est une petite credential auto-prouvante : des claims que votre serveur a cautionnés, enveloppés dans une signature que seul votre serveur a pu produire et que toute copie de votre app peut vérifier sans réseau. Réussissez cette fondation — vérifiez avant de faire confiance, gardez la clé privée côté serveur, planifiez la rotation — et tout le reste du licensing (expiration, droits, activation, révocation) est bâti sur un terrain qu”on ne peut pas falsifier sous vos pieds.