लिनक्स: लक पूल /dev/random हटाउँदै

/dev/random, एक क्रिप्टोग्राफिक रूपमा सुरक्षित छद्म-यादृच्छिक नम्बर जनरेटर (CSPRNG), एक कष्टप्रद समस्याको रूपमा परिचित छ: अवरुद्ध। यस लेखले तपाइँ यसलाई कसरी समाधान गर्न सक्नुहुन्छ भनेर बताउँछ।

विगत केही महिनाहरूमा, कर्नेलमा अनियमित संख्या उत्पादन सुविधाहरू थोरै पुन: काम गरिएको छ, तर यस उपप्रणालीमा समस्याहरू व्यापक रूपमा समाधान गरिएको छ। समय सीमा। सबैभन्दा पछिल्लो परिवर्तनहरू प्रणाली बुट हुँदा getrandom() प्रणाली कललाई लामो समयसम्म अवरुद्ध हुनबाट रोक्नको लागि बनाइएको थियो, तर यसको मूल कारण अनियमित पूलको अवरुद्ध व्यवहार थियो। भर्खरैको प्याचले यो पोखरी हटाउनेछ र यो मुख्य कोर तिर जाने अपेक्षा गरिएको छ।

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

प्याचहरूले अवरुद्ध पूल पनि हटाउँदछ। कर्नेलले हाल दुई अनियमित डाटा पूलहरू राख्दछ, एउटा /dev/random सँग सम्बन्धित र अर्को /dev/urandom सँग, जसमा वर्णन गरिएको छ। लेख २०१५। अवरुद्ध पूल /dev/random को लागि पूल हो; अनुरोध पूरा गर्न प्रणालीबाट "पर्याप्त" एन्ट्रोपी सङ्कलन नभएसम्म त्यो यन्त्रको लागि पढ्ने (यसको नामको अर्थ) रोकिनेछ। यदि पूलमा पर्याप्त एन्ट्रोपी छैन भने यस फाइलबाट थप पढाइहरू पनि अवरुद्ध छन्।

लक पूल हटाउनुको अर्थ /dev/random बाट पढ्दा getrandom() लाई शून्यमा सेट गरिएको झण्डा (र GRND_RANDOM फ्ल्यागलाई नूपमा परिणत गर्छ) जस्तै व्यवहार गर्छ। एक पटक क्रिप्टोग्राफिक अनियमित नम्बर जेनेरेटर (CRNG) प्रारम्भ भएपछि, /dev/random बाट पढ्ने र getrandom(...,0) लाई कल गर्नाले रोकिने छैन र अनियमित डाटाको अनुरोध गरिएको रकम फिर्ता गर्नेछ।

Lutomirsky भन्छन्: "मलाई विश्वास छ कि लिनक्स अवरुद्ध पूल अप्रचलित भएको छ। CRNG Linux ले आउटपुट उत्पन्न गर्दछ जुन कुञ्जी उत्पादनको लागि पनि प्रयोग गर्न पर्याप्त छ। अवरुद्ध पोखरी कुनै पनि भौतिक अर्थमा बलियो छैन र यसलाई समर्थन गर्न शंकास्पद मूल्यको धेरै पूर्वाधार चाहिन्छ। ”

परिवर्तनहरू अवस्थित कार्यक्रमहरू वास्तवमै प्रभावित हुने छैनन् भनी सुनिश्चित गर्ने लक्ष्यका साथ गरिएको थियो, र वास्तवमा, GnuPG कुञ्जी जेनेरेसन जस्ता चीजहरूको लागि लामो पर्खाइमा कम समस्याहरू हुनेछन्।

"यी एपिसोडहरूले कुनै पनि अवस्थित कार्यक्रमहरूलाई बाधा पुर्‍याउनु हुँदैन। /dev/urandom अपरिवर्तित रहन्छ। /dev/random अझै पनि बुटमा तुरुन्तै ब्लक गर्दछ, तर यसले पहिले भन्दा कम ब्लक गर्दछ। getentropy() अवस्थित झण्डाहरूको साथमा परिणाम फर्काउनेछ जुन पहिले जस्तै व्यावहारिक उद्देश्यका लागि उपयुक्त छ।"

लुटोमिरस्कीले उल्लेख गरे कि यो अझै पनि खुला प्रश्न हो कि कर्नेलले तथाकथित "साँचो अनियमित संख्याहरू" प्रदान गर्नुपर्छ, जुन अवरुद्ध कर्नेलले निश्चित हदसम्म गर्नु पर्ने थियो। उहाँले यसको एउटै कारण देख्नुहुन्छ: "सरकारी मापदण्डहरूको अनुपालन।" लुटोमिरस्कीले सुझाव दिए कि यदि कर्नेलले यो प्रदान गर्ने हो भने, यो पूर्णतया फरक इन्टरफेस मार्फत गरिनु पर्छ, वा यसलाई प्रयोगकर्ता स्पेसमा सार्नु पर्छ, जसले प्रयोगकर्तालाई कच्चा घटना नमूनाहरू पुन: प्राप्त गर्न अनुमति दिन्छ जुन यस्तो लक पूल सिर्जना गर्न प्रयोग गर्न सकिन्छ।

स्टेफन मुलरले आफ्नो सेट सुझाव दिए प्याचहरू Linux Random Number Generator (LRNG) को लागि (हालमा संस्करण 26 जारी गरिएको छ) यो आवश्यक पर्ने अनुप्रयोगहरूको लागि साँचो अनियमित नम्बरहरू प्रदान गर्ने तरिका हुन सक्छ। LRNG "रैन्डम बिटहरू उत्पन्न गर्न प्रयोग गरिने एन्ट्रोपी स्रोतहरूमा SP800-90B दिशानिर्देशहरूसँग पूर्ण रूपमा अनुरूप छ," यसले सरकारी स्तरहरूको समस्याको समाधान बनाउँछ।
म्याथ्यू ग्यारेटले "साँचो यादृच्छिक डेटा" शब्दमा आपत्ति जनाए, यो नोट गर्दै कि नमूना गरिएका यन्त्रहरू सिद्धान्तमा तिनीहरूलाई भविष्यवाणी गर्नको लागि पर्याप्त रूपमा मोडेल गर्न सकिन्छ: "हामी यहाँ क्वान्टम घटनाहरूको नमूना गरिरहेका छैनौं।"

मुलरले जवाफ दिए कि शब्द जर्मन मानक AIS 31 बाट एक अनियमित संख्या जनरेटरको वर्णन गर्न को लागी आएको हो जसले केवल "अन्तर्निहित आवाज स्रोतले एन्ट्रोपी उत्पादन गर्दछ समान दरमा" परिणाम दिन्छ।

शब्दावलीको भिन्नतालाई छाडेर, LRNG प्याचहरूले सुझाव दिए अनुसार लक पूल हुनुले विभिन्न समस्याहरू निम्त्याउनेछ, कम्तिमा यदि यो विशेषाधिकार बिना पहुँच गरियो भने।

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

Mueller ले नोट गरे कि getrandom() को थपले अब GnuPG लाई यो इन्टरफेस प्रयोग गर्न अनुमति दिनेछ, किनकि यसले आवश्यक ग्यारेन्टी प्रदान गर्नेछ कि पूल प्रारम्भ गरिएको छ। GnuPG विकासकर्ता वर्नर कोचसँगको छलफलको आधारमा, म्युलरले GnuPG हाल /dev/random बाट सिधै पढ्ने कारण ग्यारेन्टी नै हो भन्ने विश्वास गर्छन्। तर यदि त्यहाँ एक विशेषाधिकार नभएको इन्टरफेस छ जुन सेवा अस्वीकार गर्न संवेदनशील छ (जस्तै /dev/random आज छ), लुटोमिरस्की तर्क गर्दछ कि यो केहि अनुप्रयोगहरु द्वारा दुरुपयोग हुनेछ।

लिनक्सको अनियमित नम्बर सबसिस्टमका विकासकर्ता थिओडोर यू टक त्सोले ब्लकिङ पूलको आवश्यकताबारे आफ्नो मन परिवर्तन गरेको देखिन्छ। उनले भने कि यो पोखरी हटाउनाले लिनक्ससँग साँचो अनियमित नम्बर जनरेटर (TRNG) छ भन्ने धारणालाई प्रभावकारी रूपमा हटाउनेछ: "यो बकवास होइन, किनकि यो वास्तवमा *BSD ले सधैं गरेको छ।"

उनी यो पनि चिन्तित छन् कि TRNG संयन्त्र प्रदान गर्नाले अनुप्रयोग विकासकर्ताहरूका लागि मात्र एक चाराको रूपमा काम गर्नेछ र विश्वास गर्दछ कि वास्तवमा, लिनक्स द्वारा समर्थित विभिन्न प्रकारका हार्डवेयरहरूलाई दिएर, कर्नेलमा TRNG ग्यारेन्टी गर्न असम्भव छ। जड विशेषाधिकारहरूसँग मात्र उपकरणहरूसँग काम गर्ने क्षमताले पनि समस्या समाधान गर्दैन: "अनुप्रयोग विकासकर्ताहरूले निर्दिष्ट गर्छन् कि तिनीहरूको अनुप्रयोगलाई सुरक्षा उद्देश्यका लागि रूटको रूपमा स्थापना गरिएको छ, ताकि तपाईले 'वास्तवमा राम्रो' अनियमित संख्याहरूमा पहुँच गर्न सक्ने यो मात्र तरिका हो।"

मुलरले काओले आफूले लामो समयदेखि प्रस्ताव गरेको अवरुद्ध पूल कार्यान्वयनलाई त्यागेको हो कि भनेर सोधे। काओले जवाफ दिए कि उसले लुटोमिरस्कीको प्याचहरू लिने योजना बनाएको छ र कर्नेलमा अवरोध गर्ने इन्टरफेस थप्ने सक्रिय रूपमा विरोध गर्दछ।

"कर्नेलले कुनै पनि ग्यारेन्टी दिन सक्दैन कि शोर स्रोत ठीकसँग विशेषता गरिएको छ कि छैन। GPG वा OpenSSL विकासकर्ताले प्राप्त गर्न सक्ने एक मात्र चीज भनेको TRUERANDOM "राम्रो" हो भन्ने अस्पष्ट भावना हो, र उनीहरूले थप सुरक्षा चाहन्छन्, उनीहरूले निस्सन्देह यसलाई प्रयोग गर्ने प्रयास गर्नेछन्। केहि बिन्दुमा यो अवरुद्ध हुनेछ, र जब केहि अन्य स्मार्ट प्रयोगकर्ता (सायद वितरण विशेषज्ञ) ले यसलाई init स्क्रिप्टमा सम्मिलित गर्दछ र प्रणालीहरूले काम गर्न छोड्छ, प्रयोगकर्ताहरूले लिनस टोर्भाल्ड्सलाई मात्र गुनासो गर्नुपर्नेछ।"

Cao ले क्रिप्टोग्राफरहरू र जसलाई वास्तवमा TRNG चाहिन्छ प्रयोगकर्ता स्पेसमा उनीहरूको आफ्नै एन्ट्रोपी फसलको लागि उपयुक्त देख्ने तरिका प्रयोग गर्नको लागि वकालत गर्दछ। उनी भन्छन् कि एन्ट्रोपी सङ्कलन कुनै प्रक्रिया होइन जुन कर्नेलले समर्थन गर्ने सबै फरक हार्डवेयरमा गर्न सकिन्छ, न त कर्नेल आफैले विभिन्न स्रोतहरूद्वारा प्रदान गरिएको एन्ट्रोपीको मात्रा अनुमान गर्न सक्छ।

"कर्नेलले विभिन्न आवाज स्रोतहरू एकै ठाउँमा मिलाउनु हुँदैन, र यसले अपमानजनक रूपमा साधारण सीपीयूमा कुनै प्रकारको "ट्विची एन्ट्रोपी गेम" खेल्ने प्रयास गर्दा कति बिट्स एन्ट्रोपी पाउँदैछ भनेर दावी गर्ने प्रयास गर्नु हुँदैन। उपभोक्ता प्रयोगकर्ताहरूका लागि वास्तुकला। IOT/एम्बेडेड केसहरू जहाँ सबै कुरा एकल मास्टर ओसिलेटरसँग सिंक नभएको छ, जहाँ दर्तालाई पुन: क्रमबद्ध गर्न वा पुन: नामाकरण गर्न कुनै CPU निर्देशन छैन, आदि।"

"तपाईले यी गणनाहरू गर्न प्रयास गर्ने उपकरणहरू उपलब्ध गराउने बारे कुरा गर्न सक्नुहुन्छ, तर त्यस्ता चीजहरू प्रत्येक प्रयोगकर्ताको हार्डवेयरमा गर्नुपर्दछ, जुन धेरै वितरण प्रयोगकर्ताहरूको लागि व्यावहारिक छैन। यदि यो केवल क्रिप्टोग्राफरहरूको लागि हो भने, त्यसपछि यो तिनीहरूको प्रयोगकर्ता ठाउँमा गर्न दिनुहोस्। र GPG, OpenSSL, आदिलाई सरलीकृत नगरौं ताकि सबैले "हामी "साँचो अनियमितता" चाहन्छौं र कमको लागि बसोबास गर्दैनौं। हामीले क्रिप्टोग्राफरहरूलाई कसरी इन्टरफेसहरू प्रदान गर्ने भन्ने बारे कुरा गर्न सक्छौं ताकि उनीहरूले प्राथमिक आवाज स्रोतहरू, छुट्याइएको र नाम दिएर पहुँच गरेर उनीहरूलाई आवश्यक जानकारी प्राप्त गर्न सकून्, र सायद कुनै न कुनै रूपमा ध्वनि स्रोतले पुस्तकालय वा प्रयोगकर्ता स्पेस अनुप्रयोगमा आफूलाई प्रमाणीकरण गर्न सक्छ।"

त्यहाँ यस्तो इन्टरफेस कस्तो देखिन सक्छ भन्ने बारे केही छलफल भएको थियो, उदाहरणका लागि त्यहाँ केही घटनाहरूको लागि सुरक्षा प्रभाव हुन सक्छ। काओले नोट गरे कि किबोर्ड स्क्यान कोडहरू (जस्तै किस्ट्रोकहरू) एन्ट्रोपी सङ्कलनको भागको रूपमा पोखरीमा मिसाइन्छ: "यसलाई प्रयोगकर्ता स्पेसमा ल्याउन, विशेषाधिकार प्राप्त प्रणाली कल मार्फत पनि, कम्तिमा भन्नु मूर्खता हुनेछ।" यो सम्भव छ कि अन्य घटना समयहरूले साइड च्यानलहरू मार्फत केही प्रकारको जानकारी चुहावट सिर्जना गर्न सक्छ।

त्यसैले यस्तो देखिन्छ कि लिनक्सको अनियमित नम्बर सबसिस्टमको साथ लामो समयदेखि समस्या समाधानको बाटोमा छ। अनियमित संख्या उपप्रणालीमा हालसालै आएका परिवर्तनहरूले यसलाई प्रयोग गर्दा मात्र DoS समस्याहरू निम्त्याएको छ। अब कर्नेलले प्रदान गर्न सक्ने उत्तम अनियमित संख्याहरू प्राप्त गर्ने प्रभावकारी तरिकाहरू छन्। यदि TRNG अझै लिनक्समा वांछनीय छ भने, त्यसपछि यो त्रुटिलाई भविष्यमा सम्बोधन गर्न आवश्यक छ, तर सम्भवतः यो कर्नेल भित्र नै हुने छैन।

केही विज्ञापनहरू 🙂

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

डेल R730xd 2x एम्स्टर्डमको इक्विनिक्स टियर IV डाटा सेन्टरमा सस्तो छ? यहाँ मात्र 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 बाट! बारे पढ्नुहोस् पूर्वाधार कर्पोरेशन कसरी निर्माण गर्ने। डेल R730xd E5-2650 v4 सर्भरहरूको प्रयोगको साथ एक पैसाको लागि 9000 यूरो मूल्यको वर्ग?

स्रोत: www.habr.com