លីនុច៖ លុបអាងចាក់សោ /dev/random

/dev/random ដែលជាម៉ាស៊ីនបង្កើតលេខ pseudo-random សុវត្ថិភាពសម្ងាត់ (CSPRNG) ត្រូវបានគេដឹងថាមានបញ្ហារំខានមួយ៖ ការទប់ស្កាត់។ អត្ថបទនេះពន្យល់ពីរបៀបដែលអ្នកអាចដោះស្រាយវាបាន។

ក្នុងរយៈពេលប៉ុន្មានខែកន្លងមកនេះ ឧបករណ៍បង្កើតលេខចៃដន្យនៅក្នុងខឺណែលត្រូវបានដំណើរការឡើងវិញបន្តិច ប៉ុន្តែបញ្ហានៅក្នុងប្រព័ន្ធរងនេះត្រូវបានដោះស្រាយក្នុងរយៈពេលកាន់តែទូលំទូលាយ។ ស៊ុមពេលវេលា. ច្រើនបំផុត ការផ្លាស់ប្តូរចុងក្រោយ ត្រូវ​បាន​បង្កើត​ឡើង​ដើម្បី​ការពារ​ការ​ហៅ​ប្រព័ន្ធ getrandom() ពី​ការ​ទប់ស្កាត់​ជា​យូរ​មក​ហើយ​នៅ​ពេល​ដែល​ប្រព័ន្ធ​ចាប់ផ្ដើម ប៉ុន្តែ​ហេតុផល​មូលដ្ឋាន​សម្រាប់​ការ​នេះ​គឺ​ការ​រារាំង​នៃ​ក្រុម​ចៃដន្យ។ បំណះថ្មីមួយនឹងដកចេញអាងនេះ ហើយវាត្រូវបានគេរំពឹងថានឹងឆ្ពោះទៅរកស្នូលសំខាន់។

Andy Lutomirski បានបោះពុម្ពកំណែទីបីនៃបំណះនៅចុងខែធ្នូ។ គាត់រួមចំណែក "ការផ្លាស់ប្តូរអត្ថន័យសំខាន់ពីរចំពោះ APIs លីនុចចៃដន្យ". បំណះបន្ថែមទង់ GRND_INSECURE ថ្មីទៅការហៅប្រព័ន្ធ getrandom() (ទោះបីជា Lutomirsky សំដៅលើវាថា getenttropy() ដែលត្រូវបានអនុវត្តនៅក្នុង glibc ដោយប្រើ getrandom() ជាមួយនឹងទង់ថេរ); ទង់នេះបណ្តាលឱ្យការហៅទូរសព្ទត្រលប់មកវិញនូវចំនួនទិន្នន័យដែលបានស្នើសុំ ប៉ុន្តែដោយមិនធានាថាទិន្នន័យគឺចៃដន្យ។ ខឺណែលនឹងប្រឹងប្រែងអស់ពីសមត្ថភាពដើម្បីបង្កើតទិន្នន័យចៃដន្យដ៏ល្អបំផុតដែលវាមាននៅពេលកំណត់។ "ប្រហែលជារឿងល្អបំផុតដែលត្រូវធ្វើគឺហៅវាថា 'អសុវត្ថិភាព' (មិនមានសុវត្ថិភាព) ដើម្បីការពារ API នេះពីការប្រើប្រាស់សម្រាប់អ្វីដែលត្រូវការសុវត្ថិភាព។"

បំណះក៏យកចេញនូវអាងទប់ស្កាត់ផងដែរ។ ខឺណែលបច្ចុប្បន្នរក្សានូវបណ្តុំទិន្នន័យចៃដន្យពីរ ដែលមួយត្រូវគ្នានឹង /dev/random និងមួយទៀតទៅ /dev/urandom ដូចដែលបានពិពណ៌នានៅក្នុងនេះ អត្ថបទ ឆ្នាំ 2015 ។ អាងទប់ស្កាត់គឺជាអាងសម្រាប់ /dev/random; អានសម្រាប់ឧបករណ៍នោះនឹងរារាំង (មានន័យថាឈ្មោះរបស់វា) រហូតដល់ "គ្រប់គ្រាន់" entropy ត្រូវបានប្រមូលពីប្រព័ន្ធដើម្បីបំពេញសំណើ។ ការអានបន្ថែមពីឯកសារនេះក៏ត្រូវបានរារាំងផងដែរ ប្រសិនបើមិនមាន entropy គ្រប់គ្រាន់នៅក្នុងអាង។

ការលុបអាងចាក់សោមានន័យថាការអានពី /dev/random មានឥរិយាបទដូច getrandom() ជាមួយនឹងទង់កំណត់ទៅសូន្យ (ហើយប្រែទង់ GRND_RANDOM ទៅជា noop)។ នៅពេលដែលម៉ាស៊ីនបង្កើតលេខចៃដន្យគ្រីបគ្រីប (CRNG) ត្រូវបានចាប់ផ្តើម ការអានពី /dev/random និងការហៅទៅកាន់ getrandom(...,0) នឹងមិនរារាំងទេ ហើយនឹងត្រឡប់ចំនួនដែលបានស្នើសុំនៃទិន្នន័យចៃដន្យ។

Lutomirsky បាននិយាយថា: "ខ្ញុំជឿថាអាងរារាំងលីនុចបានក្លាយទៅជាលែងប្រើហើយ។ CRNG Linux បង្កើតលទ្ធផលដែលល្អគ្រប់គ្រាន់ដើម្បីប្រើប្រាស់សម្រាប់ការបង្កើតកូនសោរ។ អាងទប់ស្កាត់មិនខ្លាំងជាងក្នុងន័យសម្ភារៈណាមួយទេ ហើយត្រូវការហេដ្ឋារចនាសម្ព័ន្ធជាច្រើនដែលមានតម្លៃគួរឱ្យសង្ស័យដើម្បីគាំទ្រវា»។

ការផ្លាស់ប្តូរត្រូវបានធ្វើឡើងដោយមានគោលដៅធានាថាកម្មវិធីដែលមានស្រាប់នឹងមិនរងផលប៉ះពាល់ទេ ហើយតាមពិត វានឹងមានបញ្ហាតិចជាងមុនជាមួយនឹងការរង់ចាំយូរសម្រាប់អ្វីៗដូចជាការបង្កើតកូនសោ GnuPG ជាដើម។

“វគ្គទាំងនេះមិនត្រូវរំខានដល់កម្មវិធីដែលមានស្រាប់ណាមួយឡើយ។ /dev/urandom នៅតែមិនផ្លាស់ប្តូរ។ /dev/random នៅតែរារាំងភ្លាមៗនៅពេលចាប់ផ្ដើម ប៉ុន្តែវាទប់ស្កាត់តិចជាងមុន។ getenttropy() ជាមួយនឹងទង់ដែលមានស្រាប់នឹងត្រឡប់លទ្ធផលដែលសមរម្យសម្រាប់គោលបំណងជាក់ស្តែងដូចពីមុន។"

Lutomirsky បានកត់សម្គាល់ថាវានៅតែជាសំណួរបើកចំហថាតើខឺណែលគួរតែផ្តល់អ្វីដែលគេហៅថា "ចំនួនចៃដន្យពិត" ដែលជាអ្វីដែលខឺណែលទប់ស្កាត់ត្រូវបានគេសន្មត់ថាធ្វើក្នុងកម្រិតជាក់លាក់មួយ។ គាត់មើលឃើញហេតុផលតែមួយគត់សម្រាប់រឿងនេះ: "ការអនុលោមតាមស្តង់ដាររដ្ឋាភិបាល" ។ Lutomirsky បានស្នើថា ប្រសិនបើខឺណែលត្រូវផ្តល់វា វាគួរតែត្រូវបានធ្វើតាមរយៈចំណុចប្រទាក់ខុសគ្នាទាំងស្រុង ឬវាគួរតែត្រូវបានផ្លាស់ទីទៅក្នុងចន្លោះអ្នកប្រើប្រាស់ ដែលអនុញ្ញាតឱ្យអ្នកប្រើប្រាស់ទាញយកគំរូព្រឹត្តិការណ៍ឆៅដែលអាចត្រូវបានប្រើដើម្បីបង្កើតអាងចាក់សោបែបនេះ។

Stephan Muller បានស្នើថាឈុតរបស់គាត់។ បំណះ សម្រាប់ Linux Random Number Generator (LRNG) (បច្ចុប្បន្នកំណែ 26 បានចេញផ្សាយ) អាចជាវិធីមួយដើម្បីផ្តល់លេខចៃដន្យពិតសម្រាប់កម្មវិធីដែលត្រូវការវា។ LRNG គឺ "អនុលោមតាមគោលការណ៍ណែនាំ SP800-90B យ៉ាងពេញលេញលើប្រភព Entropy ដែលប្រើដើម្បីបង្កើតចៃដន្យ Bits" ដែលធ្វើឱ្យវាក្លាយជាដំណោះស្រាយចំពោះបញ្ហាស្តង់ដាររបស់រដ្ឋាភិបាល។
Matthew Garrett បានជំទាស់នឹងពាក្យ "ទិន្នន័យចៃដន្យពិត" ដោយកត់សម្គាល់ថាឧបករណ៍ដែលបានយកគំរូតាមគោលការណ៍អាចត្រូវបានគេយកគំរូតាមយ៉ាងជាក់លាក់គ្រប់គ្រាន់ដើម្បីធ្វើឱ្យពួកគេអាចទស្សន៍ទាយបាន៖ "យើងមិនយកគំរូតាមព្រឹត្តិការណ៍ Quantum នៅទីនេះទេ។"

Müller បានឆ្លើយតបថាពាក្យនេះបានមកពីស្តង់ដារអាឡឺម៉ង់ AIS 31 ដើម្បីពិពណ៌នាអំពីម៉ាស៊ីនបង្កើតលេខចៃដន្យដែលបង្កើតលទ្ធផល "ក្នុងអត្រាដូចគ្នានឹងប្រភពសំលេងរំខានដែលផលិត entropy" ។

ភាពខុសគ្នានៃវាក្យស័ព្ទមួយឡែក ការមានអាងចាក់សោ ដូចដែលបានណែនាំដោយបំណះ LRNG នឹងនាំទៅរកបញ្ហាផ្សេងៗ យ៉ាងហោចណាស់ប្រសិនបើវាត្រូវបានចូលដោយគ្មានសិទ្ធិ។

ដូចដែល Lutomirsky បាននិយាយថា: "នេះមិនដោះស្រាយបញ្ហាទេ។ ប្រសិនបើអ្នកប្រើពីរផ្សេងគ្នាដំណើរការកម្មវិធីឆោតល្ងង់ដូចជា gnupg ពួកគេនឹងគ្រាន់តែបង្ហូរគ្នាទៅវិញទៅមក។ ខ្ញុំឃើញថាបច្ចុប្បន្នមានបញ្ហាចម្បងពីរជាមួយ /dev/random៖ វាងាយនឹង DoS (ឧ. ការថយចុះធនធាន ឥទ្ធិពលព្យាបាទ ឬអ្វីមួយដែលស្រដៀងគ្នា) ហើយដោយសារគ្មានសិទ្ធិតម្រូវឱ្យប្រើវា វាក៏ងាយនឹងបំពានផងដែរ។ Gnupg គឺខុស វាជាការដួលរលំទាំងស្រុង។ ប្រសិនបើយើងបន្ថែមចំណុចប្រទាក់ដែលគ្មានសិទ្ធិថ្មីដែល gnupg និងកម្មវិធីស្រដៀងគ្នានឹងប្រើ យើងនឹងបាត់បង់ម្តងទៀត។"

Mueller បានកត់សម្គាល់ថាការបន្ថែម getrandom() ឥឡូវនេះនឹងអនុញ្ញាតឱ្យ GnuPG ប្រើចំណុចប្រទាក់នេះព្រោះវានឹងផ្តល់នូវការធានាចាំបាច់ដែលអាងត្រូវបានចាប់ផ្តើម។ ផ្អែកលើការពិភាក្សាជាមួយអ្នកអភិវឌ្ឍន៍ GnuPG លោក Werner Koch លោក Mueller ជឿជាក់ថាការធានាគឺជាហេតុផលតែមួយគត់ដែលបច្ចុប្បន្ន GnuPG អានដោយផ្ទាល់ពី /dev/random ។ ប៉ុន្តែប្រសិនបើមានចំណុចប្រទាក់ដែលគ្មានសិទ្ធិដែលងាយនឹងបដិសេធសេវាកម្ម (ដូច /dev/random គឺសព្វថ្ងៃនេះ) Lutomirsky ប្រកែកថាវានឹងត្រូវបានប្រើប្រាស់ខុសដោយកម្មវិធីមួយចំនួន។

Theodore Yue Tak Ts'o អ្នកអភិវឌ្ឍន៍ប្រព័ន្ធរងលេខចៃដន្យរបស់លីនុចហាក់ដូចជាបានផ្លាស់ប្តូរគំនិតរបស់គាត់អំពីតម្រូវការសម្រាប់ក្រុមរារាំង។ គាត់បាននិយាយថាការដកអាងនេះចេញនឹងមានប្រសិទ្ធភាពកម្ចាត់គំនិតដែលថាលីនុចមានម៉ាស៊ីនបង្កើតលេខចៃដន្យ (TRNG)៖ "នេះមិនមែនជារឿងសមហេតុសមផលទេ ព្រោះនេះជាអ្វីដែល *BSD តែងតែធ្វើ។"

គាត់ក៏មានការព្រួយបារម្ភផងដែរថាការផ្តល់យន្តការ TRNG នឹងបម្រើជានុយសម្រាប់អ្នកអភិវឌ្ឍន៍កម្មវិធី ហើយជឿជាក់ថាតាមពិត ការផ្តល់ប្រភេទ Hardware ផ្សេងៗដែលគាំទ្រដោយ Linux វាមិនអាចទៅរួចទេក្នុងការធានា TRNG នៅក្នុងខឺណែល។ សូម្បីតែសមត្ថភាពក្នុងការធ្វើការជាមួយឧបករណ៍តែជាមួយសិទ្ធិជា root នឹងមិនដោះស្រាយបញ្ហាទេ: "អ្នកអភិវឌ្ឍន៍កម្មវិធីបញ្ជាក់ថាកម្មវិធីរបស់ពួកគេត្រូវបានដំឡើងជា root សម្រាប់គោលបំណងសុវត្ថិភាព ដូច្នេះនេះគឺជាវិធីតែមួយគត់ដែលអ្នកអាចចូលប្រើលេខចៃដន្យ 'ពិតជាល្អ' ។"

Mueller បានសួរថាតើ Cao បានបោះបង់ចោលការអនុវត្តអាងទប់ស្កាត់ដែលខ្លួនគាត់ផ្ទាល់បានស្នើជាយូរមកហើយឬអត់។ Cao បានឆ្លើយតបថាគាត់គ្រោងនឹងយកបំណះរបស់ Lutomirsky និងប្រឆាំងយ៉ាងសកម្មក្នុងការបន្ថែមចំណុចប្រទាក់ទប់ស្កាត់ត្រឡប់ទៅខឺណែលវិញ។

“ខឺណែលមិនអាចធានាបានថាតើប្រភពសំឡេងរំខានត្រូវបានកំណត់លក្ខណៈត្រឹមត្រូវឬអត់។ រឿងតែមួយគត់ដែលអ្នកអភិវឌ្ឍន៍ GPG ឬ OpenSSL អាចទទួលបានគឺអារម្មណ៍មិនច្បាស់លាស់ដែលថា TRUERANDOM "ប្រសើរជាង" ហើយដោយសារពួកគេចង់បានសុវត្ថិភាពបន្ថែមទៀត ពួកគេនឹងព្យាយាមប្រើវាដោយសង្ស័យ។ នៅចំណុចខ្លះវានឹងត្រូវបានរារាំង ហើយនៅពេលដែលអ្នកប្រើប្រាស់ឆ្លាតវៃផ្សេងទៀត (ប្រហែលជាអ្នកឯកទេសចែកចាយ) បញ្ចូលវាទៅក្នុងស្គ្រីប init ហើយប្រព័ន្ធឈប់ដំណើរការ អ្នកប្រើប្រាស់នឹងត្រូវប្តឹងទៅ Linus Torvalds ខ្លួនឯងតែប៉ុណ្ណោះ។

Cao ក៏តស៊ូមតិផ្តល់ឱ្យអ្នកសរសេរកូដសម្ងាត់ និងអ្នកដែលពិតជាត្រូវការ TRNG នូវវិធីមួយដើម្បីប្រមូលយក entropy ផ្ទាល់ខ្លួនរបស់ពួកគេនៅក្នុងទំហំអ្នកប្រើប្រាស់ដើម្បីប្រើប្រាស់ដូចដែលពួកគេយល់ស្រប។ គាត់និយាយថាការប្រមូល entropy មិនមែនជាដំណើរការដែលអាចត្រូវបានអនុវត្តដោយ kernel នៅលើ hardware ផ្សេងគ្នាទាំងអស់ដែលវាគាំទ្រនោះទេ ហើយ kernel ខ្លួនឯងក៏មិនអាចប៉ាន់ស្មានចំនួន entropy ដែលផ្តល់ដោយប្រភពផ្សេងៗគ្នាដែរ។

"ខឺណែលមិនគួរត្រូវបានលាយប្រភពសំលេងរំខានផ្សេងៗជាមួយគ្នានោះទេ ហើយវាពិតជាមិនគួរព្យាយាមអះអាងដើម្បីដឹងពីចំនួនប៊ីតនៃ entropy ដែលវាទទួលបាននៅពេលដែលវាកំពុងព្យាយាមលេងហ្គេម "twitchy entropy" មួយចំនួននៅលើ CPU ដ៏សាមញ្ញមួយ។ ស្ថាបត្យកម្មសម្រាប់អ្នកប្រើប្រាស់។ IOT/Embedded case ដែលអ្វីៗទាំងអស់មិនស៊ីសង្វាក់គ្នាជាមួយ master oscillator តែមួយ ដែលមិនមានការណែនាំ CPU ដើម្បីតម្រៀបឡើងវិញ ឬប្តូរឈ្មោះការចុះឈ្មោះ។ល។"

“អ្នកអាចនិយាយអំពីការផ្តល់ឧបករណ៍ដែលព្យាយាមធ្វើការគណនាទាំងនេះ ប៉ុន្តែរឿងបែបនេះត្រូវធ្វើនៅលើផ្នែករឹងរបស់អ្នកប្រើម្នាក់ៗ ដែលវាមិនមានប្រយោជន៍សម្រាប់អ្នកប្រើប្រាស់ចែកចាយភាគច្រើននោះទេ។ ប្រសិនបើនេះមានបំណងសម្រាប់តែអ្នកសរសេរកូដសម្ងាត់ប៉ុណ្ណោះ សូមអនុញ្ញាតឱ្យវារួចរាល់ក្នុងចន្លោះអ្នកប្រើប្រាស់របស់ពួកគេ។ ហើយសូមកុំធ្វើឱ្យ GPG សាមញ្ញ OpenSSL ជាដើម។ ដើម្បីឱ្យមនុស្សគ្រប់គ្នានិយាយថា "យើងចង់បាន "ភាពចៃដន្យពិត" ហើយនឹងមិនដោះស្រាយតិចជាងនេះទេ។ យើង​អាច​និយាយ​អំពី​របៀប​ដែល​យើង​ផ្តល់​ចំណុច​ប្រទាក់​ដល់​អ្នក​គ្រីបតូ ដូច្នេះ​ពួកគេ​អាច​ទទួល​បាន​ព័ត៌មាន​ដែល​ពួកគេ​ត្រូវ​ការ​ដោយ​ការ​ចូល​ប្រើប្រាស់​ប្រភព​សំឡេង​រំខាន​ចម្បង​ដោយ​បំបែក​ និង​ដាក់​ឈ្មោះ​ ហើយ​ប្រហែល​ជា​ប្រភព​សំឡេង​រំខាន​អាច​ផ្ទៀងផ្ទាត់​ខ្លួន​វា​ទៅ​បណ្ណាល័យ​ ឬ​កម្មវិធី​ចន្លោះ​អ្នក​ប្រើ។

មានការពិភាក្សាមួយចំនួនអំពីអ្វីដែលចំណុចប្រទាក់បែបនេះអាចមើលទៅដូច ចាប់តាំងពីឧទាហរណ៍ វាអាចមានផលប៉ះពាល់សុវត្ថិភាពសម្រាប់ព្រឹត្តិការណ៍មួយចំនួន។ Cao បានកត់សម្គាល់ថាលេខកូដស្កេនក្តារចុច (ឧទាហរណ៍ការចុចគ្រាប់ចុច) ត្រូវបានលាយបញ្ចូលគ្នាទៅក្នុងអាងដែលជាផ្នែកមួយនៃការប្រមូល entropy: "ការនាំយកវាទៅក្នុងចន្លោះអ្នកប្រើប្រាស់ សូម្បីតែតាមរយៈការហៅតាមប្រព័ន្ធដែលមានសិទ្ធិក៏ដោយ វានឹងជាការមិនសមហេតុផលក្នុងការនិយាយតិចបំផុត"។ វាអាចទៅរួចដែលថាពេលវេលាព្រឹត្តិការណ៍ផ្សេងទៀតអាចបង្កើតការលេចធ្លាយព័ត៌មានមួយចំនួនតាមរយៈបណ្តាញចំហៀង។

ដូច្នេះវាមើលទៅដូចជាបញ្ហាដែលមានរយៈពេលយូរជាមួយប្រព័ន្ធរងលេខចៃដន្យរបស់លីនុចកំពុងស្ថិតនៅលើផ្លូវទៅរកដំណោះស្រាយ។ ការផ្លាស់ប្តូរដែលប្រព័ន្ធរងលេខចៃដន្យបានឆ្លងកាត់ថ្មីៗនេះពិតជាបានបណ្តាលឱ្យមានបញ្ហា DoS ខណៈពេលដែលកំពុងប្រើវា។ ឥឡូវនេះមានវិធីដ៏មានប្រសិទ្ធភាពក្នុងការទទួលបានលេខចៃដន្យដ៏ល្អបំផុតដែលខឺណែលអាចផ្តល់ឱ្យ។ ប្រសិនបើ TRNG នៅតែចង់បាននៅលើលីនុច នោះកំហុសនេះនឹងត្រូវដោះស្រាយនៅពេលអនាគត ប៉ុន្តែទំនងជាវានឹងមិនត្រូវបានធ្វើនៅក្នុងខឺណែលខ្លួនឯងនោះទេ។

ការផ្សាយពាណិជ្ជកម្មមួយចំនួន🙂

សូមអរគុណចំពោះការស្នាក់នៅជាមួយពួកយើង។ តើអ្នកចូលចិត្តអត្ថបទរបស់យើងទេ? ចង់មើលខ្លឹមសារគួរឱ្យចាប់អារម្មណ៍បន្ថែមទៀតទេ? គាំទ្រយើងដោយការបញ្ជាទិញឬណែនាំដល់មិត្តភក្តិ, cloud VPS សម្រាប់អ្នកអភិវឌ្ឍន៍ចាប់ពី $4.99, analogue តែមួយគត់នៃម៉ាស៊ីនមេកម្រិតធាតុ ដែលត្រូវបានបង្កើតឡើងដោយពួកយើងសម្រាប់អ្នក៖ ការពិតទាំងមូលអំពី VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ចាប់ពី $19 ឬរបៀបចែករំលែកម៉ាស៊ីនមេ? (អាចប្រើបានជាមួយ RAID1 និង RAID10 រហូតដល់ 24 cores និងរហូតដល់ 40GB DDR4)។

Dell R730xd 2x ថោកជាងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ Equinix Tier IV នៅទីក្រុង Amsterdam? នៅទីនេះ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ចាប់ពី $199 នៅប្រទេសហូឡង់! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ចាប់ពី $99! អាន​អំពី របៀបបង្កើតក្រុមហ៊ុនហេដ្ឋារចនាសម្ព័ន្ធ ថ្នាក់ជាមួយនឹងការប្រើប្រាស់ម៉ាស៊ីនមេ Dell R730xd E5-2650 v4 ដែលមានតម្លៃ 9000 អឺរ៉ូសម្រាប់មួយកាក់?

ប្រភព: www.habr.com