Menguji dan Memvalidasi Penerapan RNG

Pengujian generator bilangan acak menghadapi tantangan mendasar: urutan yang benar-benar acak dan urutan semuacak dari PRNG yang baik tampak sama bagi pengujian statistik. Tidak ada pengujian dengan panjang terbatas yang dapat membuktikan bahwa suatu urutan acak — statistik hanya dapat mendeteksi ketidakacakan dengan tingkat keyakinan tertentu. Pengujian memvalidasi bahwa RNG tidak memiliki bias atau pola yang jelas, tetapi tidak dapat membuktikan keamanan kriptografis. Pengujian RNG kriptografis memiliki dua tujuan yang berbeda: (1) kualitas statistik — memverifikasi bahwa distribusi keluaran tampak seragam dan independen; (2) kekuatan kriptografis — memverifikasi bahwa algoritme DRBG diterapkan dengan benar dan klaim keamanannya terpenuhi. Kedua tujuan ini memerlukan pendekatan pengujian yang berbeda.

NIST SP 800-22 menyediakan 15 pengujian statistik untuk mengevaluasi urutan bit. Pengujian tersebut meliputi: pengujian frekuensi (satu bit) — proporsi bit 1 harus mendekati 0.5. Pengujian frekuensi blok — frekuensi bit 1 dalam setiap blok m-bit. Pengujian rangkaian — jumlah rangkaian bit identik yang tidak terputus. Pengujian rangkaian terpanjang — panjang rangkaian bit 1 yang paling panjang. Pengujian peringkat matriks biner — peringkat matriks biner yang dibentuk dari urutan tersebut. Pengujian spektral (DFT) — mendeteksi pola periodik. Pencocokan templat yang tumpang tindih — menghitung kemunculan pola tertentu. Pengujian statistik universal Maurer — memampatkan urutan dan mengukur seberapa pendek hasilnya. Setiap pengujian menghasilkan nilai-p; p < 0.01 menunjukkan kemungkinan ketidakacakan. Pengujian dilakukan pada 1 juta hingga 1 miliar bit.

TestU01 (L'Ecuyer dan Simard, 2007) adalah kumpulan pengujian statistik komprehensif yang banyak digunakan dalam komunitas RNG. SmallCrush: 10 pengujian, sekitar 35 detik, sesuai untuk pemeriksaan cepat. Crush: 144 pengujian, sekitar 2 jam. BigCrush: 160 pengujian, sekitar 24 jam. Pengujian BigCrush menemukan korelasi halus yang tidak terdeteksi oleh NIST SP 800-22. DRBG kriptografis yang dirancang dengan baik (HMAC_DRBG, CTR_DRBG) lulus BigCrush dengan mudah — keluarannya tidak dapat dibedakan secara komputasional dari keluaran acak oleh algoritme waktu polinomial. PRNG nonkriptografis (Mersenne Twister, generator kongruensial linear) gagal dalam beberapa pengujian BigCrush. Kegagalan BigCrush merupakan indikator kuat bahwa RNG tersebut tidak boleh digunakan untuk keperluan kriptografis.

SP 800-90B dan 90A menetapkan pengujian kesehatan yang harus dijalankan DRBG secara terus-menerus selama beroperasi. Pengujian RNG Berkelanjutan (CRNGT): setiap blok yang dihasilkan dibandingkan dengan blok sebelumnya — jika keduanya sama (RNG macet), DRBG harus masuk ke keadaan kesalahan dan berhenti menghasilkan keluaran. Pengujian Hitungan Pengulangan: jika sampel berturut-turut memiliki nilai yang sama berulang lebih banyak daripada yang diharapkan secara statistik berdasarkan perkiraan entropi, pengujian gagal. Pengujian Proporsi Adaptif: jika nilai yang paling sering muncul melebihi jumlah ambang dalam suatu jendela, pengujian gagal. Pengujian kesehatan ini mendeteksi kegagalan sumber entropi (sensor macet, kerusakan perangkat keras HWRNG) sebelum kegagalan tersebut secara diam-diam membahayakan pembuatan kunci kriptografis.

PractRand adalah alat pengujian RNG modern yang dirancang untuk evaluasi daring saat data mengalir, dengan menganalisis urutan ketika dihasilkan, bukan mengharuskan panjang yang telah ditentukan sebelumnya. Alat ini menerapkan pengujian yang mencakup pengujian celah, pengujian distribusi bit, dan pengujian spektral dengan presisi adaptif. PractRand sangat efektif dalam mendeteksi RNG yang menghasilkan urutan pendek yang baik, tetapi memperlihatkan pola setelah mencapai miliaran bit. DRBG kriptografis menghasilkan keluaran yang tidak dapat dibedakan PractRand dari keluaran acak, berapa pun panjangnya — inilah definisi operasional ketidakdapatdibedakan secara komputasional. PractRand juga digunakan untuk mengevaluasi sumber entropi (menguji keluaran /dev/urandom dan keluaran RDRAND) guna mendeteksi kegagalan perangkat keras atau bias sistematis.

Program Validasi Algoritme Kriptografis (CAVP) menyediakan vektor pengujian resmi untuk DRBG SP 800-90A. Pengujian CAVP melibatkan pengiriman implementasi ke sistem pengujian otomatis NIST dengan vektor pengujian yang jawabannya diketahui (KAT): berdasarkan masukan entropi, nilai sekali pakai, string personalisasi, dan additional_input tertentu, implementasi tersebut harus menghasilkan bit keluaran yang sama persis dengan yang diharapkan. CAVP tidak menguji sifat statistik — program ini menguji kebenaran algoritmis. Sertifikasi FIPS 140-3 mengharuskan validasi CAVP untuk semua algoritme kriptografis yang digunakan dalam batas modul. Vektor pengujian CAVP tersedia untuk umum dari peladen ACVP (Automated Crypto Validation Protocol) milik NIST dan diintegrasikan ke dalam rangkaian pengujian OpenSSL, mbedTLS, dan BoringSSL.

Sebelum DRBG dapat diinisialisasi dengan aman, sumber entropinya harus divalidasi. SP 800-90B menetapkan: (1) Perkiraan entropi — mengukur entropi aktual per bit menggunakan pengujian statistik (perkiraan entropi minimum). (2) Pengujian saat mulai — memverifikasi bahwa sumber entropi menghasilkan keluaran yang valid sebelum penggunaan pertama. (3) Pengujian sesuai permintaan — pengujian opsional yang dipicu oleh aplikasi. (4) Pengujian kesehatan sumber derau — mendeteksi penurunan kualitas perangkat keras. Sumber entropi umum dan perkiraan entropinya per bit: CPU RDRAND/RDSEED (sekitar 1 bit/bit, tersertifikasi perangkat keras); /dev/urandom (mencampurkan beberapa sumber, dengan perkiraan entropi yang konservatif); TRNG osilator cincin (0,5–0,9 bit/bit bergantung pada desain); derau ADC (0,1–0,5 bit/bit). Validasi SP 800-90B memerlukan pengujian laboratorium dengan peralatan khusus.

Lingkungan virtual menimbulkan tantangan khusus dalam pengujian RNG. VM mungkin mengalami kondisi entropi rendah saat mulai berjalan (tanpa peristiwa perangkat keras) atau setelah pemulihan cuplikan (keadaan diatur ulang). Kontainer Docker berbagi RNG dari inti sistem mesin induk — kontainer tidak dapat menguji kualitas entropi yang mendasarinya secara langsung. Pengujian untuk penerapan VM: (1) Ukur waktu hingga pembacaan /dev/random selesai — waktu tunggu yang lama menunjukkan entropi yang tidak memadai. (2) Uji apakah terdapat UUID atau kunci duplikat yang dihasilkan secara paralel pada instans VM (mode kegagalan nyata yang didokumentasikan dalam penerapan awan). (3) Pastikan VIRTIO-RNG (virtio_rng.ko) dimuat dalam VM — ini menyediakan injeksi entropi dari mesin induk ke mesin tamu. (4) Audit urutan inisialisasi aplikasi: apakah pembuatan kunci berlangsung sebelum entropi yang memadai tersedia?

Pengujian keamanan pencabangan RNG mencegah kerentanan terselubung: ketika suatu proses bercabang, proses induk dan anak berbagi keadaan DRBG yang sama sehingga keduanya menghasilkan urutan yang identik. Deteksi: buat N proses anak, hasilkan satu UUID di masing-masing proses, lalu pastikan semua UUID unik. Jika ada dua yang sama, RNG tersebut tidak aman terhadap pencabangan. OpenSSL memperbaiki cacat keamanan pencabangan pada 2020 (CVE-2020-1971 tidak secara langsung melibatkan DRBG, tetapi polanya serupa). OpenSSL saat ini menggunakan pembaruan benih berbasis PID: jika PID berubah sejak pemanggilan terakhir (yang menunjukkan adanya pencabangan), DRBG secara otomatis diberi benih ulang. Untuk mengujinya, jalankan pengujian sebelum dan sesudah pencabangan, lalu pastikan pembenihan ulang terjadi dengan memverifikasi keluaran yang berbeda.

Daftar periksa praktis untuk audit implementasi RNG: (1) Apakah RNG diinisialisasi dari OS (getrandom, BCryptGenRandom), bukan dari benih berbasis waktu? (2) Apakah jenis DRBG merupakan mekanisme yang disetujui NIST SP 800-90A (Hash, HMAC, CTR)? (3) Apakah panjang benih cukup untuk kekuatan keamanan yang diklaim? (4) Apakah pembenihan ulang dipicu secara berkala atau setelah jumlah pemanggilan pembuatan yang tetap? (5) Apakah implementasi menangani keamanan pencabangan (pembenihan ulang setelah pencabangan)? (6) Apakah pengujian kesehatan diaktifkan dan apakah sistem berhenti ketika terjadi kegagalan? (7) Apakah keadaan dinolkan saat sistem dimatikan? (8) Apakah vektor pengujian CAVP dijalankan dalam CI/CD? (9) Apakah estimasi entropi didokumentasikan dan divalidasi? (10) Untuk persyaratan FIPS: apakah modul tersebut tersertifikasi FIPS 140-3?

Kegagalan RNG dalam sejarah menunjukkan besarnya risikonya. OpenSSL Debian (2006–2008): sebuah tambalan secara tidak sengaja menghapus dua baris kode pengumpulan entropi sehingga kumpulan benih berkurang menjadi ruang PID 15 bit — hanya 32.767 kunci SSH yang mungkin dihasilkan untuk seluruh basis pengguna Debian. Semua kunci SSH server dan kunci pengguna yang dihasilkan Debian perlu diganti. Dompet Bitcoin di Android (2013): SecureRandom milik Android menggunakan pembenihan tingkat Java yang gagal pada beberapa perangkat sehingga menyebabkan nilai k duplikat dalam tanda tangan ECDSA — yang secara langsung mengungkapkan kunci privat. Sony PS3 (2010): menggunakan nonce konstan dalam penandatanganan firmware ECDSA sehingga memungkinkan ekstraksi kunci privat dari dua tanda tangan (k yang sama pada pesan berbeda mengungkapkan kunci melalui aljabar sederhana).

Manakah dari pengujian berikut yang mendeteksi bahwa DRBG mungkin menghasilkan keluaran macet (nilai yang sama berulang kali)?

Pengujian statistik (NIST SP 800-22, TestU01 BigCrush, PractRand) memverifikasi kualitas keluaran, tetapi tidak dapat membuktikan keamanan kriptografis. Pengujian jawaban yang diketahui dari CAVP memverifikasi kebenaran algoritmik implementasi SP 800-90A. Pengujian sumber entropi SP 800-90B (estimasi entropi minimum, pengujian kesehatan) memvalidasi masukan benih. Pengujian RNG Berkelanjutan (CRNGT) mendeteksi keluaran macet secara waktu nyata. Penerapan VM dan kontainer memerlukan injeksi entropi (VIRTIO-RNG) serta pemeriksaan entropi saat mulai berjalan. Pengujian keamanan pencabangan memverifikasi bahwa proses anak tidak mewarisi keadaan DRBG proses induk. Kegagalan di dunia nyata (Debian, Android) menunjukkan bahwa cacat RNG dapat langsung menyebabkan kompromi kunci kriptografis. Daftar periksa audit meresmikan pemeriksaan ini untuk penerapan produksi.