WebAuthn में कौन से एन्क्रिप्शन एल्गोरिदम समर्थित हैं?

WebAuthn को लचीला होने के लिए डिज़ाइन किया गया है और यह एन्क्रिप्शन एल्गोरिदम की एक विस्तृत श्रृंखला का समर्थन करता है, जिसमें प्रमुख रूप से RSA (RS256), ECDSA (ES256), और EdDSA शामिल हैं। यह अनुकूलनशीलता इसे विभिन्न ऑथेंटिकेटर और प्लेटफार्मों के साथ सहजता से एकीकृत करने की अनुमति देती है, जिससे व्यापक संगतता सुनिश्चित होती है।

की पेयर बनाने में pubKeyCredParams की कार्यक्षमता क्या है?

pubKeyCredParams WebAuthn प्रक्रिया के पंजीकरण चरण में एक महत्वपूर्ण भूमिका निभाता है, यह निर्दिष्ट करके कि रिलाइंग पार्टी कौन से क्रिप्टोग्राफिक एल्गोरिदम का समर्थन करती है। यह सुनिश्चित करता है कि बनाए गए की पेयर उपयोगकर्ता के ऑथेंटिकेटर और रिलाइंग पार्टी की आवश्यकताओं दोनों के साथ संगत हैं।

credentialPublicKey की कार्यक्षमता और पब्लिक कीज़ कैसे निकालें?

credentialPublicKey का उपयोग ऑथेंटिकेटर द्वारा प्रदान किए गए attestationObject से पब्लिक कीज़ निकालने के लिए किया जाता है। यह अनुशंसा की जाती है कि इस प्रक्रिया के लिए एक अच्छी तरह से परीक्षण की गई WebAuthn लाइब्रेरी का उपयोग किया जाए ताकि सटीकता और सुरक्षा सुनिश्चित हो सके।

WebAuthn pubKeyCredParams और credentialPublicKey: CBOR और COSE

जानें कि WebAuthn पासकी ऑथेंटिकेशन में एसिमेट्रिक एन्क्रिप्शन एल्गोरिदम और pubKeyCredParams का उपयोग कैसे करता है, और credentialPublicKey, CBOR और COSE की भूमिका क्या है।

Our mission is to make the Internet a safer place, and the new login standard passkeys provides a superior solution to achieve that. That's why we want to help you understand passkeys and its characteristics better.

1. परिचय: pubKeyCredParams और credentialPublicKey#

डिजिटल सुरक्षा में, पासकीज़ (passkeys) नया पासवर्ड रहित मानक हैं। पासकीज़ के केंद्र में पब्लिक-की क्रिप्टोग्राफी है, जिसका उपयोग WebAuthn प्रोटोकॉल के भीतर किया जाता है, जिस पर पासकीज़ आधारित हैं। पासकी ऑथेंटिकेशन को डिज़ाइन या उपयोग करते समय यह समझना महत्वपूर्ण है कि WebAuthn में पब्लिक-की क्रिप्टोग्राफी का उपयोग कैसे किया जाता है, विशेष रूप से पासकीज़ बनाने, निकालने, प्रबंधित करने और संग्रहीत करने में। पब्लिक की को रिलाइंग पार्टी (RP) के सर्वर पर संग्रहीत किया जाता है, जो उस वेबसाइट का बैकएंड है जो पासकीज़ के माध्यम से उपयोगकर्ता को प्रमाणित करना चाहता है, और प्राइवेट की को ऑपरेटिंग सिस्टम के आधार पर एक हार्डवेयर सुरक्षा मॉड्यूल में सुरक्षित रूप से संग्रहीत किया जाता है, जैसे Secure Enclave (iOS), TEE (Android) या TPM (Windows)।

इस ब्लॉग पोस्ट में, हम पासकीज़ में उपयोग की जाने वाली पब्लिक-की क्रिप्टोग्राफी की मूल बातों पर शीघ्रता से नज़र डालेंगे। ब्लॉग पोस्ट के अंत तक निम्नलिखित प्रश्नों के उत्तर दिए जाने चाहिए:

WebAuthn में कौन से एन्क्रिप्शन एल्गोरिदम समर्थित हैं
की-पेयर बनाते समय pubKeyCredParams कैसे काम करते हैं?
बनाई गई पब्लिक कीज़ को निकालते समय credentialPublicKey कैसे काम करता है?

2. पब्लिक-की क्रिप्टोग्राफी क्या है?#

यह समझने के लिए कि WebAuthn के भीतर पब्लिक-की क्रिप्टोग्राफी कैसे काम करती है, हम एक त्वरित नज़र डालेंगे कि यह सामान्य रूप से कैसे काम करती है और एल्गोरिदम के सामान्य प्रकार क्या हैं।

2.1 पब्लिक-की क्रिप्टोग्राफी कैसे काम करती है?#

पब्लिक-की क्रिप्टोग्राफी, जिसे एसिमेट्रिक क्रिप्टोग्राफी के रूप में भी जाना जाता है, सिमेट्रिक क्रिप्टोग्राफी के विपरीत है जहाँ एन्क्रिप्शन और डिक्रिप्शन दोनों के लिए एक ही की का उपयोग किया जाता है। एसिमेट्रिक क्रिप्टोग्राफी दो अलग-अलग कीज़ का उपयोग करती है - एक पब्लिक की, जिसे खुले तौर पर साझा किया जा सकता है, और एक प्राइवेट की, जिसे मालिक द्वारा गुप्त रखा जाता है।

से लिया गया: https://en.wikipedia.org/wiki/Public-key_cryptography

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

Subscribe to our Passkeys Substack for the latest news.

2.2 पब्लिक-की क्रिप्टोग्राफी एल्गोरिदम के सामान्य प्रकार#

यहाँ पब्लिक की क्रिप्टोग्राफी में उपयोग किए जाने वाले कुछ सामान्य प्रकार के एल्गोरिदम का अवलोकन दिया गया है:

श्रेणी	RSA	DSA	ECDSA	EdDSA
आविष्कार की तिथि	1977	1991	1999	2011
एल्गोरिदम का प्रकार	एसिमेट्रिक पब्लिक की क्रिप्टोग्राफी	डिजिटल सिग्नेचर एल्गोरिदम	एलिप्टिक कर्व डिजिटल सिग्नेचर	एडवर्ड्स-कर्व डिजिटल सिग्नेचर
मुख्य उपयोग	सुरक्षित डेटा ट्रांसमिशन	इलेक्ट्रॉनिक दस्तावेज़ों पर हस्ताक्षर करना	सुरक्षित लेनदेन और हस्ताक्षर	सुरक्षित लेनदेन और हस्ताक्षर
सामान्य की साइज़	1024 से 15360 बिट्स	1024 से 3072 बिट्स	160 से 512 बिट्स	256 बिट्स
प्रदर्शन	बड़े की साइज़ के कारण धीमा	हस्ताक्षर के लिए RSA से तेज़	छोटी कीज़ के साथ तेज़ गणना	गति और सुरक्षा के लिए अनुकूलित
लोकप्रियता	ऐतिहासिक रूप से व्यापक रूप से उपयोग किया जाता है	RSA से कम आम	तेजी से लोकप्रिय हो रहा है	तेजी से लोकप्रियता प्राप्त कर रहा है
मोबाइल उपकरणों के लिए दक्षता	मोबाइल पर कम कुशल	मध्यम रूप से कुशल	मोबाइल उपकरणों पर उच्च दक्षता	अधिकतम दक्षता
कीज़ के लिए स्टोरेज आवश्यकताएँ	बड़े की साइज़ के कारण उच्च	मध्यम	कम स्टोरेज स्पेस की आवश्यकता	न्यूनतम स्टोरेज की आवश्यकता
बैटरी का उपयोग	उच्च खपत	मध्यम खपत	कम बिजली की खपत	बैटरी संरक्षण के लिए इष्टतम
मोबाइल के लिए उपयुक्तता	साइज़ और पावर के कारण कम उपयुक्त	मध्यम रूप से उपयुक्त	अत्यधिक उपयुक्त	अत्यधिक उपयुक्त
मानकों में अपनाना	व्यापक रूप से अपनाया गया (TLS, SSH)	कम व्यापक रूप से अपनाया गया	आधुनिक प्रोटोकॉल में व्यापक रूप से अपनाया गया (TLS, SSH)	नए प्रोटोकॉल में अपनाया जा रहा है (TLS, SSH)
भविष्य के खतरों का प्रतिरोध	क्वांटम हमलों के प्रति संवेदनशील	क्वांटम हमलों के प्रति संवेदनशील	क्वांटम हमलों के प्रति संभावित रूप से प्रतिरोधी	क्वांटम हमलों के प्रति संभावित रूप से प्रतिरोधी
बहुमुखी प्रतिभा	प्लेटफार्मों पर उच्च बहुमुखी प्रतिभा	विशिष्ट उपयोग के मामलों तक सीमित	उच्च बहुमुखी प्रतिभा	उच्च बहुमुखी प्रतिभा
पेटेंट स्थिति	पेटेंट के तहत नहीं	पेटेंट के तहत नहीं	पेटेंट के तहत नहीं	पेटेंट के तहत नहीं

एलिप्टिक कर्व क्रिप्टोग्राफी (ECC) की गणितीय नींव, जिसमें ECDSA और EdDSA शामिल हैं, में एलिप्टिक कर्व्स के गुण शामिल हैं जिन्हें हम इस लेख में शामिल नहीं करेंगे। लेकिन उपरोक्त तालिका से यह स्पष्ट है कि ऐसे फायदे हैं जो उनके अपनाने को प्रेरित करते हैं। हम अगले खंड में सबसे महत्वपूर्ण पर चर्चा करेंगे।

Become part of our Passkeys Community for updates & support.

Join

2.3 ECC-आधारित पब्लिक क्रिप्टोग्राफी को तेजी से अपनाना#

एलिप्टिक कर्व क्रिप्टोग्राफी को मोबाइल उपकरणों के लिए व्यापक रूप से अपनाया गया है क्योंकि वे छोटे की साइज़ से लाभान्वित होते हैं, जिससे निम्नलिखित फायदे होते हैं:

कम स्टोरेज आवश्यकताएँ: ECC की छोटी कीज़ को RSA जैसी पारंपरिक क्रिप्टोग्राफिक विधियों की तुलना में कम स्टोरेज स्पेस की आवश्यकता होती है। यह सीमित मेमोरी संसाधनों वाले उपकरणों के लिए विशेष रूप से फायदेमंद है, जिससे स्पेस का अधिक कुशल उपयोग होता है। निम्नलिखित तालिका तुलनीय सुरक्षा स्तरों और उपयोग की गई कीज़ के वास्तविक साइज़ का अनुमान दिखाती है। सुरक्षा स्तर को बिट्स में मापा जाता है और आमतौर पर उस साइज़ के सिमेट्रिक की सिफर से मेल खाता है:

सुरक्षा स्तर (बिट्स)	RSA की साइज़ (बिट्स)	ECDSA/EdDSA की साइज़ (बिट्स)
80	1024	160-223
112	2048	224-255
128	3072	256-383
256	15360	512+

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

बढ़ी हुई परफॉर्मेंस: छोटी कीज़ तेज़ क्रिप्टोग्राफिक संचालन को सक्षम करती हैं, जो कम प्रोसेसिंग पावर वाले उपकरणों के लिए महत्वपूर्ण है। इसके परिणामस्वरूप तेज़ एन्क्रिप्शन और डिक्रिप्शन गतिविधियाँ होती हैं, जिससे मोबाइल एप्लिकेशन की समग्र परफॉर्मेंस और प्रतिक्रिया में वृद्धि होती है। बेंचमार्क के प्रकार के आधार पर गति में 10-40 गुना की वृद्धि होती है। यहाँ बेंचमार्क डेटा का एक उदाहरण है जो AWS ने 2018 में क्लाउडफ्रंट के लिए ECDSA लागू करते समय आयोजित किया था:

एल्गोरिदम	की साइज़	साइन-ऑपरेशन	साइन/सेकंड
RSA	2048	0.001012s	987
ECDSA	256	0.000046s	21565 (x20)

बेहतर बैटरी दक्षता: छोटी कीज़ से अधिक कुशल प्रोसेसिंग के साथ, ECC संचालन कम बिजली की खपत कर सकते हैं। ऊर्जा का यह संरक्षण मोबाइल उपकरणों के लिए महत्वपूर्ण है, जहाँ बैटरी जीवन को संरक्षित करना एक निरंतर चुनौती है।

ये कारक ECC को मोबाइल वातावरण के लिए विशेष रूप से उपयुक्त बनाते हैं, जहाँ स्टोरेज, प्रोसेसिंग गति और बिजली की खपत का अनुकूलन आवश्यक है। परिणामस्वरूप, ECC को मोबाइल कंप्यूटिंग में डिवाइस के प्रदर्शन से समझौता किए बिना मजबूत सुरक्षा प्रदान करने की क्षमता के लिए तेजी से पसंद किया जा रहा है। फिर भी, आज तक TLS (HTTPS, FTPS या SMTPS के लिए उपयोग किया जाता है), SSH या IPsec जैसे व्यापक प्रोटोकॉल के बहुत सारे पुराने संस्करण मौजूद हैं जो अभी भी RSA का समर्थन करते हैं, लेकिन उन्होंने ECC-आधारित वेरिएंट की पेशकश शुरू कर दी है जो उनका समर्थन करते हैं।

3. WebAuthn: पासकीज़ के भीतर पब्लिक-की क्रिप्टोग्राफी का उपयोग कैसे किया जाता है?#

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

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

पासकीज़ के साइन-अप / पंजीकरण के लिए, तीन महत्वपूर्ण चरण हैं:

(1) रिलाइंग पार्टी समर्थित एन्क्रिप्शन एल्गोरिदम का संकेत देती है: रिलाइंग पार्टी PublicKeyCredentialCreationOptions.pubKeyCredParams के माध्यम से समर्थित एन्क्रिप्शन एल्गोरिदम का संकेत देती है, साथ ही अन्य PublicKeyCredentialCreationOptions के साथ।
(2) उपयोगकर्ता का ऑथेंटिकेटर की-पेयर बनाता है: ऑथेंटिकेटर pubKeyCredParams सूची की जाँच करता है कि वह कौन से एन्क्रिप्शन एल्गोरिदम का समर्थन करता है और एक अद्वितीय क्रेडेंशियल आईडी के साथ एक की-पेयर बनाता है। यह प्राइवेट की को HSM के भीतर संग्रहीत करता है और फिर पब्लिक-की और उपयोग किए गए एन्क्रिप्शन-एल्गोरिदम को ब्राउज़र को लौटाता है। फिर, ब्राउज़र "authData" अनुभाग में attestationObject के साथ रिलाइंग पार्टी बैकएंड को एक POST अनुरोध भेजता है। यदि समर्थित एन्क्रिप्शन एल्गोरिदम का कोई मेल नहीं होता है, तो बनाने की प्रक्रिया विफल हो जाएगी।
(3) रिलाइंग पार्टी पब्लिक-की निकालती है और उसे संग्रहीत करती है: रिलाइंग पार्टी ब्राउज़र से attestationObject प्राप्त करती है। यह authData.credentialPublicKey अनुभाग को पार्स करती है और पब्लिक-की निकालती है। पब्लिक-की के साथ उपयोग किए गए एन्क्रिप्शन एल्गोरिदम और क्रेडेंशियल आईडी के बारे में जानकारी भी रिलाइंग पार्टी को वापस भेजी जाती है।

पासकीज़ के साथ बाद के लॉगिन / प्रमाणीकरण के लिए, निम्नलिखित चरण आवश्यक हैं (विवरण सरलीकृत):

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

दोनों मामलों को देखने पर, हम देख सकते हैं कि केवल पासकीज़ के साइन-अप / पंजीकरण के लिए पब्लिक-की और एन्क्रिप्शन एल्गोरिदम जानकारी अभिनेताओं के बीच ले जाई जाती है।

पासकीज़ के साथ बाद के लॉगिन / प्रमाणीकरण घटनाओं के लिए, केवल चुनौती और हस्ताक्षर प्रेषित डेटा का हिस्सा हैं।

WebAuthn मानक उपयोग किए गए एन्क्रिप्शन एल्गोरिदम की पहचान करने के लिए IANA COSE एल्गोरिदम आईडी का उपयोग करता है। COSE एल्गोरिदम आईडी दोनों का उपयोग pubKeyCredParams में समर्थित एल्गोरिदम को संकेत देने और credentialPublicKey में वास्तव में बनाए गए की-पेयर प्रकार को प्रसारित करने के लिए किया जाता है। हम अगले दो खंडों में उनके कार्यान्वयन पर ध्यान केंद्रित करेंगे।

4. सही pubKeyCredParams सेटिंग्स कैसे चुनें?#

IANA की COSE एल्गोरिदम सूची में 75 से अधिक एल्गोरिदम शामिल हैं जिनका सैद्धांतिक रूप से WebAuthn मानक के साथ उपयोग किया जा सकता है। ऋणात्मक आईडी वाले अधिकांश एल्गोरिदम एसिमेट्रिक पब्लिक-की हैं और अधिकांश धनात्मक सिमेट्रिक हैं, लेकिन यह एक परंपरा है क्योंकि इसके अपवाद भी हैं।

4.1 WebAuthn के लिए कौन से COSE एल्गोरिदम प्रासंगिक हैं?#

जैसा कि हमने पहले बताया है, एन्क्रिप्शन एल्गोरिदम को WebAuthn समारोह में उपयोग करने के लिए ऑथेंटिकेटर और रिलाइंग पार्टी बैकएंड द्वारा समर्थित होना चाहिए। चूंकि अधिकांश रिलाइंग पार्टियां मौजूदा WebAuthn पुस्तकालयों का उपयोग करती हैं जिनके पास एन्क्रिप्शन एल्गोरिदम की एक विस्तृत श्रृंखला तक पहुंच है, इसलिए यह देखना अधिक महत्वपूर्ण है कि कौन से एल्गोरिदम किस ऑथेंटिकेटर द्वारा समर्थित हैं:

नाम	आईडी	विवरण	Apple	Android	Windows 10	Windows 11+	सुरक्षा कीज़
RS256	-257	RSASSA-PKCS1-v1_5 SHA-256 का उपयोग करके	❌	❌	✅	✅	✅
EdDSA	-8	EdDSA	❌	❌	❌	❌	✅ (*)
ES256	-7	ECDSA w/ SHA-256 (NIST P-256 के रूप में भी जाना जाता है)	✅	✅	❌	✅	✅

(*) = सुरक्षा कीज़ का छोटा हिस्सा (जैसे Yubikeys 5+, Solokey या Nitrokey) IANA तालिका से उद्धरण: पूरी सूची यहाँ देखें

जैसा कि आप इस तालिका से देख सकते हैं, सभी महत्वपूर्ण ऑथेंटिकेटर का समर्थन करने के लिए RS256 और ES256 पर्याप्त हैं। समुदाय के कुछ हिस्से हैं जो सुरक्षा को और बेहतर बनाने के लिए EdDSA को भी एकीकृत करने की सलाह देते हैं। दूसरी ओर, क्रेडेंशियल आईडी जिन्हें संग्रहीत करने की भी आवश्यकता होती है, EdDSA कीज़ के लिए काफी लंबी लगती हैं। आज तक, आगामी स्तर 3 WebAuthn मानक पर W3C संपादक का मसौदा तीनों एल्गोरिदम का सुझाव देता है।

4.2 pubKeyCredParams में pubKeyCredParams-Array को परिभाषित करना#

पासकी बनाने के लिए समर्थित एन्क्रिप्शन एल्गोरिदम को कॉन्फ़िगर करना PublicKeyCredentialCreationOptions के माध्यम से किया जाता है:

const publicKeyCredentialCreationOptions = {
    challenge: "*",
    rp: {
        name: "Corbado",
        id: "corbado.com",
    },
    user: {
        id: "user-X",
        name: "user@corbado.com",
        displayName: "Corbado Name",
    },
    pubKeyCredParams: [
        {
            alg: -8,
            type: "public-key",
        },
        {
            alg: -7,
            type: "public-key",
        },
        {
            alg: -257,
            type: "public-key",
        },
    ],
    authenticatorSelection: {
        authenticatorAttachment: "platform",
        requireResidentKey: true,
    },
};
 
const credential = await navigator.credentials.create({
    publicKey: publicKeyCredentialCreationOptions,
});

उदाहरण दिखाता है कि एल्गोरिदम को pubKeyCredParams के भीतर कैसे निर्दिष्ट किया जाता है: आईडी के लिए alg और एल्गोरिदम के प्रकार के रूप में public-key जोड़कर। लाइन 29/30 में, PublicKeyCredentialCreationOptions को ब्राउज़र के WebAuthn API के माध्यम से ऑथेंटिकेटर को पास किया जाता है। ES256 या RS256 के लिए समर्थन हटाने से त्रुटियां उत्पन्न होंगी और इसकी सख्त अनुशंसा नहीं की जाती है।

एक कामकाजी उदाहरण के रूप में, हम पासकीज़ डिबगर में एक मैक पर निम्नलिखित PublicKeyCredentialCreationOptions चलाएंगे।

{
    "rp": {
        "id": "www.passkeys-debugger.io",
        "name": "Relying Party Name"
    },
    "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -8
        },
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "excludeCredentials": [],
    "timeout": 120000,
    "authenticatorSelection": {
        "residentKey": "required",
        "requireResidentKey": true,
        "userVerification": "required",
        "authenticatorAttachment": "platform"
    },
    "hints": [],
    "attestation": "direct",
    "user": {
        "name": "User-2024-08-19",
        "displayName": "User-2024-08-19",
        "id": "LlakhOS2vobxxwdkInYP-277Atf0S5OsJax_uBCNNINk"
    }
}

ऑथेंटिकेटर द्वारा उत्पन्न प्रतिक्रिया रिलाइंग पार्टी को (अटेस्टेशन के रूप में) भेजी जाती है और इस तरह दिखती है:

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": "o2NmbXRmcGFja2VkZ2F0dFN0bXSiY2FsZyZjc2lnWEcwRQIhAIvVNCTlYXX7WKOfeto7WyBQE6uvXpvnNy22kqrMxs_QAiAmanFqalrvD_1fe0Cb2f60ljth4nngckkKJ8JPtqZiO2hhdXRoRGF0YVikt8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADdFAAAAAK3OAAI1vMYKZIsLJfHwVQMAIGljJhOARPWc70Snfa0IXcurm65Qdwjq00RUADXusnR4pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
        "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiQUFBQmVCNzhIckllbWgxalRkSklDcl8zUUdfUk1PaHAiLCJvcmlnaW4iOiJodHRwczovL29wb3Rvbm5pZWUuZ2l0aHViLmlvIiwiY3Jvc3NPcmlnaW4iOmZhbHNlfQ",
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

अगले सत्र में, हम देखेंगे कि प्रतिक्रिया से पब्लिक कीज़ और उपयोग किए गए एन्क्रिप्शन एल्गोरिदम को कैसे निकाला जा सकता है।

5. attestationObject से पब्लिक की कैसे निकालें?#

सबसे पहले, हमें यह जांचना होगा कि वास्तविक attestationObject कैसे बनाया जाता है, क्योंकि जैसा कि हम ऊपर देखते हैं, इसे JSON में रिलाइंग पार्टी को नहीं भेजा जाता है।

5.1 अवलोकन: attestationObject क्या है?#

attestationObject WebAuthn पंजीकरण प्रक्रिया में एक महत्वपूर्ण भूमिका निभाता है, जो ऑथेंटिकेटर द्वारा प्रदान किए गए अटेस्टेशन स्टेटमेंट के लिए एक कंटेनर के रूप में कार्य करता है। यह ऑब्जेक्ट रिलाइंग पार्टी (RP) को नए बनाए गए पब्लिक की क्रेडेंशियल की उत्पत्ति और अखंडता को सत्यापित करने के लिए आवश्यक बहुत सारी जानकारी प्रदान करता है।

अपने मूल में, attestationObject एक जटिल संरचना है। यह ज्यादातर CBOR (संक्षिप्त बाइनरी ऑब्जेक्ट रिप्रेजेंटेशन) प्रारूप में एन्कोड किया गया है, जिसे फिर अंत में Base64URL एन्कोडिंग के साथ एन्कोड किया जाता है। यह ऑथेंटिकेटर डेटा को एक अटेस्टेशन स्टेटमेंट के साथ समाहित करता है जो जानकारी की प्रामाणिकता को सत्यापित करता है। क्योंकि पासकीज़ अटेस्टेशन "none" के साथ बनाई जाती हैं और इसलिए एक अटेस्टेशन स्टेटमेंट नहीं ले जाती हैं, हम इस लेख में इसे कवर नहीं करेंगे। एक साइड नोट के रूप में: हमने ज्यादातर CBOR लिखा क्योंकि वैकल्पिक एक्सटेंशन के लिए आवश्यक चर लंबाई के कारण गैर-मानक CBOR उपसर्ग भी शामिल हैं। हम इसमें और गहराई में नहीं जाएंगे, जटिलताओं के बारे में एक चर्चा यहाँ पाई जा सकती है।

WebAuthn विनिर्देश से लिया गया

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

5.2 संक्षिप्त बाइनरी ऑब्जेक्ट रिप्रेजेंटेशन (CBOR) क्या है?#

CBOR (संक्षिप्त बाइनरी ऑब्जेक्ट रिप्रेजेंटेशन) एक डेटा प्रारूप है जिसे डेटा को एक कॉम्पैक्ट, कुशल और विस्तार योग्य तरीके से एन्कोड करने के लिए डिज़ाइन किया गया है। यह बाइनरी है, जो इसे इसके टेक्स्ट-आधारित रोल-मॉडल JSON की तुलना में छोटा और पार्स करने में तेज़ बनाता है। निम्नलिखित उदाहरण दिखाता है कि JSON और CBOR कैसे भिन्न हैं (टेक्स्ट बनाम बाइनरी):

JSON टेक्स्ट	CBOR बाइनरी डेटा	CBOR डिकोड किया गया
नाम:Corbado	A1 64 4E 61 6D 65 67 43 6F 72 62 61 64 6F	A1 # map(1) एक प्रविष्टि के साथ 64 # text(4) 4E616D65 # नाम; 67 # text(7) 436F726261646F # Corbado

बोल्ड नाम है। इटैलिक कॉर्बाडो है। (अधिक जानकारी https://cbor.io/ पर पाई जा सकती है)

WebAuthn के संदर्भ में, CBOR का उपयोग कई कारणों से किया जाता है:

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

CBOR का उपयोग पब्लिक कीज़ और attestationObject को एन्कोड करने के लिए विशेष रूप से उपयुक्त है क्योंकि इसे ऊपर चर्चा की गई विभिन्न प्रारूपों और लंबाई को संभालने की आवश्यकता है। उदाहरण के लिए, एक RSA की में ECDSA की की तुलना में अलग-अलग विशेषताएँ और साइज़ होंगे। attestationObject के भीतर, पब्लिक कीज़ को COSE की प्रारूप में संग्रहीत किया जाता है, जो CBOR पर आधारित है।

5.3 COSE की प्रारूप क्या है?#

एक COSE की संरचना एक CBOR मैप ऑब्जेक्ट पर बनाई गई है। यह की प्रतिनिधित्व के लिए एक संरचित तरीका परिभाषित करता है, जिसमें विभिन्न की प्रकार और उनके संबंधित पैरामीटर शामिल हैं, जैसे कि RSA मापांक और घातांक, या एलिप्टिक कर्व पब्लिक की निर्देशांक। यह मानकीकृत प्रारूप कीज़ को उनके अंतर्निहित क्रिप्टोग्राफिक एल्गोरिदम के बावजूद, एक सुसंगत तरीके से क्रमबद्ध और अक्रमबद्ध करने की अनुमति देता है, ऊपर चर्चा की गई एन्क्रिप्शन एल्गोरिदम आईडी के अलावा।

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

5.4 attestationObject को डिकोड और पार्स करना#

जब WebAuthn के भीतर attestationObject को डिकोड करने की बात आती है, तो डेवलपर्स को एक महत्वपूर्ण निर्णय का सामना करना पड़ता है: एक कस्टम समाधान विकसित करें या एक स्थापित पुस्तकालय का लाभ उठाएं। इस प्रक्रिया की जटिलता और महत्वपूर्ण प्रकृति को कम करके नहीं आंका जा सकता है। Base64URL और CBOR डिकोडिंग का मैन्युअल कार्यान्वयन, जबकि तकनीकी रूप से संभव है, सूक्ष्म त्रुटियों का जोखिम प्रस्तुत करता है जो प्रमाणीकरण प्रक्रिया की अखंडता से समझौता कर सकता है।

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

अटेस्टेशन स्टेटमेंट और ऑथेंटिकेटर डेटा निकालने के लिए CBOR प्रारूप को सही ढंग से पार्स करना।
पब्लिक की को पुनः प्राप्त करने के लिए COSE की प्रारूप की व्याख्या करना।
WebAuthn मानक के अनुसार हस्ताक्षर को मान्य करने के लिए क्रिप्टोग्राफिक जांच करना।

एक प्रतिष्ठित पुस्तकालय पर भरोसा करके, डेवलपर्स न केवल समय और संसाधनों की बचत करते हैं, बल्कि मन की शांति भी प्राप्त करते हैं। पब्लिक की, एक बार इन विश्वसनीय उपकरणों के माध्यम से निकाली और सत्यापित हो जाने के बाद, डेटाबेस में सुरक्षित रूप से संग्रहीत की जा सकती है, जो सुरक्षित प्रमाणीकरण सत्रों के लिए उपयोग किए जाने के लिए तैयार है। यह दृष्टिकोण प्रोटोकॉल के विनिर्देशों का पालन सुनिश्चित करता है और WebAuthn कार्यान्वयन में अपेक्षित सुरक्षा मुद्रा बनाए रखता है। सरलता के लिए, हम SimpleWebauthn डिबगर का उपयोग करेंगे जो CBOR फ़ील्ड्स को विस्फोटित JSON में परिवर्तित करके एक पूरी तरह से डिकोड किया गया संस्करण लौटाता है:

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": {
            "fmt": "packed",
            "attStmt": {
                "alg": "ES256 (-7)",
                "sig": "MEUCIQCL1TQk5WF1-1ijn3raO1sgUBOrr16b5zcttpKqzMbP0AIgJmpxampa7w_9X3tAm9n-tJY7YeJ54HJJCifCT7amYjs"
            },
            "authData": {
                "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                "flags": {
                    "userPresent": true,
                    "userVerified": true,
                    "backupEligible": false,
                    "backupStatus": false,
                    "attestedData": true,
                    "extensionData": false
                },
                "counter": 0,
                "aaguid": "adce0002-35bc-c60a-648b-0b25f1f05503",
                "credentialID": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
                "credentialPublicKey": "pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
                "parsedCredentialPublicKey": {
                    "keyType": "EC2 (2)",
                    "algorithm": "ES256 (-7)",
                    "curve": 1,
                    "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
                    "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
                }
            }
        },
        "clientDataJSON": {
            "type": "webauthn.create",
            "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
            "origin": "https://opotonniee.github.io",
            "crossOrigin": false
        },
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

SimpleWebauthn पुस्तकालय का उपयोग पूरे attestationObject को डिकोड करने के लिए किया जाता है। जैसा कि हम देख सकते हैं, अब सभी जानकारी पठनीय है। सभी क्रिप्टोग्राफिक जानकारी credentialPublicKey का हिस्सा है जो authData-भाग का हिस्सा है। जिसे पुस्तकालय ने parsedCredentialPublicKey स्टेटमेंट में विस्फोटित कर दिया है। विनिर्देश में, कई उदाहरण हैं कि COSE की प्रारूप कैसा दिखता है।

{
    "parsedCredentialPublicKey": {
        "keyType": "EC2 (2)",
        "algorithm": "ES256 (-7)",
        "curve": 1,
        "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
        "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
    }
}

यह आउटपुट credentialPublicKey के सभी क्रिप्टोग्राफिक तत्वों को बड़े करीने से मानव-पठनीय रूप में पार्स करके दिखाता है। यह विशेष उदाहरण ES256 एल्गोरिदम के लिए एक EC2 की को प्रकट करता है, जैसा कि एल्गोरिदम पैरामीटर और x और y निर्देशांक की उपस्थिति से संकेत मिलता है।

इसके विपरीत, एक विंडोज 10 सिस्टम का आउटपुट इस प्रकार दिखता है:

{
    "parsedCredentialPublicKey": {
        "keyType": "RSA (3)",
        "algorithm": "RS256 (-257)",
        "modulus": "mzRVwAL6jbccWT4NQ3rQWEYLkTKkEBeHPPUn0CXT8VwvvGE_IaXDeP9ZzcA7WoX3z6E0l_L-XZmRuKc9cO7BkiYyz3jOg_pNFTz5Ap9a1f_9H0m4mpL-30WHQZi1skB5f6zt8sO8q7rBYH0mRmH8LdCrhJRhVjB_UxbcAbYlpV98M5g-5OBs_boNXtMhMoyp-IOeGChp07wwSLVOH3hKMoxlU27hZ3QvK2LRWosNKhXSHcU9IOC0XOyhlZ5rtPX2ae3KsSE1H2rEJVcMaVMRAg8yx2SRM98pDvf829smrnJPdMBojKftne2j8o84i_xyDJ_jARlyVj0kxR37u0AVQQ",
        "exponent": 65537
    }
}

यहाँ, एल्गोरिदम आईडी -257 है, जो RS256 से मेल खाती है, और हम देख सकते हैं कि इस पब्लिक की की विशेषता वाले गुण ECDSA की के गुणों से काफी भिन्न हैं। COSE की प्रारूप प्रति प्रकार अद्वितीय विशेषताओं को निर्दिष्ट करने की अनुमति देता है:

विशेषता/प्रकार	ECDSA	RSA
की प्रकार	EC2 (एलिप्टिक कर्व 2)	RSA (3)
एल्गोरिदम	ES256 (-7)	RS256 (-257)
अद्वितीय विशेषताएँ	कर्व X-निर्देशांक Y-निर्देशांक	मापांक घातांक

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

6. सिफारिश#

पब्लिक-की क्रिप्टोग्राफी की मूल बातें जानने और यह समझने के बाद कि इसे WebAuthn / FIDO2 मानक में कैसे शामिल किया गया है, हमारे पास रिलाइंग पार्टियों के लिए दो प्रमुख सिफारिशें हैं:

सही एन्क्रिप्शन एल्गोरिदम चुनें: WebAuthn के कार्यान्वयन में, अधिकतम संगतता के लिए सही एल्गोरिदम का उपयोग करना महत्वपूर्ण है। वर्तमान सिफारिशों के आधार पर RS256, ES256, और EdDSA का संयोजन उचित है। RS256 और ES256 अपने व्यापक समर्थन के कारण सबसे अलग हैं, और EdDSA को शामिल करने से जहाँ संभव हो सुरक्षा बढ़ सकती है।
पब्लिक-की निकालने के लिए अच्छी तरह से परीक्षण किए गए WebAuthn पुस्तकालयों का उपयोग करें: एक बार जब आप एल्गोरिदम पर निर्णय ले लेते हैं, तो अगला कदम एक अच्छी तरह से परीक्षण किए गए WebAuthn पुस्तकालय को एकीकृत करना है। ऐसा पुस्तकालय * attestationObject* को पार्स करने की जटिलताओं को कुशलता से संभाल सकता है। पुस्तकालय द्वारा पब्लिक कीज़ और उससे जुड़े डेटा को निकालने के बाद इसे डेटाबेस में सुरक्षित रूप से संग्रहीत किया जा सकता है। पुस्तकालय द्वारा उपयोग किया जाने वाला प्रारूप आमतौर पर यह सुनिश्चित करता है कि की को इस तरह से संग्रहीत किया जाता है जिसे भविष्य के प्रमाणीकरण उद्देश्यों के लिए सटीक रूप से पढ़ा और उपयोग किया जा सकता है।

यह महत्वपूर्ण है कि पहिया को फिर से न बनाया जाए: स्थापित पुस्तकालयों के भीतर निहित सामूहिक ज्ञान का लाभ उठाएं। कस्टम कार्यान्वयन से त्रुटियों और सुरक्षा खामियों को पेश करने का जोखिम होता है जो प्रमाणीकरण की प्रभावशीलता और सिस्टम की समग्र सुरक्षा को कमजोर कर सकता है।

7. निष्कर्ष#

इस ब्लॉग पोस्ट में, हमने प्रारंभिक तीन मुख्य प्रश्नों के उत्तर देने के लिए पब्लिक-की क्रिप्टोग्राफी की मूल बातों की जांच की है:

WebAuthn में समर्थित एन्क्रिप्शन एल्गोरिदम: WebAuthn को लचीला होने के लिए डिज़ाइन किया गया है और यह एन्क्रिप्शन एल्गोरिदम की एक विस्तृत श्रृंखला का समर्थन करता है, जिसमें प्रमुख रूप से RSA (RS256), ECDSA (ES256), और EdDSA शामिल हैं। यह अनुकूलनशीलता इसे विभिन्न ऑथेंटिकेटर और प्लेटफार्मों के साथ सहजता से एकीकृत करने की अनुमति देती है, जिससे व्यापक संगतता सुनिश्चित होती है।
की पेयर बनाने में pubKeyCredParams की कार्यक्षमता: pubKeyCredParams WebAuthn प्रक्रिया के पंजीकरण चरण में एक महत्वपूर्ण भूमिका निभाता है, यह निर्दिष्ट करके कि रिलाइंग पार्टी कौन से क्रिप्टोग्राफिक एल्गोरिदम का समर्थन करती है। यह सुनिश्चित करता है कि बनाए गए की पेयर उपयोगकर्ता के ऑथेंटिकेटर और रिलाइंग पार्टी की आवश्यकताओं दोनों के साथ संगत हैं।
credentialPublicKey की कार्यक्षमता और पब्लिक कीज़ निकालना: credentialPublicKey का उपयोग ऑथेंटिकेटर द्वारा प्रदान किए गए attestationObject से पब्लिक कीज़ निकालने के लिए किया जाता है।

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