eMudhra Security Breach: 8 कमजोर Keys से इंटरनेट की सुरक्षा पर सवाल

Key Points

• eMudhra के 8 Intermediate Certificates की Private Keys में गंभीर कमजोरी मिली, जिससे फर्जी वेबसाइट सर्टिफिकेट बनाने का खतरा पैदा हुआ।
• Google, Apple, Microsoft और Mozilla ने सुरक्षा के लिए कदम उठाए हैं।
• MeitY के अनुसार, भारत में Digital Signature Certificate (DSC) और eSign सेवाएं प्रभावित नहीं हुई हैं।

टेक्नोलॉजी डेस्क,

eMudhra security breach के मामले में कंपनी के 8 Intermediate CA Certificates से जुड़ी Private Keys में गंभीर कमजोरी सामने आई है। ये सर्टिफिकेट्स अप्रैल 2025 में बनाए गए थे। जांच में पता चला कि Key Generation Process के दौरान कमजोर Keys तैयार हो गई थीं, जिनका इस्तेमाल करके हमलावर दूसरे डोमेन के लिए फर्जी डिजिटल सर्टिफिकेट बना सकते थे। Google, Apple, Microsoft और Mozilla ने प्रभावित सर्टिफिकेट्स को ब्लॉक करने के लिए कदम उठाए हैं। वहीं, भारतीय IT मंत्रालय (MeitY) ने मामले की जांच के लिए विशेष टीम बनाई है। सरकार के मुताबिक, भारतीय DSC और eSign सेवाएं इस घटना से प्रभावित नहीं हुई हैं।

eMudhra Security Breach में आखिर क्या हुआ?

eMudhra एक भारतीय डिजिटल ट्रस्ट और साइबर सिक्योरिटी कंपनी है। इसकी Global TLS सेवाएं वेबसाइट्स और ऑनलाइन सर्विसेज की पहचान सत्यापित करने में मदद करती हैं। इस सिस्टम में Digital Certificates का इस्तेमाल होता है, ताकि ब्राउजर यह जांच सके कि यूजर सही वेबसाइट से जुड़ रहा है या नहीं।

21 अक्टूबर 2026 को जारी जानकारी के मुताबिक, यह मामला eMudhra के Global TLS Infrastructure से जुड़े 8 Intermediate Certificate Authorities (CA) का है। इन सर्टिफिकेट्स की Private Keys तैयार करने की प्रक्रिया में गड़बड़ी हुई थी।

कंपनी के अनुसार, 30 अप्रैल 2025 को हुए Key Generation Ceremony के दौरान एक प्रक्रिया में गड़बड़ी के कारण मूल मजबूत Keys के साथ कमजोर Keys का दूसरा सेट भी बन गया। कमजोर Keys ही ब्राउजर के Trust Stores तक पहुंच गई थीं। कंपनी ने कहा है कि वह इस गड़बड़ी के मूल कारण की जांच कर रही है।

कमजोर Private Keys कितनी गंभीर थीं?

CERT-In के अनुसार, प्रभावित Keys को P-384 Elliptic Curve Cryptography के तहत बनाया जाना था। इस तरह की Cryptography में सही तरीके से तैयार की गई Private Key को अनुमान लगाकर निकालना बेहद मुश्किल होना चाहिए।

लेकिन इस मामले में कमजोर Keys की वैल्यू 256 से भी कम थी। इसलिए संबंधित Public Keys से इन Private Keys को लगभग तुरंत रिकवर किया जा सकता था।

इसका मतलब यह नहीं है कि P-384 Encryption Algorithm में ही कोई खामी पाई गई है। CERT-In ने स्पष्ट किया कि कमजोरी Key Generation Process में थी, न कि P-384 Algorithm में। यह अंतर महत्वपूर्ण है, क्योंकि समस्या मजबूत Cryptographic System के गलत इस्तेमाल से पैदा हुई थी।

फर्जी वेबसाइट और Data Interception का खतरा कैसे पैदा हुआ?

वेबसाइट खोलते समय ब्राउजर उसके डिजिटल सर्टिफिकेट की मदद से उसकी पहचान जांचता है। यदि सर्टिफिकेट भरोसेमंद CA से जुड़ा होता है और बाकी जरूरी जांच सही होती हैं, तो ब्राउजर सुरक्षित कनेक्शन स्थापित कर सकता है।

Intermediate Certificate एक ऐसी कड़ी है जो Root Certificate Authority और वेबसाइट के सर्टिफिकेट के बीच भरोसे का संबंध बनाती है। यदि इस कड़ी की Private Key पर हमलावर का नियंत्रण हो जाए, तो वह ऐसी वेबसाइट के लिए भी फर्जी सर्टिफिकेट जारी करने की कोशिश कर सकता है, जिसे वह नियंत्रित नहीं करता।

इससे तीन बड़े खतरे पैदा हो सकते थे:

• Fake Website Certificates: हमलावर किसी असली वेबसाइट के नाम पर फर्जी डिजिटल सर्टिफिकेट जारी कर सकता था।
• Man-in-the-Middle Attack: कुछ परिस्थितियों में हमलावर यूजर और सर्वर के बीच होने वाले कनेक्शन को इंटरसेप्ट या बदल सकता था।
• Sensitive Data का जोखिम: यदि हमला सफल होता, तो पासवर्ड, लॉगिन जानकारी या दूसरी संवेदनशील जानकारी खतरे में पड़ सकती थी।

हालांकि, खतरा पैदा होने और वास्तव में हमला होने में अंतर है। 21 अक्टूबर 2026 तक उपलब्ध सार्वजनिक जानकारी में इन कमजोर Keys के इस्तेमाल से किसी सफल दुर्भावनापूर्ण हमले की पुष्टि नहीं हुई थी। Google ने यह भी बताया कि ब्लॉकिंग से पहले प्रभावित छह TLS Intermediate CAs से जुड़े किसी TLS सर्टिफिकेट की Certificate Transparency Logs में एंट्री नहीं मिली थी।

Google, Apple और Mozilla ने क्या कार्रवाई की?

कमजोर Keys का पता चलने के बाद ब्राउजर कंपनियों और दूसरी टेक्नोलॉजी कंपनियों ने प्रभावित सर्टिफिकेट्स पर भरोसा रोकने के लिए कदम उठाए। इसका उद्देश्य उन Keys का इस्तेमाल करके बनाए जा सकने वाले फर्जी सर्टिफिकेट्स से यूजर्स को बचाना था।

Google के मुताबिक, Chrome ने 17 अक्टूबर 2026 को प्रभावित Intermediate CAs की Public Keys को ब्लॉक करने के लिए CRLSet अपडेट जारी किया। कंपनी ने Android डिवाइसों के लिए भी Google Play Services के माध्यम से सुरक्षा अपडेट पहुंचाए।

Mozilla ने Firefox में OneCRL के जरिए प्रभावित TLS Intermediate Certificates को ब्लॉक किया। कंपनी ने कुछ ऐसे यूजर्स के लिए Firefox के अतिरिक्त सिक्योरिटी रिलीज भी जारी किए, जिनकी सेटिंग्स के कारण सामान्य ब्लॉकिंग अपडेट उन तक नहीं पहुंच सकता था।

Apple और Microsoft ने भी प्रभावित सर्टिफिकेट्स के खिलाफ सुरक्षा कदम उठाए। इसके अलावा, Cloudflare जैसी इंटरनेट इंफ्रास्ट्रक्चर कंपनियों ने अपने सिस्टम और ग्राहकों की सुरक्षा के लिए कार्रवाई की। 

Chrome Root Store से emSign Certificate भी हटेगा

Google ने प्रभावित Intermediate Certificates को ब्लॉक करने के अलावा emSign ECC Root CA – G3 को Chrome Root Store से हटाने का फैसला भी किया है। यह Root Certificate उन प्रभावित Intermediate Certificates पर हस्ताक्षर करने वाली Trust Chain का हिस्सा था।

Google के अनुसार, यह बदलाव Chrome Root Store पर निर्भर डिवाइसों के लिए 27 अक्टूबर 2026 को जारी होने की उम्मीद है। इसका उद्देश्य ऐसे ऐप्स और डिवाइसों को भी सुरक्षा देना है, जो Intermediate Certificate Revocation की जानकारी प्राप्त नहीं करते।

हालांकि, इस कदम का दूसरा पहलू भी है। जिन वैध वेबसाइट्स के सर्टिफिकेट इसी Root Certificate पर निर्भर हैं, वे कुछ सिस्टम में अविश्वसनीय माने जा सकते हैं। इसलिए प्रभावित वेबसाइट ऑपरेटरों को वैकल्पिक Trust Hierarchy से नया TLS Certificate लेने और उसे इंस्टॉल करने की जरूरत पड़ सकती है।

क्या भारत की Digital Signature और eSign सेवाएं प्रभावित हुई हैं?

इस मामले में सबसे महत्वपूर्ण सवाल यह है कि क्या भारतीय यूजर्स की Digital Signature Certificate (DSC) और eSign सेवाओं पर भी असर पड़ा है।

MeitY और CERT-In के अनुसार, यह घटना eMudhra के Global TLS Certificate Business से संबंधित है। कंपनी की भारतीय DSC और eSign सेवाएं अलग इंफ्रास्ट्रक्चर पर चलती हैं और इस घटना से प्रभावित नहीं हुई हैं।

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

eMudhra ने अपने बयान में कहा कि उसके आंतरिक इंफ्रास्ट्रक्चर में सेंध नहीं लगी और किसी डेटा ब्रीच की पुष्टि नहीं हुई है। कंपनी के अनुसार, प्रभावित Global TLS Business उसके कुल रेवेन्यू का लगभग 1 प्रतिशत है। हालांकि, कंपनी ने संभावित प्रतिष्ठागत नुकसान की आशंका जताई है।

ध्यान देने वाली बात यह है कि कंपनी के बयान, सरकार की शुरुआती जानकारी और जांच के अंतिम निष्कर्ष अलग-अलग चीजें हैं। घटना की पूरी तकनीकी वजह और सभी संभावित प्रभावों की पुष्टि जांच पूरी होने के बाद ही हो सकेगी।

आम इंटरनेट यूजर्स को क्या करना चाहिए?

फिलहाल आम यूजर्स को घबराने या अपने ब्राउजर की Certificate Settings में खुद से बदलाव करने की जरूरत नहीं है। सबसे जरूरी है कि डिवाइस और सॉफ्टवेयर को अपडेट रखा जाए।

यूजर्स ये कदम उठा सकते हैं:

• Browser अपडेट करें: Chrome, Firefox या दूसरे ब्राउजर का उपलब्ध नवीनतम सिक्योरिटी अपडेट इंस्टॉल करें।
• Operating System अपडेट रखें: Windows, Android, macOS और अन्य सिस्टम के लिए उपलब्ध सुरक्षा अपडेट लगाएं।
• Certificate Warning को नजरअंदाज न करें: अगर किसी वेबसाइट पर Certificate Error दिखाई दे, तो उसे बायपास करके आगे न बढ़ें।
• संदिग्ध लिंक से बचें: बैंकिंग, ईमेल या दूसरे संवेदनशील अकाउंट में लॉगिन करते समय वेबसाइट का सही डोमेन जांचें।
• सॉफ्टवेयर की सुरक्षा जांचें: अगर आप किसी कंपनी की वेबसाइट या ऐप चलाते हैं, तो उसके ऑपरेटर से पुष्टि करें कि जरूरी Certificate और Trust Store अपडेट लागू हैं।

Google ने बताया कि Chrome की शुरुआती ब्लॉकिंग सुरक्षा के लिए ब्राउजर को अपडेट या रीस्टार्ट करना जरूरी नहीं था। फिर भी, डिवाइस और ऐप्स को अपडेट रखना एक अच्छा सुरक्षा उपाय है, क्योंकि अलग-अलग सिस्टम में सुरक्षा अपडेट पहुंचने का तरीका अलग हो सकता है।

वेबसाइट मालिकों और IT एडमिनिस्ट्रेटर्स के लिए यह मामला ज्यादा महत्वपूर्ण है। उन्हें जांचना चाहिए कि उनके TLS Certificates प्रभावित Trust Chain पर निर्भर तो नहीं हैं। जरूरत पड़ने पर नया सर्टिफिकेट इंस्टॉल करके वेबसाइट, ऐप और सर्वर पर उसकी वैधता जांचनी चाहिए।

eMudhra Incident से क्या सबक मिलता है?

यह घटना दिखाती है कि इंटरनेट की सुरक्षा केवल मजबूत Encryption Algorithm पर निर्भर नहीं करती। Keys को सही तरीके से तैयार करना, सर्टिफिकेट जारी करने की प्रक्रिया की जांच करना और सुरक्षा कमजोरियां सामने आने पर तुरंत कार्रवाई करना भी उतना ही जरूरी है।

इस मामले में प्रभावित सर्टिफिकेट्स को ब्लॉक करने के लिए कई कंपनियों ने कदम उठाए हैं। लेकिन पुराने सॉफ्टवेयर, अलग Trust Stores और अपडेट न मिलने वाले डिवाइसों के कारण सुरक्षा सुधार लागू करना चुनौतीपूर्ण हो सकता है।

फिलहाल उपलब्ध जानकारी के अनुसार, भारतीय DSC और eSign सेवाएं प्रभावित नहीं हुई हैं और कमजोर Keys के इस्तेमाल से किसी सफल हमले की पुष्टि नहीं हुई थी। फिर भी, यह घटना डिजिटल सर्टिफिकेट सिस्टम की विश्वसनीयता और उसकी निगरानी पर गंभीर सवाल उठाती है।