eMudhra इंटरमीडिएट CA समझौता

मूल लेख ↗ Hacker News चर्चा ↗

एक भारतीय प्रमाणपत्र प्राधिकरण, eMudhra, ने कई इंटरमीडिएट TLS और code-signing certificates जारी किए, जिनकी elliptic-curve private keys वस्तुतः आसानी से अनुमान लगाने योग्य थीं (जैसे “4” जैसे एकल-अंकीय मान), जिससे ब्राउज़रों और OS विक्रेताओं द्वारा revoke किए जाने तक कोई भी मनचाहे domains के लिए certificates forge कर सकता था। टिप्पणीकारों का कहना है कि प्रमुख ब्राउज़रों के revocation और Certificate Transparency mechanisms ने वेब उपयोगकर्ताओं के लिए जोखिम सीमित किया, लेकिन बड़ी संख्या में non-browser clients और IoT devices जो अपने स्वयं के CA stores embed करते हैं, वर्षों तक कमजोर रह सकते हैं। यह घटना Web PKI मॉडल की आलोचना को फिर से भड़काती है—जहाँ कोई भी trusted CA किसी भी domain के लिए vouch कर सकता है—और DNSSEC/DANE, सख्त name constraints, तथा अधिक केंद्रीकृत या audited revocation infrastructure जैसे विकल्पों पर बहस को तेज़ करती है।

घटना का अवलोकन

  • आठ eMudhra/emSign इंटरमीडिएट CAs की निजी कुंजियाँ अत्यंत आसानी से पुनः प्राप्त करने योग्य पाई गईं।
  • ये P-384 ECC कुंजियाँ थीं जिनके निजी स्कैलर बहुत छोटे पूर्णांक थे (<256); एक कुंजी तो सचमुच “4” थी।
  • इंटरमीडिएट्स को एक अन्य प्रमुख CA द्वारा क्रॉस-साइन किया गया था, इसलिए वे व्यापक रूप से विश्वसनीय रूट्स तक चेन करते थे।
  • प्रभावित इंटरमीडिएट्स में TLS (DV सहित) और कम-से-कम दो Microsoft-विश्वसनीय कोड-साइनिंग CAs शामिल थीं।

तकनीकी मूल कारण (जैसा कि चर्चा में बताया गया)

  • eMudhra की घटना रिपोर्ट दोष Ultimaco HSMs के साथ उपयोग किए गए एक की-जेनरेशन सेरेमनी स्क्रिप्ट की एक खामी पर डालती है।
  • सामान्य कुंजियाँ कथित तौर पर ऑन-HSM जनरेट की गई थीं, लेकिन एक wrap/unwrap “test” पथ ने कमजोर द्वितीयक कुंजियाँ उत्पन्न कीं।
  • समान लेबलों के कारण, स्टाफ ने गलती से इन कमजोर कुंजियों का उपयोग CSRs बनाने के लिए किया, जिन्हें फिर eMudhra के रूट और क्रॉस-साइनिंग CA — दोनों द्वारा साइन किया गया।
  • CRLs को शुरू में “सही” कुंजियों से साइन किया गया, वे वैलिडेशन में विफल रहीं, और फिर उन्हें कमजोर कुंजियों से पुनः साइन किया गया; कई लोग इसे एक बड़ी प्रक्रिया विफलता मानते हैं।

सुरक्षा प्रभाव

  • जिनके पास इन इंटरमीडिएट्स के सार्वजनिक certs हैं, वे निजी कुंजियाँ निकाल सकते हैं और वैध दिखने वाले leaf certs जारी कर सकते हैं।
  • यह उन क्लाइंट्स के लिए अदृश्य MITM सक्षम करता है जो:
    • प्रभावित चेन पर भरोसा करते हैं, और
    • Certificate Transparency (CT) लागू नहीं करते।
  • जिन ब्राउज़रों में CT आवश्यक है, वे बिना-लॉग किए दुरुपयोग को अस्वीकार कर देंगे, और इन इंटरमीडिएट्स से कोई पूर्व-घटना leaf cert CT logs में नहीं देखा गया।
  • गैर-ब्राउज़र TLS (curl, IoT, VPNs, embedded/industrial systems) भारी जोखिम में है क्योंकि उनमें से कई CT नहीं करते और शायद ही trust stores अपडेट करते हैं।

रिवोकेशन और इकोसिस्टम की प्रतिक्रिया

  • प्रमुख ब्राउज़रों ने केंद्रीकृत तंत्रों (CRLSet/OneCRL/CRLite-जैसी) का उपयोग करके इंटरमीडिएट्स को तेज़ी से ब्लॉक किया; उपयोगकर्ताओं को अक्सर सॉफ़्टवेयर अपडेट की आवश्यकता नहीं पड़ी।
  • OSes और libraries अलग-अलग हैं: Windows केंद्रीय रूप से ब्लॉक कर सकता है; Linux/Unix आम तौर पर केवल PEM bundles ship करते हैं, इसलिए Go, rustls, Homebrew, Python का certifi, Electron, आदि आपातकालीन अपडेट भेज रहे हैं जो इंटरमीडिएट्स को hard-block करते हैं।
  • कई projects अपने स्वयं के CA bundles embed करते हैं, जिससे पूरे ecosystem का remediation धीमा और असमान हो जाता है।
  • कुछ उपयोगकर्ताओं ने रिपोर्ट किया कि mobile Firefox पर CRL updates propagate होने तक blocking असंगत रही।

Web PKI बनाम विकल्पों पर बहस

  • इस बात की कड़ी आलोचना कि कोई भी trusted CA किसी भी domain के लिए issue कर सकती है, जिससे सुरक्षा सबसे कमजोर CA पर निर्भर हो जाती है।
  • प्रस्ताव और counter-arguments:
    • DNSSEC/DANE: समर्थक auth को DNS hierarchy के साथ align करने के पक्ष में हैं; आलोचक operational fragility, गलत व्यवहार करने वाले TLDs को “kill” न कर पाने, और Web PKI की तुलना में कमजोर monitoring/ejection mechanisms की ओर इशारा करते हैं।
    • Name constraints और CAA: इन्हें कम उपयोग में या deploy करने में कठिन माना जाता है (NCs), और CAA केवल issuance को constrain करता है, client acceptance को नहीं।
    • Web-of-trust: कुछ लोग इसे अधिक मानव-स्वाभाविक मानते हैं; अन्य PGP की ऐतिहासिक विफलताओं और de-facto केंद्रीय प्राधिकरणों के उभरने की ओर संकेत करते हैं।
  • कई टिप्पणीकार Web PKI के “death penalty” मॉडल का बचाव करते हैं: ब्राउज़र CAs को eject कर सकते हैं और करते भी हैं; आप व्यावहारिक रूप से किसी TLD को eject नहीं कर सकते।

eMudhra और CAs के लिए परिणाम

  • कई लोगों को उम्मीद है कि eMudhra के roots प्रमुख root programs से हटाए जाएंगे; पिछले CA “death penalty” मामलों से तुलना की जा रही है।
  • कुछ लोग एक संबंधित brand के माध्यम से US विश्वविद्यालय certificate ecosystems में eMudhra की भूमिका की ओर ध्यान दिलाते हैं, जिससे supply-chain चिंताएँ बढ़ती हैं।
  • यह घटना CA auditing में कथित कमजोरियों और key export तथा व्यापक उपयोग के लिए अभिप्रेत intermediates की अनुमति देने को उजागर करती है।

व्यापक सबक (IoT, टूलिंग, trust stores)

  • IoT और अन्य non-updatable या शायद ही अपडेट होने वाले devices इन intermediates पर उनके expiry (~2039) तक भरोसा कर सकते हैं, जिससे वे लंबे समय के MITM targets बन जाते हैं।
  • कुछ लोग locked-down devices के reverse-engineering के लिए benign MITM आसान होने में एक “silver lining” देखते हैं।
  • यह घटना कई fragment किए गए trust stores और bespoke TLS stacks के बजाय लगातार अपडेट होने वाले platform mechanism की कमी की लागत को उजागर करती है।
  • कई tools और projects (जैसे upki, Nix overlays) गैर-ब्राउज़र software के लिए केंद्रीकृत, स्वचालित revocation सुधारने के तरीके के रूप में चर्चा में हैं।