W tym artykule omówimy w szczegółach czym jest TSS, jakie potencjalne korzyści wnosi do przestrzeni blockchain, gdzie rozpocząć w kwestii jego implementacji do własnego projektu oraz jak wygląda na tle ona algorytmów Shamir Secret Sharing czy Multisig. Na samym końcu artykułu omówimy również różne sposoby wykorzystania TSS do zarządzania kluczami rozproszonymi oraz omówimy zagrożenia i ograniczenia wynikające z użycia tego algorytmu.
Siła drzemiąca w kryptografii
Blockchain
W artykule skupimy się na jednej z innowacyjnych technologii: Schemacie Podpisów Progowych (TSS).
MPC oraz Threshold Signature Scheme (TSS)
Multi-party computation (pol. dosł. wielopodmiotowe obliczenia - MPC) to gałąź kryptografii, którą zapoczątkowała przełomowa dla tej dziedziny praca Andrewa C. Yao, której publikacja miała miejsce prawie 40 lat temu. MPC polega na tym, iż uczestnicy takiego systemu, którzy nie ufają sobie nawzajem, próbują wspólnie obliczyć funkcję na podstawie posiadanych przez siebie danych wejściowych, zachowując jednak dane wyjściowe dla siebie - w formie prywatnej.
Jako przykład powiedzmy, że "x" pracowników firmy chce wiedzieć, kto otrzymuje największą wypłatę ale nie przy okazji nie chcą ujawniać sobie nawzajem swojej rzeczywistej płacy. Tutaj prywatnymi danymi wejściowymi są pensje, a daną wyjściową, którą poznają wszyscy będzie nazwisko pracownika o najwyższym wynagrodzeniu. Wykonując obliczenia za pomocą MPC, możemy być pewni, że żadno z wynagrodzeń oraz danych pracowników nie zostało ujawnione innym uczestnikom procesu obliczania.
Dwiema głównymi właściwościami MPC są poprawność (prawidłowość) i prywatność:
Poprawność: dane wyjściowe wygenerowane przez algorytm są poprawne (zgodnie z oczekiwaniami).
Prywatność: prywatne dane wejściowe przechowywane przez jedną ze stron nie są przekazywane innym stronom procesu.
Aby lepiej zrozumieć zasadę działania MPC posłużmy się przykładem. W przykładzie w rozproszony sposób wygenerujemy cyfrowy podpis (sygnaturę). Zobaczmy, jak powyższe właściwości można zastosować do podpisów. Przypomnijmy, że w przypadku podpisów konieczne jest wykonanie następujących trzech kroków:
Generacja klucza: pierwszy krok jest również najbardziej złożony. Musimy wygenerować klucz, który będzie jednocześnie publiczny i będzie służył do weryfikacji przyszłych podpisów Przy okazji musimy też wygenerować tzw. individual secret dla każdej ze stron, który nazwiemy secret share. Jeśli chodzi o poprawność danych i prywatność w procesie MPC, to w wyniku obliczeń możemy być pewni, iż wygenerowany zostanie ten sam klucz publiczny dla wszystkich stron oraz inny secret share dla każdej z nich. Tym samym: (1) prywatność: żadne dane secret share nie wyciekły między stronami, oraz (2) poprawność: klucz publiczny jest funkcją secret shares.
Podpisywanie: ten krok obejmuje funkcję generowania podpisu. Danymi wejściowymi każdej ze stron będzie ich secret share, utworzony jako wynik poprzedniego kroku (rozproszona generacja klucza). Na tym etapie powstaje również tzw. public input (publiczne dane wejściowe), który jest po prostu wiadomością do podpisania. Wynikiem tej operacji będzie podpis cyfrowy. Właściwość MPC, którą jest prywatność gwarantuje, że na żadnym z etapów obliczeń nie doszło do wycieku secret shares.
- Weryfikacja: algorytm weryfikacji pozostaje taki sam, jak w ustawieniu klasycznym. Aby zachować zgodność jedno-kluczowymi podpisamy, każdy, kto zna klucz publiczny, powinien mieć możliwość weryfikacji i walidacji podpisów. To właśnie taką pracę wykonują węzły walidujące dane w sieci blockchain.
Threshold signature scheme (TSS) to nazwa, którą nadajemy procesowi generowania klucza rozproszonego (DKG) i rozproszonego schematu podpisywania sygnatur progowych.
Implementacja TSS w blockchain
Aby lepiej wyjaśnić to zagadnienie, zacznijmy od krótkiego wyjaśnienia w jaki sposób tworzone są nowe adresy w klasycznej sieci blockchain. Krótko mówiąc, utworzenie nowego adresu jest możliwe poprzez wygenerowanie klucza prywatnego, a następnie obliczenie klucza publicznego z klucza prywatnego. Tym samym zauważymy, że adres blockchain pochodzi formalnie z klucza publicznego.
Implementując TSS do blockchain mamy do czynienia z "x" stronami, które wspólnie obliczają klucz publiczny, a każda z nich posiada secret share klucza prywatnego (poszczególne share nie są ujawniane innym stronom). Z klucza publicznego możemy uzyskać adres w taki sam sposób, jak w tradycyjnym systemie, dzięki czemu blockchain pozostaje niezależny od sposobu generowania adresu. Zaletą takiego rozwiązania jest to, iż klucz prywatny przestaje być pojedynczym punktem, który może zawieść (tzw. ang. single point of failure) ponieważ każda ze stron posiada tylko wybraną część tego klucza.
To samo można zrobić przy podpisywaniu transakcji. W tym kontekście transakcja nie jest podpisywana kluczem prywatnym tylko przez jedną stronę. Zamiast tego do jej podpisania wykorzystywany jest proces rozproszonej generacji podpisu w którym bierze udział wiele stron. Tym samym każda ze stron uczestnicząca w procesie jest w stanie wyprodukować (dosłownie) prawidłowy podpis tak długo, jak wystarczająca ilość uczestników procesu działa uczciwie. Ponownie, dzięki TSS obliczenia lokalne (pojedynczy punkt awarii) zamieniane są na obliczenia rozproszone.
Należy również wspomnieć, że proces rozproszonego generowania klucza można wykonać na wiele sposobów, gdzie każdy z nich charakteryzuje się inną strukturą dostępu do danych: najczęściej spotykane ustawienia procesu polegają na zabezpieczeniu procesu przed "t" błędami w obliczaniu klucza prywatnego, bez zmniejszania bezpieczeństwa całego procesu.
TSS vs. Multisig
Innymi słowy, zarówno multisig, jak i TSS zasadniczo próbują osiągnąć podobne cele, ale TSS korzysta z kryptografii poza siecią blockchain, podczas gdy procesy inicjowane przez multisig odbywają się w łańcuchu bloków (w sieci). Co jednak istotne, to fakt, iż sieć blockchain potrzebuje sposobu na zakodowanie multisig, co może zaszkodzić prywatności, ponieważ struktura dostępu (liczba stron uczestniczących w procesie podpisywania) zostaje zapisana i publicznie ujawniona w blockchain. Co więcej, koszt transakcji multisig jest wyższy, ponieważ w sieci muszą również zostać zapisane informacje o wszystkich stronach uczestniczących w procesie podpisywania.
W przypadku TSS dane sygnatariuszy są łączone i zapisywane w formie zwykłej transakcji, co zmniejsza koszty i zapewnia prywatność. Z drugiej strony proces multisig może pozostać nie-interaktywny, co może (ale nie musi) oszczędzić kłopotów z uruchomieniem złożonej warstwy komunikacyjnej między różnymi sygnatariuszami.
TSS vs. algorytm Shamir secret sharing scheme
Schemat SSSS (Shamir Secret Sharing Scheme) daje możliwość przechowywania klucza prywatnego w sposób rozproszony - przy czym odnosi się to do sytuacji, kiedy w danym momencie nie jest on używany. Pomiędzy TSS i SSSS występują dwie główne różnice:
Generowanie klucza: w przypadku SSSS, za wygenerowanie secret shares dla danego klucza prywatnego odpowiada jedna strona, którą nazwano “the dealer”. Tym samym, w chwili zainicjowania procesu generacji klucza, klucz prywatny generowany jest w jednej lokalizacji, a następnie dystrybuowany do pozostałych lokacji. W przypadku TSS, w rolę dealera wchodzą wszystkie strony zaangażowane w proces generowania klucza - dzięki czemu tworzony jest on w sposób rozproszony - i nigdy nie znajduje się w całości w jednej lokalizacji.
Podpisywanie: w przypadku SSSS, każda ze stron musi samodzielnie odtworzyć klucz prywatny, aby móc podpisać jakąkolwiek partię danych, co ponownie powoduje powstanie tzw. pojedynczego punktu awarii za każdym razem, gdy potrzebne jest uzyskanie/wygenerowanie podpisu. W przypadku TSS, proces podpisywania partii danych odbywa się w rozproszony sposób bez konieczności odtwarzania secret shares klucza prywatnego.
Jak więc widać, w TSS klucz prywatny (który generalnie reprezentuje poziom bezpieczeństwa danego systemu) nigdy nie znajduje się w jednym miejscu przez cały okres jego użytkowania.
Portfele Threshold
W przypadku portfeli typu threshold, nie jest to już tak proste. O ile możliwe jest wygenerowanie struktury HD, jej wygenerowanie musi odbyć się w sposób rozproszony, jako kolejny protokół MPC. Każda ze stron uczestnicząca w tym procesie musi wspólnie z innymi stronami zdecydować, który z kluczy zostanie wykorzystany w następnej kolejności. Innymi słowy, każda ze stron będzie posiadać swój własny seed phrase. Seed phrases są generowane osobno i nigdy nie są ze sobą łączone, dzięki czemu każda ze stron jest w stanie uzyskać klucz prywatny z własnego seeda.
Portfele oparte na TSS charakteryzują się również dodatkową warstwą bezpieczeństwa, która umożliwia zmianę algorytmu generowania klucza prywatnego (ang. public key rotation), bez konieczności całkowitej zmiany klucza publicznego i adresu blockchain do niego przypisanego. Funkcja Private key rotation znana również pod nazwą Proactive Secret Sharing, to nic innego jak kolejny protokół MPC, który na bazie jednej porcji secret shares (w postaci danych wejściowych), generuje nowy zestaw secret shares. Dzięki temu starych (nieaktualnych) secret shares można się pozbyć i bez żadnych problemów korzystać z nowych.
Taka struktura sprawia, że atakujący musi znajdować się w wielu lokalizacjach jednocześnie, aby móc z sukcesem zaatakować portfel typu threshold. Połączenie ze sobą secret shares przed ich "rotacją" z ich odpowiednikami po rotacji nie da atakującemu żadnej dodatkowej korzyści, jeśli będzie on próbował sfałszować podpis.
Minusem tego rodzaju portfeli jest to, że bez posiadania frazy „seed”, Twój portfel staje się niezgodny z portfelami, które wykorzystują system jednokluczowy. Dlatego ważne jest, aby rozważyć, które strony będą w posiadaniu secret shares.
Portfele Threshold mogą występować w kilku różnych rodzajach:
Outsoure'ujące TSS: w których użytkownik portfela daje “n” wskazanym serwerom możliwość wykonywania obliczeń w jego imieniu. Dzięki temu proces generowania, zarządzania i podpisywania kluczy jest skutecznie outsource'owany do dostawców usług, którzy nie są właścicielami aktywów, ale zapewniają warstwę bezpieczeństwa w zamian za pewne korzyści.
Wykorzystujące wiele urządzeń: w których użytkownik końcowy wykonuje TSS między urządzeniami, których je właścicielem. Dla przykładu - jedna strona będzie jakimś urządzeniem IoT w domu użytkownika, inna strona będzie użytkownikiem mobilnym, kolejna ze stron będzie jego laptopem i tak dalej.
Hybrydowym: TSS funkcjonuje w taki sposób, iż niektóre strony są kontrolowane przez zewnętrznych dostawców usług, a niektóre strony działają na urządzeniach należących do użytkowników.
Pierwsza metoda odciąża klienta użytkownika od konieczności wykonywania najcięższych obliczeń. Z drugiej strony dostawcy usług mogą specjalnie się zmawiać, aby wspólnie wykradać aktywa swoich użytkowników (chociaż ciężko wyobrazić sobie scenariusz w którym wystarczająca liczba użytkowników zostanie zaatakowana w tym samym czasie, to w praktyce jest to możliwe).
Druga z metod daje użytkownikowi pełną kontrolę, ale sprawia, że przeprowadzanie transakcji jest uciążliwe, ponieważ potrzeba wielu urządzeń, przejścia do trybu online i zaangażowania się w obliczenia TSS.
Trzecia opcja jest uważana za najlepszą mieszankę plusów i minusów z obu światów, ponieważ zapewnia użytkownikowi łatwy i szybki sposób przeprowadzania transakcji, ale dalej bez możliwości przeprowadzania transakcji bez autoryzacji użytkownika.
TSS i smart kontrakty
Zagrożenia
Po pozytywnej stronie natomiast warto wspomnieć o tym, iż co rusz powstają nowe przykłady skutecznych implementacji TSS, co z kolei skutkuje pojawianiem się wielu audytów i propozycji ulepszeń na polu wydajności tego algorytmu.
Przemyślenia końcowe
W tym artykule przedstawiliśmy jedynie podstawy schematu podpisów progowych (TSS), który jest bardzo ciekawym przykładem algorytmu kryptograficznego niskiego poziomu, a który ma moc wprowadzenia istotnych zmian w sposobie w jaki wykorzystujemy technologię blockchain.
Lista dodatkowych i sugerowanych źródeł do przeczytania (w języku angielskim):