برای هفته تولد (Birthday Week)، شرکت کلادفلر (Cloudflare) به یکی از پروتکلهای امنیتی اصلی اینترنت کمک میکند تا حفاظتهای قویتری در برابر حملات تنزل رتبه کوانتومی توسعه دهد. برای محافظت از مشتریان خود و کل اینترنت، ما با کارگروه مهندسی اینترنت (IETF) همکاری کردیم تا یک راهکار کاهش خطرات برای حملات تنزل رتبه روی IPsec توسعه دهیم که آن را پیادهسازی کرده و به صورت بتا در محصولات IPsec خود در دسترس قرار دادهایم.
جهان در حال مسابقه برای ساخت نسل اول رایانههای کوانتومی است. این ماشینهای جدید نویدبخش بزرگی هستند، اما یک تهدید جدید نیز ایجاد میکنند: رایانههای کوانتومی اولیه قادر خواهند بود رمزنگاریهایی را که برای ارتباط امن به آنها متکی بودهایم، بشکنند. برای حل این مشکل، مهاجرت به رمزنگاری پساکوانتومی (PQ) ضروری است: رمزنگاریای که معتقدیم حتی رایانههای کوانتومی نیز نمیتوانند آن را بشکنند. توافق کلید دیفی-هلمن باید با مکانیسمهای توافق کلید PQ مانند ML-KEM جایگزین شود؛ طرحهای امضای کلاسیک مانند ECDSA و RSA باید با طرحهای PQ مانند ML-DSA جایگزین شوند و غیره.
مهاجرت به PQ به خوبی در جریان است و ما با تبدیل رمزنگاری پساکوانتومی به حالت پیشفرض در محصولات خود، متنباز کردن بخشی از ابزار کشف رمزنگاری داخلی خود، راهاندازی ویژگیهای جدید دیدهبانی پساکوانتومی و پیشتاز بودن در مهاجرت وب به گواهیهای پساکوانتومی، به این مهاجرت کمک میکنیم. با این حال، سالها طول خواهد کشید تا تمام کلاینتها و سرورها در اینترنت به رمزنگاری پساکوانتومی ارتقا یابند. در این میان، لازم است دستگاههای مدرن برای اتصال با نقاط پایانی امروزی، پشتیبانی از رمزنگاری کلاسیک را حفظ کنند.
نیاز به سازگاری با گذشته خطرات خاص خود را ایجاد میکند. در یک حمله تنزل رتبه (downgrade attack)، یک مهاجم در مسیر (on-path) بین کلاینت و سرور، نقاط پایانی را فریب میدهد تا از رمزنگاری ضعیفتری نسبت به آنچه پشتیبانی میکنند، استفاده کنند. این کار با دستکاری پیامهای ارسال شده بین کلاینت و سرور انجام میشود و به گونهای وانمود میکند که طرف مقابل اصلاً از PQ پشتیبانی نمیکند. به عبارت دیگر، یک حمله تنزل رتبه با تنزل دادن قربانیان به سیستم کلاسیک، حفاظت ارائهشده توسط رمزنگاری PQ را از بین میبرد تا بتواند مورد حمله یک رایانه کوانتومی قرار گیرد.
این بدان معناست که صرفاً افزودن پشتیبانی از پایههای رمزنگاری برای دفع تهدید کوانتومی کافی نیست. مرز بعدی در مهاجرت PQ جلوگیری از دور زدن PQ توسط مهاجمان فعال با تنزل دادن اتصال است.
در این مقاله، ما بر روی پروتکل IPsec تمرکز میکنیم که جزء مرکزی انواعی از محصولات کلادفلر (Cloudflare) یعنی IPsec کلادفلر، شبکه گسترده کلادفلر (Cloudflare WAN) و مجیک ترانزیت (Magic Transit) است. مانند تمام پروتکلهای کانال امن، از جمله TLS، پروتکل IPsec تا زمانی که هر دو احراز هویت کلاسیک و پساکوانتومی پشتیبانی میشوند، در برابر حمله تنزل رتبه ساده زیر آسیبپذیر است. یک مهاجم میتواند با شکستن اعتبارنامههای کلاسیک یک طرف، خود را به جای او جا بزند و وانمود کند که آن طرف از PQ پشتیبانی نمیکند. با این حال، چند ماه پیش، ما یک نقص طراحی در IPsec را کشف کردیم که اجازه میدهد یک حمله پیچیدهتر بدون توجه به اینکه از چه روش احراز هویتی استفاده میشود، کار کند.
این آسیبپذیری به یک مهاجم کوانتومی اجازه میدهد تمام ترافیک بین نقاط پایانی دارای قابلیت PQ را رمزگشایی کند. انجام این حمله نسبتاً دشوار است، زیرا مستلزم انجام یک محاسبات کوانتومی در زمان واقعی طی دستدهی (handshake) پروتکل است. (این با حمله ذخیره اکنون، رمزگشایی در آینده (harvest-now, decrypt-later) که در آن محاسبات کوانتومی کاملاً آفلاین است، متفاوت است.) ما هنوز نمیدانیم که آیا و چه زمانی این حمله عملی خواهد شد، اما روندهای اخیر به ما دلیلی کافی برای احتیاط میدهد: در زمان نگارش این مقاله، برآوردهای منابع برای حملات کوانتومی بر روی رمزنگاری کلید عمومی به شدت کاهش یافته است و باعث شده است کلادفلر (Cloudflare) مهلت انتقال خود را به سال 2029 جلو بکشد.
برای مصونسازی IPsec در برابر این تهدید، ما به IETF کمک کردیم تا یک افزونه توسعه دهد که یک مکانیسم حفاظت در برابر تنزل رتبه را به IPsec اضافه میکند. هر دو طرف باید از این افزونه پشتیبانی کنند تا مؤثر واقع شود: به نوبه خود، کلادفلر (Cloudflare) پشتیبانی بتا را در Cloudflare WAN و Magic Transit عرضه کرده است که مشتریان اکنون میتوانند با درخواست از مدیران حساب خود برای روشن کردن پرچم ipsec_downgrade_protection برای حسابهایشان، آن را فعال کنند. ما امیدواریم که بقیه اکوسیستم IPsec نیز به زودی همین رویه را دنبال کنند.
جایگاه IPsec در اینترنت
خوانندگان همیشگی وبلاگ کلادفلر (Cloudflare) احتمالاً از قبل با پروتکلهای TLS و QUIC آشنا هستند. در میان آنها، TLS/QUIC عملاً تمام ترافیک وب در حال گذر در اینترنت امروز را ایمن میکنند. هر دو در لایه انتقال پشته شبکه عمل میکنند: TLS روی TCP اجرا میشود، در حالی که QUIC روی پروتکل دیتاگرام کاربر (UDP) اجرا میشود.
پروتکل IPsec عملکرد مشابهی دارد، اما در لایه IP عمل میکند. از آنجا که IPsec در لایهای حتی پایینتر از پشته شبکه نسبت به TLS و QUIC عمل میکند، عمیقاً در زیرساخت شبکه مدرن ریشه دوانده است. IPsec کلادفلر به سازمانها اجازه میدهد اتصالات IPsec خود را بدون نیاز به اتصالات گرانقیمت سویچینگ برچسب چندپروتکلی (MPLS) روی شبکه انیکست جهانی کلادفلر (Cloudflare) گسترش دهند. IPsec همچنین بخشی از محصول Magic Transit شرکت کلادفلر (Cloudflare) است. با Magic Transit، شبکه انیکست جهانی کلادفلر (Cloudflare) در جلوی محدوده IP یک سازمان قرار میگیرد تا آن را در برابر حملات و تهدیداتی مانند حملات انکار خدمت توزیعشده (DDoS) محافظت کند و سپس ترافیک پاکسازی شده را از طریق تونلهای IPsec به سازمان تحویل دهد.
با وجود اینکه پروتکل IPsec عمیقاً در زیرساخت اینترنت امروز ریشه دوانده است، اما همچنان به تکامل خود ادامه میدهد. این پروتکل در چندین سال گذشته ارتقاهای مهم بسیاری را تجربه کرده است، از جمله افزودن توافق کلید پساکوانتومی (PQ). IPsec همچنین در مسیری قرار دارد که احراز هویت PQ را در همان بازه زمانی مشابه TLS/QUIC بپذیرد. (در واقع، بسته به نحوه پیکربندی، IPsec در واقع جلوتر است. یک کلید از پیش به اشتراک گذاشته شده اغلب برای احراز هویت در IPsec استفاده میشود و این مورد هماکنون کاملاً پساکوانتومی است!) این نشان میدهد که اکوسیستم IPsec بیش از حد توانایی سازگاری با تهدیدات در حال تغییر را دارد.
زمینهای درباره IPsec
بیایید نگاهی به جزئیات پروتکل که مربوط به حمله تنزل رتبه است بیندازیم. اصطلاح «IPsec» به مکانیسم مورد استفاده برای رمزگذاری بستههای IP اشاره دارد. قبل از اینکه رمزگذاری آغاز شود، نقاط پایانی ابتدا باید یک توافق کلید احراز هویت شده را انجام دهند. آنها این کار را با استفاده از پروتکل IKEv2 انجام میدهند.
پروتکل IKEv2 معمولاً دو فاز دارد که به آنها مبادله (exchange) گفته میشود. در مبادله اولیه، آغازگر (initiator) پارامترهایی را که پشتیبانی میکند اعلام کرده و یک سهم کلید دیفی-هلمن ارسال میکند. پاسخدهنده (responder) مبادله اولیه را با اعلام پارامترهایی که انتخاب کرده و ارسال سهم کلید خود تکمیل میکند.
پس از مبادله اولیه، آغازگر و پاسخدهنده یک کلید رمزگذاری را از سهم کلیدها مشتق میکنند و تمام مبادلات بعدی را رمزگذاری میکنند. سهم کلیدها هنوز احراز هویت نشدهاند، به این معنی که هر نقطه پایانی هیچ راهی برای دانستن اینکه سهم کلید از کجا آمده است ندارد. این کار در مبادله احراز هویت انجام میشود که در آن آغازگر خود را به همتای خود معرفی میکند و امضایی از سهم کلید و پارامترهای اعلامشده خود را ارسال میکند. پاسخدهنده از هویت برای حل اعتبارنامههای آغازگر استفاده میکند و قبل از پذیرش اتصال جدید، امضا را تأیید میکند. پاسخدهنده همین کار را در پیام احراز هویتی که در پاسخ ارسال میکند انجام میدهد.
یک جزئیات مهم برای اشاره در اینجا: هر طرف فقط پیامهای خروجی خود را امضا میکند، نه کل رونوشت دستدهی را، برخلاف پروتکلهای مدرنتر مانند TLS 1.3. این بدان معناست که طرف احراز هویتشونده هرگز به طرف متکی تأیید نمیکند که آنها همان دنباله پیامها را مشاهده کردهاند. این برای حمله بسیار مهم خواهد بود.
رمزگذاری پیامهای دستدهی دو هدف دارد. اول اینکه هویت نقاط پایانی را از شبکه پنهان میکند. (پروتکلهای TLS/QUIC به طور پیشفرض این ویژگی را ندارند، اما میتوانند با استفاده از افزونه Encrypted Client Hello آن را فعال کنند.) دوم اینکه به نقاط پایانی اجازه میدهد مکانیسم قطعهبندی بسته IPsec را شروع کنند و انتقال پیامهای طولانی را روی چندین بسته قابل اعتمادتر سازند. (این به ویژه برای مدیریت پیامهای بزرگ مبادله کلید ML-KEM مرتبط است.)
این پروتکل به مبادله کلید کلاسیک دیفی-هلمن متکی است، به این معنی که یک مهاجم کوانتومی در نهایت قادر خواهد بود کلید رمزگذاری را از سهم کلیدهای مبادله شده مشتق کند. برای کاهش این تهدید، IKEv2 شامل گزینهای برای اجرای یک مبادله میانی (intermediate exchange) پس از مبادله اولیه با استفاده از ML-KEM به عنوان الگوریتم مبادله کلید است.
سازگاری با گذشته. نکته مهم این است که این مبادله تنها در صورتی انجام میشود که آغازگر در مبادله اولیه پشتیبانی از آن را اعلام کند و پاسخدهنده با استفاده از آن موافقت کند. این امر امکان سازگاری با گذشته را با نقاط پایانی که هنوز از PQ پشتیبانی نمیکنند فراهم میکند. به ویژه، اگر پاسخدهنده یک توافق کلید فقط-کلاسیک را انتخاب کند، آغازگر فرض خواهد کرد که پاسخدهنده از PQ پشتیبانی نمیکند و به حالت فقط-کلاسیک بازمیگردد. به همین ترتیب، اگر آغازگر پشتیبانی از توافق کلید PQ را اعلام نکند، پاسخدهنده فرض خواهد کرد که آغازگر از آن پشتیبانی نمیکند.
سلام، نام من مالوری است
بیایید به این فکر کنیم که چگونه از این رفتار مذاکره پارامتر بهرهبرداری کنیم. ما با یک ایده ساده که کاملاً کار نمیکند شروع میکنیم و میبینیم چه چیزی برای کار کردن آن لازم است.
فرض کنید یک مهاجم بین نقاط پایانی وجود دارد - بیایید او را مالوری (Mallory) بنامیم - که یک رایانه کوانتومی دارد. مالوری میتواند با رهگیری پیام مبادله کلید اولیه آغازگر، بازنویسی آن برای اعلام حالت فقط-کلاسیک و ارسال پیام تغییریافته به پاسخدهنده، به گونهای وانمود کند که آغازگر از PQ پشتیبانی نمیکند.
این امر باعث میشود که مبادله احراز هویت با شکست مواجه شود. آغازگر پیامی را که ارسال کرده است امضا میکند، اما پاسخدهنده پیامی را که دریافت کرده است تأیید میکند. از آنجا که پیام دریافتی با پیام ارسالی متفاوت است، تأیید امضا با شکست مواجه میشود، مگر اینکه مهاجم همچنین موفق شود امضایی را جعل کند که پاسخدهنده آن را بپذیرد.
با این حال، این تمام ماماجرا نیست: در IKEv2، پیامهای احراز هویت رمزگذاری شدهاند، به این معنی که مالوری همچنین باید کلید رمزگذاری را محاسبه کند. اما این دقیقاً همان چیزی است که حمله تنزل رتبه امکانپذیر میسازد: مالوری قبلاً نقاط پایانی را متقاعد کرده است که به حالت فقط-کلاسیک بازگردند و آنها میتوانند از رایانه کوانتومی خود برای بازیابی کلید رمزگذاری از سهم کلیدهای دیفی-هلمن استفاده کنند.
با این حال، هیچ راه آشکاری برای جعل امضا از آغازگر صادق وجود ندارد، مگر اینکه مالوری کلید احراز هویت آغازگر را به خطر انداخته باشد. مقالهای از سال 2016 نشان میدهد که: از آنجا که پاسخدهنده فقط پیامهای خروجی خود را امضا میکند، در واقع به همتای خود تأیید نمیکند که چه هویت آغازگری را پذیرفته است. این بدان معناست که پاسخدهنده یک پیام احراز هویت را از هر آغازگری که به آن اعتماد دارد میپذیرد، نه فقط آغازگر اتصال.
فرض کنید خود مالوری یک آغازگر است که پاسخدهنده اعتبارنامههای او را میپذیرد. در این صورت، مالوری میتواند با استفاده از اعتبارنامههای خودش یک امضای معتبر تولید کند. پاسخدهنده اتصال را کامل میکند و معتقد است که با مالوری صحبت میکند که با IDm در شکل زیر مشخص شده است. در همین حال، آغازگر (IDi) اتصال را کامل میکند و معتقد است که با پاسخدهنده (IDr) صحبت میکند.
این نوعی حمله ناسازگاری هویت (identity-misbinding) است: هر دو نقطه پایانی یک کلید رمزگذاری شناختهشده برای مهاجم را پذیرفتهاند، اما یک نقطه پایانی هویت موجودیت اشتباهی را احراز هویت کرده است.
انواع بیشتری از این حمله امکانپذیر است. به عنوان مثال، در یک حمله جعل وانمودسازی به خطر افتادن کلید (key-compromise impersonation)، مالوری به سادگی اعتبارنامههای آغازگر را میدزدد و مستقیماً به جای آغازگر وانمود میکند و به آنها اجازه میدهد تا زمانی که پاسخدهنده اعتبارنامههای مسروقه را لغو کند، استراق سمع کنند؛ این نوع حمله نیازی به ناسازگاری هویت ندارد. این حملات همچنین مختص PQ نیستند: مالوری میتواند نقاط پایانی را مجبور کند از ضعیفترین روش توافق کلید که هر دو از آن پشتیبانی میکنند استفاده کنند.
آیا این حمله واقعاً مهم است؟
دشواری اصلی در نوع کوانتومی این حمله این است که محاسبات کوانتومی آنلاین است، به این معنی که باید در طول حمله قبل از تکمیل دستدهی انجام شود. این در تضاد با سایر تهدیدات کوانتومی علیه اینترنت است که در آن محاسبات آفلاین است (حملات ذخیره اکنون، رمزگشایی در آینده، شکستن گواهی TLS و غیره). این امر به ما کمی تنفس میدهد: حملات تنزل رتبه بعید است اولین هدف رایانههای کوانتومی مرتبط با رمزنگاری باشند، با توجه به اینکه میوههای بسیار بسیار آسانتری برای چیدن وجود دارد.
از طرف دیگر، احتمال غیرقابل انکاری وجود دارد که روز Q (Q-day) قبل از اینکه فرصتی برای غیرفعال کردن حالت فقط-کلاسیک در سراسر اکوسیستم IPsec داشته باشیم، فرا برسد. ما هنوز دقیقاً نمیدانیم چقدر طول میکشد تا یک توافق کلید دیفی-هلمن شکسته شود، اما حدس امن این است که قابلیتهای رایانههای کوانتومی پس از ورود به سرعت افزایش خواهد یافت. بهتر است در حالی که در میان سایر ارتقاهای PQ برای IPsec هستیم، از تهدید جلوتر باشیم، به ویژه با توجه به اینکه چقدر طول میکشد تا این ارتقاها در سراسر اکوسیستم مستقر شوند.
حفاظت از IPsec
سادهترین راه برای کاهش این حمله، غیرفعال کردن توافق کلید فقط-کلاسیک است (یعنی پیکربندیهای IKEv2 با یک مبادله اولیه دیفی-هلمن اما بدون مبادله کلید PQ پس از آن). با این حال، گفتن این کار آسانتر از انجام آن است: دلیل وجود مذاکره پارامتر در TLS و IPsec این است که آغازگر همیشه قابلیتهای پاسخدهنده را قبل از تلاش برای اتصال نمیداند (و بالعکس).
در برخی موارد، مکانیسمی1 شبیه به HSTS امکانپذیر است. با HSTS (امنیت حمل و نقل سختگیرانه HTTP)، یک کلاینت به خاطر میسپارد که کدام یک از همتاها و سرورهایش در یک اتصال قبلی از PQ پشتیبانی کردهاند و سپس حالت فقط-کلاسیک را در تمام اتصالات آینده به آن همتاها رد میکند. این کار تا زمانی که بدانید چه کسی سعی در اتصال دارد کار میکند، یعنی زمانی که همتای شما خود را معرفی میکند. اما در IKEv2، مذاکره در مبادله اولیه اتفاق میافتد؛ همتا خود را تا مبادله احراز هویت معرفی نمیکند، تا آن زمان خیلی دیر شده است.
در هر صورت، این راهحل در حل مشکل اساسی ناکام است. به یاد داشته باشید که هر نقطه پایانی فقط پیامهای خروجی خود را امضا میکند و پیامهای ارسال شده توسط همتای خود را امضا نمیکند. این به مهاجم اجازه میدهد یک «نمای تقسیمشده» (split view) از اجرای پروتکل ایجاد کند: آغازگر یک دنباله از پیامها را میبیند و پاسخدهنده دنباله دیگری را میبیند. اگر آغازگر و پاسخدهنده تأیید میکردند که یک مکالمه منطبق دارند، حملات تنزل رتبه غیرممکن بود. در پروتکلهای دستدهی مدرن مانند TLS 1.3، هر طرف احراز هویتشونده کل رونوشت دستدهی، از جمله پیامهایی را که از طرف متکی دریافت کرده است، امضا میکند. این به طرف متکی اجازه میدهد تأیید کند که همان مکالمه را داشته است و در نتیجه از نمای تقسیمشده سوءاستفاده شده توسط حمله تنزل رتبه جلوگیری میکند. ما این رویکرد اصولیتر را ترجیح میدهیم.
معرفی افزونه احراز هویت کامل رونوشت IKEv2
ما با کارگروه نگهداری IPsec (IPSECME) در IETF همکاری کردیم تا یک افزونه برای IKEv2 (که به زودی به یک RFC تبدیل خواهد شد!) به نام IKE_SA_INIT_FULL_TRANSCRIPT_AUTH توسعه دهیم که پروتکل را با احراز هویت کامل رونوشت مجهز میکند. برای سازگاری با گذشته، استفاده از این افزونه درست مانند هر ویژگی دیگری مذاکره میشود. این بدان معناست که خود افزونه در معرض حمله تنزل رتبه است، اما افزونه از یک ترفند هوشمندانه برای جلوگیری از این امر استفاده میکند.
این افزونه بسیار ساده است:
- پشتیبانی از افزونه با یک پیام اطلاعرسانی (notify) ارسال شده در مبادله کلید اولیه اعلام میشود. این اطلاعرسانی به صورت بیشرط ارسال میشود: آغازگر همیشه اطلاعرسانی میکند؛ و پاسخدهنده اطلاعرسانی میکند حتی اگر آغازگر این کار را نکرده باشد. این با افزونههای TLS 1.3 متفاوت است، جایی که سرور فقط در صورت درخواست کلاینت قرار است به یک افزونه پاسخ دهد.
- اگر همتا پشتیبانی از افزونه را اطلاعرسانی کند، یک نقطه پایانی IKEv2 منطق احراز هویت بهروزرسانیشده را انتخاب میکند. به ویژه، به جای امضای فقط پیامهای خروجی خود، کل رونوشت را امضا میکند. به همین ترتیب، انتظار دارد همتایش کل رونوشت را امضا کند.
ترفندی که از تنزل رتبه جلوگیری میکند، اطلاعرسانی بیشرط است. فرض کنید مالوری مبادله اولیه را با حذف اطلاعرسانی IKE_SA_INIT_FULL_TRANSCRIPT_AUTH از پیام آغازگر تغییر دهد، اما اجازه دهد اطلاعرسانی پاسخدهنده عبور کند. در این مورد، پاسخدهنده به منطق احراز هویت قدیمی بازمیگردد، اما آغازگر منطق جدید را انتخاب میکند. پاسخدهنده در نهایت توالی بایت متفاوتی را نسبت به آنچه آغازگر تأیید میکند امضا خواهد کرد و باعث میشود مبادله احراز هویت با شکست مواجه شود و منجر به یک اطلاعرسانی AUTHENTICATION_FAILURE شود. اگر مالوری اطلاعرسانی پاسخدهنده را حذف کند اما اجازه دهد اطلاعرسانی آغازگر عبور کند، اتفاق مشابهی رخ میدهد.
اکنون در نظر بگیرید اگر مالوری اطلاعرسانی را از هر دو پیام حذف کند چه اتفاقی میافتد. این امر باعث میشود هر دو طرف به منطق احراز هویت قدیمی بازگردند و به مالوری اجازه دهد اتصال را تنزل دهد و کلید رمزگذاری را محاسبه کند. اما برای انجام این حمله، مالوری نیاز دارد که نه تنها از آغازگر، بلکه از پاسخدهنده نیز یک امضا جعل کند.
هنگام تلاش برای ناسازگاری هویت، مالوری باید یک هویت برای یک پاسخدهنده متفاوت از آنچه آغازگر میخواست به آن متصل شود ارائه دهد. اینریال مانند این است که آغازگر سعی کرده به example.com متصل شود، اما گواهی برای cloudflare.com دریافت کرده است. مگر اینکه آغازگر به شدت اشتباه پیکربندی شده باشد، این اتفاق نمیافتد.
منبع: blog.cloudflare.com