इलेक्ट्रॉनिक कुंजी सुरक्षा प्रणालियों का विकास

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

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

संकलित प्रोग्रामिंग भाषाओं (सी, सी ++, पास्कल, डेल्फी, फोरट्रान, आदि) का उपयोग करके विकसित विंडोज-आधारित अनुप्रयोगों की सुरक्षा पर विचार करें।

कार्यक्रम और इलेक्ट्रॉनिक कुंजी के बीच डेटा विनिमय

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

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

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



ऐसी योजना में हमलों का उद्देश्य विभिन्न रक्षा मॉड्यूलों के बीच बातचीत करना है। इलेक्ट्रॉनिक कुंजी ड्राइवर (1) या USB बस चालक (2) के स्तर पर इलेक्ट्रॉनिक कुंजी के लिए अवरोधन अनुरोधों को स्थिर एपीआई पुस्तकालय (3) में कॉल को इंटरसेप्ट करने के विकल्प के विपरीत, आवेदन के प्रत्येक नए संस्करण के पुन: संशोधन की आवश्यकता नहीं होती है।

इलेक्ट्रॉनिक कुंजी चालक पर हमला

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

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



इस तरह की सुरक्षा को व्यवहार में लाने के बाद, सॉफ्टवेयर एमुलेटर यूएसबी बस (2 के हमले के विकल्प) के स्तर पर स्थानांतरित हो गए।

USB बस चालक पर हमला

ऐसे एमुलेटर के निर्माण के लिए इलेक्ट्रॉनिक कुंजी चालक और USB बस चालक के बीच विनिमय प्रोटोकॉल के अध्ययन की आवश्यकता थी। विरोधाभास के रूप में यह लग सकता है, LPT चाबियाँ ऐसी स्थिति में अधिक विश्वसनीय निकला, तब से डोंगल चालक सीधे कंप्यूटर I / O पोर्ट के माध्यम से LPT डोंगल के साथ इंटरैक्ट ड्राइवर को दरकिनार करता है।

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

मैं प्रोटेक्शन का भी उल्लेख करना चाहूंगा, जब डेवलपर्स इलेक्ट्रॉनिक कुंजी की उपस्थिति के लिए एक साधारण चेक तक सीमित होते हैं। यह एक दोष है। एक डिस्सेम्बलर का उपयोग करके, "स्वतंत्रता" को 15 मिनट में इस तरह के कार्यक्रम में प्रस्तुत किया जा सकता है।

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

एपीआई स्टैटिक लाइब्रेरी कॉल इंटरसेप्शन अटैक

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

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

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

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

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



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



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

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



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

निष्कर्ष

विश्वसनीय सुरक्षा के निर्माण के लिए कई सिफारिशें।

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