182 / 736FROST

FROST

Jeden podpis, o kterém musí rozhodnout více lidí

Anna, Jan a Eva chtějí spravovat společné prostředky tak, aby je nikdo nemohl poslat sám. FROST umožňuje nastavit potřebnou spolupráci a z jejich dílčích výpočtů vytvořit jeden podpis. Celý tajný klíč se při podepisování nemusí sejít na jednom zařízení.

FROST je protokol pro prahové Schnorrovy podpisy, tedy digitální podpisy vytvářené společně. Prahový znamená, že k podpisu musí spolupracovat alespoň stanovený počet držitelů odlišných podílů společného tajného klíče. Tajný klíč je číslo potřebné k vytvoření podpisu; zde se místo něj při podepisování používají jednotlivé podíly. Výsledek lze ověřit jediným skupinovým veřejným klíčem, který lze sdílet a který sám podepsání neumožňuje. Název zkracuje Flexible Round-Optimized Schnorr Threshold; nejde o peněženku ani o nový druh bitcoinu.

Představme si spolek, jehož úspory spravují Anna, Jan a Eva. Zvolí pravidlo 2 ze 3: platbu mohou schválit Anna s Janem, Anna s Evou nebo Jan s Evou. Každý drží jiný tajný podíl, tedy kryptograficky vytvořenou část společného klíčového materiálu. Jeden podíl nestačí, nejde však ani o tři kopie stejného hesla. Když je Eva nedostupná, zbývající dvojice může spolupracovat. Tatáž hranice platí pro útočníka: získá-li dostatečný počet podílů, může podepsat také. Rozdělení má proto smysl jen tehdy, když napadení jednoho zařízení nebo účtu neotevře cestu ke všem ostatním. [1] [2]

Anna by neměla potvrdit operaci jen proto, že jí aplikace oznámila čekající podpis. Potřebuje vědět, komu prostředky odejdou, kolik, s jakým poplatkem a zda se případný zbytek vrací spolku. Každý podepisující musí mít důvěryhodný způsob, jak skutečnou transakci ověřit. Hash, krátký kryptografický otisk dat, sám člověku její obsah nevysvětlí. FROST umožňuje spolupráci nad stejnou zprávou; neposoudí, zda je faktura pravá nebo zda člověk pochopil, co schvaluje. Ani dokončený podpis ještě není potvrzením platby v bloku. Blok je skupina transakcí zapsaná do společné historie bitcoinové sítě. RFC 9591 je informační specifikace protokolu, nikoli osvědčení bezpečnosti celé aplikace. [1] [2]

Taproot je vylepšení Bitcoinu, které umožňuje utratit prostředky buď podpisem příslušného klíče, nebo splněním předem určených podmínek. Vhodně sestavený prahový podpis může při utracení pomocí klíče v Taproot vypadat jako běžný podpis jedním klíčem. Ze samotného podpisu pozorovatel nevyčte interní počet podílů ani potřebný práh. To je užitečné pro soukromí a velikost podpisových dat, nezaručuje to však anonymitu celé transakce nebo komunikace mezi účastníky. Bitcoin vyžaduje přesná pravidla BIP 340; obecný FROST na křivce secp256k1, matematickém základu výpočtů s bitcoinovými klíči, nestačí. Zcash Foundation (ZF) proto nabízí zvlášť frost-secp256k1-tr pro Taproot. Je třeba správně vyřešit i úpravy klíče, které Taproot používá. Shodný název křivky není důkazem kompatibility a existence knihovny neznamená podporu v každé peněžence. [3] [4]

Než spolek cokoli podepíše, musí podíly bezpečně vytvořit. Důvěryhodný distributor může vytvořit celý klíč a rozdělit jej. Tím ale vzniká citlivý okamžik: distributor celý klíč zná a ponechaná kopie by umožnila obejít zamýšlené společné schvalování. Druhou cestou je DKG, společné vytváření klíče, při kterém se celý tajný klíč nemusí objevit u jediného účastníka. Vyžaduje ověřenou a chráněnou komunikaci i správné provedení protokolu. Nestačí pouze poslat několik souborů e-mailem. RFC 9591 se soustředí na podepisování; automaticky neslibuje DKG v každém produktu. Podíl dlouhodobého klíče navíc není totéž co část podpisu jedné konkrétní platby. [1] [2]

Samotné podepisování probíhá ve dvou kolech, do nichž se nezapočítává předchozí tvorba klíče. Nejdříve každý vybraný účastník vytvoří dvě tajné jednorázové hodnoty nonce a předá jejich veřejné závazky, tedy hodnoty, které jej k těmto nonce kryptograficky vážou. Potom dostane společnou zprávu a seznam závazků, ověří podklady a vypočte svou část podpisu. Koordinátor tyto části spojí. Takzvané vazební faktory propojují výpočty s konkrétní zprávou, skupinovým veřejným klíčem a závazky. U pravidla 2 ze 3 lze začít se dvěma účastníky. Vyberou-li se však pro konkrétní relaci všichni tři, musejí v ní svůj příspěvek dodat všichni; nestačí jednoduše vynechat toho, kdo se odmlčel. [1] [3]

Nonce je zde tajná hodnota určená pro jediný podpisový pokus, nikoli heslo, které lze používat stále dokola. Její opakované použití může odhalit tajný klíčový materiál. Pokud Janův počítač po odeslání části podpisu spadne, nesmí obnova starého stavu označit již použité nonce za nové. Ani nedokončená platba neopravňuje k jejich opětovnému použití. Bezpečná implementace musí zajistit kvalitní náhodnost, oddělení souběžných pokusů a spolehlivé vyřazování spotřebovaných hodnot. To je jeden z důvodů, proč FROST není vhodné sestavovat svépomocí z náhodných skriptů. Správná matematika sama neochrání chybnou správu tajných dat. [1]

Koordinátor organizuje zprávy, ale samotná tato role mu nedává možnost podepsat za spolek. Potřebuje příspěvky vybraných držitelů podílů. Může však komunikaci zadržet nebo relaci přerušit, stejně jako ji může zmařit vadný příspěvek účastníka. Kontroly umožňují odhalit neplatnou část podpisu; k přiřazení chyby konkrétnímu člověku je nutné důvěryhodně znát původ zpráv. Odhalení chyby ještě nezajistí dokončení. Nový pokus potřebuje dostupnou oprávněnou skupinu a čerstvé nonce. Spolek tedy potřebuje i postup pro výpadek a neshodu, ne jen údaj o prahu na úvodní obrazovce. [1] [2]

Když Eva ztratí zařízení, samotný nápis FROST jí prostředky neobnoví. Záloha musí zachovat její podíl, identifikátor, potřebné skupinové údaje a možnost načíst je v kompatibilním programu. Není to automaticky běžná Seed Phrase, tedy slovní záloha peněženky. Pomoc ostatních při obnově podílu a obměna podílů jsou další postupy, které konkrétní systém musí podporovat. Kopie Evina podílu zůstává stejným podílem, nepřidává nezávislého hlasujícího. Ani obměna se stejným skupinovým klíčem nezneškodní dostatečnou sadu dříve ukradených podílů. Před použitím skutečných úspor proto patří do zkoušky také obnova, výpadek a ověření přesné verze softwaru, nikoli pouze jeden úspěšný podpis. [2] [3]

Pro nejúplnější obraz čtěte toto heslo společně s Schnorr Signature, MuSig2, Multisig, Taproot, Shamir Secret Sharing, Bitcoin.

DOC · 001RFC 9591 — FROSTSpecifikace DOC · 002ZF FROST Book — key generation and recoveryPrimární zdroj DOC · 003ZF frost-secp256k1-tr — Taproot implementationPrimární zdroj DOC · 004BIP 340 — Schnorr Signatures for secp256k1Specifikace
Revidováno: Primární zdroje · Nejde o investiční doporučení