2011-08-08 12 views
33

एमएसडीएन SecureString सामग्री के अनुसार एन्क्रिप्टेड अतिरिक्त सुरक्षा के लिए है ताकि यदि प्रोग्राम डिस्क पर बदल दिया गया है तो स्ट्रिंग सामग्री को स्नीफ नहीं किया जा सकता है।सिक्योरस्ट्रिंग "एन्क्रिप्टेड" कैसे है और अभी भी उपयोग योग्य है?

इस तरह के एन्क्रिप्शन को मैं कैसे सोच सकता हूं? एल्गोरिदम तय किया जाएगा और इसलिए या तो जाने-माने या कटौती योग्य (उद्योग एल्गोरिदम में व्यापक रूप से उपयोग किए जाने वाले सात में से एक कहते हैं) और कार्यक्रम में कहीं भी एक कुंजी होना चाहिए। तो हमलावर एन्क्रिप्टेड स्ट्रिंग ला सकता है, कुंजी ला सकता है और डेटा डिक्रिप्ट कर सकता है।

इस तरह के एन्क्रिप्शन उपयोगी कैसे हो सकता है?

+0

यह नहीं कहा गया कि यह सुरक्षित था, केवल * सुरक्षित * –

+0

@ मार्क पीटर्स: यही कारण है कि मैं * अतिरिक्त सुरक्षा * कहता हूं। – sharptooth

+0

आप इसे क्रिप्टो.एसई पर पूछ सकते हैं - बहुत ही विषय पर –

उत्तर

15

मैं DPAPI के बारे में एक लेख से उद्धृत कर रहा हूं जिसका उपयोग कुंजी प्राप्त करने के लिए किया जाता है। यह SecureString के बारे में आपके अधिकांश प्रश्नों का उत्तर देना चाहिए।

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

DAPI कुंजी प्रबंधन

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

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

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

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

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

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

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

+1

+1 हमें हॉकी –

+0

के बारे में बताने के लिए +1 है। मुझे लगता है कि पोस्ट किए गए लेख से दूर करने की मुख्य बात यह है कि "अधिकांश भाग के लिए डीएपीआई कुंजी प्रबंधन प्रक्रिया अजेय है और आपको आमतौर पर इसके बारे में चिंता करने की आवश्यकता नहीं है "। यह वहीं मुझे एक कस्टम समाधान की तरफ झुकता है। अच्छी पर्याप्त सुरक्षा हमेशा अच्छी नहीं है, ठीक है, काफी अच्छा है। –

+0

नोट: 05/18/2017 तक, आलेख लिंक 404 लौटाता है: http://www.dsmyth.net/wiki/Print.aspx?Page=StudyNotes_DAPI – iokevins

11

मैंने इसके लिए कोड में एक बिंदु देखा और यह अपने गंदे काम करने के लिए विंडोज के advapi32 का उपयोग करता है। तो कुंजी एप्लिकेशन की स्मृति में संग्रहीत नहीं है।

[ReliabilityContract(Consistency.WillNotCorruptState, Cer.Success)] 
[DllImport("advapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)] 
internal static int SystemFunction040([In, Out] SafeBSTRHandle pDataIn, [In] uint cbDataIn, [In] uint dwFlag) 

कौन सा बेहतर जाना जाता है के रूप में RtlEncryptMemory.

यह RtlDecryptMemory (SystemFunction041) के साथ decrypts।

मुझे यकीन है कि संकलक SecurityCriticalAttribute के साथ कुछ भी करता है।

संपादित करें यह 4.0 का उपयोग कर प्रतिबिंबित किया गया था। अन्य संस्करण अलग हो सकते हैं।

2

DPAPI का जादू द्वारा:

इस वर्ग अपने डेटा डेटा संरक्षण एपीआई (DPAPI) की रक्षा की स्मृति मॉडल का उपयोग कर संग्रहीत करता है। दूसरे शब्दों में, डेटा हमेशा अपने एन्क्रिप्टेड रूप में होता है जबकि इसे सेक्योरस्ट्रिंग के अंदर संग्रहीत किया जाता है। एन्क्रिप्शन कुंजी स्थानीय सुरक्षा प्राधिकरण उपप्रणाली (LSASS.EXE) द्वारा प्रबंधित की जाती है, और डीपीएपीआई के माध्यम से, डेटा इंटरप्रोसेस संचार के माध्यम से डिक्रिप्ट किया जा सकता है।

7

के रूप में दूसरों को पहले से ही उत्तर दिया है, SecureString की सामग्री DPAPI का उपयोग करके एन्क्रिप्ट कर रहे हैं, तो कुंजी अपने आवेदन में संग्रहीत नहीं हैं, वे ओएस का हिस्सा हैं। मैं 100% सकारात्मक नहीं हूं, लेकिन मुझे लगता है कि SecureString उपयोगकर्ता-विशिष्ट कुंजी का उपयोग करता है, ताकि अगर किसी अन्य प्रक्रिया को स्मृति के ब्लॉक तक पहुंच प्राप्त हो, तो उसे केवल डिक्रिप्ट करने के लिए समान प्रमाण-पत्रों के तहत चलना होगा डीपीएपीआई का उपयोग कर सामग्री। यहां तक ​​कि यदि नहीं, तो मशीन कुंजी (सिद्धांत में) स्ट्रिंग को किसी अन्य सिस्टम में स्थानांतरित होने पर आसानी से डिक्रिप्ट होने से रोकती है।

SecureString के साथ अधिक महत्वपूर्ण यह है कि & जब आप इसका उपयोग करते हैं। इसका उपयोग स्ट्रिंग डेटा को स्टोर करने के लिए किया जाना चाहिए जिसे समय की "विस्तारित" अवधि के लिए स्मृति में बनाए रखा जाना चाहिए, लेकिन जिनकी अक्सर उनके डिक्रिप्ट फॉर्म में आवश्यकता नहीं होती है। किसी बिंदु पर, आपको इसे नियमित रूप से पुराने System.String, या System.Char[] में डिक्रिप्ट करना होगा। यह तब होता है जब यह स्मृति में सबसे कमजोर होता है। यदि आप इसे अक्सर करते हैं, तो आपके पास एकत्रित होने की प्रतीक्षा में स्मृति में घूमते हुए डिक्रिप्टेड स्ट्रिंग की कई प्रतियां होती हैं।

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

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