/dev/random, penjana nombor pseudo-rawak yang selamat secara kriptografi (CSPRNG), diketahui mempunyai satu masalah yang menjengkelkan: menyekat. Artikel ini menerangkan cara anda boleh menyelesaikannya.
Sejak beberapa bulan lalu, kemudahan penjanaan nombor rawak dalam kernel telah diolah semula sedikit, tetapi masalah dalam subsistem ini telah diselesaikan sepanjang tempoh yang lebih luas. . Paling banyak telah dibuat untuk menghalang panggilan sistem getrandom() daripada menyekat untuk masa yang lama apabila sistem but, tetapi sebab asas untuk ini adalah tingkah laku menyekat kumpulan rawak. Tampalan baru-baru ini akan mengalih keluar kumpulan ini dan ia dijangka akan menuju ke teras utama.
Andy Lutomirski menerbitkan versi ketiga patch pada akhir Disember. Dia menyumbang "dua perubahan semantik utama kepada API Linux rawak". Tampalan itu menambah bendera GRND_INSECURE baharu pada panggilan sistem getrandom() (walaupun Lutomirsky merujuknya sebagai getentropy(), yang dilaksanakan dalam glibc menggunakan getrandom() dengan bendera tetap); bendera ini menyebabkan panggilan sentiasa mengembalikan jumlah data yang diminta, tetapi tanpa menjamin bahawa data itu rawak. Kernel hanya akan melakukan yang terbaik untuk menghasilkan data rawak terbaik yang ada pada masa tertentu. "Mungkin perkara terbaik untuk dilakukan ialah memanggilnya 'INSECURE' (tidak selamat) untuk menghalang API ini daripada digunakan untuk perkara yang memerlukan keselamatan."
Tompok-tompok itu juga mengeluarkan kolam yang menyekat. Kernel pada masa ini mengekalkan dua kumpulan data rawak, satu sepadan dengan /dev/random dan satu lagi dengan /dev/urandom, seperti yang diterangkan dalam ini 2015. Kolam penyekat ialah kolam untuk /dev/random; bacaan untuk peranti itu akan menyekat (bermaksud namanya) sehingga entropi "cukup" telah dikumpulkan daripada sistem untuk memenuhi permintaan. Bacaan lanjut dari fail ini juga disekat jika tidak ada entropi yang mencukupi dalam kolam.
Mengalih keluar kumpulan kunci bermakna membaca daripada /dev/random berkelakuan seperti getrandom() dengan bendera ditetapkan kepada sifar (dan menukar bendera GRND_RANDOM menjadi noop). Setelah penjana nombor rawak kriptografi (CRNG) dimulakan, membaca daripada /dev/random dan panggilan ke getrandom(...,0) tidak akan menyekat dan akan mengembalikan jumlah data rawak yang diminta.
Lutomirsky berkata: βSaya percaya bahawa kumpulan penyekat Linux telah menjadi usang. CRNG Linux menjana output yang cukup baik untuk digunakan walaupun untuk penjanaan kunci. Kumpulan penyekat tidak lebih kuat dari segi material dan memerlukan banyak infrastruktur yang mempunyai nilai yang meragukan untuk menyokongnya.β
Perubahan dibuat dengan matlamat untuk memastikan program sedia ada tidak akan benar-benar terjejas, dan sebenarnya, akan ada lebih sedikit masalah dengan menunggu lama untuk perkara seperti penjanaan kunci GnuPG.
βEpisod ini tidak boleh mengganggu mana-mana program sedia ada. /dev/urandom kekal tidak berubah. /dev/random masih menyekat serta-merta semasa but, tetapi ia menyekat kurang daripada sebelumnya. getentropy() dengan bendera sedia ada akan mengembalikan hasil yang sama sesuai untuk tujuan praktikal seperti sebelumnya."
Lutomirsky menyatakan bahawa ia masih menjadi persoalan terbuka sama ada kernel harus menyediakan apa yang dipanggil "nombor rawak benar," yang mana kernel penyekat sepatutnya lakukan pada tahap tertentu. Dia melihat hanya satu sebab untuk ini: "pematuhan dengan piawaian kerajaan." Lutomirsky mencadangkan bahawa jika kernel menyediakan ini, ia harus dilakukan melalui antara muka yang sama sekali berbeza, atau ia harus dialihkan ke ruang pengguna, membolehkan pengguna mendapatkan semula sampel peristiwa mentah yang boleh digunakan untuk mencipta kumpulan kunci sedemikian.
Stephan MΓΌller mencadangkan bahawa setnya untuk Penjana Nombor Rawak Linux (LRNG) (versi 26 dikeluarkan pada masa ini) boleh menjadi cara untuk menyediakan nombor rawak sebenar untuk aplikasi yang memerlukannya. LRNG "mematuhi sepenuhnya Garis Panduan SP800-90B mengenai Sumber Entropi yang Digunakan untuk Menjana Bit Rawak," menjadikannya penyelesaian kepada masalah piawaian kerajaan.
Matthew Garrett membantah istilah "data rawak sebenar", dengan menyatakan bahawa peranti yang dijadikan sampel pada dasarnya boleh dimodelkan dengan cukup tepat untuk menjadikannya boleh diramal: "kami tidak mengambil sampel peristiwa kuantum di sini."
MΓΌller menjawab bahawa istilah itu berasal daripada AIS 31 standard Jerman untuk menerangkan penjana nombor rawak yang hanya menghasilkan hasil "pada kadar yang sama seperti sumber bunyi asas menghasilkan entropi."
Mengetepikan perbezaan istilah, mempunyai kumpulan kunci seperti yang dicadangkan oleh tampalan LRNG hanya akan membawa kepada pelbagai masalah, sekurang-kurangnya jika ia diakses tanpa keistimewaan.
Seperti kata Lutomirsky: βIni tidak menyelesaikan masalah. Jika dua pengguna berbeza menjalankan program bodoh seperti gnupg, mereka hanya akan menguras satu sama lain. Saya melihat bahawa pada masa ini terdapat dua masalah utama dengan /dev/random: ia terdedah kepada DoS (iaitu pengurangan sumber, pengaruh jahat atau sesuatu yang serupa), dan kerana tiada keistimewaan diperlukan untuk menggunakannya, ia juga terdedah kepada penyalahgunaan. Gnupg salah, ia benar-benar runtuh. Jika kami menambah antara muka tidak istimewa baharu yang akan digunakan gnupg dan program serupa, kami akan kalah lagi."
Mueller menyatakan bahawa penambahan getrandom() kini akan membenarkan GnuPG menggunakan antara muka ini, kerana ia akan memberikan jaminan yang diperlukan bahawa kumpulan telah dimulakan. Berdasarkan perbincangan dengan pembangun GnuPG Werner Koch, Mueller percaya bahawa jaminan adalah satu-satunya sebab GnuPG pada masa ini membaca terus dari /dev/random. Tetapi jika terdapat antara muka yang tidak mempunyai hak istimewa yang terdedah kepada penafian perkhidmatan (seperti /dev/random pada hari ini), Lutomirsky berhujah bahawa ia akan disalahgunakan oleh sesetengah aplikasi.
Theodore Yue Tak Ts'o, pembangun subsistem nombor rawak Linux, nampaknya telah mengubah fikirannya tentang keperluan untuk kumpulan penyekat. Dia berkata bahawa mengalih keluar kumpulan ini secara berkesan akan menyingkirkan idea bahawa Linux mempunyai penjana nombor rawak sebenar (TRNG): "ini bukan omong kosong, kerana ini adalah perkara yang selalu dilakukan oleh *BSD."
Beliau juga bimbang bahawa menyediakan mekanisme TRNG hanya akan berfungsi sebagai umpan untuk pembangun aplikasi dan percaya bahawa sebenarnya, memandangkan pelbagai jenis perkakasan yang disokong oleh Linux, adalah mustahil untuk menjamin TRNG dalam kernel. Malah keupayaan untuk bekerja dengan peralatan hanya dengan keistimewaan root tidak akan menyelesaikan masalah: "Pembangun aplikasi menentukan bahawa aplikasi mereka dipasang sebagai akar untuk tujuan keselamatan, supaya ini adalah satu-satunya cara anda boleh mengakses nombor rawak 'sangat bagus'."
Mueller bertanya sama ada Cao telah meninggalkan pelaksanaan kumpulan penyekat yang dia sendiri telah lama mencadangkan. Cao menjawab bahawa dia merancang untuk mengambil tampalan Lutomirsky dan secara aktif menentang penambahan antara muka penyekat kembali ke kernel.
βInti tidak boleh membuat sebarang jaminan sama ada sumber bunyi telah dicirikan dengan betul. Satu-satunya perkara yang boleh diperoleh oleh pembangun GPG atau OpenSSL ialah perasaan samar-samar bahawa TRUERANDOM adalah "lebih baik", dan kerana mereka mahukan lebih keselamatan, mereka pasti akan cuba menggunakannya. Pada satu ketika ia akan disekat, dan apabila beberapa pengguna pintar lain (mungkin pakar pengedaran) memasukkannya ke dalam skrip init dan sistem berhenti berfungsi, pengguna hanya perlu mengadu kepada Linus Torvalds sendiri."
Cao juga menyokong memberi kriptografi dan mereka yang benar-benar memerlukan TRNG cara untuk menuai entropi mereka sendiri dalam ruang pengguna untuk digunakan sebagaimana yang mereka fikirkan patut. Dia mengatakan bahawa mengumpul entropi bukanlah proses yang boleh dilakukan oleh kernel pada semua perkakasan berbeza yang disokongnya, dan juga kernel itu sendiri tidak boleh menganggarkan jumlah entropi yang disediakan oleh sumber yang berbeza.
"Inti tidak seharusnya mencampurkan sumber hingar yang berbeza bersama-sama, dan ia pastinya tidak sepatutnya cuba untuk mendakwa mengetahui berapa banyak bit entropi yang diperolehi apabila ia cuba memainkan sejenis" permainan entropi yang berkedut "pada CPU yang sangat mudah. seni bina untuk pengguna pengguna. Kes IOT/Terbenam di mana semuanya tidak segerak dengan pengayun induk tunggal, di mana tiada arahan CPU untuk menyusun semula atau menamakan semula daftar, dsb.
βAnda boleh bercakap tentang menyediakan alat yang cuba melakukan pengiraan ini, tetapi perkara sedemikian perlu dilakukan pada perkakasan setiap pengguna, yang sememangnya tidak praktikal untuk kebanyakan pengguna pengedaran. Jika ini hanya ditujukan untuk kriptografi, maka biarkan ia dilakukan di ruang pengguna mereka. Dan jangan kita permudahkan GPG, OpenSSL, dsb. supaya semua orang berkata "kami mahukan "keacakan sebenar" dan tidak akan berpuas hati dengan harga yang kurang." Kita boleh bercakap tentang cara kami menyediakan antara muka kepada ahli kriptografi supaya mereka boleh mendapatkan maklumat yang mereka perlukan dengan mengakses sumber hingar utama, dipisahkan dan dinamakan, dan mungkin entah bagaimana sumber hingar itu boleh mengesahkan dirinya ke perpustakaan atau aplikasi ruang pengguna."
Terdapat beberapa perbincangan tentang rupa antara muka sedemikian, kerana sebagai contoh mungkin terdapat implikasi keselamatan untuk beberapa acara. Cao menyatakan bahawa kod imbasan papan kekunci (iaitu ketukan kekunci) dicampurkan ke dalam kumpulan sebagai sebahagian daripada koleksi entropi: "Membawa ini ke dalam ruang pengguna, walaupun melalui panggilan sistem yang istimewa, adalah tidak bijak untuk diperkatakan." Ada kemungkinan bahawa pemasaan acara lain boleh mewujudkan beberapa jenis kebocoran maklumat melalui saluran sampingan.
Oleh itu, nampaknya masalah lama dengan subsistem nombor rawak Linux sedang dalam perjalanan ke penyelesaian. Perubahan yang telah dilalui oleh subsistem nombor rawak baru-baru ini sebenarnya hanya mengakibatkan isu DoS semasa menggunakannya. Kini terdapat cara yang cekap untuk mendapatkan nombor rawak terbaik yang boleh diberikan oleh kernel. Jika TRNG masih diingini pada Linux, maka kecacatan ini perlu diatasi pada masa hadapan, tetapi kemungkinan besar ini tidak akan dilakukan dalam kernel itu sendiri.
Beberapa iklan π
Terima kasih kerana tinggal bersama kami. Adakah anda suka artikel kami? Ingin melihat kandungan yang lebih menarik? Sokong kami dengan membuat pesanan atau mengesyorkan kepada rakan, , analog unik pelayan peringkat permulaan, yang kami cipta untuk anda: (tersedia dengan RAID1 dan RAID10, sehingga 24 teras dan sehingga 40GB DDR4).
Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya disini di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - daripada $99! Baca tentang
Sumber: www.habr.com