Pourquoi vos clés ne quittent jamais l'appareil

Dans CardanoWall, vos clés privées restent sur votre appareil. Le logiciel qui signe, scelle, déchiffre à l'essai et vérifie s'exécute localement ; le gateway hébergé est conçu pour ne jamais recevoir votre graine d'identité, votre clé de signature, vos clés de destinataire, ni le matériel qui déchiffre un fichier scellé.

Le gateway a déjà beaucoup à faire sans ces secrets. Il peut établir un devis, accepter du texte chiffré déjà prêt pour le stockage, soumettre une transaction Cardano, indexer des records et suivre votre solde. Rien de tout cela n'exige les clés qui prouvent la paternité ou qui ouvrent un contenu scellé. La séparation est délibérée : le service aide à déplacer la preuve, et vous gardez les secrets.

De quelles clés parle-t-on ?

Une identité Label 309 part d'une seule valeur : une graine d'identité de 32 octets. À partir de cette graine, tout logiciel conforme dérive les clés qu'une identité utilise réellement, dans trois rôles :

une clé Ed25519 qui signe les records ;
une clé X25519 qui reçoit les records scellés de façon classique ;
une clé hybride post-quantique qui reçoit les records scellés de façon post-quantique.

La dérivation est déterministe. Les mêmes 32 octets produisent toujours les trois mêmes paires de clés, dans n'importe quel client conforme. C'est ce qui rend la graine portable — et c'est ce qui en fait la seule chose à protéger. Quiconque détient la graine peut restaurer l'identité, signer en son nom et déchiffrer les records scellés qui lui sont adressés. La graine reste donc privée, et tout le reste en découle.

Que fait le client localement ?

Le client prend en charge chaque opération qui touche une clé privée :

générer ou importer une graine d'identité ;
en dériver les clés de signature et de réception ;
signer les records ;
chiffrer les fichiers avant l'envoi ;
construire les emplacements de destinataire scellés qui enveloppent une clé de contenu ;
déchiffrer à l'essai les records entrants pour repérer ceux qui vous sont adressés ;
déchiffrer le texte chiffré et recalculer l'empreinte du texte en clair ;
vérifier les signatures et la structure des records.

L'application web, l'application de bureau, l'outil en ligne de commande et tout logiciel bâti sur les SDK diffèrent par la façon dont ils stockent les clés et par la manière dont ils les déverrouillent. Le principe, lui, ne change pas : le matériel de clé privée n'est pas envoyé au gateway.

Que fait alors le gateway ?

Le gateway exécute le pipeline de publication. Il peut :

calculer un devis ;
recevoir du texte chiffré déjà prêt et renvoyer une URI adressée par le contenu ;
accepter un record de preuve préparé ;
soumettre une transaction Cardano et attendre la confirmation ;
gérer les réorganisations de la chaîne et rembourser automatiquement si une publication échoue définitivement ;
indexer les records dans un flux partagé ;
suivre le solde de votre compte ;
exposer son API et émettre les événements de cycle de vie.

Ce sont de vraies tâches, et elles représentent l'essentiel du travail opérationnel. Mais aucune d'elles n'a besoin d'une clé capable de déchiffrer votre contenu scellé. Le gateway est une couche de transport et d'exploitation. Ce n'est pas votre coffre d'identité, et il n'est pas conçu pour s'y substituer.

Pourquoi cette séparation est-elle importante ?

Parce qu'une preuve doit rester vérifiable sans avoir à faire confiance au service qui a aidé à la créer.

Si un service hébergé détenait l'unique copie de vos clés, ce service deviendrait votre racine de confiance. S'il fermait, modifiait ses conditions, subissait une compromission ou verrouillait votre compte, votre capacité à signer, à déchiffrer, voire à seulement vérifier, en dépendrait. C'est précisément la situation que Label 309 est conçu pour éviter.

Un record Label 309 est vérifiable à partir de données publiques. Un vérificateur n'a besoin que des métadonnées de la transaction, éventuellement des octets du contenu, et d'un explorateur Cardano public — aucun serveur d'émetteur à aucune étape. Un record scellé peut être ouvert par le détenteur de la clé. Un record signé peut être contrôlé face à sa clé de signature. Le gateway peut rendre la publication bien plus simple, mais, par conception, il ne peut pas lire un contenu correctement scellé sous prétexte qu'il a aidé à l'inscrire sur la chaîne.

Voilà toute la différence entre un service qui vous affirme détenir une preuve et une preuve qui se suffit à elle-même.

Le gateway peut-il lire mes fichiers scellés ?

Si le client a correctement scellé le contenu, non — le gateway ne voit jamais que du texte chiffré.

Voici comment se présente un record scellé. Le record public inscrit sur la chaîne s'engage sur l'empreinte du texte en clair — cette empreinte, conjuguée à l'horodatage du bloc, constitue la preuve de datation. La charge utile chiffrée elle-même ne va jamais sur la chaîne ; elle réside à une URI adressée par le contenu (telle que ar://). La clé de contenu est enveloppée vers une ou plusieurs clés publiques de destinataire, à raison d'un emplacement par destinataire. Le destinataire (ou l'expéditeur) récupère le texte chiffré, le déchiffre localement et recalcule l'empreinte du texte en clair pour confirmer qu'elle correspond à l'engagement inscrit sur la chaîne.

Le gateway peut constater qu'un record scellé existe, et il peut observer la taille du texte chiffré, le moment de l'envoi, l'activité du compte, le statut de la transaction et les métadonnées publiques. Il n'est pas conçu pour voir le texte en clair, et sans la bonne clé privée, le texte chiffré reste illisible. Deux réserves honnêtes accompagnent ce constat : le scellement protège la confidentialité, pas l'anonymat — des métadonnées observables restent des métadonnées — et un destinataire qui déchiffre un fichier peut toujours choisir d'en divulguer ensuite le texte en clair. Le chiffrement protège les octets en transit et au repos, pas ce qu'un lecteur autorisé en fait ensuite.

Le gateway peut-il falsifier une preuve valide ?

Il est conçu de telle sorte qu'il ne puisse pas faire passer une preuve invalide à une vérification indépendante.

Un vérificateur contrôle le record sur la chaîne, la structure du record, les empreintes, les signatures et — pour un record scellé qu'il peut ouvrir — l'empreinte recalculée du texte en clair. Si un gateway mentait sur une transaction, modifiait les octets du record, supprimait une signature ou pointait vers des octets ne correspondant pas à l'empreinte engagée, un vérificateur indépendant devrait le détecter.

C'est une promesse précise, et il ne faut pas la surévaluer. Un gateway peut malgré tout mal se comporter de façon purement opérationnelle : il peut échouer à publier, retarder une transaction, renvoyer une erreur, rapporter son propre statut de manière inexacte, subir une panne ou offrir une mauvaise expérience. Ce qu'il ne devrait pas pouvoir faire, c'est transformer une preuve invalide en une preuve qui se vérifie proprement face à des données publiques. Le confort peut faire défaut ; la revendication cryptographique, elle, ne dépend pas de l'honnêteté du gateway.

Et l'application web en particulier ?

L'application web est un logiciel qui s'exécute dans un navigateur, et cela façonne son modèle de confiance.

La frontière pertinente englobe le navigateur, le code applicatif qui se charge, les extensions éventuellement installées, l'appareil lui-même et le flux de déverrouillage. Un navigateur est commode, mais ce n'est pas le même environnement qu'un coffre de bureau ou qu'un outil en ligne de commande lancé à partir d'un build que vous contrôlez. Un script malveillant présent dans une session déverrouillée peut lire les secrets en mémoire ; une politique de sécurité du contenu stricte, un minimum de scripts et une étape de déverrouillage explicite réduisent cette exposition, mais aucune application web ne peut prétendre l'éliminer.

C'est l'une des raisons pour lesquelles un client de bureau dédié existe, à destination de celles et ceux qui veulent un stockage local et un contrôle plus serré sur la manière dont les clés sont détenues. L'invariant tient pour chaque client — le gateway n'a pas besoin de vos clés privées — même si chaque client protège ces clés différemment. Pour un exposé plus complet de l'endroit où passe la ligne, voir ce que CardanoWall peut et ne peut pas voir.

Et l'application de bureau ?

CardanoWall Desktop est une application open source, multiplateforme, bâtie dès le départ autour d'un coffre chiffré local.

Un cœur Rust détient le coffre d'identité, la cryptographie, le moteur de synchronisation, le déchiffrement à l'essai et la vérification, tandis qu'une webview se contente d'afficher l'interface. Les graines et les clés privées dérivées ne sont pas remises à la webview sous forme de chaînes JavaScript ordinaires ; lorsqu'un contenu doit être prévisualisé, les octets déchiffrés sont diffusés vers la vue par un canal dédié plutôt que de transiter par la page en tant que chaîne. Les secrets ne sont pas envoyés au gateway, et ils ne franchissent pas la frontière du moteur de rendu.

Cette architecture réduit la surface d'attaque ; elle ne l'efface pas. Un système d'exploitation compromis, une dépendance malveillante, un enregistreur de frappe ou un logiciel malveillant approuvé par l'utilisateur peuvent toujours mettre en échec la sécurité locale — la même limite honnête que porte n'importe quel portefeuille de bureau. Garder les clés hors du gateway et hors du moteur de rendu est une amélioration réelle, pas une garantie contre un hôte entièrement compromis. Pour le détail de son fonctionnement, voir la présentation de CardanoWall Desktop et des preuves hors ligne.

Et l'outil en ligne de commande et les SDK ?

Ils comptent parce qu'ils rendent le même modèle disponible sans passer par le site web.

Un développeur peut conserver une graine localement, signer des records localement, sceller des fichiers localement et soumettre via n'importe quel gateway. Un système d'intégration continue peut publier avec des identifiants d'API restreints tout en gardant le matériel d'identité sous les propres contrôles de l'équipe. Une entreprise peut bâtir son propre client ou intégrer Label 309 à un logiciel existant. La répartition reste la même quelle que soit l'interface choisie : le gateway publie, le client garde les secrets.

L'outil en ligne de commande et les SDK sont open source et indépendants du gateway, si bien que la frontière est une chose que vous pouvez inspecter plutôt qu'une chose à accepter sur parole.

Que ne faut-il jamais envoyer à un gateway ?

N'envoyez jamais ceci à un gateway — ni à aucun site web :

votre graine d'identité L309-SEED-1… ;
la graine brute en hexadécimal ;
une clé privée de signature ;
une clé privée de réception X25519 ;
un secret de réception hybride post-quantique ;
une phrase secrète qui déchiffre du contenu scellé ;
du texte en clair que vous vouliez garder privé.

Le gateway peut légitimement avoir besoin de clés publiques, de signatures publiques, des octets publics du record, de texte chiffré, d'identifiants de devis, de jetons d'API et d'identifiants de compte. Rien de tout cela n'est du matériel d'identité privé. La règle est simple : si un processus vous demande de coller un secret quelque part, arrêtez-vous et demandez-vous pourquoi.

Qu'est-ce qui requiert encore votre vigilance ?

Des clés locales ne sont jamais plus sûres que l'environnement qui les entoure. La cryptographie tient un gateway à l'écart de vos secrets ; elle ne peut pas protéger une graine qu'un utilisateur recopie dans un formulaire contrôlé par un attaquant. Vous devez donc encore :

protéger votre graine d'identité et en conserver une véritable sauvegarde ;
vérifier l'adresse de réception d'un destinataire avant de sceller quoi que ce soit de sensible ;
éviter les sites d'hameçonnage ;
être attentif au choix des extensions de navigateur ;
maintenir vos appareils à jour ;
utiliser le chiffrement de disque lorsque c'est pertinent ;
comprendre comment les fichiers déchiffrés sont mis en cache ;
exécuter des builds de confiance des outils de bureau et en ligne de commande ;
définir des politiques de gestion des clés pour les usages partagés ou en équipe.

Il vaut la peine d'être direct sur les modes de défaillance, car ils ne sont pas symétriques. Perdez la graine et vos facteurs de déverrouillage, et tout usage futur de cette identité disparaît — même si les preuves que vous avez déjà publiées restent vérifiables, pour toujours, à partir de données publiques. Une graine volée est une compromission totale de l'identité : la réponse consiste à créer une nouvelle identité et à désactiver l'ancienne, pas à réinitialiser un mot de passe. Il n'y a pas de réinitialisation ; c'est le prix de l'absence de dépositaire.

Pourquoi cela compte pour un standard ouvert

Un standard ouvert de preuve ne devrait pas dépendre d'un unique opérateur de confiance.

Si CardanoWall disparaissait demain, un record Label 309 devrait conserver tout son sens. Si une entreprise exploite son propre gateway, ses records devraient rester conformes au standard. Si vous exportez votre graine vers un autre client conforme, il devrait dériver exactement les mêmes clés. Cela ne fonctionne que si la frontière reste nette : les records sont standard, la vérification est indépendante, les gateways sont remplaçables, les clients gardent les secrets, et vous pouvez toujours sauvegarder vous-même la racine de votre identité.

Ainsi, « les clés ne quittent jamais l'appareil » n'est pas un slogan. C'est l'un des éléments qui rendent une preuve d'existence portable — une preuve que vous pouvez emporter au-delà de tout service unique, celui-ci compris.

En bref

Le gateway aide à publier la preuve. Le client garde les secrets.

Les clés privées ne sont pas envoyées au gateway. Le contenu est chiffré avant l'envoi. Le déchiffrement se déroule localement. La vérification ne dépend pas de la parole d'un service. C'est la forme de sécurité sur laquelle CardanoWall est bâti — et celle que Label 309 est conçu pour garder ouverte.

Pour aller plus loin

Votre identité est une graine — ce qu'est la graine d'identité et pourquoi elle constitue la véritable sauvegarde.
Comment CardanoWall stocke votre identité — le coffre chiffré et ce que le serveur peut et ne peut pas déchiffrer.
Ce qu'une preuve ne prouve pas — les limites honnêtes des preuves de datation et d'intégrité.
Le standard Label 309 sur label309.org, soumis au processus CIP de Cardano et en cours d'examen par les éditeurs CIP.
Les clients, SDK et gateway open source sur github.com/cardanowall.