Co przekaźnik SSP może, a czego nie może zobaczyć
SSP to portfel dwuurządzeniowy. Rozszerzenie przeglądarki trzyma jeden klucz, telefon drugi, i żadne z nich nie ruszy środków samodzielnie. Ale te dwa urządzenia muszą ze sobą rozmawiać, a robią to przez serwer, który prowadzimy i nazywamy przekaźnikiem.
Ten serwer to oczywiste miejsce na niewygodne pytanie: skoro wszystko przechodzi przez infrastrukturę obsługiwaną przez firmę od portfela, co dokładnie widzi ta firma?
To uczciwe pytanie i zasługuje na odpowiedź konkretną, a nie uspokajającą. Oto więc, co naprawdę jest w kodzie.
Przekaźnik nie może niczego podpisać
Zacznijmy od tego, co najważniejsze.
Przekaźnik nigdy nie otrzymuje klucza prywatnego. Ani zaszyfrowanego, ani podzielonego, w żadnej postaci. Klucz portfela zostaje w rozszerzeniu przeglądarki, a klucz aplikacji na telefonie; przez sieć przechodzą wyłącznie klucze publiczne, dane niepodpisane oraz podpisy powstałe już na twoich urządzeniach.
To nie jest zobowiązanie regulaminowe, lecz strukturalne. Multipodpis dwa-z-dwóch wymaga obu podpisów, by ruszyć środki, a przekaźnik nie posiada żadnego z kluczy. Całkowicie złośliwy przekaźnik — nasz, przejęty albo podmieniony przez napastnika — wciąż nie wytworzy poprawnej transakcji, bo jej wytworzenie wymaga sekretów, których nigdy mu nie wysłano.
To jest ta gwarancja. Wszystko poniżej dotyczy tego, czym przekaźnik faktycznie się zajmuje: zbioru węższego, ale naprawdę niepustego.
Co przez niego przechodzi i jak długo
Przekaźnik przechowuje cztery rodzaje zapisów. Dwa kasują się same.
Dane synchronizacji, gdy parujesz oba urządzenia. Niosą łańcuch, twoją tożsamość portfela, rozszerzony klucz publiczny aplikacji, wynikową tożsamość WK, publiczne nonce, wygenerowany adres oraz xpub odzyskiwania wraz z jego podpisem.
Dane akcji, gdy coś podpisujesz. Niosą łańcuch, ścieżkę wyprowadzenia, twoją tożsamość WK, rodzaj akcji, sam ładunek oraz odpowiednie UTXO.
Obie kolekcje mają w MongoDB indeks TTL ustawiony na expireAfterSeconds: 900. Piętnaście minut. Baza kasuje zapis niezależnie od tego, co się jeszcze wydarzy — to nie zadanie porządkowe, o którym ktoś musi pamiętać, ani obietnica w polityce prywatności. To indeks, egzekwowany przez samą bazę.
Tokeny powiadomień push, żeby telefon dało się obudzić, gdy jest coś do zatwierdzenia. Te zostają, bo token wygasający co piętnaście minut byłby bezużyteczny.
Xpub odzyskiwania, jeden na tożsamość, zupełnie bez wygasania. To celowe i kod tak mówi: istnieje po to, by portfel mógł go pobrać, kiedy tylko go potrzebuje, a nie jedynie w krótkich chwilach, gdy obie aplikacje akurat czuwają.
Część, o której powinniśmy powiedzieć wprost
Spójrz jeszcze raz na ten ładunek synchronizacji. Zawiera rozszerzony klucz publiczny.
Xpub nie jest kluczem wydawania i nie może autoryzować transakcji. Ale to nie jest nic. Z xpuba konta da się wyprowadzić każdy adres, jakiego to konto kiedykolwiek użyje, co znaczy, że kto go ma, może obserwować całe saldo i całą historię transakcji w tym łańcuchu. To dostęp do odczytu twojego życia finansowego na tym koncie — dokładnie to powiązanie, którego unikanie stanowi istotę prywatności w łańcuchu.
Ładunek akcji jest równie realny. Gdy podpisujesz, przekaźnik obsługuje niepodpisaną transakcję: dokąd idą pieniądze, ile ich jest i z których wyjść.
Uczciwe podsumowanie nie brzmi więc „przekaźnik nic nie widzi”. Brzmi:
Przekaźnik nie może wydać twoich pieniędzy, a przez piętnaście minut naraz może widzieć, co z nimi robisz.
Piętnastominutowe okno jest złagodzeniem i to znaczącym — ogranicza, ile historii może zgromadzić się w jednym miejscu. Ale w tym oknie dane tam są, a my wolimy powiedzieć to wprost, niż pozwolić, by „niepowiernicze” wykonywało retoryczną robotę, na którą nie zapracowało.
Zasada projektowa warta pożyczenia
W usłudze odzyskiwania jest komentarz, który oddaje architekturę lepiej niż jakikolwiek diagram:
portfel weryfikuje ten podpis względem klucza publicznego tożsamości, który sam wyprowadza, więc temu magazynowi się nie ufa.
Xpub odzyskiwania przechowywany jest razem z odłączonym podpisem, który SSP Key nad nim złożył. Gdy portfel go pobiera, niezależnie wyprowadza klucz publiczny tożsamości i sam sprawdza podpis. Gdyby przekaźnik zwrócił inny xpub — przez przejęcie, błąd albo celową podmianę — podpis by się nie zgadzał i portfel by go odrzucił.
Oprogramowanie zależne od przekaźnika traktuje go jak niezaufaną rurę. To właściwy sposób budowania na infrastrukturze, którą sam prowadzisz, bo oznacza, że błąd twojego serwera nie staje się problemem twoich użytkowników. To także wzorzec, którego warto szukać przy ocenie dowolnego portfela: nie „czy obiecują się zachowywać?”, lecz „co się stanie, jeśli ich serwer zachowa się źle?”.
Co wrogi przekaźnik mógłby naprawdę zrobić
Warto być konkretnym co do rzeczywistego modelu zagrożeń.
Mógłby obserwować. W oknie TTL twój xpub i twoją oczekującą transakcję. To odsłonięcie prywatności, a nie ryzyko kradzieży.
Mógłby cenzurować. Odmówić przekazywania wiadomości między twoimi urządzeniami, co uniemożliwiłoby ci podpisywanie nowych transakcji zwykłą drogą. Uciążliwe i zakłócające — i nie to samo co utrata czegokolwiek. Twoje klucze wciąż są twoje, środki wciąż są w łańcuchu, a ścieżki odzyskiwania istnieją właśnie dlatego, że przekaźnika może nie być.
Mógłby kłamać i przeważnie zawieść. Podmianę xpuba odzyskiwania udaremnia opisane wyżej sprawdzenie podpisu. Dlatego ta weryfikacja ma znaczenie.
Nie może podpisać. Bez klucza nie ma podpisu, nie ma transakcji.
Realistycznie najgorszy przypadek to inwigilacja i zakłócenie, nie utrata. To wyraźnie lepsza pozycja niż przy usłudze powierniczej, gdzie odpowiednikiem najgorszego przypadku jest to, że pieniędzy nie ma. To nie to samo co „nikt nic nie widzi”, a mylenie tych dwóch rzeczy sprawia, że ludzie mają fałszywy obraz własnej prywatności.
Co możesz zrobić z widocznymi częściami
Zrozum, co odsłania parowanie. Zsynchronizowanie łańcucha oznacza, że xpub tego łańcucha przechodzi przez przekaźnik. To koszt tego, że projekt dwuurządzeniowy w ogóle działa.
Pamiętaj, że okno jest krótkie, ale niezerowe. Piętnaście minut na akcję to ograniczenie, a nie nieobecność.
Traktuj xpub odzyskiwania jako trwały. Z założenia przechowuje się go bez wygasania i jest to publiczny materiał klucza z dołączonym weryfikowalnym podpisem — ale jest trwały i lepiej to wiedzieć, niż odkryć.
Oceniaj architekturę, a nie zapewnienia. Użyteczne pytanie o serwer jakiegokolwiek portfela nie brzmi, czy firma obiecuje dyskrecję. Brzmi, czy oprogramowanie zauważyłoby, że serwer skłamał. Nasze sprawdza podpisy zamiast wierzyć odpowiedziom, a możesz to przeczytać w kodzie, zamiast wierzyć nam na słowo.
Najbardziej chcielibyśmy, by zrozumiano kształt tej wymiany. Portfel dwuurządzeniowy potrzebuje kanału koordynacji, a kanał koordynacji to miejsce, w którym gromadzą się metadane. Ograniczyliśmy to wygasaniem egzekwowanym przez bazę i zaprojektowaliśmy klientów tak, by nie ufali serwerowi — ale uczciwa wersja brzmi: przekaźnik widzi rzeczy prawdziwe, przez chwilę, i żadna staranna architektura nie sprowadzi tej liczby do zera.
