ESP32 पर WireGuard कुंजियाँ: हर डिवाइस के लिए अलग या एक ही अंतर्निहित?

स्केच WireGuard की निजी कुंजी को एक अक्षर सरणी में रखता है, और सुरंग काम करती है, इसीलिए यह सवाल बार-बार उठता है। जो निर्णय आपको वास्तव में लेना है वह «क्या यह सुरक्षित है» नहीं, बल्कि «तीन शर्तों में से कौन इस परिनियोजन पर लागू होती है» है। वे हैं: कौन डिवाइस को भौतिक रूप से पकड़ सकता है, आपके हिस्से पर फ़्लैश पढ़ने से क्या मिलता है, और क्या बेड़ा एक कुंजी साझा करता है या हर इकाई अपनी ले जाती है। इनका उत्तर दें और डिज़ाइन सामने आ जाएगा, क्योंकि हर शर्त लीक हुई कुंजी की कीमत बदलती है, यह तथ्य नहीं कि वह लीक हो सकती है।

कुंजी किस बात का अधिकार देती है

WireGuard सहकर्मियों को सार्वजनिक कुंजी से प्रमाणित करता है। सर्वर हर सहकर्मी की सार्वजनिक कुंजी को एक पते और AllowedIPs सूची से जोड़ता है, इसलिए निजी कुंजी ही क्लाइंट को उस पते से ट्रैफ़िक भेजने देती है।

यही प्रविष्टि तय करती है कि डिवाइस किन गंतव्यों तक पहुँच सकता है, इसलिए लीक हुई कुंजी सुरंग के पीछे का नेटवर्क और सुरंग का पता दोनों उजागर करती है।

शर्त एक: डिवाइस कौन पकड़ सकता है

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

इस शर्त को बाकी दो से पहले तय करें, क्योंकि यह दोनों के लिए बजट तय करती है।

शर्त दो: फ़्लैश पढ़ने से क्या मिलता है

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

डिज़ाइन समीक्षा में कोई गुण दावा करने से पहले अपने सटीक चिप और कॉन्फ़िगरेशन के लिए प्लेटफ़ॉर्म दस्तावेज़ पढ़ें।

शर्त तीन: पूरे बेड़े में पुनःउपयोग

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

अगर बेड़ा बेंच पर पाँच इकाइयों का है, तो कुंजी साझा करना उचित सौदा हो सकता है। अगर मैदान में पाँच सौ है, तो यह कोई सौदा ही नहीं है।

वह नामांकन पैटर्न जो प्रति-डिवाइस कुंजियों को व्यावहारिक बनाता है

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

यह एक छोटी सेवा है, और यही अंतर है — जिस बेड़े का आप अंकेक्षण कर सकते हैं और जिसे केवल पुनःफ़्लैश कर सकते हैं, उसके बीच।

समय, समापन-बिंदु और निर्णय

उदाहरण सुरंग शुरू करने से पहले समय का तालमेल करता है, और यह TLS से आगे मायने रखता है: WireGuard के हाथ मिलाने में पुनःप्रसारण सुरक्षा के लिए समय-चिह्न होता है, इसलिए गलत घड़ी से बूट होने वाले डिवाइस के हाथ मिलाने अस्वीकार हो सकते हैं। समापन-बिंदु एक होस्टनाम है, जो DNS को विश्वास के पथ में डालता है, हालाँकि सर्वर की सार्वजनिक कुंजी अब भी सहकर्मी को प्रमाणित करती है। गलत पता प्रयास बर्बाद करता है और उजागर करता है कि डिवाइस कब ऑनलाइन है। कुंजी पर बहस करने से पहले दोनों संभालें।

फिर तय करें: साझा कुंजी केवल तब तक जब कब्ज़ा नियंत्रित हो और बेड़ा छोटा हो, प्रति-डिवाइस कुंजियाँ जैसे ही इनमें से एक भी सच होना बंद करे।