Un passeport numérique de produit ne présente pas les mêmes informations à tout le monde. Une acheteuse voit les données publiques. Un réparateur ou un recycleur en voit davantage. Une autorité de surveillance du marché voit tout. Ce point est clarifié, et les normes européennes le stipulent désormais expressément.
La question intéressante est plus subtile : si quelqu’un a accès à des champs protégés au-delà des données publiques, peut-il alors prouver que ces champs-là, précisément, sont authentiques ? Ou doit-il se fier au fait que la plateforme les a correctement sélectionnés et transmis sans les modifier ?
Imaginez un notaire qui ne certifie pas la lettre dans son intégralité, mais chaque paragraphe séparément. Tout le monde reçoit la lettre publique. Ceux qui ont droit à davantage reçoivent les paragraphes supplémentaires, et chacun d’entre eux porte toujours le cachet du même notaire. C’est ainsi que nous avons conçu notre plateforme. Sur la plupart des plateformes, la réponse honnête à la question ci-dessus est : la confiance. Chez nous, elle est : la preuve, pour chaque champ ajouté uniquement au moment de la divulgation. Cet article explique pourquoi cette différence est importante et pourquoi nous avons choisi cette voie, plus complexe.
Tout le monde respecte la règle d’accès de la même manière
Lanorme EN 18239, norme européenne relative aux droits d’accès, à la sécurité et à la confidentialité dans le DPP, exige que l’accès soit contrôlé champ par champ : pour chaque champ, il existe une règle définissant qui est autorisé à le consulter. C’est une exigence justifiée, et elle n’est pas difficile à respecter. Nous avons détaillé le statut de ces normes dans notre article consacré aux normes harmonisées.
La méthode habituelle pour y parvenir consiste à utiliser un filtre sur le serveur. Le serveur identifie l’utilisateur qui effectue la requête, vérifie ce que cette personne est autorisée à voir et renvoie exactement cette partie de l’information. La norme n’exige rien de plus. Le lecteur doit avoir confiance dans le fait que le serveur a effectué une sélection honnête et n’a rien modifié en cours de route. Pour une fiche d’information publique, cela convient. Pour une valeur sur laquelle un recycleur base directement le prix d’une batterie d’occasion, cela demande beaucoup de confiance.
Il y a toutefois un hic dont la norme ne tient pas compte : l’extrait est fourni sans sceau.
La solution qui s’impose est de signer les données. Aux deux extrémités de l’échelle, une signature classique fonctionne bien : signer la vue publique, signer l’ensemble complet des données. Le fonctionnement détaillé est décrit dans la section « Signatures et certificats » du DPP. C’est au milieu que le système présente une faille. Une signature couvrant l’ensemble du document ne porte que sur les champs qui étaient présents au moment de la signature. Si l’on dévoile en plus un champ protégé à un lecteur autorisé, ce champ se trouve en dehors de l’ensemble signé et lui parvient sans protection. Personne ne signe à l’avance toutes les combinaisons possibles de « qui voit quoi », car le nombre de combinaisons explose. On en revient alors au filtre sans sceau, et le niveau intermédiaire repose à nouveau sur la confiance.
Signer chaque champ individuellement
Il existe une meilleure approche, et c’est sur celle-ci que nous construisons la plateforme. Au lieu de signer le document fini comme un bloc unique, le créateur définit chaque champ individuellement en une seule opération (pour les spécialistes des normes : la procédure W3C ecdsa-sd-2023).
Chaque vue commence ainsi par les mêmes champs publics. Ce qu’un lecteur voit en plus s’ajoute champ par champ, et chacun de ces champs renvoie toujours à la clé publique du fabricant, hors ligne, sans nouvelle signature et sans faire confiance à l’organisme qui a compilé la vue. Les champs non revendiqués sont tout simplement absents. Ils ne sont pas masqués, mais n’existent tout simplement pas, et aucune information à leur sujet ne transparaît.
Un cycle : l’atelier de réparation
Un atelier de réparation a déclaré un intérêt légitime pour une batterie, l’un des niveaux d’accès expressément prévus par le règlement sur les batteries. Son système d’atelier se connecte à notre interface à l’aide de sa clé et récupère le passeport. La réponse est le même passeport public que celui que voit l’acheteuse, enrichi d’un champ supplémentaire : les instructions de démontage, qui ne sont divulguées qu’aux lecteurs autorisés. Pas de deuxième document, pas de version spéciale.
Avant que l’entreprise ne se fie à ce champ, son logiciel vérifie la signature fournie à l’aide de la clé publique du fabricant. Si la vérification de la signature aboutit, y compris pour ce champ supplémentaire, elle sait alors que ce mode d’emploi provient à la lettre du fabricant et que personne n’y a apporté de modification en cours de route. Si la vérification échoue, il met de côté l’ensemble du document. C’est à notre système de contrôle d’accès que revient la tâche de veiller à ce qu’il reçoive exactement les champs auxquels il a droit. La nouveauté réside dans l’étape suivante : c’est lui-même qui vérifie l’authenticité des données reçues, sans nous consulter.
Pourquoi l’« intégrité » est-elle si importante?
Un sceau intact ne garantit pas que le contenu soit authentique. Il indique : c’est exactement ce qu’a écrit le créateur, et depuis, personne n’y a modifié le moindre caractère. Ainsi, tous ceux qui se sont contentés de transmettre le document sont écartés de la question de la confiance : le cache, le réseau, les archives, nous.
Peu importe désormais qui vous a remis ce passeport.
Et un sceau est binaire. Soit il tient, soit il ne tient pas ; il n’existe pas de sceau à moitié brisé. C’est pourquoi le fait que les champs supplémentaires vous parviennent avec ou sans leur sceau ne constitue pas une différence graduelle : sans sceau, ils ne sont pas simplement un peu moins validés, ils ne le sont pas du tout.
Les deux méthodes de consultation
Chacun peut le vérifier par lui-même. L’ Transpareo Time Machine voici notre application open source de visualisation des passeports produits : elle parcourt l’historique des versions d’un passeport produit et recalcule chaque signature dans le navigateur de l’utilisateur, sans interroger l’un de nos serveurs. Le passeport d’un t-shirt comporte une signature couvrant l’ensemble du document, tandis que celui d’une batterie comporte une validation champ par champ.
Il s’agit dans les deux cas de normes W3C ouvertes, que tout le monde peut mettre en œuvre. La signature portant sur l’ensemble du document est nettement moins coûteuse à mettre en place et à gérer, et elle suffit à ceux qui ne fournissent que des données publiques. Le fait que le « Transpareo Time Machine » maîtrise les deux procédures est intentionnel : le Pass reste un format standard classique que tout outil adapté peut vérifier, et pas seulement le nôtre.
À qui cela profite-t-il, et qu’exige la norme?
À## qui, au-delà des données publiques, des informations sont-elles réellement divulguées ? Pas à la cliente occasionnelle. Ce sont les professionnels du traitement des déchets qui évaluent la valeur d’un bloc-batterie usagé, l’assureur qui évalue un risque, le recycleur qui trie les composants chimiques, l’autorité qui monte un dossier. Des lecteurs dont les décisions ont des implications financières ou de sécurité. Et, dans l’approche habituelle, ce sont précisément ces lecteurs qui n’obtiennent pas de label pour les champs sur lesquels repose leur décision. Nous estimons qu’un label de conformité devrait avoir la même signification pour tous : chaque champ affiché provient du fabricant et n’a pas été modifié depuis. Un label qui ne s’applique qu’aux champs publics n’est qu’un demi-label.
Nous le disons sans détour : rien de tout cela n’est obligatoire. La norme EN 18239 exige que l’accès soit contrôlé, et un filtre sur le serveur le fait parfaitement. Rendre les champs divulgués vérifiables est une mesure supplémentaire que nous prenons, car tout l’intérêt d’un passeport signé réside dans le fait que personne ne doit avoir à faire confiance à la plateforme. Exclure le niveau intermédiaire en tant qu’exception rétablit précisément la confiance que la signature était censée éliminer.
Ce même principe permet d’oublier un champ
Se prononcer sur chaque champ individuellement implique une deuxième caractéristique, et celle-ci est en effet exigée par le droit européen. Le Règlement général sur la protection des données confère aux personnes le droit de faire supprimer leurs données à caractère personnel. Un ensemble de données signé en bloc ne peut pas se conformer à cette exigence sans détruire sa propre signature.
Comme chaque champ est ici indépendant, il est possible de supprimer un champ isolé, tandis que tout le reste reste valide. Si des données à caractère personnel se retrouvent par inadvertance dans un passeport, elles en sont retirées sans problème et le passeport reste valide : pas de réémission, pas d’historique interrompu. Les champs que la loi exige de conserver restent en place ; ce qui peut être supprimé peut l’être sur demande, même des années plus tard.
Pourquoi cela est-il difficile, et comment y avons-nous remédié?
Nous n’avons pas inventé ce procédé ; il s’agit d’une norme publique du W3C. Ce n’est pas difficile d’avoir l’idée. Ce qui est difficile, c’est de la mettre en œuvre de manière à ce qu’un passeport soit toujours valide dans dix ans. Une signature classique porte sur les octets d’un document. La signature champ par champ porte quant à elle sur chacune de ses données ; pour cela, le passeport est mis, avant la signature, sous une forme fixe dans laquelle chaque donnée apparaît comme une phrase distincte. Ce format doit pouvoir être reproduit caractère par caractère dans dix ans, sinon aucun sceau ne correspondra plus. Trois éléments anodins font obstacle à cela, et nous les avons tous les trois éliminés à la source.
Les nombres perdent leur type. Une valeur telle que 2,0 revient sous la forme 2 après être passée par un format de données classique. Pour un humain, c’est la même chose ; pour la notation fixe, il s’agit d’une phrase différente. Chez nous, chaque valeur est enregistrée avec son type, et la publication s’interrompt dès qu’un seul nombre sans type apparaît.
Les désignations ne constituent pas encore une signification. Chaque nom de champ doit renvoyer à une signification unique dans un dictionnaire, sinon le champ disparaît silencieusement lors de la conversion et le sceau ne le recouvre pas. Chez nous, chaque dictionnaire est disponible localement et n’est jamais récupéré via le réseau ; un nom de champ inconnu interrompt la signature, au lieu de renvoyer silencieusement un résultat vide.
Les entrées doivent avoir des noms fixes. Chez nous, chaque entrée du document porte un identifiant fixe, afin que la syntaxe reste la même à chaque passage, au lieu d’attribuer à chaque fois de nouveaux noms auxiliaires.
La partie la plus délicate concerne la clé propre au fabricant. Pour chaque émission, une clé supplémentaire à durée de vie limitée est nécessaire, avec laquelle les champs pouvant être divulgués sont signés individuellement. C’est le fabricant lui-même qui génère et supprime cette clé. Si elle se trouvait en notre possession, nous pourrions inventer des champs individuels a posteriori. Chaque passeport porte deux de ces sceaux : l’un du fabricant et l’autre de Transpareo, même pour un champ divulgué isolément.
Pour nous, cet effort est justifié. Grâce à l’ Transpareo Proofchain, chaque passeport est signé lors de sa publication et lié à la version précédente, et l’ Transpareo Vault, cette archive inaltérable sur dix ans, entre en vigueur dès que les passeports sont enregistrés auprès du registre de l’UE. Le fait de signer chaque champ plutôt que le bloc entier constitue une extension de ce noyau, et non un simple ajout.
Où en sommes-nous ?
Nous avons opté pour la preuve, pour chaque lecteur, car un sceau doit avoir la même signification, quelle que soit la personne qui le consulte. Si vous souhaitez voir comment cela fonctionne : les deux exemples de passeports dont les liens figurent ci-dessus peuvent être vérifiés directement dans le navigateur, sans passer par un serveur.
Questions concernant cet article
Une norme impose-t-elle la signature champ par champ ?
Non. La norme européenne EN 18239 relative aux droits d’accès dans le DPP exige que l’accès soit contrôlé champ par champ, et un filtre sur le serveur répond pleinement à cette exigence. Le fait de rendre vérifiables les champs divulgués au-delà de cette exigence relève de notre décision et ne constitue pas une condition imposée par la réglementation. Nous estimons que cet effort est justifié, car tout l’intérêt d’un passeport signé réside dans le fait que personne ne doit avoir à faire confiance à la plateforme. Le statut exact de ces normes est précisé dans notre article consacré aux normes harmonisées.
Nous ne publions que des données publiques. Est-ce nécessaire ?
Probablement pas, et nous le disons clairement. Une signature couvrant l’ensemble du document englobe un passeport dont tous les champs sont publics, et elle est nettement moins coûteuse à mettre en place et à gérer. La validation champ par champ s’avère utile dès qu’un deuxième groupe cible entre en jeu, par exemple un réseau de réparation, un recycleur ou une administration à qui vous remettriez autrement des extraits sans cachet. Ces deux procédés sont des normes W3C ouvertes (ecdsa-sd-2023 pour la signature champ par champ) ; tout outil prenant en charge cette norme peut les vérifier, et les deux fonctionnent aujourd’hui dans la Transpareo Time Machine, sur le « passeport » d’un t-shirt et sur celui d’une batterie.
Est-il possible de faire supprimer ultérieurement les données à caractère personnel sans invalider le passeport ?
Oui, et cet aspect est effectivement exigé par le droit européen. Le Règlement général sur la protection des données confère aux personnes le droit de faire effacer leurs données à caractère personnel, et un enregistrement signé sous forme de bloc ne peut pas satisfaire à cette exigence sans détruire sa propre signature. Comme chaque champ est ici défini individuellement, il est possible de supprimer un seul champ, tandis que tous les autres continuent de valider les données, sans qu’il soit nécessaire de réémettre le document et sans interrompre l’historique des versions. Les champs que la loi exige de conserver restent en place.
Qui détient la clé de signature ?
Chaque passeport comporte deux cachets, dont l’un peut être le vôtre. Chaque délivrance nécessite en outre une clé à durée de vie limitée qui signe individuellement les champs pouvant être divulgués ; c’est le fabricant lui-même qui génère et supprime cette clé, car si elle se trouvait entre nos mains, nous pourrions inventer certains champs a posteriori. Nous vérifions le sceau renvoyé à l’aide de la clé publique enregistrée avant de lui accorder notre confiance. Chaque passeport comporte ainsi deux sceaux provenant de deux organismes indépendants, tant pour un champ divulgué individuellement que pour l’ensemble des données.
Un passeport sera-t-il encore valable dans dix ans ?
C’est précisément là que réside la difficulté. La signature champ par champ s’appuie sur les informations individuelles d’un document plutôt que sur ses octets ; ce format fixe doit donc être reproduit, caractère par caractère, une décennie plus tard. Trois éléments viennent perturber ce processus, et nous les avons tous trois éliminés à la source. Chaque valeur est enregistrée avec son type, chaque dictionnaire est stocké chez nous et n’est jamais récupéré via le réseau, et chaque entrée porte un identifiant fixe. L’archive inaltérable sur dix ans est mise en place et entre en vigueur dès que les passeports sont enregistrés auprès du registre de l’UE. Pour en savoir plus, consultez notre analyse du règlement sur le registre.
