هشت بیت اعتماد؛ کلیدهای CA eMudhra در چند میلی ثانیه شکستند

یکی از کلیدهای خصوصی مجوز eMudhra عدد 4 است.

نه عددی که با 4 شروع شود یا عدد 4 به دنبال آن چند صد رقم تصادفی، فقط، 4... یکی دیگر 56 است و دیگری 115. می دانم، چون همین الان همه آنها را از گواهینامه عمومی آنها در لپ تاپم بازیابی کردم و کمتر از یک ثانیه طول کشید.

در روز شنبه 17 اکتبر، یک محقق امنیتی به اپل، گوگل، مایکروسافت، موزیلا و eMudhra گزارش داد که کلیدهای خصوصی هشت گواهی میانی eMudhra به خطر افتاده است. کروم یک به‌روزرسانی CRLSet را اعمال کرد و آن‌ها را در همان عصر مسدود کرد و موزیلا چند ساعت بعد آنها را از طریق OneCRL در فایرفاکس مسدود کرد. در روز سه‌شنبه 20، موزیلا آن را به‌طور عمومی اعلام کرد و یک به‌روزرسانی NSS را ارسال کرد که ریشه eMudhra را حذف می‌کند، و کروم تأیید کرد که روت در Chrome Root Store نسخه 43 عرضه می‌شود.

هشت واسطه شامل شش CA صادرکننده TLS (DV، OV و EV، هر کدام دو نسل) و دو CA امضاکننده کد هستند که همگی در آوریل 2025 ایجاد شدند. هر یک از آنها نیز توسط ریشه خدمات گواهینامه AAA Sectigo در می 2025 امضا شد.

این «چی» است، اما «چگونه» آن قسمت جالب است، و توسط ایان کارول در یک خط در موضوع خلاصه شده است:

اینها کلیدهای منحنی بیضی روی منحنی P-384 هستند. کلید خصوصی فقط یک عدد است، d. کلید عمومی، چیزی که در گواهی می رود تا دنیا ببیند، d × G است، جایی که G یک نقطه ثابت روی منحنی است که همه از آن استفاده می کنند و «×» به معنای افزودن G به خودش d برابر با استفاده از محاسبات خاص منحنی است.

به جلو رفتن آسان است، اما به عقب، از کلید عمومی به d، غیرعملی تلقی می شود. این کل مدل امنیتی است و فقط زمانی برقرار است که d بسیار زیاد باشد. یک کلید خصوصی P-384 باید یک عدد تصادفی 384 بیتی باشد که به شما 2384 احتمال (یا تقریبا 101115) می دهد، بنابراین هیچ کس هرگز آن را جستجو نمی کند.

این 47 بایت صفر و سپس یک بایت است و هر 8 کلید اینگونه هستند. یک بایت دارای 256 مقدار ممکن است، بنابراین "جستجو" به این صورت است: 1 × G , 2 × G , 3 × G را محاسبه کنید و زمانی که با گواهی مطابقت داشت متوقف می شود که حداکثر 255 مرحله است.

بنابراین، در کل، هر گواهینامه ای که آن CA ها می توانستند صادر کنند، هر کلاینتی که به آنها اعتماد داشت، بر هشت بیت استوار بود.

موزیلا گواهی‌های آسیب‌دیده را به اعلامیه‌شان پیوست، بنابراین من تمام ۱۶ کلید (۸ کلید، که هر کدام در دو گواهی صادر شده استفاده می‌شوند: یک‌بار توسط eMudhra و یک‌بار توسط Sectigo) را کشیدم و آنها را به‌صورت بی‌رحمانه مجبور کردم. هر یک فورا از بین رفت، شش مقدار TLS، و دو کلید امضای کد به همان اندازه ضعیف هستند:

جالب است که هیچ چیز در مورد این گواهینامه ها اشتباه به نظر نمی رسد. یک کلید عمومی مشتق شده از d = 4 یک نقطه کاملا معتبر در منحنی است، رمزگذاری خوب است، منحنی خوب است، هر بررسی ساختاری انجام می شود. تنها راه برای فهمیدن این است که تلاش کنید.

معمولا وقتی یک کلید CA به خطر می افتد، شخصی آن را دزدیده است! یک دزد وجود دارد، یک لحظه آن اتفاق افتاده است، و شما حداقل می توانید در مورد اینکه چه کسی اکنون به آن کلید دسترسی دارد، استدلال کنید.

اینجا کسی مجبور نبود چیزی بدزدد. کلید از روزی که گواهی وجود داشت به طور مؤثر عمومی بود. هر کسی که از آوریل 2025 به یکی از این گواهی‌ها نگاه می‌کرد، می‌توانست کلید را در چند میلی ثانیه روی سخت‌افزار کالا بازیابی کند. این یک پنجره 17 ماهه است و هیچ راهی برای دانستن اینکه آیا کسی این کار را کرده است وجود ندارد.

Chrome به این نکته اشاره کرد که چون Chrome شفافیت گواهی را اعمال می‌کند و هیچ گواهی TLS زنجیره‌ای به این CA در CT نشان داده نمی‌شود، هیچ گواهی جعلی نمی‌توانست به‌طور پیش‌فرض در Chrome قابل اعتماد باشد. این درست است و برای مرورگرها اطمینان بخش است. CT با وجود این، صدور اشتباه را تشخیص می دهد، از آن جلوگیری نمی کند، و بسیاری از نرم افزارها اصلا CT را بررسی نمی کنند.

مرورگرهای اصلی و به روز شده احتمالا کاملا خوب هستند. کروم و فایرفاکس مستقیما واسطه ها را مسدود می کنند و هر دو به CT نیاز دارند و سافاری نیز به CT نیاز دارد.

با این حال، هر چیز دیگری داستان متفاوتی است. اکثر کلاینت‌های TLS غیر مرورگر (بنابراین اساسا همه چیزهای دیگر، با تنظیمات پیش‌فرض)، مواردی مانند curl، Python، Node، Go، Java، git، مدیریت بسته‌ها و هر اسکریپت و دیمونی که دارید، سه کار مهم را در اینجا انجام می‌دهند: آنها به یک بسته CA روی دیسک اعتماد می‌کنند، به طور پیش‌فرض ابطال را بررسی نمی‌کنند و CT را بررسی نمی‌کنند. بنابراین این واقعیت که eMudhra و Sectigo این واسطه ها را لغو کرده اند به هیچ وجه به آنها کمک نمی کند.

این چیزی است که من اغلب هنگام صحبت در مورد TLS و PKI می یابم، درک اینکه چقدر اکوسیستم مشتری عظیم است را می توان نادیده گرفت. هنگامی که به راه حل های مدرن برای ابطال مانند CRLite نگاه می کنیم، اغلب در آموزش روی این موضوع تمرکز می کنیم، که در مرورگرهای دسکتاپ معجزه می کند، اما برای هیچ کلاینت TLS دیگری کاری انجام نمی دهد. در نظر بگیرید که چه چیزی نیاز به به روز رسانی فروشگاه ریشه آن دارد، و این فقط نوک کوه یخ است:

من این را روی ماشین‌های خودم با استفاده از یک سرور محلی و گواهی برای api.stripe.com آزمایش کردم، نامی که احتمالا همه می‌توانیم با آن موافق باشیم ارزش بسیار بالایی دارد. با تنظیمات پیش‌فرض، curl گفت گواهی SSL تایید می‌شود، پایتون دست دادن را تکمیل کرد و Node گفت مجاز: true. این در هر دستگاه لینوکس و macOS که من آزمایش کردم صادق بود. در ویندوز، CryptoAPI زنجیره را می پذیرفت مگر اینکه بررسی ابطال روشن شود، و حتی پس از آن فقط یکی از دو مسیر به عنوان باطل بازگشت.

شما می توانید هر نام میزبان دیگری را که می خواهید در آن گواهی قرار دهید و همه چیزهایی را که برای رهگیری ترافیک آن دستگاه نیاز دارید در اختیار دارید، تنها کاری که باید انجام دهید این است که در مسیر شبکه قرار بگیرید.

خوشبختانه مراحل مورد نیاز در اینجا برای دستگاه‌هایی که می‌توانید به‌روزرسانی کنید پیچیده نیست و توصیه‌ها اساسا به «به‌روزرسانی آنها» خلاصه می‌شود. مشکل دستگاه هایی است که نمی توانید به راحتی آپدیت یا به روز کنید.

هشت بیت برای 17 ماه تمام، این تنها چیزی است که بین حجم عظیمی از نرم افزارهای غیر مرورگر و گواهی جعلی برای هر سایتی که امنیت تمام ترافیک رمزگذاری شده شما را تحت تأثیر قرار می دهد، بود.

موضوع MDSP: https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE/m/Kp1v6CPuAAAJ

اطلاعیه تحقیق: https://emudhra.we-have-a-problem.com/

به روز رسانی 20 اکتبر 2026 ساعت 20:16 UTC مدت کوتاهی پس از انتشار، موزیلا بلیط حادثه خود را عمومی کرد: https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

eMudhra گزارش خود را از آنچه در آن بلیط رخ داده است، ارائه کرده است. به نظر می رسد اشکالی در اسکریپت مورد استفاده در مراسم وجود داشته است، یک جفت کلید ضعیف دوم در HSM ایجاد شده است و داشتن نام های مشابه یک خطای انسانی منجر به استفاده از کلیدهای اشتباه برای CSR می شود. هیچ چیزی در متن مقاله من در بالا در نتیجه این اطلاعات جدید تغییر نکرده است. همچنین می‌توانم تأیید کنم که یک دستور ساده در یک عامل هوش مصنوعی به من اجازه می‌دهد کلیدهای خصوصی CA را بازیابی کنم. کلود توانست کلیدهای خصوصی را با یک اعلان بازیابی کند.