Ce que CardanoWall peut voir (et ce qu'il ne peut pas voir)

CardanoWall voit les données de service ordinaires et les records de preuve publics que vous publiez. Par conception, il ne voit pas votre graine d'identité en clair, vos clés privées, ni le texte en clair d'un fichier que vous scellez. Les éléments les plus sensibles sont conservés et utilisés sur votre appareil, pas sur nos serveurs.

Voilà la version honnête du modèle de confidentialité. CardanoWall est un produit hébergé construit sur un gateway ; il a donc réellement besoin de données de compte, de facturation, de publication et d'indexation pour fonctionner. La vraie question n'est pas « est-ce que CardanoWall voit quelque chose ? » — oui, il en voit. La vraie question, c'est quel type de données il voit, et ce qui reste chiffré pour nous.

Cet article parcourt cette ligne de démarcation, catégorie par catégorie.

Quelles données de compte CardanoWall conserve-t-il ?

Des données ordinaires de service hébergé. Selon votre usage du produit, cela peut inclure :

votre identifiant de compte ;
des identifiants de connexion comme une adresse e-mail ou la référence d'un compte OAuth lié ;
les enregistrements de facturation et votre solde prépayé ;
les métadonnées des clés d'API et la forme hachée des clés d'API (jamais la clé en clair) ;
les références du prestataire de paiement pour les rechargements ;
les réglages au niveau du compte ;
les horodatages des actions sur le compte ;
les métadonnées de support et d'exploitation ;
les journaux de limitation de débit et de sécurité.

C'est la même forme de données que détient n'importe quel service basé sur des comptes. Rien là-dedans n'est votre graine d'identité.

Quelles données d'identité peut-il voir ?

Les clés publiques d'identité — et rien de privé.

Dans CardanoWall, une identité dérive de façon déterministe d'une seule graine d'identité de 32 octets, et ce sont les clés publiques de cette identité dont le service a besoin pour faire son travail : lister votre identité, compter ses preuves signées, lier une identité à votre compte après une vérification de possession, et afficher un profil public lorsque vous choisissez d'en publier un.

Le service peut donc voir des données d'identité publiques telles que :

la clé publique de signature Ed25519 ;
la clé publique de réception X25519 ;
la clé publique de réception hybride post-quantique facultative ;
la date de création de l'identité dans la base de données du service ;
l'état de liaison entre un compte et une identité ;
tous les champs de profil public que vous activez.

Ce sont des faits publics ou de niveau service. Ce ne sont pas la clé privée de signature ni la clé privée de réception, et ils ne peuvent pas être reconvertis en votre graine.

Qu'est-ce que le serveur n'a jamais besoin de voir ?

Tout ce qui lui permettrait d'agir à votre place. Le serveur n'a pas besoin de détenir, et il est conçu pour ne pas détenir sous une forme exploitable :

les graines d'identité en clair ;
les clés privées de signature Ed25519 ;
les clés privées de réception X25519 ;
les secrets de réception hybrides (post-quantiques) ;
les éléments de déverrouillage produits par votre passkey ;
le contenu déchiffré de votre coffre d'identité ;
le texte en clair déchiffré d'un fichier scellé.

Tout cela vit sur votre appareil après votre déverrouillage, ou dans des sauvegardes que vous contrôlez. La copie portable et canonique d'une identité, c'est sa graine — c'est cet artefact-là, et non la couche de confort hébergée, qui constitue la véritable sauvegarde.

Qu'est-ce que le coffre chiffré révèle au serveur ?

Son existence — et bien peu d'autre.

Pour vous permettre de déverrouiller sur un nouvel appareil avec un passkey, CardanoWall stocke une ligne de coffre chiffré courante par compte. Le serveur peut lire les métadonnées de la ligne — sa dernière mise à jour, son numéro de version, et les passkeys enregistrés qui lui sont associés — parce qu'il en a besoin pour l'expérience de déverrouillage et la gestion du cycle de vie.

Ce que le serveur ne peut pas faire, c'est déchiffrer le coffre. Le coffre est un unique texte chiffré de style age adressé exclusivement à vos facteurs de déverrouillage par passkey WebAuthn (stanzas PRF). Il n'existe délibérément aucun chemin de déverrouillage dérivé d'un mot de passe ni aucun destinataire à clé publique ajouté, de sorte que le texte chiffré stocké n'expose rien que le serveur pourrait attaquer hors ligne. C'est un confort de la couche service, pas de la conservation : nous détenons la boîte verrouillée, vos passkeys détiennent les seules clés.

Le texte en clair du coffre contient vos graines d'identité et vos étiquettes d'affichage privées — précisément les éléments qui ne doivent jamais être lisibles par le serveur. La même conception régit aussi la révocation : retirer un passkey rechiffre le coffre vers vos facteurs restants et supprime définitivement le texte chiffré précédent, si bien que l'authentificateur retiré ne peut plus ouvrir le coffre courant. C'est une véritable révocation pour l'état actuel, mais elle n'est pas rétroactive — une copie qu'un attaquant aurait déjà exfiltrée et qu'il pourrait encore ouvrir est un problème distinct. Comment les passkeys protègent votre coffre d'identité approfondit ce point.

Quelles données de preuve sont publiques ?

La preuve elle-même. Les records Label 309 sont publiés sur Cardano précisément pour que quiconque dispose de la référence de transaction puisse les vérifier. Selon le record, les données publiques peuvent inclure :

les empreintes du contenu ;
la référence de transaction ;
l'heure de bloc attribuée par la chaîne ;
la structure du record ;
les signatures et les clés publiques de signataires, lorsque l'auteur a choisi de signer ;
les racines de Merkle, pour les records regroupés ;
les métadonnées d'enveloppe chiffrée ;
les URI de stockage adressé par le contenu (ar://, ipfs://) ;
le nombre d'emplacements de destinataires chiffrés ;
la famille d'échange de clés utilisée pour un record scellé.

Ces données sont publiques à dessein : c'est ce qui rend une preuve vérifiable sans faire confiance à CardanoWall. Pour un record scellé, notez ce qui ne s'y trouve pas — le texte en clair du fichier ne va jamais sur la chaîne. Un observateur peut voir qu'un record est scellé, combien d'emplacements de destinataires il comporte, et quelle famille d'échange de clés il utilise, mais ni l'identité des destinataires ni le contenu.

Que peuvent voir les gateways de stockage ?

Les octets stockés et les métadonnées de requête.

Si un record pointe vers du contenu sur Arweave ou IPFS, les gateways publics qui servent ces octets peuvent voir les requêtes qui les concernent. Pour un fichier public, ces octets sont en clair. Pour un fichier scellé, ces octets sont du texte chiffré, et ils doivent rester illisibles sans la clé privée du destinataire.

Les gateways peuvent aussi observer le moment des requêtes, la taille des objets et leurs schémas récurrents. Ce n'est pas un endroit où placer sa confiance pour la confidentialité. C'est précisément la raison de sceller un fichier sensible avant qu'il parte vers le stockage, plutôt que de compter sur la couche de stockage pour le garder privé.

Que peut voir le navigateur pendant que vous êtes déverrouillé ?

Tout ce dont il a besoin pour agir au nom de votre identité — aussi longtemps que la session reste déverrouillée.

Après votre déverrouillage, vos graines d'identité et les clés privées qui en dérivent vivent dans la mémoire de session de votre navigateur pour que l'application puisse signer et déchiffrer. Lorsque vous déchiffrez un fichier scellé, le texte en clair se trouve lui aussi dans le navigateur. Au verrouillage ou à la déconnexion, ces données en mémoire sont remises à zéro dans la mesure du possible.

C'est de la confidentialité côté client, et elle est honnête sur ses limites. Garder les secrets sur votre appareil vous protège de la conservation par le serveur, mais cela signifie que votre appareil et votre environnement de navigateur comptent. Une extension de navigateur malveillante, un logiciel local hostile ou une faille de cross-site-scripting active pendant une session déverrouillée peuvent lire ce qui se trouve en mémoire. Des en-têtes de sécurité de contenu stricts, un flux de déverrouillage à script minimal et un déverrouillage déclenché uniquement sur action explicite réduisent tous cette exposition — mais ils ne peuvent pas l'éliminer. Pour les identités sensibles, utilisez un appareil de confiance ; stockage du navigateur et clés de session explique précisément ce qui est mis en cache et ce qui ne l'est pas.

Que peut révéler le carnet d'adresses ?

Votre liste de contacts est une donnée de service, et elle peut être sensible à sa manière.

Les contacts de confiance sont des entrées locales au compte qui vous évitent de coller de longues clés publiques chaque fois que vous scellez un fichier à destination de quelqu'un. Une entrée peut contenir un nom d'affichage, une clé publique de signature, des adresses de réception facultatives (classiques et post-quantiques), comment et quand vous avez vérifié le contact, et des notes libres.

Ce ne sont pas des graines d'identité, mais une liste des personnes avec qui vous correspondez peut révéler des relations et des manières de travailler. La journalisation de CardanoWall est écrite pour garder cela discret : les actions côté serveur qui créent et modifient des contacts n'enregistrent qu'un identifiant de requête et votre identifiant de compte — jamais le nom du contact, ses clés, ses notes ou sa méthode de vérification.

Que CardanoWall ne promet-il pas ?

Il ne promet pas l'invisibilité.

CardanoWall n'est pas un réseau d'anonymat. La blockchain, les gateways de stockage, le système de paiement, votre connexion au compte, votre navigateur et votre chemin réseau peuvent tous exposer des métadonnées. Publier un record scellé non signé maintient l'expéditeur, les destinataires et le texte en clair hors du record Label 309 lui-même — mais c'est de la confidentialité au niveau du record, pas un anonymat complet. L'adresse Cardano qui règle les frais, votre IP telle que la voient les gateways et les signaux du même ordre vivent en dehors du record et en dehors de cette garantie.

Il ne rend pas non plus sûr un appareil compromis. Si votre session déverrouillée exécute du code malveillant, ce code peut voir ce que vous voyez.

Et une preuve publiée est publique par conception. Elle montre que des octets précis existaient avant un instant public précis. Elle ne prouve pas, à elle seule, qui les a créés, à qui ils appartiennent, ni que leur contenu est vrai — voir ce qu'une preuve ne prouve pas pour cette limite.

La version courte

CardanoWall voit les données de service et les données de preuve publiques. Par conception, il ne voit pas votre graine d'identité en clair, vos clés privées, le texte en clair de votre coffre, ni le texte en clair d'un fichier scellé.

Donc, en pratique : scellez les fichiers sensibles avant qu'ils ne quittent votre appareil, gardez une copie sûre de votre graine, déverrouillez sur des appareils de confiance, et traitez tout ce que vous publiez sur la chaîne comme définitivement public.

Une bonne confidentialité commence par savoir exactement où vit chaque type de donnée — et CardanoWall est conçu pour que les données qui comptent le plus vivent avec vous.

Pour aller plus loin

CardanoWall est l'implémentation de référence de Label 309, un standard de preuve d'existence ouvert et indépendant des fournisseurs. Le standard a été soumis au processus CIP de Cardano et est en cours d'examen par les éditeurs CIP en tant que proposition de catégorie Metadata (pull request ouverte). Le cœur cryptographique, les SDK et les outils en ligne de commande sont open source sur github.com/cardanowall, de sorte que vous pouvez auditer exactement ce qui est calculé sur votre appareil plutôt que de nous croire sur parole.