هشدار بانک مرکزی اروپا درباره رمزگشایی آیندهٔ اطلاعات ذخیره‌شده

هشدار دیروز دقیقاً درباره چه بود؟

فرانک الدرسون، نایب‌رئیس هیئت نظارت بانک مرکزی اروپا، روز ۳۰ سپتامبر در کنفرانس بین‌المللی ناظران بانکی در بالی، ریسک کوانتومی را در کنار دیگر چالش‌های نظارتی مطرح کرد. او توضیح داد که اطلاعات رمز‌شده می‌تواند امروز جمع‌آوری و ذخیره شود تا در آینده امکان رمزگشایی آن فراهم شود. اهمیت خبر برای واحد مالی در همین فاصله زمانی است: پایان سال مالی، لزوماً پایان ارزش یا حساسیت اطلاعات آن سال نیست. ^[۱]

سخنرانی، اعلام کشف یک حمله موفق به بانک‌ها یا معرفی مهلت تازه‌ای برای تعویض نرم‌افزار نیست. اشاره الدرسون به امکان دسترسی گسترده‌تر به فناوری کوانتومی تا ۲۰۳۰ نیز پیش‌بینی مشروط است؛ از آن نمی‌توان تاریخ قطعی شکستن رمز سامانه مشخصی را استخراج کرد. گزارش حاضر هیچ شاهدی برای چنین رخدادی در ایران ارائه نمی‌کند و از این سخنرانی، تکلیف قانونی داخلی نتیجه نمی‌گیرد. ^[۱]

برداشت ژرف‌بان این است که ریسک کوانتومی اطلاعات مالی باید وارد گفت‌وگوی خرید و پشتیبانی شود. تصمیم امروز می‌تواند کوچک و مشخص باشد: تعیین کنید کدام داده باید برای چند سال محرمانه بماند و چه کسی پاسخ‌گوی امکان ارتقای حفاظت آن است. این تصمیم با خرید فوری یک محصول دارای برچسب «کوانتومی» تفاوت دارد و به شناخت دارایی‌های موجود وابسته است.

عمر محرمانگی را از عمر پرونده جدا کنید

این سازوکار، موضوع تازه‌ای در اسناد امنیتی نیست. راهنمای مشترک CISA، NSA و NIST با تاریخ ۱۷ اوت ۲۰۲۳ توضیح می‌دهد که داده دارای نیاز بلندمدت به محرمانگی ممکن است هدف جمع‌آوری برای رمزگشایی بعدی قرار گیرد. راهنما تهیه فهرست وابستگی‌های رمزنگاری، ارزیابی ریسک و گفت‌وگو با فروشندگان را پیشنهاد می‌کند. این سند قدیمی‌تر، پشتوانه فنی هشدار دیروز است؛ خبر انتشار استاندارد تازه در مهر امسال محسوب نمی‌شود. ^[۲]

برای روشن‌شدن تصمیم، یک شرکت فرضی را در نظر بگیرید: گزارش عمومی فروش ماه قبل، پرونده حقوق کارکنان و شرایط قیمت‌گذاری یک قرارداد بلندمدت در یک محل نگهداری می‌شوند. حجم یکسان فایل‌ها به معنی حساسیت یکسان نیست. واحد مالی باید همراه مسئول امنیت تعیین کند افشای هر دسته، امروز و چند سال بعد چه پیامدی دارد. این مثال آموزشی است؛ درباره روش رمزنگاری یا وضعیت واقعی هیچ شرکت ایرانی ادعایی نمی‌کند.

فهرست اولیه می‌تواند نام دسته اطلاعات، مالک آن، محل نگهداری، مسیر انتقال، مدت محرمانگی و تأمین‌کننده مسئول را کنار هم بیاورد. پیشنهاد تحریریه این است که اطلاعات نامعلوم را صریحاً نامعلوم ثبت کنید. عبارت «همه فایل‌ها رمز دارند» پاسخ کافی برای تعیین مسئولیت یا برآورد هزینه نیست. مدت نگهداری قانونی اسناد را نیز با مدت محرمانگی یکی نگیرید؛ تعیین و تغییر آن باید با بررسی مقررات و تعهدات همان شرکت انجام شود.

سه استاندارد وجود دارد؛ محصول شما چه چیزی را پشتیبانی می‌کند؟

NIST در ۱۳ اوت ۲۰۲۴ سه استاندارد نهایی را اعلام کرد: FIPS 203 برای سازوکار برقراری کلید ML-KEM و FIPS 204 و FIPS 205 برای دو روش امضای دیجیتال ML-DSA و SLH-DSA. بنابراین بحث، انتظار برای اولین استاندارد نیست. کاربرد این سه هم یکسان نیست: برقراری کلید و امضای دیجیتال وظایف متفاوت دارند و نمی‌توان نام یکی را گواه پوشش تمام نیازهای امنیتی دانست. ^[۳]

در سند مشترک نهادهای آمریکایی، تمرکز بر وابستگی به رمزنگاری کلید عمومی، از جمله RSA و روش‌های مشخص مبتنی بر منحنی بیضوی است. این گزاره به معنی ازکارافتادن همه انواع رمزنگاری یا ناامن‌بودن قطعی هر نسخه پشتیبان نیست. از تیم فنی بخواهید مشخص کند در هر مسیر چه الگوریتم، کتابخانه و نسخه‌ای استفاده می‌شود و تأمین‌کننده چه برنامه مستندی برای تغییر آن دارد. ^[۲]

پیشنهاد اجرایی برای تمدید قرارداد این است که وعده فروشنده را به نسخه، دامنه پوشش و آزمون قابل قبول وصل کنید. آیا ارتقا شامل خود برنامه است یا تجهیزات و ارتباطات جانبی را هم پوشش می‌دهد؟ چه کسی سازگاری با نرم‌افزارهای دیگر را می‌آزماید؟ هزینه در پشتیبانی جاری منظور شده یا جداگانه برآورد می‌شود؟ پاسخ مکتوب به این پرسش‌ها برای بودجه مفیدتر از یک عبارت تبلیغاتی بدون دامنه و تاریخ است.

آزمایش پرداخت چه محدودیتی را نشان می‌دهد؟

بانک تسویه‌های بین‌المللی در گزارش فاز دوم Project Leap، منتشرشده در ۱۱ دسامبر ۲۰۲۵، از آزمایش رمزنگاری پساکوانتومی در یک سامانه پرداخت عملیاتی خبر داد. در این تجربه، امضاهای دیجیتال متعارف در دستورهای انتقال نقدینگی با روش‌های پساکوانتومی جایگزین شدند. خلاصه رسمی می‌گوید چند جزء سامانه به اصلاح نیاز داشتند و تفاوت عملکرد روش‌ها قابل توجه بود؛ آمادگی بیشتر پیش از پذیرش گسترده ضروری دانسته شد. ^[۴]

حد این شاهد مهم است: یک آزمایش بانکی، تأیید آماده‌بودن همه محصولات حسابداری یا راه‌اندازی همین فناوری در شبکه پرداخت ایران نیست. ما از خلاصه رسمی پروژه استفاده می‌کنیم و درصدی برای افزایش هزینه یا افت سرعت شرکت شما تخمین نمی‌زنیم. نتیجه مدیریتی پیشنهادی، جداکردن هزینه مجوز از هزینه آزمون سازگاری، اصلاح اتصال‌ها، آموزش پشتیبانی و زمان‌بندی تغییر است. هر کدام باید صاحب و مدرک برآورد داشته باشد.

NIST در نسخه به‌روزشده سند چابکی رمزنگاری، مورخ ۲۹ ژوئن ۲۰۲۶، این قابلیت را توان جایگزینی و تطبیق الگوریتم‌ها در اجزای مختلف، همراه با حفظ امنیت و تداوم عملیات تعریف می‌کند. این تعریف نشان می‌دهد کیفیت تغییر هم موضوع ارزیابی است. برای جلسه مالی، پیشنهاد ما درخواست یک برنامه آزمون در محیط غیرعملیاتی و معیار روشن بازگشت از تغییر ناموفق است؛ جزئیات فنی باید به مسئول متخصص سپرده شود. ^[۵]

مهلت‌های ۲۰۲۸، ۲۰۳۱ و ۲۰۳۵ برای چه کسانی است؟

راهنمای مرکز ملی امنیت سایبری بریتانیا سه نقطه زمانی پیشنهادی دارد: تا ۲۰۲۸ شناخت وابستگی‌ها و برنامه اولیه، تا ۲۰۳۱ مهاجرت فعالیت‌های دارای اولویت بالا و تا ۲۰۳۵ تکمیل مهاجرت. مخاطب اصلی آن سازمان‌های بزرگ، زیرساخت‌های مهم و مجموعه‌های دارای فناوری اختصاصی است. این زمان‌بندی را نباید در گزارش هیئت‌مدیره به‌عنوان مهلت قانونی شرکت ایرانی نقل کرد. ^[۶]

همان راهنما برای کسب‌وکارهای کوچک و متوسطِ متکی به محصولات معمول، نقش به‌روزرسانی‌های تأمین‌کننده را برجسته می‌کند؛ سامانه‌های اختصاصی ممکن است برنامه‌ریزی بیشتری لازم داشته باشند. پس اندازه پروژه باید با وابستگی واقعی تناسب داشته باشد. دو شرکت با درآمد برابر می‌توانند نیاز متفاوتی داشته باشند: یکی از نرم‌افزار استاندارد پشتیبانی‌شده استفاده می‌کند و دیگری اتصال‌های اختصاصی و قدیمی دارد. ^[۶]

محدودیت اصلی برآورد مالی همچنان پابرجاست: این منابع زمان دستیابی به رایانه قادر به شکستن رمز کاربردی شرکت شما، هزینه مهاجرت آن یا احتمال هدف‌گرفتن داده‌هایش را تعیین نمی‌کنند. یک تفسیر، ضرورت آماده‌سازی زودهنگام برای داده بلندعمر است؛ تفسیر دیگر بر پرهیز از هزینه‌کرد زودرس برای فناوری یا محصول ناپخته تأکید دارد. ثبت وابستگی‌ها و گرفتن تعهد قابل سنجش از فروشنده، اقدام مشترک و کم‌ابهام این دو نگاه است.

در بازبینی بعدی قرارداد چه خروجی بخواهیم؟

برای جلسه بعدی، یک جدول کوتاه از سامانه‌های دارای اطلاعات بلندمدت بخواهید: مسئول داخلی، تاریخ پایان پشتیبانی، پاسخ فروشنده درباره ارتقا، برآورد مستند هزینه و تصمیم بازِ نیازمند تأیید. نبود پاسخ را به مبلغ قطعی تبدیل نکنید. اگر بررسی فقط هزینه کارشناسی و آزمون را توجیه می‌کند، همان را بودجه‌بندی کنید؛ درباره خرید جایگزین پس از روشن‌شدن دامنه و گزینه‌های واقعی تصمیم بگیرید.

در ادامه، نسخه‌های منتشرشده و قابل آزمون فروشنده، نتیجه آزمون سازگاری و تغییر تعهدات پشتیبانی را رصد کنید. نشانه پیشرفت برای واحد مالی، تبدیل یک وابستگی نامعلوم به پاسخ مستند و قابل قیمت‌گذاری است. این کار نباید رسیدگی به دسترسی‌های غیرضروری، پشتیبان‌گیری یا به‌روزرسانی‌های جاری را عقب بیندازد. موضوع خبر امروز افزودن افق بلندمدت به همان مسئولیت نگهداری اطلاعات است.