Ce que le relais SSP peut voir et ce qu’il ne peut pas
SSP est un portefeuille à deux appareils. Votre extension de navigateur détient une clé, votre téléphone l’autre, et aucun ne peut déplacer de fonds seul. Mais ces deux appareils doivent se parler, et ils le font via un serveur que nous exploitons, appelé le relais.
Ce serveur est l’endroit évident pour poser une question inconfortable : si tout transite par une infrastructure que la société du portefeuille opère, que voit exactement cette société ?
La question est légitime et mérite une réponse précise plutôt que rassurante. Voici donc ce qu’il y a réellement dans le code.
Le relais ne peut rien signer
Commençons par ce qui compte le plus.
Le relais ne reçoit jamais de clé privée. Ni chiffrée, ni découpée, sous aucune forme. La clé de votre portefeuille reste dans votre extension, celle de l’application reste sur votre téléphone, et les seules choses qui traversent le réseau sont des clés publiques, des données non signées et des signatures déjà produites sur vos appareils.
Ce n’est pas un engagement de politique, mais un engagement structurel. Le multisig deux-sur-deux exige les deux signatures pour déplacer des fonds, et le relais ne possède aucune des deux clés. Un relais entièrement malveillant — le nôtre, compromis, ou remplacé par un attaquant — reste incapable de produire une transaction valide, car en produire une exige des secrets qui ne lui ont jamais été envoyés.
Voilà la garantie. Tout ce qui suit concerne ce que le relais manipule effectivement : un ensemble plus étroit, mais réellement non vide.
Ce qui transite, et pour combien de temps
Le relais conserve quatre sortes d’enregistrements. Deux d’entre elles s’effacent d’elles-mêmes.
Les données de synchronisation, lorsque vous appairez vos deux appareils. Elles portent la chaîne, votre identité de portefeuille, la clé publique étendue de l’application, l’identité WK obtenue, les nonces publics, l’adresse générée, et le xpub de récupération avec sa signature.
Les données d’action, lorsque vous signez quelque chose. Elles portent la chaîne, le chemin de dérivation, votre identité WK, le type d’action, la charge utile elle-même et les UTXO concernés.
Ces deux collections possèdent dans MongoDB un index TTL fixé à expireAfterSeconds: 900. Quinze minutes. La base de données supprime l’enregistrement quoi qu’il arrive : ce n’est pas une tâche de nettoyage qu’il faut penser à lancer, ni une promesse dans une politique de confidentialité. C’est un index, imposé par la base elle-même.
Les jetons de notification push, pour que votre téléphone puisse être réveillé quand il y a quelque chose à approuver. Ceux-là persistent, car un jeton qui expirerait toutes les quinze minutes serait inutile.
Le xpub de récupération, un par identité, sans aucune expiration. C’est délibéré et le code le dit : il existe pour que le portefeuille puisse le récupérer quand il en a besoin, et non seulement durant les brefs moments où les deux applications sont éveillées.
La partie sur laquelle il faut être franc
Regardez à nouveau cette charge de synchronisation. Elle contient une clé publique étendue.
Un xpub n’est pas une clé de dépense et ne peut autoriser aucune transaction. Mais ce n’est pas rien. À partir du xpub d’un compte, on peut dériver chaque adresse que ce compte utilisera jamais : quiconque le détient peut donc observer l’intégralité du solde et de l’historique de transactions sur cette chaîne. C’est un accès en lecture à votre vie financière sur ce compte — précisément le recoupement que la confidentialité on-chain consiste à éviter.
La charge d’action est tout aussi réelle. Pendant que vous signez, le relais manipule la transaction non signée : où va l’argent, combien, et depuis quelles sorties.
Le résumé honnête n’est donc pas « le relais ne voit rien ». C’est :
Le relais ne peut pas dépenser votre argent, et par tranches de quinze minutes il peut voir ce que vous en faites.
La fenêtre de quinze minutes est l’atténuation, et elle est réelle : elle borne la quantité d’historique pouvant s’accumuler au même endroit. Mais pendant cette fenêtre, les données sont là, et nous préférons le dire clairement plutôt que laisser « non dépositaire » accomplir un travail rhétorique qu’il n’a pas mérité.
Le principe de conception à emprunter
Un commentaire dans le service de récupération capture l’architecture mieux qu’aucun schéma :
le portefeuille vérifie cette signature contre la clé publique d’identité qu’il dérive lui-même, ce stockage n’est donc pas de confiance.
Le xpub de récupération est enregistré avec une signature détachée que SSP Key a produite dessus. Quand le portefeuille le récupère, il dérive indépendamment la clé publique d’identité et vérifie la signature lui-même. Si le relais renvoyait un xpub différent — par compromission, par bogue ou par substitution délibérée —, la signature ne serait pas valide et le portefeuille le rejetterait.
Le relais est traité comme un tuyau non fiable par le logiciel qui en dépend. C’est la bonne façon de bâtir sur une infrastructure que l’on exploite soi-même, car cela signifie qu’une erreur de votre serveur ne devient pas le problème de vos utilisateurs. C’est aussi le motif à chercher pour évaluer n’importe quel portefeuille : non pas « promettent-ils de bien se conduire ? », mais « que se passe-t-il si leur serveur se conduit mal ? ».
Ce qu’un relais hostile pourrait réellement faire
Il vaut la peine d’être concret sur le vrai modèle de menace.
Il pourrait observer. Dans la fenêtre TTL, votre xpub et votre transaction en attente. C’est une exposition de confidentialité, pas un risque de vol.
Il pourrait censurer. Refuser de transmettre les messages entre vos appareils, ce qui vous empêcherait de signer de nouvelles transactions par le chemin normal. Agaçant et perturbant — et pas la même chose qu’une perte. Vos clés restent les vôtres, vos fonds restent sur la chaîne, et des voies de récupération existent précisément parce que le relais pourrait ne pas être là.
Il pourrait mentir, et échouer le plus souvent. Substituer un xpub de récupération est déjoué par la vérification de signature décrite plus haut. C’est pourquoi cette vérification compte.
Il ne peut pas signer. Pas de clé, pas de signature, pas de transaction.
Le pire cas réaliste est la surveillance et la perturbation, non la perte. C’est une position nettement meilleure que celle d’un service dépositaire, où le pire cas équivalent est que l’argent a disparu. Ce n’est pas la même chose que « personne ne peut rien voir », et confondre les deux est la façon dont on se fait une image fausse de sa propre confidentialité.
Ce que vous pouvez faire des parties visibles
Comprenez ce que l’appairage expose. Synchroniser une chaîne signifie qu’un xpub de cette chaîne transite par le relais. C’est le coût du fonctionnement même du modèle à deux appareils.
Rappelez-vous que la fenêtre est courte, pas nulle. Quinze minutes par action, c’est une borne, pas une absence.
Traitez le xpub de récupération comme permanent. Il est stocké sans expiration par conception, et c’est du matériel de clé publique accompagné d’une signature vérifiable — mais il est durable, et mieux vaut le savoir que le découvrir.
Jugez l’architecture, pas l’assurance. La question utile au sujet du serveur d’un portefeuille n’est pas de savoir si la société promet de la discrétion. C’est de savoir si le logiciel s’apercevrait que le serveur a menti. Le nôtre vérifie des signatures au lieu de croire des réponses, et vous pouvez le lire dans le code plutôt que nous croire sur parole.
Ce que nous aimerions surtout voir compris, c’est la forme de l’échange. Un portefeuille à deux appareils a besoin d’un canal de coordination, et un canal de coordination est un endroit où s’accumulent des métadonnées. Nous avons borné cela par une expiration imposée par la base de données et conçu les clients pour se méfier du serveur — mais la version honnête est que le relais voit des choses réelles, brièvement, et qu’aucune architecture soigneuse ne ramène ce nombre à zéro.
