وقتی آدرسی را در مرورگر وارد میکنید، از کجا میدانید که در حال اتصال به وبسایت درستی هستید؟ زیرساخت کلید عمومی وب (Web PKI) یک اکوسیستم پیچیده و توزیعشده از سیاستها، پروتکلها و اپراتورهای زیرساختی است که کمک میکند اعتماد کنید به یک وبسایت نادرست یا مخرب هدایت نمیشوید. در چند دهه گذشته، این اکوسیستم دستخوش تغییرات چشمگیری شده است. یکی از آنها اضافه شدن شفافیت است: الزامی که اکنون اجباری شده و بر اساس آن تمامی گواهیها باید در گزارشهای عمومی شفافیت گواهی ثبت شوند. اکنون این اکوسیستم با چالش دیگری روبرو است: ظهور قریبالوقوع یک رایانه کوانتومی که ما را ترغیب کرده است تا تا سال ۲۰۲۹ به رمزنگاری پساکوانتمی (PQ) ارتقا پیدا کنیم.
این گذار ساده نیست: جایگزین کردن ساده رمزنگاری پساکوانتمی در گواهیها در مقیاس اینترنت منجر به افت عملکرد غیرقابل قبولی خواهد شد. این لحظه نیازمند رویکرد جدیدی به زیرساخت کلید عمومی وب (Web PKI) است، رویکردی که به ما اجازه میدهد شفافیت را به عنوان یک ویژگی درجه یک به جای یک قابلیت الحاقی در نظر بگیریم و سیستم جدیدی را طراحی کنیم که امضاهای پساکوانتمی را به طور کارآمد مقیاسبندی کند.
پس از به دست آوردن حمایت گسترده در سراسر صنعت، گواهیهای درخت مرکل (Merkle Tree Certificates) یا همان MTCها به عنوان مسیر رو به جلو ظهور کردهاند. امسال، پس از یک استقرار آزمایشی موفق با کروم (Chrome)، شرکت کلودفلر (Cloudflare) با تمام توان به سمت استفاده از MTCها حرکت میکند.
به دنبال اعلام امروز مبنی بر اینکه کلودفلر در حال تبدیل شدن به یک مرجع صادرکننده گواهی (CA) است، بسیار هیجانزده هستیم که اعلام کنیم این CA از صدور MTC پشتیبانی خواهد کرد و هدفگذاری آن برای اوایل سال ۲۰۲۷ جهت قرار گرفتن در فروشگاه ریشه مقاوم در برابر کوانتوم (Quantum-resistant Root Store) تازه راهاندازی شده کروم است. به عنوان بخشی از ماموریت خود برای کمک به ساخت یک اینترنت بهتر، و به دنبال سنت کلودفلر در ارائه قویترین رمزنگاری موجود به صورت رایگان، ما صدور استاندارد MTC را بدون هیچ هزینهای ارائه خواهیم داد. داشتن یک CA که از صدور گواهی کلاسیک و MTC پشتیبانی میکند به ما اجازه میدهد به طور پیشفرض از امنترین روش احراز هویت موجود استفاده کنیم و یک مسیر ارتقای پساکوانتمی بدون دردسر و با کارایی بالا را برای بخش بزرگی از اینترنت فراهم نماییم.
اکوسیستم اعتماد فعلی
برای درک اینکه چگونه MTCها بازی را تغییر میدهند، بیایید با مقداری پیشزمینه در مورد نحوه کارکرد اعتماد در وب امروز شروع کنیم.
در سمت کلاینت، مرورگرها — در اینجا «کلاینتهای TLS» — برنامههای ریشهای را نگهداری میکنند که مجموعهای از سیاستها را مشخص میکند که CAها برای مورد اعتماد بودن باید از آنها پیروی کنند. در سمت سرور، CAها دروازهبانهای مورد اعتمادی هستند: آنها زیرساخت صدور گواهی را اداره میکنند که در آن مالکیت دامنه را تایید کرده و گواهی بر اتصال یک نام دامنه و یک کلید عمومی که نشاندهنده مالکیت آن دامنه است، ارائه میدهند.
اما چگونه بررسی کنیم که CAها از قوانین پیروی میکنند؟ اینجاست که شفافیت گواهی (CT) وارد میشود که صدور گواهی را به صورت عمومی قابل حسابرسی میکند. هنگامی که یک CA یک گواهی صادر میکند، همچنین باید آن گواهی را به حداقل دو گزارش عمومی ارسال کند. کلودفلر خانواده گزارشهای CT به نام نیمبوس (Nimbus) را از سال ۲۰۱۶ اداره کرده است و در حال راهاندازی Raio، یک خانواده جدید از گزارشهای ایستا CT (static CT logs) برای آینده است.
در حالی که اکوسیستم CT گواهیها را به صورت عمومی قابل مشاهده میکند، به این معنا نیست که آنها به درستی صادر شدهاند یا برای استفاده امن هستند. نظارت با مقایسه آن سوابق گزارش با آنچه مالکان دامنه انتظار داشتند و گزارش فعالیت مشکوک به این امر کمک میکند. کلودفلر نظارت بر شفافیت گواهی (Certificate Transparency Monitoring) را در سال ۲۰۱۹ راهاندازی کرد و اخیراً آن را به صورت عمومی در دسترس (generally available) قرار داد. ما همچنین اندازهگیریهای در مقیاس بزرگ را در مورد گواهیها در صفحه شفافیت گواهی (Certificate Transparency) در Radar (که قبلاً با نام Merkle Town شناخته میشد) منتشر میکنیم.
همانطور که سازمانها شروع به ارتقای سرورهای خود برای استفاده از احراز هویت پساکوانتمی میکنند، نظارت بر شفافیت گواهی نقش بسیار مهم تری در تشخیص نزولهای احتمالی پساکوانتمی ایفا خواهد کرد. مالکان دامنهای که دامنههای خود را به احراز هویت پساکوانتمی ارتقا دادهاند، باید گزارشهای CT را برای گواهیهای قدیمی صادر شده غیرمنتظره زیر نظر داشته باشند تا از سقوط کلاینتها به یک مسیر نزول مخرب جلوگیری کنند.
بخشی از مشکل این سیستم فعلی این است که شفافیت یک قابلیت الحاقی بود، که باعث شد با مسائل مقیاسپذیری مواجه شود. گواهیها به دفعات مکرر، در اشکال مختلف، در سراسر گزارشهای متعدد ثبت میشوند و مانیتورها را ملزم میکنند که برای از دست ندادن هیچ صدوری، هر گزارش را دانلود و پردازش کنند. این کار میتواند پرهزینه باشد — و ترغیب مجموعه متنوعی از اپراتورهای گزارش در مقیاس اینترنت را دشوار کند. بر اساس تخمینهای ما، امضاهای پساکوانتمی حجم دادههایی را که گزارشهای CT باید ذخیره کنند تا ۴۰ برابر افزایش میدهد. این چالش مقیاسپذیری و عدم تناسب انگیزههای بعدی، در هسته مشکل مقیاسپذیری پساکوانتمی قرار دارد.
چالش مقیاسپذیری پساکوانتمی
ما به طور مفصل در مورد چالشهای مقیاسبندی رمزنگاری پساکوانتمی نوشتهایم، اما به طور خلاصه: برای پشتیبانی از احراز هویت سرور در مقیاس اینترنت، زیرساخت WebPKI باید تقریباً یک میلیارد سرور TLS را بدون پیشبارگذاری کلید عمومی هر سرور در هر کلاینت، احراز هویت کند. به طور سنتی، CAها این مشکل را با استفاده از زنجیرههای گواهی به عنوان مکانیسم توزیع اعتماد حل میکردند. اما با گذشت زمان، مواردی مانند بررسیهای ابطال کلید و شفافیت گواهی، کلیدها و امضاهای عمومی بیشتری را اضافه کردهاند — پنج امضا و دو کلید در یک دستدهی (handshake) معمولی TLS. امضاهای پساکوانتمی تقریباً ۴۰ برابر بزرگتر از امضاهای کلاسیک هستند و سربارهای بزرگتری ایجاد میکنند که مدیریت آنها در مقیاس وسیع برای کلاینتها، CAها، گزارشها و مانیتورها پرهزینه خواهد بود.
اینجاست که گواهیهای درخت مرکل (Merkle Tree Certificates) یا همان MTCها وارد میشوند؛ یک پیشنویس مشخصات از کارروه IETF PLANTS که یک معماری برای گواهیهای فشرده، کارآمد و پساکوانتمی را توصیف میکند. MTCها گواهیها را در یک درخت مرکل فقط-افزودنی دستهبندی میکنند و به یک CA اجازه میدهند ریشه آن درخت را به جای بسیاری از گواهیهای فردی امضا کند. این امر به مرورگرها یا سایر کلاینتها اجازه میدهد تا یک گواهی را با استفاده از یک اثبات گنجاندن فشرده — دنبالهای از هشهای رمزنگاری — در برابر یک سر درخت امضاشده به جای اعتبارسنجی تک تک گواهیها تأیید کنند. یک ایده کلیدی پشت MTCها این است: «آنچه را صادر میکنید ثبت نکنید، با ثبت کردن صادر کنید.» با جفت کردن صدور و ثبت، شفافیت به جای یک قابلیت الحاقی، به یک الزام برای عملیات تبدیل میشود.
نقش یک مرجع صادرکننده گواهی در یک PKI بازطراحیشده
ما در حال ساخت توانایی خود برای صدور MTCها به عنوان بخش جداییناپذیری از ایجاد یک CA کلودفلر هستیم. این بدان معناست که ردیابی الزامات جدید برنامه ریشه پساکوانتمی و نوشتن یک پشته نرمافزاری صدور و آینهسازی (mirroring) همزمان با ساخت تأسیسات، عملیات و توابع انطباق یک CA سنتی — کار کوچکی نیست!
نکته مثبت این است که ما این فرصت را داریم که الزامات و معماری این PKI جدید و پساکوانتمی را از روز اول اولویتبندی کنیم و راهاندازی خود را به گونهای بسازیم که با ارزشها و شبکه جهانی کلودفلر هماهنگ باشد — با هدف اینکه در آغاز این سفر جدید تا حد امکان شفاف باشیم.
بیایید نگاهی به معماری بهروز شده برای MTC بیندازیم:
اگر این را با اکوسیستم سنتی CA مقایسه کنید، متوجه خواهید شد که مسئولیتهای یک CA عمدتاً دستنخورده باقی میمانند: تایید کنترل یک دامنه، اتصال آن به یک کلید عمومی و صدور گواهیها. تفاوت اصلی این است که در اکوسیستم MTC، به جای امضای مستقیم گواهیها و سپس ثبت آنها، CA اکنون یک گزارش شفافیت پشتیبانیشده توسط یک درخت مرکل را نگهداری میکند که در آن اثبات گنجاندن مبنی بر اینکه گواهی واقعاً در درخت است به عنوان لنگر اعتماد عمل میکند. CAها همچنین همامضاکنندگان آینهای (Mirroring cosigners) را اداره خواهند کرد که یک نسخه از گزارشهای صدور را ذخیره میکنند، سازگاری فقط-افزودنی آنها را تایید کرده و شفافیت و در دسترس بودن این گزارشها را برای اکوسیستم گستردهتر تضمین میکنند.
صدور MTCها
MTCها در دو فرم ارائه میشوند که هر دو را میتوان در فرمت گواهی X.509 که نرمافزار کلاینت امروزه تشخیص میدهد، رمزگذاری کرد — فقط با یک الگوریتم امضای «متفاوت». در فرم مستقل (standalone)، مقدار امضای گواهی حاوی یک سر درخت همامضاشده از یک گزارش صدور و یک اثبات گنجاندن (دنبالهای از هشها) است که نشان میدهد گواهی در آن گزارش قرار دارد. اگر کلاینتها بتوانند سرهای درخت همامضاشده را به صورت خارج از باند (مثلاً از طریق مکانیزم بهروزرسانی مرورگر) به دست آورند، گواهی را میتوان به جای آن در فرم نسبی به نقطه عطف (landmark-relative) ارائه داد، که در آن مقدار امضا شامل اثبات گنجاندن سبکوزن بدون هیچگونه امضای سنگین پساکوانتمی است.
برای سادگی، بیایید نگاهی به نمونهای از صدور گواهی مستقل بیندازیم. هنگامی که یک وبسایت گواهی برای دامنه خود میخواهد، میتواند آن را از طریق پروتکل محیط مدیریت خودکار گواهی (ACME) که درخواستهای گواهی، اعتبارسنجی کنترل دامنه و جریانهای کاری صدور را مدیریت میکند، از یک CA درخواست کند. زیرساخت ACME کلودفلر انشعابی (fork) از بولدر (Boulder) خواهد بود، نرمافزار ACME به طور گسترده مستقر شده و به خوبی آزمایش شده که Let's Encrypt را نیرو میدهد. Let's Encrypt به طور فعال در حال توسعه پشتیبانی از MTC در Boulder است و ما قصد داریم انشعاب خود را حفظ کنیم که شامل این تغییرات بالادستی همراه با تغییرات خاص کلودفلر است و در صورتامکان به بالادست کمک میکند.
هنگامی که MTC CA درخواست صدور گواهی را دریافت میکند، سرور ACME آن CA بررسی میکند که آیا سرور در واقع دامنه را کنترل میکند یا خیر. اگر آن بررسیها با موفقیت انجام شوند، CA آن دادهها را سریالسازی کرده و به یک گزارش فقط-افزودنی اضافه میکند.
پس از افزودن ورودی MTC به گزارش صدور خود، CA حالت بهروز شده گزارش را محاسبه میکند و سپس یک نقطه بازرسی (checkpoint) را بر روی آن حالت امضا میکند. این نقطه بازرسی گواهی میدهد که CA هر ورودی موجود در درخت مرکل گزارش را تا آن نقطه زمانی صادر کرده است.
سپس CA وضعیت بهروز شده گزارش و نقطه بازرسی جدید خود را به یک همامضاکننده مورد اعتماد ارسال میکند که نسخه ای از گزارش صدور CA را به طور پایدار ذخیره میکند و بررسی میکند که هر حالت جدید فقط-افزودنی است، با درخت قبلی سازگار است و به درستی شکل گرفته است. این همامضای اضافی به کلاینتها و مانیتورها اطمینان میدهد که یک طرف مورد اعتماد دیگر همان وضعیت گزارش را مشاهده کرده و تایید کرده است که CA نماهای متفاوتی از صدور را به بخشهای مختلف اکوسیستم ارائه نمیدهد. همچنین تضمین میکند که گواهیهای صادر شده برای نظارت در دسترس خواهند بود، حتی اگر گزارش صدور CA در دسترس نباشد.
پیشنویس سیاست برنامه ریشه مقاوم در برابر کوانتوم کروم مستلزم حداقل دو همامضا است: یکی از یک همامضاکننده آینهای شناختهشده توسط کروم که توسط سازمان متمایزی اداره میشود، و دیگری از خود MTC CA صادرکننده. به همین ترتیب، ما آینهها را برای سایر CAهای آزمایشی اداره خواهیم کرد — و حداقل به یک همامضای مستقل روی گواهیهای صادر شده خود نیاز داریم.
کلودفلر همامضاکننده آینهای خود را در Azul، گزارش شفافیت متنباز مبتنی بر زبان Rust پیادهسازی خواهد کرد و برای حداکثر قابلیت همکاری، پروتکل آینه tlog سایت c2sp.org را پیادهسازی خواهد کرد.
در نهایت، پس از دریافت موفقیتآمیز یک همامضا از یک همامضاکننده آینهای، CA یک MTC با همامضاها، کلید عمومی سرور و یک اثبات گنجاندن میسازد. سپس آن MTC را به سرور ارسال میکند که میتواند از آن برای TLS در آینده استفاده کند!
ارائه کارآمد امضاهای پساکوانتمی: بهینهسازی نقطه عطف (landmark)
در حالی که گواهیهای مستقل کاربردی هستند، اما همچنان امضاهای پساکوانتمی بزرگی را روی دستدهی TLS ارسال میکنند و کارایی آنها را محدود میکنند. بهبودهای واقعی عملکرد ارائه شده توسط طراحی MTC، گواهیهای نسبی به نقطه عطف هستند.
به جای ارسال همامضاها در هر گواهی، CAها میتوانند دنبالهای از زیردرختها را که تمام گواهیهای فعال در گزارش را پوشش میدهند به عنوان یک نقطه عطف (landmark) تعیین کنند و آن زیردرختها را (به همراه دادههای برای احراز هویت آنها) از طریق یک سرویس بهروزرسانی خارج از باند بین کلاینتها توزیع کنند. در طول یک دستدهی TLS، احراز هویت واقعی به سرور با بررسی این موضوع توسط مرورگر انجام میشود که دادههای گواهی سرور — از جمله نام دامنه و کلید عمومی آن — در یک زیردرخت مورد اعتماد گزارش CA ظاهر میشود. اگر اثبات گنجاندن آن گواهی را به یک نقطه عطف همامضاشده متصل کند، و کلید عمومی سپس مالکیت را در طول دستدهی TLS اثبات کند، کلاینت میداند که در حال صحبت با سرور درستی است.
با انتقال دورهای این امضاها و فرادادههای درخت به کلاینتهای TLS به صورت خارج از باند، مجموعه کوچکی از امضاهای دستهای MTC میتواند به طور کارآمد میلیاردها گواهی صادر شده توسط یک CA مشخص را پوشش دهد. در حالی که نقاط عطف در مقیاس کارآمدتر هستند، اما نیاز به MTCهای مستقل را از بین نمیبرند — ممکن است کلاینتها تازه نصب شده باشند، آفلاین باشند، یا بهروزرسانی نقطه عطف مربوطه را نداشته باشند. به همین دلیل است که مهم است سرورها یک پشتیبان گواهی مستقل را حفظ کنند.
MTCها در عمل: نتایج آزمایش ما با کروم
امسال، ما آزمایشی را با کروم برای آزمایش امکانسنجی MTCها بین یک کلاینت و سرور اجرا کردیم. ما یک «Bootstrap CA» (یک CA جعلی که پایپلاین صدور را stub کرده بود) را اداره کردیم که MTCهای پشتیبانیشده توسط یک زنجیره گواهی سنتی را برای انتخابی از دامنههای کلودفلر در طرح «رایگان» کلودفلر صادر کرد و آنها را به ۵۰ درصد از کروم بتا ۱۴۶ ارائه داد. در طول آزمایش، ما با موفقیت میلیاردها MTC را ارائه دادیم.
برای TLS، متوجه شدیم که حالت رایج کاملاً کارآمد است: با یک گواهی نسبی به نقطه عطف، دستدهی فقط باید یک کلید عمومی، یک امضا و یک اثبات گنجاندن کمتر از 1kB را ارسال کند. در این آزمایش، در مواردی که قادر به مذاکره برای یک گواهی نسبی به نقطه عطف با کلاینت نبودیم، به جای ارائه یک گواهی مستقل، به زنجیره گواهی سنتی بازگشتیم. در سمت CT، MTCها همچنین ویژگیهای مقیاسپذیری شفافیت را تغییر میدهند: گزارش فقط باید هشهای کلیدهای عمومی را حمل کند؛ هیچ امضایی به ازای هر ورودی وجود ندارد و امضای روی سر درخت کل گزارش را پوشش میدهد. این از انفجار گواهی جلوگیری میکند زیرا گزارش صدور CA منبع حقیقت برای تمام گواهیهایی است که CA صادر میکند و مصرفکنندگان گزارش فقط باید یک کپی از هر گواهی را دریافت کنند.
نتیجه: MTCها واقعاً کار میکنند! در میانه (median)، استفاده از یک MTC با استفاده از MTCهای نقطه عطف ۹ درصد سریعتر از یک زنجیره امضای کلاسیک است (مسلماً، بیشتر این مزیت عملکردی به دلیل حذف واسطه است). و از آنجا که ما MTCها را با امضاهای کلاسیک آزمایش کردیم، انتظار بهبود حتی بیشتری را با امضاهای پساکوانتمی داریم. با رضایت از این نتایج، و با سطح همکاری بینصنعتی با MTCها در کارروه PLANTS در IETF، ماه گذشته (اوت ۲۰۲۶) شروع به پایان دادن به این آزمایش کردیم.
راه پیش رو برای MTCها
ما بسیار هیجانزده هستیم که آزمایش ما با کروم نشان داد که MTCها میتوانند در عمل کار کنند و به ویژه خوشحالیم که میتوانیم گواهیها را به عنوان یک CA واقعی صادر کنیم.
با این حال، هنوز پرسشهای گستردهتری وجود دارد که ما فقط میتوانیم با اجرای این آزمایش بزرگ با کل اکوسیستم PKI به آنها پاسخ دهیم. آیا مانیتورهای مستقل میتوانند گزارشهای صدور MTC را در حجم تولید مصرف و تأیید کنند؟ آیا چندین CA و همامضاکننده ظاهر خواهند شد تا سیستم تنوع لازم برای انعطافپذیری را داشته باشد؟ مرورگرها چگونه باید مزایای عملکردی MTCهای نقطه عطف فشرده را با مسیرهای پشتیبان مورد نیاز برای کلاینتهای بدون نقاط عطف تازه تعادل ببخشند؟ MTCها به عنوان طراحی معتبر برای احراز هویت پساکوانتمی ظاهر شدهاند، اما اثبات آن در مقیاس تولید اینترنت نیازمند مشارکت مجموعهای متنوع از برنامههای ریشه، فروشندگان مرورگر، CAها، آینهها، مانیتورها و جامعه وسیعتر خواهد بود.
ما فرصت مشارکت در این مرحله بعدی از Web PKI را یک افتخار میدانیم و مسئولیت اداره زیرساخت CA را جدی میگیریم. CAها جایگاه ممتازی در اکوسیستم اعتماد دارند — مرورگرها، مالکان دامنه و مردم عادی برای تایید صحیح هویتها، محافظت از کلیدهای امضا، پیروی از سیاست و عملکرد قابل اعتماد به آنها اعتماد میکنند. پیش از اینکه CA کلودفلر بتواند توسط مرورگرها برای صدور MTC مورد اعتماد قرار گیرد، باید برای فروشگاه ریشه مقاوم در برابر کوانتوم کروم درخواست دهیم و تحت یک فرایند ارزیابی دقیق قرار گیریم. ما از آن موشکافی استقبال میکنیم و انتظار داریم خود را با همان استاندارد بالایی که هر CA دیگری که برای کمک به ایمنسازی اینترنت مورد اعتماد است، نگه داریم. امیدواریم CAهای دیگری برای پشتیبانی از پذیرش MTC ظاهر شوند و مشتاقانه منتظر همکاری با هر مرورگری هستیم که میخواهد MTCها را مستقر کند.
منبع: blog.cloudflare.com