Kekurangan Entropi & Kesalahan Kunci Lemah

Kekurangan entropi terjadi ketika sistem tidak memiliki masukan tak terduga yang cukup untuk memberikan nilai awal pada CSPRNG. Hal ini terjadi pada perangkat tertanam yang baru dinyalakan, server tervirtualisasi, atau sistem tanpa masukan pengguna. Keluaran RNG menjadi dapat diprediksi.

Pada 2006, pengembang Debian menghapus baris yang ditandai oleh Valgrind: MD_Update(&m, buf, j). Baris ini adalah sumber entropi. Akibatnya: OpenSSL di Debian hanya diberi nilai awal menggunakan PID (maksimal 32.768 nilai). Semua kunci yang dibuat pada 2006–2008 berada dalam kumpulan 32.768 kemungkinan.

Kunci RSA, DSA, dan ECDSA, kunci host SSH, sertifikat TLS, serta kunci VPN SSL yang dibuat pada sistem Debian/Ubuntu selama 2006–2008 telah disusupi. Sistem yang terdampak: Debian Etch, Debian Lenny, Ubuntu 7.04–8.04. Daftar hitam diterbitkan; sertifikat dicabut.

Mesin virtual dapat dikloning dengan keadaan disk yang identik. Jika kedua mesin virtual menghasilkan kunci dari keadaan CSPRNG yang sama, keduanya menghasilkan kunci yang sama. Hipervisor kini menyuntikkan entropi melalui VirtIO RNG atau tabel ACPI, tetapi mesin virtual yang dikonfigurasi dengan buruk masih menghadapi risiko ini saat dinyalakan.

Perangkat IoT (perute, kamera) sering membuat kunci SSH/TLS saat pertama kali dinyalakan, sebelum mengumpulkan entropi. Penelitian menemukan jutaan perangkat berbagi beberapa ribu pasangan kunci RSA karena semuanya menggunakan nilai awal dari keadaan penyalaan dengan entropi rendah.

Lenstra dkk. (2012) mengumpulkan 11,7 juta sertifikat TLS dan menghitung GCD berpasangan. Ditemukan 12.720 kunci RSA yang berbagi faktor prima—artinya kedua kunci dapat difaktorkan sepenuhnya. Sebanyak 0,2% dari seluruh kunci publik berhasil dipecahkan. Penyebabnya: entropi saat penyalaan tidak memadai.

ECDSA memerlukan nonce acak k yang unik untuk setiap tanda tangan. Jika k digunakan ulang (atau lemah), kunci privat dapat segera dipulihkan: d = (s1-s2)^{-1} * (z1-z2) * k / (r1-r2) mod n. PS3 milik Sony menggunakan k=constant—semua permainan dapat ditandatangani dengan kunci yang dipulihkan.

Java SecureRandom pada Android 4.x diberi nilai awal dari waktu sistem dalam kondisi tertentu. Beberapa aplikasi dompet Bitcoin membuat tanda tangan dengan nonce k yang sama sehingga kunci privat bocor. Jutaan dolar dicuri. Google memperbaiki implementasi SecureRandom.

Alat: ssh-vulnkey (memeriksa terhadap daftar hitam kunci lemah Debian), badkeys (memeriksa sertifikat TLS untuk faktor prima yang diketahui lemah), serta algoritme GCD-batch untuk audit kunci RSA secara massal. Log Certificate Transparency memungkinkan analisis pada skala populasi.

Gunakan getrandom(GRND_RANDOM) saat pertama kali membuat kunci. Baca dari /dev/urandom setelah menunggu pemberian nilai awal pertama (periksa /proc/sys/kernel/random/entropy_avail > 128). Gunakan RNG perangkat keras (RDRAND) sebagai entropi tambahan. Jangan pernah membuat kunci saat pertama kali dinyalakan tanpa jeda.

Pertahankan keadaan CSPRNG di antara proses mulai ulang: simpan 32 byte dari /dev/urandom ke berkas nilai awal saat dimatikan; baca dan masukkan kembali saat dinyalakan. Ini menyediakan kesinambungan entropi di antara penyalaan dingin. Linux melakukan hal ini secara otomatis; sistem tertanam sering kali tidak.

Kekurangan entropi menyebabkan kunci yang dapat diprediksi. Pembobolan nyata: OpenSSL Debian (nilai awal hanya berupa PID), serangan GCD pada IoT, penggunaan ulang nonce ECDSA PS3, serta dompet Bitcoin Android. Selalu gunakan entropi OS sebagai sumber nilai awal; audit pembuatan kunci pada sistem tertanam dengan cermat. Berikutnya: membuat kunci, nonce, dan IV dengan aman.