Heutzutage haben nur die Faulen nicht über Blockchain-Technologie, Kryptowährungen und wie cool sie ist, geschrieben. In diesem Artikel wird diese Technologie jedoch nicht gelobt; wir werden über ihre Mängel und Möglichkeiten zu deren Beseitigung sprechen.

Bei der Arbeit an einem der Projekte bei Altirix Systems entstand die Aufgabe der sicheren, zensurresistenten Bestätigung von Daten aus einer Quelle außerhalb der Blockchain. Es war notwendig, Änderungen in den Datensätzen des dritten Systems zu bestätigen und basierend auf diesen Änderungen den einen oder anderen Zweig in der Smart-Contract-Logik auszuführen. Die Aufgabe ist auf den ersten Blick recht trivial, doch wenn die finanzielle Lage einer der am Prozess beteiligten Parteien vom Ergebnis der Umsetzung abhängt, ergeben sich zusätzliche Anforderungen. Dies ist zunächst einmal ein umfassendes Vertrauen in einen solchen Validierungsmechanismus. Aber das Wichtigste zuerst.

Das Problem besteht darin, dass die Blockchain selbst eine autonome, geschlossene Einheit ist, sodass die Smart Contracts innerhalb der Blockchain nichts über die Außenwelt wissen. Gleichzeitig beziehen sich die Bedingungen intelligenter Verträge häufig auf Informationen über reale Dinge (Flugverspätung, Wechselkurse usw.). Damit Smart Contracts ordnungsgemäß funktionieren, müssen die von außerhalb der Blockchain empfangenen Informationen zuverlässig und verifiziert sein. Dieses Problem wird durch die Verwendung von Orakeln wie Town Crier und DECO gelöst. Diese Orakel ermöglichen es einem Smart Contract im Blockchain-Netzwerk, Informationen von einem vertrauenswürdigen Webserver zu vertrauen; wir können sagen, dass es sich dabei um Anbieter zuverlässiger Informationen handelt.

Orakel

Stellen Sie sich vor, ein Smart Contract überträgt 0.001 BTC auf Ihr Bitcoin-Wallet, wenn Ihr Lieblingsfußballverein den russischen Pokal gewinnt. Im Falle eines echten Sieges muss der Smart Contract Informationen darüber übertragen, welcher Verein gewonnen hat, und hier treten eine Reihe von Problemen auf: Wo erhält man diese Informationen, wie überträgt man sie sicher an den Smart Contract und wie stellt man sicher, dass die Informationen vorliegen Ist der im Smart Contract empfangene Vertrag tatsächlich gültig und stimmt er mit der Realität überein?

Wenn es um die Informationsquelle geht, gibt es zwei Szenarien: die Verbindung eines Smart Contracts mit einer vertrauenswürdigen Website, auf der Informationen über Spielergebnisse zentral gespeichert werden, und die zweite Möglichkeit besteht darin, mehrere Websites gleichzeitig zu verbinden und dann Informationen aus den meisten Quellen auszuwählen die die gleichen Daten liefern. Um die Richtigkeit der Informationen zu überprüfen, werden Orakel verwendet, beispielsweise Oraclize, das TLSNotary (TLS Notary Modification to Prove the Authenticity of Data) verwendet. Aber es gibt bei Google genügend Informationen über Oraclize, und es gibt mehrere Artikel über Habré. Heute werde ich über Orakel sprechen, die einen etwas anderen Ansatz zur Übermittlung von Informationen verwenden: Town Crier und DECO. Der Artikel enthält eine Beschreibung der Funktionsprinzipien beider Orakel sowie einen detaillierten Vergleich.

Ausrufer

Town Crier (TC) wurde 3 von IC2016 (The Initiative for CryptoCurrencies and Contracts) auf der CCS'16 vorgestellt. Die Hauptidee von TC: Informationen von einer Website in einen Smart Contract übertragen und sicherstellen, dass die von TC gelieferten Informationen mit denen auf der Website identisch sind. TC verwendet TEE (Trusted Execution Environment) zur Authentifizierung des Dateneigentums. Die Originalversion von TC beschreibt die Arbeit mit Intel SGX.
Town Crier besteht aus einem Teil innerhalb der Blockchain und einem Teil innerhalb des Betriebssystems selbst – TC Server.

TC Contract befindet sich in der Blockchain und fungiert als Frontend für TC. Es akzeptiert Anfragen vom CU (User Smart Contract) und gibt eine Antwort vom TC-Server zurück. Im TC-Server befindet sich ein Relay, das eine Verbindung zwischen der Enklave und dem Internet herstellt (bidirektionaler Verkehr) und die Enklave mit der Blockchain verbindet. Enclave enthält Progencl, einen Code, der Anfragen von der Blockchain stellt und Nachrichten mit einer digitalen Signatur an die Blockchain zurücksendet. Progencl enthält einen Teil des Smart-Contract-Codes und führt im Wesentlichen einige seiner Funktionen aus.

Die Intel SGX-Enklave kann als gemeinsam genutzte Bibliothek mit einer API betrachtet werden, die über ecall ausgeführt wird. Ecall überträgt die Kontrolle an die Enklave. Die Enklave führt ihren Code aus, bis sie beendet wird oder bis eine Ausnahme auftritt. ocall wird verwendet, um Funktionen aufzurufen, die außerhalb der Enklave definiert sind. Ocall wird außerhalb der Enklave ausgeführt und von dieser als nicht vertrauenswürdiger Aufruf behandelt. Nachdem ocall ausgeführt wurde, wird die Kontrolle an die Enklave zurückgegeben.

Im Enklave-Teil wird ein sicherer Kanal mit einem Webserver konfiguriert, die Enklave selbst führt einen TLS-Handshake mit dem Zielserver durch und führt alle kryptografischen Operationen intern aus. Die TLS-Bibliothek (mbedTLS) und reduzierter HTTP-Code wurden in die SGX-Umgebung exportiert. Außerdem enthält Enclave Root-CA-Zertifikate (eine Sammlung von Zertifikaten), um die Zertifikate von Remote-Servern zu überprüfen. Der Request Handler akzeptiert eine Datagramm-Anfrage im von Ethereum bereitgestellten Format, entschlüsselt sie und analysiert sie. Anschließend generiert es eine Ethereum-Transaktion mit dem angeforderten Datagramm, signiert es mit skTC und übermittelt es an Relay.

Der Relay-Teil umfasst Client-Schnittstelle, TCP und Blockchain-Schnittstelle. Die Client-Schnittstelle wird benötigt, um den Enklavencode zu zertifizieren und mit dem Client zu kommunizieren. Der Client sendet eine Attestierungsanfrage über ecall und erhält einen von skTC signierten Zeitstempel zusammen mit att (Attestierungssignatur). Anschließend wird att mithilfe des Intel Attestation Service (IAS) überprüft und der Zeitstempel wird von einem vertrauenswürdigen Zeitdienst überprüft. Die Blockchain-Schnittstelle überprüft eingehende Anfragen und platziert Transaktionen auf der Blockchain zur Zustellung von Datagrammen. Geth ist ein offizieller Ethereum-Client und ermöglicht Relay die Interaktion mit der Blockchain über RPC-Aufrufe.

Durch die Zusammenarbeit mit TEE können Sie mit TC mehrere Enklaven parallel betreiben und so die Geschwindigkeit der Informationsverarbeitung um das Dreifache erhöhen. Wenn bei einer laufenden Enklave die Geschwindigkeit 3 tx/s betrug, dann erhöht sich die Geschwindigkeit bei 15 parallel laufenden Enklaven auf 20 tx/s; zum Vergleich: Die maximale Betriebsgeschwindigkeit in der Bitcoin-Blockchain beträgt 65 tx/s.

DECO

DECO (Decentralized Oracles for TLS) wurde auf der CCS'20 vorgestellt und funktioniert mit Websites, die TLS-Verbindungen unterstützen. Gewährleistet die Vertraulichkeit und Integrität der Daten.
DECO mit TLS verwendet symmetrische Verschlüsselung, sodass Client und Webserver über Verschlüsselungsschlüssel verfügen und der Client bei Bedarf TLS-Sitzungsdaten fälschen kann. Um dieses Problem zu lösen, verwendet DECO ein Drei-Wege-Handshake-Protokoll zwischen dem Prüfer (Smart Contract), dem Verifizierer (Oracle) und dem Webserver (Datenquelle).

Die Funktionsweise von DECO besteht darin, dass der Verifizierer ein Datenelement D empfängt und dem Verifizierer bestätigt, dass D vom TLS-Server S stammt. Ein weiteres Problem besteht darin, dass TLS die Daten nicht signiert und es für den TLS-Client schwierig ist, dies zu beweisen Daten wurden genau vom richtigen Server empfangen (Herkunftsschwierigkeit).

Das DECO-Protokoll verwendet KEnc- und KMac-Verschlüsselungsschlüssel. Der Client sendet eine Anfrage Q an den Webserver, die Antwort vom Server R kommt in verschlüsselter Form, aber Client und Server besitzen denselben KMac und der Client kann die TLS-Nachricht fälschen. Die Lösung von DECO besteht darin, den KMac vor dem Client (Prüfer) zu „verstecken“, bis dieser auf die Anfrage antwortet. Jetzt ist KMac in Prüfer und Verifizierer aufgeteilt – KpMac und KvMac. Der Server empfängt KMac, um die Antwort mithilfe der Schlüsselteiloperation KpMac ⊕ KvMac = KMac zu verschlüsseln.

Durch die Einrichtung eines Drei-Wege-Handshakes erfolgt der Datenaustausch zwischen Client und Server mit garantierter Sicherheit.

Wenn man von einem dezentralen Oracle-System spricht, darf man Chainlink nicht außer Acht lassen, das darauf abzielt, ein dezentrales Netzwerk von Oracle-Knoten zu schaffen, die mit Ethereum, Bitcoin und Hyperledger kompatibel sind und dabei die Modularität berücksichtigen: Jeder Teil des Systems kann aktualisiert werden. Um gleichzeitig die Sicherheit zu gewährleisten, bietet Chainlink jedem an der Aufgabe beteiligten Orakel an, eine Kombination von Schlüsseln (öffentlich und privat) auszugeben. Mit dem privaten Schlüssel wird eine Teilsignatur generiert, die ihre Entscheidung zur Datenanfrage enthält. Um eine Antwort zu erhalten, ist es notwendig, alle Teilsignaturen der Orakel des Netzwerks zu kombinieren.

Chainlink plant die Durchführung eines ersten PoC DECO mit Schwerpunkt auf dezentralen Finanzanwendungen wie Mixicles. Zum Zeitpunkt des Verfassens dieses Artikels wurde auf Forbes bekannt, dass Chainlink DECO von der Cornell University übernommen hat.

Angriffe auf Orakel

Aus Sicht der Informationssicherheit wurden folgende Angriffe auf Town Crier in Betracht gezogen:

1. Einschleusung betrügerischer Smart-Contact-Codes auf TEE-Knoten.
   Die Essenz des Angriffs: Übermittlung eines absichtlich falschen Smart-Contract-Codes an TEE, sodass ein Angreifer, der sich Zugriff auf den Knoten verschafft hat, seinen eigenen (betrügerischen) Smart-Contract auf den entschlüsselten Daten ausführen kann. Die Rückgabewerte werden jedoch mit einem privaten Schlüssel verschlüsselt, und die einzige Möglichkeit, auf solche Daten zuzugreifen, besteht darin, den Chiffretext bei der Rückgabe/Ausgabe preiszugeben.
   Der Schutz vor diesem Angriff besteht darin, dass die Enklave die Richtigkeit des Codes überprüft, der sich an der aktuellen Adresse befindet. Dies kann mithilfe eines Adressierungsschemas erreicht werden, bei dem die Vertragsadresse durch Hashing des Vertragscodes ermittelt wird.

2. Änderungen am Chiffretext des Vertragsstatus sind durchgesickert.
   Der Kern des Angriffs: Besitzer von Knoten, auf denen Smart Contracts ausgeführt werden, haben außerhalb der Enklave Zugriff auf den Vertragsstatus in verschlüsselter Form. Ein Angreifer, der die Kontrolle über einen Knoten erlangt hat, kann den Kontaktstatus vor und nach der Transaktion vergleichen und feststellen, welche Argumente eingegeben wurden und welche Smart-Contract-Methode verwendet wurde, da der Smart-Contract-Code selbst und seine technischen Spezifikationen öffentlich verfügbar sind.
   Schutz bei der Gewährleistung der Zuverlässigkeit des Knotens selbst.

3. Seitenkanalangriffe.
   Ein besonderer Angriffstyp, der in verschiedenen Szenarien die Überwachung des Enclave-Speichers und des Cache-Zugriffs nutzt. Ein Beispiel für einen solchen Angriff ist Prime and Probe.
   
   Angriffsreihenfolge:

   • t0: Der Angreifer füllt den gesamten Datencache des Opferprozesses.
   • t1: Das Opfer führt Code mit Speicherzugriffen aus, die von den sensiblen Daten des Opfers (kryptografischen Schlüsseln) abhängig sind. Die Cache-Zeile wird basierend auf dem Schlüsselbitwert ausgewählt. Im Beispiel in der Abbildung ist Schlüsselbit = 0 und die Adresse X in Cache-Zeile 2 wird gelesen. Die in X gespeicherten Daten werden in den Cache geladen und verdrängen die zuvor dort vorhandenen Daten.
   • t2: Der Angreifer überprüft, welche seiner Cache-Zeilen gelöscht wurden – Zeilen, die vom Opfer verwendet wurden. Dies geschieht durch Messung der Zugriffszeit. Durch die Wiederholung dieses Vorgangs für jedes Schlüsselbit erhält der Angreifer den gesamten Schlüssel.

Angriffsschutz: Intel SGX verfügt über einen Schutz gegen Seitenkanalangriffe, der die Überwachung von Cache-bezogenen Ereignissen verhindert. Ein Prime- und Probe-Angriff funktioniert jedoch weiterhin, da der Angreifer die Cache-Ereignisse seines Prozesses überwacht und den Cache mit dem Opfer teilt.

Daher gibt es derzeit keinen zuverlässigen Schutz gegen diesen Angriff.

Bekannt sind auch Angriffe wie Spectre und Foreshadow (L1TF), ähnlich wie Prime und Probe. Sie ermöglichen das Lesen von Daten aus dem Cache-Speicher über einen Drittanbieterkanal. Es wird Schutz vor der Spectre-v2-Schwachstelle geboten, die zwei dieser Angriffe abwehrt.

In Bezug auf DECO bietet der Drei-Wege-Handshake eine Sicherheitsgarantie:

1. Integrität des Prüfers: Ein gehackter Prüfer kann die Herkunftsinformationen des Servers nicht fälschen und nicht dazu führen, dass der Server ungültige Anfragen akzeptiert oder falsch auf gültige Anfragen reagiert. Dies geschieht durch Anforderungsmuster zwischen Server und Prüfer.
2. Integrität des Prüfers: Ein gehackter Prüfer kann nicht dazu führen, dass der Prüfer falsche Antworten erhält.
3. Datenschutz: Der gehackte Prüfer untersucht nur öffentliche Informationen (Anfrage, Servername).

In DECO sind nur Traffic-Injection-Schwachstellen möglich. Erstens kann der Verifizierer mit einem Drei-Wege-Handshake die Identität des Servers mithilfe einer neuen Nonce ermitteln. Nach dem Handshake muss sich der Prüfer jedoch auf Indikatoren der Netzwerkschicht (IP-Adressen) verlassen. Daher muss die Kommunikation zwischen dem Verifizierer und dem Server vor Traffic-Injection geschützt werden. Dies wird durch die Verwendung von Proxy erreicht.

Vergleich von Orakeln

Town Crier basiert auf der Arbeit mit einer Enklave im Serverteil, während DECO es Ihnen ermöglicht, die Authentizität der Datenherkunft mithilfe eines Drei-Wege-Handshakes und Datenverschlüsselung mit kryptografischen Schlüsseln zu überprüfen. Der Vergleich dieser Orakel wurde nach folgenden Kriterien durchgeführt: Leistung, Sicherheit, Kosten und Praktikabilität.

Ausrufer
DECO

Leistung
Schneller (0.6 Sekunden bis zum Ziel)
Langsamer (10.50 Sekunden, um das Protokoll zu beenden)

Sicherheit
Weniger sicher
Sicherer

kosten
Teurer
Billiger

Praktikabilität
Erfordert spezielle Hardware
Funktioniert mit jedem Server, der TLS unterstützt

Geschwindigkeitsleistung: Um mit DECO zu arbeiten, ist ein Drei-Wege-Handshake erforderlich, bei der Einrichtung über LAN dauert es 0.37 Sekunden, für die Interaktion nach dem Verbindungsaufbau ist 2PC-HMAC wirksam (0,13 s pro Schreibvorgang). Die Leistung von DECO hängt von den verfügbaren TLS-Verschlüsselungssammlungen, der Größe der privaten Daten und der Komplexität der Beweise für eine bestimmte Anwendung ab. Am Beispiel der Binäroptionsanwendung von IC3: Die Fertigstellung des Protokolls über LAN dauert etwa 10,50 Sekunden. Im Vergleich dazu benötigt Town Crier etwa 0,6 Sekunden, um eine ähnliche Anwendung abzuschließen, was etwa 20-mal schneller ist als DECO. Unter sonst gleichen Bedingungen wird TC schneller sein.

Sicherheit: Angriffe auf die Intel SGX-Enklave (Side-Channel-Angriffe) funktionieren und können den Teilnehmern des Smart Contracts echten Schaden zufügen. In Bezug auf DECO sind Angriffe im Zusammenhang mit Traffic-Injection möglich, aber die Verwendung eines Proxys reduziert solche Angriffe auf Null. Deshalb ist DECO sicherer.

Kosten: Die Kosten für Geräte, die Intel SGX unterstützen, sind höher als die Kosten für die Einrichtung des Protokolls in DECO. Deshalb ist TC teurer.

Praktikabilität: Um mit Town Crier arbeiten zu können, ist eine spezielle Ausrüstung erforderlich, die TEE unterstützt. Beispielsweise wird Intel SGX auf der Intel Core-Prozessorfamilie der 6. Generation und höher unterstützt. Mit DECO können Sie mit jedem Gerät arbeiten, es gibt jedoch eine DECO-Einstellung mit TEE. Je nach Einrichtungsprozess kann der Drei-Wege-Handshake von DECO einige Zeit dauern, aber das ist nichts im Vergleich zu den Hardwareeinschränkungen von TC, sodass DECO praktischer ist.

Abschluss

Betrachtet man die beiden Orakel getrennt und vergleicht sie anhand von vier Kriterien, wird deutlich, dass Town Crier in drei von vier Punkten DECO unterlegen ist. DECO ist aus Sicht der Informationssicherheit zuverlässiger, kostengünstiger und praktischer, obwohl die Einrichtung eines Dreiparteienprotokolls einige Zeit in Anspruch nehmen kann und Nachteile hat, beispielsweise zusätzliche Vorgänge mit Verschlüsselungsschlüsseln. TC ist schneller als DECO, aber Schwachstellen bei Seitenkanalangriffen machen es anfällig für den Verlust der Vertraulichkeit. Es muss berücksichtigt werden, dass DECO im Januar 2020 eingeführt wurde und nicht genügend Zeit vergangen ist, um es als sicher zu betrachten. Town Crier steht seit 4 Jahren unter Beschuss und hat viele Tests durchlaufen, sodass sein Einsatz in vielen Projekten gerechtfertigt ist.

Source: habr.com