लिनक्स: लॉक पूल /dev/random काढून टाकत आहे

/dev/random, एक क्रिप्टोग्राफिकदृष्ट्या सुरक्षित स्यूडो-रँडम नंबर जनरेटर (CSPRNG), एक त्रासदायक समस्या म्हणून ओळखली जाते: ब्लॉक करणे. आपण ते कसे सोडवू शकता हे हा लेख स्पष्ट करतो.

गेल्या काही महिन्यांत, कर्नलमधील यादृच्छिक संख्या निर्मिती सुविधा थोड्या प्रमाणात सुधारल्या गेल्या आहेत, परंतु या उपप्रणालीतील समस्यांचे निराकरण केले गेले आहे. वेळ फ्रेम. सर्वात शेवटचे बदल सिस्टम बूट झाल्यावर getrandom() सिस्टम कॉलला बराच काळ ब्लॉक होण्यापासून रोखण्यासाठी केले होते, परंतु याचे मूळ कारण म्हणजे यादृच्छिक पूलचे ब्लॉकिंग वर्तन होते. अलीकडील पॅचने हा पूल काढून टाकला असता आणि तो मुख्य गाभ्याकडे जाणे अपेक्षित होते.

अँडी लुटोमिर्स्की यांनी डिसेंबरच्या शेवटी पॅचची तिसरी आवृत्ती प्रकाशित केली. तो योगदान देतो "यादृच्छिक लिनक्स API मध्ये दोन प्रमुख अर्थपूर्ण बदल". पॅच getrandom() सिस्टीम कॉलमध्ये एक नवीन GRND_INSECURE ध्वज जोडतो (जरी ल्युटोमिर्स्कीने त्याचा संदर्भ getentropy() म्हणून केला आहे, जो glibc मध्ये getrandom() वापरून निश्चित ध्वजांसह लागू केला जातो); या ध्वजामुळे कॉल नेहमी विनंती केलेल्या डेटाची रक्कम परत करतो, परंतु डेटा यादृच्छिक असल्याची हमी न देता. कर्नल दिलेल्या वेळी त्याच्याकडे असलेला सर्वोत्तम यादृच्छिक डेटा तयार करण्यासाठी सर्वतोपरी प्रयत्न करेल. "कदाचित सर्वोत्तम गोष्ट म्हणजे त्याला 'असुरक्षित' म्हणणे सुरक्षिततेची गरज असलेल्या गोष्टींसाठी हे API वापरण्यापासून रोखण्यासाठी (असुरक्षित).

पॅच ब्लॉकिंग पूल देखील काढून टाकतात. कर्नल सध्या दोन यादृच्छिक डेटा पूल ठेवतो, एक /dev/random आणि दुसरा /dev/urandom शी संबंधित आहे, यात वर्णन केल्याप्रमाणे लेख 2015. ब्लॉकिंग पूल हा /dev/random साठी पूल आहे; विनंती पूर्ण करण्यासाठी सिस्टममधून "पुरेशी" एन्ट्रॉपी संकलित होईपर्यंत त्या डिव्हाइससाठी वाचन अवरोधित करेल (म्हणजे त्याचे नाव). पूलमध्ये पुरेशी एन्ट्रॉपी नसल्यास या फाइलचे पुढील वाचन देखील अवरोधित केले जाते.

लॉक पूल काढून टाकण्याचा अर्थ असा आहे की /dev/random वरून वाचणे getrandom() सारखे ध्वज शून्यावर सेट करते (आणि GRND_RANDOM ध्वजाचे नूपमध्ये रूपांतर करते). एकदा क्रिप्टोग्राफिक यादृच्छिक क्रमांक जनरेटर (CRNG) सुरू झाल्यानंतर, /dev/random वरून वाचणे आणि getrandom(...,0) वर कॉल करणे अवरोधित होणार नाही आणि यादृच्छिक डेटाची विनंती केलेली रक्कम परत करेल.

लुटोमिरस्की म्हणतो: “मला विश्वास आहे की लिनक्स ब्लॉकिंग पूल अप्रचलित झाला आहे. CRNG Linux आउटपुट व्युत्पन्न करते जे की जनरेशनसाठी वापरता येण्याइतपत चांगले आहे. ब्लॉकिंग पूल कोणत्याही भौतिक अर्थाने मजबूत नाही आणि त्याला समर्थन देण्यासाठी संशयास्पद मूल्याच्या बर्याच पायाभूत सुविधांची आवश्यकता आहे.

विद्यमान प्रोग्राम्सवर खरोखर परिणाम होणार नाही याची खात्री करण्याच्या उद्देशाने बदल केले गेले आणि खरं तर, GnuPG की जनरेशन सारख्या गोष्टींसाठी दीर्घकाळ प्रतीक्षा करताना कमी समस्या असतील.

“हे भाग कोणत्याही विद्यमान कार्यक्रमांमध्ये व्यत्यय आणू नयेत. /dev/urandom अपरिवर्तित राहते. /dev/random बूट झाल्यावर लगेच ब्लॉक होते, पण ते आधीपेक्षा कमी ब्लॉक होते. विद्यमान ध्वजांसह getentropy() पूर्वीप्रमाणेच व्यावहारिक हेतूंसाठी योग्य परिणाम देईल."

ल्युटोमिर्स्की यांनी नमूद केले की कर्नलने तथाकथित "खरे यादृच्छिक क्रमांक" प्रदान केले पाहिजेत की नाही हे अद्याप एक खुले प्रश्न आहे, जे ब्लॉकिंग कर्नलने काही प्रमाणात करायचे होते. त्याला याचे एकच कारण दिसते: “सरकारी मानकांचे पालन.” ल्युटोमिर्स्कीने सुचवले की जर कर्नल हे प्रदान करायचे असेल तर ते पूर्णपणे भिन्न इंटरफेसद्वारे केले जावे, किंवा ते वापरकर्त्याच्या जागेत हलवले जावे, ज्यामुळे वापरकर्त्याला असे लॉक पूल तयार करण्यासाठी वापरता येणारे कच्चे इव्हेंट नमुने पुनर्प्राप्त करण्याची परवानगी मिळेल.

स्टीफन म्युलरने त्याचा सेट सुचवला पॅच लिनक्स रँडम नंबर जनरेटरसाठी (LRNG) (सध्या आवृत्ती 26 रिलीझ केली आहे) आवश्यक असलेल्या अनुप्रयोगांसाठी खरे यादृच्छिक क्रमांक प्रदान करण्याचा एक मार्ग असू शकतो. LRNG "यादृच्छिक बिट्स जनरेट करण्यासाठी वापरल्या जाणार्‍या एन्ट्रॉपी स्त्रोतांवरील SP800-90B मार्गदर्शक तत्त्वांचे पूर्णपणे पालन करते," ज्यामुळे ते सरकारी मानकांच्या समस्येचे निराकरण करते.
मॅथ्यू गॅरेटने "खरा यादृच्छिक डेटा" या शब्दावर आक्षेप घेतला, हे लक्षात घेऊन की नमुना घेतलेल्या डिव्हाइसेसना अंदाज लावता येण्याइतपत तंतोतंत मॉडेल केले जाऊ शकते: "आम्ही येथे क्वांटम घटनांचे नमुने घेत नाही."

म्युलरने प्रतिसाद दिला की हा शब्द यादृच्छिक संख्या जनरेटरचे वर्णन करण्यासाठी जर्मन मानक AIS 31 वरून आलेला आहे जो केवळ "अंतर्निहित ध्वनी स्रोत एंट्रोपी निर्माण करतो त्याच दराने" परिणाम देतो.

शब्दावलीतील फरक बाजूला ठेवून, LRNG पॅचेसने सुचविल्याप्रमाणे लॉक पूल असण्यामुळे विविध समस्या उद्भवतील, किमान विशेषाधिकारांशिवाय प्रवेश केला तर.

ल्युटोमिरस्कीने म्हटल्याप्रमाणे: “याने समस्या सुटत नाही. दोन भिन्न वापरकर्ते gnupg सारखे मूर्ख प्रोग्राम चालवल्यास, ते एकमेकांना निचरा करतील. मी पाहतो की /dev/random सह सध्या दोन मुख्य समस्या आहेत: ते DoS (म्हणजे संसाधन कमी होणे, दुर्भावनापूर्ण प्रभाव किंवा तत्सम काहीतरी) ची शक्यता आहे आणि ते वापरण्यासाठी कोणतेही विशेषाधिकार आवश्यक नसल्यामुळे, त्याचा गैरवापर होण्याची शक्यता देखील आहे. Gnupg चुकीचे आहे, ते संपूर्ण संकुचित आहे. आम्ही gnupg आणि तत्सम प्रोग्राम वापरत असलेला नवीन अनप्रिव्हिलेज्ड इंटरफेस जोडल्यास, आम्ही पुन्हा गमावू."

म्युलरने नमूद केले की getrandom() ची जोडणी आता GnuPG ला हा इंटरफेस वापरण्यास अनुमती देईल, कारण ते आवश्यक हमी देईल की पूल सुरू झाला आहे. GnuPG डेव्हलपर वर्नर कोच यांच्याशी झालेल्या चर्चेच्या आधारे, म्युलरचा असा विश्वास आहे की GnuPG सध्या थेट /dev/random वरून वाचण्याचे एकमेव कारण आहे. परंतु जर सेवा नाकारण्यास अतिसंवेदनशील असा अनप्रिव्हिलेज्ड इंटरफेस असेल (आज /dev/random आहे तसे), Lutomirsky असा युक्तिवाद करतात की काही अनुप्रयोगांद्वारे त्याचा गैरवापर केला जाईल.

लिनक्सच्या यादृच्छिक संख्या उपप्रणालीचे विकसक, थिओडोर यू तक त्सो यांनी ब्लॉकिंग पूलच्या गरजेबद्दल त्यांचे मत बदलल्याचे दिसते. तो म्हणाला की हा पूल काढून टाकल्याने लिनक्समध्ये खरा यादृच्छिक क्रमांक जनरेटर (TRNG) आहे या कल्पनेतून प्रभावीपणे सुटका होईल: "हे मूर्खपणाचे नाही, कारण *BSD ने नेहमीच हेच केले आहे."

TRNG यंत्रणा पुरवणे हे ऍप्लिकेशन डेव्हलपरसाठी एक आमिष म्हणून काम करेल याचीही त्याला चिंता आहे आणि त्याचा असा विश्वास आहे की, Linux द्वारे समर्थित विविध प्रकारचे हार्डवेअर पाहता, कर्नलमध्ये TRNG ची हमी देणे अशक्य आहे. केवळ मूळ अधिकारांसह उपकरणांसह कार्य करण्याची क्षमता देखील समस्येचे निराकरण करणार नाही: "अ‍ॅप्लिकेशन डेव्हलपर निर्दिष्ट करतात की त्यांचा ऍप्लिकेशन सुरक्षेच्या उद्देशाने रूट म्हणून स्थापित केला जाईल, जेणेकरून तुम्ही 'खरोखर चांगल्या' यादृच्छिक संख्यांमध्ये प्रवेश करण्याचा हा एकमेव मार्ग आहे."

म्युलरने विचारले की काओने स्वत: लांब प्रस्तावित केलेल्या ब्लॉकिंग पूल अंमलबजावणीचा त्याग केला आहे का. Cao ने प्रतिसाद दिला की तो Lutomirsky चे पॅच घेण्याची योजना आखत आहे आणि कर्नलमध्ये परत ब्लॉकिंग इंटरफेस जोडण्यास सक्रियपणे विरोध करतो.

“ध्वनी स्त्रोत योग्यरित्या वर्णित केला गेला आहे की नाही याची कर्नल कोणतीही हमी देऊ शकत नाही. GPG किंवा OpenSSL डेव्हलपरला फक्त एक अस्पष्ट भावना मिळू शकते की TRUERANDOM "चांगले" आहे आणि त्यांना अधिक सुरक्षितता हवी असल्याने, ते निःसंशयपणे ते वापरण्याचा प्रयत्न करतील. काही क्षणी ते अवरोधित केले जाईल, आणि जेव्हा काही इतर स्मार्ट वापरकर्ता (कदाचित वितरण तज्ञ) ते init स्क्रिप्टमध्ये घालतात आणि सिस्टम कार्य करणे थांबवतात तेव्हा वापरकर्त्यांना फक्त लिनस टोरवाल्ड्सकडे तक्रार करावी लागेल.

Cao क्रिप्टोग्राफर आणि ज्यांना TRNG ची गरज आहे त्यांना वापरकर्ता स्पेसमध्ये त्यांच्या स्वत: च्या एन्ट्रॉपीची कापणी करण्याचा मार्ग त्यांना योग्य वाटेल त्याप्रमाणे वापरण्याचा सल्ला देतो. तो म्हणतो की एन्ट्रॉपी गोळा करणे ही एक प्रक्रिया नाही जी कर्नलद्वारे समर्थित सर्व भिन्न हार्डवेअरवर केली जाऊ शकते किंवा कर्नल स्वतःच वेगवेगळ्या स्त्रोतांद्वारे प्रदान केलेल्या एन्ट्रॉपीच्या प्रमाणाचा अंदाज लावू शकत नाही.

"कर्नल वेगवेगळ्या आवाजाचे स्रोत एकत्र मिक्स करत नसावेत, आणि एखाद्या अत्यंत साध्या CPU वर "ट्विची एन्ट्रॉपी गेम" खेळण्याचा प्रयत्न करत असताना त्याला किती बिट एन्ट्रॉपी मिळतात हे जाणून घेण्याचा दावा करण्याचा प्रयत्न नक्कीच करू नये. ग्राहक वापरकर्त्यांसाठी आर्किटेक्चर. IOT/एम्बेडेड प्रकरणे जेथे सर्व काही एकाच मास्टर ऑसीलेटरसह समक्रमित नाही, जेथे नोंदणी पुनर्क्रमित करण्यासाठी किंवा पुनर्नामित करण्याची कोणतीही CPU सूचना नाही इ.

“आपण ही गणना करण्याचा प्रयत्न करणारी साधने प्रदान करण्याबद्दल बोलू शकता, परंतु अशा गोष्टी प्रत्येक वापरकर्त्याच्या हार्डवेअरवर केल्या पाहिजेत, जे बहुतेक वितरण वापरकर्त्यांसाठी व्यावहारिक नाही. जर हे फक्त क्रिप्टोग्राफरसाठी असेल, तर ते त्यांच्या वापरकर्त्याच्या जागेत करू द्या. आणि आपण GPG, OpenSSL इ. सरलीकृत करू नये जेणेकरून प्रत्येकजण म्हणेल "आम्हाला "खरा यादृच्छिकपणा" हवा आहे आणि कमीत कमी समाधान मानणार नाही. आम्ही क्रिप्टोग्राफरना इंटरफेस कसे प्रदान करतो याबद्दल आम्ही बोलू शकतो जेणेकरुन त्यांना प्राथमिक ध्वनी स्त्रोतांमध्ये प्रवेश करून आवश्यक माहिती मिळू शकेल, विभक्त आणि नाव दिलेले आहे आणि कदाचित कोणत्या तरी आवाजाचा स्त्रोत लायब्ररी किंवा वापरकर्ता स्पेस ऍप्लिकेशनवर स्वतःला प्रमाणीकृत करू शकेल."

असा इंटरफेस कसा दिसू शकतो याबद्दल काही चर्चा झाली, कारण उदाहरणार्थ काही इव्हेंटसाठी सुरक्षा परिणाम असू शकतात. काओने नोंदवले की कीबोर्ड स्कॅन कोड (म्हणजे कीस्ट्रोक) एंट्रॉपी संकलनाचा भाग म्हणून एका पूलमध्ये मिसळले जातात: "हे वापरकर्ता स्पेसमध्ये आणणे, अगदी विशेषाधिकारप्राप्त सिस्टम कॉलद्वारे, किमान म्हणणे मूर्खपणाचे ठरेल." हे शक्य आहे की इतर इव्हेंट वेळेमुळे साइड चॅनेलद्वारे काही प्रकारची माहिती लीक होऊ शकते.

त्यामुळे असे दिसते आहे की लिनक्सच्या यादृच्छिक संख्या उपप्रणालीसह दीर्घकाळ चाललेली समस्या सोडवण्याच्या मार्गावर आहे. यादृच्छिक संख्या उपप्रणालीमध्ये अलीकडेच झालेले बदल प्रत्यक्षात वापरताना केवळ DoS समस्या निर्माण करतात. आता कर्नल प्रदान करू शकणारे सर्वोत्कृष्ट यादृच्छिक क्रमांक मिळविण्याचे कार्यक्षम मार्ग आहेत. TRNG अजूनही लिनक्सवर इष्ट असल्यास, भविष्यात या त्रुटीकडे लक्ष देणे आवश्यक आहे, परंतु बहुधा हे कर्नलमध्येच केले जाणार नाही.

काही जाहिराती 🙂

आमच्यासोबत राहिल्याबद्दल धन्यवाद. तुम्हाला आमचे लेख आवडतात का? अधिक मनोरंजक सामग्री पाहू इच्छिता? ऑर्डर देऊन किंवा मित्रांना शिफारस करून आम्हाला समर्थन द्या, $4.99 पासून विकसकांसाठी क्लाउड VPS, एंट्री-लेव्हल सर्व्हरचे एक अद्वितीय अॅनालॉग, जे तुमच्यासाठी आमच्याद्वारे शोधले गेले आहे: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps बद्दल संपूर्ण सत्य $19 पासून किंवा सर्व्हर कसा शेअर करायचा? (RAID1 आणि RAID10 सह उपलब्ध, 24 कोर पर्यंत आणि 40GB DDR4 पर्यंत).

डेल R730xd ऍमस्टरडॅममधील इक्विनिक्स टियर IV डेटा सेंटरमध्ये 2 पट स्वस्त? फक्त इथेच 2 x इंटेल टेट्राडेका-कोर Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीव्ही $199 पासून नेदरलँड मध्ये! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 पासून! बद्दल वाचा इन्फ्रास्ट्रक्चर कॉर्पोरेशन कसे तयार करावे. डेल R730xd E5-2650 v4 सर्व्हरचा वापर करून 9000 युरो किमतीचा वर्ग?

स्त्रोत: www.habr.com