एमआईटी पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 14: "एसएसएल और एचटीटीपीएस", भाग 1

मैसाचुसेट्स इंस्टीट्यूट ऑफ टेक्नोलॉजी। व्याख्यान पाठ्यक्रम # 6.858। "कंप्यूटर सिस्टम की सुरक्षा।" निकोलाई ज़ेल्डोविच, जेम्स मिकेंस। 2014 साल

कंप्यूटर सिस्टम सुरक्षा सुरक्षित कंप्यूटर सिस्टम के विकास और कार्यान्वयन पर एक कोर्स है। व्याख्यान खतरे के मॉडल को कवर करते हैं, हमले जो सुरक्षा से समझौता करते हैं, और हाल के वैज्ञानिक कार्यों के आधार पर सुरक्षा तकनीक। विषय में ऑपरेटिंग सिस्टम (OS) सुरक्षा, सुविधाएँ, सूचना प्रवाह प्रबंधन, भाषा सुरक्षा, नेटवर्क प्रोटोकॉल, हार्डवेयर सुरक्षा और वेब अनुप्रयोग सुरक्षा शामिल हैं।

व्याख्यान 1: "परिचय: खतरे के मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 2: "हैकर हमलों का नियंत्रण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 3: "बफर ओवरफ्लो: शोषण और संरक्षण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 4: "पृथक्करण का पृथक्करण" भाग 1 / भाग 2 / भाग 3
व्याख्यान 5: "सुरक्षा प्रणालियाँ कहाँ से आती हैं?" भाग 1 / भाग 2
व्याख्यान 6: "अवसर" भाग 1 / भाग 2 / भाग 3
व्याख्यान 7: "मूल ग्राहक सैंडबॉक्स" भाग 1 / भाग 2 / भाग 3
व्याख्यान 8: "नेटवर्क सुरक्षा मॉडल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 9: "वेब अनुप्रयोग सुरक्षा" भाग 1 / भाग 2 / भाग 3
व्याख्यान 10: "प्रतीकात्मक निष्पादन" भाग 1 / भाग 2 / भाग 3
व्याख्यान 11: "उर / वेब प्रोग्रामिंग भाषा" भाग 1 / भाग 2 / भाग 3
व्याख्यान 12: नेटवर्क सुरक्षा भाग 1 / भाग 2 / भाग 3
व्याख्यान 13: "नेटवर्क प्रोटोकॉल" भाग 1 / भाग 2 / भाग 3
व्याख्यान 14: "एसएसएल और एचटीटीपीएस" भाग 1 / भाग 2 / भाग 3

अब हम देखेंगे कि इंटरनेट पर नेटवर्क कनेक्शन की सुरक्षा के लिए क्रिप्टोग्राफ़िक प्रोटोकॉल का उपयोग कैसे किया जाता है और वे आम तौर पर नेटवर्क कारकों के साथ कैसे संपर्क करते हैं। इससे पहले कि हम विवरण में जाएं, मैं आपको याद दिलाना चाहता हूं कि बुधवार को एक परीक्षा होगी, लेकिन इस दर्शक में नहीं, बल्कि वाकर में, 3 मंजिल पर, नियमित व्याख्यान के समय।



इसलिए, आज हम इस बारे में बात करेंगे कि नेटवर्क कनेक्शन की सुरक्षा के लिए इंटरनेट क्रिप्टोग्राफी का उपयोग कैसे करता है, और दो निकट से संबंधित विषयों पर विचार करें।

पहला यह है कि कर्बरोस सिस्टम की तुलना में क्रिप्टोग्राफिक रूप से सुरक्षित कनेक्शन बड़े पैमाने पर हैं, जिसे हमने पिछले व्याख्यान में कवर किया था, सुरक्षा करता है। दूसरा यह है कि इस क्रिप्टोग्राफ़िक सुरक्षा को कैसे एकीकृत किया जाए, जो नेटवर्क स्तर पर, पूरे एप्लिकेशन में प्रदान किया गया है, और वेब ब्राउज़र क्रिप्टोग्राफ़िक प्रोटोकॉल द्वारा प्रदान की गई सुरक्षा के उपयोग की गारंटी कैसे देता है। ये विषय बारीकी से संबंधित हैं, इसलिए यह पता चलता है कि नेटवर्क संचार की सुरक्षा प्रदान करना काफी आसान है, क्योंकि क्रिप्टोग्राफी हमेशा काम करती है। लेकिन इसे क्रिप्टोग्राफी के आसपास एक सिस्टम बनाने की तुलना में ब्राउज़र में एकीकृत करना अधिक कठिन काम है।

इससे पहले कि हम इस चर्चा में गोता लगाएँ, मैं आपको क्रिप्टोग्राफी के उन मूल तत्वों की याद दिलाना चाहता हूँ जिनका हम उपयोग करेंगे।

कर्बेरोस पर हमारे आखिरी व्याख्यान में, हमने सममित क्रिप्टोग्राफी का उपयोग किया, या
एन्क्रिप्शन और डिक्रिप्शन। इसका अर्थ यह है कि आपके पास एक गुप्त कुंजी K और दो फ़ंक्शन हैं। इस प्रकार, आप कुछ डेटा ले सकते हैं, चलो इसे पी कहते हैं, यह एक सादे पाठ है जिसे आप एन्क्रिप्शन फ़ंक्शन को लागू कर सकते हैं, और यह कुछ कुंजी के का कार्य है। और यदि आप इस सादे पाठ को एन्क्रिप्ट करते हैं, तो आपको एन्क्रिप्टेड पाठ सी मिलेगा। इसी तरह, हम एक डिक्रिप्शन फ़ंक्शन डी है जो उसी कुंजी के का उपयोग करता है, जिसके परिणामस्वरूप एन्क्रिप्टेड पाठ सी सादे पाठ पी में बदल जाएगा। यह वह आदिम है जिसके चारों ओर केर्बरोस बनाया गया था।



लेकिन यह पता चला है कि अन्य प्राइमेटिव हैं जो आज की चर्चा के लिए उपयोगी होंगे, और जिन्हें असममित एन्क्रिप्शन और डिक्रिप्शन कहा जाता है। यहाँ विचार एन्क्रिप्शन और डिक्रिप्शन के लिए अलग-अलग कुंजी है। आइए देखें कि यह इतना उपयोगी क्यों है।

यहाँ एक फ़ंक्शन E है, जो संदेशों के एक निश्चित समूह P को एक निश्चित सार्वजनिक कुंजी pk के साथ एन्क्रिप्ट कर सकता है, परिणामस्वरूप एन्क्रिप्टेड पाठ C. प्राप्त करने के लिए इसे फ़ंक्शन D के साथ डिक्रिप्ट करने के लिए, आपको बस संबंधित गुप्त कुंजी sk निर्दिष्ट करने और स्रोत पाठ P प्राप्त करने की आवश्यकता है।



असममित एन्क्रिप्शन की सुविधा यह है कि आप इंटरनेट पर एक सार्वजनिक कुंजी प्रकाशित कर सकते हैं और लोग आपके लिए संदेश एन्क्रिप्ट कर सकते हैं, लेकिन आपको उनके संदेशों को डिक्रिप्ट करने के लिए एक गुप्त कुंजी की आवश्यकता होती है। आज हम देखेंगे कि प्रोटोकॉल में इसका उपयोग कैसे किया जाता है। व्यवहार में, आप अक्सर सार्वजनिक कुंजी क्रिप्टोग्राफी का उपयोग थोड़े अलग तरीके से करेंगे। उदाहरण के लिए, संदेशों को एन्क्रिप्ट और डिक्रिप्ट करने के बजाय, आपको संदेशों पर हस्ताक्षर या सत्यापन करने की आवश्यकता हो सकती है।

यह पता चला है कि कार्यान्वयन के स्तर पर ये संबंधित ऑपरेशन हैं, लेकिन एपीआई आवेदन स्तर पर वे कुछ अलग दिख सकते हैं। उदाहरण के लिए, आप अपने गुप्त कुंजी स्के के साथ संदेश एम पर हस्ताक्षर कर सकते हैं और कुछ हस्ताक्षर एस प्राप्त कर सकते हैं। फिर आप इस संदेश को संबंधित सार्वजनिक कुंजी pk के साथ सत्यापित कर सकते हैं और परिणामस्वरूप एक तार्किक ध्वज प्राप्त कर सकते हैं यदि हस्ताक्षर S संदेश M के लिए सही है।



यहां कुछ अपेक्षाकृत सहज गारंटी दी गई है जो इन सुविधाओं को प्रदान करती हैं। यदि, उदाहरण के लिए, आपने यह हस्ताक्षर प्राप्त किया है और इसे सही तरीके से सत्यापित किया गया है, तो इसका मतलब है कि इसे किसी के द्वारा सही गुप्त कुंजी के साथ उत्पन्न किया जाना था। क्या यह स्पष्ट है?

तो फिर आइए यह पता लगाने की कोशिश करें कि केर्बरोस की तुलना में बड़े पैमाने पर नेटवर्क कनेक्शन की सुरक्षा कैसे की जाती है। केर्बरोस में, हमारे पास एक काफी सरल मॉडल था, जहां सभी उपयोगकर्ताओं और सर्वरों ने केडीसी ऑब्जेक्ट के साथ किसी प्रकार के कनेक्शन का उपयोग किया था, जिसमें उपयोगकर्ताओं, सेवाओं और उनकी कुंजियों की यह विशाल तालिका थी। जब भी कोई उपयोगकर्ता किसी सर्वर से बात करना चाहता है, तो उसे केडीसी से इस विशालकाय तालिका के आधार पर उसकी जरूरत के टिकट बनाने के लिए कहना चाहिए।



तो यह काफी सरल मॉडल की तरह लगता है। तो हमें कुछ और क्यों चाहिए? Kerberos साइटों के साथ काम करने के लिए पर्याप्त क्यों नहीं है? इंटरनेट सभी कनेक्शनों को सुरक्षित करने के लिए केर्बरोस का विशेष रूप से उपयोग क्यों नहीं करता है?

आपने सही उत्तर दिया - क्योंकि एकमात्र केडीसी को सभी पर भरोसा करना चाहिए, और यह बुरा है। यदि आपको लगता है कि एक निश्चित मशीन बिल्कुल सुरक्षित है, तो आपको समस्या हो सकती है।

शायद MIT के लोग KDC द्वारा प्रबंधित स्थानीय नेटवर्क पर किसी पर भरोसा करने को तैयार हैं, लेकिन हर कोई इंटरनेट पर नहीं।

और दूसरे छात्र का उत्तर भी सही है - इतनी बड़ी संख्या में चाबियों का प्रबंधन करना बहुत मुश्किल है। वास्तव में, एकल केडीसी का निर्माण करना बहुत मुश्किल हो सकता है जो दुनिया में सभी लोगों के लिए एक अरब कुंजी या दस अरब कुंजियों का प्रबंधन कर सकता है। पूरे इंटरनेट के लिए करबरोस का उपयोग करने की एक और जटिलता यह है कि सभी उपयोगकर्ताओं के पास एक कुंजी होनी चाहिए, या केडीसी द्वारा ज्ञात होनी चाहिए। यदि आप करबरोस डेटाबेस में खाता नहीं रखते हैं, तो आप कुछ सर्वर से कनेक्ट करने के लिए हमारे संस्थान में कर्बेरॉस का उपयोग भी नहीं कर सकते हैं। जबकि पूरे इंटरनेट के लिए यह अपेक्षा करना काफी उचित है कि जब आप कंप्यूटर पर जाते हैं, तो यह बिल्कुल नहीं जानता कि आप कौन हैं, लेकिन यह आपको अमेज़ॅन वेबसाइट पर जाने की अनुमति देगा, जो क्रिप्टोग्राफी द्वारा संरक्षित है।



हाँ?

कई अन्य चीजें हैं जो आप क्रिप्टोग्राफिक प्रोटोकॉल से उम्मीद करते हैं, और हम देखेंगे कि वे एसएसएल में कैसे दिखाई देते हैं। लेकिन मुख्य विचार यह है कि यह समाधान केर्बोस और एसएसएल या टीएलएस के लिए समान है। जब आप उल्लेख करते हैं कि आप सही हैं तो मूल केर्बरोस प्रोटोकॉल जो हम व्याख्यान सामग्री में पढ़ते हैं, बहुत समय पहले विकसित किए गए थे। और अगर हम उन्हें आधुनिक इंटरनेट के लिए उपयोग करना चाहते हैं, तो उन्हें कुछ बदलने की आवश्यकता होगी। आपके पास और क्या विचार हैं, हमें कर्बेरोस का उपयोग क्यों नहीं करना चाहिए?

यह सही है, एक्सेस को पुनर्स्थापित करते समय स्केलिंग की समस्या होती है, और संभवत: नए उपयोगकर्ताओं को पंजीकृत करते समय, क्योंकि आपको व्यक्तिगत रूप से कुछ खाता कार्यालय में जाना होगा और वहां एक खाता प्राप्त करना होगा। और क्या?

छात्र: कर्बेरोस सर्वर हमेशा ऑनलाइन होना चाहिए।

प्रोफेसर: हाँ, यह एक और समस्या है। हमने कुछ प्रकार के प्रबंधन मुद्दों को सूचीबद्ध किया है, लेकिन प्रोटोकॉल स्तर पर, केडीसी हमेशा ऑनलाइन होना चाहिए, क्योंकि यह वास्तव में सेवाओं के साथ आपके किसी भी इंटरैक्शन के लिए मध्यस्थ के रूप में कार्य करता है। इसका मतलब है कि हर बार जब आप किसी नई वेबसाइट पर जाते हैं, तो आपको केडीसी से बात करने की आवश्यकता होती है। सबसे पहले, यह प्रदर्शन के मामले में एक अड़चन होगी। अन्य प्रकार के स्केलेबिलिटी की तरह, यह सिद्धांत प्रदर्शन की स्केलेबिलिटी को बढ़ावा देगा, जबकि ऊपर सूचीबद्ध सिद्धांत केवल प्रबंधन की स्केलेबिलिटी को बढ़ावा देते हैं।



तो, हम इन सिद्धांतों का उपयोग करके इस समस्या को कैसे हल कर सकते हैं? केडीसी का उपयोग बंद करने के लिए कुंजी एन्क्रिप्शन का उपयोग करने का विचार है।

आइए पहले यह पता करें कि क्या आप एक सुरक्षित कनेक्शन स्थापित कर सकते हैं यदि आप दूसरी तरफ के कुछ सार्वजनिक कुंजी जानते हैं। और फिर हम देखेंगे कि हम इस प्रोटोकॉल में पार्टियों के प्रमाणीकरण के लिए केडीसी सार्वजनिक कुंजी संस्करण को कैसे कनेक्ट करते हैं। यदि आप केडीसी का उपयोग नहीं करना चाहते हैं, तो आप सार्वजनिक कुंजी क्रिप्टोग्राफी के साथ निम्नलिखित कर सकते हैं: किसी भी तरह से कनेक्शन के दूसरी तरफ भागीदार की सार्वजनिक कुंजी का पता लगाएं। तो, केर्बरोस में, अगर मैं एक फ़ाइल सर्वर से कनेक्ट करना चाहता हूं, तो मुझे बस फ़ाइल सर्वर की सार्वजनिक कुंजी कहीं से पता है। एक नए व्यक्ति के रूप में, मुझे यह कहते हुए एक प्रिंटआउट मिलता है कि फ़ाइल सर्वर की सार्वजनिक कुंजी ऐसी है और मैं इसे कनेक्ट करने के लिए उपयोग कर सकता हूं।

आप जिस फ़ाइल सर्वर से कनेक्ट करना चाहते हैं, उसकी सार्वजनिक कुंजी के लिए आप बस संदेश को एन्क्रिप्ट कर सकते हैं। लेकिन यह पता चला है कि व्यवहार में, इन सार्वजनिक कुंजियों के साथ ये ऑपरेशन काफी धीमा है। वे सममित एन्क्रिप्शन कुंजी की तुलना में परिमाण के धीमी के कई आदेश हैं। इसलिए व्यवहार में, आप आमतौर पर सार्वजनिक एन्क्रिप्शन का उपयोग छोड़ना चाहते हैं।

इस प्रकार, एक विशिष्ट प्रोटोकॉल इस तरह दिख सकता है। आपके पास ए और बी है, वे संवाद करना चाहते हैं, और ए को सार्वजनिक कुंजी बी पता है। इसी समय, ए कुछ प्रकार की सत्र कुंजी एस उत्पन्न करता है, बस इसके लिए एक यादृच्छिक संख्या का चयन करता है। तब A S सत्र कुंजी B भेजने वाला है, इसलिए यह Kerberos जैसा दिखता है। हम B के लिए सत्र कुंजी S एन्क्रिप्ट करने जा रहे हैं।

अगर आपको याद है, ऐसा करने के लिए केर्बरोस में, हमें एक केडीसी की आवश्यकता थी क्योंकि A को B की कुंजी नहीं पता थी या उसे इसे जानने की अनुमति नहीं थी, क्योंकि यह एक रहस्य है जिसे केवल B ही जान सकता है। लेकिन एक सार्वजनिक कुंजी के साथ, आप कर सकते हैं। तुरंत, बस इस Bspk सार्वजनिक कुंजी के साथ गुप्त को एन्क्रिप्ट करना, और संदेश भेजना B. अब B इस संदेश को डिक्रिप्ट कर सकता है और कह सकता है: मुझे इस गुप्त कुंजी का उपयोग करने की आवश्यकता है। अब हमारे पास एक संचार चैनल है जहां सभी संदेशों को इस गुप्त कुंजी एस के साथ एन्क्रिप्ट किया गया है।



तो इस प्रोटोकॉल में कुछ उपयोगी विशेषताएं हैं। सबसे पहले, हमें केडीसी ऑनलाइन होने और हमारे लिए एक सत्र कुंजी उत्पन्न करने की आवश्यकता से छुटकारा मिला। यदि हम कनेक्शन में से किसी एक पक्ष को उत्पन्न करते हैं और फिर केडीसी का उपयोग किए बिना दूसरे पक्ष के लिए इसे एन्क्रिप्ट करते हैं, तो हम केवल प्रेषित जानकारी की गोपनीयता सुनिश्चित कर सकते हैं।

एक और अच्छी बात यह विश्वास है कि केवल B, A से B तक भेजे गए संदेशों को पढ़ सकता है, क्योंकि केवल B ही इस संदेश को डिक्रिप्ट कर सकता है। इसलिए, बी के पास संबंधित निजी कुंजी एस होना चाहिए।

छात्र: क्या यह मायने रखता है कि यह कुंजी कौन देता है - उपयोगकर्ता या सर्वर?

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

छात्र: क्या हमलावर बार-बार संदेश भेजने के लिए एक कुंजी का उपयोग कर सकता है?

प्रोफेसर: हाँ, समस्या यह हो सकती है कि मैं सिर्फ इन संदेशों को फिर से भेज सकता हूं, और ऐसा लगेगा कि यह एक संदेश बी फिर से भेज रहा है, और इसी तरह।

इसलिए, आमतौर पर इस समस्या का हल यह है कि कनेक्शन के दोनों पक्ष S उत्पन्न करने में शामिल हैं और यह सुनिश्चित करता है कि हम जिस कुंजी का उपयोग करते हैं वह "ताज़ा" है। क्योंकि यहां, आकृति में, वास्तव में बी कुछ भी उत्पन्न नहीं करता है, इसलिए ये प्रोटोकॉल संदेश हर बार समान दिखते हैं।

आमतौर पर ऐसा होता है कि एक पक्ष S की तरह एक यादृच्छिक संख्या चुनता है, और फिर दूसरी तरफ, B, एक यादृच्छिक संख्या को भी चुनता है, आमतौर पर गैर के रूप में। दो नंबर और एक कुंजी है जो वास्तव में केवल एक पक्ष द्वारा चयनित नहीं है, यह एक हैश है जिसे दोनों पक्षों ने संयुक्त बातचीत के लिए चुना है। हैश के अलावा, आप डिफी-हेलमैन प्रोटोकॉल का उपयोग कर सकते हैं, जिसकी हमने पिछले व्याख्यान में जांच की थी, जिसकी बदौलत आपको पहले गोपनीयता मिलती है। यह केवल दो यादृच्छिक संख्याओं की तुलना में अधिक जटिल गणित है जिसने इन दोनों पक्षों को चुना है। लेकिन फिर आपको मूल साझा गुप्त कुंजी के रूप में इतनी अच्छी संपत्ति मिलेगी, एन्क्रिप्शन डेटा ट्रांसमिट करते समय डिक्रिप्शन कुंजी को स्थानांतरित करने की आवश्यकता को समाप्त कर देगा।

इस प्रकार बार-बार होने वाले हमलों से बचा जा सकता है। B नॉनस उत्पन्न करता है और फिर वास्तविक गुप्त कुंजी S 'सेट करता है, जिसका उपयोग इस गैर के साथ गुप्त कुंजी S को हैश करने के लिए किया जाता है। और, निश्चित रूप से, बी को गैर-ए को वापस भेजना होगा ताकि यह पता चल सके कि जब वे दोनों कुंजी पर सहमत होते हैं तो क्या होता है।



एक और समस्या यह है कि कोई वास्तविक प्रमाणीकरण नहीं है। A जानता है कि B कौन है, या कम से कम जानता है कि कौन डेटा को डिक्रिप्ट कर सकता है। लेकिन B को इस बात का कोई अंदाजा नहीं है कि दूसरी तरफ कौन है, क्या यह किसी अन्य के रूप में, या किसी और की तरह की प्रतिकूल स्थिति है। इसे सार्वजनिक कुंजी दुनिया में कैसे तय किया जा सकता है?

ऐसा करने के कई तरीके हैं। एक संभावना इस संदेश को शुरू में हस्ताक्षर करने की है, क्योंकि हमारे पास यह अच्छा संकेत सिद्धांत है। तो हम शायद एक गुप्त कुंजी के साथ इस पर हस्ताक्षर कर सकते हैं। यह साइन बस एक हस्ताक्षर प्रदान करता है, लेकिन संभवतः आप इसे असाइन करते हैं, और आप यह संदेश भी प्रदान करते हैं।

तब B को पता होना चाहिए कि हस्ताक्षर को सत्यापित करने के लिए A एक सार्वजनिक कुंजी है। लेकिन अगर B को पता है कि A एक सार्वजनिक कुंजी है, तो B को पूरा यकीन है कि A वह है जिसने यह संदेश भेजा है।



एक और चीज जो आप कर सकते हैं वह है एन्क्रिप्शन में विश्वास। तो शायद बी, ए को नॉन बैक भेज सकता है, ए द्वारा प्रदान की गई सार्वजनिक कुंजी के साथ इसे एन्क्रिप्ट कर सकता है और उसके बाद ही ए नॉनस को डिक्रिप्ट कर सकता है और अंतिम सत्र कुंजी एस उत्पन्न कर सकता है। तो कुछ ट्रिक्स हैं जो आप कर सकते हैं। यह कैसे क्लाइंट सर्टिफिकेट आज इंटरनेट ब्राउज़र में काम करते हैं।

इस प्रकार, ए के पास एक गुप्त कुंजी है, और इसलिए, जब आप एक व्यक्तिगत एमआईटी प्रमाण पत्र प्राप्त करते हैं, तो आपका ब्राउज़र एक लंबे समय तक रहने वाली गुप्त कुंजी बनाता है और इसके लिए एक प्रमाण पत्र प्राप्त करता है। और हर बार जब आप वेब सर्वर को एक अनुरोध भेजते हैं, तो आप इस तथ्य को साबित करते हैं कि आप अपने उपयोगकर्ता प्रमाणपत्र की गुप्त कुंजी जानते हैं, और फिर शेष कनेक्शन के लिए गुप्त कुंजी S सेट करें।

ये ऐसी समस्याएं हैं जो प्रोटोकॉल स्तर पर काफी आसानी से तय हो जाती हैं। हालाँकि, उपरोक्त सभी के लिए आधार यह है कि सभी पक्ष एक-दूसरे की सार्वजनिक कुंजी जानते हैं। आप किसी की सार्वजनिक कुंजी का पता कैसे लगा सकते हैं? मान लीजिए कि मैं किसी वेबसाइट से जुड़ना चाहता हूं, मेरे पास एक URL है जिससे मैं कनेक्ट करना चाहता हूं, या एक होस्ट नाम, मैं कैसे पता लगा सकता हूं कि कौन सी सार्वजनिक कुंजी इससे मेल खाती है?

इसी तरह, यदि मैं अपने ग्रेड को देखने के लिए MIT सर्वर से जुड़ता हूं, तो सर्वर को कैसे पता चलेगा कि मेरी सार्वजनिक कुंजी को किसी अन्य MIT छात्र की सार्वजनिक कुंजी से अलग करना चाहिए?

यह मुख्य मुद्दा है जिसे केडीसी ने संबोधित किया है। वास्तव में, केडीसी ने हमारे लिए दो समस्याओं को हल किया। सबसे पहले, उन्होंने एक संदेश (Ebspk (S)) उत्पन्न किया, एक सत्र कुंजी बनाई और इसे सर्वर के लिए एन्क्रिप्ट किया। हमने अब सार्वजनिक-कुंजी क्रिप्टोग्राफी बनाकर इसे ठीक किया है। लेकिन हमें पहले प्रदान किए गए कर्बरोस क्रिप्टोग्राफ़िक कुंजियों के मुख्य स्ट्रिंग नामों से मेल खाना चाहिए।

HTTPS दुनिया में ऐसी चीजों के लिए एक TLC प्रोटोकॉल है। इसका अर्थ यह है कि हम प्रक्रिया के कुछ पहलुओं पर भरोसा करना जारी रखेंगे जो इन विशाल तालिकाओं का समर्थन करते हैं जो प्रक्रिया प्रतिभागियों के नाम को क्रिप्टोकरंसीज के नक्शे में मैप करते हैं। योजना यह है कि हमारे पास प्रमाणन प्राधिकरण नाम की कोई चीज होगी, जिसे नेटवर्क सुरक्षा पर सभी प्रकार के साहित्य में सीए द्वारा दर्शाया गया है। यह CA तार्किक रूप से तालिका का भी समर्थन करता है, जिसके एक भाग में सभी प्रतिभागियों के नाम प्रदर्शित होते हैं, और दूसरे में - संबंधित सार्वजनिक कुंजी। इस केंद्र और केर्बरोस के बीच मुख्य अंतर यह है कि इस सीए को सभी लेनदेन के लिए ऑनलाइन नहीं होना है।
केर्बरोस में, किसी के साथ जुड़ने या किसी और की कुंजी खोजने के लिए, आपको केडीसी से बात करने की आवश्यकता है। इसके बजाय, सीए की दुनिया में, वे ऐसा करते हैं।



यदि आपके पास यहाँ किसी प्रकार का नाम है और तालिका के किसी अन्य भाग में संबंधित कुंजी है, तो प्रमाणन प्राधिकरण केवल उन संदेशों पर हस्ताक्षर करने जा रहा है जो इस तालिका में कुछ पंक्तियों में मौजूद हैं। इस प्रकार, प्रमाणन प्राधिकरण के पास यहां अपनी निजी और सार्वजनिक कुंजी होनी चाहिए। वह उस सिस्टम पर अन्य उपयोगकर्ताओं के लिए संदेश खोजने के लिए एक गुप्त कुंजी का उपयोग करेगा जिस पर आप भरोसा कर सकते हैं।

इसलिए यदि आपके पास CA डेटाबेस में "नाम + कुंजी" रिकॉर्ड है, तो CA एक संदेश बनाएगा कि यह नाम इस सार्वजनिक कुंजी से मेल खाता है और इस संदेश को अपनी CA निजी कुंजी के साथ हस्ताक्षर करता है।



यह आपको केर्बरोस के समान चीजों को करने की अनुमति देता है, लेकिन साथ ही हम सभी लेनदेन के लिए ऑनलाइन सीए खोजने की आवश्यकता से छुटकारा पा लेते हैं। और, यह वास्तव में बहुत अधिक स्केलेबल होगा। यह वही है जिसे आमतौर पर एक प्रमाण पत्र कहा जाता है। स्केलेबिलिटी को इस तथ्य से सुनिश्चित किया जाता है कि इस प्रणाली का उपयोग करने वाले ग्राहक या किसी अन्य के लिए, एक स्रोत से प्रदान किया गया प्रमाण पत्र किसी अन्य स्रोत से प्रमाण पत्र के लिए नीच नहीं है। यह प्रमाणीकरण प्राधिकरण की गुप्त कुंजी द्वारा हस्ताक्षरित है। तो आप वास्तव में एक प्रमाणीकरण प्राधिकारी या यहां सूचीबद्ध किसी अन्य पार्टी से संपर्क किए बिना इसकी प्रामाणिकता को सत्यापित कर सकते हैं।

यह उसी तरह काम करता है। सर्वर जिसे आप बात करना चाहते हैं, वह प्रमाण पत्र को संग्रहीत करता है जो इसे मूल रूप से प्रमाणन प्राधिकरण से प्राप्त हुआ है। और हर बार जब आप इससे कनेक्ट होते हैं, तो सर्वर आपको बताता है: “ठीक है, यहाँ मेरा प्रमाण पत्र है। यह इस सीए द्वारा हस्ताक्षरित किया गया था। आप हस्ताक्षर सत्यापित कर सकते हैं और बस यह सुनिश्चित कर सकते हैं कि यह मेरी सार्वजनिक कुंजी है और यह मेरा नाम है। ”

दूसरी ओर, ग्राहक प्रमाणपत्रों के साथ भी यही बात होती है। जब कोई उपयोगकर्ता वेब सर्वर से जुड़ता है, तो उसका क्लाइंट प्रमाणपत्र इंगित करता है कि आपकी सार्वजनिक कुंजी उस गुप्त कुंजी से मेल खाती है जो मूल रूप से ब्राउज़र में उत्पन्न हुई थी। इस प्रकार, सर्वर से कनेक्ट करते समय, आप एमआईटी प्रमाणीकरण प्राधिकरण द्वारा हस्ताक्षरित एक प्रमाण पत्र प्रस्तुत करने जा रहे हैं, जो इंगित करता है कि आपका उपयोगकर्ता नाम इस सार्वजनिक कुंजी से मेल खाता है। , , , , Athena.

: , ?

: , , – , ? - , , , , . - , . . , VeriSign. US Postal Service CA, , . , CA , KDC.

, , Kerberos. , , KDC. , KDC, , . , , . CA , KDS.

: ?

: , . , , KDC, . , . , , . , , , . Kerberos, . Kerberos , . , , . , , . , .

, . , , CA - , . , amazon.com, amazon.com. CA, . , , , .



. , CA , , , , - , . , , . - , amazon.com, , - .

, -, , , , . , . «» , , .

, . -, CRL, ertificate Revocation List. . , - , . , , , : «, , , - . , ».

, , , CRL, , web-, CRL. , - , , . , , , , , .

, . , . , . , . , CRL, - .

, ? , . , CRL .

, , , Kerberos, KDC. CA , . , « SSL », OCSP. CA KDC. , , , , , , - . , OCSP, : «, . , »? , CRL . , , . , , .

26:30 मि।

MIT पाठ्यक्रम "कंप्यूटर सिस्टम सुरक्षा"। व्याख्यान 14: "एसएसएल और एचटीटीपीएस", भाग 2


पाठ्यक्रम का पूरा संस्करण यहां उपलब्ध है ।

हमारे साथ बने रहने के लिए धन्यवाद। क्या आप हमारे लेख पसंद करते हैं? अधिक दिलचस्प सामग्री देखना चाहते हैं? एक आदेश रखकर या अपने दोस्तों को इसकी अनुशंसा करके हमें समर्थन दें, एंट्री-लेवल सर्वरों के अनूठे एनालॉग पर हैबर उपयोगकर्ताओं के लिए 30% छूट जो हमने आपके लिए ईजाद की है: VPS (KVM) E5-2650 v4 (6 कोर) 10GB DDR4 240GB SSD 1Gbps से पूरा सच $ 20 या सर्वर को कैसे विभाजित करें? (विकल्प RAID1 और RAID10 के साथ उपलब्ध हैं, 24 कोर तक और 40GB DDR4 तक)।

VPS (KVM) E5-2650 v4 (6 करोड़) 10GB DDR4 240GB SSD 1Gbps दिसंबर तक मुफ्त में जब छह महीने की अवधि के लिए भुगतान करते हैं, तो आप यहां ऑर्डर कर सकते हैं ।

डेल R730xd 2 बार सस्ता? केवल हमारे पास 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps नीदरलैंड और यूएसए में $ 249 से 100 टीवी है ! इन्फ्रास्ट्रक्चर Bldg का निर्माण कैसे करें के बारे में पढ़ें । एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?