क्या पूर्ण डिवाइस एन्क्रिप्शन Google और सरकार से मेरे डेटा की सुरक्षा करता है?


13

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

एक एंड्रॉइड उपयोगकर्ता के रूप में, क्या ऐसी ही संभावना है (अधिमानतः थर्ड पार्टी के बजाय ओएस में बनाया गया है) जिसे मैं Google और मेरे डिवाइस निर्माता से समान सुरक्षा प्राप्त करने के लिए उपयोग कर सकता हूं? मुझे पता है कि मेरी सेटिंग में "पूर्ण डिवाइस एन्क्रिप्शन" है, लेकिन क्या यह Google आदि को इसे एक्सेस करने से रोकता है?

संदर्भ के लिए, मेरा डिवाइस एंड्रॉइड लॉलीपॉप चलाता है और वनप्लस टू है। अगर मार्शमैलो जैसे अन्य संस्करण मुझे ऐसा करने की अनुमति देते हैं तो यह ठीक है।

जवाबों:


10

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

एन्क्रिप्ट की गई कुंजी को संग्रहीत करना

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

यहां तक ​​कि अगर किसी के पास आपके एन्क्रिप्टेड मास्टर कुंजी की एक प्रति है, तो वे इसे आपके डिवाइस के SoC से TEE कुंजी के बिना डिक्रिप्ट नहीं कर सकते हैं।

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


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

1
@eldarerathis क्या मैंने सुना है कि iPhone 6 और नए भी ओईएम अपडेट से सुरक्षित हैं, क्योंकि पासवर्ड सत्यापन ( समयबद्ध देरी / तालाबंदी सहित ) पूरी तरह से हार्डवेयर में लागू होते हैं। मैं क्या पूछ रहा हूं कि क्या एंड्रॉइड कुछ ऐसा ही करता है, या यदि यह विशुद्ध रूप से एक सॉफ्टवेयर लॉकआउट है - जो निश्चित रूप से फर्मवेयर अपडेट द्वारा बाईपास किया जा सकता है। मैं यह भी पूछ रहा हूं कि क्या बूटलोडर्स के साथ कोई एंड्रॉइड-आधारित फोन मौजूद है जो उपयोगकर्ता द्वारा निर्दिष्ट पासकोड के बिना अपडेट को मना कर दिया जाता है - जो सॉफ्टवेयर लॉकआउट अवधि को दरकिनार कर देगा।
बॉब

1
फिर भी रीफ़्रैशिंग का एक अन्य तरीका यह है कि अपडेट की अनुमति देने से पहले डिक्रिप्शन (w / उपयोगकर्ता पासवर्ड) की आवश्यकता होती है या नहीं । दूसरे शब्दों में, डिक्रिप्शन कुंजी (उपयोगकर्ता डेटा के अनिवार्य मिटाए बिना) द्वारा स्थापित (ओईएम, हस्ताक्षरित) अपडेट हैं?
बॉब

1
@ मेरे ज्ञान के अनुसार, एंड्रॉइड को अपडेट प्रक्रिया को करने के लिए डिक्रिप्शन पासवर्ड की आवश्यकता नहीं होती है, क्योंकि यह केवल /userdataविभाजन को एन्क्रिप्ट करता है , न कि उन विभाजनों को जो अपडेट वास्तव में ( /systemऔर /bootआम तौर पर) को संशोधित करता है । यह iPhone 5 (और निम्न) के समान नाव में बहुत अधिक है।
एल्डररैथिस

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

-1

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


क्या आप स्क्रीन लॉक पिन लंबाई की सीमा से अवगत हैं? तदनुसार अपने उत्तर को रीबूट करने पर विचार करें
beeshyams

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