निजी कुंजी कहाँ संग्रहीत करें?


22

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

हालांकि, अगर मैं कुछ क्लीयरटेक्स्ट को एन्क्रिप्ट करता हूं, तो मैं कुंजी कहां स्टोर करूं? कुछ भी जो सॉफ्टवेयर तक पहुंच है, एक निर्धारित हमलावर तक पहुंच जाएगा, चाहे वह किसी भी स्तर का हो:

  • मान लें कि कुंजी फ़ाइल सिस्टम के सुरक्षा मॉडल द्वारा संरक्षित है; लेकिन क्या (दुर्भावनापूर्ण) सुपरसर्स, या प्लेटफ़ॉर्म जो ऐसी निष्ठा प्रदान नहीं करते हैं?
  • या कुंजी सॉफ्टवेयर बायनेरिज़ में हार्डकोड किया गया है, लेकिन इसे हमेशा विघटित किया जा सकता है और खुले स्रोत सॉफ़्टवेयर या व्याख्या किए गए कोड के बारे में क्या है?
  • यदि कुंजी उत्पन्न होती है, तो इस तरह के एल्गोरिथ्म को नियतात्मक (संभवतः) होना चाहिए और फिर वही समस्या बीज पर लागू होती है।
  • आदि।

क्रिप्टोग्राफी केवल अपनी श्रृंखला की सबसे कमजोर कड़ी के रूप में मजबूत है और यह एक बहुत ढीली की तरह लगता है! यह मानते हुए कि यह काम के लिए सही उपकरण है (मुझे हास्य करें), तो कोई भी इस तरह की जानकारी को मजबूती से कैसे सुरक्षित कर सकता है?


नौकरी के लिए सही उपकरण के बारे में: संभवत:, उदाहरण के लिए - सेवा पहुंच (DBs, प्रमाणीकरण सर्वर, आदि) के मामले में, आप एक सेवा खाते के साथ इस स्तर पर पहुंच को प्रतिबंधित करेंगे, शायद कुछ सेवा-स्तर के साथ ऑडिटिंग, आदि और इसलिए क्लीयरटेक्स्ट में क्रेडेंशियल्स होना ऐसी चिंता नहीं है।

मेरे लिए, हालांकि, यह अभी भी अपर्याप्त लगता है: मैं नहीं चाहता कि कोई भी जहाँ वे नहीं होना चाहिए, उसके आसपास प्रहार करें!


6
आपको सुरक्षा के विभिन्न पद मिल सकते हैं । ब्याज के लिए। मैं ध्यान दूंगा कि कुछ चौखटे और भाषाएँ इसके लिए विशेष सहायता प्रदान करती हैं (जैसे, .net में एन्क्रिप्टेड कॉन्फ़िगरेशन अनुभाग)।
ब्रायन

9
दुर्भाग्य से, वहाँ बहुत ज्यादा नहीं है आप एक "दुर्भावनापूर्ण सुपरसर्स" के खिलाफ कर सकते हैं। चूँकि आपके सॉफ़्टवेयर को कुंजियों तक पहुँच की आवश्यकता है, इसलिए कोई भी सुपरयुसर तब से करेगा जब तक कि वे किसी भी एसीएल के बारे में बदलने / बाईपास करने की क्षमता रखते हैं जो आप जगह में डाल सकते हैं।
DXM

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

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

3
दुर्भावनापूर्ण ग्राहकों के बारे में सबसे अच्छा आप उन्हें एक अच्छी तरह से परिभाषित सेवा एपीआई तक सीमित कर सकते हैं, न कि उन्हें डीबी तक सीधे पहुंच प्रदान करते हैं। आप वास्तव में उससे आगे कुछ नहीं कर सकते, क्योंकि आप क्लाइंट में कोई रहस्य नहीं छिपा सकते।
कोडइन्चोस

जवाबों:


25

सबसे पहले, मैं खुद को एक सुरक्षा विशेषज्ञ के रूप में संदर्भित नहीं करूंगा, लेकिन मैं इस प्रश्न का उत्तर देने की स्थिति में हूं। मुझे जो पता चला उसने मुझे थोड़ा हैरान कर दिया: पूरी तरह से सुरक्षित प्रणाली जैसी कोई चीज नहीं है । ठीक है, मुझे लगता है कि एक पूरी तरह से सुरक्षित प्रणाली एक होगी जहां सर्वर सभी बंद हो जाते हैं :)

उस समय मेरे साथ काम करने वाले किसी व्यक्ति ने घुसपैठियों को बार उठाने के संदर्भ में एक सुरक्षित प्रणाली डिजाइन करने का वर्णन किया । तो, सुरक्षित करने की प्रत्येक परत पर हमले का अवसर कम हो जाता है।

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

प्रश्न स्पष्ट है इसलिए मैं आपके प्रत्येक अंक को संबोधित करने का प्रयास करूंगा:

मान लें कि कुंजी फ़ाइल सिस्टम के सुरक्षा मॉडल द्वारा संरक्षित है; लेकिन क्या (दुर्भावनापूर्ण) सुपरसर्स, या प्लेटफ़ॉर्म जो ऐसी निष्ठा प्रदान नहीं करते हैं?

हां, यदि आप Windows Key Store या पासवर्ड एन्क्रिप्टेड TLS निजी कुंजी का उपयोग करते हैं, तो आप उन उपयोगकर्ताओं के संपर्क में आते हैं जिनके पास निजी कुंजियों के लिए पासवर्ड (या एक्सेस) है। लेकिन, मुझे लगता है कि आप सहमत होंगे कि बार उठाता है। फ़ाइल सिस्टम ACLs (यदि ठीक से लागू किया गया है) सुरक्षा का एक अच्छा स्तर प्रदान करते हैं। और आप व्यक्तिगत रूप से अपने सुपर उपयोगकर्ताओं को जानने और जानने की स्थिति में हैं।

या कुंजी सॉफ्टवेयर बायनेरिज़ में हार्डकोड किया गया है, लेकिन इसे हमेशा विघटित किया जा सकता है और खुले स्रोत सॉफ़्टवेयर या व्याख्या किए गए कोड के बारे में क्या है?

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

यदि कुंजी उत्पन्न होती है, तो इस तरह के एल्गोरिथ्म को नियतात्मक (संभवतः) होना चाहिए और फिर वही समस्या बीज पर लागू होती है।

हां, अनिवार्य रूप से तब एल्गोरिथ्म निजी कुंजी बनाने के लिए निजी महत्वपूर्ण जानकारी बन जाता है। तो, अब इसे संरक्षित करने की आवश्यकता होगी।

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

तो, सवाल यह है कि आपका सिस्टम (और, इसलिए निजी कुंजी) कितना सुरक्षित है? आपके सिस्टम में कितना ऊंचा है, क्या बार को उठाने की आवश्यकता है?

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

कई HSM रखरखाव और सुविधाओं के व्यवस्थापक से कुंजी कार्ड का उपयोग करते हैं। कुंजी कार्ड का एक कोरम (९ में से ५ बताता है) को कुंजी को बदलने के लिए भौतिक रूप से सर्वर में रखना होगा। इसलिए, यह बार को ऊंचा उठा देता है, अगर केवल एक ब्रीच की अनुमति देता है, तो सुपर उपयोगकर्ताओं का कोरम ढह जाता है।

वहाँ सॉफ्टवेयर समाधान हो सकता है जो एक HSM के समान सुविधाएँ प्रदान करते हैं, लेकिन मुझे पता नहीं है कि वे क्या हैं।

मुझे पता है कि यह केवल सवाल का जवाब देने के लिए किसी तरह जाता है, लेकिन मुझे उम्मीद है कि इससे मदद मिलेगी।


2
"ठीक है, मुझे लगता है कि एक पूरी तरह से सुरक्षित प्रणाली एक होगी जहां सर्वर सभी बंद हो जाते हैं" और उन्हें चालू करने का कोई तरीका मौजूद नहीं है।
स्टिंगजैक 20

2

आप जो चाहते हैं वह नहीं किया जा सकता है।

मान लें कि कुंजी फ़ाइल सिस्टम के सुरक्षा मॉडल द्वारा संरक्षित है; लेकिन क्या (दुर्भावनापूर्ण) सुपरसर्स, या प्लेटफ़ॉर्म जो ऐसी निष्ठा प्रदान नहीं करते हैं?

आप मूल रूप से दुर्भावनापूर्ण लोगों से सुरक्षा चाहते हैं। आपके मॉडल में, किसी बिंदु पर किसी को कुंजी तक पहुंच प्राप्त होगी। यदि वह व्यक्ति दुर्भावनापूर्ण है तो क्या होगा? यदि आप दुर्भावनापूर्ण हैं तो क्या होगा? देखें, जैसा कि आप कहते हैं कि समस्या बिल्कुल भी नहीं है सिवाय इसके कि आपके पास चाबी नहीं है।

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


2

यह उन समस्याओं में से एक है जिन्हें वास्तव में उसी स्तर पर हल नहीं किया जा सकता है जो इसे बनाया गया था। हमें कुछ मूलभूत दर्शनों को वापस ले जाना होगा, और संकल्प की उम्मीद में कैस्केड का पालन करना होगा।

पहला दर्शन "ग्राहक पर कभी भरोसा नहीं करना" है, और निकटता से संबंधित "यदि आप वास्तव में एक रहस्य रखना चाहते हैं, तो किसी को भी न बताएं!"

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

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

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

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

लेकिन दुनिया में अधिकांश चीजों के लिए, उपयोगकर्ता से गुप्त रखने की चिंता किए बिना काम करना सबसे अच्छा है । इसके बजाय, सबसे अच्छा अभ्यास यह है कि उपयोगकर्ता को केवल गुप्त पर रहने दें, इसे सुरक्षित रखने में मदद करने के लिए अपनी ज़िम्मेदारी बनाएं (उदाहरण के लिए, उपयोगकर्ता नाम और पासवर्ड), और यदि गुप्त हो जाता है या दुर्व्यवहार होता है तो इसके नकारात्मक जोखिम को सीमित करें।

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

अब अगर आपको डीआरएम की तरह कुछ करने की ज़रूरत है, जहाँ आपकी ज़रूरत एक सीक्रेट स्टोर करने की है, तो यह वास्तव में सॉफ्टवेयर के उपयोग को नियंत्रित करने पर आधारित है, यह पूरी तरह से एक और स्थिति है


TLDR: उपयोगकर्ता से रहस्य न रखें, उपयोगकर्ता के साथ रहस्य रखें।


1

वर्तमान में मैं जिन प्रणालियों का उपयोग करता हूं उनमें से एक इस तरह से काम करती है।

  • मैं प्रमाणीकरण सेवा के लॉगिन फॉर्म के साथ शुरू करता हूं। यह सुनिश्चित करने के लिए दो-कारक प्रमाणीकरण का उपयोग करता है कि मैं वह हूं जो मैं दावा करता हूं कि मैं हूं।
  • मुझे एक अस्थायी एसएसएल प्रमाणपत्र प्राप्त होता है जिसका उपयोग मैं संरक्षित सेवा तक पहुँचने के लिए कर सकता हूँ। सेवा उन प्रमाणपत्रों का ट्रैक रखती है जिन्हें वह स्वीकार करता है।
  • मेरे एक्सचेंजों को इस सर्टिफिकेट को ईवसड्रॉपिंग से एन्क्रिप्ट किया गया है। इसे समाप्त करने की कोशिश करना बहुत उपयोगी नहीं है क्योंकि यह समाप्त हो जाएगा।
  • प्रमाण पत्र जल्दी (कई घंटों में) समाप्त हो जाता है, लेकिन इतनी जल्दी नहीं कि मुझे हर बातचीत के लिए एक पासवर्ड प्रदान करने की आवश्यकता न हो।
  • प्रमाण पत्र को दूसरी तरफ तुरंत निरस्त किया जा सकता है।

बेशक संरक्षित सेवा मेरी पहुंच से कहीं बाहर है। यह मेरी मशीन पर एक अलग खाते (और संभवतः एक कंटेनर में) के तहत चल सकता है, लेकिन मेरे पास सुपरसुअर विशेषाधिकार हैं और फिर प्रतिबंधों को दरकिनार करने की कोशिश कर सकता है।

मूल रूप से यदि आपके पास एक दुर्भावनापूर्ण सुपरयुसर है, तो सभी दांव बंद हैं। और आपको अपने खतरे के मॉडल में एक दुर्भावनापूर्ण सुपरयुजर की उपस्थिति माननी चाहिए

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

यदि आपकी संरक्षित सेवा इतनी कीमती नहीं है कि इस तरह के उपायों को करने में सक्षम हो, तो ओएस आपको जो भी एन्क्रिप्टेड कुंजी स्टोर देता है, उसके साथ जाएं: विंडोज, लिनक्स और ओएसएक्स दोनों में कीरिंग कार्यान्वयन है।


-1

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

एक अन्य तरीका यह हो सकता है कि सुरक्षा प्रणाली डेटाबेस खाता हो जो इसे स्व। बहुत स्केलेबल नहीं है ...

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.