Podpisy Progowe (ang. Threshold Signatures)
Strona G艂贸wna
Artyku艂y
Podpisy Progowe (ang. Threshold Signatures)

Podpisy Progowe (ang. Threshold Signatures)

Zaawansowany
Opublikowane Jul 21, 2019Zaktualizowane Apr 29, 2021
12m
Schemat Podpis贸w Progowych (TSS), to nic innego jak algorytm kryptograficzny niskiego poziomu, kt贸ry dedykowany jest tworzeniu (generowaniu) kluczy i wykorzystywaniu ich do podpisywania cyfrowych danych. TSS znajduje szczeg贸lne zastosowanie w sieciach blockchain, a wykorzystywany jest szczeg贸lnie w zakresie zwi臋kszenia bezpiecze艅stwa sieci. W szerszym znaczeniu, TSS ma mo偶liwo艣膰 wywarcia znacz膮cego wp艂ywu w systemach s艂u偶膮cych do zarz膮dzania kluczami (takich jak np. portfele do przechowywania kryptowalut). TSS jednocze艣nie stoi u podstaw dziedziny DeFi. Mimo to, TSS nale偶y w dalszym ci膮gu postrzega膰 jako nowa technologa, dlatego te偶 warto wzi膮膰 pod uwag臋 wynikaj膮ce z jej u偶ycia ryzyka i ograniczenia.

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

Aby m贸c zrozumie膰 algorytm TSS, to w pierwszej kolejno艣ci koniecznie musimy zrozumie膰 i posiada膰 podstawow膮 wiedz臋 na temat kryptografii. Pocz膮wszy od lat 70. XX wieku u coraz wi臋kszej ilo艣ci system贸w internetowych (takich jak TLS i PGP聽) zacz臋to stosowa膰 kryptografi臋 asymetryczn膮, znan膮 r贸wnie偶 jako kryptografi臋 klucza publicznego (Public Key Cryptography). PKC opiera si臋 na wykorzystaniu dw贸ch kluczy: publicznego i prywatnego. O ile klucz publiczny nie musi by膰 trzymany w tajemnicy mo偶na go bez obaw publicznie zakomunikowa膰, mo偶e by膰 te偶 wykorzystany przez dos艂ownie ka偶dego, o tyle klucz prywatny jest fragmentem daj膮cym dost臋p do tajnych informacji niedost臋pnych publicznie (przy u偶yciu klucza publicznego).
Szyfrowanie (ang. encryption) oraz podpisy cyfrowe (ang. digital signatures) s膮 dwoma najcz臋艣ciej wymienianymi przyk艂adami w kt贸rych stosuje si臋 PKC. Zar贸wno algorytmy szyfruj膮ce jak i podpisy cyfrowych opieraj膮 si臋 na zestawach trzech algorytm贸w. Pierwszy z nich odpowiada za generowanie pary kluczy prywatnych i publicznych, drugi za generowanie tekstu zaszyfrowanego/podpisu, a trzeci, odpowiada za proces deszyfrowania/weryfikacji dostarczonych danych. W odniesieniu do podpis贸w cyfrowych, to w ich przypadku algorytm s艂u偶膮cy do podpisu w celu uzyskania unikalnego podpisu wymaga podania klucza prywatnego, kt贸ry znany jest jedynie jego w艂a艣cicielowi. Tak wygenerowany podpis (ang. signature) do艂膮czany jest p贸藕niej do danej wiadomo艣ci propagowanej w sieci przez w艂a艣ciciela klucza prywatnego w taki spos贸b, 偶e ka偶dy, kto posiada odpowiedni klucz publiczny, b臋dzie m贸g艂 zweryfikowa膰 autentyczno艣膰 i poprawno艣膰 takiej wiadomo艣ci.


Blockchain

Nikt nie powinien mie膰 偶adnych w膮tpliwo艣ci, 偶e blockchain jest bardzo pot臋偶n膮 technologi膮. Sieci blockchain zapewniaj膮 odpowiedni膮 przestrze艅, kt贸ra dzia艂a wedle zasad zapisanych w konsensusie, w kt贸rej w odpowiedni spos贸b zapisywane i organizowane s膮 wpisy (rekordy). Dzi臋ki temu my, u偶ytkownicy, zyskujemy potencjaln膮 moc do tworzenia zdecentralizowanych gospodarek, a nawet rz膮d贸w. Co zaskakuj膮ce, lista algorytm贸w kryptograficznych potrzebnych do uruchomienia podstawowej sieci blockchain mo偶e zamkn膮膰 si臋 na podpisach cyfrowych. W kontek艣cie sieci blockchain, klucze prywatne reprezentuj膮 to偶samo艣膰 (osob臋, byt), podczas gdy podpisy s膮 publicznym o艣wiadczeniem lub roszczeniem stworzonym/opublikowanym przez dan膮 to偶samo艣膰. Blockchain z kolei porz膮dkuje i weryfikuje takie o艣wiadczenia zgodnie z przyj臋tym w konsensusie sieci zestawem regu艂, kt贸ry mi臋dzy innymi dba o to, aby podpisy by艂y unikalne oraz poprawne.
Algorytmy kryptograficzne wykorzystywane na pocz膮tku formowania si臋 pierwszych sieci blockchain znacz膮co r贸偶ni膮 si臋 od tych dost臋pnych dzisiaj. Do najbardziej niesamowitych algorytm贸w nale偶膮 obecnie: dowody zerowej wiedzy (ang. zero-knowledge proofs), algorytm szyfrowania homomorficznego, algorytmy do wielopodmiotowych oblicze艅 - jednak jest ich zdecydowanie wi臋cej. Ostatnia dekada w dziedzinie technologii blockchain spowodowa艂a ogromny wzrost zastosowa艅 kryptografii i pojawienie si臋 wielu innowacyjnych algorytm贸w - kt贸re stosowane s膮 ju偶 nie tylko w 艣wiecie 艂a艅cuch贸w blok贸w.聽

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

TSS w naturalny spos贸b mo偶na wykorzysta膰 w blockchain w celu generowania kluczy i podpis贸w cyfrowych. W tym kontek艣cie b臋dzie to zestaw polece艅 wykonywanych przez pe艂ny w臋ze艂 (ang. full node). W praktyce technologia TSS pozwala nam zast膮pi膰 wszystkie polecenia zwi膮zane z kluczem prywatnym rozproszonymi obliczeniami.

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

Niekt贸re sieci blockchain oferuj膮 funkcjonalno艣膰 TSS jako wbudowan膮 lub programowaln膮 cz臋艣膰 swojej sieci. Funkcjonalno艣膰 ta zazwyczaj nazywana jest multisig lub multi-signature. Aby lepiej zrozumie膰 r贸偶nice, najpro艣ciej jest spojrze膰 na multisig jako TSS w warstwie aplikacji blockchain.

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.

G艂贸wn膮 r贸偶nic膮 mi臋dzy TSS a Multisig jest to, 偶e multisig jest unikalne dla ka偶dej sieci blockchain i nale偶y go ponownie wdro偶y膰 dla ka偶dej kolejnej sieci. W niekt贸rych przypadkach nie jest te偶 w og贸le obs艂ugiwany. TSS natomiast zbudowany jest na bazie uniwersalnych algorytm贸w kryptograficznych, dzi臋ki czemu jego obecno艣膰 w danej sieci jest zawsze mo偶liwa. 艢wietny artyku艂 obja艣niaj膮cy r贸偶nic臋 pomi臋zy TSS i Multisig znajdziesz tutaj.


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 鈥渢he 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

Portfele wykorzystuj膮ce technologi臋 TSS w pewnych aspektach r贸偶ni膮 si臋 od tradycyjnych portfeli do przechowywania kryptowalut. W przypadku tradycyjnych portfeli, te na podstawie wygenerowanej seedphrase deterministycznie uzyskuj膮 adres do przechowywania 艣rodk贸w przez u偶ytkownika. U偶ytkownik mo偶e nast臋pnie wykorzysta膰 t臋 struktur臋 deterministyczn膮, aby 1) dotrze膰 do kluczy prywatnych, kt贸re odpowiadaj膮 adresom portfeli i podpisa膰 nimi transakcje w tych portfelach, oraz 2), odzyska膰 wszystkie klucze daj膮ce dost臋p do 艣rodk贸w w portfelu przy u偶yciu seedphrase.

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 鈥瀞eed鈥, 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 鈥渘鈥 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聽

Badacze z dziedziny kryptografii przez wiele lat istnienia TSS znale藕li wiele zastosowa艅 dla podpis贸w cyfrowych. Niekt贸re z nich s膮 zaskakuj膮co nietrywialne. Jak ju偶 wspomnieli艣my wcze艣niej, TSS jest algorytmem kryptograficznym niskiego poziomu, kt贸ry jest w stanie znacz膮co zwi臋kszy膰 bezpiecze艅stwo systemu w kt贸rym zostanie zaimplementowany. W przypadku sieci blockchain, mo偶na pokusi膰 si臋 o stwierdzenie, i偶 wiele funkcji dost臋pnych w tych sieciach mo偶na zast膮pi膰 kryptografi膮 opart膮 na TSS. Zdecentralizowane aplikacje, rozwi膮zania skaluj膮ce w ramach tzw. 2 warstwy, atomic swapy, miksowanie 艣rodk贸w, inheritance i wiele innych mo偶na odtworzy膰 wykorzystuj膮c do tego celu jedynie TSS. Pozwoli艂oby to ostatecznie na zast膮pienie kosztownych i ryzykownych operacji wykonywanych przy u偶yciu inteligentnych kontrakt贸w, ta艅szymi i bardziej niezawodnymi alternatywami.
Aby lepiej zrozumie膰 t臋 kwesti臋 pos艂u偶my si臋 przyk艂adami: Multi-Hop Locks, to rozwi膮zanie, kt贸re w sprytny spos贸b wykorzystuje podpisy-obustronne, co otwiera drog臋 do wykorzystania ich, jako alternatywy dla rozwi膮zania Lightning Network z sieci Bitcoin, jako bardziej bezpieczna i prywatna sie膰 kana艂贸w p艂atno艣ci. ShareLock jest prawdopodobnie najta艅szym rozwi膮zaniem pozwalaj膮cym na miksowanie on-chain 艣rodk贸w w sieci Ethereum, a kt贸re oparte jest na weryfikacji pojedynczej sygnatury progowej.


Zagro偶enia

Ostatnie kilka lat w 艣wiecie internetu i bran偶y komputerowej zaowocowa艂o znacz膮cym zwi臋kszeniem ilo艣ci rozwi膮za艅 w kt贸rych podj臋to si臋 implementacji TSS. Mimo wszystko, TSS jako stosunkowo nowa technologia wci膮偶 ma pewne ograniczenia i niesie za sob膮 pewne ryzyka. W por贸wnaniu z klasycznymi algorytmami kryptografii kluczy publicznych, protoko艂y TSS mog膮 by膰 bardzo z艂o偶one i nie zosta艂y jeszcze do ko艅ca sprawdzone w "walce". Co wi臋cej, rozwi膮zania wykorzystuj膮ce TSS zazwyczaj wymagaj膮 dodatkowych oraz jednocze艣nie s艂abszych kryptograficznych za艂o偶e艅 w por贸wnaniu do prostych podpis贸w cyfrowych. W rezultacie co rusz odkrywane s膮 kryptograficzne wektory ataku, kt贸re nie istniej膮 w tradycyjnych konfiguracjach (wi臋cej na ten temat znajdziesz w tej prezentacji z konferencji Breaking Bitcoin 2019). Mimo wszystko odpowiednio wyszkoleni in偶ynierowie bezpiecze艅stwa i do艣wiadczeni kryptografowie mog膮 pom贸c w odpowiednio bezpiecznym wdro偶eniu TSS do Twojego systemu.

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.

Poniewa偶 w artykule nie om贸wili艣my Schematu ECDSA, z kt贸rego dobrodziejstw mo偶na skorzysta膰 m.in w sieciach Binance Chain i Bitcoin, dla zainteresowanych czytelnik贸w podajemy list臋 dodatkowych 藕r贸de艂, kt贸re mog膮 pom贸c w lepszym zg艂臋bieniu tej tematyki. Ponadto, je艣li zechcia艂by艣 pobawi膰 si臋 kodem niekt贸rych implementacji TSS, to m.in deweloperzy portfela Binance Chain opublikowali jego kod 藕r贸d艂owy kt贸ry znajdziesz tutaj. Mo偶esz te偶 sprawdzi膰 portfel ZenGo dla Binance Chain, kt贸ry wykorzystuje metod臋 hybrydow膮 o kt贸rej wspominali艣my wy偶ej.


Lista dodatkowych i sugerowanych 藕r贸de艂 do przeczytania (w j臋zyku angielskim):