Files
oc-discovery/docs/RISQUES_DECOUVERTE_TRANSACTIONS_DECENTRALISEES.md
T

358 lines
40 KiB
Markdown
Raw Normal View History

2026-04-29 07:41:00 +02:00
# Analyse des Risques d'une Découverte de Pair Sans Confiance et des Transactions de Données et Monétaires dans un Réseau Décentralisé
2026-05-27 16:17:00 +02:00
**Catégorie** : Sécurité des systèmes distribués, Analyse de risques
2026-04-29 07:41:00 +02:00
**Domaine d'application** : Systèmes embarqués, contexte spatial, réseaux tolérants aux disruptions (DTN)
2026-05-27 16:17:00 +02:00
**Version** : 1.1, Mai 2026
2026-04-29 07:41:00 +02:00
---
## Résumé
2026-05-27 16:17:00 +02:00
Les réseaux pair-à-pair décentralisés opérant dans des environnements hostiles posent des défis de sécurité fondamentalement différents de ceux rencontrés dans les infrastructures classiques. Ce document analyse les risques inhérents à deux problématiques interdépendantes : la découverte de pairs en l'absence d'autorité centrale de confiance, et la conduite de transactions portant sur des données et des actifs monétaires dans un réseau potentiellement infiltré, surveillé, ou partiellement contrôlé par des adversaires.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Le périmètre est délimité par le contexte des systèmes distribués embarqués et spatiaux opérant selon le paradigme DTN (Delay/Disruption Tolerant Networking) : latences élevées, connectivité intermittente, coprésence d'acteurs aux niveaux de confiance hétérogènes.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Le modèle de menace distingue deux classes d'adversaires. L'adversaire rationnel à ressources limitées agit selon un calcul coût/bénéfice, il attaque si ça vaut la peine. L'adversaire à ressources quasi-illimitées peut financer des attaques dont le coût dépasse le bénéfice apparent, dans une perspective stratégique à long terme : maintenir une présence passive dans le réseau pendant des mois (watchers), accumuler des informations permettant de dé-anonymiser des participants, ou reconstruire des stratégies opérationnelles. C'est ce second modèle qui prévaut dans un contexte spatial ou militaire embarqué.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
L'analyse couvre trois couches : réseau et transport, découverte P2P, transactions (données et monétaires). Pour chacune, on identifie les vecteurs d'attaque connus, leur criticité selon le contexte, et les mécanismes de mitigation avec leurs limites résiduelles.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Un fil directeur traverse cette analyse : pour la couche de **règlement monétaire** spécifiquement, les risques de double-spend, de transparence transactionnelle et de finalité non déterministe ne trouvent de réponse robuste que dans une blockchain, idéalement confidentielle et souveraine. Les autres couches relèvent de mécanismes distincts documentés dans les propositions architecturales associées.
La conclusion principale est que la confiance ne peut, dans ce contexte, être que probabiliste et relative, jamais binaire ni absolue, et que toute architecture ignorant cette réalité est structurellement vulnérable sur le long terme.
2026-04-29 07:41:00 +02:00
---
## 1. Contexte et Modèle de Menace
2026-05-27 16:17:00 +02:00
### 1.1 Le Problème Fondamental
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
La question de la coordination entre agents sans autorité centrale de confiance est l'un des problèmes fondamentaux de l'informatique distribuée. Lamport, Shostak et Pease [14] ont formalisé ce problème sous la forme du "problème des généraux byzantins" : comment atteindre un consensus lorsque certains processus peuvent se comporter de manière arbitrairement malveillante ? Leur résultat établit qu'un consensus fiable est possible si et seulement si la proportion de processus défaillants reste strictement inférieure à un tiers de l'ensemble.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Ce résultat contraint directement toute architecture distribuée en environnement hostile : même avec des mécanismes cryptographiques parfaits, le nombre de nœuds compromis que le système peut tolérer est borné. Au-delà d'un tiers, aucun algorithme de consensus déterministe ne peut garantir la cohérence.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
S'y ajoute le résultat FLP (Fischer, Lynch & Paterson) [9], qui démontre l'impossibilité d'un consensus déterministe tolérant même une seule panne dans un système purement asynchrone. Ce théorème impose des compromis entre disponibilité, cohérence et tolérance aux pannes que toute architecture doit assumer explicitement, sous peine de créer des zones d'ombre dans ses garanties de sécurité.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 1.2 Spécificités DTN
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Les réseaux spatiaux et les réseaux embarqués militaires partagent des caractéristiques qui les distinguent radicalement des réseaux terrestres filaires sur lesquels la majorité des protocoles P2P ont été conçus.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Le paradigme DTN (Delay-Tolerant Networking) a été conçu précisément pour ces environnements : chemins bout-en-bout inexistants en permanence, latences de secondes à plusieurs heures, protocoles TCP/IP inutilisables dans leur forme standard. La couche "bundle" (RFC 4838) [4] stocke les messages et les retransmet lors des fenêtres de contact. Dans ce contexte, les hypothèses habituelles des protocoles P2P s'effondrent : connectivité permanente, timeouts courts, heartbeats garantis, détection de panne par timeout.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Ce dernier point mérite attention : dans un réseau DTN, la détection de panne par timeout devient profondément ambiguë. Un nœud absent depuis une heure est-il défaillant, ou simplement hors de couverture radio ? Cette ambiguïté crée des fenêtres d'opportunité pour des adversaires capables d'exploiter les périodes de déconnexion pour injecter de faux états ou corrompre des enregistrements en l'absence de réfutation possible.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 1.3 Adversaire Rationnel vs Adversaire d'État
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
L'adversaire rationnel à ressources limitées optimise un objectif économique. Il attaquera si le bénéfice attendu dépasse le coût. Ce modèle est pertinent pour les attaques opportunistes sur les réseaux P2P publics, la majorité des attaques réelles.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
L'adversaire à ressources quasi-illimitées opère dans une logique différente. Il peut maintenir une présence passive sur des années, capturer physiquement des nœuds pour en extraire les secrets cryptographiques, contrôler silencieusement des nœuds compromis pendant des semaines (stealthy Byzantine), et analyser les métadonnées de trafic même en présence de chiffrement de contenu. C'est ce second modèle qui est pertinent pour un contexte spatial ou militaire.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 1.4 Confiance Relative
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Le modèle de confiance binaire, pair de confiance / pair non-fiable, est inadapté aux environnements complexes. Un pair peut être partiellement compromis, fiable pour certaines opérations mais pas d'autres. La confiance est temporelle : un pair fiable hier peut être compromis aujourd'hui. Et le modèle binaire est vulnérable aux promotions frauduleuses : un adversaire peut se comporter parfaitement pendant longtemps pour atteindre un statut de confiance, puis l'exploiter.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Le résultat FLP [9] établit en outre qu'en présence d'asynchronisme, un observateur ne peut distinguer de manière déterministe un nœud défaillant d'un nœud simplement lent. Tout jugement de confiance sur un pair distant est donc nécessairement probabiliste, il repose sur une accumulation d'observations cohérentes dans le temps, non sur une preuve déterministe. D'où l'adoption de modèles de confiance à scores continus et multidimensionnels plutôt que de jugements binaires.
2026-04-29 07:41:00 +02:00
### 1.5 Propriétés de Sécurité Visées
2026-05-27 16:17:00 +02:00
- **Authenticité** : chaque pair peut prouver son identité sans tiers de confiance.
2026-04-29 07:41:00 +02:00
- **Intégrité** : les données transmises ou stockées ne peuvent être altérées sans détection.
2026-05-27 16:17:00 +02:00
- **Disponibilité** : le système continue de fonctionner en mode dégradé lors d'indisponibilités partielles.
2026-04-29 07:41:00 +02:00
- **Confidentialité** : le contenu des échanges est opaque pour les observateurs non autorisés.
- **Souveraineté** : les données appartiennent à leur créateur, qui contrôle leur cycle de vie.
2026-05-27 16:17:00 +02:00
- **Non-traçabilité** : dans le cas le plus hostile, l'existence même des échanges doit pouvoir être dissimulée.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Ces propriétés sont partiellement antagonistes, la disponibilité et la confidentialité entrent régulièrement en tension. Reconnaître ces tensions explicitement est la première étape vers une architecture qui les gère de manière informée plutôt que de les ignorer.
2026-04-29 07:41:00 +02:00
---
## 2. Risques de la Couche Réseau et Transport
### 2.1 Man-in-the-Middle et Attaques Actives
2026-05-27 16:17:00 +02:00
L'attaque MitM consiste pour un adversaire actif à s'interposer entre deux pairs communicants, se faisant passer pour chacun d'eux. Sans authentification mutuelle, cette attaque est triviale sur tout réseau P2P non protégé.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Le Noise Protocol Framework [21] offre une réponse adaptée : handshake cryptographique avec authentification mutuelle, sans PKI centralisée. Le pattern Noise_XX permet une authentification mutuelle des clés publiques en restant léger pour les contraintes embarquées.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
La limite résiduelle est le premier contact : si un pair ne connaît pas a priori la clé publique de son interlocuteur, le premier échange est vulnérable à un MitM qui substituerait sa propre clé. C'est le problème TOFU (Trust On First Use), difficile à éliminer sans mécanisme d'enrôlement hors-bande.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 2.2 Eclipse Attacks
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Une attaque par éclipse vise à monopoliser toutes les connexions entrantes et sortantes d'un pair cible, de sorte que toute l'information qu'il reçoit passe par des nœuds contrôlés par l'adversaire. Une fois isolé, le pair peut être manipulé : vue falsifiée du réseau, censure des messages sortants, soumission de fausses transactions.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
La résistance passe par la diversification des sources de pairs, bootstrap multi-seeds, connexions aléatoires dans des sous-espaces distincts du graphe. Un adversaire contrôlant un ISP ou une infrastructure réseau intermédiaire peut contourner ces mitigations.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 2.3 Partitionnement Réseau et Théorème CAP
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Le théorème CAP [3][10] établit qu'un système distribué ne peut simultanément garantir cohérence (Consistency), disponibilité (Availability) et tolérance au partitionnement (Partition tolerance). Face à un partitionnement, le système doit choisir.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
En contexte DTN, les partitions ne sont pas des événements exceptionnels, elles sont la norme opérationnelle. Un système de découverte de pairs doit délibérément favoriser la disponibilité (AP) : un nœud doit pouvoir continuer à opérer même sans vérifier en temps réel l'état de ses pairs. La cohérence forte est réservée aux opérations critiques, le règlement de transactions monétaires, où elle doit être assurée par une couche séparée avec un consensus distinct.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 2.4 Traffic Analysis, Le Watcher Problem
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Le chiffrement de contenu ne suffit pas contre un adversaire passif qui analyse les métadonnées de trafic. Timing, volume, fréquence, patterns de connexion/déconnexion, toutes ces métadonnées révèlent des informations critiques même sans accès au contenu. La fréquence des heartbeats révèle les cycles opérationnels. L'apparition simultanée de plusieurs nœuds révèle une coordination. Des travaux sur les réseaux Bitcoin montrent que l'identification de l'émetteur d'une transaction est possible à partir des seuls patterns de diffusion, sans contenu chiffré [17].
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
La mitigation complète (padding temporel, traffic shaping, mixnets) est coûteuse en bande passante, un compromis difficile dans un contexte spatial.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 2.5 Spécificités DTN : Latences et Discontinuité
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Les communications Terre-orbite basse introduisent des latences de 20 à 600 ms selon l'élévation; les fenêtres de visibilité entre satellites imposent des périodes de contact discontinues; les contraintes énergétiques forcent des modes de veille. TCP est inutilisable dans sa forme standard, les mécanismes de retransmission et de gestion des timeouts sont dimensionnés pour des latences sub-secondes. Les protocoles de couche bundle (RFC 4838) offrent une alternative, mais leur adoption dans les systèmes P2P reste embryonnaire.
2026-04-29 07:41:00 +02:00
---
2026-05-27 16:17:00 +02:00
## 3. Risques de la Couche de Découverte P2P
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 3.1 Sybil Attack
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
La formalisation de Douceur [7] est un résultat fondamental : l'attaque Sybil, création massive d'identités pseudonymes pour acquérir une influence disproportionnée, est **insoluble sans coût d'entrée ou autorité centrale**. En l'absence d'un mécanisme rendant la création d'identités coûteuse ou d'une autorité capable de vérifier les identités, aucun système P2P ne peut garantir une résistance Sybil complète.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Dans un contexte embarqué à ressources limitées, les mécanismes de preuve de travail sont énergétiquement prohibitifs. Les clés pré-partagées (PSK) organisationnelles constituent une réponse adaptée pour les réseaux fermés. Pour les réseaux plus ouverts, le scoring comportemental pénalise les pairs nouveaux ou peu fiables, sans résoudre le problème, mais en l'amortissant.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 3.2 Empoisonnement des Tables de Routage
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Le DHT Kademlia [16] organise les pairs dans un espace d'adressage XOR permettant la découverte en O(log n) sauts. Sa table de routage est vulnérable à l'empoisonnement : un adversaire peut insérer de fausses entrées, redirigeant le trafic vers des nœuds malveillants. L'extension S/Kademlia [2] ajoute des contraintes cryptographiques sur la génération des identifiants de nœuds et des signatures sur les messages de routage, ce qui réduit significativement la surface d'attaque sans l'éliminer pour un adversaire disposant de suffisamment de nœuds.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 3.3 Éclipse sur DHT
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
En contrôlant un sous-ensemble de nœuds stratégiquement positionnés dans l'espace d'adressage [23], un adversaire peut isoler une région de la DHT et intercepter toutes les requêtes portant sur les identifiants de cette région. Si la DHT est aussi utilisée pour le stockage (pas seulement la découverte), les enregistrements dans la région éclipsée peuvent être supprimés, falsifiés, ou rendus inaccessibles sans détection immédiate.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 3.4 Bootstrap Poisoning
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Tout réseau P2P doit résoudre le premier contact : un nœud rejoignant le réseau doit connaître au moins un pair existant. Les seeds d'amorçage sont donc une cible prioritaire. Bitcoin [19] utilise des DNS seeds distribués opérés par plusieurs entités indépendantes; Tor utilise des directory authorities dont les clés sont codées en dur dans le client. Dans un réseau embarqué hostile, les DNS seeds peuvent être censurés et les clés codées en dur peuvent être extraites par capture physique. Un adversaire contrôlant les seeds peut orienter tous les nouveaux nœuds vers une partition malveillante.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 3.5 Churn Adversarial
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Un churn élevé dégrade les performances de routage, fragmente les tables, et peut rendre certaines régions de la DHT temporairement inaccessibles. Dans un contexte DTN, le churn n'est pas exceptionnel mais structurel, les nœuds apparaissent et disparaissent selon les fenêtres de contact. Un adversaire peut exploiter cela en injectant massivement des nœuds éphémères qui saturent les tables de routage, déplacent les nœuds légitimes, puis disparaissent avant d'être pénalisés par les mécanismes de scoring.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 3.6 Collusion et Faux Consensus de Scoring
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Un groupe de nœuds malveillants peut s'attribuer mutuellement de bons scores, se recommander mutuellement, et dégrader les scores des nœuds légitimes. Cette attaque est particulièrement insidieuse car difficile à distinguer d'un comportement légitime sans information hors-bande sur la topologie réelle.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Les mécanismes de témoin croisé réduisent ce risque, à condition que les témoins interrogés soient suffisamment diversifiés. Un protocole de membership épidémique avec réfutation explicite ajoute une couche de protection : un nœud injustement suspecté peut émettre une réfutation qui neutralise les faux signaux propagés à son encontre. La propagation bornée des événements de membership limite la portée d'une campagne de désinformation à un voisinage local. Ces mécanismes ne résolvent pas la collusion si l'adversaire contrôle une fraction suffisante des nœuds, ils en rendent simplement la conduite plus coûteuse et plus visible.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 3.7 Injection de Faux Enregistrements
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Un adversaire peut injecter de faux enregistrements de présence dans la DHT, annoncer des ressources ou des nœuds fictifs. Au-delà du gaspillage de bande passante, cette pollution peut servir de leurre pour identifier quels nœuds recherchent quels types de ressources : une surveillance active via pot de miel.
2026-04-29 07:41:00 +02:00
---
## 4. Risques des Transactions de Données
2026-05-27 16:17:00 +02:00
### 4.1 Data Poisoning
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
La DHT Kademlia stocke les enregistrements à proximité des nœuds dont l'identifiant est proche de la clé. Un adversaire contrôlant des nœuds dans une région peut altérer silencieusement les enregistrements confiés à ces nœuds. La mitigation standard, enregistrements signés par leur créateur, détecte toute altération, à condition que la clé publique du créateur soit connue et authentique. Ce qui ramène au problème de la distribution des clés publiques.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 4.2 Replay Attacks
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Un adversaire peut capturer un enregistrement signé valide et le rejouer ultérieurement, même après révocation. La protection combine nonces et timestamps dans les données signées, mais dans un réseau DTN où les horloges ne sont pas nécessairement synchronisées, la vérification des timestamps introduit des contraintes supplémentaires.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 4.3 Tombstone Malveillant
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Un tombstone signale la suppression d'un enregistrement précédent. Un adversaire en possession de la clé privée d'un pair compromis peut émettre de faux tombstones pour invalider des enregistrements légitimes, effaçant effectivement la présence d'un nœud ou la disponibilité d'une ressource. Dans les réseaux à haute durée de vie où les enregistrements ne périment pas rapidement, un tombstone malveillant peut effacer des années d'historique légitime.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 4.4 Souveraineté de la Donnée
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Dans les architectures DHT standard, les enregistrements expirent après un TTL fixe et leur renouvellement est à la charge du créateur. Si ce créateur est temporairement indisponible, ce qui est la norme en contexte DTN, ses enregistrements expirent, le rendant invisible du réseau. Inversement, des enregistrements trop durables laissent visibles des pairs compromis ou supprimés. L'équilibre entre durabilité et fraîcheur est un paramètre critique dont les valeurs optimales dépendent du profil de connectivité des nœuds.
2026-04-29 07:41:00 +02:00
### 4.5 Inférence par Analyse de Présence
2026-05-27 16:17:00 +02:00
Même avec un contenu entièrement chiffré, les patterns de présence révèlent des informations sensibles : fréquence des heartbeats (cycles opérationnels), apparition simultanée de plusieurs nœuds (coordination), corrélation des moments d'activité avec des événements externes (plans opérationnels). Ce risque est indépendant du chiffrement du contenu, les métadonnées seules constituent une source d'information substantielle.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 4.6 Linkabilité
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
La corrélation de sessions successives peut relier différentes identités pseudonymes à un même acteur physique. Si un nœud utilise systématiquement les mêmes sous-ensembles de pairs pour se connecter, cette structure relationnelle constitue une empreinte distinctive. La rotation d'identité atténue le risque mais crée une friction opérationnelle significative.
2026-04-29 07:41:00 +02:00
---
## 5. Risques des Transactions Monétaires Décentralisées
2026-05-27 16:17:00 +02:00
C'est pour cette couche que les risques sont les plus difficiles à adresser par des mécanismes P2P seuls. Les propriétés d'immuabilité, de finalité déterministe et de règles d'exécution vérifiables sont précisément ce que les transactions monétaires requièrent, et ce qu'une DHT pair-à-pair ne peut pas offrir nativement. C'est ici que l'argument en faveur d'une blockchain dédiée est le plus solide.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 5.1 Double-Spend dans un Réseau AP
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Dans un réseau AP (disponibilité prioritaire sur cohérence), deux nœuds partitionnés peuvent chacun valider indépendamment une transaction utilisant le même actif. Le conflit ne peut être résolu qu'à la réunification. Nakamoto [19] a résolu ce problème via une chaîne de blocs avec preuve de travail, mais avec finalité probabiliste à l'heure. Les algorithmes de consensus BFT comme Tendermint [12] offrent une finalité déterministe dès la validation du bloc. Un validateur absent pendant une partition DTN est simplement exclu du quorum pour les blocs produits pendant son absence, sans invalider rétroactivement les transactions précédentes.
2026-04-29 07:41:00 +02:00
### 5.2 Front-Running et MEV
2026-05-27 16:17:00 +02:00
Les validateurs peuvent réordonner, insérer ou censurer des transactions au sein d'un bloc pour en extraire une valeur maximale, le MEV (Miner Extractable Value). Ce n'est pas une attaque au sens classique : c'est une exploitation parfaitement légale des règles du protocole. Dans un marché de ressources décentralisé, cela peut prendre la forme d'enchères truquées ou de saisie prioritaire de ressources convoitées.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Les blockchains confidentielles suppriment structurellement le MEV basé sur l'information : un validateur qui ne peut pas lire le contenu des transactions ne peut pas les réordonner à son avantage. C'est l'une des propriétés les plus directement utiles des smart contracts confidentiels pour ce contexte.
2026-04-29 07:41:00 +02:00
### 5.3 Oracle Problem
2026-05-27 16:17:00 +02:00
Un smart contract de règlement doit se déclencher quand une ressource a été effectivement consommée. Mais comment un contrat exécuté dans un environnement blockchain fermé peut-il vérifier un événement du monde réel ? Ce problème d'oracle est fondamentalement non résolu. Les solutions existantes (oracles décentralisés, attestations TEE) réduisent la surface de confiance requise sans l'éliminer. Dans un contexte spatial ou embarqué, la latence de propagation et l'impossibilité d'une confirmation en temps réel rendent la conception de l'oracle particulièrement délicate.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 5.4 Smart Contract Bugs
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
L'exploit du DAO en 2016, un bug de reentrancy drainant 60 millions de dollars, a illustré de manière spectaculaire les risques des smart contracts [15]. La vérification formelle est possible pour des contrats simples mais reste hors de portée pour des contrats complexes.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
CosmWasm, le framework de smart contracts de l'écosystème Cosmos, adopte un modèle d'exécution "actor" qui supprime structurellement les réentrances. Le langage Rust ajoute des garanties de sécurité mémoire à la compilation. Ces propriétés n'éliminent pas tous les bugs, mais éliminent des classes entières de vulnérabilités connues.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 5.5 Transparence Blockchain
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
La transparence totale des blockchains publiques est antagoniste à la souveraineté des données. Des travaux sur le réseau Bitcoin ont démontré que les transactions, supposément pseudonymes, peuvent être reliées à des entités réelles par analyse de graphe [17], corrélation avec des événements externes, et réutilisation d'adresses. Dans un contexte hostile, la simple visibilité des volumes de transactions entre acteurs révèle des informations stratégiques : qui paie qui, combien, à quelle fréquence.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
La réponse passe soit par les zk-SNARKs (Zcash, Penumbra), confidentialité cryptographique pure sans dépendance matérielle, soit par les TEE (Secret Network, Oasis), confidentialité des états de smart contracts dans des enclaves matérielles. L'approche TEE est aujourd'hui la plus mature pour des contrats complexes; l'approche ZK pure est préférable à long terme pour des garanties indépendantes du hardware.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 5.6 Finalité en Contexte DTN
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Les blockchains BFT offrent une finalité déterministe en quelques secondes, mais supposent une connectivité suffisante entre validateurs. Un validateur absent pendant plusieurs heures bloque le quorum si sa participation est requise. La conception du validator set doit anticiper les fenêtres de déconnexion et maintenir un quorum parmi les nœuds présents à chaque instant, ce qui implique un redimensionnement du validator set au-delà du strict minimum nécessaire pour le consensus.
2026-04-29 07:41:00 +02:00
---
## 6. Risques Spécifiques au Contexte Spatial et Embarqué
2026-05-27 16:17:00 +02:00
### 6.1 Ambiguïté Panne / Absence
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Dans un réseau DTN, un nœud peut être légitimement injoignable pendant plusieurs heures sans être défaillant. Un mécanisme de détection de panne naïf basé sur des timeouts courts produira des faux positifs massifs. La distinction entre "absent (normal)" et "défaillant ou malveillant" requiert une connaissance du calendrier de contact prévisible, information qui peut elle-même être sensible dans un réseau hostile.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
L'architecture Nano/Maître apporte une réponse partielle à ce problème. Le maître, présumé plus stable, connaît la feuille de route de ses nanos et peut distinguer une absence orbitale planifiée d'une indisponibilité inattendue, information qu'il peut propager aux autres participants.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 6.2 Bande Passante Contrainte
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Les liens satellites présentent des débits asymétriques et limités. Les protocoles P2P verbeux peuvent consommer une fraction substantielle de la bande passante disponible. Le Proof of Work est particulièrement inadapté : la propagation de blocs volumineux sur des liens lents crée des conditions propices aux forks. Les consensus BFT produisent des blocs de taille contrôlée avec un overhead de messages limité, bien plus adaptés.
2026-04-29 07:41:00 +02:00
### 6.3 Contraintes Énergétiques
2026-05-27 16:17:00 +02:00
Les nœuds embarqués spatiaux opèrent sur des bilans énergétiques stricts. Le Proof of Work, qui requiert une dépense énergétique continue, est structurellement incompatible. Proof of Stake et BFT présentent des profils énergétiques compatibles.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 6.4 Isolation Planifiée et Mode Autonome
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Des périodes d'isolation planifiée (passage dans l'ombre, silence radio, orbite hors couverture) font partie du profil opérationnel normal. Le réseau doit fonctionner en mode complètement autonome pendant ces périodes. Tout état critique doit être répliqué localement; les décisions opérationnelles ne doivent pas requérir de consensus réseau en temps réel; la resynchronisation après reconnexion doit être déterministe et complète.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 6.5 Capture Physique et Extraction de Secrets
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Un adversaire physiquement présent peut capturer un nœud et en extraire les secrets cryptographiques. La mitigation passe par des modules de sécurité matériels (HSM, Secure Enclave), une rotation régulière des clés, et des procédures de révocation réactives.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 6.6 Compromission de Longue Durée (Stealthy Byzantine)
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Un nœud compromis peut se comporter normalement pendant une longue période pour éviter la détection, puis activer un comportement malveillant coordonné au moment opportun. Les mécanismes de réputation basés sur l'historique accordent précisément une haute confiance aux nœuds anciens, les cibles préférées de ce type de compromission. La seule mitigation partielle est la vérification périodique de la cohérence des comportements sur des dimensions difficiles à simuler, combinée à une surveillance croisée par des témoins multiples.
2026-04-29 07:41:00 +02:00
---
## 7. Gestion de la Confiance Relative et des Consortiums
2026-05-27 16:17:00 +02:00
### 7.1 Pourquoi la Confiance Binaire Échoue
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Un modèle binaire de confiance échoue pour trois raisons complémentaires : un pair peut être partiellement compromis (fiable pour certaines opérations, pas d'autres); la confiance est temporelle (hier fiable ne garantit pas aujourd'hui); le modèle est vulnérable aux promotions frauduleuses (se comporter parfaitement en attendant d'accumuler du crédit, puis exploiter ce crédit). Un modèle continu à score multidimensionnel rend la manipulation plus coûteuse et plus visible : altérer simultanément plusieurs dimensions comportementales de manière cohérente requiert une sophistication bien supérieure à la simple patience.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 7.2 TOFU et ses Limites
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Le paradigme TOFU (Trust On First Use) accepte la clé publique d'un pair au premier contact et la considère ensuite comme authentique. Pragmatique, mais vulnérable à ce premier contact : un adversaire capable d'intercepter la première connexion peut substituer sa propre clé. SSH couple TOFU à une alerte en cas de changement ultérieur, raisonnable pour une topologie stable, problématique quand les nœuds sont fréquemment remplacés ou réinitialisés.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 7.3 Gouvernance des Consortiums
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Les consortiums définissent des sous-groupes de pairs avec une confiance a priori plus élevée, sur la base d'une relation organisationnelle hors-bande. La gouvernance soulève des questions précises : qui admet de nouveaux membres ? Quel quorum pour exclure un membre ? Ces décisions ne peuvent être prises de manière décentralisée que si un mécanisme de consensus approprié existe, et ces décisions partagent exactement les mêmes exigences que les transactions monétaires (finalité déterministe, résistance byzantine, auditabilité). Il est donc naturel d'utiliser la même infrastructure blockchain pour les deux.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
Dans l'écosystème Cosmos, chaque consortium peut opérer sa propre zone avec des propositions onchain pour l'admission et l'exclusion de validateurs, les mises à jour de protocole, et les modifications de paramètres. Cette convergence évite la fragmentation entre mécanismes de gouvernance hors-bande et mécanismes de règlement onchain.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
### 7.4 Révocation Sans Autorité Centrale
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
La révocation d'un membre sans autorité centrale est un problème partiellement ouvert. Dans un réseau décentralisé, la révocation doit être propagée de manière épidémique, mais une propagation épidémique peut être bloquée si l'adversaire contrôle les canaux de communication des nœuds informés de la révocation.
2026-04-29 07:41:00 +02:00
### 7.5 Propagation Épidémique des Signaux de Méfiance
2026-05-27 16:17:00 +02:00
Le protocole SWIM [6] (Scalable Weakly-consistent Infection-style Process Group Membership) peut être étendu à la propagation de signaux de méfiance : un nœud ayant observé un comportement suspect diffuse cette information à un sous-ensemble aléatoire de ses pairs. Convergence probabiliste en O(log n) étapes. Vulnérable si l'adversaire contrôle une fraction significative des canaux ou peut identifier et bloquer sélectivement les messages de méfiance le concernant.
2026-04-29 07:41:00 +02:00
---
## 8. Synthèse et Classification des Risques
| Risque | Couche | Criticité (réseau privé) | Criticité (réseau hostile) | Mitigation principale | Limite résiduelle |
|---|---|---|---|---|---|
2026-05-27 16:17:00 +02:00
| MitM actif | Transport | Élevée | Critique | Noise Protocol (mutual auth) | Vulnérabilité TOFU au premier contact |
| Eclipse attack | Réseau | Moyenne | Élevée | Diversification connexions, multi-seeds | Adversaire contrôlant un ISP |
| Partitionnement | Réseau | Faible | Élevée | AP délibéré (découverte) / BFT (règlement) | Forks d'état à la réunification |
2026-04-29 07:41:00 +02:00
| Traffic analysis | Transport | Faible | Critique | Padding, traffic shaping, mixnets | Coût prohibitif à grande échelle |
2026-05-27 16:17:00 +02:00
| Sybil attack | Découverte P2P | Faible (PSK) | Élevée | PSK organisationnelle + scoring | Réseau ouvert hostile non résolu |
| Routing table poisoning | Découverte P2P | Moyenne | Élevée | S/Kademlia | Adversaire avec fraction > 1/3 |
| Eclipse sur DHT | Découverte P2P | Moyenne | Élevée | Multi-seeds, diversité des voisins | Compromis performance/sécurité |
| Bootstrap poisoning | Découverte P2P | Faible | Critique | Multi-seeds distribués | Seeds = ancre de confiance unique |
| Churn adversarial | Découverte P2P | Faible | Moyenne | Rate limiting, délai de grâce | Difficile à distinguer du churn normal |
| Collusion scoring | Découverte P2P | Faible | Élevée | Témoin croisé, challenges multidimensionnels | Insoluble si adversaire > 1/3 |
2026-04-29 07:41:00 +02:00
| Data poisoning | Données | Élevée | Critique | Records signés | Distribution des clés publiques |
2026-05-27 16:17:00 +02:00
| Replay attack | Données | Moyenne | Élevée | Nonce + timestamp signé | Synchronisation d'horloge en DTN |
| Tombstone malveillant | Données | Moyenne | Élevée | Signature + timestamp révocation | Compromission de clé privée |
2026-04-29 07:41:00 +02:00
| Inférence par présence | Données | Faible | Critique | Padding temporel, faux heartbeats | Coût en bande passante |
2026-05-27 16:17:00 +02:00
| Linkabilité | Données | Faible | Élevée | Rotation d'identité, padding | Friction opérationnelle |
| Double-spend | **Règlement monétaire** | Élevée | Élevée | **Blockchain BFT (finalité déterministe)** | Indisponibilité des validateurs |
| MEV / Front-running | **Règlement monétaire** | Moyenne | Élevée | **Blockchain confidentielle (contrats chiffrés)** | Résistance imparfaite si contenu visible |
| Oracle problem | **Règlement monétaire** | Élevée | Élevée | TEE attestations, ZK-proofs | Surface de confiance matérielle ou crypto |
| Smart contract bug | **Règlement monétaire** | Élevée | Élevée | **CosmWasm/Rust (pas de reentrancy)** | Vérification formelle incomplète |
| Transparence blockchain | **Règlement monétaire** | Moyenne | Critique | **Blockchain confidentielle (Secret Network / ZK)** | Maturité ZK pure, dépendance SGX |
| Finalité en DTN | **Règlement monétaire** | Faible | Élevée | **BFT, validator set dimensionné pour absences** | Quorum impossible si partition longue |
| Stealthy Byzantine | Tous | Faible | Élevée | Scoring multidimensionnel + témoins | Détection a posteriori seulement |
| Capture physique | Tous | Faible | Critique | HSM, rotation régulière des clés | Fenêtre avant révocation |
Un patron clair se dégage : les risques de la couche de règlement monétaire forment une classe cohérente dont les mitigations convergent toutes vers le même outil, une blockchain à consensus BFT, idéalement confidentielle. Les couches de découverte P2P et de données relèvent de mécanismes distincts et complémentaires.
---
## 9. Conclusion
Quatre observations structurent la synthèse de cette analyse.
**Nécessitée de la séparation des couches** Les risques des trois couches analysées requièrent des mécanismes de mitigation fondamentalement différents. La séparation entre la couche de découverte (profil AP) et la couche de règlement monétaire (profil CP) est dictée par le théorème CAP : les prérequis des deux sont mutuellement incompatibles, et tenter de les couvrir avec un seul outil dégraderait inévitablement les garanties sur au moins une dimension.
**Les risques DTN dans les couches découverte et données ont trouvé des réponses concrètes.** Un cache de messages à deux niveaux de criticité, retry indéfini avec persistance chiffrée pour les mutations de ressources, retry limité pour les confirmations, protège contre les pertes dues à l'intermittence, avec des règles de cycle de vie qui garantissent la cohérence de l'état final quelle que soit la durée de l'interruption. Un mécanisme de réveil intégré aux heartbeats existants permet aux nœuds ayant des messages en attente de signaler cette attente sans canal dédié ni timer additionnel. L'architecture Nano/Maître fournit une délégation formelle pour les nœuds à très faible disponibilité, avec réconciliation déterministe des conflits de réservation. Ce sont des réponses architecturalement fondées, non des pistes prospectives.
**Pour le règlement monétaire, la blockchain** Double-spend, transparence transactionnelle, front-running, non-finalité, aucun de ces risques ne trouve de réponse robuste dans des mécanismes P2P seuls. La piste retenue, zones Cosmos souveraines par consortium + règlement inter-consortium confidentiel via Secret Network, avec migration anticipée vers Penumbra, est architecturalement solide. Elle n'est pas encore intégrée dans le projet; c'est le chantier qui reste ouvert.
**La confiance reste probabiliste.** Même avec une blockchain souveraine BFT pour le règlement et un système de scoring comportemental multidimensionnel pour la découverte, la confiance dans ce contexte ne peut être qu'approximative. Le résultat de Douceur sur les attaques Sybil, le théorème FLP sur l'impossibilité du consensus déterministe en système asynchrone, et les stealthy Byzantine attacks rappellent que les garanties absolues n'existent pas. L'objectif n'est pas d'éliminer le risque, c'est d'en rendre l'exploitation suffisamment coûteuse pour que l'adversaire, même bien doté, préfère d'autres vecteurs.
2026-04-29 07:41:00 +02:00
---
## Références Bibliographiques
2026-05-27 16:17:00 +02:00
**[1] [Amir et al., 2011]** Amir, Y., Coan, B., Kirsch, J., & Lane, J. (2011). Prime: Byzantine Replication Under Attack. *IEEE Transactions on Dependable and Secure Computing*, 8(4), 564577.
**[2] [Baumgart & Meinert, 2007]** Baumgart, I., & Meinert, S. (2007). S/Kademlia: A practicable approach towards secure key-based routing. In *Proceedings of ICPADS 2007*, pp. 18.
**[3] [Brewer, 2000]** Brewer, E. A. (2000). Towards robust distributed systems. In *Proceedings of PODC 2000*, pp. 7.
**[4] [Cerf et al., 2007]** Cerf, V., et al. (2007). Delay-Tolerant Networking Architecture. *RFC 4838*, IETF.
**[5] [Daian et al., 2020]** Daian, P., et al. (2020). Flash Boys 2.0. In *Proceedings of the 2020 IEEE S&P*, pp. 910927.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[6] [Das et al., 2002]** Das, A., Gupta, I., & Motivala, A. (2002). SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol. In *Proceedings of DSN 2002*, pp. 303312.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[7] [Douceur, 2002]** Douceur, J. R. (2002). The Sybil Attack. In *Proceedings of IPTPS 2002*, LNCS 2429, pp. 251260.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[8] [Fall, 2003]** Fall, K. (2003). A delay-tolerant network architecture for challenged internets. In *Proceedings of SIGCOMM 2003*, pp. 2734.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[9] [Fischer, Lynch & Paterson, 1985]** Fischer, M. J., Lynch, N. A., & Paterson, M. S. (1985). Impossibility of distributed consensus with one faulty process. *JACM*, 32(2), 374382.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[10] [Gilbert & Lynch, 2002]** Gilbert, S., & Lynch, N. (2002). Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services. *ACM SIGACT News*, 33(2), 5159.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[11] [Heilman et al., 2015]** Heilman, E., et al. (2015). Eclipse Attacks on Bitcoin's Peer-to-Peer Network. In *Proceedings of the 24th USENIX Security Symposium*, pp. 129144.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[12] [Kwon, 2014]** Kwon, J. (2014). *Tendermint: Consensus without Mining*. Draft whitepaper.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[13] [Kwon & Buchman, 2016]** Kwon, J., & Buchman, E. (2016). *Cosmos: A Network of Distributed Ledgers*. Whitepaper.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[14] [Lamport, Shostak & Pease, 1982]** Lamport, L., Shostak, R., & Pease, M. (1982). The Byzantine Generals Problem. *ACM TOPLAS*, 4(3), 382401.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[15] [Luu et al., 2016]** Luu, L., et al. (2016). Making Smart Contracts Smarter. In *Proceedings of CCS 2016*, pp. 254269.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[16] [Maymounkov & Mazières, 2002]** Maymounkov, P., & Mazières, D. (2002). Kademlia: A Peer-to-Peer Information System Based on the XOR Metric. In *Proceedings of IPTPS 2002*, LNCS 2429, pp. 5365.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[17] [Meiklejohn et al., 2013]** Meiklejohn, S., et al. (2013). A Fistful of Bitcoins. In *Proceedings of IMC 2013*, pp. 127140.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[18] [Murdoch & Danezis, 2005]** Murdoch, S. J., & Danezis, G. (2005). Low-Cost Traffic Analysis of Tor. In *Proceedings of the 2005 IEEE S&P*, pp. 183195.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[19] [Nakamoto, 2008]** Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[20] [Penumbra Labs, 2022]** Penumbra Labs (2022). *Penumbra: A Fully Private Proof-of-Stake Network for the Cosmos Ecosystem*. Technical specification. https://penumbra.zone
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[21] [Perrin, 2018]** Perrin, T. (2018). *The Noise Protocol Framework*. https://noiseprotocol.org/noise.pdf
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[22] [Rhea et al., 2004]** Rhea, S., et al. (2004). Handling Churn in a DHT. In *Proceedings of USENIX ATC 2004*, pp. 127140.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[23] [Singh et al., 2006]** Singh, A., Castro, M., Druschel, P., & Rowstron, A. (2006). Defending against Eclipse attacks on overlay networks. In *Proceedings of the 11th ACM SIGOPS European Workshop*, article 21.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[24] [Stoica et al., 2003]** Stoica, I., et al. (2003). Chord: A scalable peer-to-peer lookup protocol for internet applications. *IEEE/ACM Transactions on Networking*, 11(1), 1732.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[25] [Sun et al., 2015]** Sun, Y., et al. (2015). RAPTOR: Routing Attacks on Privacy in Tor. In *Proceedings of the 24th USENIX Security Symposium*, pp. 271286.
2026-04-29 07:41:00 +02:00
2026-05-27 16:17:00 +02:00
**[26] [Szabo, 1997]** Szabo, N. (1997). Formalizing and securing relationships on public networks. *First Monday*, 2(9).