S tím, jak se bitcoináři obracejí na Nostr jako na komunikační platformu odolnou vůči cenzuře, vyvstanou problémy se správou uživatelských klíčů.
Toto je názorový úvodník Shinobiho, samouka v oblasti bitcoinu a moderátora technicky zaměřeného bitcoinového podcastu.
Před přečtením tohoto článku doporučuji, abyste si přečetli předchozí článek, který jsem napsal a který vysvětluje, co je Nostr a jak funguje na vysoké úrovni. V tu chvíli byste tedy měli mít dobrou představu o základní konstrukci systému, takže se nyní podíváme na pravděpodobné problémy, které se budou vyskytovat při jeho rostoucím přijetí. Vzhledem k tomu, že se tato platforma stává populární pro komunitu Bitcoinu, je třeba si těchto problémů být vědom
Jak jsem uvedl v předchozím článku, páry veřejných/soukromých klíčů uživatelů jsou nedílnou součástí toho, jak Nostr jako protokol funguje. Neexistují žádná uživatelská jména ani žádný typ identifikátorů, které by měl relay server pod kontrolou a které by bylo možné přiřadit k jednotlivým uživatelům. Jsou to jednoduše klíče těchto uživatelů, které jsou plně pod jejich kontrolou.
Funguje to jako pevná vazba mezi skutečným uživatelem a tím, jak je identifikován ostatními, která brání jakémukoli relay serveru tyto dvě věci rozvázat, tj. předat něčí identifikátor jinému uživateli. Tím se řeší jeden z největších základních problémů platforem používaných pro komunikaci mezi lidmi: nedostatek kontroly nad vlastní identitou uživatelů. Zároveň to ale přináší všechny problémy se správou klíčů, na které naráží někdo, kdo vlastní soukromý klíč. Klíče se mohou ztratit a mohou být kompromitovány, a pokud by k takové události došlo, uživatelé se nemají na koho obrátit s žádostí o pomoc, stejně jako v případě Bitcoinu. Neexistuje žádná zákaznická podpora, která by umožnila cokoli obnovit. Když ho ztratíte, je to všechno.
To si nevyhnutelně vyžádá schéma, podle kterého budou uživatelé střídat jeden pár klíčů za druhý způsobem, který bude ověřitelný a zjistitelný pro ostatní uživatele, s nimiž prostřednictvím protokolu komunikují. Celý protokol je založen na dokazování, že událost pochází od konkrétního uživatele (identifikační klíč), takže všechny tyto záruky jdou stranou, jakmile jsou něčí klíče kompromitovány.
Jak to řešíte? Prostě zkontrolujete jejich účet na Twitteru? No, pak to nakonec není příliš decentralizovaný systém, pokud k ověření identity Nostr vyžadujete použití centralizované platformy, kde nemají kontrolu nad svou identitou.
Mají ostatní uživatelé potvrdit legitimitu nového klíče? To neřeší situace, jako jsou hromadné kompromitace klíčů nebo to, že nikdo z blízkých nezná nikoho natolik dobře, aby mohl důvěřovat jeho potvrzení.
Nostr potřebuje skutečné kryptografické schéma, které by vázalo rotaci jednoho klíče na druhý. Existuje návrh vývojáře fiatjaf na základní schéma, které by tento problém mohlo potenciálně vyřešit. Základní myšlenka by spočívala v tom, že by se vzala dlouhá sada adres odvozených z jednoho hlavního seedu a vytvořila by se sada „vylepšených“ klíčů podobně, jako se stromy Taproot zavazují ke klíči Bitcoin. Taproot vezme kořen Merkleova stromu Taproot a „přidá“ ho k veřejnému klíči, čímž vytvoří nový veřejný klíč. To lze replikovat přidáním tohoto kořene Merkleova stromu k soukromému klíči, aby se dosáhlo odpovídajícího soukromého klíče pro nový veřejný klíč. Fiatjafova myšlenka spočívá v řetězení závazků směrem zpět od konce k začátku, takže každý vylepšený klíč by skutečně obsahoval důkaz, že k jeho vytvoření byl použit další vylepšený klíč.
Představte si tedy, že začínáte klíčem Z, posledním v řetězci. Ten byste něčím vylepšili a pak byste se vrátili zpět a vytvořili vylepšenou verzi klíče Y pomocí vylepšeného klíče Z (Z‘ + Y = Y‘). Odtud byste vzali klávesu Y‘ a pak ji použili k úpravě klávesy X (Y‘ + X = X‘). Takto byste se vrátili až ke klávese A, abyste získali A‘, a odtud byste začali používat tuto klávesu. Když je ohrožena, může uživatel vysílat událost obsahující neovlivněnou klávesu A a ovlivněnou klávesu B‘. Ta by obsahovala všechna data potřebná k prokázání, že ke generování klíče A‘ byl použit klíč B‘, a uživatelé by mohli okamžitě přestat sledovat klíč A‘ a místo něj sledovat klíč B‘. S konečnou platností by věděli, že B‘ je dalším klíčem daného uživatele a že jej mají sledovat místo něj.
Tento návrh má však stále několik problémů. Zaprvé je třeba vygenerovat všechny klíče, které by se kdy použily, předem a nemá možnost rotovat na celou novou sadu klíčů. To by se dalo vyřešit tím, že by se v tomto schématu zavázal hlavní klíč, který by mohl takové rotace notářsky ověřit, nebo by se prostě od začátku vygenerovala velmi velká sada klíčů. Obě cesty by byly správné, ale v konečném důsledku by vyžadovaly udržování kořenového klíče nebo materiálu klíčů v bezpečí a vystavení jednotlivých klávesových zkratek pouze klientům Nostr.
Toto schéma však nijak nechrání uživatele ani nenabízí mechanismus pro obnovení identity v případě ztráty kořenového klíčového materiálu nebo jeho kompromitace. Tím nechci říci, že by fiatjafovo schéma nemělo žádný přínos, ten rozhodně má, ale je důležité zdůraznit, že žádné řešení neřeší všechny problémy.
Abychom zde trochu zamysleli nad možnými řešeními, představme si, že místo řetězce vylepšených klíčů, jak navrhuje on, se klíč vylepšuje pomocí hlavního studeného klíče, který musí být také použit k podpisu události rotující z jednoho klíče na druhý. Máte klíč A‘, který vznikne sečtením A a M (hlavního klíče), a událost rotace by byla A, M a B‘ (vzniklá sečtením B a M) s podpisem od M. M by mohl být multisig prahovým klíčem – dva ze tří, tři z pěti atd. To by mohlo potenciálně zvýšit redundanci proti ztrátě a také poskytnout bezpečný mechanismus pro rotaci klíčů. To také otevírá dveře k využití služeb pro pomoc při obnově nebo k šíření některých z těchto klíčů mezi důvěryhodnými přáteli. Nabízí to stejnou flexibilitu jako multisig u samotného Bitcoinu.
NIP26 je také návrh, který by mohl být při řešení tohoto problému velmi užitečný. Ten specifikuje rozšíření protokolu pro události umožňující podpisem z jednoho klíče autorizovat jiný klíč k odesílání událostí jeho jménem. „Token“ nebo podpisový důkaz o pověření by pak byl zahrnut do všech událostí, které druhý veřejný klíč zveřejňuje jménem prvního klíče. Může být dokonce časově omezen, takže platnost delegačních tokenů automaticky vyprší a je třeba je obnovit.
Nakonec, ať už bude tento problém vyřešen jakkoli, musíbýt pro Nostr dlouhodobě vyřešen. Protokol založený výhradně na párech veřejných a soukromých klíčů, které se používají jako identity, nemůže získat popularitu a přijetí, pokud nelze chránit a udržovat integritu těchto identit pro uživatele. To se nakonec zvrhne v nutnost neustále používat mimopásmové a centralizované platformy k ověřování nových klíčů a koordinaci lidí, kteří sledují vaši novou identitu, když se něco ztratí nebo je kompromitováno, a v tu chvíli se tyto další platformy stanou prostředkem k rozsévání zmatku a zapojení do cenzury.
Otázky správy klíčů a zabezpečení jsou velkými problémy s velmi rozsáhlým prostorem pro návrh plným kompromisů a bolestivých bodů, ale jsou to problémy, které bude nutné vyřešit v rámci Nostru, aby fungoval. V příštím článku shrnu některé problémy, které se podle mého názoru objevují v souvislosti s architekturou relay serveru a problémy se škálováním, kterým budou muset vývojáři Nostr čelit vzhledem k základním datovým strukturám, na nichž je Nostr postaven.
Pro všechny, kteří čtou a diví se, proč jsem se nezmínil o decentralizovaných identifikátorech (DID): Ano, to je potenciální řešení těchto problémů, které je podle mého názoru poměrně komplexní. Zdá se však, že vývojáři Nostr velmi váhají s integrací DID do protokolu nebo klientů kvůli tomu, že by to vytvořilo externí závislosti mimo protokol Nostr. Pokud nejste obeznámeni s tím, jak DIDy fungují na technické úrovni, a zajímá vás to, tento článek od Level 39 je velmi dobře napsaným shrnutím toho, jak fungují.
Tento příspěvek napsal jako host Shinobi. Vyjádřené názory jsou výhradně jeho vlastní a nemusí nutně odrážet názory společnosti BTC Inc nebo časopisu Bitcoin Magazine.
