Heutzutage hat nur derjenige, der faul ist, nicht über die Blockchain-Technologie, Kryptowährungen und wie cool das ist, geschrieben. In diesem Artikel wird es jedoch nicht um das Lob dieser Technologie gehen, sondern wir werden uns vielmehr mit ihren Nachteilen und möglichen Lösungen befassen.

Während der Arbeit an einem der Projekte bei Altirics Systems stellte sich die Aufgabe der sicheren, zensurresistenten Bestätigung von Daten aus einer externen Quelle für die Blockchain. Es war notwendig, Änderungen in den Datensätzen eines dritten Systems zu bestätigen und auf Grundlage dieser Änderungen in der Logik des Smart Contracts entweder diesen oder jenen Pfad auszuführen. Die Aufgabe erschien zunächst recht trivial, aber wenn das Ergebnis ihrer Ausführung vom finanziellen Zustand einer der am Prozess beteiligten Parteien abhängt, kommen zusätzliche Anforderungen hinzu. Dabei handelt es sich vor allem um das umfassende Vertrauen in einen solchen Validierungsmechanismus. Aber lassen Sie uns der Reihe nach vorgehen.

Das Problem besteht darin, dass die Blockchain an sich ein autonomes, geschlossenes Objekt darstellt, weshalb Smart Contracts innerhalb der Blockchain nichts über die Außenwelt wissen. Gleichzeitig sind die Bedingungen von Smart Contracts häufig mit Informationen über reale Dinge (Flugverspätungen, Wechselkurse usw.) verknüpft. Damit Smart Contracts ordnungsgemäß funktionieren, muss die von außerhalb der Blockchain erhaltene Information zuverlässig und überprüft sein. Dieses Problem wird durch die Verwendung von Orakeln wie Town Crier und DECO gelöst. Diese Orakel ermöglichen es dem Smart Contract in einem Blockchain-Netzwerk, den Informationen von einem überprüften Webserver zu vertrauen, man kann sagen, dass es sich um Lieferanten zuverlässiger Informationen handelt.

Orakel

Stellen Sie sich vor, ein Smart Contract überweist 0,001 BTC auf Ihre Bitcoin-Brieftasche im Falle des Sieges Ihres Lieblingsfußballvereins im russischen Pokal. Im Falle eines tatsächlichen Sieges muss dem Smart Contract mitgeteilt werden, welcher Verein gewonnen hat, und hier treten einige Probleme auf: Woher bekommen wir diese Informationen, wie übermitteln wir sie sicher an den Smart Contract und wie stellen wir sicher, dass die Informationen, die in den Smart Contract gelangen, tatsächlich mit der Realität übereinstimmen?

Es gibt zwei Szenarien hinsichtlich der Informationsquelle: die Verbindung eines Smart Contracts mit einer vertrauenswürdigen Website, auf der die Informationen über die Spielergebnisse zentral gespeichert sind, und die zweite Möglichkeit - die Anbindung mehrerer Websites, um die 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 nutzt (eine Modifikation von TLS zur Nachweisführung der Datenauthentizität). Zu Oraclize gibt es genügend Informationen bei Google, und auf Habr gibt es mehrere Artikel. Ich werde heute über Orakel sprechen, die einen etwas anderen Ansatz zur Übertragung von Informationen verwenden: Town Crier und DECO. Der Artikel beschreibt die Funktionsweise beider Orakel sowie einen detaillierten Vergleich.

Town Crier

Town Crier (TC) wurde 2016 auf der CCS'16 von IC3 (The Initiative for CryptoCurrencies and Contracts) vorgestellt. Die Hauptidee von TC besteht darin, Informationen von einer Website an einen Smart Contract zu übertragen und sicherzustellen, dass die über TC bereitgestellten Informationen mit denen auf der Website übereinstimmen. TC verwendet TEE (Trusted Execution Environment) zur Gewährleistung der Datenauthentizität. Im Original wird die Arbeit mit Intel SGX beschrieben.
Town Crier besteht aus einem Teil innerhalb der Blockchain und einem Teil innerhalb des Betriebssystems selbst – dem TC Server.

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

Die Intel SGX-Enklave kann als eine allgemeine Bibliothek mit API betrachtet werden, die über ecall funktioniert. Ecall überträgt die Kontrolle an die Enklave. Die Enklave führt ihren Code aus, bis er abgeschlossen ist oder eine Ausnahme auftritt. Für den Aufruf von Funktionen, die außerhalb der Enklave definiert sind, werden ocall verwendet. Ocall wird außerhalb der Enklave ausgeführt und vom System als unsicherer Aufruf behandelt. Nach der Ausführung von ocall wird die Kontrolle an die Enklave zurückgegeben.

Im Enclave wird ein sicherer Kanal mit dem Webserver eingerichtet, das Enclave führt das TLS-Handschlag mit dem Zieldatenserver durch und führt alle kryptografischen Operationen intern aus. Die TLS-Bibliothek (mbedTLS) und der HTTP-Code in verkleinerter Form wurden in die SGX-Umgebung exportiert. Außerdem enthält das Enclave Root-CA-Zertifikate (eine Sammlung von Zertifikaten), um die Zertifikate von entfernten Servern zu überprüfen. Der Request Handler nimmt das Datagramm im Format entgegen, das von Ethereum bereitgestellt wird, entschlüsselt es und analysiert es. Anschließend generiert er eine Ethereum-Transaktion, die das angeforderte Datagramm enthält, signiert es mit skTC und übergibt es an den Relay.

Der Relay-Bereich umfasst die Client-Schnittstelle, TCP und die Blockchain-Schnittstelle. Die Client-Schnittstelle ist notwendig für die Attestation des Enclave-Codes und die Verbindung zum Client. Der Client sendet eine Anfrage zur Attestation über ecall und erhält einen Zeitstempel, der mit skTC signiert ist, zusammen mit att (dem Attestierungszeichen), danach wird att über den Intel Attestation Service (IAS) bestätigt, und der Zeitstempel wird durch einen vertrauenswürdigen Zeitdienst überprüft. Die Blockchain-Schnittstelle überprüft die eingehenden Anfragen und platziert die Transaktionen in der Blockchain zur Lieferung der Datagrams. Geth ist der offizielle Ethereum-Client und ermöglicht es dem Relay, über RPC-Calls mit der Blockchain zu interagieren.

Durch die Arbeit mit TEE ermöglicht TC das gleichzeitige Starten mehrerer Enclaves, wodurch die Informationsverarbeitungsgeschwindigkeit um das Dreifache erhöht wird. Wenn bei einem laufenden Enclave die Geschwindigkeit 15 tx/sec betrug, steigt sie bei 20 parallel gestarteten Enclaves auf 65 tx/sec, zum Vergleich: die maximale Geschwindigkeit im Bitcoin-Blockchain beträgt 26 tx/sec.

DECO

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

Der Arbeitsprinzip von DECO besteht darin, dass der prüfende (prover) einen Teil der Daten D erhält und dem verifizierer (verifier) bestätigt, dass D vom TLS-Server S stammt. Ein weiteres Problem besteht darin, dass TLS die Daten nicht signiert und es dem TLS-Client schwerfällt zu beweisen, dass die Daten von genau diesem Server stammen (Provenance-Schwierigkeit).

Im DECO-Protokoll werden die Verschlüsselungsschlüssel KEnc und KMac verwendet. Der Client sendet eine Anfrage Q an einen Webserver, die Antwort des Servers R kommt in verschlüsselter Form, aber der Client und der Server besitzen die gleichen KMacs, sodass der Client die TLS-Nachricht fälschen kann. Die Lösung von DECO besteht darin, KMac vor dem Client (prover) zu "verstecken", bis dieser auf die Anfrage antwortet. Nun ist KMac zwischen prover und verifier aufgeteilt – KpMac und KvMac. Der Server erhält KMac zur Verschlüsselung der Antwort mittels der Operation der Schlüsselteile KpMac ⊕ KvMac = KMac.

Durch die Einrichtung eines dreiseitigen Handshakes wird der Austausch von Daten zwischen Client und Server mit einer Sicherheitsgarantie durchgeführt.

Wenn es um das System der dezentralisierten Orakel geht, muss Chainlink erwähnt werden, das eine dezentrale Netzwerkarchitektur von Orakel-Knoten anstrebt, die mit Ethereum, Bitcoin und Hyperledger kompatibel ist, unter Berücksichtigung der Modularität: Jeder Teil des Systems kann aktualisiert werden. Um die Sicherheit zu gewährleisten, bietet Chainlink jedem Orakel, das an einer Aufgabe beteiligt ist, eine Kombination von Schlüsseln (öffentlich und privat) an. Der private Schlüssel wird verwendet, um eine partielle Unterschrift zu generieren, die ihre Lösung für die Datenanforderung enthält. Um die Antwort zu erhalten, ist die Kombination aller partiellen Unterschriften der Netzwerkorakel erforderlich.

Chainlink plant die Durchführung eines ersten PoC DECO mit dem Fokus auf dezentralisierte Finanzanwendungen wie Mixicles. Zum Zeitpunkt des Schreibens wurde in den Nachrichten von Forbes berichtet, dass Chainlink DECO von der Cornell University erworben hat.

Angriffe auf Orakel

Aus der Perspektive der Informationssicherheit wurden die folgenden Angriffe auf Town Crier betrachtet:

1. Rogue-Smart-Contract-Code-Injektion auf TEE-Knoten.
   Das Wesen des Angriffs besteht darin, einen absichtlich falschen Smart-Contract-Code in die TEE zu übertragen, sodass ein Angreifer, der Zugang zum Knoten hat, seinen eigenen (betrügerischen) Smart-Contract auf entschlüsselte Daten ausführen kann. Die zurückgegebenen Werte werden jedoch mit dem privaten Schlüssel verschlüsselt, und die einzige Möglichkeit, auf solche Daten zuzugreifen, besteht darin, dass der verschlüsselte Text bei der Rückgabe/Übertragung ausläuft.
   Der Schutz vor diesem Angriff besteht darin, dass der Enklave die Richtigkeit des Codes an der aktuellen Adresse überprüft. Dies kann durch ein Addressing-Schema erreicht werden, bei dem die Adresse des Vertrags durch das Hashing des Codes des Vertrags bestimmt wird.

2. Änderungen des Verschlüsselungszustands des Vertrags führen zu Leaks.
   Die Essenz des Angriffs: Die Betreiber von Knoten, auf denen Smart Contracts ausgeführt werden, haben Zugriff auf den Contract-State in verschlüsselter Form außerhalb des Enklave. Ein Angreifer, der die Kontrolle über den Knoten erlangt, kann den Contract-State vor und nach der Ausführung der Transaktion vergleichen und ermitteln, welche Argumente übergeben wurden und welche Methode des Smart Contracts verwendet wurde, 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 der Enklave 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 Datencache des Zielprozesses.
   • t1: Das Ziel führt Code mit Speicherzugriffen aus, die von vertraulichen Daten des Opfers abhängen (kryptografische Schlüssel). Die Auswahl der Cache-Linie erfolgt anhand des Wertes keybit. Im Beispiel auf der Abbildung ist keybit = 0 und die Adresse X in Cache-Linie 2 wurde gelesen. Die Daten, die in X gespeichert sind, werden in den Cache geladen und verdrängen die zuvor dort gespeicherten Daten.
   • t2: Der Angreifer prüft, welche seiner Cache-Zeilen verdrängt wurden - die Zeilen, die vom Opfer verwendet wurden. Dies geschieht durch Messung der Zugriffszeit. Indem er diese Operation für jedes keybit wiederholt, erhält der Angreifer den gesamten Schlüssel.

Schutz vor dem Angriff: In Intel SGX gibt es einen Schutz gegen Seitenkanalangriffe, der das Monitoring von cachebezogenen Ereignissen verbietet, aber der Angriff Prime and Probe wird trotzdem durchgehen, da der Angreifer die Cache-Ereignisse seines Prozesses überwacht und den Cache mit dem Opfer teilt.

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

Es sind auch Angriffe vom Typ Spectre und Foreshadow (L1TF) bekannt, die den Angriff Prime and Probe ähneln. Sie ermöglichen das Auslesen von Daten aus dem Cache über einen Seitenkanal. Es gibt einen Schutz gegen die Spectre-v2-Schwachstelle, die gegen diese beiden Angriffe wirkt.

In Bezug auf DECO bietet das dreiseitige Handshake Sicherheitsgarantien:

1. Prover-Integrität: Ein gehackter Prover kann keine Informationen zur Herkunft des Servers fälschen und kann den Server nicht dazu bringen, ungültige Anfragen anzunehmen oder falsch auf gültige Anfragen zu antworten. Dies wird durch Anfragevorlagen zwischen Server und Prover realisiert.
2. Verifier-Integrität: Ein gehackter Verifier kann den Prover nicht dazu bringen, falsche Antworten zu erhalten.
3. Vertraulichkeit: Der gehackte Verifier betrachtet nur öffentliche Informationen (Anfrage, Servername).

In DECO sind nur Schwachstellen in Zusammenhang mit Traffikanalysen möglich. Zunächst kann der Verifier beim Triple-Handshake die Identität des Servers mit einem frischen Nonce feststellen. Nach dem Handshake muss der Verifier jedoch auf Netzwerkebene (IP-Adressen) vertrauen. So muss die Verbindung zwischen Verifier und Server vor Traffikanalysen geschützt werden. Dies wird durch die Verwendung eines Proxys erreicht.

Vergleich der Orakel

Town Crier basiert auf der Arbeit mit einem Enklave auf der Serverseite, DECO hingegen ermöglicht die Authentifizierung der Herkunft von Daten durch einen Triple-Handshake und Verschlüsselung von Daten mit kryptografischen Schlüsseln. Der Vergleich der Daten der Orakel wurde nach folgenden Kriterien durchgeführt: Geschwindigkeit, Sicherheit, Kosten und Praktikabilität.

Town Crier
DECO

Geschwindigkeit
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

Geschwindigkeit: Für die Arbeit mit DECO ist die Einrichtung eines Triple-Handshakes erforderlich, was bei der Einrichtung über LAN 0,37 Sekunden dauert, und für die Interaktion nach Verbindungserstellung ist 2PC-HMAC (0,13 s beim Schreiben) effektiv. Die Leistung von DECO hängt von den verfügbaren TLS-Verschlüsselungsalgorithmen, der Menge an persönlichen Daten und der Komplexität der Beweise für eine bestimmte Anwendung ab. Am Beispiel der Binäroptionen-App von IC3: Der Abschluss des Protokolls über LAN dauert etwa 10,50 s. Zum Vergleich benötigt Town Crier für die Durchführung einer ähnlichen Anwendung ungefähr 0,6 Sekunden, also etwa 20 Mal schneller als DECO. Unter gleichen Bedingungen wird TC schneller sein.

Sicherheit: Angriffe auf die Intel SGX-Enklave (Seitenkanalangriffe) funktionieren und können den Teilnehmern des Smart Contracts echten Schaden zufügen. In Bezug auf DECO sind Angriffe in Verbindung mit Traffikanalysen möglich, aber die Verwendung eines Proxys macht solche Angriffe unwirksam. Daher ist DECO sicherer.

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

Praktikabilität: Für die Arbeit mit Town Crier 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 ermöglicht die Arbeit mit beliebiger Hardware, obwohl es eine DECO-Konfiguration mit Verwendung von TEE gibt. Beim Einrichtungsprozess kann das dreiseitige Handshake bei DECO etwas Zeit in Anspruch nehmen, jedoch steht dies in keinem Vergleich zu den Hardwarebeschränkungen für TC, weshalb DECO praktischer ist.

Fazit

Wenn man die beiden Orakel einzeln betrachtet und sie nach vier Kriterien vergleicht, wird deutlich, dass Town Crier in drei von vier Punkten hinter DECO zurückbleibt. DECO ist in Bezug auf Informationssicherheit zuverlässiger, kostengünstiger und praktischer, obwohl die Einrichtung des dreiseitigen Protokolls etwas Zeit in Anspruch nehmen und Nachteile mit sich bringen kann, wie z. B. zusätzliche Operationen mit Verschlüsselungsschlüsseln. TC arbeitet schneller als DECO, aber die Verwundbarkeit im Zusammenhang mit Side-Channel-Angriffen macht es anfällig für den Verlust der Vertraulichkeit. Es ist zu beachten, dass DECO im Januar 2020 präsentiert wurde und noch nicht genügend Zeit vergangen ist, um es als sicher zu betrachten. Town Crier wird seit 4 Jahren angegriffen und hat viele Überprüfungen durchlaufen, weshalb sein Einsatz in vielen Projekten gerechtfertigt ist.

Quelle: habr.com