यूरी अकर्मन: "FIDO एलायंस के मूलभूत सिद्धांतों में से एक गोपनीयता सुनिश्चित करना है"

पासवर्ड रहित प्रमाणीकरण पर FIDO एलायंस के वरिष्ठ प्रमाणन इंजीनियर के साथ साक्षात्कार

हमारे उपयोगकर्ताओं ने हमें Google एप्लिकेशन के माध्यम से दो-कारक प्रमाणीकरण लागू करने के लिए कहा। और हाल ही में, हमने उन्हें यह अवसर दिया है। लगभग उसी समय, FIDO एलायंस कंसोर्टियम ने साइटों पर पासवर्ड रहित प्रमाणीकरण के लिए मोबाइल एप्लिकेशन और वेब सेवाओं - वेबऑन और सीटीएपी में मानक प्रकाशित किए।

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

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


/ फ़्लिकर / zhrefch / पीडी

कृपया समग्र रूप से आईटी क्षेत्र में अपनी पृष्ठभूमि और अनुभव के बारे में बताएं। आपने इंडस्ट्री में अपना काम कैसे शुरू किया?

मैं पंद्रह साल से प्रोग्रामिंग कर रहा था। स्कूल के बाद, मैं विश्वविद्यालय गया, जहाँ मैंने कंप्यूटर विज्ञान और गणित का अध्ययन किया। दूसरे वर्ष में मुझे क्रिप्टोग्राफी, सूचना सुरक्षा के मुद्दों और FIDO पर "ठोकर" खाने का शौक हो गया। मुझे वास्तव में उनके प्रोटोकॉल पसंद थे, और अंत में मैंने पायथन फ्लास्क के लिए एक U2F पुस्तकालय लिखा और एक प्रस्तुति दी।

मेरे काम को FIDO ने सराहा। इसके अलावा, वे सिर्फ एक प्रमाणन इंजीनियर की तलाश में थे। अंत में, मैं तकनीकी प्रमाणन के लिए जिम्मेदार हो गया।

आप कब तक FIDO के साथ प्रमाणीकरण से संबंधित विषयों के साथ काम कर रहे हैं? नए मानक विकसित करने की प्रक्रिया में आपने कौन से कार्य हल किए?

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

मैं संभावित विनिर्देशों में सुधार पर कार्य समूहों को भी सलाह देता हूं, प्रस्तुतियां देता हूं और समय-समय पर लेख लिखता हूं।

प्रमाणीकरण के लिए एक नया मानक बनाने का विचार कैसे पैदा हुआ? आपने यह क्यों तय किया कि दुनिया और समुदाय को इस क्षेत्र में एक नए समाधान की आवश्यकता है? WebAuthn को बंद करने का इरादा रखने वाले मौजूदा प्रारूपों के नुकसान क्या हैं?

FIDO Alliance की स्थापना 2013 में Agnitio, Infineon Technologies, Lenovo, Nok Nok Labs, PayPal और Validity द्वारा की गई थी, जिसने UAF को विकसित किया था। थोड़ी देर बाद वे Google, यूबिको और एनएक्सपी में शामिल हो गए - ये यू 2 एफ के पूर्ववर्ती पर काम करते थे और यह सोचते थे कि बलों में शामिल होना लाभदायक होगा, क्योंकि उनके विचार गठबंधन के विचारों के साथ मेल खाते थे। उन्होंने इंटरनेट उपयोगकर्ताओं को फ़िशिंग से बचाने, पासवर्ड की प्रयोज्य समस्याओं को हल करने और बायोमेट्रिक प्रौद्योगिकियों की पहुंच और सुरक्षा का विकास करने की मांग की।

क्या कोई प्रारंभिक अध्ययन किया गया है जिसने या तो एक मानक बनाने के इरादे को मजबूत किया, या इसके निर्माण को प्रेरित किया? यदि हां, तो आपने किस तरह के डेटा का विश्लेषण किया?

एलायंस के सदस्य जैसे कि Google, Microsoft, Samsung, Yubico और अन्य सक्रिय रूप से मानकों को बनाने और बढ़ावा देने के लिए सक्रिय रूप से काम कर रहे हैं। वे बाजारों की खोज कर रहे हैं, यह समझने की कोशिश कर रहे हैं कि कैसे FIDO विभिन्न पारिस्थितिकी प्रणालियों में "फिट" हो सकता है। उदाहरण के लिए, Google ने U2F के लिए एक बार के पासवर्ड से दूसरे कारक के प्रवास पर एक अध्ययन किया।

CTAP प्रोटोकॉल का जन्म कैसे हुआ? यह WebAuthn से कैसे जुड़ा है?

FIDO में तीन भाग होते हैं: सर्वर, क्लाइंट (ब्राउज़र) और प्रमाणक। सर्वर क्लाइंट को एक कॉल भेजता है, क्लाइंट ऑथेंटीलेटर को कॉल पास करता है, जो उस पर हस्ताक्षर करता है और क्लाइंट को वापस करता है, और वह पहले से ही सर्वर को भेजा जाता है।

सर्वर के लिए FIDO प्रमाणीकरण का उपयोग करने के लिए, क्लाइंट के पास WebAuthn JS API है। क्लाइंट निम्न-स्तरीय प्रोटोकॉल CTAP2 (क्लाइंट-टू-ऑथेंटिकेटर प्रोटोकॉल 2) का उपयोग करके प्रमाणिकता के साथ संचार करता है। CTAP2 एक प्रमाणक के साथ संचार के लिए CBOR क्वेरी संरचनाओं और ट्रांसपोर्ट, जैसे USB, NFC और BLE का वर्णन करता है। इन दोनों मानकों के संयोजन को FIDO2 कहा जाता है।

प्रारूप बनाने के लक्ष्यों में से एक फ़िशिंग से बचाव करना है। अन्य समाधानों की तुलना में कुछ फायदे क्या हैं?

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

CCA एक रिप्ले हमले से सुरक्षित नहीं हैं। वे कई साइटों पर एक एकल प्रमाण पत्र का पुन: उपयोग करते हैं, जिससे उपयोगकर्ता का नामकरण हो सकता है। FIDO में, हम गोपनीयता बनाए रखने के लिए प्रत्येक पंजीकरण के लिए एक नई अनूठी जोड़ी बनाते हैं।

CCA में स्टोरेज कीज़ की भी समस्या है, क्योंकि ज्यादातर मामलों में निजी कुंजी या तो PKCS12 में एन्क्रिप्ट की जाती है, या बस स्पष्ट में निहित होती है। इस प्रकार, यहां तक ​​कि एक अनपेक्षित अनुप्रयोग भी समस्याओं के बिना इसे चुरा सकता है। FIDO में, सभी कुंजियों को सुरक्षित रखा जाता है, उदाहरण के लिए, एक तरफ़ा SecureEnclave स्टोरेज में। इस प्रकार के भंडारण से कुंजियों को पुनर्प्राप्त करना बहुत मुश्किल है।

CCA को सर्वर पर उचित कार्यान्वयन के साथ कठिनाइयां होती हैं, क्योंकि पूर्ण CCA समर्थन वांछित होने के लिए बहुत कुछ छोड़ देता है। और टीएलएस के साथ काम करने की जटिलताओं के कारण, डेवलपर्स बहुत सारी गलतियाँ करते हैं। FIDO को केवल मूल क्रिप्टोग्राफी के लिए ही समर्थन की आवश्यकता होती है। CCA को HTTP के माध्यम से लागू किया जा सकता है, जो WebAuthn में नहीं किया जा सकता है। CCA में पोर्टेबिलिटी और उपयोग में आसानी के साथ समस्याएं भी हैं।

मुझे विश्वास नहीं हो रहा है कि अलायंस ने कुछ भी नया आविष्कार किया है। हमने केवल एक अच्छा प्रोटोकॉल विकसित किया है जिसमें मौजूदा सुरक्षा तंत्र शामिल हैं।


/ फ़्लिकर / मार्कस स्पिसके / पीडी

क्या मानक का उपयोग इस तथ्य से संबंधित अतिरिक्त हमले वैक्टर को प्रकट नहीं करेगा कि बायोमेट्रिक जानकारी की एक बड़ी मात्रा को संग्रहीत करना आवश्यक होगा?

हमारा मूलभूत सिद्धांत गोपनीयता है। बायोमेट्रिक जानकारी सुरक्षित चिप्स पर संग्रहीत की जाती है और उन्हें कभी नहीं छोड़ती है। हमारी कंपनियां FIDO या FIPS द्वारा प्रमाणित पाठकों के साथ काम करती हैं।

हम उपयोगकर्ता की उपस्थिति की पुष्टि करने के अलावा किसी अन्य चीज़ के लिए बायोमेट्रिक जानकारी का उपयोग नहीं करते हैं। और हमारे पास प्रमाणीकरणकर्ताओं के परीक्षण के लिए एक बायोमेट्रिक प्रमाणन कार्यक्रम है।

आपने एक बार कहा था कि एसएमएस कोड द्वारा प्रमाणीकरण एक बुरा 2FA विकल्प है। आप इस पर कैसे टिप्पणी कर सकते हैं?

एसएमएस कोड या एसएमएस OTP दो-कारक प्रमाणीकरण है जिसमें एसएमएस के माध्यम से एक बार पासवर्ड दिया जाता है। इसलिए, यह पता चला है कि यह समाधान फ़िशिंग के लिए कमजोर है। यदि आपका उपयोगकर्ता फ़िशिंग में पकड़ा गया है और अपना उपयोगकर्ता नाम और पासवर्ड देता है, तो उसे साइबर अपराधियों को एक एसएमएस कोड प्रसारित करने से क्या होगा?

हमें परिवहन के रूप में एसएमएस का उपयोग करने की समस्याओं के बारे में नहीं भूलना चाहिए। तीन साल पहले, SS7 प्रोटोकॉल में भेद्यता के कारण जर्मन बैंक में 400 हजार खाते हैक कर लिए गए थे, जिसका उपयोग विभिन्न दूरसंचार ऑपरेटरों के बीच दूरसंचार सूचनाओं को रूट करने के लिए किया जाता है। हमलावर जो एसएस 7 नेटवर्क तक अनधिकृत पहुंच प्राप्त करते हैं, जिसमें कोई प्रमाणीकरण नहीं है, वे पीड़ितों की संख्या को स्वयं दर्ज करने और उनके कोड प्राप्त करने में सक्षम थे।

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

यदि आपको कई उपकरणों पर सेवा में प्रवेश करने की आवश्यकता है या कई लोग एक ही समय में एक ही सेवा का उपयोग करते हैं? क्या मानक ऑपरेशन के इस तरीके का समर्थन करता है?

एक पासवर्ड के विपरीत, कई प्रमाणक हो सकते हैं। उपयोगकर्ता अपने फोन, लैपटॉप, टोकन को पंजीकृत कर सकता है और प्रमाणीकरण के लिए उनमें से किसी का उपयोग कर सकता है। इसके अलावा, एक टोकन गोपनीयता की हानि के बिना कई खातों में "बंधे" हो सकता है।

लेकिन अगर टोकन खो गया तो क्या होगा? क्या सेवाओं तक पहुंच वापस करना संभव होगा?

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

यदि हम सेवाओं तक पहुंच बहाल करने की बात करते हैं, तो यह वास्तव में एक कठिन समस्या है। रिकवरी मानक का हिस्सा नहीं है, क्योंकि विभिन्न संसाधन अलग-अलग तरीकों से खातों तक पहुंच बहाल करते हैं। क्लासिक दृष्टिकोण एक बार के कोड हैं जो फ़िशिंग के खिलाफ संरक्षित नहीं हैं। फेसबुक आपको दोस्तों के माध्यम से पहुंच पुनः प्राप्त करने की अनुमति देता है।

आज तक का सबसे आशाजनक समाधान है - एक रिकवरी प्रोटोकॉल - अन्य सेवाओं में एन्क्रिप्टेड रहस्यों के भंडारण के आधार पर एक रिकवरी प्रोटोकॉल। यह संयोगवश, U2F ब्राट हिल (Bratt Hill) के रचनाकारों में से एक द्वारा लिखा गया था। रिकवरी एक कठिन और दिलचस्प समस्या है, जिसका समाधान ढूंढा जाना बाकी है।

प्रमाणक में निजी कुंजी की प्रतिलिपि संरक्षित होनी चाहिए। किस रूप में और कहाँ पहचानकर्ता संग्रहीत हैं? उनका आदान-प्रदान कैसे किया जाता है?

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

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

नया मानक डेटा सुरक्षा कानूनों (जैसे GDPR) की आवश्यकताओं से कैसे संबंधित होगा?

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

और कौन पहले से ही मानक लागू कर रहा है?

Google, फेसबुक, ड्रॉपबॉक्स, सेल्सफोर्स, बैंक ऑफ अमेरिका, एनटीटी डोकोमो ... हमारे पास सैकड़ों कंपनियां और आधा बिलियन दैनिक उपयोगकर्ता हैं। हम हर दिन बढ़ रहे हैं। लेकिन फिर भी, पूर्ण पासवर्ड रहित प्रमाणीकरण पर स्विच करने में कुछ समय लगेगा।

मानक कितनी जल्दी किसी अन्य प्रमाणीकरण विधि से संक्रमण की अनुमति देता है?

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

मानक विकसित करने के लिए FIDO की योजनाएं क्या हैं? निकट भविष्य में क्या सुधार किए जाने की योजना है? और लंबे समय में?

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

आप WebAuthn पर काम करना जारी रखने की योजना कैसे बनाते हैं? आईटी समुदाय आपकी मदद कैसे कर सकता है?

मैं, पहले की तरह, डेवलपर समुदाय में एक राजदूत के रूप में अपना काम जारी रखता हूं: मैं लेख प्रकाशित करता हूं, खुले स्रोत पर काम करता हूं, प्रस्तुतिकरण करता हूं, और प्रशिक्षण आयोजित करता हूं। सामुदायिक सहायता के लिए, मैं केवल यह कह सकता हूं: "हमें अधिक खुले स्रोत वाले सोने की आवश्यकता है।"

---

पीएस यूरी अकर्मन ने हैबे पर एक लेख भी तैयार किया, जिसमें उन्होंने FIDO2 के मुख्य सुरक्षा तंत्र का वर्णन किया और इसके साथ काम करने के लिए JS API की समीक्षा की।