
Chaincode pour la blockchain Hyperledger Fabric fournit une heure précise aux autres chaincodes. Résolvant ainsi le problème de sécurité lié à la manipulation du temps de transaction (CVE-2024-45244).
hlf-time-oracle est un chaincode pour la blockchain Hyperledger Fabric qui fournit une heure précise aux autres chaincodes. hlf-time-oracle basé sur le paquet ntp et le paquet nts. Résolvant ainsi le problème de sécurité lié à une éventuelle manipulation de l'heure de transaction par le client blockchain (CVE-2024-45244). Le chaincode fournit les fonctions GetTimeNtp() et GetTimeNts(). L'appel de ces fonctions crée un appel aux serveurs NTP (Network Time Protocol) et NTS (Network Time Security). L'heure reçue de l'un de ces serveurs peut être utilisée pour vérifier l'exactitude de l'heure de transaction définie côté client. Les développeurs de chaincodes pour blockchain peuvent utiliser hlf-time-oracle au lieu d'écrire indépendamment du code pour interagir avec les serveurs NTP et NTS. hlf-time-oracle n'enregistre aucune donnée dans la blockchain pendant son fonctionnement.
hlf-time-oracle pour Hyperledger Fabric version 2.4.x dans le dossier hlf_2.4. hlf-time-oracle pour Hyperledger Fabric version 2.5.x dans le dossier hlf_2.5.
Résolution du problème de centralisation
Les fonctionnalités du protocole NTS
Résistance à l'attaque de l'homme du milieu
Si vous ne souhaitez pas dépendre d'un seul serveur de temps, vous pouvez utiliser plusieurs oracles de temps.
Oracles
NTS est une amélioration de NTP (voir RFC 8915). Il y a 2 connexions : TCP pour TLS et UDP pour NTP. Le port pour la connexion NTP est déterminé par le serveur NTS. Il peut être différent du standard 123/UDP. Gardez cela à l'esprit lors de la configuration du pare-feu.
Pour un établissement correct de la connexion TLS, il est nécessaire que le client (c'est-à-dire le système sur lequel hlf-time-oracle s'exécute) ait une heure système relativement correcte (se situant dans la période de validité du certificat du serveur NTS). Sinon, la connexion ne sera pas établie.
Il est recommandé d'utiliser GetTimeNts() au lieu de GetTimeNtp(). Contrairement à NTP, l'utilisation de NTS résiste à l'attaque de l'homme du milieu. En cas d'usurpation non autorisée de la partie de données ouvertes, l'erreur suivante est enregistrée : authentication failed on client. En cas de tentative d'usurpation du certificat du serveur NTS, l'erreur suivante est enregistrée : key exchange failure: tls: failed to verify certificate: x509: certificate signed by unknown authority.
Modèle
hlf-time-oracle s'exécute dans le docker (réseau docker 172.18.0.0/24). Sur l'hôte docker (Host_1), netsed (port 4000/UDP) et mitmproxy (port 8080/TCP) sont en cours d'exécution. Le trafic vers eux depuis hlf-time-oracle passera par iptables. Le second hôte (Host_2) accède aux fonctions GetTimeNtp() et GetTimeNts() de l'Oracle (via un appel peer chaincode query). L'appel de ces fonctions fait que l'Oracle appelle respectivement le serveur NTP et le serveur NTS.
Une règle iptables pour rediriger le trafic vers netsed :
iptables -t nat -A PREROUTING -s 172.18.0.0/24 -d 213.234.203.30/32 -p udp -m udp --dport 123 -m udp -j REDIRECT --to-ports 4000
Exécutez netsed avec la règle.
Créez une règle dans netsed pour remplacer %ea%33 par %eF%33
Le résultat d'une attaque réussie.
Une règle iptables pour rediriger le trafic vers netsed (le serveur NTS ntp1.glypnod.com a une adresse IP 104.131.155.175) :
iptables -t nat -A PREROUTING -s 172.18.0.0/24 -d 104.131.155.175/32 -p udp -m udp --dport 8123 -m udp -j REDIRECT --to-ports 4000
Exécutez netsed avec la règle.
Créez une règle dans netsed pour remplacer %ea%33 par %eF%33
Le résultat d'une attaque infructueuse.
Voyons les logs docker :
Logs Docker
Une règle iptables pour rediriger le trafic vers mitmproxy (le serveur NTS ntp1.glypnod.com a une adresse IP 104.131.155.175) :
iptables -t nat -A PREROUTING -p tcp -s 172.18.0.0/24 --dport 4460 -m tcp -d 104.131.155.175 -j REDIRECT --to 8080
Voyons les logs mitmproxy :
Logs mitmproxy
Voyons les logs docker :
Logs Docker
MIT