Audit Keamanan (oleh Jean Philippe Aumasson)

Kami ingin mengumumkan bahwa Ergo telah berhasil melewati audit keamanan dari bagian tertentu (paling kritis) dari kode. Kali ini audit dilakukan oleh Jean-Philippe Aumasson (aka veorq, https://aumasson.jp/ ).

Laporan rinci ada di bawah. Tidak ada yang kritis ditemukan. Komentar tentang masalah yang ditemukan:

1. Pada kata sandi dompet, kami akan memberikan rekomendasi di versi berikutnya dari klien protokol. Tidak yakin penegakan keras pada kata sandi akan dilakukan, tetapi kami akan melakukan lebih banyak konsultasi tentang ini.
2. Mengubah parameter "n" dan "k" masuk akal hanya saat meluncurkan jaringan baru. Mengubah parameter ini di node penambangan akan membuat blok yang dihasilkan tidak valid untuk node lain. Mengubah parameter ini di klien protokol berarti pergi ke fork lain (blok yang berasal dari peserta protokol yang jujur akan ditolak). Jadi mungkin tidak perlu pemeriksaan tambahan, karena orang yang meluncurkan jaringan baru akan mengatur "n" dan "k" dengan benar.
3. Saat ini node Ergo (serta klien protokol blockchain dan dompet lain yang kami ketahui, serta pustaka kriptografi yang kami gunakan) tidak memberikan perlindungan dari serangan saluran samping yang berjalan secara lokal (misalnya serangan waktu atau inspeksi memori oleh malware atau virus). Jadi, harap lindungi mesin tempat Anda menjalankan dompet!

==========================================================================================================

% Penilaian keamanan Ergo % Jean-Philippe Aumasson % 07/Des/19

Ringkasan

Kami diminta oleh Ergo untuk melakukan penilaian keamanan dari beberapa komponen Platform Ergo mereka:

• Pembuatan dan verifikasi bukti protokol Sigma
• Penyimpanan aman rahasia di dompet
• Validasi Proof-of-Work

​Laporan singkat ini merangkum penilaian kami dan menjelaskan temuan serta rekomendasi mitigasi kami.

Bukti protokol Sigma

​Protokol Ergo bergantung pada ErgoScript, bahasa skrip yang mendukung pernyataan sigma, yang dapat dibuktikan dan diverifikasi melalui bukti pengetahuan non-interaktif.

Bukti ini adalah pernyataan yang dijelaskan sebagai pohon kondisi AND, OR, dan threshold, yang daunnya adalah bukti pengetahuan dari masalah logaritma diskrit.

Bukti pernyataan sigma kemudian dibuat non-interaktif berkat transformasi Fiat-Shamir.

Logika ini ditentukan dalam makalah ErgoScript, dan rutinitas pembuktian dan verifikasi spesifik dijelaskan dalam Lampiran A-nya.

​Tantangan implementasi adalah:

• Mendefinisikan pengkodean bukti yang aman dan efisien, serta menerapkan serialisasi dan deserialisasi yang selalu berhasil dalam memproses input yang valid, dan yang selalu gagal dengan baik dalam memproses input yang tidak valid.
• Menerapkan fungsionalitas pembuktian dan verifikasi dengan benar, sesuai dengan spesifikasi, dan yang terpenting sehingga tidak ada pernyataan tidak valid yang dapat berhasil melewati verifikasi.

Kami meninjau dua aspek ini, berdasarkan kode di repositori sigmastate-interpreter, dan pada makalah ErgoScript, dengan hati-hati membandingkan perilaku yang dimaksud (di Lampiran A) dengan perilaku aktual yang diimplementasikan.

​Kami secara khusus meninjau kode dari SigSerializer, Interpreter, dan ProverInterpreter traits dan objek.

​Kami terutama mencari bug dari kelas berikut:

• ​Pemrosesan input yang tidak valid secara tidak aman
• Pemrosesan input yang tidak biasa panjang atau pendek secara tidak aman
• Perilaku saat kedalaman pohon besar atau tingkat rekursi
• Penggunaan tipe dan struktur Scala yang tidak aman
• Tipe variabel yang tidak tepat
• Overflow integer
• Kondisi balapan
• Bug logika

​Meskipun telah ditinjau secara ekstensif, kami tidak mengidentifikasi masalah keamanan.

Logika dan internal protokol tetap relatif kompleks, dan kami percaya risiko tertinggi ada pada parsing dan verifikasi bukti. Untuk mengeksploitasi masalah tersebut, bagaimanapun, seorang penyerang harus membuat skrip yang secara semantik benar yang entah bagaimana menguntungkan mereka, namun yang melewati verifikasi ketika seharusnya tidak.

Mengenai keamanan perangkat lunak, Scala menghilangkan kelas bug tertentu, tetapi kode Scala masih dapat mengalami bug karena perilaku spesifik Scala atau kesalahan yang tidak ditangani.

Dompet

Fungsi dompet Ergo memungkinkan penggunanya untuk menyimpan rahasia di disk dan memulihkannya, menginisialisasi dompet dengan seed baru saat pertama kali digunakan.

​Logika ini terutama didefinisikan dalam ErgoWalletActor, dan komponen kunci terkait penyimpanan rahasia adalah JsonSecretStorage.

​Saat pertama kali dompet dibuat, perintah InitWallet melakukan hal berikut:

• Menghasilkan settings.walletSettings.seedStrengthBits bit acak, sebagai entropi awal. Secara default, 160 bit dihasilkan.
• Menghasilkan BIP39 dari bit acak yang dihasilkan, yang dapat dilihat sebagai pengkodean dari bit entropi. Logika BIP39 standar digunakan, dengan kata sandi opsional.
• Menurunkan seed dari mnemonik menggunakan logika turunan berbasis PBKDF2 BIP39.
• Mengenkripsi seed ini ke disk dengan AES-GCM, menggunakan nonce acak, dan kunci yang diturunkan dari kata sandi menggunakan PBKDF2-HMAC-SHA256 dengan 128000 iterasi, menggunakan garam acak.

Untuk membuka kunci dompet yang sudah dibuat, pengguna memberikan kata sandi dan dompet mencoba untuk mendekripsi data yang disimpan.

​Untuk memulihkan akun yang ada dari frasa sandi BIP39, proses yang mirip dengan inisialisasi dilakukan, kecuali bahwa dompet akan menurunkan seed dari mnemonik alih-alih memilih mnemonik acak.

​Dua risiko yang kami identifikasi di sini adalah:

• Ketidakhadiran pemeriksaan pada panjang kata sandi: karena kata sandi cukup untuk mengakses seed mengingat rahasia yang disimpan di disk dompet, kata sandi seharusnya dalam teori memiliki setidaknya sebanyak entropi seperti mnemonik, dan dalam praktiknya seharusnya sulit untuk dipecahkan. Kami dengan demikian merekomendasikan untuk menegakkan panjang kata sandi minimal, misalnya 16 karakter.
• Salinan nilai rahasia (kata sandi, seed, dan kunci privat yang diturunkan) kemungkinan akan tetap ada di memori setelah eksekusi perangkat lunak dompet, yang merupakan batasan intrinsik bahasa yang mengumpulkan sampah seperti Scala.

Proses lain atau pengguna yang berbagi ruang alamat memori yang sama dapat berpotensi memulihkan rahasia, dan mereka juga dapat muncul dalam dump crash. Sejauh yang kami ketahui, tidak ada mitigasi yang efektif dalam Scala murni.

​

Validasi PoW

​Setelah sebelumnya meninjau keamanan Autolykos PoW, kami melakukan putaran tinjauan lain yang berfokus pada logika verifikasi terbarunya, dan terutama perubahan dalam komit eb0f85a.

​File utama yang relevan adalah AutolykosPowScheme, dan operasi penting lainnya misalnya diimplementasikan dalam HeadersProcessor dan ModifierValidator.

​Kami memeriksa bahwa logika verifikasi yang diimplementasikan konsisten dengan yang ditentukan dalam spesifikasi Autolykos, dan bahwa itu terintegrasi dengan baik dalam logika validasi header blok.

​Kami percaya bahwa poin-poin berikut harus ditangani:

• Validasi yang lebih ketat dari k dan n: meskipun kelas menegakkan k<=32 (jumlah elemen dalam solusi) dan n<31 (log2 dari total jumlah elemen), parameter yang diizinkan masih dapat dibuat dari parameter yang diizinkan. Fungsi validate() mungkin oleh karena itu memiliki validasi tambahan bahwa n dan k sama dengan nilai yang dimaksud.
• Menegaskan bahwa k dan n adalah nilai positif, karena saat ini nilai negatif (sebagai Ints) akan melewati pernyataan assert.