2012-05-15 7 views
9

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

  1. DSACryptoServiceProvider के साथ एक सार्वजनिक और निजी कुंजी बनाएं।
  2. आवेदन संसाधन के रूप में सार्वजनिक कुंजी जोड़े
  3. एक अद्यतन
  4. निजी कुंजी
  5. संदेश हैश और आवेदन करने के लिए अद्यतन का उपयोग कर अद्यतन के डीएसए हैश जाओ बनाएँ (इन अनुमान पकड़ा जा सकता है/परिवर्तित)
  6. सत्यापित करें हैश है सार्वजनिक कुंजी का उपयोग कर सही।
  7. तो सत्यापित अपडेट लागू

अद्यतन एक exe है और इसलिए निष्पादित किया जाएगा मुझे यकीन है कि किसी को बदल देता है या इसे से छेड़खानी करने वाले अगर यह निष्पादित नहीं कर रहा है बनाना चाहते हैं।

संपादित करें: सार्वजनिक कुंजी के रूप में अद्यतन बिंदु 6 वास्तव में हैश उत्पन्न नहीं करता है, केवल यह सत्यापित करता है। मुझे लगता है कि यह हिस्सा है कि मैं सुरक्षा के साथ संघर्ष कर रहा हूं।

+2

यह बिल्कुल सही एल्गोरिदम है, सिवाय इसके कि आप अपनी निजी कुंजी के साथ _hash_ नहीं करते हैं; आप एक हैश उत्पन्न करते हैं और फिर अपनी निजी कुंजी के साथ हैश_ को एन्क्रिप्ट करें। प्राप्तकर्ता हैश को डिक्रिप्ट और सत्यापित करने के लिए प्राप्तकर्ता आपकी _public_ कुंजी का उपयोग करता है। मैं यह भी मान रहा हूं कि आपकी निजी कुंजी एक अलग माध्यम (एक यूएसबी कुंजी या गैर-नेटवर्क कंप्यूटर) पर रहता है। :-) आपकी निजी कुंजी को गुप्त रखा जाना चाहिए, लेकिन अन्य सभी घटकों (अद्यतन, हैश, और आपकी सार्वजनिक कुंजी) को सुरक्षित रखने की आवश्यकता नहीं है। –

+0

धन्यवाद एडम, बस कुछ बिंदुओं के बारे में मुझे लगता है कि मैं याद कर रहा हूं। मैं निजी कुंजी के बिना DSACryptoProvider से हैश कैसे प्राप्त करूं? मैंने सोचा है कि हैश = DSACryptoServiceProvider.fromxmlstring (Privatekey) .signdata (fileToGetHashFrom) - दूसरा बिंदु। मुझे नहीं लगता था कि मैं डीएसए के साथ डेटा एन्क्रिप्ट कर सकता हूं, क्या मुझे कुछ और इस्तेमाल करना चाहिए? साथ ही आप आम तौर पर सार्वजनिक कुंजी के साथ डेटा एन्क्रिप्ट नहीं करते हैं और एक निजी कुंजी के साथ डिक्रिप्ट नहीं करते हैं। उस मामले में मेरी कुंजी गलत तरीके से है? क्षमा करें अगर मैं यहाँ बेवकूफ हूं ;-) – Oli

+2

@Oli डिजिटल हस्ताक्षर बनाने को अक्सर 2-चरणीय प्रक्रिया के रूप में वर्णित किया जाता है जिसमें 1) डेटा के एक हैश को हस्ताक्षर करने के लिए उत्पन्न किया जाता है, फिर 2) हैश * को बदलकर * निजी कुंजी, इस तरह से इसे सार्वजनिक कुंजी का उपयोग करके सत्यापित किया जा सकता है और जाली नहीं जा सकती है। जनरेट/सत्यापन प्रक्रिया की एक तरफा प्रकृति एन्क्रिप्शन/डिक्रिप्शन के समानताएं होती है, केवल "रिवर्स" में सार्वजनिक और निजी कुंजी का उपयोग करती है। 'DSACryptoServiceProvider' इन सभी विवरणों का बिल्कुल उसी तरह से ख्याल रखेगा जैसा आपने टिप्पणी की है, लेकिन मुझे लगता है कि एडम का मुद्दा यह है कि निजी कुंजी का उपयोग हैश उत्पन्न करने के लिए नहीं किया जाता है। – shambulator

उत्तर

1

आपका दृष्टिकोण अच्छा दिखता है। शेष प्रश्न यह है कि ग्राहक पर आपका आवेदन कितना सुरक्षित है। क्या कोई मौका है कि कोई निष्पादन योग्य के साथ छेड़छाड़ कर सकता है? शायद एप्लिकेशन संसाधन में सार्वजनिक कुंजी स्विच करें?

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

संबंधित मुद्दे