डेवलपर टूल · SHA हैश कैलकुलेटर
एक मिलान चेकसम एक हस्ताक्षर नहीं है: ईमानदारी बनाम प्रामाणिकता
· यह क्यों मायने रखती है
शा-256 क्रिप्टोग्राफी सुरक्षा
प्रकाशित SHA-256 उपयोगकर्ताओं को दूषित डाउनलोड का पता लगाने देता है, लेकिन यदि हमलावर पेज को नियंत्रित करता है तो वे चेकसम को भी नियंत्रित करते हैं। यह पोस्ट सत्यनिष्ठा को प्रामाणिकता से अलग करती है और बताती है कि हस्ताक्षर क्या जोड़ते हैं।
डाउनलोड के समान पेज पर चेकसम - यह भ्रष्टाचार से क्यों बचाता है, लेकिन समझौता किए गए होस्ट से नहीं
एक सॉफ़्टवेयर रिलीज़ को डाउनलोड वाले पेज पर SHA-256 चेकसम के साथ प्रकाशित किया जाता है। उपयोगकर्ता संग्रह ला सकते हैं, उसे हैश कर सकते हैं और परिणाम की तुलना प्रकाशित मूल्य से कर सकते हैं। यदि वे मेल खाते हैं, तो डाउनलोड दूषित नहीं है। यह सत्यनिष्ठा सत्यापन है, और यह एक वास्तविक और उपयोगी जाँच है। हालाँकि, यदि कोई हमलावर रिलीज़ को होस्ट करने वाले वेब सर्वर से समझौता करता है, तो वे बाइनरी को बदल सकते हैं, इसकी SHA-256 की पुनः गणना कर सकते हैं, और पेज पर चेकसम को अपडेट कर सकते हैं। उपयोगकर्ता चेकसम का सत्यापन करता है और हमलावर का मैलवेयर प्रकाशक से आता हुआ प्रतीत होता है। सिस्टम बिल्कुल डिज़ाइन के अनुसार काम करता है, लेकिन यह उस प्रश्न का उत्तर देने में विफल रहा जो उपयोगकर्ता ने सोचा था कि वे पूछ रहे थे।
यह स्वयं चेकसम की विफलता नहीं है. चेकसम क्या करता है और क्या नहीं, इसके बारे में यह एक सही अवलोकन है। एक चेकसम साबित करता है कि डेटा की दो प्रतियां समान हैं। इससे यह साबित नहीं होता कि डेटा किसने बनाया. यह अखंडता और प्रामाणिकता के बीच का अंतर है, और उन्हें मिलाना रिलीज़ सत्यापन में सबसे आम सुरक्षा गलतियों में से एक है। कई प्रणालियाँ इसलिए नहीं टूटतीं क्योंकि उनके चेकसम ग़लत हैं, बल्कि इसलिए क्योंकि उपयोगकर्ता उन प्रश्नों के उत्तर देने के लिए उन पर भरोसा करते हैं जिनका वे उत्तर नहीं दे पाते।
हैश क्या साबित करता है - कि दो इनपुट एक ही बाइट्स हैं, और उन्हें किसने बनाया इसके बारे में कुछ भी नहीं
सत्यनिष्ठा डेटा का ही एक गुण है। यदि आपके पास एक फ़ाइल है और उसका SHA-256 है, और फ़ाइल को संशोधित नहीं किया गया है, तो हैश मेल खाता है। हैश साबित करता है कि प्रत्येक बाइट की गणना के समय से कोई बदलाव नहीं हुआ है। यदि फ़ाइल ट्रांसमिशन त्रुटि, डिस्क विफलता, या नेटवर्क केबल पर फ़्लिप बिट के कारण दूषित हो गई थी, तो हैश मेल नहीं खाएगा। चेकसम यही अच्छा काम करते हैं। वे दुर्घटनाओं और आकस्मिक भ्रष्टाचार को पकड़ने में उत्कृष्ट हैं। वे एक ऐसे प्रतिद्वंद्वी के खिलाफ विफल हो जाते हैं जो हैश की गणना भी कर सकता है।
प्रामाणिकता इस दावे की संपत्ति है कि डेटा किसने तैयार किया। प्रश्न "क्या यह फ़ाइल उस प्रकाशक से आई है जिस पर मुझे भरोसा है?" यह प्रश्न "क्या इस फ़ाइल को संशोधित किया गया है?" से मौलिक रूप से भिन्न है। एक हैश अपने आप में प्रामाणिकता के प्रश्न का उत्तर नहीं दे सकता क्योंकि कोई भी हैश की गणना कर सकता है। फ़ाइल को संशोधित करने वाला हमलावर नए हैश की गणना कर सकता है और इसे वैध प्रकाशक जितनी आसानी से पोस्ट कर सकता है। हैशिंग सममित है; रक्षक और हमलावर दोनों की कम्प्यूटेशनल क्षमता समान है।
विश्वसनीय-चैनल की आवश्यकता - चेकसम केवल उतना ही भरोसेमंद क्यों है जितना कि आपको यह कहाँ से मिला है
विश्वसनीय-चैनल की आवश्यकता प्रमुख अंतर्दृष्टि है। एक चेकसम उतना ही भरोसेमंद होता है जितना वह माध्यम जिससे वह आया है। यदि आप प्रकाशक के आधिकारिक CDN से सॉफ़्टवेयर बाइनरी डाउनलोड करते हैं और उसी सर्वर से चेकसम डाउनलोड करते हैं, तो उन्होंने उसी पथ पर यात्रा की। सर्वर से समझौता करने का मतलब है कि एक हमलावर दोनों को नियंत्रित करता है। चेकसम डिलीवरी के दौरान भ्रष्टाचार के खिलाफ सुरक्षा प्रदान करता है - एक क्षतिग्रस्त फ़ाइल मेल नहीं खाएगी - लेकिन स्रोत को नियंत्रित करने वाले हमलावर के खिलाफ नहीं। चेकसम और फ़ाइल विफलता का एक ही बिंदु साझा करते हैं।
यदि चेकसम को अलग-अलग सर्वर पर, अलग-अलग एक्सेस नियंत्रण के साथ अलग-अलग प्रकाशित किया गया था, तो यह अधिक सुरक्षा प्रदान करता है। एक हमलावर जो प्राथमिक साइट से समझौता करता है, उसे नकली मिलान जोड़ी बनाने के लिए दोनों स्थानों से समझौता करना होगा। यह बेहतर है, लेकिन यह अभी भी सुरक्षित रहने वाले दो स्वतंत्र नियंत्रण बिंदुओं पर निर्भर करता है। हमलावर को अब एक के बजाय दो प्रणालियों का उल्लंघन करना होगा, जिससे हमले की लागत बढ़ जाएगी। लेकिन यह अभी भी प्रामाणिकता का प्रमाण नहीं है; यह एक अधिक महँगा हमला है।
हस्ताक्षर एक हैश को एक पहचान से जोड़ते हैं - कैसे एक निजी कुंजी के साथ डाइजेस्ट पर हस्ताक्षर करने से प्रामाणिकता जुड़ती है
एक डिजिटल हस्ताक्षर क्रिप्टोग्राफी का उपयोग करके डेटा को एक पहचान से जोड़कर इसे संबोधित करता है। प्रकाशक एक कुंजीयुग्म उत्पन्न करता है: एक निजी कुंजी जिसे वे गुप्त रखते हैं और एक सार्वजनिक कुंजी जिसे वे प्रकाशित करते हैं। वे डाइजेस्ट की गणना करके और फिर उस डाइजेस्ट को अपनी निजी कुंजी से एन्क्रिप्ट करके फ़ाइल पर हस्ताक्षर करते हैं। परिणाम हस्ताक्षर है. एक उपयोगकर्ता हस्ताक्षर को प्रकाशक की सार्वजनिक कुंजी के साथ डिक्रिप्ट करके सत्यापित करता है और यह जांचता है कि परिणाम प्राप्त फ़ाइल की गणना की गई डाइजेस्ट से मेल खाता है। क्रिप्टोग्राफी एक विषमता पैदा करती है जिसे चेकसम हासिल नहीं कर सकता।
यदि यह काम करता है, तो दो चीजें साबित होती हैं: डेटा प्रकाशक द्वारा हस्ताक्षरित डाइजेस्ट से मेल खाता है, और उस पर हस्ताक्षर करने के लिए उपयोग की जाने वाली निजी कुंजी प्रकाशित सार्वजनिक कुंजी से मेल खाती है। यह साबित करता है कि प्रकाशक ने इसे बनाया है, न कि सिर्फ एक हमलावर ने। सार्वजनिक कुंजी एक सुरक्षित चैनल के माध्यम से आनी चाहिए - आमतौर पर एक विश्वसनीय प्रमाणपत्र प्राधिकारी से प्रमाणपत्र - लेकिन एक बार आपके पास सार्वजनिक कुंजी हो जाने पर, आप उस प्रकाशक से हस्ताक्षर को अनिश्चित काल तक सत्यापित कर सकते हैं। हमले के लिए अब निजी कुंजी चुराने की आवश्यकता है, जो वेब सर्वर से समझौता करने से कहीं अधिक कठिन है।
काम किया गया उदाहरण - तीन खतरे के परिदृश्य (भ्रष्ट दर्पण, समझौता पेज, दुर्भावनापूर्ण अंदरूनी सूत्र) और प्रत्येक कैच में कौन सा चेकसम और हस्ताक्षर
तीन ख़तरे परिदृश्य अंतर दर्शाते हैं। परिदृश्य एक: डाउनलोड मिरर एक यादृच्छिक त्रुटि से दूषित हो गया है। चेकसम इसे पकड़ लेता है; हस्ताक्षर इसे पकड़ लेता है। दोनों समान रूप से अच्छी तरह से काम करते हैं क्योंकि किसी को भी हमलावर को हराने की ज़रूरत नहीं है। परिदृश्य दो: दर्पण से एक हमलावर द्वारा छेड़छाड़ की जाती है जो फ़ाइल और चेकसम को बदल देता है। चेकसम सुरक्षा करने में विफल रहता है; हस्ताक्षर अभी भी काम करता है, क्योंकि हमलावर के पास निजी कुंजी नहीं है और वह वैध हस्ताक्षर नहीं बना सकता है। हमलावर कुछ भी पोस्ट कर सकता है, लेकिन हस्ताक्षर साबित करता है कि यह प्रकाशक का नहीं है।
परिदृश्य तीन: CDN से समझौता किया गया है लेकिन हस्ताक्षर एक अलग चैनल के माध्यम से प्रकाशित किया गया था। CDN पर चेकसम पर भरोसा नहीं किया जा सकता है, लेकिन हस्ताक्षर को सत्यापित करना अभी भी काम करता है, क्योंकि अखंडता जांच क्रिप्टोग्राफ़िक रूप से प्रकाशक की कुंजी से जुड़ी होती है, चैनल से नहीं। हमलावर को अब एक हस्ताक्षर बनाना होगा, जिसके लिए निजी कुंजी की आवश्यकता होगी। हस्ताक्षर ही एकमात्र सत्यापन है जो सर्वर समझौता से बच जाता है। यही कारण है कि प्रामाणिकता के लिए हस्ताक्षर आवश्यक हैं; वे एकमात्र टूल हैं जो चैनल समझौते के बावजूद पहचान साबित करते हैं।
TLS की भूमिका और उसकी सीमाएँ - परिवहन सुरक्षा उड़ान में डाउनलोड की सुरक्षा करती है, प्रकाशक के सर्वर की नहीं
परिवहन सुरक्षा प्रमाणपत्र द्वारा नामित होस्ट से कनेक्शन की सुरक्षा करती है। यह रास्ते में किसी पर्यवेक्षक को डाउनलोड बाइट्स को प्रतिस्थापित करने से रोक सकता है, लेकिन यह समझौता किए गए प्रकाशक की उत्पत्ति को ईमानदार नहीं बना सकता है। यदि वह मूल एक संशोधित संग्रह और वैध TLS पर एक ताजा गणना की गई चेकसम परोसता है, तो दोनों बरकरार रहते हैं और फिर भी हमलावर-नियंत्रित सामग्री का वर्णन करते हैं।
यही कारण है कि परिवहन, अखंडता और प्रामाणिकता अलग-अलग परतें हैं। TLS एक चैनल को सुरक्षित करता है, एक डाइजेस्ट बाइट्स की तुलना करता है और एक हस्ताक्षर एक सत्यापन परिणाम को एक निजी कुंजी के नियंत्रण से जोड़ता है। किसी भी परत को दूसरे द्वारा प्रदत्त संपत्ति को साबित करने के रूप में वर्णित नहीं किया जाना चाहिए, भले ही एक रिलीज वर्कफ़्लो समझदारी से तीनों को जोड़ता हो।
इसमें क्या शामिल नहीं है - प्रमुख वितरण और विश्वास जड़ें, जो हस्ताक्षर का कठिन हिस्सा हैं
कुंजी वितरण वह कठिन सीमा है जिसे यह डाइजेस्ट कैलकुलेटर पार नहीं करता है। एक हस्ताक्षर सत्यापनकर्ता को अभी भी एक प्रामाणिक सार्वजनिक कुंजी या प्रमाणपत्र श्रृंखला और रोटेशन, निरस्तीकरण और स्वीकार्य एल्गोरिदम के लिए एक नीति की आवश्यकता होती है। एक अविश्वसनीय कुंजी के तहत गणितीय रूप से मान्य हस्ताक्षर केवल यह साबित करता है कि उस अविश्वसनीय कुंजी के धारक ने बाइट्स पर हस्ताक्षर किए हैं।
तदनुसार, काम किए गए परिदृश्य वहीं रुक जाते हैं जहां एक विश्वसनीय कुंजी पहले से ही उपलब्ध है। वे प्रमाणपत्र पिनिंग, सार्वजनिक-कुंजी अवसंरचना या रिलीज़-कुंजी समारोह निर्धारित नहीं करते हैं। उन परिनियोजन विकल्पों को अपने स्वयं के समीक्षा किए गए डिज़ाइन की आवश्यकता होती है; ToolAcre सादे डाइजेस्ट की आपूर्ति करता है जिस पर हस्ताक्षर किया जा सकता है, न कि किसी पहचान को मान्य करने के लिए उपयोग किया जाने वाला ट्रस्ट रूट।
टेकअवे: अखंडता के लिए चेकसम, प्रामाणिकता के लिए हस्ताक्षर - ToolAcre SHA हैश कैलकुलेटर डाइजेस्ट की गणना करता है; यह सत्यापित करना कि उन्हें किसने प्रकाशित किया, एक अलग कदम है
ToolAcre SHA हैश कैलकुलेटर इस सत्यापन के अखंडता पक्ष की गणना करता है। डाउनलोड की गई फ़ाइल को हैश करने और प्रकाशित मान की जांच करने के लिए इसका उपयोग करें। यदि वे मेल खाते हैं, तो डाउनलोड दूषित नहीं है। लेकिन अगर वे मेल खाते हैं क्योंकि एक हमलावर ने दोनों को फिर से लिखा है, तो अकेले अखंडता सत्यापन इसे पकड़ नहीं पाएगा। टूल इस सीमा के प्रति ईमानदार है और प्रामाणिकता को सत्यापित करने का दावा नहीं करता है। केवल सत्यनिष्ठा के लिए, चेकसम तेज़ और अच्छे होते हैं। प्रामाणिकता के लिए, आपको हस्ताक्षर की आवश्यकता है। TLS डाउनलोड के लिए ही परिवहन सुरक्षा प्रदान करता है। सर्वर से कनेक्शन एन्क्रिप्टेड और प्रमाणित है, इसलिए नेटवर्क पर कोई हमलावर ट्रांज़िट में फ़ाइल को संशोधित नहीं कर सकता है। हालाँकि, TLS यदि सर्वर से ही छेड़छाड़ हो तो मदद नहीं मिलती। एक समझौता सर्वर किसी भी फ़ाइल को किसी भी सुरक्षित TLS कनेक्शन पर प्रस्तुत कर सकता है। यही कारण है कि एप्लिकेशन-स्तरीय सत्यापन-चेकसम और हस्ताक्षर-परिवहन सुरक्षा से अलग मायने रखते हैं।
सॉफ़्टवेयर रिलीज़ में एक सामान्य पैटर्न चेकसम और हस्ताक्षर दोनों को प्रकाशित करना है। चेकसम सुविधाजनक हैं; उपयोगकर्ता उन्हें एक-लाइन शेल कमांड से शीघ्रता से सत्यापित कर सकते हैं। हस्ताक्षर उन उपयोगकर्ताओं के लिए प्रामाणिकता प्रदान करते हैं जिनके पास प्रकाशक की सार्वजनिक कुंजी है। उपयोगकर्ता त्वरित अखंडता पास के लिए पहले चेकसम की जांच कर सकता है, और फिर प्रामाणिकता के लिए अपने GPG कीरिंग में संग्रहीत कुंजी के विरुद्ध हस्ताक्षर को सत्यापित कर सकता है। दोनों चेक अलग-अलग उद्देश्यों को पूरा करते हैं और गहराई से बचाव के लिए इन्हें स्तरित किया जा सकता है। हस्ताक्षरों का कठिन हिस्सा कुंजी वितरण और विश्वास है। आपको प्रकाशक की सार्वजनिक कुंजी की आवश्यकता है, और आपको यह विश्वास करने की आवश्यकता है कि यह वास्तव में उनकी है। यह वह समस्या है जिसे हल करने के लिए प्रमाणपत्र प्राधिकारी मौजूद हैं: वे प्रकाशक प्रमाणपत्रों पर हस्ताक्षर करते हैं, और रूट CA प्रमाणपत्र ब्राउज़र और ऑपरेटिंग सिस्टम में पहले से लोड होते हैं। एक छोटे प्रोजेक्ट के लिए, आप एक अलग, सख्त वेबसाइट या सार्वजनिक कुंजी सर्वर पर GPG कुंजी प्रकाशित कर सकते हैं। चेकसम सत्यापित करना सस्ता है; हस्ताक्षरों के लिए विश्वास की जड़ों को प्रबंधित करने की आवश्यकता होती है। अतिरिक्त जटिलता प्रामाणिकता की कीमत है।