Comment CardanoWall stocke votre identité

CardanoWall ne stocke jamais votre graine d'identité en clair. Le serveur détient un coffre chiffré que seuls vos propres passkeys peuvent ouvrir, ainsi que les données publiques et non secrètes nécessaires au fonctionnement de votre compte. La graine elle-même — ce qui constitue votre identité — reste de votre côté.

Voici le modèle mental en une phrase : votre graine d'identité est l'identité portable et la véritable sauvegarde ; le coffre hébergé est une couche de confort déverrouillée par passkey, et non une mise sous garde de votre identité.

Cet article détaille ce que CardanoWall stocke, ce qu'il ne peut délibérément pas lire, et ce que cela implique lorsqu'un problème survient.

Qu'est-ce qu'une graine d'identité, et pourquoi est-ce important ?

Une identité CardanoWall se construit à partir d'une seule graine d'identité de 32 octets. À partir de cette graine, une dérivation de clés déterministe produit les clés que vous utilisez réellement : une clé Ed25519 qui signe les records et des clés fondées sur X25519 qui reçoivent les fichiers scellés. Les mêmes 32 octets reconstruisent toujours la même identité, partout — sur le site web, dans l'outil en ligne de commande, dans les SDK ou dans tout autre logiciel qui respecte les règles de dérivation du standard ouvert Label 309.

C'est là la propriété essentielle : la graine est portable, et elle détermine tout. Les clés en découlent. La seule question qui compte pour le stockage est donc de savoir où réside la graine.

La réponse : chez vous. CardanoWall peut en conserver une copie chiffrée par commodité, mais il stocke du texte chiffré, pas des graines lisibles.

Que stocke réellement CardanoWall ?

CardanoWall stocke les données de service nécessaires au fonctionnement de votre compte. Cela comprend :

• l'état de connexion de votre compte ;
• les informations de facturation et de solde ;
• vos clés d'identité publiques ;
• les records de preuve publics et les références de transaction Cardano ;
• le texte chiffré du coffre d'identité ;
• les clés API, conservées uniquement sous forme d'empreintes ;
• les paramètres produit, comme l'état du cycle de vie de chaque identité ;
• les entrées de votre carnet d'adresses et vos préférences de boîte de réception.

Remarquez ce qui ne figure pas sur cette liste. Votre graine d'identité, votre clé de signature privée dérivée, vos clés de réception privées dérivées et tout fichier scellé déchiffré sont autant de secrets côté client. Ils ne sont jamais stockés dans une colonne serveur lisible. Le coffre chiffré est le seul endroit où le serveur conserve quoi que ce soit lié à la graine, et il le conserve sous forme de texte chiffré qu'il ne peut pas ouvrir.

Pour une vue d'ensemble de ce qui est visible par le service par rapport à ce qui reste sur votre appareil, voyez ce que CardanoWall peut voir.

Qu'est-ce que le coffre d'identité ?

Le coffre d'identité est un unique paquet chiffré qui contient les secrets des identités de votre compte.

À l'intérieur du texte en clair du coffre, chaque entrée contient la graine de 32 octets d'une identité ainsi que le libellé d'affichage privé que vous avez choisi pour elle — « Personnel », « Équipe presse », ce que vous avez saisi. (Un compte peut détenir plusieurs identités ; chacune dispose de sa propre entrée.) Le libellé se trouve lui aussi à l'intérieur du chiffrement, si bien qu'il n'est jamais exposé côté serveur.

Avant que tout cela ne soit stocké, c'est chiffré. CardanoWall conserve le résultat sous la forme d'une ligne de coffre courante par compte, au format age v1. Le serveur peut détenir ce texte chiffré et vous le restituer, mais il ne détient pas le matériel de clé nécessaire pour l'ouvrir.

C'est tout l'enjeu : le coffre n'est pas une mise sous garde. C'est un cache de confort chiffré. L'artefact canonique et portable reste la graine.

Qu'est-ce qui déverrouille le coffre ?

Votre passkey enregistré le déverrouille — et rien d'autre ne le peut.

Le coffre est chiffré exclusivement à destination des facteurs de passkey WebAuthn qui prennent en charge l'extension PRF (fonction pseudo-aléatoire), avec une stanza de destinataire par passkey. Il n'existe délibérément aucune stanza dérivée d'un mot de passe ni aucune stanza à clé publique dans le coffre hébergé. Lors d'un déverrouillage, votre authentificateur effectue la vérification de l'utilisateur et libère vers le navigateur le matériel de clé dérivé du PRF ; ce matériel ouvre le coffre localement.

Le serveur de CardanoWall ne reçoit jamais la graine en clair, le coffre déchiffré, ni aucune clé privée dérivée de la graine. Du côté du serveur, tout ce qu'il sait, c'est qu'un compte est authentifié et qu'il peut restituer un bloc de texte chiffré. C'est votre navigateur, piloté par la cérémonie de votre passkey, qui l'ouvre.

Pour comprendre comment les passkeys fournissent ce verrou et les compromis de récupération selon les types de passkey, voyez comment les passkeys protègent votre coffre d'identité.

Pourquoi ne pas simplement stocker la graine sur le serveur ?

Parce que cela ferait de CardanoWall un dépositaire de votre identité — et c'est précisément ce scénario de défaillance, la mise sous garde, que la conception cherche à éviter.

Si un service stockait des graines en clair, ou des graines qu'il pourrait déchiffrer lui-même, alors une compromission du serveur pourrait se transformer en compromission des clés de l'utilisateur. Un attaquant qui déroberait la base de données ou les clés du serveur pourrait être en mesure de signer à la place des utilisateurs ou de déchiffrer leurs records scellés. C'est un point unique de défaillance catastrophique.

CardanoWall est conçu autour d'une promesse différente : une fuite de base de données ne doit pas révéler les graines d'identité, parce que le serveur ne détient jamais le matériel qui les ouvre. La conception vise à rendre une compromission hypothétique grave, mais pas catastrophique pour vos clés.

Le choix d'un chiffrement à destination des seuls passkeys a deux conséquences précises qu'il vaut la peine de nommer. Comme il n'y a pas de stanza dérivée d'un mot de passe, un coffre dérobé n'offre rien à attaquer par force brute — il n'existe aucune phrase secrète choisie par un humain à éprouver. Et comme il n'y a pas de stanza à clé publique, il n'y a aucune cible asymétrique qu'une future attaque quantique (de type Shor) pourrait viser ; les clés qui protègent le coffre sont des valeurs symétriques de 256 bits détenues à l'intérieur de vos authentificateurs, où la menace quantique pertinente est la recherche de type Grover, ce qui laisse une marge de sécurité effective d'environ 128 bits.

Cela ne fait pas disparaître tous les risques. Cela signifie que le secret le plus important ne se trouve pas dans une colonne serveur lisible, prêt à être copié.

Le coffre est-il une sauvegarde ?

Pas la sauvegarde de dernier recours. La véritable sauvegarde portable, c'est la graine d'identité.

Si vous disposez de la graine, vous pouvez reconstruire la même identité dans CardanoWall, dans l'outil en ligne de commande, dans les SDK, dans l'application de bureau, ou dans tout futur logiciel Label 309 qui suit les mêmes règles de dérivation. La graine est la seule chose qui voyage partout.

Le coffre hébergé vous évite de ressaisir la graine chaque jour. Il peut aussi vous aider à passer à un autre appareil sur lequel vous êtes connecté lorsque votre fournisseur de passkey synchronise le passkey entre vos appareils. Mais le coffre appartient à la couche de service. Il peut être supprimé, devenir indisponible, ou être retiré lorsque vous retirez votre dernier passkey. C'est la graine qu'il faut sauvegarder. Pourquoi la graine d'identité reste importante approfondit ce point.

Que se passe-t-il dans le navigateur lorsque vous déverrouillez ?

Lorsque vous déverrouillez une identité, le navigateur a besoin d'un accès temporaire au matériel de clé privée. C'est inévitable : pour signer un record, le client doit détenir la clé de signature ; pour déchiffrer un fichier scellé, il doit détenir la clé de réception. Ces clés sont dérivées de la graine dans le navigateur, après votre déverrouillage.

La conception maintient les secrets hors du stockage persistant ordinaire du navigateur. Le cache local du navigateur (IndexedDB) peut détenir le coffre sous sa forme chiffrée — les mêmes octets que ceux dont dispose le serveur — de sorte qu'un rechargement de page ne nécessite qu'une seule pression sur le passkey plutôt qu'un aller-retour réseau. Il ne met jamais en cache la graine en clair. Les clés privées actives résident en mémoire de session, conservées en dehors de l'état de l'interface de l'application, et sont remises à zéro au verrouillage ou à la déconnexion, dans la mesure du possible.

Il s'agit d'un modèle de cryptographie web, pas d'une isolation matérielle, et il est honnête sur ses limites. Une extension de navigateur malveillante, un appareil compromis ou un script malveillant actif s'exécutant pendant une session déverrouillée peuvent lire ce qui se trouve en mémoire pendant que vous êtes déverrouillé. Une politique de sécurité du contenu stricte, un minimum de scripts et un déverrouillage sur action explicite uniquement réduisent cette surface, sans pouvoir l'éliminer. CardanoWall supprime le risque lié à la garde côté serveur ; il ne peut pas rendre sûr un appareil non fiable. Les mécanismes sont décrits dans stockage du navigateur et clés de session, et le principe plus général dans pourquoi les clés ne quittent jamais l'appareil.

Que se passe-t-il lorsque vous retirez un passkey ?

Le coffre est reconstruit sans ce facteur.

Lorsque vous retirez un passkey, le coffre courant est rechiffré à destination des facteurs restants et écrit comme une nouvelle ligne unique, remplaçant l'ancien texte chiffré sur place. Le passkey retiré ne peut plus ouvrir le coffre qui existe. Le service applique même cette règle à la frontière de stockage : un coffre ne peut jamais être écrit en étant chiffré à destination d'un justificatif d'identité que le compte a déjà retiré.

Il s'agit d'une véritable révocation pour le coffre hébergé courant. C'est un contrôle au niveau de la couche de service, pas un voyage dans le temps. Si un passkey a été utilisé à mauvais escient alors qu'il était encore valide — par exemple pour ouvrir le coffre et lire la graine qu'il contient au cours d'une session active —, alors l'attaquant détient peut-être déjà la graine, et rechiffrer le coffre par la suite ne permet pas de la récupérer. Dans ce cas, la bonne réponse n'est pas une réinitialisation mais un nouveau départ : créez une nouvelle identité, désactivez l'ancienne, et publiez les nouvelles clés publiques là où les gens s'attendent à les trouver.

Que se passe-t-il si vous retirez un passkey déroule la séquence exacte.

Et si CardanoWall venait à disparaître ?

Vos preuves publiées se vérifient toujours.

Une preuve Label 309 est conçue pour être vérifiable de manière autonome. La vérifier dépend des données Cardano publiques, du stockage public adressé par le contenu lorsque le record y pointe, et de la copie que possède le vérificateur du contenu original ou du matériel de déchiffrement. Une preuve valide n'exige pas que CardanoWall reste en ligne — quiconque dispose de la référence de transaction et d'un explorateur Cardano public peut la vérifier.

Votre identité survit également si vous avez sauvegardé la graine. Les mêmes 32 octets reconstituent la même identité dans n'importe quel outil conforme.

Ce que vous perdez sans la graine, c'est l'usage futur de cette identité : produire de nouvelles signatures et déchiffrer les records scellés qui lui sont adressés. Les preuves que vous avez déjà publiées restent vérifiables pour toujours, mais vous ne pouvez plus agir en tant que cette identité. Cette asymétrie — les preuves publiées sont permanentes, l'usage futur dépend de la détention de la graine — est le prix délibéré de l'absence de dépositaire.

Que devriez-vous concrètement faire ?

Sauvegardez d'abord la graine d'identité.

Conservez-la là où vous gardez vos secrets de grande valeur : un gestionnaire de mots de passe, un emplacement sécurisé hors ligne, ou tout autre dispositif que vous réservez à ce que vous ne pouvez pas vous permettre de perdre. Ajoutez ensuite un passkey pour le confort au quotidien.

Pour un usage ordinaire, cette combinaison constitue un bon équilibre : la graine reste portable, et le passkey fluidifie l'accès quotidien. Pour les identités à haut risque, ajoutez des contrôles opérationnels — une clé de sécurité matérielle, un appareil dédié, et une identité distincte réservée au travail sensible.

Une dernière chose à bien distinguer : une graine perdue (sans plus aucun facteur de déverrouillage) signifie que l'usage futur de l'identité disparaît, mais ses preuves se vérifient toujours. Une graine dérobée est une compromission totale de l'identité, et la réponse consiste à créer une nouvelle identité et à désactiver l'ancienne — jamais une réinitialisation de mot de passe, car il n'y a aucun mot de passe à réinitialiser.

En résumé

CardanoWall stocke le texte chiffré d'un coffre, pas des graines d'identité en clair.

Votre graine est l'identité. Votre passkey déverrouille le coffre chiffré. Le navigateur n'utilise les clés privées qu'après votre déverrouillage, et les efface au verrouillage. Le serveur peut vous aider à publier, à synchroniser et à récupérer commodément l'accès — mais, par conception, il ne peut ni lire ni recréer votre identité.

Sauvegardez la graine. Utilisez le passkey. Sachez les distinguer.

Pour aller plus loin

• Votre identité est une graine — ce qu'est la graine de 32 octets et pourquoi elle constitue l'identité tout entière.
• Comment les passkeys protègent votre coffre d'identité — le verrou par passkey, et les compromis entre clés synchronisées et clés matérielles.
• Stockage du navigateur et clés de session — ce qui réside dans le navigateur, pour combien de temps, et les limites de la cryptographie web.
• Ce que CardanoWall peut voir — la frontière complète de visibilité côté serveur.
• Label 309 — le standard ouvert que CardanoWall implémente, avec le code de référence sur github.com/cardanowall.