Comment sécuriser des données avec des nœuds pas toujours fiables ?
Est-il possible de proposer un service à la fois sûr et fiable en utilisant des nœuds qui eux-mêmes ne le sont pas toujours ?
On estime généralement la fiabilité d’un système informatique (le « temps moyen entre panne », appelé aussi MTBF, pour Mean Time Between Failures) en additionnant les taux de défaillance de chacun des composants - un système étant toujours plus faible que la plus faible de ses composante.
Dans ce contexte, bâtir un système sur la base d’éléments intermittents ou peu fiables (comme dans le cas d’un réseau peer-to-peer) peut sembler une mauvaise idée… C’est pourtant ce qui se fait dans des avions, ou des navettes spatiales, où l’on ne peut pas se permettre le moindre défaut ! La force de ces systèmes repose en réalité sur le concept informatique de redondance, qui désigne la duplication de composants ou de données essentielles d'un système, dans le but d'améliorer sa fiabilité.
Les systèmes peer-to-peer (P2P) fonctionnent ainsi, en se reposant sur des milliers (ou millions) de nœuds similaires. Des nœuds qui ne sont pas nécessairement fiables, mais qui sont facilement duplicables. Le problème, c’est que la duplication a un coût. Pour garantir l’accès rapide à un fichier avec des nœuds intermittents (i.e. 90 % de disponibilité), il peut être nécessaire de dupliquer ce fichier sur deux, trois voire quatre nœuds pour des disponibilités de 99%, 99,9% ou 99,99%.
Heureusement, nous avons d’autres stratégies d’optimisation :
Utiliser la correction d'erreur directe. Les codes correcteurs ont été inventés dans les années 50 pour corriger des erreurs de transmission sur un canal de communication peu fiable. La correction d’erreur directe (FEC) utilise des données redondantes comme codes correcteurs avant la transmission ou le stockage des données. Un exemple ? Le code de Reed-Solomon, utilisé dans les CDs, DVDs et disques durs externes. L’architecture RAID-6 utilise des stratégies de redondance similaires pour ses disques durs.
Comment cela fonctionne-t-il concrètement dans le système peer-to-peer de Hive ? Les fichiers sont divisés en fragments et disséminés dans le réseau P2P. Des fragments additionnels sont également créés pour compenser l’inactivité de certains nœuds ou la destruction de contenu en cas de défaillance matérielle. Par exemple : imaginons que 100 fragments sont générés à partir d’un de vos fichiers, et envoyés à 100 pairs. La fragmentation est réalisée de telle sorte qu’il en suffit de 70 pour recréer le fichier originel. Dès qu’un nœud quitte le réseau, les fragments manquants sont recréés. Avec une marge de 30 %, la probabilité de ne pas pouvoir accéder au contenu complet est incomparablement inférieure à ce qu’elle serait avec une stratégie de réplication simple.
Modéliser le comportement des nœuds. Tous les nœuds du réseau P2P de Hive ont le même rôle, mais tous ne se comportent pas de la même façon. L’ordinateur dans votre chambre sera éteint la nuit, par exemple ; mais si vous avez un NAS, il sera probablement disponible en continu. L’usage de chaque nœud (donc sa disponibilité) varie selon le moment de la journée, la zone géographique, etc. HiveNet repère le comportement de chacun des nœuds et le modélise pour optimiser le placement des données au sein du réseau. L’objectif : toujours disposer de suffisamment de nœuds disponibles pour pouvoir accéder à un fichier donné.
Persistance des données. Nous avons montré comment la correction d’erreur directe peut compenser l’indisponibilité ponctuelle de certains nœuds. Mais ces nœuds peuvent aussi être endommagés - et donc à jamais indisponibles. Une surveillance spécifique permet de les repérer rapidement, notamment via les preuves de stockage. Si un nœud ne répond pas pendant un certain temps à la preuve de stockage, ou s’il est repéré comme indisponible pendant une certaine durée, alors il est déclaré défaillant, et le réseau pair-à-pair s’attachera à recréer ailleurs les données perdues.
S’assurer de la persistance et de la disponibilité des données n’est pas tout ; nous devons aussi protéger leur confidentialité. C’est pourquoi les données sont chiffrées avant même de quitter le terminal de l’utilisateur. Ni Hive, ni aucun des nœuds mobilisés pour le stockage ne pourra déchiffrer le contenu. Nous reviendrons dans un prochain article sur notre stratégie de chiffrement.
