
Chaincode für die Blockchain Hyperledger Fabric bietet anderen Chaincodes eine genaue Zeit. Somit wird das Sicherheitsproblem im Zusammenhang mit der Manipulation der Transaktionszeit gelöst (CVE-2024-45244).
hlf-time-oracle ist ein Chaincode für die Blockchain Hyperledger Fabric, der anderen Chaincodes eine genaue Zeit liefert. hlf-time-oracle basiert auf dem ntp-Paket und dem nts-Paket. Damit wird das Sicherheitsproblem gelöst, das mit der möglichen Manipulation der Transaktionszeit durch den Blockchain-Client verbunden ist (CVE-2024-45244). Der Chaincode bietet die Funktionen GetTimeNtp() und GetTimeNts(). Der Aufruf dieser Funktionen erzeugt einen Aufruf an die NTP- (Network Time Protocol) und NTS-Server (Network Time Security). Die von einem dieser Server empfangene Zeit kann verwendet werden, um die Korrektheit der auf der Clientseite festgelegten Transaktionszeit zu überprüfen. Entwickler von Chaincodes für die Blockchain können hlf-time-oracle verwenden, anstatt unabhängig Code für die Interaktion mit NTP- und NTS-Servern zu schreiben. hlf-time-oracle speichert während seines Betriebs keine Daten in der Blockchain.
hlf-time-oracle für Hyperledger Fabric Version 2.4.x im Ordner hlf_2.4. hlf-time-oracle für Hyperledger Fabric Version 2.5.x im Ordner hlf_2.5.
Lösung des Zentralisierungsproblems
Die Funktionen des NTS-Protokolls
Resistenz gegen den Man-in-the-Middle-Angriff
Wenn Sie nicht von einem einzelnen Zeitserver abhängig sein möchten, können Sie mehrere Zeit-Orakel verwenden.
Orakel
NTS ist eine Erweiterung von NTP (siehe RFC 8915). Es gibt 2 Verbindungen: TCP für TLS und UDP für NTP. Der Port für die NTP-Verbindung wird vom NTS-Server bestimmt. Er kann vom Standard 123/UDP abweichen. Beachten Sie dies bei der Konfiguration der Firewall.
Für den korrekten TLS-Verbindungsaufbau ist es erforderlich, dass der Client (d.h. das System, auf dem hlf-time-oracle ausgeführt wird) eine relativ korrekte Systemzeit hat (die innerhalb der Gültigkeitsdauer des NTS-Server-Zertifikats liegt). Andernfalls wird die Verbindung nicht aufgebaut.
Es wird empfohlen, GetTimeNts() anstelle von GetTimeNtp() zu verwenden. Im Gegensatz zu NTP ist die Verwendung von NTS resistent gegen Man-in-the-Middle-Angriffe. Im Falle einer unbefugten Fälschung des offenen Datenteils wird der folgende Fehler protokolliert: authentication failed on client. Im Falle eines Versuchs, das NTS-Server-Zertifikat zu fälschen, wird der folgende Fehler protokolliert: key exchange failure: tls: failed to verify certificate: x509: certificate signed by unknown authority.
Modell
hlf-time-oracle läuft im Docker (Docker-Netzwerk 172.18.0.0/24). Auf dem Docker-Host (Host_1) laufen netsed (Port 4000/UDP) und mitmproxy (Port 8080/TCP). Der Datenverkehr von hlf-time-oracle zu ihnen wird über iptables geleitet. Der zweite Host (Host_2) greift auf die Funktionen GetTimeNtp() und GetTimeNts() des Orakels zu (über Aufruf von peer chaincode query). Der Aufruf dieser Funktionen veranlasst das Orakel, den NTP-Server bzw. den NTS-Server aufzurufen.
Eine iptables-Regel zur Umleitung des Datenverkehrs zu 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
Ausführen von netsed mit einer Regel.
Erstellen Sie eine Regel in netsed, um %ea%33 durch %eF%33 zu ersetzen
Das Ergebnis eines erfolgreichen Angriffs.
Eine iptables-Regel zur Umleitung des Datenverkehrs zu netsed (NTS-Server ntp1.glypnod.com hat die IP-Adresse 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
Ausführen von netsed mit einer Regel.
Erstellen Sie eine Regel in netsed, um %ea%33 durch %eF%33 zu ersetzen
Das Ergebnis eines erfolglosen Angriffs.
Sehen wir uns die Docker-Protokolle an:
Docker-Protokolle
Eine iptables-Regel zur Umleitung des Datenverkehrs zu mitmproxy (NTS-Server ntp1.glypnod.com hat die IP-Adresse 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
Sehen wir uns die mitmproxy-Protokolle an:
mitmproxy-Protokolle
Sehen wir uns die Docker-Protokolle an:
Docker-Protokolle
MIT