BIP 39

Alicja zakłada portfel korzystający z BIP39 i zgodnie z instrukcjami bezpiecznie zapisuje słowa odzyskiwania. Po pewnym czasie jej telefon się psuje. Bitcoiny nie zniknęły z sieci: straciła urządzenie przechowujące klucze do podpisywania jej płatności. Na zaufanym urządzeniu zastępczym może użyć funkcji odzyskiwania w kompatybilnym portfelu. Te same słowa w tej samej kolejności oraz ta sama passphrase, jeśli była używana, dadzą ten sam seed. Dalsze procedury ponownie utworzą z niego potrzebne klucze prywatne, a portfel odnajdzie płatności w sieci Bitcoin. Nie jest to logowanie do konta, którego hasło może zresetować pomoc techniczna. Jeśli Alicja używała passphrase, również jej potrzebuje; PIN starego telefonu jej nie zastąpi. Zerowe saldo po odzyskaniu portfela nie musi oznaczać utraty monet: poza słowami i passphrase trzeba sprawdzić wybór konta oraz ustawienia odzyskiwania. Dlatego warto zweryfikować cały proces przed przechowaniem większej kwoty. [1] [5] [13] [14]

Słowa łatwiej przepisać i sprawdzić niż długi zapis danych komputerowych. Marek Palatinus, Pavol Rusnak, Aaron Voisine i Sean Bowe zaproponowali sposób przedstawiania losowości wygenerowanej komputerowo w postaci nadającej się do ręcznego przepisania. Propozycja nosi datę 10 września 2013 r. i ma w specyfikacji status Deployed. Słowa powinny powstać z dobrej jakości losowych danych wejściowych; nie należy wymyślać ich na podstawie ulubionego zdania. W ten sposób powstałby Brainwallet oparty na przewidywalnym sekrecie wybranym przez człowieka. Węzły Bitcoina nie sprawdzają BIP39: weryfikują transakcje i bloki, a nie sposób, w jaki portfel utworzył swoje klucze. [1]

Dobry zapis pomoże tylko wtedy, gdy potrafisz na jego podstawie przywrócić portfel. Zanim powierzysz mu znaczne środki, na zaufanym urządzeniu sprawdź procedurę odzyskiwania zalecaną przez producenta. Oprócz dokładnej kolejności słów zachowaj potrzebną passphrase, informacje o portfelu i ewentualne ustawienia derywacji lub podpisywania. W zwykłym portfelu wymagającym jednego podpisu posiadacz pełnej kopii zapasowej z odpowiednią passphrase może wyprowadzić klucze bez pierwotnego urządzenia; w przypadku Multisig trzeba spełnić dodatkowe wymagania dotyczące kluczy i reguł podpisywania. Zdjęcia, kopia w chmurze, drukarka lub historia schowka mogą ujawnić sekrety innym osobom i usługom. Papier i metal mają różne ograniczenia fizyczne; żaden materiał sam nie zapobiega kradzieży. [9] [13] [14]

Ze względu na zgodność BIP39 zdecydowanie zaleca angielską listę słów: wiele portfeli nie obsługuje innych list. Tłumaczenie kopii zapasowej nie zachowuje pierwotnego portfela, ponieważ przy wyprowadzaniu seedu wykorzystuje się sam tekst frazy. Uważaj również na inne systemy. Electrum stosuje we własnych kopiach zapasowych odrębny mechanizm wersjonowania; podobnie wyglądające słowa nie czynią ich automatycznie zgodnymi z BIP39. SLIP39 to inny format z własną listą 1 024 słów i regułami określającymi, ile udziałów potrzeba do odzyskania sekretu. Nie polega na zwykłym pocięciu kopii zapasowej BIP39. Rozłożenie 24 słów do kilku kopert nie tworzy Shamir Secret Sharing i może pogorszyć zarówno ochronę, jak i możliwość odzyskania portfela. Zawsze trzeba znać rzeczywisty format kopii zapasowej. [1] [11] [12]

Punktem wyjścia jest entropia, czyli losowe dane o długości ENT = 128, 160, 192, 224 lub 256 bitów. Dodaje się do nich sumę kontrolną: pierwsze CS = ENT/32 bitów wyniku SHA-256 obliczonego dla pierwotnych danych. Całość dzieli się na grupy po 11 bitów, z których każda wskazuje jedno słowo. Zależność MS = (ENT+CS)/11 daje zatem dokładnie 12, 15, 18, 21 lub 24 słowa. Dwanaście słów reprezentuje 128 bitów losowości i 4 bity kontrolne; nie wszystkie 132 bity stanowią więc niezależny sekret. Przy 24 słowach podział wynosi 256+8 bitów. Zaufanie do kopii zapasowej zaczyna się od generatora losowości, a nie od tego, jak niezwykle wyglądają słowa. [1]

Każda grupa 11 bitów wybiera jedną pozycję z uporządkowanej listy 2 048 słów. Pierwsze słowo nie jest więc pierwszym kluczem prywatnym: wszystkie słowa razem zapisują pierwotne dane i ich sumę kontrolną. W angielskiej liście do rozróżnienia słów wystarczą pierwsze cztery litery. Nie jest to jednak uniwersalna zasada dla dowolnego języka ani zachęta do samowolnego skracania kopii zapasowej podczas przywracania. Zmiana kolejności, zastąpienie słowa synonimem lub tłumaczenie zmieniają dane wejściowe. Czasem powstaje nieprawidłowa suma kontrolna, a czasem inna poprawna kopia zapasowa; trzeba więc dokładnie zachować zarówno brzmienie słów, jak i ich kolejność. [1] [2]

Komputer musi wiedzieć, jakie znaki rzeczywiście otrzymał. BIP39 wymaga normalizacji Unicode NFKD, a następnie kodowania UTF-8 zarówno dla frazy odzyskiwania, jak i passphrase. NFKD ujednolica niektóre różne sposoby zapisu znaków, na przykład rozkładając część liter ze znakami diakrytycznymi. Dwa różne zapisy mogą zatem dać ten sam wynik po normalizacji; samo podobieństwo wizualne tego jednak nie gwarantuje. Kolejność słów, spacje i znaki passphrase nadal mają znaczenie. Inny sposób normalizacji może podczas przywracania doprowadzić do wyprowadzenia innego seedu. Implementacja referencyjna i publiczne wektory testowe pomagają sprawdzić, czy program przestrzega wymaganego sposobu obliczeń. [1] [3] [4]

PBKDF2 otrzymuje dwa oddzielne wejścia. Wejście password tworzą rzeczywiste słowa odzyskiwania. Drugie wejście nazywa się salt i dostarcza dodatkowych danych do obliczeń kryptograficznych. Tutaj jest to dosłowny tekst „mnemonic”, do którego bez separatora dołącza się passphrase. Samych słów odzyskiwania nie umieszcza się tutaj ponownie. Oba wejścia są normalizowane za pomocą NFKD i kodowane w UTF-8. BIP39 określa HMAC-SHA512, 2 048 iteracji oraz wynik o długości 512 bitów, czyli 64 bajtów. Bez passphrase salt pozostaje równy „mnemonic”; pusta jest tylko passphrase. Obliczenie nie odszyfrowuje słów i nie tworzy nowej, niezależnej losowości. Po ujawnieniu słów same iteracje nie ochronią więc łatwej do odgadnięcia passphrase. [1] [10]

BIP39 kończy się na seedzie o długości 64 bajtów. Inny standard, BIP32, zwykle wyprowadza z niego główny klucz prywatny i 32-bajtowy chain code za pomocą HMAC-SHA512 ze stałym kluczem „Bitcoin seed”. Chain code to dodatkowe dane, które wraz z kluczem służą do wyprowadzania kolejnych kluczy. Te dwa elementy są punktem wyjścia dla całego drzewa kluczy. Reguły takie jak BIP44, BIP49, BIP84 i BIP86 określają różne ścieżki derywacji i typy skryptów. Podczas przywracania możesz więc wpisać poprawne słowa i passphrase, a mimo to zobaczyć zerowe saldo, jeśli program szuka innego konta, innej gałęzi lub innego typu adresu. Ważny jest też gap limit, czyli liczba kolejnych nieużywanych adresów, na które program może natrafić podczas wyszukiwania. Nazwa pierwotnego portfela, informacje o kontach, ścieżki derywacji lub Output Descriptor mogą uzupełnić dane, których nie zawierają same słowa. [5] [6] [7] [8] [9] [14]

Passphrase to dodatkowe tajne wejście do wyprowadzania seedu. Nie jest PIN-em urządzenia, a BIP39 nie potrafi zgłosić, że wpisano niewłaściwą wartość: obliczy wynik również dla innej. Literówka zmieniająca znormalizowane wejście zwykle prowadzi do innego portfela, w którym nie zobaczysz swoich środków. Natomiast różne zapisy dające ten sam wynik NFKD wyprowadzą ten sam seed. Kto uzyska słowa odzyskiwania oraz informacje pozwalające rozpoznać poszukiwany portfel, może sprawdzać możliwe wartości passphrase offline. Jeśli używasz passphrase, potrzebuje ona odpowiedniej siły, zaufanego sposobu wprowadzania i własnej niezawodnej kopii zapasowej. Oddzielne przechowywanie ma ograniczyć ryzyko jednoczesnej kradzieży obu sekretów, a nie uczynić passphrase tajemnicą, która zniknie wraz z tobą. [1] [13]

Suma kontrolna pomaga wykrywać literówki, ale nie dowodzi, do kogo należy kopia zapasowa ani czy utworzono ją bezpiecznie. Przy 12 słowach ma 4 bity, a przy 24 słowach 8 bitów. Jednostajnie losowy ciąg słów z danej listy przejdzie więc kontrolę z prawdopodobieństwem odpowiednio 1/16 lub 1/256. Wiele błędów zostanie wykrytych, ale nie wszystkie; suma kontrolna sama ich też nie poprawi. Atakujący może utworzyć inną kopię zapasową z prawidłową sumą kontrolną. Specyfikacja wymaga ostrzeżenia przy niezgodności i odróżnia kontrolę słów od samego wyprowadzania seedu. Problem nieprawidłowej sumy kontrolnej należy więc rozwiązywać z uwzględnieniem pierwotnego portfela i jego formatu, a nie przez wpisywanie prawdziwej kopii zapasowej do internetowego narzędzia sprawdzającego. [1]