Dziś tylko leniwy nie pisał o technologii blockchain, kryptowalutach i o tym, jak niesamowite to jest. Jednak w tym artykule nie będzie wychwalania tej technologii, lecz omówię jej wady i sposoby ich rozwiązania.

Podczas pracy nad jednym z projektów w firmie Altirix Systems pojawiło się zadanie dotyczące zabezpieczonego, cenzuroodpornego potwierdzenia danych z zewnętrznego źródła do blockchaina. Należało potwierdzać zmiany w zapisach trzeciego systemu i na ich podstawie realizować różne ścieżki w logice inteligentnego kontraktu. Zadanie na pierwszy rzut oka wydaje się dość trywialne, ale gdy od wyniku jego realizacji zależy sytuacja finansowa jednej ze stron zaangażowanych w proces, pojawiają się dodatkowe wymagania. Przede wszystkim jest to wszechstronne zaufanie do tego rodzaju mechanizmu walidacji. Ale wszystko po kolei.

Problem polega na tym, że blockchain sam w sobie jest autonomicznym, zamkniętym obiektem, dlatego inteligentne kontrakty w ramach blockchaina nic nie wiedzą o zewnętrznym świecie. Jednocześnie warunki inteligentnych kontraktów często są związane z informacjami o rzeczywistych zjawiskach (opóźnienia lotów, kurs walut itp.). Aby inteligentne kontrakty działały prawidłowo, informacje uzyskane z zewnątrz blockchaina muszą być wiarygodne i zweryfikowane. Problem ten rozwiązuje się poprzez wykorzystanie orakli, takich jak Town Crier i DECO. Te orakle pozwalają inteligentnym kontraktom w sieci blockchain ufać informacjom z zaufanego serwera internetowego, można powiedzieć, że to dostawcy wiarygodnych informacji.

Orakle

Wyobraź sobie, że inteligentny kontrakt dokonuje przelewu 0.001 btc na twój portfel bitcoinowy w przypadku zwycięstwa twojego ulubionego klubu piłkarskiego w Pucharze Rosji. W przypadku rzeczywistego zwycięstwa do inteligentnego kontraktu należy przesłać informację o tym, który klub wygrał, a pojawia się szereg problemów: skąd wziąć tę informację, jak bezpiecznie przesłać ją do inteligentnego kontraktu i jak upewnić się, że informacja przekazana do inteligentnego kontraktu faktycznie odpowiada rzeczywistości?

W kwestii źródła informacji mogą istnieć dwa scenariusze: podłączenie smart kontraktu do zaufanej strony internetowej, na której centralnie przechowywane są informacje o wynikach meczów, oraz drugi wariant — podłączenie kilku stron i następnie dokonanie selekcji informacji z większości źródeł, które dostarczają te same dane. W celu potwierdzenia prawidłowości informacji wykorzystuje się orakule, na przykład Oraclize, korzystający z TLSNotary (Modyfikacja TLS do udowodnienia autentyczności danych). Jednak w Google jest wystarczająco dużo informacji na temat Oraclize, a na Habrze znajduje się kilka artykułów; ja dzisiaj opowiem o orakulach, które stosują nieco inne podejście do przekazywania informacji: Town Crier i DECO. W artykule przedstawiono zasady działania obu orakuli, a także szczegółowe porównanie.

Town Crier

Town Crier (TC) został zaprezentowany przez IC3 (Inicjatywa na rzecz Kryptowalut i Umów) w 2016 roku na CCS’16. Główna idea TC: przekazać informacje ze strony internetowej do smart kontraktu i upewnić się, że informacje dostarczone przez TC są takie same jak te na stronie internetowej. TC wykorzystuje TEE (Trusted Execution Environment) dla autentyczności własności danych. W oryginalnej wersji opisano pracę z Intel SGX.
Town Crier składa się z części wewnątrz blockchaina i części w samej OS — TC Server.

Kontrakt TC znajduje się w blockchainie i działa jako front end dla TC. Przyjmuje żądania od CU (smart kontrakt użytkownika) i zwraca odpowiedź od TC Server. Wewnątrz TC Server znajduje się Relay, który nawiązuje łączność z internetem (dwukierunkowy ruch) i łączy enclave z blockchainem. Enclave zawiera progencl, który jest kodem wykonującym zapytania z blockchaina i zwracającym wiadomości do blockchaina z cyfrowym podpisem; progencl zawiera część kodu smart kontraktu i w zasadzie wykonuje niektóre z jego funkcji.

Enclave Intel SGX można traktować jako ogólną bibliotekę z API, działającą przez ecall. Ecall przekazuje kontrolę do enclave. Enclave wykonuje swój kod, aż do jego zakończenia lub pojawienia się wyjątku. Do wywoływania funkcji zdefiniowanych poza enclave, używa się ocall. Ocall jest wykonywane poza enclave i traktowane przez nią jako niebezpieczne wywołanie. Po zakończeniu ocall kontrola wraca do enclave.

W części Enclave następuje konfiguracja secure channel z serwerem WWW, a sam enclave wykonuje handshake TLS z docelowym serwerem i przeprowadza wszystkie operacje kryptograficzne w swoim wnętrzu. Biblioteka TLS (mbedTLS) oraz kod HTTP w zmniejszonej wersji są eksportowane do środowiska SGX. Ponadto Enclave zawiera certyfikaty root CA (zbiór certyfikatów), aby weryfikować certyfikaty zdalnych serwerów. Request Handler przyjmuje żądanie datagramu w formacie dostarczanym przez Ethereum, odszyfrowuje je i analizuje. Następnie generuje transakcję Ethereum zawierającą requested datagram, podpisuje ją za pomocą skTC i przekazuje do Relay.

Część Relay obejmuje interfejs klienta, TCP, interfejs blockchain. Interfejs klienta jest potrzebny do atestacji kodu enclave i komunikacji z klientem. Klient wysyła żądanie atestacji za pomocą ecall i otrzymuje timestamp, podpisany skTC, razem z att (podpis atestacji), który następnie jest potwierdzany przez Intel Attestation Service (IAS), a timestamp weryfikowany przez zaufaną usługę time service. Interfejs blockchain sprawdza nadchodzące żądania i umieszcza transakcje w blockchainie w celu dostarczenia datagramów. Geth to oficjalny klient Ethereum, który pozwala Relay na interakcję z blockchainem za pośrednictwem wywołań RPC.

Pracując z TEE, TC pozwala uruchomić jednocześnie kilka enclave, zwiększając w ten sposób szybkość przetwarzania informacji trzykrotnie. Jeśli z jedną działającą enclave prędkość wynosiła 15 tx/sec, to przy 20 równolegle uruchomionych enclave prędkość wzrasta do 65 tx/sec, dla porównania, maksymalna prędkość pracy w blockchainie Bitcoin wynosi 26 tx/sec.

DECO

DECO (Decentralized Oracles for TLS) został zaprezentowany na CCS’20, działa z witrynami, które obsługują połączenia TLS. Zapewnia poufność i integralność danych.
DECO z TLS wykorzystuje szyfrowanie symetryczne, dzięki czemu klient i serwer WWW mają klucze szyfrowania, a klient, jeśli chce, może podrobić dane sesji TLS. Aby rozwiązać ten problem, DECO stosuje trójnasty protokół handshake między prover (smart contract), verifier (oracle) i web-server (źródło danych).

Zasada działania DECO polega na tym, że weryfikator (prover) uzyskuje część danych D i potwierdza weryfikatorowi (verifier), że D pochodzi od serwera TLS S. Innym problemem jest to, że TLS nie podpisuje danych, a klientowi TLS trudno jest udowodnić, że dane zostały uzyskane dokładnie z tego serwera (trudność w udowodnieniu pochodzenia).

W protokole DECO używane są klucze szyfrowania KEnc i KMac. Klient wysyła zapytanie Q do serwer www, odpowiedź od serwera R przychodzi w zaszyfrowanej formie, ale klient i serwer mają te same KMac, więc klient może sfałszować wiadomość TLS. Rozwiązanie DECO polega na tym, aby "ukryć" KMac przed klientem (prover), aż odpowie na zapytanie. Teraz KMac jest podzielony między prover a verifier — KpMac i KvMac. Serwer otrzymuje KMac do szyfrowania odpowiedzi poprzez operację na częściach klucza KpMac ⊕ KvMac = KMac.

Po skonfigurowaniu trójstronnej procedury uzgadniania, wymiana danych między klientem a serwerem będzie przeprowadzona z zapewnieniem bezpieczeństwa.

Mówiąc o systemie zdecentralizowanych orakli, nie można pominąć Chainlink, który dąży do stworzenia zdecentralizowanej sieci węzłów orakli, kompatybilnej z Ethereum, Bitcoin i Hyperledger, z uwzględnieniem modułowości: każda część systemu może być aktualizowana. Aby zapewnić bezpieczeństwo, Chainlink oferuje każdemu oraklowi biorącemu udział w zadaniu wydanie kombinacji kluczy (publicznego i prywatnego). Klucz prywatny jest wykorzystywany do generowania częściowego podpisu, który zawiera ich rozwiązanie na zapytanie o dane. Aby uzyskać odpowiedź, konieczne jest połączenie wszystkich częściowych podpisów orakli sieci.

Chainlink planuje przeprowadzić wstępny PoC DECO z naciskiem na zdecentralizowane aplikacje finansowe, takie jak Mixicles. W momencie pisania artykułu ukazała się wiadomość na Forbes, że Chainlink nabył DECO z Uniwersytetu Cornella.

Ataki na orakle

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

1. Injectowanie złośliwego kodu smart-contract na węzłach TEE.
   Istota ataku: przesłanie do TEE fałszywego kodu smart-contract, w ten sposób, intruz, który uzyskał dostęp do węzła, będzie miał możliwość wykonania własnego (oszukańczego) smart-contract na odszyfrowanych danych. Niemniej jednak zwracane wartości będą szyfrowane za pomocą klucza prywatnego, a jedyną możliwością dostępu do takich danych jest wyciek szyfrowanego tekstu podczas zwrotu/wyjścia.
   Ochrona przed tym atakiem polega na weryfikacji przez enclave poprawności kodu znajdującego się pod bieżącym adresem. Można to osiągnąć za pomocą schematu adresowania, w którym adres kontraktu jest określany przez haszowanie kodu kontraktu.

2. Zmiany w szyfrogramie stanu kontraktu ujawniają wycieki.
   Istota ataku: Właściciele węzłów, na których wykonywane są inteligentne kontrakty, mają dostęp do stanu kontraktu w zaszyfrowanej formie poza enklawą. Haker, zdobywając kontrolę nad węzłem, może porównywać stan kontraktu przed i po wykonaniu transakcji oraz określić, jakie argumenty zostały wprowadzone i który konkretny metod inteligentnego kontraktu został użyty, ponieważ sam kod inteligentnego kontraktu i jego specyfikacje techniczne są publicznie dostępne.
   Ochrona w zapewnieniu niezawodności samego węzła.

3. Ataki kanałów bocznych.
   Szczególny typ ataków, wykorzystujący monitorowanie dostępu do pamięci i pamięci podręcznej enklawy w różnych scenariuszach. Przykładem takiego ataku jest Prime and Probe.
   
   Procedura przeprowadzenia ataku:

   • t0: Haker zapełnia całą pamięć podręczną danych procesu ofiary.
   • t1: Ofiara wykonuje kod z odwołaniami do pamięci, które zależą od poufnych danych ofiary (klucze kryptograficzne). Wybór linii pamięci podręcznej odbywa się na podstawie wartości keybit. W przedstawionym przykładzie, keybit = 0 i odczytano adres X w linii pamięci podręcznej 2. Dane przechowywane w X są ładowane do pamięci podręcznej, wypychając dane, które tam wcześniej były.
   • t2: Haker sprawdza, które z jego linii pamięci podręcznej zostały wypchnięte — linie używane przez ofiarę. Dokonuje się to poprzez pomiar czasu dostępu. Powtarzając tę operację dla każdego keybit, haker uzyskuje cały klucz.

Ochrona przed atakiem: W Intel SGX istnieje ochrona przed atakami kanałów bocznych, która zabrania monitorowania zdarzeń związanych z pamięcią podręczną, ale atak Prime and Probe nadal się powiedzie, ponieważ haker obserwuje zdarzenia pamięci podręcznej swojego procesu i dzieli pamięć podręczną z ofiarą.

W związku z tym obecnie nie ma niezawodnej ochrony przed tym atakiem.

Znane są również ataki takie jak Spectre i Foreshadow (L1TF), podobne do Prime and Probe. Pozwalają one na odczyt danych z pamięci podręcznej poprzez kanał boczny. Przewidziano ochronę przed podatnością Spectre-v2, działającą przeciwko tym dwóm atakom.

W odniesieniu do DECO, trzystronna ręka zapewnia gwarancję bezpieczeństwa:

1. Integralność Provera: zhakowany prover nie może sfałszować informacji o pochodzeniu serwera i nie może wymusić na serwerze akceptacji niedopuszczalnych zapytań ani odpowiadać niewłaściwie na prawidłowe zapytania. Jest to możliwe poprzez wzorce zapytań między serwerem a proverem.
2. Integralność Weryfikatora: zhakowany weryfikator nie może wymusić na proverze uzyskania błędnych odpowiedzi.
3. Prywatność: Haker verifer bada tylko publiczne informacje (zapytanie, nazwa serwera).

W DECO możliwe są tylko luki związane z wstrzykiwaniem ruchu. Na początku, podczas trójstronnego uzgadniania, verifer może ustalić tożsamość serwera za pomocą świeżego nonce. Jednak po uzgodnieniu verifer musi polegać na wskaźnikach na poziomie sieciowym (adresy IP). W ten sposób połączenie między verifer a serwerem powinno być zabezpieczone przed wstrzykiwaniem ruchu. Osiąga się to poprzez użycie Proxy.

Porównanie oracle'ów

Town Crier opiera się na pracy z enclave w części serwerowej, natomiast DECO pozwala na weryfikację pochodzenia danych za pomocą trójstronnych uzgodnień i szyfrowania danych z wykorzystaniem kluczy kryptograficznych. Porównanie danych oracle'ów przeprowadzono według następujących kryteriów: wydajność, bezpieczeństwo, koszt i praktyczność.

Town Crier
DECO

wydajność
Szybszy (0,6 s do zakończenia)
Wolniejszy (10,50 s do zakończenia protokołu)

bezpieczeństwo
Mniej bezpieczny
Bardziej bezpieczny

koszt
Droższy
Tańszy

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

Wydajność: Aby uzyskać dostęp do DECO, wymagana jest konfiguracja trójstronnego uzgodnienia, która przez LAN zajmuje 0,37 sekundy, a po nawiązaniu połączenia efektywny jest 2PC-HMAC (0,13 s na zapis). Wydajność DECO zależy od dostępnych zestawów szyfrów TLS, rozmiaru danych osobowych i złożoności dowodów dla konkretnej aplikacji. W przypadku aplikacji dla opcji binarnych od IC3: zakończenie protokołu przez LAN zajmuje około 10,50 s. Dla porównania, Town Crier potrzebuje do wykonania analogicznej aplikacji około 0,6 sekundy, co oznacza, że jest około 20 razy szybszy niż DECO. Pod tymi samymi warunkami, TC będzie szybszy.

Bezpieczeństwo: Ataki na enclave Intel SGX (ataki kanału bocznego) działają i mogą wyrządzić rzeczywiste szkody uczestnikom umowy inteligentnej. W odniesieniu do DECO możliwe są ataki związane z wstrzykiwaniem ruchu, ale użycie proxy eliminuje takie ataki. Dlatego DECO jest bardziej bezpieczne.

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

Praktyczność: Aby korzystać z Town Crier, potrzebny jest specjalny sprzęt obsługujący TEE. Na przykład, Intel SGX jest obsługiwany przez procesory Intel Core 6. generacji i nowsze. DECO umożliwia pracę z dowolnym sprzętem, chociaż istnieje konfiguracja DECO z wykorzystaniem TEE. Proces konfiguracji z wykorzystaniem trójstronnej wymiany kluczy w DECO może zająć trochę czasu, ale nie ma to żadnego porównania z ograniczeniem sprzętowym w TC, dlatego DECO jest bardziej praktyczny.

Podsumowanie

Analizując dwa orakle oddzielnie i porównując je pod względem czterech kryteriów, widać, że Town Crier ustępuje DECO w trzech z czterech punktów. DECO jest bardziej niezawodny pod względem bezpieczeństwa informacji, tańszy i bardziej praktyczny, chociaż konfiguracja trójstronnego protokołu może zająć trochę czasu i ma swoje wady, takie jak dodatkowe operacje z kluczami szyfrującymi. TC działa szybciej niż DECO, ale podatność na atak typu side-channel czyni go narażonym na ryzyko utraty prywatności. Należy pamiętać, że DECO został zaprezentowany w styczniu 2020 roku, i nie minęło wystarczająco dużo czasu, aby uznać go za bezpieczny. Town Crier jest atakowany od 4 lat i przeszedł przez wiele testów, dlatego jego zastosowanie w wielu projektach jest uzasadnione.

Źródło: habr.com