Dziś o technologii blockchain, kryptowalutach i tym, jakie to fajne, nie pisali już tylko leniwi. Ale w tym artykule nie będziemy chwalić tej technologii, porozmawiamy o jej wadach i sposobach ich wyeliminowania.

Podczas pracy nad jednym z projektów w Altirix Systems pojawiło się zadanie bezpiecznego, odpornego na cenzurę potwierdzania danych ze źródła zewnętrznego wobec blockchaina. Należało potwierdzić zmiany w zapisach trzeciego systemu i na podstawie tych zmian wykonać tę czy inną gałąź w logice inteligentnych kontraktów. Zadanie na pierwszy rzut oka jest dość banalne, jednak gdy od wyniku jego realizacji zależy sytuacja finansowa jednej ze stron biorących udział w procesie, pojawiają się dodatkowe wymagania. Przede wszystkim jest to pełne zaufanie do takiego mechanizmu walidacji. Ale najpierw najważniejsze.

Problem w tym, że sam blockchain jest autonomiczną, zamkniętą jednostką, więc inteligentne kontrakty wewnątrz blockchainu nie wiedzą nic o świecie zewnętrznym. Jednocześnie warunki inteligentnych kontraktów często odnoszą się do informacji o rzeczach rzeczywistych (opóźnienie lotu, kursy walut itp.). Aby inteligentne kontrakty działały prawidłowo, informacje otrzymywane spoza blockchainu muszą być wiarygodne i zweryfikowane. Problem ten rozwiązuje się za pomocą wyroczni, takich jak Town Crier i DECO. Wyrocznie te pozwalają inteligentnemu kontraktowi w sieci blockchain ufać informacjom z zaufanego serwera WWW; można powiedzieć, że są to dostawcy wiarygodnych informacji.

Wyrocznie

Wyobraź sobie, że inteligentny kontrakt przekazuje 0.001 btc do Twojego portfela bitcoin, jeśli Twój ulubiony klub piłkarski zdobędzie Puchar Rosji. W przypadku prawdziwego zwycięstwa inteligentny kontrakt musi przekazać informację o tym, który klub wygrał, i pojawia się szereg problemów: skąd wziąć tę informację, jak bezpiecznie przenieść ją do inteligentnego kontraktu i jak zadbać o to, aby informacja otrzymany w inteligentnym kontrakcie jest ważny faktycznie pokrywa się z rzeczywistością?

Jeśli chodzi o źródło informacji, mogą być 2 scenariusze: połączenie inteligentnej umowy z zaufaną witryną internetową, na której centralnie przechowywane są informacje o wynikach meczów, oraz druga opcja polega na połączeniu kilku witryn jednocześnie, a następnie wybraniu informacji z większości źródeł które dostarczają tych samych danych. W celu sprawdzenia poprawności informacji wykorzystuje się wyrocznie, np. Oraclize, które wykorzystuje TLSNotary (TLS Notary Modification to Prove the Authenticity of Data). Ale w Google jest wystarczająco dużo informacji o Oraclize, a na Habré jest kilka artykułów.Dziś opowiem o wyroczniach, które stosują nieco inne podejście do przekazywania informacji: Town Crier i DECO. W artykule opisano zasadę działania obu wyroczni, a także szczegółowe porównanie.

Wołacz miejski

Town Crier (TC) został wprowadzony przez IC3 (Inicjatywa na rzecz Kryptowalut i Kontraktów) w 2016 roku na CCS'16. Główna idea TC: przenieś informacje ze strony internetowej do inteligentnej umowy i upewnij się, że informacje dostarczone przez TC są takie same, jak na stronie internetowej. TC używa TEE (Trusted Execution Environment) do uwierzytelniania własności danych. Oryginalna wersja TC opisuje sposób pracy z Intel SGX.
Town Crier składa się z części znajdującej się wewnątrz blockchainu i części wewnątrz samego systemu operacyjnego – serwera TC.

Umowa TC znajduje się na blockchainie i działa jako interfejs dla TC. Akceptuje żądania od CU (inteligentny kontrakt użytkownika) i zwraca odpowiedź z serwera TC. Wewnątrz Serwera TC znajduje się Relay, który nawiązuje połączenie pomiędzy enklawą a Internetem (ruch dwukierunkowy) i łączy enklawę z blockchainem. Enclave zawiera progencl, czyli kod wysyłający żądania z blockchainu i zwracający wiadomości do blockchaina z podpisem cyfrowym, progencl zawiera część kodu inteligentnego kontraktu i zasadniczo wykonuje część jego funkcji.

Enklawę Intel SGX można traktować jako bibliotekę współdzieloną z interfejsem API działającym poprzez ecall. Ecall przekazuje kontrolę nad enklawą. Enklawa wykonuje swój kod do momentu zakończenia działania lub wystąpienia wyjątku. ocall służy do wywoływania funkcji zdefiniowanych poza enklawą. Ocall jest wykonywany poza enklawą i jest przez nią traktowany jako niezaufane wywołanie. Po wykonaniu ocall kontrola wraca do enklawy.

W części Enklawa konfigurowany jest bezpieczny kanał z serwerem WWW, enklawa sama wykonuje uzgadnianie TLS z serwerem docelowym i wykonuje wewnętrznie wszystkie operacje kryptograficzne. Biblioteka TLS (mbedTLS) i zredukowany kod HTTP zostały wyeksportowane do środowiska SGX. Enclave zawiera także certyfikaty głównego urzędu certyfikacji (zbiór certyfikatów) umożliwiające weryfikację certyfikatów serwerów zdalnych. Request Handler akceptuje żądanie datagramu w formacie dostarczonym przez Ethereum, odszyfrowuje je i analizuje. Następnie generuje transakcję Ethereum zawierającą żądany datagram, podpisuje ją za pomocą skTC i przesyła do Relay.

Część Relay obejmuje interfejs klienta, TCP i interfejs Blockchain. Interfejs Klienta jest potrzebny do certyfikacji kodu enklawy i komunikacji z klientem. Klient wysyła żądanie zaświadczenia za pomocą ecall i otrzymuje znacznik czasu podpisany przez skTC wraz z att (podpisem zaświadczenia), następnie att jest weryfikowany za pomocą usługi Intel Attestation Service (IAS), a znacznik czasu jest weryfikowany przez zaufaną usługę pomiaru czasu. Interfejs Blockchain weryfikuje przychodzące żądania i umieszcza transakcje w łańcuchu bloków w celu dostarczenia datagramów. Geth jest oficjalnym klientem Ethereum i umożliwia Relay interakcję z blockchainem za pośrednictwem wywołań RPC.

Współpracując z TEE, TC pozwala na uruchomienie kilku enklaw równolegle, zwiększając tym samym prędkość przetwarzania informacji 3-krotnie. Jeśli przy jednej działającej enklawie prędkość wynosiła 15 tx/s, to przy 20 równolegle działających enklawach prędkość wzrosła do 65 tx/s; dla porównania maksymalna prędkość robocza w łańcuchu bloków Bitcoin wynosi 26 tx/s.

DECO

DECO (Decentralized Oracles for TLS) zostało zaprezentowane na CCS'20, współpracuje z witrynami obsługującymi połączenia TLS. Zapewnia poufność i integralność danych.
DECO z TLS wykorzystuje szyfrowanie symetryczne, więc klient i serwer WWW mają klucze szyfrujące, a klient może sfałszować dane sesji TLS, jeśli chce. Aby rozwiązać ten problem, DECO wykorzystuje trójkierunkowy protokół uzgadniania pomiędzy testerem (inteligentny kontrakt), weryfikatorem (oracle) i serwerem internetowym (źródło danych).

Sposób działania DECO polega na tym, że weryfikator otrzymuje część danych D i potwierdza weryfikatorowi, że D pochodzi z serwera TLS S. Innym problemem jest to, że TLS nie podpisuje danych i klient TLS ma trudności z udowodnieniem, że dane otrzymano z dokładnie właściwego serwera (trudność pochodzenia).

Protokół DECO wykorzystuje klucze szyfrujące KEnc i KMac. Klient wysyła żądanie Q do serwera WWW, odpowiedź z serwera R jest zaszyfrowana, ale klient i serwer mają tego samego KMac i klient może sfałszować wiadomość TLS. Rozwiązanie DECO polega na „ukryciu” KMaca przed klientem (weryfikatorem) do czasu, aż ten odpowie na żądanie. Teraz KMac jest podzielony na sprawdzającego i weryfikatora - KpMac i KvMac. Serwer otrzymuje KMac w celu zaszyfrowania odpowiedzi przy użyciu operacji na części klucza KpMac ⊕ KvMac = KMac.

Dzięki ustawieniu trójstronnego uzgadniania wymiana danych pomiędzy klientem a serwerem będzie odbywać się z gwarancją bezpieczeństwa.

Mówiąc o zdecentralizowanym systemie Oracle, nie można nie wspomnieć o Chainlink, którego celem jest stworzenie zdecentralizowanej sieci węzłów Oracle kompatybilnych z Ethereum, Bitcoin i Hyperledger, z uwzględnieniem modułowości: każda część systemu może być aktualizowana. Jednocześnie, aby zapewnić bezpieczeństwo, Chainlink oferuje każdej wyroczni biorącej udział w zadaniu wydanie kombinacji kluczy (publicznego i prywatnego). Klucz prywatny służy do wygenerowania częściowego podpisu, który zawiera decyzję dotyczącą żądania danych. Aby uzyskać odpowiedź, konieczne jest połączenie wszystkich częściowych podpisów wyroczni sieci.

Chainlink planuje przeprowadzić wstępne PoC DECO, koncentrując się na zdecentralizowanych aplikacjach finansowych, takich jak Mixicles. W momencie pisania tego tekstu w Forbesie pojawiła się wiadomość, że Chainlink przejął DECO od Cornell University.

Ataki na wyrocznie

Z punktu widzenia bezpieczeństwa informacji rozważono następujące ataki na Town Crier:

1. Nieuczciwe wstrzykiwanie kodu inteligentnego kontaktu do węzłów TEE.
   Istota ataku: przesłanie do TEE celowo nieprawidłowego kodu inteligentnego kontraktu, dzięki czemu osoba atakująca, która uzyskała dostęp do węzła, będzie mogła wykonać swój własny (fałszywy) inteligentny kontrakt na odszyfrowanych danych. Jednak zwracane wartości będą szyfrowane kluczem prywatnym, a jedynym sposobem uzyskania dostępu do takich danych jest wyciek szyfrogramu przy powrocie/wyjściu.
   Ochrona przed tym atakiem polega na sprawdzeniu przez enklawę poprawności kodu znajdującego się pod aktualnym adresem. Można to osiągnąć za pomocą schematu adresowania, w którym adres kontraktu jest określany poprzez mieszanie kodu kontraktu.

2. Wyciek tekstu zaszyfrowanego stanu kontraktu.
   Istota ataku: Właściciele węzłów, na których realizowane są inteligentne kontrakty, mają dostęp do stanu kontraktu w zaszyfrowanej formie poza enklawą. Osoba atakująca po przejęciu kontroli nad węzłem może porównać stan kontaktu przed i po transakcji oraz określić, jakie argumenty zostały wprowadzone i jaką metodę inteligentnego kontraktu zastosowano, gdyż sam kod inteligentnego kontraktu i jego specyfikacje techniczne są publicznie dostępne.
   Ochrona w zapewnieniu niezawodności samego węzła.

3. Ataki z kanału bocznego.
   Specjalny rodzaj ataku wykorzystujący monitorowanie pamięci enklawy i dostępu do pamięci podręcznej w różnych scenariuszach. Przykładem takiego ataku jest Prime i Probe.
   
   Kolejność ataku:

   • t0: Osoba atakująca wypełnia całą pamięć podręczną danych procesu ofiary.
   • t1: Ofiara wykonuje kod, którego dostęp do pamięci zależy od wrażliwych danych ofiary (kluczy kryptograficznych). Linia pamięci podręcznej jest wybierana na podstawie wartości bitu klucza. W przykładzie na rysunku odczytywany jest bit klucza = 0 i adres X w linii 2 pamięci podręcznej. Dane przechowywane w X są ładowane do pamięci podręcznej, wypierając dane, które znajdowały się tam wcześniej.
   • t2: Osoba atakująca sprawdza, które linie pamięci podręcznej zostały usunięte — linie używane przez ofiarę. Odbywa się to poprzez pomiar czasu dostępu. Powtarzając tę ​​operację dla każdego bitu klucza, atakujący uzyskuje cały klucz.

Ochrona przed atakami: Intel SGX ma ochronę przed atakami z kanału bocznego, która uniemożliwia monitorowanie zdarzeń związanych z pamięcią podręczną, ale atak Prime i Probe nadal będzie skuteczny, ponieważ osoba atakująca monitoruje zdarzenia w pamięci podręcznej swojego procesu i udostępnia pamięć podręczną ofierze.

Dlatego w tej chwili nie ma niezawodnej ochrony przed tym atakiem.

Znane są również ataki takie jak Spectre i Foreshadow (L1TF), podobne do Prime i Probe. Umożliwiają odczyt danych z pamięci podręcznej za pośrednictwem kanału strony trzeciej. Zapewniona jest ochrona przed luką Spectre-v2, która działa przeciwko dwóm z tych ataków.

W przypadku DECO trójstronny uścisk dłoni stanowi gwarancję bezpieczeństwa:

1. Integralność programu dowodzącego: zhakowany moduł dowodzący nie może sfałszować informacji o pochodzeniu serwera i nie może spowodować, że serwer zaakceptuje nieprawidłowe żądania lub nieprawidłowo odpowie na ważne żądania. Odbywa się to poprzez wzorce żądań pomiędzy serwerem a serwerem sprawdzającym.
2. Integralność weryfikatora: zhakowany weryfikator nie może spowodować, że weryfikator otrzyma nieprawidłowe odpowiedzi.
3. Prywatność: zhakowany weryfikator sprawdza wyłącznie informacje publiczne (żądanie, nazwa serwera).

W DECO możliwe są tylko luki w zabezpieczeniach polegające na wstrzykiwaniu ruchu. Po pierwsze, za pomocą trójstronnego uzgadniania weryfikator może ustalić tożsamość serwera za pomocą nowego identyfikatora jednorazowego. Jednak po uzgodnieniu weryfikator musi polegać na wskaźnikach warstwy sieci (adresach IP). Dlatego komunikacja pomiędzy weryfikatorem a serwerem musi być chroniona przed wstrzykiwaniem ruchu. Osiąga się to za pomocą serwera proxy.

Porównanie wyroczni

Town Crier opiera się na pracy z enklawą w części serwerowej, natomiast DECO pozwala na weryfikację autentyczności pochodzenia danych za pomocą trójstronnego uzgadniania oraz szyfrowania danych kluczami kryptograficznymi. Porównanie tych wyroczni przeprowadzono według następujących kryteriów: wydajność, bezpieczeństwo, koszt i praktyczność.

Wołacz miejski
DECO

wydajność
Szybciej (0.6 s do końca)
Wolniej (10.50 s do zakończenia protokołu)

bezpieczeństwo
Mniej bezpieczne
Więcej Ochrony

koszt
Droższe
Taniej

praktyczność
Wymaga specjalnego sprzętu
Działa z każdym serwerem obsługującym TLS

Prędkość: Do pracy z DECO wymagane jest trójstronne uzgadnianie, podczas konfiguracji przez LAN zajmuje to 0.37 sekundy, do interakcji po nawiązaniu połączenia skuteczny jest 2PC-HMAC (0,13 s na zapis). Wydajność DECO zależy od dostępnych zestawów szyfrów TLS, rozmiaru prywatnych danych i złożoności dowodów dla konkretnej aplikacji. Na przykładzie aplikacji opcji binarnych z IC3: wykonanie protokołu przez LAN zajmuje około 10,50 sekundy. Dla porównania, Town Crier potrzebuje około 0,6 sekundy na wykonanie podobnej aplikacji, czyli około 20 razy szybciej niż DECO. Jeśli wszystko będzie takie samo, najaktywniejszy partner będzie szybszy.

bezpieczeństwo: Ataki na enklawę Intel SGX (ataki side-channel) działają i mogą wyrządzić realne szkody uczestnikom inteligentnego kontraktu. W przypadku DECO możliwe są ataki związane z wstrzykiwaniem ruchu, ale użycie serwera proxy ogranicza takie ataki do zera. Dlatego DECO jest bezpieczniejsze.

Kosztować: Koszt sprzętu obsługującego Intel SGX jest wyższy niż koszt konfiguracji protokołu w DECO. Dlatego TC jest droższy.

Praktyczność: Do pracy z Town Crier wymagany jest specjalny sprzęt obsługujący TEE. Na przykład technologia Intel SGX jest obsługiwana w rodzinie procesorów Intel Core szóstej generacji i nowszych. DECO pozwala na pracę z dowolnym sprzętem, chociaż istnieje ustawienie DECO przy użyciu TEE. Zgodnie z procesem konfiguracji, trójstronne uzgadnianie DECO może zająć trochę czasu, ale to nic w porównaniu z ograniczeniami sprzętowymi TC, więc DECO jest bardziej praktyczne.

wniosek

Patrząc na obie wyrocznie osobno i porównując je pod kątem czterech kryteriów, jasne jest, że Town Crier jest gorszy od DECO w trzech z czterech punktów. DECO jest bardziej niezawodne z punktu widzenia bezpieczeństwa informacji, tańsze i bardziej praktyczne, chociaż ustawienie protokołu trójstronnego może zająć trochę czasu i ma swoje wady, na przykład dodatkowe operacje na kluczach szyfrujących. TC jest szybszy niż DECO, ale luki w zabezpieczeniach przed atakami z kanału bocznego sprawiają, że jest podatny na utratę poufności. Trzeba wziąć pod uwagę, że DECO został wprowadzony w styczniu 2020 roku, a upłynęło zbyt mało czasu, aby uznać go za bezpieczny. Town Crier jest atakowany od 4 lat i przeszedł wiele testów, więc jego wykorzystanie w wielu projektach jest uzasadnione.

Źródło: www.habr.com