Sécurité et confidentialité

Comment Babel Mesh répartit les requêtes, protège les comptes et vérifie les nœuds, et ce qu'il ne sait pas faire.

Où va ce que vous envoyez

Votre requête arrive à la passerelle Babel Mesh, qui choisit un nœud selon la classe de données de la requête et la lui transmet. Le nœud calcule le résultat avec son modèle et le renvoie par la passerelle.

  • Le nœud qui traite une requête peut la lire. C'est un fait du fonctionnement actuel : un nœud doit lire l'invite pour y répondre. N'envoyez donc ni mots de passe, ni numéros d'identité, ni secrets commerciaux.
  • Le nœud ne peut pas voir qui vous êtes. La requête reçue par un nœud ne porte ni nom de compte ni clé, seulement une étiquette anonyme.
  • Babel Mesh ne conserve pas les conversations. Les journaux de la passerelle contiennent l'heure d'une requête, le modèle, le résultat et l'utilisation. Les conversations restent dans votre propre client ou navigateur.
  • Babel Mesh n'examine pas le contenu. La passerelle ne vérifie pas, ne bloque pas et ne filtre pas les entrées ni les sorties selon des règles de contenu, et ne conserve ni extraits ni noms de compte à cause de ce qu'une requête contient. La responsabilité de l'usage du contenu incombe à l'utilisateur ; n'envoyez pas de contenu illicite.
  • Les contrôles ponctuels rejouent des requêtes. Pour vérifier ce que renvoient les contributeurs, une petite part des requêtes de classe publique est recalculée sur les nœuds propres de l'opérateur et les deux résultats sont comparés.

Classes de données

Chaque compte et chaque requête a une classe de données. Les comptes qui s'inscrivent eux-mêmes commencent en « publique ». Les nœuds des contributeurs ne reçoivent que des requêtes « publiques ». Les classes supérieures vont uniquement aux nœuds propres de l'opérateur. Pour l'instant, les images et la vidéo ne sont aussi servies que par les nœuds de l'opérateur, car leurs résultats ne peuvent pas être contrôlés par sondage comme le texte.

  • Le site web et l'API utilisent HTTPS. Les composants qui sont derrière (contrôleur, passerelle, registre, relais, nœuds) communiquent par des connexions chiffrées avec authentification mutuelle par certificat ; l'identité d'un nœud est dans son certificat.
  • Les nœuds se connectent uniquement vers l'extérieur. Ils n'ouvrent aucun port entrant et servent via un relais.
  • Le client conserve votre clé d'API sur votre ordinateur, lisible uniquement par votre compte système. La page du client ne reçoit jamais la clé ; c'est le client qui fait les requêtes pour vous.
  • Les mises à jour du client sont vérifiées par rapport à un manifeste signé : la clé publique est intégrée au client, et une signature incorrecte ou une version qui n'est pas plus récente n'est jamais installée.

Comptabilité et vérification

  • Reçus signés par les deux parties. Pour chaque requête, la passerelle et le nœud signent le même reçu, et le registre ne l'enregistre que s'ils concordent. Un reçu contient des empreintes de la requête et du résultat et l'utilisation, pas le contenu.
  • Contrôles aléatoires. Les nouveaux nœuds sont contrôlés plus souvent, ceux qui ont un long historique irréprochable moins souvent. Un nœud dont les résultats ne concordent pas est mis en quarantaine ; une fois la triche confirmée par l'opérateur, ses gains sont perdus et sanctionnés selon les règles.
  • Les gains sont retenus. Le revenu d'un contributeur attend quelques jours, pendant lesquels les contrôles continuent.

Hive : le serveur ne voit pas votre tâche

Hive suit une autre voie : les tâches et fichiers que vous lui confiez sont chiffrés dans votre navigateur, et le répartiteur et le stockage ne reçoivent que du texte chiffré. Voici ce qu’il fait aujourd’hui, y compris ce qu’il ne sait pas faire.

  • Le chiffrement se fait dans le navigateur. Chaque tâche a sa propre clé maîtresse ; la tâche, ses fichiers et son résultat sont scellés avec elle, et la clé maîtresse est scellée séparément pour chaque machine autorisée à exécuter la tâche. Le répartiteur, le stockage et la passerelle voient du texte chiffré, des tailles, des heures et votre identifiant de compte, pas le contenu.
  • La machine qui exécute une tâche peut la lire. Elle doit l’ouvrir pour travailler, et c’est inévitable. Les machines sont donc séparées par classe de données : les tâches publiques peuvent aller à toute machine admise ; les tâches de confiance seulement aux machines de la plateforme, aux institutions sous contrat et aux machines ayant passé l’attestation à distance ; les tâches confidentielles seulement aux machines de la plateforme et aux machines attestées. Vos propres machines passent toujours en premier, et seules elles peuvent prendre vos tâches quelle que soit la classe.
  • Les machines s’exécutent en isolation. Une tâche s’exécute dans un bac à sable gVisor, sans réseau par défaut et avec accès à son seul dossier de travail. Une nouvelle machine doit réussir plusieurs vérifications avant de recevoir de vraies tâches, et une machine qui échoue à une vérification est mise en quarantaine ou bannie.
  • Une clé de modèle à usage unique par tâche. Les machines n’obtiennent jamais la clé de votre compte ; une tâche utilise une clé créée pour elle seule, avec un plafond de dépense. Le serveur la révoque dès que la tâche se termine, que votre page soit ouverte ou non.
  • Combien de temps les choses sont conservées. Une tâche et son résultat (chiffrés) restent 7 jours sur le serveur puis sont supprimés ; la page indique la date. Annuler efface aussitôt. Vos enregistrements de tâches et les clés pour les ouvrir restent uniquement dans votre navigateur : si vous effacez ses données ou changez de navigateur, ils ne s’ouvrent plus, sauf si vous activez la synchronisation entre appareils (chiffrée avec une phrase secrète que vous seul connaissez ; si vous l’oubliez, personne ne peut la récupérer).
  • Ma bibliothèque est aussi chiffrée dans le navigateur. Les fichiers sont découpés en blocs et chiffrés avec une clé propre avant l’envoi ; le stockage ne contient que du texte chiffré, sur plus d’une machine, et l’index est chiffré. Un fichier partagé avec une tâche est en lecture seule, limité dans le temps et à ses blocs.
  • Vous pouvez le vérifier. Le code central doit devenir open source ; les versions peuvent déjà être construites de façon reproductible, et leurs empreintes seront consignées dans un journal de transparence pour que vous confirmiez que le programme que vous exécutez est celui construit à partir du source (cette étape n’a pas commencé) ; la cryptographie côté navigateur est un fichier distinct, recoupé avec l’implémentation du serveur par des vecteurs de test communs.

Ce que Hive ne peut pas faire : empêcher la machine qui exécute une tâche de voir ce qu’elle traite (la classe confidentielle s’appuie sur l’attestation matérielle, pour l’instant seulement les machines de la plateforme) ; protéger contre un navigateur compromis ou un ordinateur avec une extension malveillante ; le serveur connaît encore des métadonnées comme « un compte a soumis une tâche de cette taille à cette heure » ; les tâches publiques peuvent être traitées par des machines d’inconnus, n’y mettez donc rien de privé ; il n’y a pas eu d’audit de sécurité par un tiers.

Ce qu'il ne sait pas faire

  • Il n'existe pas encore d'environnement d'exécution de confiance (TEE) : on ne peut pas garantir qu'un nœud ne voit pas le contenu, d'où les classes de requêtes.
  • Il n'a pas fait l'objet d'un audit de sécurité par un tiers.
  • Aucune promesse de disponibilité : les nœuds peuvent disparaître à tout moment, et une requête est retentée sur un autre nœud, mais le succès n'est pas garanti.

Cette page décrit ce que le système fait réellement aujourd'hui. Les conditions d'utilisation et la politique de confidentialité formelles sont publiées séparément par l'entité exploitante.