در تاریخ 22 ژوئن 2026 رئیس‌جمهور دستور اجرایی Executive Order 14409 با عنوان “Securing the Nation Against Advanced Cryptographic Attacks” را امضا کرد. این دستور مهلت‌های مشخصی تعیین می‌کند: تا 31 دسامبر 2030 سیستم‌های حساس فدرال باید به post-quantum encryption منتقل شوند و تا 31 دسامبر 2031 مهلت رسیدن به post-quantum authentication است. همچنین پیمانکاران فدرال موظف به رعایت نسخه‌های post-quantum در FIPS تا پایان 2030 شده‌اند. 🚀

تجربه تاریخی نشان داده که رهبری و خریدِ دولت‌های بزرگ باعث تسریع پذیرش فناوری‌های جدید در کل صنعت می‌شود؛ نمونه‌هایی مثل IPv6، RPKI و DNSSEC این موضوع را نشان داده‌اند. ادامه این مسیر حالا با post-quantum cryptography دنبال می‌شود و این دستور اجرایی هم در همین راستا قرار دارد.

این دستور در زمانی اهمیت ویژه‌ای دارد که جدول زمانی رسیدن به Q-Day — روزی که کامپیوترهای کوانتومی قادر به شکستن رمزنگاری کلید عمومی فعلی شوند — کوتاه‌تر شده است. در آوریل 2026، Cloudflare هدف کامل‌سازی امنیت post-quantum را به 2029 جابجا کرد، پس از پیشرفت‌های پژوهشی از Google و Oratomic. نهاد استانداردسازی NIST در 2024 نیز پیشنهاد کرده بود که RSA و Elliptic Curve Cryptography تا 2030 Deprecated شوند و تا 2035 غیرمجاز شوند.

وضعیت فعلی انتقال اینترنت به post-quantum این‌گونه است که بخش مربوط به encryption نسبتاً جلوتر است و بخش authentication تازه شروع شده. امروز بیش از دو سوم ترافیک مرورگر به شبکه Cloudflare با post-quantum encryption محافظت می‌شود و بسیاری از محصولات این شرکت post-quantum key agreement را پشتیبانی می‌کنند. پلتفرم SASE آن‌ها یعنی Cloudflare One، post-quantum encryption را روی ورودی‌ها و خروجی‌های معمول مثل TLS، MASQUE و IPsec فراهم می‌کند؛ همچنین پیاده‌سازی post-quantum authentication آغاز شده و هدف نهایی دست‌یابی به وضعیت fully post-quantum تا 2029 است.

این دستور روی کاری که از سال 2019 شروع شده پایه می‌گذارد. در عین حال فرصت‌هایی برای OMB وجود دارد تا با راهنمایی‌های هوشمندانه مهاجرت را اقتصادی و قابل اجرا کند. در ادامه یک نقشه راه و نکات فنی برای سازمان‌ها و آژانس‌ها آمده است تا مهاجرتشان مؤثرتر پیش برود. 📋

محور اصلی الزام‌های اجرایی دو گروه سیستم فدرال را هدف می‌گیرد: High Value Assets (HVAs) و high impact systems. HVAs سیستم‌ها یا اطلاعاتی هستند که OMB آن‌ها را به‌عنوان دارایی‌های مهم دولت شناسایی می‌کند — یعنی سیستم‌هایی که در صورت فساد یا نفوذ، به امنیت ملی، روابط خارجی یا اعتماد عمومی لطمه سنگینی می‌زنند. مثال: پایگاه‌داده‌های کارکنان دولت، سیستم‌های پردازش اطلاعات طبقه‌بندی‌شده یا پلتفرم‌های مدیریت تراکنش‌های مالی فدرال. سیستم‌های high impact بر اساس FIPS 199 آن‌هایی هستند که Confidentiality/Integrity/Availability آن‌ها در سطح “high” ارزیابی می‌شود و نقضشان می‌تواند خسارت‌های جدی شامل از دست رفتن جان، زیان مالی بزرگ یا ناتوانی قابل‌توجه آژانس در انجام مأموریت باشد.

نکته مهم اینکه EO الزام‌آور برای آژانس‌های فدرال است و به‌طور مستقیم شامل دولت‌های ایالتی، محلی، قبیله‌ای، دانشگاه‌ها یا بخش خصوصی نمی‌شود؛ به همین دلیل مهلت‌ها خاص آژانس‌های فدرال تعیین شده‌اند.

محدوده زمانی و تعهدات کلیدی که در EO آمده به‌صورت خلاصه:

ژوئیه 2026 — هر رئیس آژانس فدرال باید یک PQC migration lead تعیین کند و نام و اطلاعات تماس او را به OMB و National Cyber Director اعلام کند.

سپتامبر 2026 — OMB باید راهنمایی‌هایی منتشر کند که از آژانس‌ها می‌خواهد: (1) inventory از HVAs و سیستم‌های high impact را بازبینی کنند؛ (2) برنامه مهاجرت PQC را طراحی کنند؛ و (3) آن برنامه را به OMB و National Cyber Director ارسال کنند.

دسامبر 2030 — تمام HVAs و high impact systems باید برای key establishment به PQC منتقل شده باشند.

دسامبر 2031 — همان گروه از سیستم‌ها باید برای digital signatures و authentication به PQC منتقل شده باشند. (توجه: National Security Systems در یک مسیر جدا و طبقه‌بندی‌شده تحت مدیریت NSA قرار دارند و مهلت‌های آن‌ها بین 2030 تا 2033 تعریف شده است.)

EO مهاجرت PQC را به دو فاز اصلی تقسیم می‌کند: post-quantum key establishment (encryption) تا 2030 و post-quantum digital signatures (authentication) تا 2031. این جداکردن واقعیت فنی امروز را بازتاب می‌دهد؛ post-quantum encryption در اینترنت امروز در دسترس‌تر است و authentication پیچیدگی‌های بیشتری دارد. عملکرد QKD هم در این دستور کنار گذاشته شده که منطقی است چون Quantum Key Distribution برای مقیاس اینترنتی عملی نیست (نیاز به سخت‌افزار ویژه و پیوندهای فیزیکی اختصاصی دارد).

چرا باید فوراً روی post-quantum encryption کار کرد؟ به‌خاطر خطر harvest-now-decrypt-later: یعنی بازیگرهای تهدید امروز ترافیک رمزنگاری‌شده را ضبط می‌کنند تا وقتی کامپیوترهای کوانتومی قوی شدند، آن را رمزگشایی کنند. این موضوع برای داده‌هایی که حتی بعد از 3–10 سال هنوز ارزش دارند (حساب‌های بانکی، اطلاعات سلامت، داده‌های دفاعی، اطلاعات اپراتورهای مخابراتی و غیره) بسیار حیاتی است.

از سوی دیگر، post-quantum authentication جلوی جعل گواهی‌ها، امضای بدافزار با کلیدهای جعلی یا دسترسی غیرمجاز توسط کسی با کامپیوتر کوانتومی را می‌گیرد. این نوع مهاجرت ریسک فعال‌تری را می‌پوشاند که پس از ظهور یک CRQC واقعی (cryptographically-relevant quantum computer) خطرش محقق می‌شود.

زمینهٔ پیشرفت‌های کوانتومی هم اهمیت دارد: هم‌زمان با EO مربوط به post-quantum، یک EO دیگر برای تسریع توسعه و تجاری‌سازی quantum computing، sensing و networking هم امضا شده است. تعیین مهلت 2031 برای authentication نشان می‌دهد دولت احتمال معناداری برای ظهور یک CRQC در حوالی آن زمان می‌دهد.

اگر بخواهیم مقایسه‌ای فنی بین PQ Encryption و PQ Authentication داشته باشیم، نقاط کلیدی عبارت‌اند از:

– الگوریتم‌ها: برای key agreement (PQ Encryption) الگوریتم‌هایی مثل ML-KEM (تطبیق با FIPS 203) مطرح هستند؛ برای signatureها الگوریتم‌هایی مثل ML-DSA (FIPS 204) و SLH-DSA (FIPS 205) معرفی شده‌اند.

– عملکرد: hybrid ML-KEM over TLS 1.3 معمولاً سریع‌تر از معماری‌های کلاسیک مبتنی بر TLS 1.2 عمل می‌کند. اما signatureهای post-quantum بزرگ‌ترند و ممکن است در اتصالات کوتاه‌عمر یا پروتکل‌های محدود، تأثیر عملکردی نشان دهند.

– استانداردسازی IETF: در بخش TLS و IPsec پیشرفت خوبی هست و برخی پیکربندی‌ها برای تولید آماده‌اند. اما برای certificateها و بسیاری از پروتکل‌های دیگر هنوز کار در جریان است؛ PLANTS working group در IETF روی post-quantum certificates برای TLS فعال است.

– استقرار: PQ Encryption پذیرش بالاتری دارد — امروز دو سوم ترافیک مرورگر در Cloudflare با آن محافظت می‌شود و خدمات هسته‌ای زیادی از آن استفاده می‌کنند. اما PQ Authentication تاکنون بیشتر محدود به آزمایشی/پایلوت‌هاست و پشتیبانی گسترده در اکوسیستم تا حداقل 2027+ انتظار می‌رود.

– مهلت EO: encryption تا 2030 و authentication تا 2031؛ این فاصله یک ساله فشردگی بالایی ایجاد می‌کند و کارها نباید به‌صورت سریال اجرا شوند بلکه نیاز به کار همزمان است.

– تهدیدها و فوریت: برای encryption فوریت فوری است (داده‌های ضبط‌شده امروز را ممکن است در آینده رمزگشایی کنند). برای authentication، تهدید فعال بعد از ظهور یک CRQC ملموس می‌شود اما آماده‌سازی باید امروز شروع شود.

چالش‌های اصلی مهاجرت authentication شامل چند نکته است:

– اندازه بزرگ‌تر signatureها می‌تواند باعث افت عملکرد در برخی سناریوها شود؛ به همین خاطر پروژه‌هایی مثل Merkle Tree Certificates با همکاری Google Chrome در جریان است تا مشکل را برای TLS حل کنند.

– زنجیره‌های وابستگی در authentication طولانی‌تر است: نیاز به هماهنگی بین کلاینت‌ها، سرورها، certificate authorities، certificate transparency logs، root stores و مرورگرها وجود دارد که پیچیدگی پیاده‌سازی را افزایش می‌دهد.

– اکوسیستم برای PQ Authentication هنوز در مراحل اولیه است؛ برای داشتن اکوسیستمی بالغ و قابل‌اعتماد به زمان و هماهنگی بیشتر بین بازیگران نیاز داریم.

یک سال فاصله بین deadlines برای encryption و authentication خیلی کم است؛ بنابراین کارها باید به‌صورت موازی پیش روند تا مهلت 2031 از دست نرود. همچنین استانداردها و تصمیم‌های IETF برای پذیرش امن و گستردهٔ PQC ضروری‌اند و باید سازمان‌ها در این فرآیند همکاری فعال داشته باشند.

یکی از اثرات بالقوه و مهم این EO فشار روی زنجیره تأمین است: بخش قابل‌توجهی از توان تأثیرگذاری از طریق الزام به پیمانکاران فدرال اعمال می‌شود. طبق EO، FAR Council باید قوانین پیشنهادی منتشر کند تا “covered contractors” تا 31 دسامبر 2030 با NIST FIPS های دارای PQC مطابقت کنند و همچنین برنامه‌های افشای آسیب‌پذیری (vulnerability disclosure) را پیاده‌سازی نمایند — این الزامات می‌تواند موجی از تطبیق در صنعت را به دنبال داشته باشد.

برای تیم‌های DevOps / SRE که مسئول اجرای این مهاجرت هستند، یک نقشه راه عملیاتی پیشنهادی:

– تعیین مسئول PQC: یک PQC migration lead منصوب و کانال‌های هماهنگی با OMB و ارکان ذی‌ربط برقرار شود.

– inventory دقیق: شناسایی HVAs و سیستم‌های high impact، تعیین جریان‌های داده حساس و طول عمر مفید داده‌ها (data retention/value horizon) تا اولویت‌بندی مشخص شود.

– استراتژی hybrid و phased: در مرحله اول از hybrid deployments استفاده کنید (PQC + classical) تا compatibility و rollback ممکن بماند و سپس به سمت pure PQ حرکت کنید.

– آزمایش و اندازه‌گیری: lab و staging برای اندازه‌گیری تأثیر اندازه کلیدها و امضاها بر latency و throughput، و شناسایی نقاطی که نیاز به بهینه‌سازی (مثل connection reuse، keep-alive) دارند.

– مدیریت چرخه عمر گواهی‌ها: بازنگری در طول عمر گواهی‌ها، سازوکارهای rotation و تعامل با CAها و CT logs؛ هماهنگی با vendorها و root store maintainers ضروری است.

– اتوماسیون و CI/CD: اسکریپت‌ها و playbookها (Ansible/Terraform/CICD pipelines) را برای استقرار الگوریتم‌های PQ و تست‌های ناهمگام به‌روزرسانی کنید؛ تست‌های back-compat و interoperability را در pipeline بگنجانید.

– observability و incident response: متریک‌ها و alertهای جدید برای مشکلات crypto-related (مثلاً failed handshakes با الگوریتم‌های جدید)، و playbookهای پاسخ به رخدادهای مرتبط با کلید و گواهی.

– همکاری با تامین‌کنندگان و قراردادها: به‌روزرسانی شروط قراردادها برای تضمین پشتیبانی PQ، شفاف‌سازی timelines و الزامات تست و ارائه fallback plans.

– برنامه‌‌ریزی برای مقیاس‌پذیری: به‌خاطر افزایش اندازه امضاها و payloadهای کریپتو، ظرفیت شبکه و منابع محاسباتی را بازبینی و در صورت نیاز افزایش دهید.

– هماهنگی بین‌سازمانی: شرکت در کارگروه‌های صنعت، تعامل با IETF، NIST، CAها و دیگر پیمانکاران فدرال برای تضمین سازگاری و اجتناب از پیاده‌سازی‌های جزیره‌ای.

در پایان، پیام مشخص برای تیم‌های فنی این است: روی PQ Encryption فوراً کار کنید تا از ریسک harvest-now-decrypt-later محافظت کنید؛ هم‌زمان، برنامه و آزمایش‌های لازم برای PQ Authentication را شروع کنید چون فاصله زمانی تعیین‌شده کوتاه است و نیاز به کار موازی دارد. این مسیر فناوری و عملیاتی نیازمند تعامل نزدیک بین مهندسان شبکه، امنیت، عملیات و مدیریت، و همچنین هماهنگی با نهادهای استانداردسازی و تأمین‌کنندگان است. 💡