/dev/random, generator nomor pseudo-acak (CSPRNG) yang aman secara kriptografis, diketahui memiliki satu masalah yang mengganggu: pemblokiran. Artikel ini menjelaskan bagaimana Anda bisa mengatasinya.
Selama beberapa bulan terakhir, fasilitas pembangkitan angka acak di kernel telah sedikit dikerjakan ulang, namun masalah dalam subsistem ini telah diselesaikan dalam jangka waktu yang lebih luas. . Yang paling dibuat untuk mencegah panggilan sistem getrandom() memblokir dalam waktu lama saat sistem melakukan booting, namun alasan mendasarnya adalah perilaku pemblokiran kumpulan acak. Patch terbaru akan menghapus kumpulan ini dan diharapkan mengarah ke inti utama.
Andy Lutomirski menerbitkan patch versi ketiga pada akhir Desember. Dia berkontribusi "dua perubahan semantik besar pada API Linux acak". Patch menambahkan tanda GRND_INSECURE baru ke panggilan sistem getrandom() (walaupun Lutomirsky menyebutnya sebagai getentropy(), yang diimplementasikan di glibc menggunakan getrandom() dengan tanda tetap); tanda ini menyebabkan panggilan selalu mengembalikan jumlah data yang diminta, tetapi tanpa jaminan bahwa data tersebut acak. Kernel akan melakukan yang terbaik untuk menghasilkan data acak terbaik yang dimilikinya pada waktu tertentu. "Mungkin hal terbaik untuk dilakukan adalah menyebutnya 'TIDAK AMAN'. (tidak aman) untuk mencegah API ini digunakan untuk hal-hal yang memerlukan keamanan."
Tambalan tersebut juga menghapus kumpulan pemblokiran. Kernel saat ini mengelola dua kumpulan data acak, satu sesuai dengan /dev/random dan yang lainnya dengan /dev/urandom, seperti yang dijelaskan dalam ini 2015. Kumpulan pemblokiran adalah kumpulan untuk /dev/random; pembacaan untuk perangkat itu akan diblokir (artinya namanya) hingga entropi "cukup" telah dikumpulkan dari sistem untuk memenuhi permintaan. Pembacaan lebih lanjut dari file ini juga diblokir jika entropi di kumpulan tidak mencukupi.
Menghapus kumpulan kunci berarti membaca dari /dev/random berperilaku seperti getrandom() dengan flag disetel ke nol (dan mengubah flag GRND_RANDOM menjadi noop). Setelah generator nomor acak kriptografi (CRNG) diinisialisasi, pembacaan dari /dev/random dan panggilan ke getrandom(...,0) tidak akan memblokir dan akan mengembalikan jumlah data acak yang diminta.
Lutomirsky berkata: “Saya yakin kumpulan pemblokiran Linux sudah ketinggalan zaman. CRNG Linux menghasilkan keluaran yang cukup baik bahkan untuk digunakan untuk pembuatan kunci. Kelompok pemblokiran tidak lebih kuat secara material dan membutuhkan banyak infrastruktur dengan nilai yang meragukan untuk mendukungnya.”
Perubahan ini dilakukan dengan tujuan untuk memastikan bahwa program yang ada tidak terlalu terpengaruh, dan faktanya, akan ada lebih sedikit masalah karena penantian yang lama untuk hal-hal seperti pembuatan kunci GnuPG.
“Episode ini tidak boleh mengganggu program yang sudah ada. /dev/urandom tetap tidak berubah. /dev/random masih memblokir segera setelah boot, tetapi memblokir lebih sedikit dari sebelumnya. getentropy() dengan flag yang ada akan mengembalikan hasil yang sesuai untuk tujuan praktis seperti sebelumnya."
Lutomirsky mencatat bahwa masih menjadi pertanyaan terbuka apakah kernel harus menyediakan apa yang disebut “angka acak yang sebenarnya,” yang merupakan apa yang seharusnya dilakukan oleh kernel pemblokiran sampai batas tertentu. Ia hanya melihat satu alasan untuk hal ini: “kepatuhan terhadap standar pemerintah.” Lutomirsky menyarankan bahwa jika kernel menyediakan ini, itu harus dilakukan melalui antarmuka yang benar-benar berbeda, atau harus dipindahkan ke ruang pengguna, memungkinkan pengguna untuk mengambil sampel kejadian mentah yang dapat digunakan untuk membuat kumpulan kunci tersebut.
Stephan Müller menyarankan setnya untuk Linux Random Number Generator (LRNG) (saat ini versi 26 dirilis) bisa menjadi cara untuk memberikan nomor acak yang sebenarnya untuk aplikasi yang membutuhkannya. LRNG “sepenuhnya mematuhi Pedoman SP800-90B tentang Sumber Entropi yang Digunakan untuk Menghasilkan Bit Acak,” menjadikannya solusi terhadap masalah standar pemerintah.
Matthew Garrett keberatan dengan istilah “data acak yang sebenarnya”, dan menyatakan bahwa perangkat yang diambil sampelnya pada prinsipnya dapat dimodelkan dengan cukup tepat agar dapat diprediksi: “kami tidak mengambil sampel peristiwa kuantum di sini.”
Müller menjawab bahwa istilah tersebut berasal dari standar Jerman AIS 31 untuk menggambarkan generator bilangan acak yang hanya menghasilkan hasil "pada tingkat yang sama dengan sumber kebisingan yang mendasari menghasilkan entropi."
Terlepas dari perbedaan terminologi, memiliki kumpulan kunci seperti yang disarankan oleh patch LRNG hanya akan menimbulkan berbagai masalah, setidaknya jika diakses tanpa hak istimewa.
Seperti yang dikatakan Lutomirsky: “Ini tidak menyelesaikan masalah. Jika dua pengguna berbeda menjalankan program bodoh seperti gnupg, mereka hanya akan saling menguras tenaga. Saya melihat bahwa saat ini ada dua masalah utama dengan /dev/random: rentan terhadap DoS (yaitu penipisan sumber daya, pengaruh jahat, atau sejenisnya), dan karena tidak diperlukan hak istimewa untuk menggunakannya, ia juga rentan terhadap penyalahgunaan. Gnupg salah, ini benar-benar runtuh. Jika kita menambahkan antarmuka baru tanpa hak istimewa yang akan digunakan oleh gnupg dan program serupa, kita akan kalah lagi."
Mueller mencatat bahwa penambahan getrandom() sekarang akan memungkinkan GnuPG untuk menggunakan antarmuka ini, karena ini akan memberikan jaminan yang diperlukan bahwa kumpulan telah diinisialisasi. Berdasarkan diskusi dengan pengembang GnuPG Werner Koch, Mueller yakin bahwa jaminan tersebut adalah satu-satunya alasan GnuPG saat ini membaca langsung dari /dev/random. Namun jika ada antarmuka tanpa hak istimewa yang rentan terhadap penolakan layanan (seperti /dev/random saat ini), Lutomirsky berpendapat bahwa itu akan disalahgunakan oleh beberapa aplikasi.
Theodore Yue Tak Ts'o, pengembang subsistem nomor acak Linux, tampaknya telah berubah pikiran tentang perlunya kumpulan pemblokiran. Dia mengatakan bahwa menghapus kumpulan ini akan secara efektif menghilangkan gagasan bahwa Linux memiliki generator bilangan acak yang sebenarnya (TRNG): "ini bukan omong kosong, karena inilah yang selalu dilakukan *BSD."
Dia juga khawatir bahwa menyediakan mekanisme TRNG hanya akan menjadi umpan bagi pengembang aplikasi dan percaya bahwa pada kenyataannya, mengingat berbagai jenis perangkat keras yang didukung oleh Linux, tidak mungkin untuk menjamin TRNG di kernel. Bahkan kemampuan untuk bekerja dengan peralatan hanya dengan hak akses root tidak akan menyelesaikan masalah: "Pengembang aplikasi menetapkan bahwa aplikasi mereka diinstal sebagai root untuk tujuan keamanan, sehingga ini adalah satu-satunya cara Anda dapat mengakses nomor acak yang 'sangat bagus'."
Mueller bertanya apakah Cao Cao telah meninggalkan penerapan kelompok pemblokiran yang telah lama diusulkannya sendiri. Cao menjawab bahwa dia berencana untuk mengambil patch Lutomirsky dan secara aktif menentang penambahan antarmuka pemblokiran kembali ke kernel.
“Kernel tidak dapat menjamin apakah sumber kebisingan telah dikarakterisasi dengan benar. Satu-satunya hal yang bisa didapat oleh pengembang GPG atau OpenSSL adalah perasaan samar bahwa TRUERANDOM "lebih baik", dan karena mereka menginginkan keamanan lebih, mereka pasti akan mencoba menggunakannya. Pada titik tertentu sistem ini akan diblokir, dan ketika beberapa pengguna pintar lainnya (mungkin spesialis distribusi) memasukkannya ke dalam skrip init dan sistem berhenti bekerja, pengguna hanya perlu mengajukan keluhan kepada Linus Torvalds sendiri."
Cao juga menganjurkan untuk memberikan para kriptografer dan mereka yang benar-benar membutuhkan TRNG cara untuk memanen entropi mereka sendiri di ruang pengguna untuk digunakan sesuai keinginan mereka. Dia mengatakan bahwa mengumpulkan entropi bukanlah proses yang dapat dilakukan oleh kernel pada semua perangkat keras berbeda yang didukungnya, dan kernel juga tidak dapat memperkirakan jumlah entropi yang disediakan oleh sumber berbeda.
“Kernel tidak boleh mencampurkan sumber kebisingan yang berbeda, dan tentu saja tidak boleh mengklaim mengetahui berapa banyak bit entropi yang didapat ketika mencoba memainkan semacam “permainan entropi yang gelisah” pada CPU yang sangat sederhana. arsitektur untuk pengguna konsumen. Kasus IOT/Embedded di mana semuanya tidak sinkron dengan satu osilator master, di mana tidak ada instruksi CPU untuk menyusun ulang atau mengganti nama register, dll.”
“Anda dapat berbicara tentang menyediakan alat yang mencoba melakukan penghitungan ini, namun hal seperti itu harus dilakukan pada perangkat keras setiap pengguna, yang tidak praktis bagi sebagian besar pengguna distribusi. Jika ini hanya ditujukan untuk kriptografer, biarkan hal itu dilakukan di ruang pengguna mereka. Dan jangan menyederhanakan GPG, OpenSSL, dll. sehingga semua orang mengatakan "kami menginginkan "keacakan yang sebenarnya" dan tidak akan menerima yang lebih sedikit." Kita dapat berbicara tentang bagaimana kami menyediakan antarmuka kepada kriptografer sehingga mereka bisa mendapatkan informasi yang mereka perlukan dengan mengakses sumber kebisingan utama, dipisahkan dan diberi nama, dan mungkin entah bagaimana sumber kebisingan dapat mengautentikasi dirinya ke perpustakaan atau aplikasi ruang pengguna."
Ada beberapa diskusi tentang seperti apa tampilan antarmuka tersebut, karena misalnya mungkin ada implikasi keamanan untuk beberapa kejadian. Cao mencatat bahwa kode pemindaian keyboard (yaitu penekanan tombol) dicampur ke dalam kumpulan sebagai bagian dari pengumpulan entropi: "Membawa ini ke ruang pengguna, bahkan melalui panggilan sistem yang memiliki hak istimewa, setidaknya tidak bijaksana." Sangat mungkin bahwa waktu kejadian lain dapat menyebabkan kebocoran informasi melalui saluran sampingan.
Jadi sepertinya masalah lama pada subsistem nomor acak Linux sedang menuju solusi. Perubahan yang dialami subsistem bilangan acak akhir-akhir ini sebenarnya hanya mengakibatkan masalah DoS saat menggunakannya. Sekarang ada cara efisien untuk mendapatkan nomor acak terbaik yang bisa disediakan oleh kernel. Jika TRNG masih diinginkan di Linux, maka kelemahan ini perlu diatasi di masa mendatang, tetapi kemungkinan besar hal ini tidak akan dilakukan di dalam kernel itu sendiri.
Beberapa iklan 🙂
Terima kasih untuk tetap bersama kami. Apakah Anda menyukai artikel kami? Ingin melihat konten yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman, , analog unik dari server level awal, yang kami temukan untuk Anda: (tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2x 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 - mulai $99! Membaca tentang
Sumber: www.habr.com