Cyberbezpieczeństwo w aplikacjach opartych na infrastrukturze blockchain: ogólne problemy i konkretne rozwiązania

26 listopada 2020
Maxim Zavgorodny
Cyberbezpieczeństwo w aplikacjach opartych na infrastrukturze blockchain: ogólne problemy i konkretne rozwiązania
W DataArt pracuję od siedmiu lat. Od trzech ostatnich jako architekt rozwiązań. Moje zainteresowania zawodowe to ML/AI. Wcześniej zajmowałem się rozwojem zdecentralizowanych systemów opartych na blockchain, gdzie byłem ściśle zaangażowany w kwestie bezpieczeństwa.

W tym artykule postaram się wyjaśnić podstawowe zasady, którymi należy się kierować projektując rozwiązanie blockchain oraz zwrócić uwagę czytelników na pewne punkty, takie jak tworzenie portfeli, a także generowanie, przechowywanie i używanie kluczy. Tekst nie będzie analizował niuansów technicznych dla każdego z nich. Wyróżnione punkty można raczej wykorzystać jako listę kontrolną do sprawdzenia planu projektu pod kątem zgodności z normami bezpieczeństwa.

Rozwiązania oparte na blockchain są aktywnie wykorzystywane w projektach finansowych, np. przy projektowaniu systemów płatności, giełdowych, platform handlu kryptowalutami. Ale blockchain może być równie dobrze używany w ubezpieczeniach, opiece zdrowotnej i innych obszarach biznesu. Jednocześnie klienci zainteresowani wykorzystaniem stosunkowo nowej i popularnej technologii często nie są dostatecznie świadomi problemów bezpieczeństwa, jakie pojawiają się w projektach blockchain. To dlatego ich aplikacje są tak często hakowane. Na przykład w samym 2019 r. zaatakowano ponad 30 głównych platform handlowych.

Zacznijmy od tego, że znaczenie cyberbezpieczeństwa w projektach kryptowalut jest oczywiste. A co z innymi obszarami? Przyjrzyjmy się głównym aspektom technologii blockchain, które wymagają wdrożenia zgodnie z wysokimi standardami bezpieczeństwa, niezależnie od charakteru działalności klienta. Transakcje, certyfikaty, tworzenie i przechowywanie kluczy prywatnych - każdy aspekt lub proces implementacji może być w równym stopniu niewystarczająco bezpieczny. Same te aspekty pozostają dokładnie takie same w każdej infrastrukturze blockchain. Dobra wiadomość jest taka, że najlepsze praktyki finansowe można bezpiecznie stosować na przykład w projektach medycznych.

Najłatwiejszym i najszybszym sposobem zabezpieczenia projektu blockchain jest wykorzystanie istniejących bibliotek open source (takich jak bitcoinJ) lub integracja RPC z produktami takimi jak Electrum czy Geth. Umożliwi nam to manipulowanie kluczami, transakcjami, seedami itp. Za pośrednictwem istniejącego RPC. Takie podejście może być rzeczywiście uzasadnione na etapie weryfikacji koncepcji, kiedy terminy i budżet są zwykle ograniczone. Ale tej opcji nie należy brać pod uwagę w trybie produkcyjnym.

Biblioteki i wszelkie oprogramowanie do generowania poufnych informacji kryptograficznych nie powinny mieć żadnych dodatkowych funkcji. Wszystkie programy używane w tym celu muszą pomyślnie przejść audyty prawne i bezpieczeństwa, a wszelkie przekazywanie wygenerowanych kluczy i seedów w systemie musi być zabronione. Ponadto warto zabronić zaufania do jakichkolwiek otwartych bibliotek i usług firm zewnętrznych.

Oto lista ważnych kwestii bezpieczeństwa, które należy uwzględnić podczas projektowania systemu:

  • Generowanie klucza/seedów
  • Tworzenie portfela
  • Przechowywanie kluczy
  • Użycie kluczy

Przyjrzyjmy się bliżej, czego wymagają wysokie standardy bezpieczeństwa w każdym z tych aspektów.

1. Generowanie klucza i/lub seedów

Wszystkie seedy kryptograficzne i klucze transakcji muszą być generowane wewnętrznie. Takie informacje są absolutnie poufne i nie mogą być przekazywane osobom trzecim. Algorytmy generowania kluczy i seedów muszą przestrzegać poufnych i nieprzewidywalnych reguł.

1.1 Klucz/seed generowane przez operatora

Wrażliwe informacje kryptograficzne, takie jak klucze lub seedy, muszą być generowane przez operatora, który jest odpowiedzialny za podpis potwierdzający transakcję. Jeśli mówimy o zdecentralizowanej aplikacji, takiej jak portfel kryptograficzny, klucz i seed muszą zostać wygenerowane przez użytkownika aplikacji bez przekazywania tych poufnych danych nikomu innemu.

W przypadku scentralizowanej aplikacji (portfele online lub klasyczne giełdy kryptowalut) proces tworzenia będzie odbywał się na tych scentralizowanych platformach.

Należy zweryfikować metodologie generacji, aby wykluczyć determinizm. Bezpieczeństwo algorytmów generowania poufnych informacji kryptograficznych musi zostać potwierdzone przez niezależnych audytorów.

Generowanie kluczowych seedów musi odbywać się w odpowiedniej strefie zdemilitaryzowanej (DMZ) lub systemie autonomicznym. Kopie zapasowe tajemnic kryptograficznych muszą być zaszyfrowane i przesłane do tajnego magazynu do zaufanej osoby w celu wykonania kopii zapasowych i przywracania.

1.2 Generatory losowych bitów (DRBG)

Szukamy kluczy, które powinny być używane z zatwierdzonymi algorytmami kryptograficznymi.

Na przykład prawdziwe generowanie liczb losowych (TRNG), podobnie jak deterministyczne generatory losowych bitów (DRBG), jest uważane za przyjęty standard w branży. Klucze są generowane przy użyciu matematycznego przetwarzania danych wyjściowych przy użyciu generatorów losowych bitów i dodatkowych parametrów. Aby uzyskać więcej informacji, zobacz Wytyczne dotyczące generowania kluczy kryptograficznych (publikacja specjalna NIST 800-133 ).

2. Tworzenie portfela

Logika wdrożenia portfela lub magazynu kluczy prywatnych do pracy z transakcjami blockchain powinna obejmować następujący zestaw zagadnień: zarządzanie adresami, używanie kluczy prywatnych do potwierdzania operacji oraz wdrażanie multisignature.

Ponadto portfel można zaimplementować dla każdego konta indywidualnego. Metoda deterministyczna pozwala na utworzenie zestawu adresów/par kluczy w postaci wspólnej puli adresów z jednego głównego seeda. Ponadto wdrażając portfel, należy zwrócić uwagę na różne zagrożenia, takie jak utrata, kradzież i ujawnienie kluczy. Łączeniu portfela z kontem konkretnego użytkownika musi towarzyszyć wprowadzenie dodatkowych poziomów identyfikacji.

2.1 Implementacja hierarchicznego deterministycznego (HD) portfela

Wartość seeda głównego można wykorzystać do stworzenia wystarczającej liczby unikalnych adresów połączonych tylko za pomocą algorytmu generowania, to znaczy niezależnych od siebie dla zewnętrznego obserwatora. Każdy adres pomocniczy otrzymuje miejsce w strukturze rozwidlonej i jest powiązany z określoną ścieżką w drzewie HD. Ważne jest, aby wykonanie portfela HD było zgodne ze standardem, czyli BIP44.

2.2 Unikalny adres dla każdej transakcji

Dla każdej anonimowej transakcji należy wygenerować unikalny adres.

2.3 Wielokrotny podpis. Wiele kluczy do podpisu

Każdy adres, który generuje portfel HD, wymaga co najmniej dwóch podpisów jako danych wejściowych dla transakcji. Ponadto, aby zabezpieczyć środki użytkownika przed kradzieżą, konieczne jest umieszczenie kluczy w strefach DMZ odizolowanych od siebie.

2.4 Klucz odzyskiwania kopii zapasowej

Powszechną metodą jest utworzenie 2 z 3 możliwych podpisów do wykorzystania jako dane wejściowe transakcji.

2.5 Stosowanie portfeli hierarchicznie deterministycznych (HD)

Wszystkie adresy są przypisywane deterministycznie na podstawie seedów, które muszą być prywatne.

2.6 Kopia zapasowa portfela

Konieczne jest regularne tworzenie kopii zapasowych dla każdej nowej generacji kluczy i master seeda.

2.7 Szyfrowanie portfela

Wszystkie dane w portfelu muszą być zaszyfrowane przy użyciu bezpiecznych algorytmów. Odszyfrowywanie danych powinno znajdować się w oddzielnych węzłach z silnymi zasadami bezpieczeństwa, np. usługa tożsamości, Vault HashiCorp itp.

Scheme image
[Wysoka architektura portfela z wieloma podpisami, rys. 1.1.]

3. Przechowywanie kluczy

Kiedy klucze nie są używane, muszą być bezpiecznie zaszyfrowane. Oprócz samego szyfrowania należy zwrócić uwagę na osobne przechowywanie kluczy (powinny być one umieszczone w całkowicie niezależnej infrastrukturze) oraz fizyczne bezpieczeństwo nośników informacji tam, gdzie to możliwe.

3.1 Klucze podstawowe są przechowywane w postaci zaszyfrowanej

Do przechowywania kluczy i/lub seedów należy użyć silnego poziomu szyfrowania. Na przykład AES-256-CBC.

3.2 Miejsce przechowywania kluczy

Zaszyfrowane klucze i/lub seedy i zaszyfrowane hasła muszą być przechowywane na różnych platformach. Ponadto informacje te muszą być fizycznie rozmieszczone między różnymi lokalizacjami i dostawcami.

3.3 Klucz zapasowy

Klucze/seedy muszą być archiwizowane (cyfrowe, sprzętowe, papierowe itp.).

3.4 Zasady backupów kluczy

Klucze należy chronić przed ryzykiem fizycznego zniszczenia, w tym klęsk żywiołowych i katastrof spowodowanych przez człowieka, takich jak powodzie, pożary itp. Przechowuj kopie zapasowe w lokalizacjach geograficznie oddalonych od miejsca użytkowania. Wszystkie kopie zapasowe muszą być chronione przez kontrolę dostępu.

4. Używanie kluczy

Wszystkie operacje interakcji z seedami muszą być wykonywane w bezpieczny sposób. Konieczne jest wykluczenie możliwości kopiowania lub zmiany kluczy przez szkodliwe programy.

Klucze muszą być chronione przed nieuczciwymi użytkownikami, którzy używają autoryzowanego dostępu do nieautoryzowanych transakcji. Implementacja mechanizmu deszyfrowania i podpisywania musi być wielowarstwowa i niezawodna.

4.1 Do generowania kluczy zaleca się użycie ścieżki „użytkownik/hasło/n-ty współczynnik”

Dostęp do użycia klucza musi być chroniony przy użyciu modelu uwierzytelniania wieloskładnikowego. Na przykład może być wymagany identyfikator (może to być nazwa użytkownika, adres e-mail itp.), Tokeny Google Authenticator, podpisy cyfrowe z klucza prywatnego i weryfikacja osobistego identyfikatora.

4.2 Klucze mogą być używane tylko w zaufanym środowisku

Używanie kluczy wyłącznie w zaufanym środowisku DMZ zmniejsza ryzyko nieautoryzowanego kopiowania złośliwego oprogramowania, wklejania kopii i przechowywania kluczy. Takie podejście zapewni również ochronę przed złośliwymi próbami odzyskania klucza i kradzieżą poufnych danych.

4.3 Informacje o operatorze i sprawdzanie dziennika operacji

Konieczne jest sprawdzenie wszystkich pracowników, którzy mają dostęp do systemu. Wszystkie działania operatora muszą być rejestrowane i zapisywane w dziennikach.

4.4 Jedno urządzenie - jeden klucz

Dwa klucze z portfela nie mogą być przechowywane na tym samym urządzeniu, do którego dostęp wymaga wielu podpisów.

4.5 Uwierzytelnianie wieloskładnikowe

Podpisywanie transakcji musi być chronione przez uwierzytelnianie wieloskładnikowe.

4.6 Audytor operacyjny

W przypadku ważnych transakcji należy dodać dodatkową warstwę uwierzytelniania z obowiązkową zgodą menedżera

Scheme image
[Sekwencja użycia kluczy, rys. 1.2]

Dokonaliśmy przeglądu podstawowych warstw wymaganych do bezpiecznego zabezpieczenia systemu opartego na rozwiązaniu blockchain. Jednak wdrożenie techniczne nie wystarczy, aby zapewnić bezpieczeństwo.

Ponadto należy:

  • Przechwytywać i dokumentować wszystkie operacje w dziennikach, audytach systemu, audytach bezpieczeństwa, procedurach i politykach dla kluczowych użytkowników. Wszystkie operacje i zmiany w systemie muszą być rejestrowane w dziennikach.
  • Zapewnić śledzenie rejestrowania transakcji i tworzenie kopii zapasowych dziennika.

Źródła: