Seperti yang Anda ketahui, / dev / random, generator nomor acak pseudo kriptografi (CSPRNG) yang kuat secara kriptografis, memiliki satu masalah - pemblokiran yang tidak menyenangkan. Artikel ini menjelaskan cara menyelesaikannya.
Selama beberapa bulan terakhir, cara menghasilkan angka acak di kernel telah sedikit dikerjakan ulang, tetapi masalah dalam subsistem ini telah diselesaikan dalam
kerangka waktu yang lebih luas.
Perubahan terbaru dibuat untuk mencegah panggilan sistem getrandom () diblokir untuk waktu yang lama selama boot sistem, tetapi alasan di balik ini adalah perilaku pemblokiran kelompok acak. Tambalan baru-baru ini akan menghapus kumpulan ini, dan diharapkan akan menuju inti utama.
Andy Lutomirski merilis versi ketiga tambalan pada akhir Desember. Itu membuat
"dua perubahan semantik dasar untuk API Linux acak .
" Patch menambahkan flag GRND_INSECURE baru ke system call getrandom () (walaupun Lutomirsky menyebutnya sebagai getentropy (), yang diimplementasikan dalam glibc menggunakan getrandom () dengan flag tetap); tanda ini memaksa panggilan untuk selalu mengembalikan jumlah data yang diminta, tetapi tanpa menjamin bahwa data tersebut acak. Kernel hanya akan melakukan yang terbaik untuk memberikan data acak terbaik yang dimilikinya pada waktu tertentu.
"Mungkin hal terbaik yang dapat Anda lakukan adalah menyebutnya" INSECURE " (tidak aman) untuk mencegahnya digunakan untuk hal-hal yang membutuhkan keamanan."
Tambalan juga menghapus kolam pemblokiran. Saat ini, kernel mendukung dua kumpulan data acak, salah satunya sesuai dengan / dev / acak, dan yang lainnya untuk / dev / urandom, seperti yang dijelaskan dalam
artikel 2015
ini . Blocking pool adalah pool untuk / dev / random; pembacaan untuk perangkat ini akan diblokir (artinya namanya) sampai entropi “cukup” dikumpulkan dari sistem untuk memenuhi permintaan. Bacaan lebih lanjut dari file ini juga diblokir jika tidak ada cukup entropi di kumpulan.
Menghapus kumpulan kunci berarti bahwa membaca dari / dev / acak berperilaku seperti getrandom () dengan nilai flag yang disetel ke nol (dan mengubah flag GRND_RANDOM menjadi noop). Setelah menginisialisasi generator nomor acak kriptografis (CRNG), membaca dari / dev / random dan memanggil getrandom (..., 0) tidak akan memblokir dan mengembalikan jumlah data acak yang diminta.
Lutomirsky mengatakan:
“Saya percaya pool blocking Linux telah menjadi usang. CRNG Linux menghasilkan output yang cukup baik untuk digunakan bahkan untuk generasi kunci. Blocking pool tidak lebih kuat dalam arti materi, dan itu membutuhkan banyak infrastruktur yang nilai meragukan untuk mempertahankannya. "Perubahan dilakukan dengan tujuan untuk memastikan bahwa program yang ada tidak menderita, dan pada kenyataannya, masalah dengan menunggu lama untuk hal-hal seperti menghasilkan kunci GnuPG akan menjadi lebih kecil.
“Seri ini seharusnya tidak melanggar program yang ada. / dev / urandom tetap tidak berubah. / dev / random masih memblokir segera setelah memuat, tetapi itu memblokir kurang dari sebelumnya. getentropy () dengan flag yang ada akan mengembalikan hasil yang akan sama praktisnya dengan tujuan seperti sebelumnya. "Lutomirsky mencatat bahwa pertanyaannya tetap terbuka apakah inti harus menyediakan apa yang disebut "angka acak sejati", yang sampai batas tertentu seharusnya dilakukan oleh inti pemblokiran. Dia hanya melihat satu alasan untuk ini: "kepatuhan dengan standar negara." Lutomirsky menyarankan bahwa jika kernel harus menyediakan ini, itu harus dilakukan melalui antarmuka yang sama sekali berbeda atau harus ditransfer ke ruang pengguna, memungkinkan dia untuk mengambil pola acara yang tidak diproses yang dapat digunakan untuk membuat kumpulan kunci seperti itu.
Stephan Müller menyarankan bahwa
tambalannya ditetapkan untuk penghasil angka acak Linux (LRNG) (versi 26 saat ini dirilis) mungkin menjadi cara untuk memberikan angka acak yang benar untuk aplikasi yang membutuhkannya. LRNG "sepenuhnya mematuhi persyaratan" Rekomendasi tentang sumber entropi yang digunakan untuk menghasilkan bit acak "SP800-90B", yang menjadikannya solusi untuk masalah standar negara.
Matthew Garrett keberatan dengan istilah "data acak sejati," mencatat bahwa perangkat yang dipilih, pada prinsipnya, dapat dimodelkan secara cukup akurat sehingga dapat diprediksi: "kita tidak mengambil peristiwa kuantum di sini."
Muller menjawab bahwa istilah tersebut berasal dari standar Jerman AIS 31 untuk menggambarkan generator angka acak yang hanya menghasilkan hasil "pada kecepatan yang sama dengan sumber kebisingan yang mendasari menghasilkan entropi".
Selain kesalahpahaman terminologi, kehadiran kumpulan kunci, seperti yang disarankan oleh patch LRNG, hanya akan menyebabkan berbagai masalah, setidaknya jika tersedia tanpa hak istimewa.
Seperti yang dikatakan Lutomirsky:
"Ini tidak menyelesaikan masalah. Jika dua pengguna berbeda menjalankan program bodoh seperti gnupg, mereka hanya saling melelahkan. Saya melihat bahwa saat ini ada dua masalah utama dengan / dev / random: ia rentan terhadap DoS (mis., Penipisan sumber daya, pengaruh berbahaya, atau sesuatu yang serupa), dan karena tidak memerlukan hak istimewa untuk menggunakannya, ia juga dapat disalahgunakan. Gnupg salah, itu adalah keruntuhan total. Jika kita menambahkan antarmuka unprivileged baru yang akan digunakan gnupg dan program serupa, kita akan kehilangan lagi. "Muller mencatat bahwa menambahkan getrandom () sekarang akan memungkinkan GnuPG untuk menggunakan antarmuka ini, karena itu akan memberikan jaminan yang diperlukan bahwa kumpulan telah diinisialisasi. Berdasarkan diskusi dengan pengembang GnuPG Werner Koch, Muller percaya bahwa garansi adalah satu-satunya alasan GnuPG saat ini membaca langsung dari / dev / random. Tetapi jika ada antarmuka yang tidak terjangkau yang tunduk pada penolakan layanan (seperti hari ini / dev / acak), maka menurut Lutomirsky, itu akan disalahgunakan oleh beberapa aplikasi.
Theodore Yue Tak Ts'o, pengembang subsistem nomor acak Linux, tampaknya telah berubah pikiran tentang perlunya kolam pemblokiran. Dia mengatakan bahwa menghapus kumpulan ini akan secara efektif menghilangkan gagasan bahwa Linux memiliki generator nomor acak yang sebenarnya (TRNG):
"ini bukan omong kosong, karena ini adalah persis seperti yang selalu dilakukan * BSD."Dia juga khawatir bahwa menyediakan mekanisme TRNG hanya akan berfungsi sebagai umpan bagi pengembang aplikasi dan percaya bahwa pada kenyataannya, mengingat berbagai jenis perangkat keras yang didukung oleh Linux, tidak mungkin untuk menjamin TRNG dalam kernel. Bahkan kemampuan untuk bekerja dengan peralatan berdasarkan hak akses root tidak akan menyelesaikan masalah:
"Pengembang aplikasi menentukan bahwa aplikasi mereka diinstal sebagai root untuk alasan keamanan, karena ini adalah satu-satunya cara Anda dapat mengakses nomor acak" sangat bagus "."Muller bertanya apakah Cao menolak menerapkan kolam pemblokiran, yang sudah lama ia usulkan. Cao menjawab bahwa ia berencana untuk mengambil tambalan Lutomirsky dan secara aktif keberatan untuk menambahkan antarmuka pemblokiran kembali ke kernel.
“Kernel tidak dapat memberikan jaminan apakah sumber kebisingan telah ditandai dengan benar. Satu-satunya hal yang bisa didapatkan oleh pengembang GPG atau OpenSSL adalah perasaan samar bahwa TRUERANDOM adalah "lebih baik," dan karena mereka menginginkan lebih banyak keamanan, mereka pasti akan mencoba menggunakannya. Pada titik tertentu, itu akan diblokir, dan ketika beberapa pengguna pintar lainnya (mungkin spesialis distribusi) memasukkannya ke dalam skrip init dan sistem berhenti bekerja, pengguna hanya perlu mengeluh kepada Linus Torvalds sendiri. ”Cao juga mengadvokasi menyediakan cryptographers dan mereka yang benar-benar membutuhkan TRNG dengan cara untuk mengumpulkan entropi mereka sendiri di ruang pengguna sehingga mereka dapat menggunakannya sesuai keinginan mereka. Dia mengatakan bahwa pengumpulan entropi bukanlah proses yang dapat dilakukan oleh kernel pada semua jenis perangkat keras yang didukungnya, di samping itu, kernel itu sendiri tidak dapat memperkirakan jumlah entropi yang disediakan oleh berbagai sumber.
"Kernel seharusnya tidak mencampur sumber suara yang berbeda bersama-sama, dan tentu saja, tidak boleh mencoba untuk mengklaim bahwa ia tahu berapa banyak bit entropi yang diterimanya ketika mencoba untuk memainkan semacam" permainan entropi "pada arsitektur CPU yang sederhana untuk pengguna yang jelek. "Kasus IOT / Tertanam, ketika semuanya tidak sinkron dengan generator master tunggal, ketika tidak ada instruksi CPU untuk memesan ulang atau mengganti nama register, dll."
“Kita dapat berbicara tentang menyediakan alat yang mencoba membuat perhitungan ini, tetapi hal-hal seperti itu harus dilakukan pada peralatan masing-masing pengguna, yang bagi sebagian besar pengguna kit distribusi tidak praktis. Jika ini hanya ditujukan untuk cryptographers, maka biarkan dilakukan di ruang pengguna mereka. Dan jangan menyederhanakan GPG, OpenSSL, dll., Sehingga semua orang mengatakan: "kami ingin" keacakan yang sebenarnya "dan jangan menyetujui apa pun yang kurang." Kami dapat berbicara tentang bagaimana kami menyediakan antarmuka untuk kriptografer sehingga mereka bisa mendapatkan informasi yang diperlukan melalui akses ke sumber kebisingan primer, dipisahkan dan dinamai, dan, mungkin, entah bagaimana sumber suara dapat mengotentikasi dirinya sendiri di perpustakaan atau aplikasi ruang pengguna. "Ada sedikit diskusi tentang bagaimana tampilan antarmuka seperti itu, karena, misalnya, untuk beberapa acara mungkin ada implikasi keamanan. Cao mencatat bahwa kode pemindaian keyboard (yaitu, penekanan tombol) dicampur ke dalam kumpulan sebagai bagian dari koleksi entropi: "Mentransfer ini ke ruang pengguna, bahkan melalui sistem panggilan istimewa, setidaknya akan tidak masuk akal." Mungkin saja timing acara lainnya dapat membuat semacam kebocoran informasi melalui saluran samping.
Dengan demikian, ada perasaan bahwa masalah lama dari subsistem nomor acak Linux sedang menuju solusi. Perubahan yang telah dilakukan oleh subsistem angka acak baru-baru ini, pada kenyataannya, hanya menyebabkan masalah DoS dalam proses penggunaannya. Sekarang ada cara efektif untuk mendapatkan angka acak terbaik yang dapat disediakan oleh kernel. Jika TRNG masih diinginkan untuk Linux, maka kekurangan ini perlu ditangani di masa depan, tetapi kemungkinan besar itu tidak akan dilakukan di dalam kernel itu sendiri.
Sedikit iklan :)
Terima kasih telah tinggal bersama kami. Apakah Anda suka artikel kami? Ingin melihat materi yang lebih menarik? Dukung kami dengan melakukan pemesanan atau merekomendasikan kepada teman Anda,
VPS berbasis cloud untuk pengembang mulai $ 4,99 ,
analog unik dari server entry-level yang diciptakan oleh kami untuk Anda: Seluruh kebenaran tentang VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps mulai dari $ 19 atau cara membagi server? (opsi tersedia dengan RAID1 dan RAID10, hingga 24 core dan hingga 40GB DDR4).
Dell R730xd 2 kali lebih murah di pusat data Equinix Tier IV di Amsterdam? Hanya kami yang memiliki
2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV dari $ 199 di Belanda! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mulai dari $ 99! Baca tentang
Cara Membangun Infrastruktur Bldg. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?