112 / 736BLIND

Blind Signature

Ślepy podpis: potwierdzenie wiadomości bez poznawania jej treści

Wyobraź sobie bon wymagający zatwierdzenia przez wystawcę, który nie powinien przy tym zapisywać jego unikalnego numeru. Później rozpozna autentyczny bon, ale na podstawie podpisu nie ustali, kto go odebrał. Blind Signature pomaga rozwiązać tę pozorną sprzeczność. To jedna z podstaw elektronicznej gotówki: sprawdzić ważność pieniędzy bez tworzenia przy okazji rejestru wszystkich zakupów właściciela.

Blind Signature, czyli ślepy podpis, to procedura kryptograficzna: wnioskodawca ukrywa wiadomość przed podpisującym, otrzymuje podpis ukrytej postaci, a następnie usuwa maskowanie. Pozostaje użyteczny podpis oryginalnej wiadomości. David Chaum zastosował tę ideę do elektronicznej gotówki. W poprawnym protokole podpisujący nie potrafi powiązać późniejszego tokenu z jego wydaniem na podstawie wymiany podczas podpisywania. Inne ślady, takie jak czas, kwota czy adres sieciowy, nie znikają automatycznie.

Przy zwykłym zatwierdzeniu wystawca może zapisać numer bonu i jego odbiorcę. Kiedy sklep zwróci bon, połączy oba zapisy. Chaum objaśniał ślepy podpis kopertą z kalką: pieczęć na zewnątrz odbija się na kartce wewnątrz, której numeru wystawca nie widzi. Wyjęta kartka ma ważne potwierdzenie. To obrazowa analogia, nie bezpieczna procedura z papierem i pieczątką. Rzeczywisty protokół używa liczb i matematyki, by takie rozdzielenie działało między komputerami. [7] [1]

Anna chce cyfrowy bon na 100 sats. Sats to małe jednostki Bitcoina. Portfel, czyli aplikacja do przechowywania tych bonów i płacenia nimi, generuje nieprzewidywalną tajną wartość odróżniającą bon, a potem maskuje ją matematycznie inną losową wartością. To zaślepianie, czyli blinding. Wystawca otrzymuje zamaskowaną wiadomość, nie pierwotny sekret. Portfel zachowuje dane potrzebne do późniejszego usunięcia maskowania. Sama zmiana nazwy pliku czy skasowanie imienia nie wystarcza: zaślepianie musi spełniać precyzyjne wymagania kryptograficzne. Dla prostoty używamy jednego bonu; rzeczywisty portfel może złożyć potrzebną kwotę z kilku bonów o różnych nominałach. [8] [2]

Ślepy podpis nie oznacza podpisywania wszystkiego wszystkim za darmo. Wystawca może najpierw sprawdzić płatność Anny lub pomniejszyć jej saldo. Zna żądaną wartość 100 sats, ale nie musi znać ukrytego numeru bonu. Klucz podpisu to tajna wartość liczbowa, której program wystawcy używa do tworzenia podpisów. Wartość bonu można związać z osobnym kluczem podpisu dla danego nominału; zmiana cyfry w pliku nie stworzy droższego bonu. Wystawca podpisuje ukryte dane i zwraca wynik. Oddzielamy więc powód, dla którego Anna może otrzymać bon, od sposobu późniejszego rozpoznania konkretnego bonu. [7] [8]

Anna nie musi teraz ujawniać pierwotnego sekretu. Portfel sam usuwa losowe maskowanie z otrzymanego wyniku. Ten krok to unblinding. Dobrze zaprojektowana procedura pozostawia ważne potwierdzenie wiadomości przygotowanej na początku, nie przekazując portfelowi prywatnego klucza podpisu wystawcy. Użytkownik widzi nową kwotę; matematyczne pakowanie i rozpakowywanie odbywa się w tle. Cyfrowy dowód często nazywa się tokenem. Nie jest osobnym bitcoinem na blockchainie, czyli wspólnym rejestrze transakcji Bitcoina, lecz roszczeniem wobec wystawcy. [2] [8]

Weryfikacja sprawdza, czy potwierdzenie pasuje do wiadomości i właściwego klucza wystawcy. W ślepych podpisach opartych na systemie kryptograficznym RSA wystarcza klucz publiczny; inne konstrukcje mogą wymagać dodatkowego dowodu lub udziału wystawcy. Nie dowodzi to, że bon nie został jeszcze wykorzystany do zapłaty, że nikt go nie skopiował ani że wystawca ma wystarczające rezerwy. To trzy dalsze pytania. Autentyczny, lecz już wykorzystany bilet nie daje drugiego wejścia. Tak samo kryptograficznie poprawny dowód może nie nadawać się do kolejnej zapłaty. [2] [10]

Anna przesyła bon Piotrowi. Ponieważ to dane, może zachować identyczną kopię. Ślepy podpis nie usuwa plików z jej urządzenia. W typowym systemie online portfel odbiorcy przedstawia więc token wystawcy, który sprawdza ważność i to, czy token z tym samym sekretem został już wykorzystany do zapłaty. Po przyjęciu oznacza stary token jako wykorzystany i może wydać Piotrowi nowy token za pomocą tej samej procedury ślepego podpisywania. Anna nie zna nowego sekretu Piotra. Kolejna próba wydania starej kopii zostanie odrzucona. Ponowne wydanie tych samych środków to double spend, czyli podwójne wydanie; zapobieganie mu jest osobnym elementem systemu płatniczego. [9] [8]

Ochrona musi działać też w drugą stronę: klient nie może z dozwolonych podpisów wytwarzać dodatkowych ważnych dowodów z nowymi sekretami. To niepodrabialność. Przy ślepych podpisach bada się szczególnie one-more unforgeability: czy po określonej liczbie interakcji podpisywania napastnik potrafi przedstawić jeszcze jedną nową, ważną parę wiadomości i podpisu? Kopiowanie tej samej pary jest poprzednim problemem. Kryptografia nie zastępuje także serwerowej kontroli uprawnień, kwot i dozwolonej struktury tokenów. Dopiero łącznie te kontrole mogą zapobiegać nieuprawnionej emisji wartości. [2] [3]

Wystawca może wiedzieć, kiedy Anna otrzymała tokeny i o jakiej wartości. Przy ich realizacji może znać czas, kwotę lub adres sieciowy odbiorcy. To metadane, czyli informacje towarzyszące dowodowi płatności. W małej grupie użytkowników nietypowa kwota lub natychmiastowa kolejna płatność mogą ułatwić powiązanie zdarzeń. Ważne są też wspólne, zweryfikowane klucze: klucz przypisany tylko jednej osobie mógłby ją oznaczać. Ślepota protokołu chroni określone powiązanie podpisu z wydaniem, nie wszystkie informacje dookoła. Nie naprawi też przejętego portfela ani nie wymusi wypłacalności wystawcy. [7] [2]

Idea Chauma leży u podstaw elektronicznej gotówki, historycznie związanej z DigiCash. Dziś wykorzystują ją Cashu i Fedimint, a połączenia z Lightning Network (sieć do szybkich płatności bitcoinem) ułatwiają wpłaty i wypłaty. Ich konstrukcje nie są jednak RSA. Podstawowy Cashu weryfikuje token tajnym kluczem wystawcy, zwanego mintem; NUT-12 dodaje dowód pozwalający sprawdzić podpis publicznymi danymi, ale nie to, czy token nie został już wykorzystany. Fedimint rozdziela zarządzanie między operatorów. W obu przypadkach użytkownik ma roszczenie wobec wystawcy i zależy od przechowywania przez niego środków oraz jego dostępności. GNU Taler na przykład łączy prywatność kupującego z możliwością prześledzenia dochodów sprzedawców. [5] [6] [10] [4]

Uproszczony schemat opisuje kilka równań. Wiadomość bezpiecznie kodujemy jako liczbę m; klucz publiczny zawiera n i e, a d oznacza część prywatną. Wnioskodawca wybiera losowe r z odwrotnością multiplikatywną r⁻¹ modulo n i wysyła m′ = m·r^e mod n. Mod n oznacza obliczenia na resztach z dzielenia przez n. Podpisujący zwraca s′ = (m′)^d mod n, a wnioskodawca otrzymuje s = s′·r⁻¹ mod n. Weryfikacja daje s^e mod n = m. Czynnik r⁻¹ usuwa maskowanie. Te zależności tłumaczą mechanizm, ale nie są gotowym bezpiecznym programem. RFC 9474 określa również przygotowanie wiadomości, schemat RSA-PSS z bezpiecznym kodowaniem, kontrolę danych wejściowych i rozdzielenie kluczy podpisu. Liczą się losowość i właściwy wariant protokołu. [2] [3]

Pełniejszy obraz uzyskasz, czytając to hasło razem z David Chaum, Chaumian eCash, DigiCash, Cashu, Fedimint, Prywatność w Bitcoinie. Do tego hasła prowadzą również odsyłacze z DigiCash, Chaumian eCash, Reusable Proofs of Work, Fedimint.

DOC · 001David Chaum — Blind Signatures for Untraceable PaymentsŹródło pierwotne DOC · 002RFC 9474 — RSA Blind SignaturesSpecyfikacja DOC · 003IRTF/CFRG — RFC 9474 publication recordSpecyfikacja DOC · 004GNU Taler — PrinciplesŹródło pierwotne DOC · 005Cashu protocol specificationsSpecyfikacja DOC · 006Fedimint — How Federations WorkŹródło pierwotne DOC · 007David Chaum — Security without IdentificationŹródło pierwotne DOC · 008Cashu NUT-00 — Notation and modelsSpecyfikacja DOC · 009Cashu NUT-03 — Swapping tokensSpecyfikacja DOC · 010Cashu NUT-12 — DLEQ proofsSpecyfikacja
Zaktualizowano: Najpierw źródła · To nie jest porada inwestycyjna