2012-02-07 32 views
7

में कुंजी (सार्वजनिक/निजी) की एक जोड़ी शामिल करने का सबसे सुरक्षित तरीका है, मैं एंड्रॉइड के लिए एक एप्लीकेशन विकसित कर रहा हूं और मुझे निजी और सार्वजनिक कुंजी की एक जोड़ी के माध्यम से सर्वर के साथ एक सुरक्षित संचार बनाए रखना है। मेरे एपीके में निजी कुंजी को स्टोर करने का सबसे सुरक्षित तरीका कौन सा है? जाहिर है, मैं कोड को खराब करने जा रहा हूं लेकिन मुझे और सुरक्षा चाहिए। मैंने निम्न विकल्प सोचा है:जो एपीके

यदि मैं लेनदेन की जानकारी पर हस्ताक्षर करने के तरीकों के साथ मूल शेयर लाइब्रेरी बनाता हूं, तो एपीके में केवल .so फ़ाइल होनी चाहिए और यह फ़ाइल मशीन कोड में है, इसलिए डिकंपिलेशन हो सकता है मुश्किल है, है ना?

कोई विचार? धन्यवाद

+0

आपके खतरे के मॉडल में हमलावर कौन है? आपके डिवाइस का वैध उपयोगकर्ता? – CodesInChaos

+0

हमलावर उपयोगकर्ता नहीं होगा, समस्या यह है कि ऐप भुगतान सेवाओं तक पहुंच जाएगा और हम एक सुरक्षित ऐप चाहते हैं। एक साधारण एपीके में कोई भी डिकंपाइल कर सकता है, चाबियाँ प्राप्त कर सकता है और भुगतान प्रणाली तक पहुंचने के लिए उनका उपयोग कर सकता है – rdiaz82

+2

आपको अपने एप्लिकेशन को इस तरह से डिज़ाइन करना चाहिए कि जिस उपयोगकर्ता के पास एप्लिकेशन का पूर्ण स्रोत कोड है और सभी एम्बेडेड कुंजियां कुछ भी नहीं कर सकती हैं बुराई। – CodesInChaos

उत्तर

2

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

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

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

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

विकल्प किसी ऐसे स्मार्ट कार्ड के समान समर्पित क्रिप्टोग्राफिक हार्डवेयर डिवाइस का उपयोग करना होगा जो निजी कुंजी को सुरक्षित रूप से स्टोर करेगा लेकिन आपको अभी भी डिवाइस से कुंजी पढ़ने के लिए अपने एप्लिकेशन को अधिकृत करने की समस्या है (उल्लेख नहीं है कहा डिवाइस के साथ इंटरफेसिंग की जटिलता)।

अब, आपको खुद से पूछने के लिए सवाल यह है: "आप निजी कुंजी पढ़ने से रोकने की कोशिश कर रहे हैं?" (अन्य प्रश्न का उत्तर देने के बाद: "क्या आपको वास्तव में क्लाइंट के लिए सार्वजनिक/निजी कुंजी जोड़ी चाहिए")।

+0

ग्राहक पक्ष सार्वजनिक/निजी कुंजी यह सर्वर पक्ष द्वारा मजबूर है। मुझे डेटा के हैश की गणना करनी है, फिर हैश को निजी कुंजी के साथ संहिताबद्ध करें और मेरे डेटा, हैश का परिणाम और सर्वर के लिए सार्वजनिक कुंजी भेजें। यह मेरी मुख्य समस्या है, मैं निजी कुंजी की रक्षा कैसे कर सकता हूं !! :) – rdiaz82

+0

@ rdiaz82, उस स्थिति में आप सत्र के लिए एक नई सार्वजनिक/निजी कुंजी उत्पन्न कर सकते हैं। इस तरह निजी कुंजी रन टाइम पर उत्पन्न होती है और प्रत्येक सत्र के लिए पुनर्नवीनीकरण की जाती है। ऐसा तब तक होता है जब तक सर्वर को किसी भी तरह से पहले से पंजीकृत होने के लिए ग्राहक की सार्वजनिक कुंजी की एक प्रति की आवश्यकता नहीं होती है। –

+1

इस तरह के परिदृश्य में निजी कुंजी आम तौर पर ऐप के उपयोगकर्ता की पहचान करने के लिए जेनरेट की जाती है, न कि सर्वर पर प्रतिक्रियाओं को एन्क्रिप्ट करने के लिए उपयोग की जाने वाली सार्वजनिक कुंजी के समान। इस मामले में, कुंजी को पीढ़ी के बाद डिवाइस पर संग्रहीत किया जाना चाहिए क्योंकि यह उपयोगकर्ता की कुंजी है। – mikebabcock

4

कीस्टोर में कीपैयर स्टोर करें और अपने एपीके में संसाधन के रूप में कीस्टोर को शामिल करें। एंड्रॉइड बाउंसीकास्टल की स्टोर (बीकेएस) प्रारूप को पसंद करता है। कीस्टोर विशेष रूप से इस उद्देश्य के लिए डिज़ाइन किए गए हैं।

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

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

मैं आपको Application Security for the Android Platform पर भी इंगित करूंगा। यह पुस्तक (अस्वीकरण: मैंने पुस्तक लिखी है) एक संपूर्ण अध्याय है जिसमें सुरक्षित एंड्रॉइड ऐप-टू-सर्वर संचार कैसे डिजाइन किया जाए, कोड उदाहरणों के साथ उचित सुरक्षा को कार्यान्वित करने का तरीका बताएं। आप इसे पढ़ना चाह सकते हैं।

+0

आपकी प्रतिक्रिया ने समस्या को हल करने के लिए विभिन्न तरीकों को खोला है। Obfuscation के बावजूद, मुझे लगता है कि कुंजीस्टोर के लिए पासवर्ड अभी भी कोड में दिखाई दे रहा है, इसलिए keystore तक पहुंच प्राप्त करना मुश्किल नहीं है। – rdiaz82

+0

यह सच है। हालांकि ... यह सबसे अच्छा है। यदि डिवाइस पर चल रहे आपके क्लाइंट ऐप को उस स्टोर तक पहुंच की आवश्यकता है जो उस स्टोर तक पहुंचता है, तो उस डिवाइस तक पहुंचने वाला व्यक्ति भी इसका उपयोग कर पाएगा। आप इसे और अधिक कठिन बना सकते हैं। बेशक, आप पासवर्ड को स्टोर नहीं कर सकते हैं और उपयोगकर्ता को चाबियों तक पहुंचने के लिए हर बार टाइप करने के लिए बाध्य कर सकते हैं। आदर्श यूएक्स नहीं है, लेकिन वह पासवर्ड कहीं से आना है। – jeffsix

+0

यह एक बड़ा सौदा है! मुझे क्लाइंट साइड सर्टिफिकेट की रक्षा करने की ज़रूरत है। ऐप खरीदने के लिए है और ग्राहक के बीच सभी लेनदेन (ऐप का उपयोग करने वाले किसी भी व्यक्ति) और सर्वर पर हस्ताक्षर किए जाने चाहिए। मुझे डर है कि कोई भी प्रमाण पत्र निकाल सकता है और सर्वर को वैध लेनदेन भेजना शुरू कर देता है। – rdiaz82

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