BitForge și TSShock

Cum ne-am apărat împotriva a două atacuri asupra criptografiei care stau la baza tBTC - rapid, liniștit și fără dramatism.
TL;DR:
Recent, două atacuri împotriva protocolului GG18 și multe implementări au fost dezvăluite public - BitForge, de către echipa Fireblocks, și TSShock, de către Verichains.
tBTC rămâne în siguranță.
Suntem bucuroși să raportăm că, datorită unei dezvăluiri responsabile din partea Fireblocks și a codificării defensive din partea echipei noastre de dezvoltare, ambele vulnerabilități au fost atenuate în tBTC din iunie, cu luni înainte de alte proiecte din spațiu și cu mult înainte de dezvăluirea publică. Ca parte a acestei experiențe, am decis să livrăm și să menținem o alternativă la Binance
tss-lib
.
Dezvăluirea BitForge
Pe 10 mai 2023, am primit un raport de vulnerabilitate la mâna a doua de la un cercetător de securitate prietenos. Raportul de vulnerabilitate ar fi provenit de la echipa Fireblocks și, în timp ce i-am contactat pentru confirmare, autenticitatea lui a fost verificată de Dan Boneh la A16z.
 Fireblocks report 2023 05 10 fireblocks-report-2023-05-10.pdf 154 KB download-circle Înțelegerea raportului
Pentru a înțelege modul în care BitForge ar putea afecta tBTC, vă ajută să înțelegeți tBTC.
tBTC este o punte Bitcoin descentralizată care se bazează pe operatori clienți aleși aleatoriu pentru a gestiona bitcoin. Pentru ca operatorii să facă asta, trebuie să poată crea portofele bitcoin partajate și să semneze tranzacții cu bitcoin. Pentru a produce o semnătură, acel grup trebuie să aibă un consens de 51 din 100.
Matematica creării semnăturilor fără ca niciun membru să învețe cum să semneze în numele întregului grup este complexă. Schema folosită în producție în tBTC astăzi este descrisă în GG18, iar implementarea pe care o folosește principalul client este Binance.
tss-lib
.
Printre alte blocuri de construcție, GG18 (și
tss-lib
) folosește criptosistemul Paillier pentru proprietățile sale homomorfe[1]. La configurarea criptosistemului Paillier, fiecare participant generează două numere prime mari (p, q) ca cheie privată și apoi N = p • q ca cheie publică.[2]
Vulnerabilitatea BitForge se învârte în jurul a ceea ce se întâmplă atunci când un semnatar rău intenționat este capabil să utilizeze un modul
N = mic_prim_1 • small_prim_2 • ... • small_prim_16 • q
, și niciunul dintre ceilalți participanți nu verifică.
În tBTC, o exploatare cu succes a vulnerabilității BitForge ar putea exfiltra material cheie, ducând la pierderea de fonduri. Pentru a face asta, ar fi nevoie de un atac
Un atac de succes de tip om-in-the-middle împotriva comunicării semnatarului - puțin probabil, având în vedere stratul nostru de rețea întărit.
Un staker T existent, rău intenționat, care cunoaște vulnerabilitatea și suficient T stake pentru a fi ales pentru un portofel.
Atenuare imediată
Acum că am înțeles vulnerabilitatea, existau două acțiuni pe care le-am putea lua imediat pentru a atenua amenințarea.
Mai întâi, am întrerupt bătăile inimii portofelului. tBTC se bazează pe semnăturile periodice din portofele („bătăi ale inimii”) pentru a dovedi vioitatea semnatarului. Deoarece BitForge vizează protocolul de semnare și pentru că tBTC nu a acceptat încă răscumpărări în mai, dezactivarea bătăilor inimii a însemnat că vulnerabilitatea nu ar putea fi exploatată în continuare, chiar și de către un semnatar rău intenționat deja alocat unui portofel BTC.
În al doilea rând, am lucrat cu guvernanța pentru a dezactiva crearea de portofel noi. Deoarece tBTC v2 a fost lansat cu o restricție beta staker, știam că șansa unui semnatar rău intenționat era scăzută. Totuși, această mișcare a asigurat și mai mult ca un nou semnatar care cunoaște vulnerabilitatea nu se poate strecura într-un nou portofel.
Ambele măsuri au fost executate pe 11 mai 2023. Fără semnături sau DKG, nu există căi de cod în
tss-lib
 ar putea fi declanșat pe rețeaua principală. În acest moment, în mai puțin de 24 de ore până la răspunsul la incident, am avut ceea ce orice inginer de securitate ar putea spera într-o diminuare activă a vulnerabilității: timpul.
Am luat în considerare două planuri de atac.
„Cel mare”
Am numit primul plan de atenuare luat în considerare „The Big One”. După cum sugerează și numele, a inclus măsuri drastice.
În primul rând, ar trebui să implementăm o alternativă la
tss-lib
 și GG18 care nu a suferit de vulnerabilitatea BitForge. Ne-am planificat deja să livrăm asistență pentru semnăturile Schnorr ca o îmbunătățire a performanței.
Dacă nu sunteți familiarizat cu semnăturile Schnorr, gândiți-vă la ele ca la o actualizare majoră a schemei de semnătură ECDSA utilizată pe scară largă în Bitcoin și Ethereum astăzi. Semnăturile Schnorr simplifică foarte mult construcțiile de prag fără presupunerile suplimentare ale semnăturilor BLS... dar, cel mai important, sunt acceptate pe Bitcoin astăzi!
Această adăugare ar însemna o actualizare majoră a versiunii
păstrează-miezul
 Client P2P care alimentează tBTC — un lucru dificil de făcut în liniște. Din fericire, era deja pe foaia noastră de parcurs, așa că expedierea nu ar ridica suspiciunea de o vulnerabilitate nedezvăluită.
Pasul final din acest plan ar necesita rotirea tuturor portofelelor BTC din sistem: realizabil, dar lent, care necesită un efort de coordonare la nivelul întregii comunități.
„Peticirea lui Paillier”
Al doilea plan de atenuare, numit „Patching the Paillier”, ar încerca să rezolve problema în loc.
În primul rând, vom trimite o remediere la nivelul clientului pentru a preveni primele mici generate accidental. Deși acest lucru nu ar apăra împotriva unui client creat cu răutate, ar evita
Apoi, vom trimite o atenuare completă împotriva BitForge, folosind dovezile Paillier ZK „fără un factor mic” găsite în protocolul ECDSA de prag CGGMP21.
După discuție, a fost clar că acest plan era alegerea mai conservatoare; și s-a dovedit că deja implementasem majoritatea dovezilor necesare într-un efort de cercetare anterior.
Am început să implementăm dovezile ZK pentru o versiune de client privat.
Dovedirea onestității operatorului
În timp ce implementăm patch-ul complet, ne-am propus și să confirmăm descoperirile noastre de până acum.
Știam că niciun nou operator nu ar putea ataca tBTC... dar ce rămâne cu operatorii existenți? Dacă s-ar scurge detaliile despre vulnerabilitatea BitForge, ar putea operatorii să pună în pericol fondurile?
La momentul dezvăluirii, tBTC avea 4 portofele, fiecare având 100 de membri. Dacă am putea dovedi că nu au fost folosiți factori minori atunci când au fost generate acele portofele, dincolo de orice îndoială rezonabilă, am putea evita rotația portofelelor și am fi mult mai încrezători în siguranța sistemului.
Fiecare membru al fiecărui portofel are un modul Paillier. Am folosit forța brută.
Dezvăluirea inițială nu era specifică despre modul în care a funcționat atacul, dar scria:
 Originea vulnerabilității este că părțile nu verifică dacă modulul Paillier, notat cu N, are factori mici (un prim de dimensiune mai mic de 2 100 este considerat mic) sau dacă este un biprim (deci este produsul exact de două numere prime)
Versiunea cel mai greu de detectat a atacului relevant pentru tBTC este cea în care un atacator folosește un factor mic de ordinul 2100 și altul de ordinul 21948. Cu cât modulul are mai mulți factori, cu atât este mai ușor să-l factorizeze. Cu cât un factor este mai mic, cu atât este mai ușor să-l factorizezi. Ne-am pregătit pentru ce e mai rău și am sperat la ce este mai bun!
În primul rând, am creat un set de chei rău intenționate. Biblioteca python libnum este bună pentru asta:
import libnum biți = 100 total_bits = 2048 q = libnum.generate_prime(biți) p = libnum.generate_prime(total_bits - biți) N = p * q print(p, q, N)
Acest lucru creează module de 2048 de biți generați aleatoriu cu un factor mic (~2^100) și un factor mare (~2^1948).
Apoi, am evaluat cât de mult durează acestea pentru factorizarea utilizând sympy.ntheory.fatorint:
import timp de la sympy.ntheory import factornt start = time.time() factori = factorint(N) end = time.time() print(factori, str(end - start))
Toate testele sunt luate în considerare! Iată statisticile:
N. 64 min 4016,88 q1 35906,3 mediană 65896,9 q3 123775 max 453262 medie 105729 stddev 107148 stderr 13393,6
Până la 12 mai 2023, la două zile după atenuarea noastră activă, am confirmat că nu existau numere prime sub 50 de biți folosind laptopurile noastre... și ne-am pregătit pentru un proces de factoring mai lung în cloud.
Apoi, am creat picături oceanice digitale optimizate pentru procesor cu 8x48 de nuclee și 1x16 nuclee, pentru un total de 400 de nuclee.
factorint
 rulează cu un singur thread (și este cea mai rapidă dintre bibliotecile de factoring pe care le-am găsit); fiecărei casete i s-a dat un număr de factor pentru fiecare nucleu.
import sys din sympy.ntheory import factornt import time import json N = int(sys.argv[1], 16) start = time.time() factori = factorint(N) end = time.time() fișier = deschis(f) „{sys.argv[2]}.txt”, „w”) file.writelines([json.dumps(factori), „\n”, str(sfârșit - început)]) file.close()
Am distribuit modulele între mașini și apoi am început factorizarea.
python3 factor.py <moduli1> 1 și respinge python3 factor.py <moduli2> 2 și respinge ... python3 factor.py <moduli48> 48 și respinge
Am verificat de două ori că avem 48 de nuclee pe fiecare mașină care rulează la o utilizare de 100%, apoi am verificat periodic pentru a ne asigura că nimic nu s-a blocat.
Am rulat mașinile din 2023-05-15T16:01Z până în 2023-05-22T19:21Z, adică 7 zile, 3 ore, 20 de minute sau 616.800 de secunde în total. Niciunul dintre cele 400 de fire nu a găsit niciun factor.
Aceasta este de aproximativ 4,8 abateri standard peste medie și cu 36% mai mult decât cea mai lungă încercare de factoring pe care am văzut-o, ceea ce ne oferă încredere că am încercat factoring suficient de mult.
Pentru ca un factor mic să fie prezent, atacatorul trebuie să aibă:
A descoperit atacul cu mult înaintea cercetătorilor de securitate.
A modificat clientul înainte de formarea portofelului. Cel mai recent portofel a fost înregistrat pe 2023-04-19.
Cumva au evitat ca factorul lor mic să fie detectat de algoritmul de mai sus.
Cu toate acestea împreună, știam că niciuna dintre chei nu era expusă riscului de acest potențial atac.
Un patch complet
Lucrarea CGGMP21 folosește, de asemenea, criptosistemul Paillier. Diferența este că în timpul generării cheilor, protocolul face ca fiecare participant să demonstreze fără cunoștințe că
Modulul lor nu conține factori mici. p66.
Modulul lor este un modul Paillier-Blum. p36.
Parametrii lor Ring-Pedersen sunt bine formați. p37.
Până pe 16 mai 2023, aveam un prototip al tuturor dovezilor și am început revizuirea internă.
Pe 5 iunie, am creat un furk privat și apoi am construit în liniște + am expediat binarul client folosind o versiune privată, personalizată a
tss-lib
 pentru a efectua dovezile de mai sus.
Deoarece plănuiam deja o lansare majoră a clientului pentru a activa o nouă caracteristică, sweeping, am putut să includem în liniște patch-ul - fără a dezvălui vulnerabilitatea sau a anunța eventualii hackeri.
Pe 6 iunie, Trail of Bits a început să verifice patch-ul nostru, iar pe 7 iunie, am remediat toate constatările. [3]
 Teză tss-lib Raport rezumat remediere BitForge Teză tss-lib Raport rezumat remediere BitForge.pdf 772 KB download-circle TSShock Disclosure
Pe 14 iulie, am primit un alt raport al unei probleme critice, de data aceasta de la echipa Verichains prin ImmuneFi. Cel mai îngrijorător, echipa a inclus o dovadă de concept despre care ei susțin că a demonstrat o exfiltrare a cheilor din
păstrează-nucleul
 client.
Cu toate acestea, pe măsură ce am săpat, am realizat că PoC-ul echipei Verichains se baza pe o versiune mai veche a clientului,
v2.0.0-m3
 — nu versiunea beta pe care o foloseau stakers.
Până pe 18 iulie, am confirmat că clientul corectat privat de la atenuarea BitForge a făcut și tBTC în siguranță împotriva noii vulnerabilități, numită TSShock, și că atacul nu a fost posibil pe rețeaua principală.
Cum? În timp ce lucram la atenuarea BitForge, am descoperit problema coliziunii hashing din spatele TSShock care a fost deja remediată public și am introdus-o în clientul corelat privat. Am apreciat dezvăluirea de la Verichains și suntem mulțumiți de rezultat.
La pachet
Dezvăluirea responsabilă este dificilă
Ca întotdeauna, una dintre cele mai dificile părți ale dezvăluirii responsabile este adesea găsirea persoanei potrivite cu care să discutați.
În ultimele zile, am lucrat cu un grup de pălărie albe, auditori și alți lideri de securitate pentru a încerca să rezolv cea mai grea parte a dezvăluirii responsabile: găsirea persoanei potrivite cu care să vorbesc. pic.twitter.com/pPjt7D51ZE
— @samczsun.com (@samczsun) 7 august 2023
Aici, am fost norocoși că am primit dezvăluirea BitForge atât de devreme – au fost implicați mai mulți intermediari înainte să luăm legătura cu echipa Fireblocks.
Nu este clar cum ne-am fi putut descurca mai bine aici... depozitele relevante au un proces de divulgare publicat, avem un program de recompense ImmuneFi, răspundem rapid la e-mailuri prin
security@threshold.network
și respectăm standardul security.txt.
Pe de altă parte, am avut câteva probleme prin verificarea faptului că problema suferită de ThorChain pe 16 august a fost, de fapt, TSShock - și nu o nouă vulnerabilitate. Nu am putut confirma acest lucru, în ciuda faptului că am contactat pe Twitter, prin contacte Telegram partajate etc.
Trebuie să găsim o modalitate mai bună în industrie de coordonare, în special între proiectele cu dependențe comune critice, cum ar fi
tss-lib
.
Unde e fum, acolo e foc.
Binance
tss-lib
 a avut o serie de probleme de-a lungul anilor. Nu este actualizat frecvent, acoperirea testului nu este grozavă și majoritatea îmbunătățirilor de cod din ultimii ani au fost ca răspuns la dezvăluiri.
Știm, pentru că noi înșine suntem unii dintre cei mai frecventi contribuitori.
După BitForge și TSShock, nu mai avem încredere în upstream
tss-lib
 depozit, inclusiv atenuarea adecvată a acestor probleme.
În schimb, vă recomandăm pe toate
tss-lib
 utilizatorii să ia în considerare utilizarea furcii noastre, care acum este open source.
Munca viitoare
Pe deasupra problemelor cu
tss-lib
... familia GG18 de protocoale de prag a avut, de asemenea, o serie de vulnerabilități de-a lungul anilor. Și, în timp ce toată criptografia trebuie să servească testul timpului, acolo unde este fum, adesea există foc - și dacă putem evita riscul, ar trebui.
Multe proiecte au nevoie de un prag ECDSA, iar pentru acestea, vă recomandăm să faceți upgrade la CGGMP21.
Din fericire, avem o alternativă mai puternică. Din 14 noiembrie 2021, Bitcoin a activat o nouă schemă de semnătură – Schnorr. Din aprilie,  planul nostru a fost de a migra tBTC la semnăturile Schnorr, folosind ROAST/FROST și GJKR (RFC 10) pentru a evita complexitatea implementărilor ECDSA de prag. Echipa a fost de acord să recomande ca programul beta staker să fie lăsat în vigoare până când are loc migrarea către Schnorr.
Așteptați-vă să auziți mai multe despre acest efort mai târziu în acest an!
Mulțumiri
Securitatea software-ului este o treabă mare, iar atenuarea acestor vulnerabilități s-a bazat pe un număr de oameni.
Dorim să mulțumim...
Ari și echipa de la Fireblocks pentru descoperirile lor.
MacLane Wilkison, Tux și Dan Boneh pentru ajutorul lor în verificarea dezvăluirii.
Promethea Rashke pentru munca sa de portare a dovezilor de la CGGMP21 la tss-lib, Beau Rancourt pentru munca sa de factoring a modulelor Paillier existente și Jakub Nowakowski, Piotr Dyraga și Lukasz Zimnoc pentru munca lor de coordonare a răspunsului nostru și de revizuire a întregului cod.
Tjaden Hess și Trail of Bits pentru asistență și feedback care ne verifică atenuarea.
The Threshold DAO pentru capacitatea lor de răspuns incredibilă.
Cronologie
Pentru cei interesați, iată o cronologie mai detaliată. Rețineți că toate orele sunt UTC.
2023-05-10 21:19: Primiți divulgarea inițială a vulnerabilității.
2023-05-10 21:53: Distribuie munca: Kuba preia modulele Paillier existente, astfel încât să putem verifica începerea factorizării acestora. Promethea începe să corecteze tss-lib. Beau începe să scrie cod de factoring și benchmark-uri. Piotr pregătește o tranzacție pentru guvernarea tBTC pentru a întrerupe crearea unui portofel nou.
2023-05-11 00:06: Kuba extrage și partajează cei 400 de module existenți.
2023-05-11 13:08: Piotr predă tranzacția pentru a întrerupe crearea unui portofel nou în sarcina guvernării.
2023-05-11 19:45: Promethea implementează proiectul brut al dovezilor necesare într-un furk privat al tss-lib.
2023-05-12 4:35 PM: Beau generează cu succes un biprime dimensionat corespunzător și începe să încerce să-l factorizeze.
2023-05-12 19:15: Beau folosește bi-prime mai ușor de factorizat pentru a compara diferite biblioteci de factoring și pentru a înțelege cum se scalează performanța. primefac are cele mai bune rezultate.
2023-05-15 12:12: Guvernarea tBTC dezactivează noua generație de portofel.
2023-05-15 16:36: Beau începe să factorizeze toți cei 400 de module folosind picături Digital Ocean optimizate pentru procesor.
2023-05-17 2:49 PM: Promethea ajustează patch-ul tss-lib pentru a fi pe deplin compatibil cu clienții keep.
2023-05-19 13:58: Promethea identifică potențiale coliziuni hash și adaugă o remediere.
2023-05-22 19:21: Beau oprește mașinile de factoring. Nu s-au găsit factori.
2023-05-25 5:01 PM: Piotr programează un audit Trail of Bits pentru modificări și creează o nouă furcă de consiliere de securitate a tss-lib pentru a facilita auditul.
2023-06-05 2:25 PM: Piotr introduce în liniște modificările în lansarea keep-core v2.0.0-m3.
2023-06-06 21:42: tjade273 (Trail of Bits Auditor) își termină prima trecere a patch-ului de securitate tss-lib.
2023-06-07 2:51 PM: Promethea identifică că Ntilde, (un alt modul Paillier) este, de asemenea, vulnerabilă și că remedierea trebuie aplicată și protocolului de redistribuire (nu folosim redistribuirea; am remediat-o oricum).
2023-06-13 2:34 PM: Promethea termină redistribuirea și repare Ntilde.
2023-07-14 10:11: Descoperiți prin ImmuneFi că Verichains a găsit un exploit care implică coliziuni hash pe care Promethea o rezolvase deja.
2023-07-18 15:04: Kuba confirmă că Verichains PoC nu afectează clientul keep-core corelat privat.
2023-07-20 11:34: Trimiteți keep-core v2.0.0-m4 care include remedierea ntilde și redistribuire.
2023-06-29 22:49: tjade273 termină de auditat redistribuirea și remedierea Ntilde.
2023-08-16 13:46: Un alt proiect tweetează despre o nouă vulnerabilitate (este aceeași). Întrerupem publicarea acestei dezvăluiri pentru a investiga.
[1]: O schemă de criptare homomorfă este una în care puteți efectua matematică pe textul criptat și puteți să-l decriptați mai târziu. Pentru Paillier,
decriptare(criptare(mesaj1) • criptare(mesaj2)) == mesaj1 + mesaj2
.
[2]: Este ușor să verificăm acest lucru din punct de vedere computațional
N = p • q
 dar greu de dat seama ce p și q sunt date doar N. Vezi Factorizarea întregului. Cel mai mare astfel de număr factorizat a fost RSA-250, un număr cu 250 de cifre zecimale, în 2020. Timpul total de calcul a fost de aproximativ 2700 de ani-nucleu de calcul.
[3]: comentariile extragerii au fost pierdute când divulgarea de securitate a fost îmbinată. Lucrăm cu GitHub pentru a le restabili. Între timp, iată o captură de ecran:
Și iată rezumatul remedierii elaborat de Trail of Bits.
Apendice
N-uri rău intenționate pentru benchmarking
https://gist.github.com/beaurancourt/c26f437baa62ebda45d069998273b053
Rezultate benchmark
Măsurat în secunde, în ordinea indicelui.
 Vulnerabilitatea Benchmark Timing Results Vulnerability Benchmark Timing Results. GitHub Gist: partajați instantaneu cod, note și fragmente.  Gist 262588213843476 