Google Cloud Key Vault Service

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

लेखक: शब्सी वॉलफ़िश
वर्शन की तारीख: 06-03-2018

ध्यान दें: इस दस्तावेज़ पर अब भी काम चल रहा है. साथ ही, इसे लागू करने की जानकारी पर अब भी काम किया जा रहा है. जैसे-जैसे सिस्टम बेहतर होगा और ज़्यादा दस्तावेज़ तैयार किए जा सकेंगे, हम इस व्हाइट पेपर को ज़्यादा जानकारी के साथ अपडेट करेंगे. खास तौर पर, ओपन सोर्स रिलीज़ के साथ.

खास जानकारी

आम तौर पर, डेटा की निजता को पक्का करने के लिए एन्क्रिप्शन का इस्तेमाल किया जाता है. इसके लिए, ऐसे पासवर्ड का इस्तेमाल करना ज़रूरी होता है जिनमें एन्ट्रॉपी की वैल्यू ज़्यादा हो, ताकि हमले करने वाले को पासवर्ड का अनुमान न लग पाए. ज़्यादा एंट्रॉपी ज़रूरी है, क्योंकि ऐन्क्रिप्शन स्कीम को ब्रूट फ़ोर्स अटैक से बचाना होता है. यह अटैक तब तक सभी संभावित गुप्त पासवर्ड को आज़माता रहता है, जब तक कि सही पासवर्ड न मिल जाए. कंप्यूटिंग पावर की मौजूदा उपलब्धता को देखते हुए, क्रिप्टोग्राफ़िक सीक्रेट के लिए कम से कम एन्ट्रापी की ज़रूरत 70 से 80 बिट के आस-पास हो सकती है. हालांकि, इंसानों के लिए ¹ एन्ट्रॉपी वाले पासवर्ड या अन्य गोपनीय जानकारी को याद रखना और भरोसेमंद तरीके से याद करना बहुत मुश्किल होता है. खास तौर पर, अगर इनका इस्तेमाल कभी-कभार किया जाता है. हालांकि, ज़्यादा एन्ट्रॉपी वाले पासवर्ड का बार-बार इस्तेमाल करना मुश्किल और थकाऊ होता है. इससे हमें एक मुश्किल समस्या का सामना करना पड़ता है: अगर हमें गुप्त जानकारी को "नॉलेज फ़ैक्टर" बनाना है, जिसे उपयोगकर्ता याद रख सके, तो एन्क्रिप्शन टेक्नोलॉजी की मदद से निजी डेटा को कैसे सुरक्षित रखा जा सकता है? कई वजहों से, इस समस्या को हल करना बहुत मुश्किल है. इसलिए, Cloud Storage की सेवाएं आम तौर पर सिर्फ़ उन पासवर्ड से डेटा एन्क्रिप्ट करती हैं जिन्हें Cloud Storage की सेवा देने वाली कंपनी मैनेज करती है. ऐसा इसलिए किया जाता है, ताकि उपयोगकर्ता को अपने पासवर्ड याद रखने की ज़रूरत न पड़े.

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

इस व्हाइट पेपर में, भरोसेमंद हार्डवेयर मॉड्यूल (THMs) का इस्तेमाल करके, Cloud Key Vault सेवा बनाने के हमारे तरीके के बारे में बताया गया है. सीकेवी सेवा को पहली बार लागू करने के पीछे हमारा मकसद, रिकवरी पासकोड को सुरक्षित रखना है. इसके लिए, हम उपयोगकर्ता के Lock Screen Knowledge Factor (LSKF) का इस्तेमाल करेंगे. LSKF, स्मार्टफ़ोन को अनलॉक करने के लिए इस्तेमाल किया जाने वाला गुप्त पिन, पासवर्ड या स्वाइप पैटर्न होता है. इंसान अपने एलएसकेएफ़ को भरोसेमंद तरीके से याद रख सकते हैं. साथ ही, आम तौर पर ऐसे एलएसकेएफ़ सीक्रेट में, हमलावर के लिए ज़रूरत के मुताबिक एन्ट्रापी होती है. हमलावर के पास, सीक्रेट को ऐक्सेस करने के लिए बहुत कम कोशिश करने का विकल्प होता है. इसलिए, ये सीकेवी सेवा के लिए सही होते हैं.

क्लाउड की-वॉल्ट सेवा का पहला इस्तेमाल, क्लाइंट-साइड एन्क्रिप्शन की सुविधा वाले Android बैकअप को चालू करने के लिए किया जाएगा. पहले, Android डिवाइस पर लोकल तौर पर एन्क्रिप्ट की गई फ़ाइलों के लिए, उपयोगकर्ता के एलएसकेएफ़ से सुरक्षित की गई कुंजी का इस्तेमाल किया जाता था. हालांकि, क्लाउड में सेव की गई (और एन्क्रिप्ट की गई) उन फ़ाइलों के बैकअप को एलएसकेएफ़ से सुरक्षित नहीं किया जाता था. Cloud Key Vault, पहली बार Cloud में सेव किए गए Android बैकअप के लिए भी, लॉक स्क्रीन की सुरक्षा की सुविधा चालू करता है. इसका मतलब है कि Google के सर्वर के पास, एन्क्रिप्ट (सुरक्षित) किए गए बैकअप के कॉन्टेंट को ऐक्सेस करने या उसे वापस लाने की सुविधा नहीं है. सिर्फ़ उपयोगकर्ता के एलएसकेएफ़ वाला डिवाइस ही बैकअप को डिक्रिप्ट (सुरक्षित से सामान्य में बदलना) कर सकता है.

मुख्य कॉन्सेप्ट

शुरुआत में, Cloud Key Vault सेवा के लिए सिर्फ़ Android 9 Pie ऑपरेटिंग सिस्टम पर क्लाइंट प्लैटफ़ॉर्म का इस्तेमाल किया जा सकता है. इस व्हाइट पेपर में क्लाइंट का मतलब, Google Play services के साथ Android 9 Pie ऑपरेटिंग सिस्टम पर काम करने वाले डिवाइस से है. सर्वर साइड ट्रांज़िशन की सुविधा, खास तौर पर चुने गए Google सर्वर पर लागू होती है. इन सर्वर में एक अतिरिक्त Titan चिप² इंस्टॉल होता है. Google की डिज़ाइन की गई टाइटन चिप, हमारे भरोसेमंद हार्डवेयर मॉड्यूल में हार्डवेयर कॉम्पोनेंट के तौर पर काम करती है. हमने इसे खास तौर पर, कस्टम बूटलोडर और फ़र्मवेयर के साथ उपलब्ध कराया है. यह हमारे प्रोटोकॉल और सुरक्षा लागू करने के तरीकों को लागू करता है. इनके बारे में यहां बताया गया है. हम हार्डवेयर की पुष्टि करने की तकनीकों का इस्तेमाल करते हैं, ताकि यह पक्का किया जा सके कि हमारा प्रोटोकॉल सचमुच Titan हार्डवेयर पर चल रहा है.

सीकेवी सेवा को अरबों³ Android डिवाइसों से आने वाले ट्रैफ़िक को मैनेज करने के लिए स्केल करना होगा. साथ ही, यह भी ज़रूरी है कि हार्डवेयर से जुड़ी गड़बड़ियों (जैसे, बर्न-आउट चिप) की वजह से उपयोगकर्ता का ज़्यादा डेटा न मिटे या डेटा सेंटर के रखरखाव की वजह से लंबे समय तक सेवाएं न बंद हों. इस वजह से, Titan चिप वाले सर्वर को एक साथ ग्रुप में बांटा जाता है. हर ग्रुप में कई अलग-अलग THM होते हैं. इनमें से हर एक में एक ही पासकोड की कॉपी होती है. किसी कोहॉर्ट को अलग-अलग डेटा सेंटर में बांटा जाएगा, ताकि यह पक्का किया जा सके कि सिस्टम, उपलब्धता और भरोसेमंदता के लक्ष्यों को पूरा कर सके. स्केले करने के लिए, क्लाइंट को कई अलग-अलग कोहॉर्ट में बांटा जाएगा, ताकि हम उपलब्ध कोहॉर्ट की संख्या बढ़ाने के लिए, सिर्फ़ ज़्यादा सर्वर जोड़कर सेवा की क्षमता में बदलाव कर सकें.

अब हम Cloud Key Vault सेवा के आर्किटेक्चर के मुख्य कॉम्पोनेंट के बारे में बताने के लिए तैयार हैं.

आर्किटेक्चर के कॉम्पोनेंट / शब्दावली

लॉक स्क्रीन के लिए नॉलेज फ़ैक्टर (एलएसकेएफ़): यह एक ऐसा पासवर्ड होता है जिसे याद रखना आसान हो. जैसे, छोटा पिन, 3 x 3 बिंदुओं के ग्रिड पर स्वाइप पैटर्न या पासवर्ड. इस पासवर्ड का इस्तेमाल, डिवाइस को स्थानीय तौर पर अनलॉक करने की सुविधा को सुरक्षित रखने के लिए किया जाता है. साथ ही, इसे उपयोगकर्ता के डिवाइस के स्क्रीन लॉक के लिए, पुष्टि करने का मुख्य (या "मज़बूत") फ़ैक्टर माना जाता है.

क्लाइंट: असली उपयोगकर्ता का ऐसा डिवाइस जिस पर Android 9 Pie ऑपरेटिंग सिस्टम और Google Play services या इससे मिलता-जुलता सॉफ़्टवेयर काम कर रहा हो.

Android फ़्रेमवर्क: हम Android 9 Pie या उसके बाद के वर्शन में मौजूद एपीआई के बारे में बताने के लिए, इस सामान्य शब्द (या सिर्फ़ फ़्रेमवर्क) का इस्तेमाल करते हैं. इसका मतलब, किसी भी पुरानी रिलीज़ के बारे में बताना नहीं है.

Google Play services: यह सेवाओं और ऐप्लिकेशन का एक कलेक्शन है, जो उपयोगकर्ता के डिवाइस पर काम करता है. इससे, डिवाइस को Google के खाता सिस्टम और कस्टम सर्वर एपीआई के साथ काम करने में मदद मिलती है.

रिकवरी एजेंट: यह एक सिस्टम ऐप्लिकेशन है, जो Android 9 Pie डिवाइस (या मिलते-जुलते डिवाइस) पर, उपयोगकर्ता-स्पेस में Google Play services के हिस्से के तौर पर काम करता है. रिकवरी एजेंट की यह ज़िम्मेदारी है कि वह अलग-अलग प्रोटोकॉल के क्लाइंट साइड को लागू करे. साथ ही, ज़रूरत पड़ने पर Android ऑपरेटिंग सिस्टम के साथ इंटरफ़ेस करे, ताकि LSKF से जुड़े किसी भी प्रोटोकॉल मैसेज को तैयार किया जा सके.

खाता वापस पाने का दावा: जब उपयोगकर्ता को रिकवरी पासकोड वापस पाना हो, तो उसे रिकवरी पासकोड पाने का दावा करना होगा. इसमें, एलएसकेएफ़ की एन्क्रिप्ट की गई वह कॉपी होती है जिसके बारे में उपयोगकर्ता का दावा होता है कि वह उसे जानता है. आम तौर पर, उपयोगकर्ता को अपने पुराने डिवाइस का एलएसकेएफ़ डालने के लिए कहा जाएगा. ऐसा उस नए डिवाइस पर किया जाएगा जिस पर पुराने डिवाइस की रिकवरी कुंजी को ऐक्सेस करने की कोशिश की जा रही है.

रिकवरी पासकोड: यह एक क्रिप्टोग्राफ़िक पासकोड है, जिसे Cloud Key Vault सेवा से सुरक्षित किया जाता है. इसका इस्तेमाल, क्लाइंट डिवाइस पर डेटा को एन्क्रिप्ट (सुरक्षित) करने और उसकी पुष्टि करने के लिए किया जाता है. रिकवरी पासकोड को Vault में डालने के बाद (नीचे देखें), क्लाइंट के डेटा को एन्क्रिप्ट करने के लिए इसका इस्तेमाल करने के बाद, लोकल कॉपी को मिटाया जा सकता है.

क्लाउड की सेवा देने वाली कुंजी का तिजोरा (CKV): यह एक इंटरनेट सेवा है. इसकी मदद से, क्लाइंट डिवाइसों पर क्रिप्टोग्राफ़िक कुंजियां सेव की जा सकती हैं. ये कुंजियां, याद रखने लायक एलएसकेएफ़ (लार्ज-स्केल कुंजी फ़ॉर्मैट) से सुरक्षित होती हैं.

कोहॉर्ट: Vault सर्वर/THM का ऐसा कलेक्शन जो एक-दूसरे के रिडंडेंट रेप्लिक के तौर पर काम कर सकता है.

कोहॉर्ट का सार्वजनिक पासकोड: THMs के किसी खास कोहॉर्ट से जनरेट किए गए पासकोड की जोड़ी का सार्वजनिक पासकोड. उससे जुड़ी निजी कुंजी सिर्फ़ उन THM में उपलब्ध होती है जो कुंजी जनरेट करने के समय कोहॉर्ट में थे.

ट्रस्टेड हार्डवेयर मॉड्यूल (THM): यह एक खास सिक्योरिटी मॉड्यूल (माइक्रोकंट्रोलर) है. इसे कम और भरोसेमंद कंप्यूटिंग एनवायरमेंट देने के लिए डिज़ाइन किया गया है. कम से कम, सुरक्षित एलिमेंट में गुप्त कुंजियां जनरेट और/या सेव करने की सुविधा होनी चाहिए. साथ ही, इसमें ऐसी स्थिति होनी चाहिए जो बदलती रहती हो और जिसे मिटाया न जा सके. इससे, डिवाइस को पहले जैसा करने के लिए किए जाने वाले हमलों से बचा जा सकता है.

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

Vault सर्वर: Google के डेटा सेंटर में काम करने वाली सामान्य मशीन, जिसे खास तौर पर ट्रस्टेड हार्डवेयर मॉड्यूल (THM) जोड़ने के लिए फिर से तैयार किया गया है.

प्रोटोकॉल डिज़ाइन

सीकेवी प्रोटोकॉल में कई चरण होते हैं. इनके बारे में यहां बताया गया है:

डेटा लेयर में इवेंट बनाने की प्रोसेस

सिस्टम को शुरू करने के लिए, Google "रूट ऑफ़ ट्रस्ट" के लिए एक सार्वजनिक कुंजी देगा. इसका इस्तेमाल, फ़्रेमवर्क, Google के हार्डवेयर की पुष्टि करने के लिए करेगा. इस रूट ऑफ़ ट्रस्ट के लिए साइनिंग पासकोड को ऑफ़लाइन सेव किया जाता है और उसे सावधानी से सुरक्षित रखा जाता है. इसकी वजह से, इस पर हस्ताक्षर करने के लिए कई कर्मचारियों की ज़रूरत होती है. इस रूट ऑफ़ ट्रस्ट की सार्वजनिक कुंजी, Android OS में पहले से मौजूद होती है. इसे सिर्फ़ OS अपडेट करके बदला जा सकता है.

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

वॉल्ट बनाना

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

Vault Opening

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

सीकेवी, रिकवरी क्लेम (और उससे जुड़े वॉल्ट) को उन वॉल्ट सर्वर पर भेजता है जो सही कोहॉर्ट का हिस्सा हैं. इसके बाद, वॉल्ट सर्वर में मौजूद THM, रिकवरी क्लेम को डिक्रिप्ट करता है. साथ ही, दावा किए गए LSKF हैश का इस्तेमाल करके, ओरिजनल वॉल्ट से रिकवरी पासकोड निकालने की कोशिश करता है. ऐसा, एन्क्रिप्शन की इंटरनल पासकोड पाने के लिए किया जाता है. अगर ओरिजनल LSKF हैश और दावा किए गए LSKF हैश मैच करते हैं, तो THM वॉल्ट से रिकवरी पासकोड निकालेगा और उसे दावेदार पासकोड से फिर से एन्क्रिप्ट करेगा. यह पासकोड, रिकवरी दावे में मौजूद होता है. अगर ऐसा नहीं होता है, तो THM, 'पुष्टि नहीं हुई' काउंटर को बढ़ा देगा. गलत पासवर्ड डालने की कोशिशों की संख्या तय सीमा तक पहुंचने के बाद, THM इस वॉल्ट के लिए, रिकवरी क्लेम को प्रोसेस करने से मना कर देगा.

आखिर में, अगर सब कुछ ठीक रहा, तो फिर से एन्क्रिप्ट किया गया रिकवरी पासकोड (जो अब दावेदार पासकोड के तहत एन्क्रिप्ट किया गया है) को वॉल्ट सर्वर से फ़्रेमवर्क पर वापस भेज दिया जाता है. रिकवरी पासकोड को डिक्रिप्ट करने के लिए, दावेदार की पासकोड की कॉपी का इस्तेमाल किया जाता है. इसके बाद, प्रोटोकॉल पूरा हो जाता है.

सुरक्षा के उपाय

Cloud Key Vault सिस्टम का मकसद, हमारे स्टैक के कई लेवल पर सुरक्षा उपायों को शामिल करके, "मज़बूत सुरक्षा" उपलब्ध कराना है. इन सुरक्षा उपायों के काम करने के तरीके के बारे में बताने के लिए, हम सबसे पहले क्लाइंट के बारे में बताएंगे. इसके बाद, हम क्लाउड कीवर्ड वॉल्ट सेवा तक के बारे में बताएंगे.

क्लाइंट की सुरक्षा

आम तौर पर, लॉक स्क्रीन नॉलेज फ़ैक्टर (एलएसकेएफ़) को डिवाइस पर सेव और सुरक्षित किया जाता है. इसके लिए, अलग-अलग ओईएम अलग-अलग तरीके अपनाते हैं. उदाहरण के लिए, Google के Pixel 2 डिवाइसों में, LSKF को स्टोर करने और उसकी पुष्टि करने के लिए, बदलाव किए जाने से सुरक्षित हार्डवेयर सुरक्षा मॉड्यूल का इस्तेमाल किया जाता है. Cloud Key Vault का इस्तेमाल करने के लिए, नए फ़्रेमवर्क एपीआई पेश किए जा रहे हैं. इन्हें इस तरह से डिज़ाइन किया गया है कि वे सुरक्षा से जुड़ी मौजूदा गारंटी को ज़्यादा से ज़्यादा बनाए रखें. भले ही, डिवाइस LSKF के स्टोरेज को सुरक्षित रखने के लिए, ऐसे हार्डवेयर सुरक्षा मॉड्यूल का इस्तेमाल करता हो.

हम इस सेक्शन में, खास तौर पर उन सुरक्षा से जुड़ी समस्याओं और सुरक्षा उपायों पर फ़ोकस करेंगे जिनका असर, Cloud Key Vault की नई सुविधा पर पड़ता है. हम LSKF से जुड़े सभी सुरक्षा उपायों के बारे में पूरी जानकारी देने की कोशिश नहीं करेंगे.

फ़्रेमवर्क के एपीआई को सुरक्षित करना

सीकेवी सेवा के साथ काम करने के लिए जोड़े गए नए फ़्रेमवर्क एपीआई, @SystemApi के तौर पर मार्क किए गए हैं. साथ ही, इनके लिए खास अनुमतियां ज़रूरी हैं. इससे यह पक्का होता है कि ये सिर्फ़ OEM के अनुमति वाले सिस्टम ऐप्लिकेशन के लिए उपलब्ध हों, जैसे कि Google Play services. इससे, डिवाइस पर उपयोगकर्ता के इंस्टॉल किए गए ऐप्लिकेशन के लिए, सीधे तौर पर हमले का कोई भी प्लैटफ़ॉर्म नहीं बचता.

फ़्रेमवर्क एपीआई यह भी पक्का करते हैं कि वॉल्ट सिर्फ़ उन कोहॉर्ट पब्लिक पासकोड के लिए बनाए जाएं जिनकी पुष्टि, भरोसेमंद रूट ने की हो. डिवाइस शिप होने पर, OEM, फ़्रेमवर्क में भरोसे का रूट डाल देता है. इसे ओएस अपडेट किए बिना बदला नहीं जा सकता. इससे यह भरोसा मिलता है कि एलएसकेएफ का इस्तेमाल सिर्फ़ ऐसे वॉल्ट बनाने के लिए किया जा रहा है जो हार्डवेयर पर आधारित ब्रूट फ़ोर्स प्रोटेक्शन को सही तरीके से लागू करेंगे. हम Cloud Key Vault सेवा में मौजूद टीएचएम का इस्तेमाल करके, LSKF को ब्रूट फ़ोर्स अटैक से सुरक्षित रखते हैं. इससे, डिवाइस पर सुरक्षित हार्डवेयर का इस्तेमाल करने के बराबर सुरक्षा मिलती है. Google Pixel 2 डिवाइसों में भी यही तरीका अपनाया जाता है.

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

रिकवरी एजेंट को सुरक्षित करना

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

प्रोटोकॉल की सुरक्षा सुविधाएं

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

हर वॉल्ट बनाने पर, रिकवरी पासकोड नए सिरे से जनरेट होता है. इसलिए, हम पासकोड रोटेशन की सुविधा लागू करते हैं. इसके लिए, हम किसी मौजूदा वॉल्ट की एंट्री को नए वॉल्ट से बदल देते हैं. Vault बनाने के दौरान, Vault में इस्तेमाल किए जाने वाले, पासकोड डालने की कोशिश के दौरान हुई गड़बड़ी की गिनती करने वाले काउंटर का पता चुना जाता है. साथ ही, फ़्रेमवर्क यह पक्का करता है कि अगले Vault के लिए इस्तेमाल किए जाने वाले काउंटर का पता तब तक नहीं बदलेगा, जब तक कि एलएसकेएफ़ में बदलाव नहीं किया जाता या कोहॉर्ट पब्लिक पासकोड की नई पुष्टि की गई सूची मौजूद नहीं होती. इसलिए, रिकवरी पासकोड को बदला जा सकता है. ऐसा करने से, एलएसकेएफ़ के लिए ब्रूट फ़ोर्स से सुरक्षा की सुविधा पर कोई असर नहीं पड़ेगा.

Cloud Key Vault सेवा के लिए सर्वर की सुरक्षा

सर्वर को सामान्य सर्वर हार्डवेयर पर चलने वाले सॉफ़्टवेयर और खास हार्डवेयर (टाइटन चिप) पर चलने वाले फ़र्मवेयर के कॉम्बिनेशन का इस्तेमाल करके लागू किया जाता है. हम हर लेयर पर दी जाने वाली सुरक्षा के बारे में बताएंगे.

हार्डवेयर की सुरक्षा

CKV सेवा के सर्वर साइड पर लागू की गई मुख्य सुरक्षा, भरोसेमंद हार्डवेयर मॉड्यूल (THMs) है. इन्हें Google के कस्टम डिज़ाइन किए गए Titan चिप का इस्तेमाल करके बनाया गया है. चिप पर ऐसा फ़र्मवेयर चल रहा है जो सीकेवी प्रोटोकॉल लागू करने के लिए ज़रूरी एपीआई दिखाता है. खास तौर पर, वे अपने कोहॉर्ट के अन्य सदस्यों के साथ एक पासकोड जनरेट कर सकते हैं और उसे सुरक्षित तरीके से शेयर कर सकते हैं. इससे फ़र्मवेयर लॉजिक, निजी पासकोड को कोहॉर्ट में मौजूद Titan चिप के बाहर लीक होने से बचाता है. यह ऐप्लिकेशन, वॉल्ट खोलने की प्रोसेस भी कर सकता है. साथ ही, हर वॉल्ट के लिए, गलत पासकोड डालने की कोशिशों की संख्या को कड़ाई से बढ़ाता रहता है. यह संख्या, Titan चिप में सेव की गई स्थिति के आधार पर तय की जाती है. CKV Titan चिप फ़र्मवेयर के ज़रिए लागू किए गए प्रोटोकॉल के बारे में ज़्यादा जानकारी, इस दस्तावेज़ के अगले वर्शन में दी जाएगी.

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

सॉफ़्टवेयर की सुरक्षा

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

हम उन Cloud सेवाओं के लिए भी सुरक्षा के स्टैंडर्ड तरीके लागू करते हैं जिनमें उपयोगकर्ता का डेटा होस्ट किया जाता है. इनमें, ऐक्सेस कंट्रोल, निगरानी, और ऑडिट करना शामिल है.

प्रोटोकॉल के बारे में ज़्यादा जानकारी

प्रोटोकॉल के स्पेसिफ़िकेशन के बारे में पूरी जानकारी अभी तैयार की जा रही है. इस दस्तावेज़ को अपडेट किया जाएगा, ताकि इस साल के आखिर में Android Open Source Project में क्लाइंट कोड पब्लिश करने के साथ-साथ, उसमें ये जानकारी भी शामिल की जा सके.

नोट