Apakah pantas menggunakan hasged sebagai sumber entropi pada mesin virtual?

(Peringatan: Saya tentu saja tidak mengklaim bahwa HAVEGE memenuhi klaimnya. Saya belum memeriksa teori atau penerapannya.)

Untuk mendapatkan keacakan, HAVEGE dan sistem serupa memanfaatkan "peristiwa fisik", dan khususnya pada waktu dari peristiwa fisik. Peristiwa semacam itu termasuk kejadian interupsi perangkat keras (yang, pada gilirannya, mengumpulkan data tentang penekanan tombol, gerakan mouse, paket ethernet yang masuk, waktu hard disk untuk menyelesaikan permintaan tulis...). HAVEGE juga mengklaim memberi makan pada semua jenis kesalahan cache yang terjadi di CPU (cache L1, cache L2, TLB, prediksi cabang...); perilaku elemen-elemen ini bergantung pada apa yang telah dilakukan CPU dalam beberapa ribu siklus clock sebelumnya, sehingga ada potensi "keacakan". Ini bergantung pada kemungkinan untuk mengukur waktu saat ini dengan sangat presisi (belum tentu akurat), di mana rdtsc instruksi mulai berlaku. Ini mengembalikan konten penghitung internal saat ini yang bertambah pada setiap siklus clock, sehingga menawarkan presisi sub-nanodetik.

Untuk sistem mesin virtual, ada tiga pilihan sehubungan dengan instruksi ini:

1. Biarkan instruksi langsung ke perangkat keras.
2. Jangkap instruksi dan tiru.
3. Nonaktifkan instruksi sama sekali.

Jika manajer VM memilih solusi pertama, maka rdtsc memiliki semua presisi yang dibutuhkan, dan harus berfungsi sebaik jika berada di mesin fisik, untuk tujuan mengumpulkan entropi dari peristiwa perangkat keras. Namun, karena ini adalah mesin virtual, ini adalah aplikasi di sistem host; itu tidak mendapatkan CPU sepanjang waktu. Dari sudut pandang sistem operasi tamu menggunakan rdtsc , sepertinya CPU-nya kadang-kadang "dicuri":dua rdtsc berturut-turut instruksi, yang secara nominal dipisahkan oleh satu siklus clock, dapat melaporkan peningkatan penghitung sebesar beberapa juta . Singkatnya, saat rdtsc hanya diterapkan pada perangkat keras, lalu OS tamu dapat menggunakannya untuk mendeteksi keberadaan hypervisor.

Solusi kedua dimaksudkan untuk membuat emulasi lebih "sempurna" dengan mempertahankan penghitung siklus per-VM virtual, yang melacak siklus yang benar-benar dialokasikan ke VM tersebut. Keuntungannya adalah rdtsc , dari sudut pandang tamu, tidak akan lagi menunjukkan efek "siklus yang dicuri". Kelemahannya adalah bahwa emulasi ini dilakukan melalui pemicuan dan penjebakan pengecualian CPU, meningkatkan biaya rdtsc opcode dari beberapa lusin siklus clock (tergantung pada merek CPU; beberapa menjalankan rdtsc kurang dari 10 siklus, penggunaan lain 60 atau 70 siklus) hingga lebih dari seribu siklus. Jika tamu mencoba melakukan banyak rdtsc (seperti yang cenderung dilakukan HAVEGE), maka itu akan melambat menjadi merangkak. Selain itu, kode penanganan pengecualian akan mengganggu pengukuran; alih-alih mengukur waktu peristiwa perangkat keras, kode akan mengukur waktu eksekusi penangan pengecualian, yang dapat menurunkan kualitas keacakan yang diekstraksi.

Solusi ketiga (menonaktifkan rdtsc ) hanya akan mencegah HAVEGE mengembalikan keacakan yang baik. Karena secara internal menggunakan PRNG, hasilnya mungkin masih menipu alat analisis statistik, karena ada perbedaan besar antara "terlihat acak" dan "tidak dapat diprediksi" (alat analisis statistik mengikuti jalur "terlihat acak", tetapi keamanan kriptografi bergantung pada ketidakpastian. ).

Manual VirtualBox mengklaim bahwa VirtualBox, secara default, mengikuti metode pertama (rdtsc diizinkan tanpa syarat dan diterapkan pada perangkat keras secara langsung), tetapi dapat dikonfigurasi untuk menerapkan solusi kedua (yang tidak Anda inginkan, dalam hal ini).

Untuk menguji apa yang dilakukan VM Anda, Anda dapat mencoba program kecil ini (kompilasi dengan gcc -W -Wall -O di Linux; -O penting):

#include <stdio.h>

#if defined(__i386__)

static __inline__ unsigned long long rdtsc(void)
{
        unsigned long long int x;

        __asm__ __volatile__ (".byte 0x0f, 0x31" : "=A" (x));
        return x;
}

#elif defined(__x86_64__)

static __inline__ unsigned long long rdtsc(void)
{
        unsigned hi, lo;

        __asm__ __volatile__ ("rdtsc" : "=a"(lo), "=d"(hi));
        return ( (unsigned long long)lo)|( ((unsigned long long)hi)<<32 );
}

#endif

int
main(void)
{
        long i;
        unsigned long long d;

        d = 0;
        for (i = 0; i < 1000000; i ++) {
                unsigned long long b, e;

                b = rdtsc();
                e = rdtsc();
                d += e - b;
        }
        printf("average : %.3f\n", (double)d / 1000000.0);
        return 0;
}

Pada mesin non-virtual, dengan rdtsc "true". , ini akan melaporkan nilai antara 10 dan 100, bergantung pada merek CPU. Jika nilai yang dilaporkan adalah 0, atau jika program macet, maka rdtsc dinonaktifkan. Jika nilainya ribuan, maka rdtsc ditiru, yang berarti pengumpulan entropi mungkin tidak bekerja sebaik yang diharapkan.

Perhatikan bahwa bahkan mendapatkan nilai antara 10 dan 100 bukanlah jaminan bahwa rdtsc tidak ditiru, karena manajer VM, sambil mempertahankan penghitung virtualnya, dapat mengurangi waktu yang diharapkan darinya untuk menjalankan penangan pengecualian. Pada akhirnya, Anda benar-benar harus melihat dengan baik manual dan konfigurasi pengelola VM Anda.

Tentu saja, seluruh premis HAVEGE patut dipertanyakan. Untuk keamanan praktis apa pun, Anda memerlukan beberapa bit "acak nyata", tidak lebih dari 200, yang Anda gunakan sebagai benih dalam PRNG yang aman secara kriptografis. PRNG akan menghasilkan gigabyte pseudo-alea yang tidak dapat dibedakan dari keacakan sebenarnya, dan itu cukup baik untuk semua tujuan praktis.

Bersikeras untuk kembali ke perangkat keras untuk setiap bit tampak seperti ledakan lain dari ide cacat yang melihat entropi sebagai sejenis bensin, yang Anda bakar saat melihatnya.

Pada penasehat polassl:Tanggapan teknis terperinci dapat ditemukan di sumber debian terbaru:

http://bazaar.launchpad.net/~ubuntu-branches/debian/experimental/haveged/experimental/revision/12?start_revid=12#debian/README.Debian

Ringkasan eksekutifnya adalah:polarssl !=haveged !=HAVEGE

Pada percobaan emulator embloms.se:

haveged rangkaian pengujian, NIST dan ent , verifikasi bahwa build sumber telah menghasilkan RNG fungsional. Pengujian run-time diperlukan untuk memverifikasi operasi yang telah dilakukan di lingkungan virtual. Itu adalah tambahan yang cukup baru untuk dimiliki.

Pada pengujian statistik:

Misalkan Anda memiliki hardware RNG , sebuah TRNG , bagaimana Anda tahu itu tidak rusak? Kerusakan perangkat keras. Badan standar Jerman memiliki spesifikasi yang menangani masalah itu, AIS31 . Pendekatan itu diadopsi oleh hasged. Diskusi (bias) tentang standar untuk RNG yang berlaku untuk hasged dapat ditemukan di:

http://www.issihosts.com/haveged/ais31.html

Ketidakpastian HAVEGE persis mekanisme yang sama terlihat pada perangkat lunak pembandingan. Ini bukan karena penyimpangan waktu, tetapi agregasi perilaku asinkron dalam prosesor modern. Tidak masalah apakah variasi kinerja berasal dari cache yang hilang atau irisan waktu yang dikirimkan ke prosesor lain. Akurasi pengatur waktu juga tidak masalah asalkan 'memadai'. Bagaimana itu ditentukan? Oleh keluaran. Berdasarkan desain (atau mungkin desain berlebihan) /dev/random kebal terhadap input data yang buruk. Satu-satunya cara untuk menumbangkan desain adalah dengan berbohong tentang entropi yang ditambahkan ke kumpulan entropi. Versi terbaru dari hasged menjalankan estimasi entropi run-time pada output yang dihasilkan untuk memastikan output konsisten dengan TRNG yang ideal.

Ringkasan eksekutif:haveged keluaran tidak dapat dibedakan dari TRNG menurut tes yang digunakan oleh badan standar Jerman untuk mengesahkan TRNG . Jika bukan itu masalahnya, haveged akan dimatikan.

(Diperbarui , terima kasih kepada gwuertz penulis/pengelola haveged saat ini , saya melewatkan pemisahan antara HAVEGE dan haveged .)

haveged adalah implementasi berbeda dari metode HAVEGE untuk menghasilkan angka acak, saat ini, dipelihara, dan didokumentasikan di sini:http://www.issihosts.com/haveged/ (dan tidak lagi menggunakan libhavege secara langsung).

HAVEGE tidak terlalu terkini (2006), meskipun seseorang telah menambalnya baru-baru ini (2009) untuk kecepatan dan kebenaran. Saya akan berhati-hati karena tidak mendokumentasikan metodenya, tidak menyebutkan mesin virtual, dan seperti disebutkan, bergantung (sangat) pada RDTSC (atau setara platform). (Juga kode sumber membuat saya bergidik, tapi itu cukup subyektif.)

Saya berpendapat bahwa VM tuan rumah tidak boleh secara tidak sengaja membocorkan status apa pun ke tamu, jadi ini tidak boleh dianggap sebagai sumber entropi yang baik saat menggunakan metode ini.

Pendekatan yang lebih baik di Linux adalah rng-tools dengan driver rng paravirtualisasi virtio-rng (yaitu mengizinkan tamu untuk mengakses entropi yang dikumpulkan oleh tuan rumah, menghilangkan banyak masalah potensial tentang tampilan tamu dari acara "acak"), atau Anda mungkin menemukan Entropi Broker lebih bermanfaat. Pada chip Intel terbaru, Anda juga dapat memaparkan instruksi RDRAND kepada tamu, mengesampingkan masalah.

Artikel ini (dari pembicaraan hpa di LinuxCon Eropa 2012 ) adalah bacaan yang bermanfaat:http://lwn.net/Articles/525459/ , juga membahas HAVEGE /haveged (meskipun perbedaannya juga tidak jelas di sini).

Lihat jawaban atas pertanyaan ini untuk beberapa pemikiran tentang cara menentukan kekurangan keacakan:Statistik apa yang dapat digunakan untuk mengidentifikasi data acak semu?