Bagaimana kami bertahan melawan dua serangan terhadap kriptografi yang mendasari tBTC — dengan cepat, diam-diam, dan tanpa drama.

DIATAS;DR:

Baru-baru ini, dua serangan terhadap protokol GG18 dan banyak implementasinya diungkapkan ke publik — BitForge, oleh tim Fireblocks, dan TSShock, oleh Verichains.

tBTC tetap aman.

Kami dengan senang hati melaporkan bahwa berkat pengungkapan yang bertanggung jawab dari Fireblocks dan pengkodean defensif oleh tim pengembangan kami, kedua kerentanan telah diatasi di tBTC sejak Juni, beberapa bulan sebelum proyek lain di seluruh dunia, dan jauh sebelum pengungkapan publik. Sebagai bagian dari pengalaman ini, kami telah memutuskan untuk mengirimkan dan memelihara alternatif untuk Binance

tss-lib

.

Pengungkapan BitForge

Pada tanggal 10 Mei 2023, kami menerima laporan kerentanan dari seorang peneliti keamanan yang ramah. Laporan kerentanan tersebut konon berasal dari tim Fireblocks, dan saat kami menghubungi mereka untuk konfirmasi, keasliannya diverifikasi oleh Dan Boneh di A16z.

Laporan Fireblocks 2023 05 10 fireblocks-report-2023-05-10.pdf 154 KB download-circle Memahami Laporan

Untuk memahami bagaimana BitForge dapat memengaruhi tBTC, ada baiknya kita memahami tBTC.

tBTC adalah jembatan Bitcoin terdesentralisasi yang mengandalkan operator klien yang dipilih secara acak untuk mengelola bitcoin. Agar operator dapat melakukannya, mereka harus dapat membuat dompet bitcoin bersama, dan menandatangani transaksi bitcoin. Untuk menghasilkan tanda tangan, kelompok tersebut harus memiliki konsensus 51 dari 100.

Matematika untuk membuat tanda tangan tanpa ada anggota yang belajar cara menandatangani atas nama seluruh kelompok itu rumit. Skema yang digunakan dalam produksi di tBTC saat ini dijelaskan dalam GG18, dan implementasi yang digunakan klien utama adalah Binance

tss-lib

.

Di antara blok bangunan lainnya, GG18 (dan

tss-lib

) menggunakan kriptosistem Paillier untuk sifat homomorfiknya[1]. Saat menyiapkan kriptosistem Paillier, setiap peserta menghasilkan dua bilangan prima besar (p, q) sebagai kunci privat mereka, dan kemudian N = p • q sebagai kunci publik mereka.[2]

Kerentanan BitForge berkisar pada apa yang terjadi ketika penanda tangan jahat dapat menggunakan modulus

N = bilangan prima kecil 1 • bilangan prima kecil 2 • ... • bilangan prima kecil 16 • q

, dan tidak ada peserta lain yang memeriksa.

Dalam tBTC, eksploitasi kerentanan BitForge yang berhasil dapat mencuri materi penting, yang menyebabkan hilangnya dana. Untuk melakukan itu, serangan akan memerlukan

  • Serangan perantara yang berhasil terhadap komunikasi penanda tangan — tidak mungkin, mengingat lapisan jaringan kami yang tangguh.

  • Seorang staker T jahat yang sudah ada dan mengetahui kerentanan tersebut, dan cukup T yang dipertaruhkan untuk dipilih menjadi dompet.

Mitigasi Segera

Sekarang setelah kita memahami kerentanannya, ada dua tindakan yang dapat segera kita ambil untuk mengurangi ancaman tersebut.

Pertama, kami menghentikan detak jantung dompet. tBTC mengandalkan tanda tangan berkala dari dompet ("detak jantung") untuk membuktikan keaktifan penanda tangan. Karena BitForge menargetkan protokol penandatanganan, dan karena tBTC belum mendukung penebusan pada bulan Mei, menonaktifkan detak jantung berarti kerentanan tidak dapat dieksploitasi lebih lanjut, bahkan oleh penanda tangan jahat yang telah ditugaskan ke dompet BTC.

Kedua, kami bekerja dengan tata kelola untuk menonaktifkan pembuatan dompet baru. Karena tBTC v2 diluncurkan dengan pembatasan staker beta, kami tahu kemungkinan adanya penanda tangan jahat rendah. Namun, langkah ini semakin memastikan penanda tangan baru yang mengetahui kerentanan tersebut tidak dapat masuk ke dompet baru.

Kedua tindakan ini dilaksanakan pada tanggal 11 Mei 2023. Tanpa tanda tangan atau DKG, tidak ada jalur kode di

tss-lib

dapat dipicu di mainnet. Pada titik ini, kurang dari 24 jam sejak respons insiden, kami memiliki apa yang diharapkan oleh setiap teknisi keamanan dalam mitigasi kerentanan aktif — waktu.

Kami mempertimbangkan dua rencana serangan.

"Yang Besar"

Kami menyebut rencana mitigasi pertama yang sedang dipertimbangkan sebagai "Yang Besar". Sesuai namanya, rencana ini mencakup langkah-langkah drastis.

Pertama, kita perlu menerapkan alternatif untuk

tss-lib

dan GG18 yang tidak mengalami kerentanan BitForge. Kami telah merencanakan untuk mengirimkan dukungan untuk tanda tangan Schnorr sebagai peningkatan kinerja.

Jika Anda tidak familier dengan tanda tangan Schnorr, anggap saja itu sebagai peningkatan besar pada skema tanda tangan ECDSA yang banyak digunakan di Bitcoin dan Ethereum saat ini. Tanda tangan Schnorr sangat menyederhanakan konstruksi ambang batas tanpa asumsi tambahan dari tanda tangan BLS... tetapi yang terpenting, tanda tangan itu didukung di Bitcoin saat ini!

Penambahan ini berarti pembaruan versi utama untuk

tetap inti

Klien P2P yang mendukung tBTC — hal yang sulit dilakukan secara diam-diam. Untungnya, hal itu sudah ada dalam rencana kami, jadi pengirimannya tidak akan menimbulkan kecurigaan akan kerentanan yang tidak diungkapkan.

Langkah terakhir dalam rencana ini memerlukan perputaran semua dompet BTC dalam sistem: dapat dilakukan, tetapi lambat, memerlukan upaya koordinasi seluruh komunitas.

"Menambal Paillier"

Rencana mitigasi kedua, yang disebut "Menambal Paillier", akan mencoba memperbaiki masalah tersebut di tempat.

Pertama, kami akan mengirimkan perbaikan sisi klien untuk mencegah bilangan prima kecil yang dihasilkan secara tidak sengaja. Meskipun ini tidak akan melindungi dari klien yang dibuat secara jahat, ini akan menghindari

Kemudian, kami akan mengirimkan mitigasi penuh terhadap BitForge, menggunakan bukti Paillier ZK "faktor yang tidak kecil" yang ditemukan dalam protokol ECDSA ambang batas CGGMP21.

Setelah berdiskusi, jelas bahwa rencana ini merupakan pilihan yang lebih konservatif; dan ternyata, kami telah menerapkan sebagian besar bukti yang diperlukan dalam upaya penelitian sebelumnya.

Kami mulai menerapkan bukti ZK untuk rilis klien pribadi.

Membuktikan Kejujuran Operator

Sembari mengimplementasikan patch penuh, kami juga berupaya mengonfirmasi temuan kami sejauh ini.

Kami tahu bahwa tidak ada operator baru yang dapat menyerang tBTC... tetapi bagaimana dengan operator yang sudah ada? Jika rincian kerentanan BitForge bocor, dapatkah operator mempertaruhkan dana mereka?

Pada saat pengungkapan tersebut, tBTC memiliki 4 dompet, yang masing-masing memiliki 100 anggota. Jika kami dapat membuktikan tidak ada faktor kecil yang digunakan saat dompet tersebut dibuat, tanpa keraguan yang wajar, kami dapat menghindari perputaran dompet, dan menjadi jauh lebih yakin akan keamanan sistem.

Setiap anggota dari setiap dompet memiliki modulus Paillier. Kami menggunakan brute force.

Pengungkapan aslinya tidak menjelaskan secara spesifik bagaimana serangan itu bekerja, tetapi tertulis:

Asal usul kerentanan ini adalah karena para pihak tidak memeriksa apakah modulus Paillier, yang dilambangkan dengan N, memiliki faktor-faktor kecil (bilangan prima berukuran kurang dari 2 100 dianggap kecil) atau bahwa bilangan tersebut merupakan biprima (sehingga merupakan hasil perkalian tepat dua bilangan prima).

Versi serangan yang paling sulit dideteksi yang relevan dengan tBTC adalah ketika penyerang menggunakan faktor kecil sekitar 2100 dan faktor lainnya sekitar 21948. Semakin banyak faktor yang dimiliki modulus, semakin mudah untuk memfaktorkannya. Semakin kecil faktor apa pun, semakin mudah untuk memfaktorkannya. Kami bersiap untuk yang terburuk dan berharap yang terbaik!

Pertama, kami membuat satu set kunci berbahaya. Pustaka python libnum cocok untuk ini:

impor libnum bit = 100 total_bit = 2048 q = libnum.generate_prime(bit) p = libnum.generate_prime(total_bit - bit) N = p * q cetak(p, q, N)

Ini menciptakan modulus 2048-bit yang dihasilkan secara acak dengan satu faktor kecil (~2^100), dan satu faktor besar (~2^1948).

Kemudian, kami mengukur berapa lama waktu yang dibutuhkan untuk memfaktorkan hal ini menggunakan sympy.ntheory.factorint:

impor waktu dari sympy.ntheory impor faktorint mulai = waktu.waktu() faktor = faktorint(N) akhir = waktu.waktu() cetak(faktor, str(akhir - mulai))

Semua tes diperhitungkan! Berikut statistiknya:

N. 64 menit 4016,88 q1 35906,3 median 65896,9 q3 123775 maks 453262 rata-rata 105729 stddev 107148 stderr 13393,6

Pada tanggal 12 Mei 2023, dua hari setelah mitigasi aktif, kami mengonfirmasi bahwa tidak ada bilangan prima di bawah 50 bit yang menggunakan laptop kami... dan bersiap untuk proses pemfaktoran yang lebih lama di cloud.

Kemudian, kami memutar 8x48-core CPU-Optimized Digital Ocean Droplets dan 1x16 core, sehingga totalnya menjadi 400 core.

faktorin

berjalan dengan metode single-threaded (dan merupakan pustaka pemfaktoran tercepat yang kami temukan); setiap kotak diberi satu angka untuk difaktorkan per inti.

impor sys dari sympy.ntheory impor factorint impor waktu impor json N = int(sys.argv[1], 16) mulai = waktu.waktu() faktor = factorint(N) akhir = waktu.waktu() berkas = buka(f'{sys.argv[2]}.txt', "w") berkas.writelines([json.dumps(faktor), "\n", str(akhir - mulai)]) berkas.tutup()

Kami mendistribusikan modulus di antara mesin-mesin dan kemudian mulai melakukan pemfaktoran.

python3 factor.py <moduli1> 1 & tolak python3 factor.py <moduli2> 2 & tolak ... python3 factor.py <moduli48> 48 & tolak

Kami memeriksa ulang bahwa kami memiliki 48 inti pada setiap mesin yang berjalan pada utilisasi 100%, lalu memeriksa secara berkala untuk memastikan tidak ada yang rusak.

Kami menjalankan mesin dari 2023-05-15T16:01Z hingga 2023-05-22T19:21Z yang berarti 7 hari, 3 jam, 20 menit atau 616.800 detik total. Tak satu pun dari 400 utas menemukan faktor apa pun.

Ini sekitar 4,8 deviasi standar di atas rata-rata dan 36% lebih lama daripada upaya pemfaktoran terpanjang yang kami lihat, yang memberi kami keyakinan bahwa kami telah mencoba pemfaktoran cukup lama.

Agar faktor kecil dapat hadir, penyerang perlu memiliki:

  • Menemukan serangan itu jauh sebelum para peneliti keamanan.

  • Mengubah klien sebelum dompet terbentuk. Dompet terbaru didaftarkan pada 2023-04-19.

  • Entah bagaimana menghindari terdeteksinya faktor kecilnya oleh algoritma di atas.

Dengan semua ini, kami tahu bahwa tidak ada satu pun kunci yang berisiko terkena serangan potensial ini.

Patch Penuh

Makalah CGGMP21 juga menggunakan kriptosistem Paillier. Perbedaannya adalah bahwa selama pembuatan kunci, protokol membuat setiap peserta membuktikan tanpa pengetahuan bahwa

  • Modulusnya mengandung banyak faktor kecil. h.66.

  • Modulusnya adalah modulus Paillier-Blum. hal.36.

  • Parameter Ring-Pedersen mereka terbentuk dengan baik. h.37.

Pada tanggal 16 Mei 2023, kami memiliki prototipe semua bukti dan memulai peninjauan internal.

Pada tanggal 5 Juni, kami membuat fork pribadi dan kemudian diam-diam membangun + mengirimkan biner klien menggunakan versi pribadi dan khusus

tss-lib

untuk melakukan pembuktian di atas.

Karena kami sudah merencanakan rilis klien utama untuk mengaktifkan fitur baru yang menyeluruh, kami dapat menyertakan patch secara diam-diam — tanpa mengungkapkan kerentanan atau memberi tahu calon peretas mana pun.

Pada tanggal 6 Juni, Trail of Bits mulai memverifikasi patch kami, dan pada tanggal 7 Juni, kami telah memperbaiki semua temuan. [3]

Tesis tss-lib Laporan Ringkasan Remediasi BitForge Tesis tss-lib Laporan Ringkasan Remediasi BitForge.pdf 772 KB download-circle Pengungkapan TSShock

Pada tanggal 14 Juli, kami menerima laporan lain tentang masalah kritis, kali ini dari tim Verichains melalui ImmuneFi. Yang paling mengkhawatirkan, tim menyertakan bukti konsep yang mereka klaim menunjukkan eksfiltrasi kunci dari

tetap inti

klien.

Namun, saat kami menyelidikinya, kami menyadari bahwa PoC tim Verichains didasarkan pada versi klien yang lebih lama,

v2.0.0-m3

—bukan rilisan beta klien pribadi yang digunakan para staker.

Pada tanggal 18 Juli, kami mengonfirmasi bahwa klien yang ditambal secara pribadi dari mitigasi BitForge juga membuat tBTC aman terhadap kerentanan baru, yang dijuluki TSShock, dan bahwa serangan itu tidak mungkin terjadi pada mainnet.

Bagaimana? Saat mengerjakan mitigasi BitForge, kami menemukan masalah tabrakan hashing di balik TSShock yang telah diperbaiki secara publik, dan menariknya ke klien yang ditambal secara pribadi. Kami menghargai pengungkapan dari Verichains, dan senang dengan hasilnya.

Hal-hal yang perlu dibawa pulang

Pengungkapan yang bertanggung jawab sulit dilakukan

Seperti biasa, salah satu bagian tersulit dari pengungkapan yang bertanggung jawab adalah sering kali menemukan orang yang tepat untuk diajak bicara.

Selama beberapa hari terakhir saya telah bekerja dengan sekelompok whitehats, auditor, dan pemimpin keamanan lainnya untuk mencoba dan memecahkan bagian tersulit dari pengungkapan yang bertanggung jawab: menemukan orang yang tepat untuk diajak bicara. pic.twitter.com/pPjt7D51ZE

— @samczsun.com (@samczsun) 7 Agustus 2023

Di sini, kami beruntung mendapatkan pengungkapan BitForge begitu awal — banyak perantara yang terlibat sebelum kami menghubungi tim Fireblocks.

Tidak jelas bagaimana kami bisa melakukan yang lebih baik di sini... repositori yang relevan memiliki proses pengungkapan yang dipublikasikan, kami memiliki program hadiah ImmuneFi, kami merespons email dengan cepat melalui

keamanan@threshold.network

, dan kami mengikuti standar security.txt.

Di sisi lain, kami mengalami beberapa kendala dalam memverifikasi bahwa masalah yang dialami ThorChain pada tanggal 16 Agustus, sebenarnya adalah TSShock — dan bukan kerentanan baru. Saya tidak dapat mengonfirmasinya, meskipun telah menghubungi melalui Twitter, melalui kontak Telegram bersama, dll.

Kita perlu menemukan cara yang lebih baik di seluruh industri untuk melakukan koordinasi, terutama antara proyek-proyek dengan ketergantungan bersama yang penting seperti

tss-lib

.

Di mana ada asap, di situ ada api.

Binance adalah

tss-lib

telah mengalami sejumlah masalah selama bertahun-tahun. Tidak sering diperbarui, cakupan pengujiannya tidak bagus, dan sebagian besar perbaikan kode selama beberapa tahun terakhir merupakan respons terhadap pengungkapan.

Kami tahu, karena kami sendiri termasuk kontributor yang paling sering.

Setelah BitForge dan TSShock, kami tidak lagi yakin dengan hulu

tss-lib

repositori, termasuk mitigasi yang tepat terhadap masalah ini.

Sebaliknya, kami merekomendasikan semua

tss-lib

pengguna untuk mempertimbangkan penggunaan fork kami, yang sekarang merupakan sumber terbuka.

Pekerjaan Masa Depan

Selain masalah-masalah yang ada

tss-lib

... keluarga protokol ambang batas GG18 juga memiliki sejumlah kerentanan selama bertahun-tahun. Dan sementara semua kriptografi perlu menjalani ujian waktu, di mana ada asap, sering kali ada api — dan jika kita dapat menghindari risiko, kita harus melakukannya.

Banyak proyek memerlukan ECDSA ambang batas, dan untuk itu, kami sarankan peningkatan ke CGGMP21.

Untungnya, kami memiliki alternatif yang lebih kuat. Sejak 14 November 2021, Bitcoin mengaktifkan skema tanda tangan baru — Schnorr. Sejak April, rencana kami adalah memigrasikan tanda tangan tBTC ke Schnorr, menggunakan ROAST/FROST dan GJKR (RFC 10) untuk menghindari kerumitan implementasi ECDSA ambang batas. Tim telah setuju untuk merekomendasikan program beta staker tetap berlaku hingga migrasi ke Schnorr berlangsung.

Nantikan informasi lebih lanjut tentang upaya ini akhir tahun ini!

Ucapan Terima Kasih

Keamanan perangkat lunak merupakan pekerjaan besar, dan upaya mengatasi kerentanan ini bergantung pada sejumlah orang.

Kami ingin mengucapkan terima kasih kepada...

  • Ari dan tim di Fireblocks atas temuan mereka.

  • MacLane Wilkison, Tux, dan Dan Boneh atas bantuan mereka dalam memverifikasi pengungkapan tersebut.

  • Promethea Rashke atas karyanya dalam memindahkan bukti dari CGGMP21 ke tss-lib, Beau Rancourt atas karyanya dalam memfaktorkan modulus Paillier yang ada, dan Jakub Nowakowski, Piotr Dyraga, dan Lukasz Zimnoc atas karya mereka dalam mengoordinasikan respons kami dan meninjau semua kode.

  • Tjaden Hess dan Trail of Bits atas bantuan dan masukan mereka dalam memverifikasi mitigasi kami.

  • DAO Threshold karena responsivitasnya yang luar biasa.

Garis Waktu

Bagi yang tertarik, berikut kronologi yang lebih rinci. Harap dicatat bahwa semua waktu adalah UTC.

  • 2023-05-10 9:19 PM: Terima pengungkapan kerentanan asli.

  • 2023-05-10 9:53 PM: Distribusikan pekerjaan: Kuba mengambil modulus Paillier yang ada sehingga kami dapat memeriksa dan mulai memfaktorkannya. Promethea mulai menambal tss-lib. Beau mulai menulis kode pemfaktoran dan tolok ukur. Piotr menyiapkan transaksi untuk tata kelola tBTC guna menghentikan sementara pembuatan dompet baru.

  • 2023-05-11 12:06 AM: Kuba mengekstrak dan membagikan 400 moduli yang ada.

  • 2023-05-11 1:08 PM: Piotr menyerahkan transaksi untuk menghentikan sementara pembuatan dompet baru ke tata kelola.

  • 2023-05-11 7:45 PM: Promethea mengimplementasikan draf kasar bukti yang diperlukan dalam percabangan pribadi tss-lib.

  • 2023-05-12 16:35: Beau berhasil menghasilkan biprima berukuran tepat dan mulai mencoba memfaktorkannya.

  • 2023-05-12 7:15 PM: Beau menggunakan bi-prima yang lebih mudah difaktorkan untuk membandingkan berbagai pustaka pemfaktoran dan memahami bagaimana skala kinerja. Primefac memberikan kinerja terbaik.

  • 2023-05-15 12:12 PM: Tata kelola tBTC menonaktifkan pembuatan dompet baru.

  • 2023-05-15 16:36: Beau mulai memfaktorkan semua 400 modulus menggunakan droplet Digital Ocean yang dioptimalkan CPU.

  • 2023-05-17 14:49: Promethea menyesuaikan patch tss-lib agar sepenuhnya kompatibel dengan klien keep.

  • 2023-05-19 1:58 PM: Promethea mengidentifikasi potensi tabrakan hash dan menambahkan perbaikan.

  • 2023-05-22 7:21 PM: Beau mematikan mesin pemfaktoran. Tidak ada faktor yang ditemukan.

  • 2023-05-25 5:01 PM: Piotr menjadwalkan audit Trail of Bits untuk perubahan dan membuat cabang penasihat keamanan baru tss-lib untuk memfasilitasi audit.

  • 2023-06-05 14:25: Piotr diam-diam memasukkan perubahan ke keep-core rilis v2.0.0-m3.

  • 2023-06-06 9:42 PM: tjade273 (Auditor Trail of Bits) menyelesaikan tahap pertama patch keamanan tss-lib.

  • 2023-06-07 2:51 PM: Promethea mengidentifikasi bahwa Ntilde, (modulus Paillier lainnya) juga rentan dan perbaikan juga perlu diterapkan pada protokol pembagian ulang (kami tidak menggunakan pembagian ulang; kami tetap memperbaikinya).

  • 2023-06-13 2:34 PM: Promethea menyelesaikan pembagian ulang dan perbaikan Ntilde.

  • 2023-07-14 10:11AM: Temukan melalui ImmuneFi bahwa Verichains menemukan eksploitasi yang melibatkan tabrakan hash yang telah diperbaiki oleh Promethea.

  • 2023-07-18 3:04PM: Kuba mengonfirmasi bahwa PoC Verichains tidak memengaruhi klien keep-core yang ditambal secara pribadi.

  • 2023-07-20 11:34 AM: Kirim keep-core v2.0.0-m4 yang menyertakan perbaikan ntilde dan pembagian ulang.

  • 2023-06-29 10:49 PM: tjade273 selesai mengaudit pembagian ulang dan perbaikan Ntilde.

  • 2023-08-16 1:46 PM: Proyek lain mencuit tentang kerentanan baru (yang sama). Kami menunda perilisan pengungkapan ini untuk melakukan penyelidikan.

[1]: Skema enkripsi homomorfik adalah skema di mana Anda dapat melakukan perhitungan matematika pada teks terenkripsi dan dapat mendekripsinya dengan benar nanti. Bagi Paillier,

dekripsi(enkripsi(pesan1) • enkripsi(pesan2)) == pesan1 + pesan2

.

[2]: Secara komputasi mudah untuk memverifikasi bahwa

N = p • q

tetapi sulit untuk mengetahui p dan q yang diberikan hanya N. Lihat Faktorisasi Bilangan Bulat. Angka terbesar yang difaktorkan adalah RSA-250, angka dengan 250 digit desimal, pada tahun 2020. Total waktu komputasi sekitar 2700 tahun inti komputasi.

[3]: Komentar tinjauan penarikan hilang saat pengungkapan keamanan digabungkan. Kami sedang bekerja sama dengan GitHub untuk memulihkannya. Sementara itu, berikut tangkapan layarnya:

Dan berikut adalah Ringkasan Remediasi yang disusun oleh Trail of Bits.

Lampiran

Ns Berbahaya untuk Benchmarking

https://Gist.github.com/beaurancourt/c26f437baa62ebda45d069998273b053

Hasil Benchmark

Diukur dalam detik, berdasarkan indeks.

Hasil Waktu Tolok Ukur Kerentanan Hasil Waktu Tolok Ukur Kerentanan. GitHub Gist: langsung bagikan kode, catatan, dan cuplikan.Intisari 262588213843476