Aller au contenu principal

Modèle de Sécurité

Primitives Cryptographiques​

PrimitiveAlgorithmeUtilisation
SignaturesEd25519 (ed25519-dalek)Signature de transactions, signature de blocs
Hachage de blocsSHA-512Hachage de bloc avec balise de domaine "BLK"
Hachage de transactionsSHA-256Hachage du message de signature
Hachage d'étatBLAKE3Calcul de la racine d'état
Hachage de stockageKeccak256Dérivation des emplacements de stockage des contrats
Compressionsnap, lz4Compression des messages P2P

Sécurité du Transport​

Couche P2P​

  • Chiffrement : Protocole Noise de libp2p (chiffrement authentifié)
  • Multiplexage : Yamux
  • Identité : Clés de pairs Ed25519
  • Taille maximale de transmission : 256 Ko par message

Couche RPC​

  • TLS : Non terminé par le serveur RPC. Les déploiements en production doivent utiliser un proxy inverse avec terminaison TLS.
  • CORS : Restreint aux origines localhost. Configurer les origines autorisées pour la production.
  • Limite du corps : Maximum 1 Mo pour le corps de la requête.

Limitation du Débit​

CoucheLimiteFenêtre
RPC global200 req/sFenêtre glissante de 1 seconde
RPC par IP50 req/sFenêtre glissante de 1 seconde
Taille de lot100 requêtesPar requête HTTP
Scan de hachage de bloc1000 blocsPar appel chain_getBlockByHash

Validation des Entrées​

RPC​

  • La version JSON-RPC doit être exactement "2.0"
  • Les messages d'erreur sont assainis avant d'être retournés aux clients
  • Les erreurs internes retournent des messages génériques (pas de traces de pile ni de formats internes)
  • Les détails de rejet du mempool sont supprimés des réponses d'erreur

Mempool​

  • Validation du nonce : Nonces séquentiels requis (tolérance d'écart jusqu'à 5000 pour la récupération en rafale)
  • Vérification du solde : L'expéditeur doit avoir un solde suffisant pour le montant + les frais
  • Vérification de signature : Signature Ed25519 vérifiée avant admission
  • Système de quotas : Limites par classe (Finance : 50K, IoT : 100K, Global : 100K)
  • Limite par expéditeur : Maximum 512 transactions en attente par expéditeur

Pipeline de Transactions​

Gardes sans état (exécutés en premier) :

  1. Validation du format de signature
  2. Vérification de la signature Ed25519
  3. Vérification de la dérivation clé publique → adresse

Gardes avec état (exécutés après le passage sans état) :

  1. Nonce >= nonce du compte
  2. Solde >= montant + frais
  3. Compte non mis sur liste noire

Commit atomique : la déduction du solde et l'incrémentation du nonce se produisent de manière atomique.

Sécurité du Consensus​

Quorum BFT​

  • Quorum : 2f+1 (67 %) des validateurs doivent signer le Certificat d'Acceptation de Bloc
  • Tolérance byzantine : Jusqu'à f = (n-1)/3 nœuds byzantins
  • Vérification des certificats : Les masternodes vérifient toutes les signatures d'attestation

Anti-Manipulation PoU​

  • Lissage du score : La moyenne mobile exponentielle empêche la manipulation du score via un comportement transitoire
  • Rotation du proposant : Après 50 blocs, le proposant doit céder la place (prévient le monopole)
  • Seuil de score minimum : Score < 300 disqualifie des récompenses

Sécurité des Élections​

  • Identifiants de groupe déterministes : Basés sur l'époque, non sur l'horloge murale (évite le désaccord entre MN)
  • Déduplication des élections : Seul le premier résultat par session est validé
  • Rejet doux des groupes inconnus : Les masternodes avertissent mais continuent le traitement pour les identifiants de groupe inconnus

Gestion des Clés​

Portefeuille SDK​

  • Zéroïsation : Les clés privées sont zéroïsées à la libération (via la crate zeroize)
  • Pas de persistance : Le portefeuille SDK n'enregistre pas les clés sur disque
  • Application HTTPS : Les points de terminaison RPC distants nécessitent HTTPS par défaut

Faucet​

  • Clés en rotation : 10 paires de clés rotatives pour éviter la contention de nonce
  • Réclamations sérialisées : Le mutex faucet_lock empêche les conditions de course TOCTOU
  • Limites de réclamation : 5 SAVT par réclamation, délai de 24 heures par adresse

Sécurité des Nœuds​

Vivacité des Pairs​

  • Keepalive Gossipsub : Le partage de score PoU publie via gossipsub pour rafraîchir last_seen
  • Délai d'inactivité : 600 secondes (configurable) avant suppression du pair
  • Déconnexion SlowPeer : Les nœuds sont déconnectés si la file d'envoi gossipsub est saturée

Limites des Ressources​

  • File du gestionnaire de connexion : 50 000 messages (LN + MN)
  • Maillage Gossipsub : mesh_n=8, mesh_n_high=12, mesh_n_low=4
  • Taille de pile : 8 Mo pour éviter le débordement de pile
  • Mémoire : Pools de mempool bornés avec contre-pression

Divulgation Responsable​

Signalez les vulnérabilités de sécurité via le processus de divulgation responsable du projet. Ne créez pas de tickets publics pour les bogues de sécurité.