Heutzutage hat wirklich jeder über Blockchain-Technologie, Kryptowährungen und deren Vorteile geschrieben. Doch in diesem Artikel geht es nicht um das Lob dieser Technologie, sondern um ihre Schwächen und Lösungen, um diese zu beheben.

Während der Arbeit an einem Projekt bei Altirix Systems entstand die Anforderung eines sicheren, zensurresistenten Datenbestätigungsmechanismus aus einer externen Blockchain-Quelle. Es war notwendig, Änderungen in den Einträgen eines dritten Systems zu validieren und auf Basis dieser Änderungen verschiedene Logikzweige in den Smart Contracts auszuführen. Auf den ersten Blick scheint diese Aufgabe simpel zu sein, doch wenn das Ergebnis erhebliche finanzielle Konsequenzen für eine der beteiligten Parteien hat, entstehen zusätzliche Anforderungen. Vor allem ist ein umfassendes Vertrauen in einen solchen Validierungsmechanismus notwendig. Aber alles der Reihe nach.

Das Problem besteht darin, dass die Blockchain selbst ein autonomes, geschlossenes System ist, weshalb Smart Contracts innerhalb der Blockchain keine Informationen über die Außenwelt haben. Gleichzeitig beziehen sich die Bedingungen von Smart Contracts häufig auf Informationen über reale Dinge (z.B. Flugverspätungen, Wechselkurse usw.). Damit Smart Contracts korrekt funktionieren, muss die von außerhalb der Blockchain erhaltene Information zuverlässig und verifiziert sein. Dieses Problem wird durch den Einsatz von Orakeln wie Town Crier und DECO gelöst. Diese Orakel ermöglichen es Smart Contracts im Blockchain-Netzwerk, Informationen von einem vertrauenswürdigen Webserver zu akzeptieren, man kann sagen, dass sie zuverlässige Informationsanbieter sind.

Orakel

Stellen Sie sich vor, ein Smart Contract überweist 0,001 BTC auf Ihre Bitcoin-Brieftasche, wenn Ihr Lieblingsfußballverein den russischen Pokal gewinnt. Im Falle eines tatsächlichen Sieges muss der Smart Contract Informationen über den gewonnenen Verein übermitteln, und hier stellen sich einige Probleme: Woher bekommt man diese Informationen, wie werden sie sicher an den Smart Contract übertragen und wie kann man sicherstellen, dass die Informationen, die in den Smart Contract gelangen, tatsächlich der Realität entsprechen?

In Bezug auf Informationsquellen gibt es zwei Szenarien: Die Verbindung eines Smart Contracts mit einer vertrauenswürdigen Website, auf der die Informationen über die Spielergebnisse zentral gespeichert sind, oder die Verbindung mehrerer Websites, um Informationen aus den meisten Quellen auszuwählen, die dieselben Daten bereitstellen. Um die Richtigkeit der Informationen zu verifizieren, werden Orakel verwendet, wie zum Beispiel Oraclize, das TLSNotary nutzt (eine Modifikation von TLS zur Authentifizierung von Daten). Informationen über Oraclize sind recht häufig in Google zu finden, und es gibt einige Artikel auf Habré. Heute möchte ich jedoch über Orakel berichten, die einen etwas anderen Ansatz bei der Informationsübertragung verwenden: Town Crier und DECO. Der Artikel bietet eine Beschreibung der Funktionsweise beider Orakel sowie einen detaillierten Vergleich.

Town Crier

Town Crier (TC) wurde 2016 auf der CCS’16 von der Initiative for CryptoCurrencies and Contracts (IC3) vorgestellt. Die Hauptidee von TC ist es, Informationen von der Webseite an den Smart Contract zu übermitteln und sicherzustellen, dass die übermittelten Informationen identisch mit denen auf der Webseite sind. TC nutzt eine TEE (Trusted Execution Environment), um die Eigentümerschaft der Daten zu authentifizieren. In der ursprünglichen Version beschreibt TC die Zusammenarbeit mit Intel SGX.
Town Crier besteht aus einem Teil innerhalb der Blockchain und einem Teil innerhalb des Betriebssystems — TC Server.

Der TC Contract befindet sich in der Blockchain und fungiert als Frontend für TC. Er empfängt Anfragen vom CU (User Smart Contract) und gibt Antworten vom TC Server zurück. Innerhalb des TC Servers gibt es ein Relay, das eine Verbindung zwischen dem Enklave und dem Internet (bidirektionaler Datenverkehr) herstellt und das Enklave mit der Blockchain verbindet. Die Enklave enthält progencl, das den Code darstellt, der Anfragen aus der Blockchain bearbeitet und Nachrichten mit einer digitalen Signatur an die Blockchain zurücksendet. Progencl enthält Teile des Codes des Smart Contracts und führt im Wesentlichen einige seiner Funktionen aus.

Der Intel SGX-Enklave kann als eine gemeinsame Bibliothek mit einer API betrachtet werden, die über ecall funktioniert. Ecall überträgt die Kontrolle an die Enklave. Die Enklave führt ihren Code aus, bis sie abgeschlossen ist oder eine Ausnahme auftritt. Um Funktionen aufzurufen, die außerhalb der Enklave definiert sind, werden ocalls verwendet. Ocall wird außerhalb der Enklave durchgeführt und als unsicherer Aufruf behandelt. Nach der Ausführung von ocall wird die Kontrolle an die Enklave zurückgegeben.

Im Enklaven-Teil wird ein sicherer Kanal mit dem Webserver eingerichtet, die Enklave führt selbst das TLS-Handshake mit dem Zielserver durch und führt alle kryptografischen Operationen intern aus. Die TLS-Bibliothek (mbedTLS) und der HTTP-Code wurden in einer reduzierten Version in die SGX-Umgebung exportiert. Außerdem enthält die Enklave Root-CA-Zertifikate (eine Sammlung von Zertifikaten), um die Zertifikate von Remote-Servern zu überprüfen. Der Request Handler nimmt eine Datagrammanfrage im von Ethereum bereitgestellten Format entgegen, entschlüsselt sie und analysiert sie. Dann wird eine Ethereum-Transaktion generiert, die das angeforderte Datagramm enthält, mit skTC signiert und an das Relay übermittelt.

Der Relay umfasst das Client Interface, TCP und das Blockchain Interface. Das Client Interface ist notwendig für die Attestierung des Enklaven-Codes und die Kommunikation mit dem Client. Der Client sendet einen Attestierungsantrag über ecall und erhält einen mit skTC signierten Zeitstempel zusammen mit att (der Attestierungsunterschrift). Anschließend wird att über den Intel Attestation Service (IAS) bestätigt und der Zeitstempel durch einen vertrauenswürdigen Zeitdienst überprüft. Das Blockchain Interface prüft die eingehenden Anfragen und platziert Transaktionen in die Blockchain zur Lieferung von Datagrammen. Geth ist der offizielle Ethereum-Client und ermöglicht es Relay, über RPC-Calls mit der Blockchain zu interagieren.

Durch die Arbeit mit TEE ermöglicht TC das gleichzeitige Ausführen mehrerer Enklaven, wodurch die Informationsverarbeitungsgeschwindigkeit um das Dreifache erhöht wird. Bei einem laufenden Enklaven betrug die Geschwindigkeit 15 tx/sec; wenn jedoch 20 Enklaven parallel gestartet werden, steigt die Geschwindigkeit auf 65 tx/sec. Zum Vergleich: Die maximale Geschwindigkeit im Bitcoin-Blockchain beträgt 26 tx/sec.

DECO

DECO (Decentralized Oracles for TLS) wurde auf der CCS’20 vorgestellt und funktioniert mit Websites, die TLS-Verbindungen unterstützen. Es gewährleistet die Vertraulichkeit und Integrität der Daten.
DECO c TLS verwendet symmetrische Verschlüsselung, wodurch der Client und der Webserver über Verschlüsselungsschlüssel verfügen. Der Client kann, wenn er möchte, die TLS-Sitzungsdaten fälschen. Um dieses Problem zu lösen, nutzt DECO ein dreiseitiges Handshake-Protokoll zwischen prover (Smart Contract), verifier (Oracle) und web-server (Datenquelle).

Der DECO-Mechanismus besteht darin, dass der Prüfer (prover) einen Teil der Daten D erhält und dem Verifizierer (verifier) bestätigt, dass D vom TLS-Server S stammt. Ein weiteres Problem ist, dass TLS keine Daten signiert und es für den TLS-Client schwierig ist zu beweisen, dass die Daten tatsächlich von diesem Server stammen (Provenance-Schwierigkeit).

Im DECO-Protokoll werden die Verschlüsselungsschlüssel KEnc und KMac verwendet. Der Client sendet eine Anfrage Q an Webserver, die Antwort des Servers R kommt in verschlüsselter Form, aber sowohl der Client als auch der Server besitzen dieselben KMac, und der Client kann die TLS-Nachricht fälschen. Die Lösung von DECO besteht darin, KMac vor dem Client (prover) zu "verstecken", bis dieser auf die Anfrage antwortet. KMac wird nun zwischen prover und verifier geteilt — KpMac und KvMac. Der Server erhält KMac zur Verschlüsselung der Antwort durch die Operation über die Schlüsselanteile KpMac ⊕ KvMac = KMac.

Durch die Einrichtung eines dreifachen Handshakes wird der Datenaustausch zwischen Client und Server mit einer Sicherheitsgarantie durchgeführt.

Wenn wir über dezentrale Orakelsysteme sprechen, ist Chainlink nicht zu vernachlässigen, das darauf abzielt, ein dezentrales Netzwerk von Orakel-Knoten zu schaffen, das mit Ethereum, Bitcoin und Hyperledger kompatibel ist und Modularität berücksichtigt: Jeder Teil des Systems kann aktualisiert werden. Um die Sicherheit zu gewährleisten, bietet Chainlink jedem Orakel, das an einer Aufgabe teilnimmt, eine Kombination aus Schlüssel (öffentlich und privat) an. Der private Schlüssel wird verwendet, um eine partielle Unterschrift zu erzeugen, die ihre Lösung auf die Datenanforderung enthält. Um eine Antwort zu erhalten, müssen alle partiellen Unterschriften der Orakel im Netzwerk kombiniert werden.

Chainlink plant die Durchführung eines ersten PoC DECO mit dem Fokus auf dezentrale Finanzanwendungen wie Mixicles. Zum Zeitpunkt der Veröffentlichung des Artikels gab es Neuigkeiten auf Forbes, dass Chainlink DECO von der Cornell University erworben hat.

Angriffe auf Orakel

Aus Sicht der Informationssicherheit wurden folgende Angriffe auf Town Crier betrachtet:

1. Schadhafter Smart Contract Code-Injektion auf TEE-Knoten.
   Die Angriffsmethode besteht darin, fehlerhaften Code für den Smart Contract im TEE zu übermitteln. Ein Angreifer, der Zugriff auf einen Knoten hat, kann somit seinen eigenen (betrügerischen) Smart Contract auf die entschlüsselten Daten ausführen. Allerdings werden die zurückgegebenen Werte mit dem privaten Schlüssel verschlüsselt, und der einzige Zugang zu diesen Daten besteht in der Möglichkeit, den verschlüsselten Text beim Rückgabe-/Ausgabeprozess abzugreifen.
   Der Schutz vor diesem Angriff liegt in der Überprüfung des Codes durch den Enklave, der sich an der aktuellen Adresse befindet. Dies kann erreicht werden, indem man ein Adressierungsschema verwendet, bei dem die Adresse des Vertrags durch Hashing des Vertragcodes bestimmt wird.

2. Änderungen des chiffrierten Vertragsstatus ermöglichen Leaks.
   Die Angriffsmethode: Knotenbetreiber, auf denen Smart Contracts ausgeführt werden, haben Zugriff auf den contract state in verschlüsselter Form außerhalb der Enklave. Ein Angreifer, der die Kontrolle über den Knoten erlangt hat, kann den contract state vor und nach der Ausführung einer Transaktion vergleichen und so erkennen, welche Argumente eingereicht wurden und welche Methoden des Smart Contracts verwendet wurden, da der Code des Smart Contracts und seine technischen Spezifikationen öffentlich zugänglich sind.
   Schutz zur Gewährleistung der Zuverlässigkeit des Knotens selbst.

3. Seitenkanalangriffe.
   Eine spezielle Art von Angriffen, die das Monitoring des Zugriffs auf den Speicher und den Cache des Enklaven in verschiedenen Szenarien nutzt. Ein Beispiel für einen solchen Angriff ist Prime and Probe.
   
   Ablauf des Angriffs:

   • t0: Der Angreifer füllt den gesamten Daten-Cache des Opfers.
   • t1: Das Opfer führt Code aus, der auf den Speicher zugreift, abhängig von sensiblen Daten des Opfers (kryptografische Schlüssel). Die Auswahl der Cache-Zeile erfolgt basierend auf dem Wert des keybit. Im Beispiel auf der Abbildung ist keybit = 0, und die Adresse X in Cache-Zeile 2 wurde gelesen. Die Daten, die in X gespeichert sind, werden in den Cache geladen und verdrängen die zuvor darin gespeicherten Daten.
   • t2: Der Angreifer überprüft, welche seiner Cache-Zeilen verdrängt wurden - die von dem Opfer verwendeten Zeilen. Dies geschieht durch Messung der Zugriffszeit. Indem er diesen Vorgang für jedes keybit wiederholt, erhält der Angreifer den gesamten Schlüssel.

Schutz gegen den Angriff: Intel SGX verfügt über Schutzmaßnahmen gegen Seitenkanalangriffe, die das Monitoring von Cache-bezogenen Ereignissen verhindern. Dennoch wird der Prime and Probe-Angriff durchgehen, da der Angreifer die Cache-Ereignisse seines Prozesses beobachtet und den Cache mit dem Opfer teilt.

Derzeit gibt es keinen zuverlässigen Schutz gegen diesen Angriff.

Es sind auch Angriffe vom Typ Spectre und Foreshadow (L1TF) bekannt, die ähnlich wie Prime and Probe funktionieren. Diese ermöglichen es, Daten aus dem Cache über einen Seitenkanal zu lesen. Es gibt Schutzmaßnahmen gegen die Schwachstelle Spectre-v2, die gegen diese beiden Angriffe wirken.

Im Hinblick auf DECO gewährleistet das dreiseitige Handshake die Sicherheit:

1. Prover-Integrität: Ein gehackter Prover kann keine Informationen über die Herkunft des Servers fälschen und kann den Server nicht dazu bringen, ungültige Anfragen anzunehmen oder fälschlicherweise auf gültige Anfragen zu reagieren. Dies wird durch Anfrage-Templates zwischen dem Server und dem Prover umgesetzt.
2. Verifier-Integrität: Ein gehackter Verifier kann den Prover nicht dazu bringen, falsche Antworten zu erhalten.
3. Vertraulichkeit: Ein gehackter Verifier untersucht nur öffentliche Informationen (Anfrage, Servername).

In DECO sind nur Schwachstellen im Zusammenhang mit Traffic-Injektionen möglich. Zu Beginn des dreiseitigen Handshakes kann der Verifier die Identität des Servers mittels eines frischen Nonces bestätigen. Nach dem Handshake muss der Verifier jedoch auf Netzwerk-Level-Indikatoren vertrauen.IP-Adressen). Somit sollte die Verbindung zwischen dem Verifier und dem Server vor Traffic-Injection geschützt werden. Dies wird durch den Einsatz eines Proxys erreicht.

Vergleich der Orakel

Town Crier basiert auf der Arbeit mit einem Enklave im Serverbereich, während DECO eine Authentifizierung der Herkunft von Daten durch ein dreiseitiges Handshake und Datenverschlüsselung mit kryptografischen Schlüsseln ermöglicht. Der Vergleich der Dateneorakel erfolgte anhand folgender Kriterien: Leistung, Sicherheit, Kosten und Praktikabilität.

Town Crier
DECO

Leistung
Schneller (0,6 s bis zum Abschluss)
Langsam (10,50 s bis zum Abschluss des Protokolls)

Sicherheit
Weniger sicher
Sicherer

Kosten
Teurer
Günstiger

Praktikabilität
Benötigt spezielle Hardware
Funktioniert mit jedem Server, der TLS unterstützt

Leistung: Um mit DECO zu arbeiten, ist eine Dreipunkt-Handschlag-Konfiguration erforderlich. Bei der Einrichtung über LAN dauert dies 0,37 Sekunden. Für den Austausch nach der Verbindungsherstellung ist 2PC-HMAC effektiv (0,13 s zum Schreiben). Die Leistung von DECO hängt von den verfügbaren TLS-Verschlüsselungs-sets, der Größe der persönlichen Daten und der Komplexität der Beweise für die jeweilige Anwendung ab. Am Beispiel der Binary Options-App von IC3: der Abschluss des Protokolls über LAN dauert etwa 10,50 s. Zum Vergleich benötigt Town Crier für die Ausführung einer ähnlichen Anwendung etwa 0,6 Sekunden, was ungefähr 20 Mal schneller ist als DECO. Bei gleichen Bedingungen wird TC schneller sein.

Sicherheit: Angriffe auf den Intel SGX-Enclave (Seitenkanalangriffe) funktionieren und können den Teilnehmern von Smart Contracts echten Schaden zufügen. Bezüglich DECO sind Angriffe durch Traffic-Injection möglich, aber die Verwendung von Proxys mitigiert solche Angriffe. Daher ist DECO sicherer.

Kosten: Die Kosten für die Hardware, die mit Intel SGX arbeitet, sind höher als die Einrichtungskosten des DECO-Protokolls. Daher ist TC teurer.

Praktikabilität: Um mit Town Crier zu arbeiten, ist spezielle Hardware erforderlich, die TEE unterstützt. Zum Beispiel wird Intel SGX auf Prozessoren der Intel Core 6. Generation und neuer unterstützt. DECO hingegen kann mit beliebiger Hardware arbeiten, obwohl es eine DECO-Konfiguration mit TEE gibt. Die Einrichtung des dreiseitigen Handshakes bei DECO kann einige Zeit in Anspruch nehmen, aber das steht in keinem Vergleich zu den Hardwareeinschränkungen für TC, daher ist DECO die praktischere Lösung.

Fazit

Wenn man die beiden Orakel einzeln betrachtet und sie anhand von vier Kriterien vergleicht, wird deutlich, dass Town Crier in drei von vier Punkten hinter DECO zurückbleibt. DECO ist aus Sicht der Informationssicherheit zuverlässiger, kostengünstiger und praktischer, obwohl die Einrichtung des dreiseitigen Protokolls einige Zeit in Anspruch nehmen kann und auch ihre Nachteile hat, wie zusätzliche Operationen mit Verschlüsselungsschlüsseln. TC arbeitet schneller als DECO, jedoch macht die Verletzlichkeit durch Angriffe über Seitenkanäle es anfällig für den Verlust der Vertraulichkeit. Man muss beachten, dass DECO im Januar 2020 vorgestellt wurde und noch nicht genügend Zeit vergangen ist, um es als sicher zu betrachten. Town Crier sieht sich bereits seit 4 Jahren Angriffen ausgesetzt und hat zahlreiche Prüfungen bestanden, weshalb der Einsatz in vielen Projekten gerechtfertigt ist.

Quelle: habr.com