رمزنگاری پساکوانتومی در راه است؛ سازمان شما پیش از ۲۰۳۰ چه اقداماتی باید انجام دهد؟
در اوت ۲۰۲۴، NIST اولین استانداردهای نهایی رمزنگاری پساکوانتومی خود را منتشر کرد: ML-KEM (FIPS 203)، ML-DSA (FIPS 204)، SLH-DSA (FIPS 205) و FN-DSA (FIPS 206). این خبر به طور گسترده پوشش داده شد. واکنش بیشتر سازمانها این بود که آن را به نقشه راه امنیتی آینده اضافه کرده و به سراغ اولویتهای فوریتر بروند.
این تصمیم اشتباه است و دلیل آن به تهدیدی برمیگردد که منتظر تکمیل مهاجرت نمیماند. درک خطر واقعی و گامهای مشخص برای مقابله با آن، چیزی است که سازمانهایی را که این انتقال را به خوبی مدیریت میکنند از آنهایی که در سال ۲۰۲۹ دستوپا خواهند زد، جدا میکند.
مدل تهدید: ذخیرهسازی اکنون، رمزگشایی بعد
استدلال معمول برای فوریت در زمینه رمزنگاری مقاوم در برابر کامپیوترهای کوانتومی این است: کامپیوترهای کوانتومی مرتبط با رمزنگاری هنوز وجود ندارند، پس چرا عجله کنیم؟ پاسخ حمله «ذخیرهسازی اکنون، رمزگشایی بعد» (HNDL) است و این حمله جدول زمانی توسعه کامپیوترهای کوانتومی را تا حد زیادی برای تصمیمگیریهای امروز مهاجرت بیربط میکند.
دشمنان دولتی و سازمانهای مجرم حرفهای امروز ترافیک رمزنگاری شده را ضبط میکنند – جلسات TLS، تونلهای VPN، انتقال فایلهای رمزنگاری شده – و آن را برای رمزگشایی پس از وجود کامپیوتر کوانتومی قادر به اجرای الگوریتم Shor در مقیاس بزرگ ذخیره میکنند. دادهای که امروز با RSA-2048 یا ECDSA P-256 رمزنگاری میشود شامل اطلاعات حساس بلندمدت است: سوابق پزشکی، تراکنشهای مالی، مالکیت فکری، ارتباطات طبقهبندی شده. اگر این داده باید برای ۱۰ تا ۲۰ سال محرمانه بماند، سؤال relevant این نیست که «کی کامپیوترهای کوانتومی RSA را میشکنند؟» بلکه «آیا کامپیوتر کوانتومی capable در پنجره محرمانگی دادهای که امروز رمزنگاری میکنم ممکن است؟»
بیشتر تخمینهای معتبر، کامپیوتر کوانتومی مرتبط با رمزنگاری (CRQC) را ۸ تا ۱۵ سال آینده میدانند. بدبینانهترین تخمینهای معتبر آن را ۵ تا ۷ سال میدانند. ذخیرهسازی اکنون در حال وقوع است. ساعت از لحظه ضبط داده شروع میشود، نه از لحظه روشن شدن کامپیوتر کوانتومی.
چهار استاندارد NIST و کاربرد آنها
ML-KEM (FIPS 203) – مبتنی بر الگوریتم CRYSTALS-Kyber – یک مکانیسم کپسولهسازی کلید است که برای جایگزینی RSA و ECDH در تبادل کلید طراحی شده است. این مهمترین استاندارد برای بیشتر سازمانها است: تبادل کلید TLS 1.3، راهاندازی جلسه VPN و پروتکلهای پیامرسانی امن همگی به مکانیسمهای تبادل کلیدی متکی هستند که ML-KEM جایگزین آنها میشود.
ML-DSA (FIPS 204) – مبتنی بر CRYSTALS-Dilithium – یک الگوریتم امضای دیجیتال است که جایگزین RSA و ECDSA برای امضا میشود. هر جا احراز هویت به امضاها متکی باشد relevant است: امضای کد، صدور گواهی، امضای اسناد، احراز هویت SSH.
SLH-DSA (FIPS 205) – مبتنی بر SPHINCS+ – یک طرح امضای مبتنی بر hash بدون حالت است. از ML-DSA کندتر است و امضاهای بزرگتری تولید میکند، اما اثبات امنیتی آن تنها بر اساس امنیت تابع hash است و آن را به الگوریتم پشتیبان ارزشمندی در صورت یافتن آسیبپذیری در طرحهای مبتنی بر lattice تبدیل میکند. برای مواردی که نیاز به تأیید امضای بلندمدت (سالها تا دههها) دارند توصیه میشود.
FN-DSA (FIPS 206) – مبتنی بر FALCON – یک طرح امضا با اندازه امضای کوچکتر از ML-DSA است که در محیطهای با پهنای باند محدود مفید است. برای جلوگیری از حملات جانبی پیادهسازی دقیق نیاز دارد و در مقایسه با ML-DSA برای بیشتر سازمانها اولویت پایینتری دارد.
ترتیب اولویت مهاجرت برای بیشتر سازمانها: ابتدا ML-KEM (محافظت از تبادل کلید در مسیر)، سپس ML-DSA (محافظت از احراز هویت)، سپس در نظر گرفتن SLH-DSA برای امضاهای بلندمدت. FN-DSA برای محیطهای تخصصی است.
آنچه CISA و NIST واقعاً الزام کردهاند
نشریه ویژه NIST 1800-38C (دسامبر ۲۰۲۴) راهنمای مهاجرت برای TLS 1.3 ارائه میدهد و تنظیمات ترکیبی خاص تبادل کلید را توصیه میکند: X25519MLKEM768 (ترکیب ML-KEM-768 با X25519) برای استقرار فوری. حالتهای ترکیبی تبادل کلید کلاسیک و پساکوانتومی را همزمان اجرا میکنند – اگر هر یک امن باشد، جلسه امن است – و به سازمانها اجازه میدهد PQC را بدون شرط بندی همه چیز بر روی الگوریتمهای جدید قبل از زمان کافی در میدان مستقر کنند.
راهنمای CISA در سال ۲۰۲۵ برای سازمانهای غیرنظامی فدرال دو مرحله تعیین کرد: تکمیل فهرست رمزنگاری تا پایان ۲۰۲۶ و تکمیل مهاجرت سیستمهای اولویتدار تا پایان ۲۰۳۰. «سیستمهای اولویتدار» به معنای سیستمهای پردازش اطلاعات طبقهبندی شده، کنترل زیرساخت بحرانی و سیستمهای پردازش اطلاعات قابل شناسایی شخصی در مقیاس بزرگ است.
برای بخش خصوصی، این موارد الزام قانونی نیستند. اما صنایع تحت نظارت از قبل شاهد انتقال الزامات هستند: نهادهای نظارتی خدمات مالی در اتحادیه اروپا آمادگی برای PQC را در استانداردهای فنی DORA 2026 خود گنجاندهاند. راهنمای HIPAA بهروزرسانی شده در ۲۰۲۵ به استانداردهای PQC NIST برای سیستمهای مراقبت بهداشتی که سوابق با نگهداری طولانی را پردازش میکنند ارجاع میدهد. الزامات تدارکات جلوتر از شما هستند: اگر به سازمانهای فدرال عرضه میکنید، سیستمهای قابلیت PQC قبل از ۲۰۲۸ الزام قراردادی خواهد بود.
از کجا شروع کنیم: فهرست رمزنگاری
اولین و اغلب دست کم گرفته شدهترین گام، دانستن رمزنگاری فعلی سیستم شما است. بیشتر سازمانها تصویر کاملی از محل استفاده از RSA و ECDSA در سراسر سیستمهای خود ندارند. فهرستبرداری سختتر از آن چیزی است که به نظر میرسد، زیرا عناصر رمزنگاری در کتابخانههای برنامه، زیرساخت شبکه، سیستمهای PKI، ماژولهای امنیتی سختافزاری و نرمافزارهای شخص ثالث تعبیه شدهاند.
فرآیند فهرستبرداری باید فهرستی از موارد زیر تولید کند: همه گواهیها و الگوریتمهای آنها، همه مکانیسمهای تبادل کلید در حال استفاده (به تفکیک پروتکل و سیستم)، همه زیرساختهای امضای کد و امضای اسناد، همه HSMها و پشتیبانی الگوریتمی آنها، و همه فروشندگان شخص ثالث که قابلیتهای رمزنگاری آنها بر وضعیت امنیتی شما تأثیر میگذارد.
ابزارهایی که کمک میکنند: مرکز ملی امنیت سایبری NIST یک پروژه مهاجرت PQC با ابزارهای منبع باز منتشر کرده است. فروشندگانی از جمله Keyfactor، AppViewX و Venafi ابزارهای فهرست گواهی با نقشهبرداری مهاجرت PQC منتشر کردهاند. ابزارهای اسکن شبکه مانند Qualys و Tenable قابلیتهای تشخیص PQC را اضافه کردهاند. نکته این نیست که فوراً یک فهرست کامل داشته باشید – بلکه داشتن یک نقطه شروع قابل دفاع است.
آنچه امروز قابل استقرار است
چندین سیستم اصلی از قبل از تبادل کلید پساکوانتومی در حالت ترکیبی پشتیبانی میکنند:
OpenSSH 9.0 (منتشر شده در آوریل ۲۰۲۲) به طور پیشفرض از sntrup761x25519 برای تبادل کلید استفاده میکند. در حالی که این نسخه قبل از استانداردهای نهایی NIST است و از الگوریتم متفاوتی استفاده میکند، الگو را نشان میدهد: تبادل کلید ترکیبی در تولید کار میکند و سالها است که کار میکند.
TLS 1.3 با X25519MLKEM768 در Chrome 131 (منتشر شده در نوامبر ۲۰۲۴)، Firefox 132 و OpenSSL 3.5 پشتیبانی میشود. Cloudflare در سپتامبر ۲۰۲۴ تبادل کلید ترکیبی PQC را برای تمام ترافیک فعال کرد. Apple در فوریه ۲۰۲۵ تبادل کلید ترکیبی ML-KEM را در iMessage به عنوان بخشی از پروتکل PQ3، جایگزین طرح PQXDH راهاندازی شده در ۲۰۲۴، فعال کرد.
نقطه شروع عملی برای بیشتر سازمانها در سال ۲۰۲۶: فعالسازی X25519MLKEM768 در لایه پایان TLS (لود بالانسرها، دروازههای API، تنظیمات CDN) و بهروزرسانی نقشه راه PKI داخلی برای شامل شدن قابلیت صدور گواهی ML-DSA تا ۲۰۲۸. هیچ یک از این موارد نیاز به کارهای فوقالعاده سازمانی ندارد – آنها تغییرات پیکربندی و کار برنامهریزی PKI هستند که میتوانند فوراً شروع شوند.
سازمانهایی که در ۲۰۲۹ با مشکل مواجه خواهند شد، آنهایی هستند که این را یک مشکل آینده تلقی میکنند. آنهایی که به خوبی مدیریت میکنند، اکنون فهرستبرداری میکنند، تبادل کلید ترکیبی را در لبه مستقر میکنند، و الزامات فروشنده شامل PQC را از امروز به چرخههای تدارکات اضافه میکنند.