La licence qui ne prouvait rien : signer une clé à travers deux langages

Pendant la plus grande partie de la vie de sh0, une clé de licence ressemblait à ceci :

sh0-biz-3f2a1c9e-88d4b077-1e5a9f30

Et le serveur en déduisait le plan comme ceci :

rustlet plan = if key.starts_with("sh0-biz-") {
    "business"
} else if key.starts_with("sh0-scl-") {
    "scale"
} else {
    "pro"
};

Relisez ce else. Toute chaîne non reconnue s'activait en Pro. hello-world vous offrait le palier payant. Cette moitié-là avait été refermée la veille : les chaînes inconnues renvoyaient désormais un 400. Mais le problème de fond a survécu au correctif, et c'est celui qui mérite d'être raconté.

La clé ne prouvait rien. Elle portait un plan, et aucune preuve que nous l'avions émise. Un client qui avait acheté Pro à 19 $ et voulait Business à 99 $ n'avait rien à attaquer. Il lui suffisait de savoir que les clés Business commencent par sh0-biz-, ce que la sienne lui montrait déjà.

Ce qu'une licence doit encaisser

Le correctif évident est une signature. Ce qui l'est moins, c'est la liste de contraintes autour, et c'est elle qui fait la conception.

sh0 est auto-hébergé. C'est tout le produit. Une vérification de licence qui exige Internet est une vérification qui échoue exactement dans le déploiement auquel nous vendons. La vérification doit donc fonctionner hors ligne, ce qui veut dire que la preuve voyage à l'intérieur de la clé et que le vérificateur est le binaire.

La clé est collée par un humain, dans un formulaire, depuis un e-mail. Elle tient sur une ligne et doit survivre au copier-coller.

L'émetteur est en Node — un site SvelteKit avec Prisma. Le vérificateur est en Rust. Deux langages, deux sérialiseurs JSON, deux implémentations de base64, et aucun code partagé.

Et un plan que l'on retire doit l'être pour une raison défendable. Un serveur qui perd Pro parce qu'une résolution DNS a échoué est pire qu'un serveur qui garde un Pro qu'il ne paie plus.

Le format

SH0-LIC-1.<base64url(payload JSON)>.<base64url(Ed25519 signature)>

Trois parties, l'étiquette de version en tête pour qu'une future rotation de clé soit un incrément de format et non une migration. La charge utile porte licence_id, plan, holder, issued_at et un expires_at optionnel.

La décision qui compte tient en une ligne et se rate facilement :

La signature couvre la charge utile base64url telle qu'elle est écrite, pas le JSON décodé.

Si vous signez l'objet décodé, les deux côtés doivent s'accorder sur la sérialisation : ordre des clés, espaces, façon d'émettre un null, échappement ou non du non-ASCII. JSON.stringify côté Node et serde_json côté Rust ne s'accordent pas sur tout cela, et n'ont pas à le faire. Signez les octets exacts qui voyagent, et la question disparaît. C'est la raison pour laquelle JWS signe les segments encodés.

La deuxième décision porte sur l'ordre des opérations :

rust// Signed bytes are the payload *as written*, not the decoded JSON.
ring::signature::UnparsedPublicKey::new(&ring::signature::ED25519, pubkey)
    .verify(payload_b64.as_bytes(), &signature)
    .map_err(|_| LicenceError::BadSignature)?;

// Only now is the payload worth reading: everything below this line has
// been proven to come from us.
let payload: LicencePayload = serde_json::from_slice(&payload_json)?;

Vérifier, puis désérialiser. Jamais l'inverse. Un désérialiseur est un analyseur syntaxique, un analyseur est une surface d'attaque, et il n'y a aucune raison de le pointer sur des octets choisis par un inconnu.

Échouer fermé, et le dire

La clé publique est une constante du binaire. Que doit-il se passer quand cette constante est vide — une compilation où personne ne l'a collée ?

La réponse tentante est « on accepte tout, ce n'est qu'une licence ». La bonne réponse est l'inverse :

rust/// When the key is not configured in a build, every activation is **refused**
/// -- a licence system that cannot verify must not accept.
const LICENCE_PUBKEY_HEX: &str = "…";

Un système de licences incapable de vérifier ne doit pas accepter. Le tableau de bord le dit, en cinq langues, plutôt que d'afficher une erreur générique.

Une décision plus discrète se cache dans le même fichier. free n'est pas un plan signable :

rust/// Plans a licence may carry. `free` is not among them: Free is the absence of
/// a licence, and signing one would be a way to *downgrade* a server remotely.
fn known_plan(plan: &str) -> bool {
    matches!(plan, "pro" | "scale" | "business")
}

Si nous pouvions signer une licence free, nous aurions construit un interrupteur d'arrêt à distance et remis cette capacité à quiconque mettrait un jour la main sur la clé de signature. Cela ne se désinvente pas une fois inscrit dans le format.

La révocation, et la règle qui a été la plus longue à écrire

Une licence signée est valide jusqu'à son expiration. Remboursements et rétrofacturations arrivent plus tôt que cela, alors le serveur demande à sh0.dev, une fois par jour, si la licence qu'il détient est toujours bonne.

Tous les modes d'échec de cette question ont la même réponse :

rust/// Read one revocation answer. Any failure -- DNS, timeout, 500, a body we do
/// not recognise -- is `Unknown`, deliberately: the only thing that removes a
/// plan is an explicit `revoked`.

Délai dépassé : on garde le plan. 500 : on garde le plan. Corps illisible : on garde le plan. Identifiant de licence inconnu : on garde le plan — celui-là vient du serveur, et c'est le cas qu'une implémentation paresseuse rate. Une sauvegarde restaurée, une faute de frappe, une licence émise par un autre déploiement, et voilà que 404 se lit « invalide » et qu'un client payant perd ses fonctions. L'endpoint renvoie donc 404, et le client traite 404 comme « je n'ai pas pu demander ».

Et une ligne de plus, dans le journal qui se déclenche quand un plan est réellement retiré :

Licence revoked upstream -- Pro features stop, running applications are untouched

La révocation coupe les fonctions payantes. Elle ne coupe rien de ce qui tourne. Quel que soit le litige commercial, la production de quelqu'un reste debout.

Deux langages, un seul test

Voici l'échec auquel cette conception expose. Les deux côtés passent leurs propres tests. Node signe, Node vérifie sa propre signature, vert. Rust vérifie, Rust fait l'aller-retour sur ses propres clés, vert. Puis la production émet une clé que tous les serveurs de la terre refusent, parce qu'un côté a utilisé du base64 standard et l'autre du base64url, ou que l'un a signé le JSON et l'autre l'encodage.

Rien, dans l'une ou l'autre des suites de tests, ne peut le voir. Le test d'interopérabilité est donc un vecteur figé : une licence produite par le signataire Node, avec une clé jetable générée pour l'occasion, versionnée dans la suite Rust.

rust/// It exists because the two halves are written in different languages: a
/// base64 alphabet, a padding rule or a "sign the JSON rather than the encoded
/// payload" mismatch would pass every test on each side alone and refuse every
/// real licence in production.
#[test]
fn a_licence_signed_by_the_node_issuer_verifies_here() {

Le vecteur porte un holder accentué et un horodatage ISO avec millisecondes — les deux choses qu'un émetteur JavaScript produit naturellement et sur lesquelles un analyseur Rust peut se montrer strict.

Ce que la relecture adverse a trouvé

L'implémentation est passée devant un relecteur en lecture seule avant le commit. Il a confirmé la cryptographie et l'ordre des opérations. Il a aussi trouvé cinq défauts réels, et les deux pires n'avaient rien à voir avec la cryptographie.

La clé privée entrait dans le contexte de build Docker. .gitignore couvrait *.pem — correctement, et l'historique git était propre. .dockerignore, lui, ne le faisait pas, et le Dockerfile fait COPY . .. L'image publiée était saine ; la couche builder ne l'était pas, et les couches de build survivent à leur build dans les caches et les exports de cache de registre. Une clé de signature est le seul secret qu'on ne peut pas renouveler discrètement : la remplacer, c'est reconstruire tous les serveurs déployés.

L'e-mail de livraison cassait sur la nouvelle clé. L'ancienne faisait 34 caractères. La nouvelle en fait 330, et le gabarit l'affichait en gras, 16 px, centrée, avec du letter-spacing et sans word-break. Une chaîne base64url ininterrompue n'a nulle part où se couper. Gmail et Outlook l'auraient déchiquetée — dans le seul canal qui livre la clé, et celui-là même que notre message d'erreur désigne : « Recopiez-la depuis votre e-mail de commande. »

Un troisième constat était plus subtil : expires_at était vérifié à l'activation, et plus jamais ensuite. Un serveur redémarre, recharge son plan depuis la base, et ne regarde plus la date. La date était décorative. Elle est désormais revérifiée au démarrage et à chaque passe quotidienne — avec la même règle que pour la révocation : une date illisible ne coûte son plan à personne.

Le prouver

Les tests étaient au vert, 27 sur 27, dont sept qui pilotent un vrai serveur HTTP pour prouver qu'un 500, un 404, un corps illisible et un endpoint injoignable laissent tous le plan intact. Des tests verts ne sont pas une preuve, cependant. Donc :

Deux VPS jetables, Debian 12 et Ubuntu 24.04. Installation neuve, 50 secondes chacune. Une licence signée par la clé de production, sur le site de production, activée via l'API sur un vrai serveur. Le plan passe à pro, le détenteur s'affiche. Révocation en amont. Redémarrage. Cinq minutes et vingt-cinq secondes plus tard :

pro active  →  free revoked

Et l'application déployée a répondu 200 à chacun des sondages pendant que cela se produisait.

Clé forgée : refusée. Charge utile altérée : refusée. Ancienne clé à préfixe — sh0-biz-1234-5678-9abc, la forme exacte qui achetait Business — refusée.

Cette dernière, c'est toute l'histoire en une ligne.

Ce qui n'a pas été construit

La licence reste un jeton au porteur. server_id n'est pas renseigné : une clé Business activée sur cinq serveurs fonctionne sur cinq serveurs. Ce n'est pas une régression — le format à préfixe avait la même propriété — mais c'est désormais le trou le plus large du modèle, et la conception qui a refermé celui de la contrefaçon n'a pas refermé celui-là. L'écrire noir sur blanc fait partie du travail.

L'activation ne consulte pas non plus l'endpoint de révocation. Une licence révoquée s'active et fonctionne jusqu'à la vérification quotidienne suivante. C'est un arbitrage délibéré : interroger le réseau à l'activation contredirait « une licence signée s'active hors ligne », qui est précisément la propriété que toute cette conception existe pour protéger. C'est un argument, pas un oubli — et sa place est dans le journal, à côté des tests qui passent.