FROST

Wyobraźmy sobie stowarzyszenie, którego oszczędnościami zarządzają Anna, Jan i Ewa. Wybierają zasadę 2 z 3: płatność mogą zatwierdzić Anna z Janem, Anna z Ewą albo Jan z Ewą. Każdy przechowuje inny tajny udział, czyli kryptograficznie utworzony fragment wspólnego materiału kluczowego. Jeden nie wystarczy, ale nie są to też trzy kopie tego samego hasła. Gdy Ewa jest niedostępna, pozostali mogą współpracować. Ta sama granica dotyczy napastnika: zdobycie wystarczającej liczby udziałów również pozwala mu podpisywać. Rozdzielenie ma więc sens tylko wtedy, gdy przejęcie jednego urządzenia lub konta nie otwiera dostępu do wszystkich pozostałych. [1] [2]

Anna nie powinna zatwierdzać operacji tylko dlatego, że aplikacja informuje o oczekującym podpisie. Musi znać odbiorcę, kwotę i opłatę oraz sprawdzić, czy ewentualna reszta wraca do stowarzyszenia. Każdy podpisujący potrzebuje wiarygodnego sposobu sprawdzenia rzeczywistej transakcji. Hash, krótki kryptograficzny odcisk danych, nie wyjaśnia człowiekowi ich treści. FROST umożliwia współpracę nad tą samą wiadomością; nie oceni autentyczności faktury ani tego, czy ktoś zrozumiał, co zatwierdza. Nawet gotowy podpis nie oznacza potwierdzenia płatności w bloku. Blok to grupa transakcji zapisana we wspólnej historii sieci Bitcoin. RFC 9591 jest informacyjną specyfikacją protokołu, a nie certyfikatem bezpieczeństwa całej aplikacji. [1] [2]

Taproot to ulepszenie Bitcoina, które pozwala wydać środki za pomocą podpisu odpowiadającego właściwemu kluczowi lub przez spełnienie wcześniej określonych warunków. Odpowiednio skonstruowany podpis progowy może przy wydawaniu środków ścieżką klucza Taproot wyglądać jak zwykły podpis jednego klucza. Z samego podpisu nie da się odczytać wewnętrznej liczby udziałów ani progu. Sprzyja to prywatności i ogranicza rozmiar danych podpisu, ale nie zapewnia anonimowości całej transakcji ani komunikacji uczestników. Bitcoin wymaga dokładnych reguł BIP 340; ogólny FROST na krzywej secp256k1, stanowiącej matematyczną podstawę obliczeń z kluczami Bitcoina, nie wystarcza. Dlatego Zcash Foundation (ZF) udostępnia frost-secp256k1-tr specjalnie dla Taproot. Trzeba też poprawnie obsłużyć modyfikacje klucza stosowane przez Taproot. Zgodna nazwa krzywej nie dowodzi kompatybilności, a istnienie biblioteki nie oznacza obsługi w każdym portfelu. [3] [4]

Zanim stowarzyszenie cokolwiek podpisze, musi bezpiecznie utworzyć udziały. Zaufany dystrybutor może wygenerować cały klucz i go podzielić. Powstaje jednak wrażliwy moment: zna cały klucz, a zachowana kopia pozwoliłaby obejść zamierzone wspólne zatwierdzanie. Alternatywą jest DKG, rozproszone generowanie klucza, w którym cały tajny klucz nie musi pojawić się u jednego uczestnika. Wymaga to uwierzytelnionej, chronionej komunikacji i poprawnego wykonania protokołu. Wysłanie kilku plików e-mailem nie wystarczy. RFC 9591 skupia się na podpisywaniu; nie obiecuje automatycznie DKG w każdym produkcie. Długoterminowy udział klucza różni się też od części podpisu jednej konkretnej płatności. [1] [2]

Sam proces podpisywania obejmuje dwie rundy; wcześniejsze generowanie klucza nie jest do nich wliczane. Najpierw każdy wybrany uczestnik tworzy dwie tajne jednorazowe wartości nonce i przesyła ich publiczne zobowiązania: wartości wiążące go kryptograficznie z tymi nonce. Następnie otrzymuje wspólną wiadomość i listę zobowiązań, sprawdza dane i oblicza swoją część podpisu. Koordynator łączy części. Czynniki wiążące łączą obliczenia z konkretną wiadomością, publicznym kluczem grupy i zobowiązaniami. Przy zasadzie 2 z 3 można rozpocząć sesję z dwiema osobami. Jeśli jednak wybrano wszystkie trzy, każda musi dostarczyć swój wkład; nie można po prostu pominąć osoby, która przestała odpowiadać. [1] [3]

Nonce jest tutaj tajną wartością do jednej próby podpisania, a nie hasłem wielokrotnego użytku. Ponowne użycie może ujawnić tajny materiał kluczowy. Jeśli komputer Jana ulegnie awarii po wysłaniu części podpisu, odtworzenie dawnego stanu nie może oznaczyć zużytych nonce jako nowych. Niedokończona płatność również nie uprawnia do ponownego ich użycia. Bezpieczna implementacja potrzebuje dobrej losowości, rozdzielenia równoległych prób i niezawodnego wycofywania wykorzystanych wartości. Dlatego nie warto samodzielnie składać FROST z przypadkowych skryptów. Poprawna matematyka nie ochroni źle zarządzanych tajnych danych. [1]

Koordynator organizuje wiadomości, ale sama ta rola nie pozwala mu podpisywać za stowarzyszenie. Potrzebuje wkładu wybranych posiadaczy udziałów. Może jednak zatrzymać komunikację lub przerwać sesję, podobnie jak może ją udaremnić nieprawidłowy wkład uczestnika. Kontrole wykrywają nieprawidłową część podpisu; przypisanie błędu konkretnej osobie wymaga wiarygodnego ustalenia pochodzenia wiadomości. Wykrycie problemu nie gwarantuje zakończenia. Kolejna próba potrzebuje dostępnej uprawnionej grupy i świeżych nonce. Stowarzyszenie musi więc mieć plan na awarie i spory, a nie tylko próg wyświetlony na ekranie powitalnym. [1] [2]

Gdy Ewa straci urządzenie, sam napis FROST nie odzyska środków. Kopia zapasowa musi zachować jej udział, identyfikator, potrzebne dane grupy i możliwość wczytania ich w zgodnym programie. Nie jest to automatycznie zwykła Seed Phrase, czyli słowna kopia zapasowa portfela. Odzyskanie udziału z pomocą innych oraz odświeżanie udziałów to dodatkowe procedury, które konkretny system musi obsługiwać. Kopia udziału Ewy nadal jest tym samym udziałem i nie dodaje niezależnego głosu. Odświeżenie z zachowaniem klucza grupy nie unieszkodliwia też wystarczającego zestawu wcześniej skradzionych udziałów. Przed użyciem prawdziwych oszczędności próba powinna więc obejmować odzyskiwanie, awarie i dokładną wersję programu, a nie tylko jeden udany podpis. [2] [3]