आठ बिट्स का भरोसा: eMudhra की CA कुंजियाँ मिलीसेकंडों में टूट गईं
एक प्रमुख भारतीय certificate authority, eMudhra, को ऐसा पाया गया कि उसने कई elliptic-curve CA private keys वस्तुतः केवल 8 bits of entropy के साथ जनरेट किए थे, जिनमें एक “4” मान वाली कुंजी भी शामिल थी, जिससे वे अपनी public certificates से मिलीसेकंडों में टूट सकीं। टिप्पणीकार चर्चा करते हैं कि यह ब्राउज़र trust stores तक कैसे पहुँच गया, यह web के certificate authority model की नाज़ुकता के बारे में क्या दिखाता है, और Certificate Transparency जैसी safeguards की सीमाएँ क्या हैं। वे unpatchable IoT और embedded devices पर दीर्घकालिक प्रभाव को भी रेखांकित करते हैं, जो अब trust stores के अपडेट होने या devices के retired होने तक HTTPS man‑in‑the‑middle attacks के लिए आसानी से vulnerable हो सकते हैं—या opportunistically jailbroken भी किए जा सकते हैं।
कमज़ोर कुंजियों का कारण
- टिप्पणीकार Mozilla बग रिपोर्ट का विश्लेषण करते हैं: eMudhra “KGC script” में हुए एक विचलन को दोष देता है, जिसका उपयोग निर्यात के लिए ECC कुंजियों को wrap/unwrap करने में किया गया था।
- एक दूसरी, कहीं अधिक कमज़ोर key pair apparently एक code flaw के कारण जनरेट हुई, और उलझन पैदा करने वाले रूप से मिलते-जुलते key labels के कारण operators ने CSRs और cross-signing के लिए गलत कुंजियाँ इस्तेमाल कर लीं।
- कई लोगों को यह चिंताजनक लगता है कि HSM या ceremony tooling इतनी छोटी range में कुंजियाँ बना ही सकता था; वे “test/weak key” क्षमताओं को मूल डिज़ाइन की समस्या मानते हैं।
दुर्भावना बनाम अक्षमता
- कई लोग तर्क देते हैं कि यह घोर लापरवाही या “advanced stupidity” है, दुर्भावना नहीं: यदि आपके पास पहले से CA का नियंत्रण है, तो उसे दुरुपयोग करने के लिए कमज़ोर कुंजी की ज़रूरत नहीं होती।
- अन्य लोग नोट करते हैं कि जानबूझकर रखी गई कमज़ोरी plausible deniability दे सकती है, लेकिन अधिकांश लोग फिर भी “bug + sloppy procedures” वाली व्याख्या को अधिक संभव मानते हैं।
प्रणालीगत CA और ऑडिट समस्याएँ
- एक मज़बूत धारणा यह है कि CA ecosystem पर बहुत अधिक भरोसा किया जाता है और बहुत कम सत्यापन होता है: सैकड़ों roots और हज़ारों intermediates हैं, लेकिन CA keys के लिए बुनियादी entropy/unit tests तक नहीं हैं।
- Audits की आलोचना box-ticking exercises के रूप में की जाती है, जो 8‑bit keys जैसी तुच्छ विफलताओं को भी चूक सकती हैं।
- कुछ लोग सुझाते हैं कि यह घटना firm-ending होनी चाहिए; अन्य लोग कहते हैं कि कई CAs “grandfathered” हैं और राजनीतिक/eIDAS-शैली की आवश्यकताओं के कारण कठोर pruning की संभावना कम है।
प्रभाव और शमन
- तात्कालिक सलाह: OS CA bundles, language runtimes, और container images को rebuild करें; ध्यान दें कि Flatpak और कुछ runtimes अभी भी अपने खुद के stores ship कर सकते हैं।
- unpatchable या शायद ही अपडेट होने वाले devices (routers, TVs, printers, IoT, embedded Java keystores) को लेकर बड़ी चिंता है, जो 2039 तक इन intermediates पर भरोसा करते रहेंगे।
खोज और अन्य कमज़ोर कुंजियों की तलाश
- बताया गया है कि weak keys Google के paranoid_crypto को CCADB certificates पर चलाकर पाए गए; उस corpus की आगे की scanning में ऐसे और मामले नहीं मिले।
- कई लोग सभी roots/intermediates पर व्यापक automated checks (“luggage code entropy”) का प्रस्ताव रखते हैं, जिसमें truncated या timestamp-seeded keys भी शामिल हों।
PKI विकल्पों पर बहसें
- लंबे subthreads CAs को DNSSEC/DANE, name constraints, या content-signing और user-controlled trust graphs के माध्यम से बदलने या सीमित करने पर बहस करते हैं।
- प्रतिवाद deployment failures (DNSSEC), TLD operators के साथ राजनीतिक/control issues, गैर-विशेषज्ञों के लिए usability, और legacy clients की निरंतर मौजूदगी पर ज़ोर देते हैं।
IoT और अवसरवादी उपयोग
- कई लोग पहले से ही broken CA keys का उपयोग traffic को MITM करने और locked-down devices (smart speakers, appliances, ESP32 hardware) को jailbreak करने के लिए कर रहे हैं।
- इस dual-use पहलू को devices के unpatched रहने तक एक दुर्लभ “upside” और confidentiality के लिए गंभीर जोखिम, दोनों माना जा रहा है।