Résumé

  • La révision 12 du projet BBS permet au titulaire de prouver qu’il connaît une signature portant sur plusieurs messages tout en ne révélant que ceux qu’il choisit. La non-corrélabilité annoncée concerne la valeur aléatoire de la preuve : l’en-tête lié à la signature, l’en-tête de présentation, les valeurs révélées, le nombre et la position des messages, la clé publique, l’adresse réseau et les données de l’application peuvent encore servir de jointure.
  • Une validation BBS est donc un reçu circonscrit. Elle atteste une relation cryptographique sous une clé donnée ; elle n’atteste ni l’identité civile du porteur, ni le contrôle effectué à l’émission, ni l’état actuel, ni la suffisance des éléments présentés, ni l’autorisation, ni l’absence de traçage de bout en bout, ni l’effet obtenu.

La scène est banale : le tableau de bord de confidentialité affiche deux preuves valides et différentes. Il les classe comme « non corrélables ». Un outil de lutte contre la fraude les rattache pourtant au même groupe avant même d’examiner le contenu métier.

Il n’a cassé ni la courbe, ni le zéro de connaissance. Il a utilisé ce qui entourait la preuve : le même header presque unique, la même forme de credential, une combinaison d’indices peu fréquente, une clé d’émetteur employée pour une minuscule cohorte et un identifiant de terminal conservé par la couche HTTP. Les deux rapports peuvent être exacts. Ils ne parlent pas du même objet.

Le mérite du draft-irtf-cfrg-bbs-signatures-12 est de ne pas entretenir cette confusion. Il décrit une primitive puissante, puis limite précisément son affirmation de confidentialité. Cette limite appartient au produit autant que l’algorithme.

La révision 12 rend l’essai reproductible, pas la vie privée automatique

Le texte, déposé le 28 septembre 2026, est un Internet-Draft actif du CFRG dans le flux IRTF, destiné à une publication Informational. Ce n’est ni un RFC achevé, ni une norme IETF Standards Track, ni la preuve d’un déploiement, d’une interopérabilité ou d’une certification commerciale.

Le passage de la révision 11 à la révision 12 est concret. Des emplacements de modèle deviennent des constantes, scalaires, générateurs, signatures et fixtures de preuve exploitables. Un développeur peut donner les entrées prescrites à son code et comparer les octets obtenus. Pour vérifier une sérialisation, une opération de courbe ou une interface, c’est une avancée réelle.

Mais une fixture choisit à l’avance la clé, les messages, les en-têtes et l’aléa simulé. Le système vivant doit établir autre chose : provenance et cohérence de la clé, taille de la population partageant l’en-tête, absence de réutilisation d’aléa après un fork ou un snapshot, métadonnées ajoutées par le portefeuille, le réseau et le verifier. Le test ne voit aucune de ces décisions.

Un dossier de mise en production doit donc garder deux colonnes. La première dit que cette version produit les sorties attendues pour les vecteurs de la révision 12. La seconde couvre la distribution des clés, les ensembles d’anonymat, les valeurs d’en-tête, le générateur aléatoire, les journaux et les essais de corrélation. La première ne peut pas servir de raccourci pour la seconde.

Traduire VALID par une phrase qui s’arrête au bon endroit

BBS signe une liste ordonnée de messages au moyen d’une signature de taille constante. Le holder peut ensuite produire une preuve aléatoire, à divulgation nulle de la signature, et ne montrer qu’un sous-ensemble des messages signés. ProofVerify reçoit la clé publique du Signer, la preuve, le header fixé lors de la signature, le presentation_header propre à cette présentation, les messages divulgués et leurs indices d’origine.

Un résultat valide autorise la phrase suivante : le prover connaît une signature BBS valable sous cette clé, couvrant une liste dont la longueur est déduite ; les valeurs montrées occupaient ces positions ; les deux en-têtes ont été liés à la preuve ; la preuve n’a pas révélé la signature cachée ni les valeurs non divulguées.

Il ne dit pas quelle personne utilise le logiciel. Il ne décrit pas comment l’Issuer a vérifié une affirmation dans le monde réel. Il ne consulte pas spontanément une liste de révocation. Il ne prouve pas qu’aucun champ important n’a été omis. Il ne décide pas si une porte, un paiement ou une récupération de compte doivent être autorisés. Il n’observe pas la conséquence.

L’article existant sur RFC 9901 conserve la frontière propre au SD-JWT entre divulgation valide et dossier complet. La frontière BBS étudiée ici est différente : même lorsque la non-corrélabilité cryptographique de la preuve tient, l’enveloppe visible peut rester une empreinte.

L’en-tête choisi par l’émetteur peut devenir un nom permanent

Le projet définit deux en-têtes dont les propriétaires et les durées diffèrent. Le header est choisi par le Signer. Il est lié à la signature initiale et à toutes les preuves qui en dérivent ; il doit être révélé à chaque Verifier. Il convient à un contexte commun — identifiant d’application, domaine de déploiement, version à faible cardinalité — mais il devient dangereux dès qu’il individualise.

Un identifiant de credential aléatoire, une date d’expiration à la seconde, une adresse électronique ou un numéro de terminal se répétera dans toutes les présentations. La randomisation de la preuve n’y change rien. Le projet exige donc une valeur de faible entropie partagée par une large population.

Cette qualité n’est jamais absolue. Un code pays peut être partagé par des millions de personnes dans un programme mondial et n’en désigner que deux dans une petite mission. Une version logicielle très commune au lancement peut isoler trois appareils après une campagne de mise à jour. Un identifiant de déploiement banal peut devenir unique une fois combiné à la région, à la clé et à la structure des messages.

L’Issuer doit conserver les octets exacts, la règle de génération, la population attendue et observée, la clé associée et les exceptions. Le Holder ne peut pas remplacer ce champ déjà signé. Le pouvoir de le choisir et la responsabilité de son risque restent donc chez l’émetteur.

L’en-tête de présentation atteste un challenge, pas tout son contexte

Le presentation_header est choisi pour une preuve. Il peut intégrer un nonce fourni par le Verifier, une audience, un domaine, une période de validité ou un message que le Prover souhaite signer. Une preuve valide confirme que la valeur est liée à cette preuve.

La fraîcheur ne découle pas d’une chaîne qui paraît aléatoire. Il faut savoir qui a émis le nonce, à quelle session et audience il appartient, quand il expire, s’il a déjà été consommé et comment les échecs sont traités. En mode non interactif, une autre règle doit établir son unicité. Un nonce repris d’un canal à l’autre peut être unique tout en visant la mauvaise transaction.

La règle de confidentialité est symétrique. Une valeur de forte entropie est utile si elle change à chaque preuve et ne contient aucune donnée identifiante. Sa réutilisation fabrique une poignée stable. Une localisation précise, un numéro de compte ou un build très rare peut identifier même sans répétition.

Le journal nécessaire comprend l’origine, l’audience, la session, la création, l’expiration et l’état consommé. Il ne suffit pas de garder « nonce valide ». À l’inverse, tout conserver pour toujours créerait une nouvelle base de corrélation. Anti-rejeu et minimisation ne sont pas la même commande.

La forme des secrets reste visible

La preuve masque les valeurs non divulguées, mais sa taille et la liste des révélations permettent d’inférer le nombre total de messages. Les indices divulgués révèlent leurs positions dans le schéma. Une longueur, un ordre ou une combinaison rares peuvent identifier une famille de credentials ou une petite cohorte.

Supposons cinq champs pour le personnel ordinaire, neuf pour les prestataires et treize pour un programme protégé. Sans retrouver un seul secret, le Verifier peut classer le porteur. Si une seule cohorte présente ensemble les indices 2 et 11, le croisement de plusieurs journaux réduit encore l’ensemble.

Le projet recommande un remplissage vers une longueur commune et un ordre stable lorsque cela est possible. Ce ne sont pas des préférences esthétiques. Ce sont des contrôles de population. Les preuves d’exploitation doivent montrer version du schéma, distribution des longueurs, règle de padding, carte des indices et essais portant sur les champs optionnels.

Le padding augmente la taille et la complexité ; une politique de remplissage rare peut elle-même devenir un signal. La bonne question n’est pas « avons-nous rempli ? », mais « quelle population voulons-nous rendre indiscernable, et quelle est la plus petite classe réellement produite ? ».

La clé publique peut découper la population avant la première preuve

Chaque proof est vérifié sous une clé publique de Signer. Si une clé n’est utilisée que pour une personne ou une micro-cohorte, chaque présentation sous cette clé révèle déjà la cohorte. Aucune comparaison entre proof values n’est nécessaire.

Le découpage peut être involontaire : rotation régionale décalée, canary de vingt comptes, isolement d’incident, ancienne hiérarchie après une fusion. Il peut aussi être hostile : un Issuer montre une vue de clés différente à quelques titulaires et obtient un marquage silencieux.

Le reçu doit inclure la clé et son identifiant, le canal de publication, les dates d’activation et de retrait, la population prévue, la population observée et un mécanisme de cohérence. Les travaux de key consistency mentionnés par le projet proposent une direction ; l’obligation fondamentale reste de démontrer qu’Holder et Verifier n’ont pas reçu des vues sélectivement fragmentées.

Une clé mondiale agrandit l’ensemble d’anonymat mais le rayon d’impact d’une compromission. Une hiérarchie facilite l’exploitation mais crée de plus petites classes. Il n’existe pas de topologie universelle : il faut nommer le compromis, mesurer le résultat et le réexaminer à chaque rotation.

Une donnée authentique peut être l’identifiant le plus efficace

Nom complet, numéro administratif, courriel ou téléphone peuvent être signés et volontairement divulgués. Répétés, ils relient immédiatement les présentations. Une combinaison rare de profession, petite ville et date précise peut produire le même effet.

Le schéma BBS garantit l’authenticité et l’intégrité des messages révélés ; il ne détermine pas ce dont un service a besoin. Finalité, proportionnalité, rétention et alternatives sont des décisions d’application. Demander la date de naissance exacte lorsque seul « majeur » est nécessaire consume le bénéfice sans enfreindre l’algorithme.

Des preuves d’appartenance ou d’intervalle peuvent réduire la divulgation, mais ce sont d’autres constructions, avec leurs paramètres et leurs propres reçus. BBS de base ne transforme pas spontanément un âge en seuil et ne prouve pas une non-révocation parce qu’un identifiant reste caché.

L’aléa appartient à la frontière de confidentialité

ProofGen requiert plusieurs scalaires indépendants, uniques à chaque appel et indiscernables d’une distribution uniforme. Réutilisation, prévisibilité ou relation connue peuvent révéler les messages cachés ou la signature. Une API peut encore renvoyer une preuve bien formée après la perte de confidentialité.

Le projet évoque aussi un canal d’exfiltration : un attaquant manipulant quelques bits de l’aléa peut encoder des données dans des preuves apparemment normales. Un générateur déterministe, amorcé une fois par une graine unique et uniforme, peut limiter ce canal dans certains environnements ; il ne supprime ni le besoin d’entropie sûre ni la garde de la graine.

Le dossier d’exécution doit identifier le générateur, le build de bibliothèque, l’origine de la graine, les tests de santé, les frontières de processus et de matériel, le comportement après fork ou restauration de snapshot, ainsi que la réaction aux échecs. « RNG système » est une assertion d’architecture, pas le reçu d’un appel précis.

Validation des clés, contrôles de sous-groupe, séparation de domaines, opérations résistantes aux canaux auxiliaires et prétraitement identique des messages restent des obligations séparées. Une fixture correcte peut coexister avec un contrôle omis ou une normalisation de texte différente selon la langue.

Les extensions voisines ne sont pas des propriétés implicites

Blind BBS Signatures est une extension distincte permettant de signer des messages du Holder cachés au Signer par un engagement. La divulgation sélective du BBS de base cache des messages au Verifier lors de la présentation ; elle ne prouve pas que l’Issuer les ignorait lors de l’émission.

BBS per Verifier Linkability ajoute un pseudonyme lié à un contexte. Il permet à un Verifier de reconnaître des retours tout en cherchant à empêcher la liaison entre contextes. BBS de base ne crée pas automatiquement ce pseudonyme stable.

La cryptosuite W3C bbs-2023 est un profil pour Verifiable Credentials : elle mappe pointeurs obligatoires et sélectifs, transformations de données et options de holder binding ou de pseudonyme. Une fiche d’achat doit séparer révision, ciphersuite, interface, extension et profil. « Supporte BBS » ne dit pas lesquels sont présents.

Le risque quantique sépare authenticité et secret

L’authenticité BBS dépend de la difficulté du logarithme discret et n’est pas post-quantique. Une machine quantique cryptographiquement pertinente pourrait retrouver la clé secrète et produire signatures et proofs pour des messages choisis.

Le projet affirme séparément que le masquage des messages non divulgués dans une preuve déjà créée est informationnel : même un adversaire illimité possédant le secret du Signer ne les extrait pas du proof. C’est une confidentialité durable de la preuve, pas une étiquette « quantum safe » pour tout le système.

La migration comporte donc deux calendriers. L’authenticité doit changer avant que la durée de valeur d’une décision rencontre la menace. Les anciens proofs peuvent conserver leur secret, tandis que leurs valeurs révélées, en-têtes, IP et journaux restent corrélables. Une rotation ne supprime aucune copie historique.

Construire un reçu pour l’interaction entière

La chaîne minimale distingue : version et ciphersuite ; provenance de clé ; cohérence de vue ; émission aveugle ou non ; header et taille de cohorte ; schéma, ordre et padding ; valeurs et indices révélés ; presentation header, nonce, audience et fraîcheur ; proof et verdict ; aléa ; parseur, sous-groupe et séparation de domaines ; métadonnées réseau et terminal ; état ou révocation ; règle locale ; autorisation ; action ; effet ; rétention ; migration.

Il n’est pas nécessaire de tout centraliser. Issuer, wallet, Verifier, application, sécurité et privacy conservent la décision qu’ils contrôlent, puis la relient par un identifiant de transaction borné et une horloge. Le principe de spécification initiale minimale de Lu Heng maintient le socle cryptographique à sa juste taille. La discipline des couches de réalité empêche un zéro de connaissance d’emprunter l’autorité d’une décision. La primauté du code exécuté demande quelles clé, configuration, RNG et chaîne de journaux ont réellement fonctionné.

La conclusion n’est pas que BBS protège mal. La promesse de la primitive est forte et soigneusement bornée. Le risque naît quand une organisation agrandit la phrase sans produire les reçus supplémentaires. La preuve peut être non corrélable ; son enveloppe peut encore nommer la personne.

Sources