Jak jsme se bránili dvěma útokům na kryptografii, která je základem tBTC – rychle, tiše a bez dramatu.
TL; DR:
Nedávno byly veřejně odhaleny dva útoky proti protokolu GG18 a mnoha implementacím – BitForge od týmu Fireblocks a TSShock od Verichains.
tBTC zůstává v bezpečí.
Jsme rádi, že můžeme oznámit, že díky zodpovědnému odhalení od Fireblocks a defenzivnímu kódování ze strany našeho vývojového týmu byly obě zranitelnosti v tBTC zmírněny od června, měsíce před jinými projekty v celém prostoru, a dlouho před zveřejněním. V rámci této zkušenosti jsme se rozhodli dodávat a udržovat alternativu k Binance
tss-lib
.
Zveřejnění BitForge
10. května 2023 jsme obdrželi zprávu o zranitelnosti z druhé ruky od přátelského bezpečnostního výzkumníka. Zpráva o zranitelnosti údajně pocházela od týmu Fireblocks, a zatímco jsme je požádali o potvrzení, její pravost byla ověřena Danem Bonehem na A16z.
Fireblocks report 2023 05 10 fireblocks-report-2023-05-10.pdf 154 KB download-circle Understanding the Report
Abyste pochopili, jak může BitForge ovlivnit tBTC, pomůže vám porozumět tBTC.
tBTC je decentralizovaný bitcoinový most, který se při správě bitcoinů spoléhá na náhodně vybrané klientské operátory. Aby to operátoři mohli dělat, musí být schopni vytvářet sdílené bitcoinové peněženky a podepisovat bitcoinové transakce. K vytvoření podpisu musí mít tato skupina konsensus 51 ze 100.
Matematika vytváření podpisů, aniž by se kterýkoli člen učil, jak podepisovat jménem celé skupiny, je složitá. Schéma používané při výrobě v tBTC dnes je popsáno v GG18 a implementace, kterou hlavní klient používá, je Binance
tss-lib
.
Mezi další stavební bloky patří GG18 (a
tss-lib
) používá pro své homomorfní vlastnosti kryptosystém Paillier[1]. Při nastavování kryptosystému Paillier si každý účastník vygeneruje dvě velká prvočísla (p, q) jako svůj soukromý klíč a poté N = p • q jako svůj veřejný klíč.[2]
Zranitelnost BitForge se točí kolem toho, co se stane, když je podepisovatel se zlými úmysly schopen použít modul
N = small_prime_1 • small_prime_2 • ... • small_prime_16 • q
a nikdo z ostatních účastníků nekontroluje.
V tBTC by úspěšné zneužití zranitelnosti BitForge mohlo exfiltrovat klíčový materiál, což by vedlo ke ztrátě finančních prostředků. K tomu by byl nutný útok
Úspěšný útok typu man-in-the-middle proti komunikaci signatáře – nepravděpodobný, vezmeme-li v úvahu naši zesílenou síťovou vrstvu.
Stávající, zlomyslný T staker se znalostí zranitelnosti a dostatečným T vsazeným, aby mohl být vybrán pro peněženku.
Okamžité zmírnění
Nyní, když jsme pochopili zranitelnost, mohli jsme okamžitě podniknout dvě akce, abychom hrozbu zmírnili.
Nejprve jsme pozastavili tlukot srdce peněženky. tBTC se spoléhá na pravidelné podpisy z peněženek (tlukot srdce) k prokázání živosti podepisujících. Protože BitForge cílí na podpisový protokol a protože tBTC v květnu ještě nepodporoval zpětné odkupy, deaktivace prezenčního signálu znamenalo, že zranitelnost nemohla být dále zneužita, a to ani podepisovatelem se zlými úmysly, který již byl přiřazen k peněžence BTC.
Za druhé, spolupracovali jsme s vedením na deaktivaci vytváření nových peněženek. Vzhledem k tomu, že tBTC v2 byl spuštěn s omezením beta stakerů, věděli jsme, že šance na nebezpečného signatáře je nízká. Přesto tento krok dále zajistil, že nový signatář se znalostí zranitelnosti nemůže vklouznout do nové peněženky.
Obě tato opatření byla provedena 11. května 2023. Bez podpisů nebo DKG nejsou žádné cesty kódu v
tss-lib
lze spustit na mainnetu. V tomto okamžiku, méně než 24 hodin po reakci na incident, jsme měli to, v co mohl každý bezpečnostní technik doufat v aktivní zmírnění zranitelnosti – čas.
Zvažovali jsme dva plány útoku.
"Velký"
První zvažovaný plán zmírnění jsme nazvali „Velký“. Jak název napovídá, zahrnovala drastická opatření.
Nejprve bychom museli implementovat alternativu k
tss-lib
a GG18, které netrpěly zranitelností BitForge. Již jsme plánovali dodat podporu pro podpisy Schnorr jako vylepšení výkonu.
Pokud podpisy Schnorr neznáte, považujte je za hlavní upgrade podpisového schématu ECDSA, které se dnes široce používá napříč bitcoiny a Ethereem. Signatury Schnorr výrazně zjednodušují konstrukce prahů bez dalších předpokladů signatur BLS... ale co je nejdůležitější, jsou dnes podporovány na bitcoinu!
Toto přidání by znamenalo velkou aktualizaci verze
udržovat jádro
P2P klient napájející tBTC — obtížné potichu. Naštěstí už to bylo na naší cestovní mapě, takže jeho odeslání nevzbudí podezření na nezveřejněnou zranitelnost.
Poslední krok v tomto plánu by vyžadoval rotaci všech BTC peněženek v systému: proveditelné, ale pomalé, vyžadující koordinační úsilí v rámci celé komunity.
"Patching the Paillier"
Druhý plán zmírnění, nazvaný „Patching the Paillier“, by se pokusil problém vyřešit na místě.
Nejprve bychom dodali opravu na straně klienta, abychom zabránili náhodně generovaným malým prvočíslům. I když by to nebránilo proti zlomyslně postavenému klientovi, vyhnulo by se tomu
Pak bychom dodali úplné zmírnění proti BitForge s použitím důkazů Paillier ZK „bez malého faktoru“, které se nacházejí v protokolu CGGMP21 prahové ECDSA.
Po diskusi bylo jasné, že tento plán byl konzervativnější volbou; a ukázalo se, že většinu požadovaných důkazů jsme již implementovali v dřívějším výzkumném úsilí.
Začali jsme implementovat nátisky ZK pro vydání soukromého klienta.
Prokázání poctivosti operátora
Při implementaci úplné opravy jsme se také rozhodli potvrdit naše dosavadní zjištění.
Věděli jsme, že žádný nový operátor nemůže zaútočit na tBTC... ale co stávající operátoři? Pokud by podrobnosti o zranitelnosti BitForge unikly, mohli by operátoři ohrozit finanční prostředky?
V době zveřejnění měl tBTC 4 peněženky, z nichž každá měla 100 členů. Kdybychom dokázali, že při generování těchto peněženek nebyly použity žádné malé faktory, mimo rozumnou pochybnost bychom se mohli vyhnout rotujícím peněženkám a být si mnohem jistější v bezpečnost systému.
Každý člen každé peněženky má Paillierův modul. Použili jsme hrubou sílu.
Původní zveřejnění nebylo konkrétní o tom, jak útok fungoval, ale napsal:
Původ zranitelnosti je v tom, že strany nezkontrolují, zda Paillierův modul, označený N, má malé faktory (prvočíslo o velikosti menší než 2 100 je považováno za malé) nebo zda se jedná o dvouprvkový modul (takže je součinem přesně dvě prvočísla)
Nejhůře detekovatelná verze útoku relevantní pro tBTC je ta, kde útočník použije malý faktor v řádu 2100 a další v řádu 21948. Čím více faktorů modul má, tím snazší je jeho zohlednění. Čím menší je kterýkoli faktor, tím snazší je jej zohlednit. Připravili jsme se na nejhorší a doufali v to nejlepší!
Nejprve jsme vytvořili sadu škodlivých klíčů. K tomu je dobrá knihovna python libnum:
import libnum bitů = 100 total_bits = 2048 q = libnum.generate_prime(bits) p = libnum.generate_prime(total_bits - bits) N = p * q print(p, q, N)
To vytváří náhodně generované 2048bitové moduly s jedním malým faktorem (~2^100) a jedním velkým faktorem (~2^1948).
Poté jsme pomocí sympy.ntheory.factorint porovnali, jak dlouho trvá jejich faktorizace:
import time from sympy.ntheory import factorint start = time.time() faktory = factorint(N) end = time.time() print(factors, str(end - start))
Všechny testy zohledněny! Zde jsou statistiky:
N. 64 min 4016,88 q1 35906,3 medián 65896,9 q3 123775 max 453262 průměr 105729 stddev 107148 stderr 13393,6
Do 12. května 2023, dva dny po našem aktivním zmírňování, jsme potvrdili, že pomocí našich notebooků nejsou žádná prvočísla pod 50 bitů... a připravili jsme se na delší faktoringový proces v cloudu.
Poté jsme vytvořili 8x48jádrové digitální oceánské kapky optimalizované pro CPU a 1x16jádro, celkem tedy 400 jader.
faktorint
běží jednovláknově (a je nejrychlejší z factoringových knihoven, které jsme našli); každé krabici bylo přiděleno jedno číslo k faktoru na jádro.
import sys ze sympy.ntheory import factorint import time import json N = int(sys.argv[1], 16) start = time.time() factor = factorint(N) end = time.time() file = open(f '{sys.argv[2]}.txt', "w") file.writelines([json.dumps(factors), "\n", str(end - start)]) file.close()
Rozdělili jsme moduly mezi stroje a poté začali faktoring.
python3 factor.py <moduli1> 1 & disown python3 factor.py <moduli2> 2 & disown ... python3 factor.py <moduli48> 48 & disown
Dvakrát jsme zkontrolovali, že na každém počítači máme 48 jader běžících na 100 % a pak jsme se pravidelně kontrolovali, abychom se ujistili, že nic nespadne.
Stroje jsme provozovali od 2023-05-15T16:01Z do 2023-05-22T19:21Z, což je 7 dní, 3 hodiny, 20 minut nebo celkem 616 800 sekund. Žádné ze 400 vláken nenalezlo žádné faktory.
To je ~4,8 standardní odchylky nad průměrem a o 36 % delší než nejdelší pokus o faktoring, který jsme viděli, což nám dává jistotu, že jsme se pokoušeli o faktoring dostatečně dlouho.
Aby byl přítomen malý faktor, útočník musí mít:
Útok objevili mnohem dříve, než bezpečnostní výzkumníci.
Upravil klienta před vytvořením peněženky. Nejnovější peněženka byla zaregistrována 2023-04-19.
Nějak se vyhnuli tomu, aby jejich malý faktor detekoval výše uvedený algoritmus.
S tím vším dohromady jsme věděli, že žádný z klíčů není ohrožen tímto potenciálním útokem.
Plná záplata
Dokument CGGMP21 také používá kryptosystém Paillier. Rozdíl je v tom, že během generování klíčů protokol přiměje každého účastníka prokázat to s nulovou znalostí
Jejich modul neobsahuje žádné malé faktory. p66.
Jejich modul je Paillier-Blumův modul. p36.
Jejich parametry Ring-Pedersen jsou dobře tvarované. p37.
Do 16. května 2023 jsme měli prototyp všech nátisků a zahájili interní kontrolu.
5. června jsme vytvořili privátní fork a poté tiše postavili + odeslali klientský binární soubor pomocí soukromé, vlastní verze
tss-lib
provést výše uvedené důkazy.
Protože jsme již plánovali hlavní klientskou verzi, která by umožnila novou, rozsáhlou funkci, mohli jsme v tichosti zahrnout opravu – aniž bychom odhalili zranitelnost nebo upozornili případné hackery.
6. června začala Trail of Bits ověřovat náš patch a 7. června jsme opravili všechny nálezy. [3]
Thesis tss-lib BitForge Remediation Summary Report Thesis tss-lib BitForge Remediation Summary Report.pdf 772 KB download-circle TSShock Disclosure
14. července jsme obdrželi další zprávu o kritickém problému, tentokrát od týmu Verichains prostřednictvím ImmuneFi. Nejvíce znepokojivé bylo, že tým zahrnoval důkaz o konceptu, o kterém tvrdili, že prokázal klíčovou exfiltraci z
udržovat jádro
klienta.
Když jsme se však dokopali, zjistili jsme, že PoC týmu Verichains bylo založeno na starší verzi klienta,
v2.0.0-m3
— nikoli beta verzi beta pro soukromého klienta, kterou používali uživatelé.
Do 18. července jsme potvrdili, že soukromě opravený klient z BitForge mitigation také zajistil tBTC proti nové zranitelnosti, nazvané TSShock, a že útok nebyl možný na mainnetu.
Jak? Při práci na zmírnění BitForge jsme objevili problém s kolizí hašování za TSShock, který byl již veřejně opraven, a vtáhli jsme jej do soukromě opraveného klienta. Ocenili jsme zveřejnění od Verichains a jsme spokojeni s výsledkem.
Jídlo s sebou
Odpovědné odhalení je obtížné
Jako vždy je jednou z nejobtížnějších částí zodpovědného odhalení často nalezení správné osoby, se kterou si můžete promluvit.
V posledních několika dnech jsem pracoval se skupinou whitehatů, auditorů a dalších bezpečnostních vůdců, abych se pokusil vyřešit nejtěžší část zodpovědného odhalení: najít tu správnou osobu, se kterou bych mohl mluvit. pic.twitter.com/pPjt7D51ZE
— @samczsun.com (@samczsun) 7. srpna 2023
Zde jsme měli štěstí, že jsme získali informace o BitForge tak brzy – bylo zapojeno několik zprostředkovatelů, než jsme byli v kontaktu s týmem Fireblocks.
Není jasné, jak bychom to tady mohli udělat lépe... příslušná úložiště mají zveřejněný proces zveřejňování, máme bounty program ImmuneFi, rychle odpovídáme na e-maily prostřednictvím
security@threshold.network
a řídíme se standardem security.txt.
Na druhou stranu jsme měli několik problémů, které ověřovaly, že problém, kterým ThorChain 16. srpna trpěl, byl ve skutečnosti TSShock – a ne nová zranitelnost. Nepodařilo se mi to potvrdit, přestože jsem se obrátil na Twitter, prostřednictvím sdílených kontaktů v telegramu atd.
Musíme najít lepší způsob koordinace napříč průmyslem, zejména mezi projekty s kritickými sdílenými závislostmi, jako je např
tss-lib
.
Kde je kouř, tam je oheň.
Binance
tss-lib
má v průběhu let řadu problémů. Není často aktualizován, testovací pokrytí není skvělé a většina vylepšení kódu za posledních několik let byla reakcí na zveřejnění.
Víme to, protože sami patříme k těm častějším přispěvatelům.
Po BitForge a TSShocku už si v upstreamu nevěříme
tss-lib
úložiště, včetně řádného zmírnění těchto problémů.
Místo toho doporučujeme všechny
tss-lib
uživatelé, aby zvážili použití našeho forku, který je nyní open source.
Budoucí práce
Kromě problémů s
tss-lib
... rodina prahových protokolů GG18 měla v průběhu let také řadu zranitelností. A zatímco veškerá kryptografie musí obstát ve zkoušce času, kde je kouř, tam je často oheň – a pokud se můžeme vyhnout riziku, měli bychom.
Mnoho projektů vyžaduje prahovou hodnotu ECDSA a pro ty doporučujeme upgrade na CGGMP21.
Naštěstí máme silnější alternativu. Od 14. listopadu 2021 Bitcoin aktivoval nové podpisové schéma — Schnorr. Od dubna je naším plánem migrace tBTC na signatury Schnorr pomocí ROAST/FROST a GJKR (RFC 10), abychom se vyhnuli složitosti implementace prahových ECDSA. Tým souhlasil s tím, že doporučí, aby byl program beta staker ponechán na místě, dokud neproběhne migrace na Schnorr.
Očekávejte, že o tomto úsilí uslyšíte později v tomto roce!
Poděkování
Softwarová bezpečnost je velký úkol a zmírnění těchto zranitelností záviselo na řadě lidí.
Chtěli bychom poděkovat...
Ari a týmu ve Fireblocks za jejich zjištění.
MacLane Wilkisonovi, Tuxovi a Danu Bonehovi za jejich pomoc s ověřením odhalení.
Promethea Rashke za její práci na portování korektur z CGGMP21 do tss-lib, Beau Rancourt za jeho práci s faktorováním existujících modulů Paillier a Jakub Nowakowski, Piotr Dyraga a Lukasz Zimnoc za jejich práci na koordinaci naší reakce a kontrole veškerého kódu.
Tjadenu Hessovi a Trail of Bits za jejich pomoc a zpětnou vazbu ověřující naše zmírnění.
Threshold DAO za jejich neuvěřitelnou odezvu.
Časová osa
Pro zájemce je zde podrobnější časový harmonogram. Všimněte si, že všechny časy jsou UTC.
2023-05-10 21:19: Získejte původní oznámení o zranitelnosti.
2023-05-10 21:53: Distribuce práce: Kuba stáhne stávající moduly Paillier, abychom mohli zkontrolovat, jak je začít faktorizovat. Promethea začíná opravovat tss-lib. Beau začíná psát faktoringový kód a benchmarky. Piotr připravuje transakci pro správu tBTC, aby pozastavila vytváření nové peněženky.
2023-05-11 00:06: Kuba extrahuje a sdílí stávajících 400 modulů.
2023-05-11 13:08: Piotr předává transakci, aby pozastavil vytváření nové peněženky před správou.
2023-05-11 19:45: Promethea implementuje hrubý návrh nezbytných důkazů v soukromém forku tss-lib.
2023-05-12 16:35: Beau úspěšně vygeneruje správně dimenzovaný biprim a začne se ho snažit zohlednit.
2023-05-12 19:15: Beau používá snáze faktorovatelné bi-primes k porovnání různých factoringových knihoven a získání přehledu o tom, jak se výkon škáluje. primefac funguje nejlépe.
2023-05-15 12:12 PM: tBTC governance deaktivuje novou generaci peněženky.
2023-05-15 16:36: Beau začíná faktorizovat všech 400 modulů pomocí digitálních oceánských kapiček optimalizovaných pro CPU.
2023-05-17 14:49: Promethea upravuje patch tss-lib tak, aby byl plně zpětně kompatibilní s klienty keep.
2023-05-19 13:58: Promethea identifikuje potenciální hašovací kolize a přidá opravu.
22.05.2023 19:21: Beau vypíná faktoringové stroje. Nebyly nalezeny žádné faktory.
2023-05-25 17:01: Piotr naplánuje audit Trail of Bits kvůli změnám a vytvoří nový bezpečnostní rozvětvení tss-lib pro usnadnění auditu.
2023-06-05 14:25: Piotr tiše vkládá změny do keep-core verze v2.0.0-m3.
2023-06-06 21:42: tjade273 (Trail of Bits Auditor) dokončil svůj první průchod bezpečnostní opravy tss-lib.
2023-06-07 14:51: Promethea identifikuje, že Ntilde (jiný modul Paillier) je také zranitelný a že opravu je třeba použít také na protokol opětovného sdílení (nepoužíváme opětovné sdílení; stejně jsme to opravili).
2023-06-13 14:34: Promethea dokončuje opětovné sdílení a opravu Ntilde.
2023-07-14 10:11: Zjistěte přes ImmuneFi, že společnost Verichains našla exploit zahrnující hašovací kolize, které Promethea již opravil.
2023-07-18 15:04: Kuba potvrzuje, že PoC Verichains nemá vliv na soukromě opraveného klienta pro udržení jádra.
2023-07-20 11:34 AM: Odešlete keep-core v2.0.0-m4, který zahrnuje opravu ntilde a opětovného sdílení.
29. 6. 2023 22:49: tjade273 dokončuje audit sdílení a opravy Ntilde.
2023-08-16 13:46: Jiný projekt tweetuje o nové zranitelnosti (je to ta samá). Zveřejňování tohoto oznámení pozastavujeme, abychom prošetřili.
[1]: Homomorfní šifrovací schéma je schéma, kde můžete provádět matematické výpočty se zašifrovaným textem a správně jej později dešifrovat. pro Paillier,
dešifrovat(zašifrovat(zpráva1) • zašifrovat(zpráva2)) == zpráva1 + zpráva2
.
[2]: Je výpočetně snadné to ověřit
N = p • q
ale obtížné zjistit, jaké p a q jsou dány právě N. Viz faktorizace celých čísel. Největší takto faktorované číslo bylo RSA-250, číslo s 250 desetinnými číslicemi, v roce 2020. Celková doba výpočtu byla zhruba 2700 jádrových let výpočetní techniky.
[3]: Komentáře k přezkumu stažení byly ztraceny, když bylo sloučeno zveřejnění zabezpečení. Na jejich obnovení pracujeme s GitHubem. Mezitím je zde snímek obrazovky:
A zde je shrnutí nápravy, které sestavil Trail of Bits.
Dodatek
Škodlivé N pro srovnávání
https://gist.github.com/beaurancourt/c26f437baa62ebda45d069998273b053
Srovnávací výsledky
Měřeno v sekundách, v pořadí podle indexu.
Zranitelnost Benchmark Timing Results Výsledky měření zranitelnosti Benchmark. GitHub Gist: okamžitě sdílejte kód, poznámky a úryvky. 
Hlavní číslo 262588213843476 