Ang /dev/random, isang cryptographically secure na pseudo-random number generator (CSPRNG), ay kilala na may isang nakakainis na problema: pagharang. Ipinapaliwanag ng artikulong ito kung paano mo ito malulutas.
Sa nakalipas na ilang buwan, ang mga pasilidad sa pagbuo ng random na numero sa kernel ay bahagyang na-rework, ngunit ang mga problema sa subsystem na ito ay nalutas sa panahon ng mas malawak na . Ang pinaka ay ginawa upang pigilan ang getrandom() system call mula sa pagharang ng mahabang panahon kapag nag-boot ang system, ngunit ang pinagbabatayan nito ay ang pag-block ng pag-uugali ng random na pool. Aalisin sana ng isang kamakailang patch ang pool na ito at inaasahang pupunta ito sa pangunahing core.
Inilathala ni Andy Lutomirski ang ikatlong bersyon ng patch sa katapusan ng Disyembre. Nagtatampo siya "dalawang pangunahing pagbabago sa semantiko sa mga random na Linux API". Ang patch ay nagdaragdag ng bagong GRND_INSECURE flag sa getrandom() system call (bagama't tinutukoy ito ni Lutomirsky bilang getentropy(), na ipinapatupad sa glibc gamit ang getrandom() na may mga nakapirming flag); ang flag na ito ay nagiging sanhi ng tawag na palaging ibalik ang dami ng data na hiniling, ngunit hindi ginagarantiyahan na ang data ay random. Gagawin lamang ng kernel ang lahat ng makakaya upang makagawa ng pinakamahusay na random na data na mayroon ito sa ibinigay na oras. "Marahil ang pinakamagandang gawin ay tawagin itong 'INSECURE' (hindi sigurado) upang maiwasan ang API na ito na gamitin para sa mga bagay na nangangailangan ng seguridad."
Tinatanggal din ng mga patch ang nakaharang na pool. Ang kernel ay kasalukuyang nagpapanatili ng dalawang random na data pool, ang isa ay tumutugma sa /dev/random at ang isa sa /dev/urandom, tulad ng inilarawan dito 2015. Ang nakaharang na pool ay ang pool para sa /dev/random; reads para sa device na iyon ay haharangin (ibig sabihin ang pangalan nito) hanggang sa "sapat" na entropy ay nakolekta mula sa system upang matugunan ang kahilingan. Ang mga karagdagang pagbabasa mula sa file na ito ay hinaharangan din kung walang sapat na entropy sa pool.
Ang pag-alis sa lock pool ay nangangahulugan na ang pagbabasa mula sa /dev/random ay kumikilos tulad ng getrandom() na may mga flag na nakatakda sa zero (at ginagawang noop ang flag ng GRND_RANDOM). Kapag nasimulan na ang cryptographic random number generator (CRNG), ang pagbabasa mula sa /dev/random at mga tawag sa getrandom(...,0) ay hindi haharang at ibabalik ang hiniling na dami ng random na data.
Sinabi ni Lutomirsky: βNaniniwala ako na ang Linux blocking pool ay naging lipas na. Ang CRNG Linux ay bumubuo ng output na sapat na mabuti upang magamit kahit para sa pagbuo ng pangunahing. Ang blocking pool ay hindi mas malakas sa anumang materyal na kahulugan at nangangailangan ng maraming imprastraktura ng kahina-hinalang halaga upang suportahan ito."
Ginawa ang mga pagbabago sa layuning matiyak na hindi talaga maaapektuhan ang mga kasalukuyang programa, at sa katunayan, magkakaroon ng mas kaunting mga problema sa mahabang paghihintay para sa mga bagay tulad ng pagbuo ng key ng GnuPG.
"Ang mga episode na ito ay hindi dapat makagambala sa anumang mga kasalukuyang programa. Ang /dev/urandom ay nananatiling hindi nagbabago. Ang /dev/random ay naka-block pa rin kaagad sa pag-boot, ngunit mas mababa ito kaysa dati. getentropy() na may mga umiiral nang flag ay magbabalik ng resulta na angkop din para sa mga praktikal na layunin tulad ng dati."
Nabanggit ni Lutomirsky na bukas pa rin ang tanong kung ang kernel ay dapat magbigay ng tinatawag na "true random numbers," na kung ano ang dapat gawin ng blocking kernel sa isang tiyak na lawak. Isa lang ang nakikita niyang dahilan para dito: "pagsunod sa mga pamantayan ng gobyerno." Iminungkahi ni Lutomirsky na kung ibibigay ito ng kernel, dapat itong gawin sa pamamagitan ng isang ganap na naiibang interface, o dapat itong ilipat sa espasyo ng gumagamit, na nagpapahintulot sa gumagamit na makuha ang mga hilaw na sample ng kaganapan na maaaring magamit upang lumikha ng naturang lock pool.
Iminungkahi ni Stephan MΓΌller na ang kanyang set para sa Linux Random Number Generator (LRNG) (kasalukuyang bersyon 26 na inilabas) ay maaaring isang paraan upang magbigay ng totoong random na numero para sa mga application na nangangailangan nito. Ang LRNG ay βganap na sumusunod sa SP800-90B Guidelines on Entropy Sources Used to Generate Random Bits,β na ginagawa itong solusyon sa problema sa pamantayan ng gobyerno.
Tinutulan ni Matthew Garrett ang terminong "true random data," na binanggit na ang mga device na na-sample sa prinsipyo ay maaaring ma-modelo nang tumpak para maging predictable ang mga ito: "hindi kami nagsa-sample ng mga quantum event dito."
Tumugon si MΓΌller na ang termino ay nagmula sa German standard na AIS 31 upang ilarawan ang isang random na generator ng numero na gumagawa lamang ng isang resulta "sa parehong rate na ang pinagmumulan ng ingay ay gumagawa ng entropy."
Bukod sa mga pagkakaiba ng terminolohiya, ang pagkakaroon ng lock pool gaya ng iminumungkahi ng mga patch ng LRNG ay hahantong lamang sa iba't ibang problema, kahit man lang kung ma-access ito nang walang mga pribilehiyo.
Tulad ng sinabi ni Lutomirsky: βHindi nito malulutas ang problema. Kung ang dalawang magkaibang mga gumagamit ay nagpapatakbo ng mga hangal na programa tulad ng gnupg, sila ay mag-drain lamang sa isa't isa. Nakikita ko na kasalukuyang may dalawang pangunahing problema sa /dev/random: ito ay madaling kapitan ng DoS (ibig sabihin, pagkaubos ng mapagkukunan, malisyosong impluwensya o katulad na bagay), at dahil walang kinakailangang mga pribilehiyo para magamit ito, ito ay madaling abusuhin. Mali ang Gnupg, ito ay isang kumpletong pagbagsak. Kung magdadagdag kami ng bagong unprivileged interface na gagamitin ng gnupg at mga katulad na program, mawawala ulit kami."
Nabanggit ni Mueller na ang pagdaragdag ng getrandom() ay magbibigay-daan na ngayon sa GnuPG na gamitin ang interface na ito, dahil magbibigay ito ng kinakailangang garantiya na ang pool ay nasimulan na. Batay sa mga talakayan sa developer ng GnuPG na si Werner Koch, naniniwala si Mueller na ang garantiya ang tanging dahilan kung bakit direktang nagbabasa ang GnuPG mula sa /dev/random. Ngunit kung mayroong isang unprivileged interface na madaling kapitan sa pagtanggi ng serbisyo (tulad ng /dev/random ay ngayon), Lutomirsky argues na ito ay maling gamitin ng ilang mga application.
Si Theodore Yue Tak Ts'o, developer ng random number subsystem ng Linux, ay lumilitaw na nagbago ng kanyang isip tungkol sa pangangailangan para sa isang blocking pool. Sinabi niya na ang pag-alis sa pool na ito ay epektibong mapupuksa ang ideya na ang Linux ay may tunay na random number generator (TRNG): "Hindi ito katarantaduhan, dahil ito ang palaging ginagawa ni *BSD."
Nababahala din siya na ang pagbibigay ng mekanismo ng TRNG ay magsisilbi lamang na pain para sa mga developer ng application at naniniwala na sa katunayan, dahil sa iba't ibang uri ng hardware na sinusuportahan ng Linux, imposibleng magarantiya ang TRNG sa kernel. Kahit na ang kakayahang magtrabaho kasama ang kagamitan lamang na may mga pribilehiyo sa ugat ay hindi malulutas ang problema: "Tumukoy ang mga developer ng application na naka-install ang kanilang application bilang root para sa mga layuning pangseguridad, upang ito ang tanging paraan upang ma-access mo ang 'talagang magandang' random na mga numero."
Tinanong ni Mueller kung tinalikuran na ni Cao ang pagpapatupad ng blocking pool na siya mismo ay matagal nang iminungkahi. Tumugon si Cao na plano niyang kunin ang mga patch ni Lutomirsky at aktibong tinututulan ang pagdaragdag ng interface ng pagharang pabalik sa kernel.
"Ang kernel ay hindi maaaring gumawa ng anumang mga garantiya kung ang pinagmumulan ng ingay ay wastong nailalarawan. Ang tanging makukuha ng isang developer ng GPG o OpenSSL ay isang malabong pakiramdam na ang TRUERANDOM ay "mas mahusay", at dahil gusto nila ng higit pang seguridad, walang alinlangan na susubukan nilang gamitin ito. Sa ilang mga punto ay mai-block ito, at kapag ang ilang iba pang matalinong gumagamit (marahil isang espesyalista sa pamamahagi) ay nagpasok nito sa init script at ang mga system ay tumigil sa paggana, ang mga gumagamit ay kakailanganin lamang magreklamo sa Linus Torvalds mismo.
Itinataguyod din ni Cao ang pagbibigay sa mga cryptographer at sa mga talagang nangangailangan ng TRNG ng isang paraan upang makuha ang kanilang sariling entropy sa espasyo ng gumagamit upang magamit ayon sa nakikita nilang angkop. Sinabi niya na ang pagkolekta ng entropy ay hindi isang proseso na maaaring gawin ng kernel sa lahat ng iba't ibang hardware na sinusuportahan nito, at hindi rin matantya ng kernel mismo ang dami ng entropy na ibinigay ng iba't ibang mga mapagkukunan.
"Ang kernel ay hindi dapat pinagsasama-sama ang iba't ibang mga pinagmumulan ng ingay, at tiyak na hindi ito dapat subukang i-claim na malaman kung gaano karaming mga piraso ng entropy ang nakukuha nito kapag sinusubukan nitong maglaro ng ilang uri ng "twitchy entropy game" sa isang napakasimpleng CPU architecture para sa mga user ng consumer. IOT/Embedded na mga kaso kung saan ang lahat ay hindi naka-sync sa isang master oscillator, kung saan walang tagubilin sa CPU na muling ayusin o palitan ang pangalan ng isang rehistro, atbp."
βMaaari mong pag-usapan ang pagbibigay ng mga tool na sumusubok na gawin ang mga kalkulasyong ito, ngunit ang mga bagay na ito ay kailangang gawin sa hardware ng bawat user, na sadyang hindi praktikal para sa karamihan ng mga gumagamit ng pamamahagi. Kung para lang ito sa mga cryptographer, hayaan itong gawin sa kanilang user space. At huwag nating pasimplehin ang GPG, OpenSSL, atbp. para sabihin ng lahat na "gusto natin ang "tunay na randomness" at hindi na mag-settle ng mas kaunti." Maaari naming pag-usapan kung paano kami nagbibigay ng mga interface sa mga cryptographer upang makuha nila ang impormasyong kailangan nila sa pamamagitan ng pag-access sa mga pangunahing pinagmumulan ng ingay, na pinaghihiwalay at pinangalanan, at marahil kahit papaano ay maaaring mapatunayan ng pinagmumulan ng ingay ang sarili nito sa isang library o application ng espasyo ng gumagamit."
Nagkaroon ng ilang talakayan tungkol sa kung ano ang maaaring hitsura ng naturang interface, dahil halimbawa ay maaaring may mga implikasyon sa seguridad para sa ilang mga kaganapan. Sinabi ni Cao na ang mga keyboard scan code (i.e. mga keystroke) ay pinaghalo sa isang pool bilang bahagi ng entropy collection: "Ang pagdadala nito sa espasyo ng user, kahit na sa pamamagitan ng isang privileged system call, ay hindi magandang sabihin." Posible na ang ibang mga timing ng kaganapan ay maaaring lumikha ng ilang uri ng pagtagas ng impormasyon sa pamamagitan ng mga side channel.
Kaya mukhang isang matagal nang problema sa random number subsystem ng Linux ay patungo sa isang solusyon. Ang mga pagbabagong pinagdaanan ng random number subsystem kamakailan ay talagang nagresulta lamang sa mga isyu sa DoS habang ginagamit ito. Ngayon ay may mga mahusay na paraan upang makuha ang pinakamahusay na mga random na numero na maibibigay ng kernel. Kung ang TRNG ay kanais-nais pa rin sa Linux, ang kapintasan na ito ay kailangang matugunan sa hinaharap, ngunit malamang na hindi ito gagawin sa loob mismo ng kernel.
Ilang ad π
Salamat sa pananatili sa amin. Gusto mo ba ang aming mga artikulo? Gustong makakita ng mas kawili-wiling nilalaman? Suportahan kami sa pamamagitan ng pag-order o pagrekomenda sa mga kaibigan, , isang natatanging analogue ng mga entry-level na server, na inimbento namin para sa iyo: (magagamit sa RAID1 at RAID10, hanggang 24 na core at hanggang 40GB DDR4).
Dell R730xd 2x na mas mura sa Equinix Tier IV data center sa Amsterdam? Dito lang sa Netherlands! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - mula $99! Basahin ang tungkol sa
Pinagmulan: www.habr.com