{"id":93794,"date":"2020-09-10T07:42:27","date_gmt":"2020-09-10T05:42:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne"},"modified":"2020-09-10T07:42:27","modified_gmt":"2020-09-10T05:42:27","slug":"town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/town-crier-vs-deco-kakoj-orakul-ispolzovat-v-blokchejne","title":{"rendered":"Town Crier vs DECO: Welcher Oracle sollte im Blockchain verwendet werden?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Heutzutage hat wirklich jeder \u00fcber Blockchain-Technologie, Kryptow\u00e4hrungen und deren Vorteile geschrieben. Doch in diesem Artikel geht es nicht um das Lob dieser Technologie, sondern um ihre Schw\u00e4chen und L\u00f6sungen, um diese zu beheben. <\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

W\u00e4hrend der Arbeit an einem Projekt bei Altirix Systems entstand die Anforderung eines sicheren, zensurresistenten Datenbest\u00e4tigungsmechanismus aus einer externen Blockchain-Quelle. Es war notwendig, \u00c4nderungen in den Eintr\u00e4gen eines dritten Systems zu validieren und auf Basis dieser \u00c4nderungen verschiedene Logikzweige in den Smart Contracts auszuf\u00fchren. Auf den ersten Blick scheint diese Aufgabe simpel zu sein, doch wenn das Ergebnis erhebliche finanzielle Konsequenzen f\u00fcr eine der beteiligten Parteien hat, entstehen zus\u00e4tzliche Anforderungen. Vor allem ist ein umfassendes Vertrauen in einen solchen Validierungsmechanismus notwendig. Aber alles der Reihe nach. <\/p>\n

<\/a><\/noindex><\/p>\n

Das Problem besteht darin, dass die Blockchain selbst ein autonomes, geschlossenes System ist, weshalb Smart Contracts innerhalb der Blockchain keine Informationen \u00fcber die Au\u00dfenwelt haben. Gleichzeitig beziehen sich die Bedingungen von Smart Contracts h\u00e4ufig auf Informationen \u00fcber reale Dinge (z.B. Flugversp\u00e4tungen, Wechselkurse usw.). Damit Smart Contracts korrekt funktionieren, muss die von au\u00dferhalb der Blockchain erhaltene Information zuverl\u00e4ssig und verifiziert sein. Dieses Problem wird durch den Einsatz von Orakeln wie Town Crier und DECO gel\u00f6st. Diese Orakel erm\u00f6glichen es Smart Contracts im Blockchain-Netzwerk, Informationen von einem vertrauensw\u00fcrdigen Webserver zu akzeptieren, man kann sagen, dass sie zuverl\u00e4ssige Informationsanbieter sind. <\/p>\n

<\/p>\n

Orakel<\/h1>\n

<\/p>\n

Stellen Sie sich vor, ein Smart Contract \u00fcberweist 0,001 BTC auf Ihre Bitcoin-Brieftasche, wenn Ihr Lieblingsfu\u00dfballverein den russischen Pokal gewinnt. Im Falle eines tats\u00e4chlichen Sieges muss der Smart Contract Informationen \u00fcber den gewonnenen Verein \u00fcbermitteln, und hier stellen sich einige Probleme: Woher bekommt man diese Informationen, wie werden sie sicher an den Smart Contract \u00fcbertragen und wie kann man sicherstellen, dass die Informationen, die in den Smart Contract gelangen, tats\u00e4chlich der Realit\u00e4t entsprechen? <\/p>\n

<\/p>\n

In Bezug auf Informationsquellen gibt es zwei Szenarien: Die Verbindung eines Smart Contracts mit einer vertrauensw\u00fcrdigen Website, auf der die Informationen \u00fcber die Spielergebnisse zentral gespeichert sind, oder die Verbindung mehrerer Websites, um Informationen aus den meisten Quellen auszuw\u00e4hlen, 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 \u00fcber Oraclize sind recht h\u00e4ufig in Google zu finden, und es gibt einige Artikel auf Habr\u00e9. Heute m\u00f6chte ich jedoch \u00fcber Orakel berichten, die einen etwas anderen Ansatz bei der Informations\u00fcbertragung verwenden: Town Crier und DECO. Der Artikel bietet eine Beschreibung der Funktionsweise beider Orakel sowie einen detaillierten Vergleich. <\/p>\n

<\/p>\n

Town Crier<\/h1>\n

<\/p>\n

Town Crier (TC) wurde 2016 auf der CCS\u201916 von der Initiative for CryptoCurrencies and Contracts (IC3) vorgestellt. Die Hauptidee von TC ist es, Informationen von der Webseite an den Smart Contract zu \u00fcbermitteln und sicherzustellen, dass die \u00fcbermittelten Informationen identisch mit denen auf der Webseite sind. TC nutzt eine TEE (Trusted Execution Environment), um die Eigent\u00fcmerschaft der Daten zu authentifizieren. In der urspr\u00fcnglichen Version beschreibt TC die Zusammenarbeit mit Intel SGX.
\nTown Crier besteht aus einem Teil innerhalb der Blockchain und einem Teil innerhalb des Betriebssystems \u2014 TC Server.
\n\"Town
\nDer TC Contract befindet sich in der Blockchain und fungiert als Frontend f\u00fcr TC. Er empf\u00e4ngt Anfragen vom CU (User Smart Contract) und gibt Antworten vom TC Server zur\u00fcck. 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\u00e4lt progencl, das den Code darstellt, der Anfragen aus der Blockchain bearbeitet und Nachrichten mit einer digitalen Signatur an die Blockchain zur\u00fccksendet. Progencl enth\u00e4lt Teile des Codes des Smart Contracts und f\u00fchrt im Wesentlichen einige seiner Funktionen aus. <\/p>\n

<\/p>\n

Der Intel SGX-Enklave kann als eine gemeinsame Bibliothek mit einer API betrachtet werden, die \u00fcber ecall funktioniert. Ecall \u00fcbertr\u00e4gt die Kontrolle an die Enklave. Die Enklave f\u00fchrt ihren Code aus, bis sie abgeschlossen ist oder eine Ausnahme auftritt. Um Funktionen aufzurufen, die au\u00dferhalb der Enklave definiert sind, werden ocalls verwendet. Ocall wird au\u00dferhalb der Enklave durchgef\u00fchrt und als unsicherer Aufruf behandelt. Nach der Ausf\u00fchrung von ocall wird die Kontrolle an die Enklave zur\u00fcckgegeben.
\n\"Town
\nIm Enklaven-Teil wird ein sicherer Kanal mit dem Webserver eingerichtet, die Enklave f\u00fchrt selbst das TLS-Handshake mit dem Zielserver durch und f\u00fchrt alle kryptografischen Operationen intern aus. Die TLS-Bibliothek (mbedTLS) und der HTTP-Code wurden in einer reduzierten Version in die SGX-Umgebung exportiert. Au\u00dferdem enth\u00e4lt die Enklave Root-CA-Zertifikate (eine Sammlung von Zertifikaten), um die Zertifikate von Remote-Servern zu \u00fcberpr\u00fcfen. Der Request Handler nimmt eine Datagrammanfrage im von Ethereum bereitgestellten Format entgegen, entschl\u00fcsselt sie und analysiert sie. Dann wird eine Ethereum-Transaktion generiert, die das angeforderte Datagramm enth\u00e4lt, mit skTC signiert und an das Relay \u00fcbermittelt.<\/p>\n

<\/p>\n

Der Relay umfasst das Client Interface, TCP und das Blockchain Interface. Das Client Interface ist notwendig f\u00fcr die Attestierung des Enklaven-Codes und die Kommunikation mit dem Client. Der Client sendet einen Attestierungsantrag \u00fcber ecall und erh\u00e4lt einen mit skTC signierten Zeitstempel zusammen mit att (der Attestierungsunterschrift). Anschlie\u00dfend wird att \u00fcber den Intel Attestation Service (IAS) best\u00e4tigt und der Zeitstempel durch einen vertrauensw\u00fcrdigen Zeitdienst \u00fcberpr\u00fcft. Das Blockchain Interface pr\u00fcft die eingehenden Anfragen und platziert Transaktionen in die Blockchain zur Lieferung von Datagrammen. Geth ist der offizielle Ethereum-Client und erm\u00f6glicht es Relay, \u00fcber RPC-Calls mit der Blockchain zu interagieren. <\/p>\n

<\/p>\n

Durch die Arbeit mit TEE erm\u00f6glicht TC das gleichzeitige Ausf\u00fchren mehrerer Enklaven, wodurch die Informationsverarbeitungsgeschwindigkeit um das Dreifache erh\u00f6ht 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\u00e4gt 26 tx\/sec.<\/p>\n

<\/p>\n

DECO<\/h1>\n

<\/p>\n

DECO (Decentralized Oracles for TLS) wurde auf der CCS\u201920 vorgestellt und funktioniert mit Websites, die TLS-Verbindungen unterst\u00fctzen. Es gew\u00e4hrleistet die Vertraulichkeit und Integrit\u00e4t der Daten.
\nDECO c TLS verwendet symmetrische Verschl\u00fcsselung, wodurch der Client und der Webserver \u00fcber Verschl\u00fcsselungsschl\u00fcssel verf\u00fcgen. Der Client kann, wenn er m\u00f6chte, die TLS-Sitzungsdaten f\u00e4lschen. Um dieses Problem zu l\u00f6sen, nutzt DECO ein dreiseitiges Handshake-Protokoll zwischen prover (Smart Contract), verifier (Oracle) und web-server (Datenquelle).<\/p>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Der DECO-Mechanismus besteht darin, dass der Pr\u00fcfer (prover) einen Teil der Daten D erh\u00e4lt und dem Verifizierer (verifier) best\u00e4tigt, dass D vom TLS-Server S stammt. Ein weiteres Problem ist, dass TLS keine Daten signiert und es f\u00fcr den TLS-Client schwierig ist zu beweisen, dass die Daten tats\u00e4chlich von diesem Server stammen (Provenance-Schwierigkeit). <\/p>\n

<\/p>\n

Im DECO-Protokoll werden die Verschl\u00fcsselungsschl\u00fcssel KEnc und KMac verwendet. Der Client sendet eine Anfrage Q an Webserver<\/a>, die Antwort des Servers R kommt in verschl\u00fcsselter Form, aber sowohl der Client als auch der Server besitzen dieselben KMac, und der Client kann die TLS-Nachricht f\u00e4lschen. Die L\u00f6sung 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 \u2014 KpMac und KvMac. Der Server erh\u00e4lt KMac zur Verschl\u00fcsselung der Antwort durch die Operation \u00fcber die Schl\u00fcsselanteile KpMac \u2295 KvMac = KMac.<\/p>\n

<\/p>\n

Durch die Einrichtung eines dreifachen Handshakes wird der Datenaustausch zwischen Client und Server mit einer Sicherheitsgarantie durchgef\u00fchrt.
\n\"Town
\nWenn wir \u00fcber dezentrale Orakelsysteme sprechen, ist Chainlink nicht zu vernachl\u00e4ssigen, das darauf abzielt, ein dezentrales Netzwerk von Orakel-Knoten zu schaffen, das mit Ethereum, Bitcoin und Hyperledger kompatibel ist und Modularit\u00e4t ber\u00fccksichtigt: Jeder Teil des Systems kann aktualisiert werden. Um die Sicherheit zu gew\u00e4hrleisten, bietet Chainlink jedem Orakel, das an einer Aufgabe teilnimmt, eine Kombination aus Schl\u00fcssel (\u00f6ffentlich und privat) an. Der private Schl\u00fcssel wird verwendet, um eine partielle Unterschrift zu erzeugen, die ihre L\u00f6sung auf die Datenanforderung enth\u00e4lt. Um eine Antwort zu erhalten, m\u00fcssen alle partiellen Unterschriften der Orakel im Netzwerk kombiniert werden.<\/p>\n

<\/p>\n

Chainlink plant die Durchf\u00fchrung eines ersten PoC DECO mit dem Fokus auf dezentrale Finanzanwendungen wie Mixicles. Zum Zeitpunkt der Ver\u00f6ffentlichung des Artikels gab es Neuigkeiten auf Forbes, dass Chainlink DECO von der Cornell University erworben hat.<\/p>\n

<\/p>\n

Angriffe auf Orakel<\/h1>\n

<\/p>\n

\"Town<\/p>\n

<\/p>\n

Aus Sicht der Informationssicherheit wurden folgende Angriffe auf Town Crier betrachtet:<\/p>\n

<\/p>\n

    \n
  1. \n

    Schadhafter Smart Contract Code-Injektion auf TEE-Knoten.
    \nDie Angriffsmethode besteht darin, fehlerhaften Code f\u00fcr den Smart Contract im TEE zu \u00fcbermitteln. Ein Angreifer, der Zugriff auf einen Knoten hat, kann somit seinen eigenen (betr\u00fcgerischen) Smart Contract auf die entschl\u00fcsselten Daten ausf\u00fchren. Allerdings werden die zur\u00fcckgegebenen Werte mit dem privaten Schl\u00fcssel verschl\u00fcsselt, und der einzige Zugang zu diesen Daten besteht in der M\u00f6glichkeit, den verschl\u00fcsselten Text beim R\u00fcckgabe-\/Ausgabeprozess abzugreifen.
    \nDer Schutz vor diesem Angriff liegt in der \u00dcberpr\u00fcfung 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. <\/p>\n

    \n<\/li>\n

  2. \n

    \u00c4nderungen des chiffrierten Vertragsstatus erm\u00f6glichen Leaks.
    \nDie Angriffsmethode: Knotenbetreiber, auf denen Smart Contracts ausgef\u00fchrt werden, haben Zugriff auf den contract state in verschl\u00fcsselter Form au\u00dferhalb der Enklave. Ein Angreifer, der die Kontrolle \u00fcber den Knoten erlangt hat, kann den contract state vor und nach der Ausf\u00fchrung 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 \u00f6ffentlich zug\u00e4nglich sind.
    \nSchutz zur Gew\u00e4hrleistung der Zuverl\u00e4ssigkeit des Knotens selbst.<\/p>\n

    \n<\/li>\n

  3. \n

    Seitenkanalangriffe.
    \nEine spezielle Art von Angriffen, die das Monitoring des Zugriffs auf den Speicher und den Cache des Enklaven in verschiedenen Szenarien nutzt. Ein Beispiel f\u00fcr einen solchen Angriff ist Prime and Probe.
    \n\"Town
    \nAblauf des Angriffs:<\/p>\n

    <\/p>\n