آسیب‌پذیری در تولید کلید رمزنگاری AES در نرم‌افزارهای PDF: وقتی امنیت ۲۵۶ بیتی به ۹ بیت آب می‌شود — The case of the 9 bit AES key
خلاصه
بررسی امنیتی جدید نشان می‌دهد که برخی نرم‌افزارهای خواندن و ویرایش PDF، کلیدهای رمزنگاری AES-256 را با استفاده از منابع تصادفی‌ساز ناامن و فضاهای حالت بسیار کوچک تولید می‌کنند. این نقص باعث می‌شود که رمزگشایی فایل‌های محافظت‌شده بدون نیاز به رمز عبور و در کسری از ثانیه امکان‌پذیر شود.
رمزنگاری اسناد PDF برای محافظت از داده‌ها، جریان‌های اطلاعاتی و فراداده‌ها طراحی شده است. استانداردهای مدرن PDF که از ریبیزون ۶ به بعد معرفی شده‌اند، برای رمزنگاری محتوا از الگوریتم AES-256 استفاده می‌کنند. در این ساختار، محتوای فایل با یک کلید تصادفی ۳۲ بایتی رمزگذاری می‌شود و خود این کلید نیز با هشِ رمز عبور کاربر و یک مقدار نمک (salt) محافظت می‌گردد. ایده اصلی این است که حتی اگر رمز عبور ضعیف باشد، کلید اصلی فایل به اندازه‌ای تصادفی و قوی باشد که حمله به آن غیرممکن یا بسیار زمان‌بر باشد. اما تحقیقات اخیر نشان داده است که نحوه تولید این کلیدها در چندین کتابخانه و نرم‌افزار معروف PDF به شدت معیوب است.
ماجرای کلید ۹ بیتی در MuPDF
در نسخه‌های قدیمی‌تر کتابخانه MuPDF، برای تولید اعداد تصادفی از خانواده drand48 استفاده می‌شد که یک تولیدکننده عدد شبه‌تصادفی خطی (LCG) با طول ۴۸ بیت است. این سیستم تنها یک بار با استفاده از زمان سیستم (epoch) مقداردهی اولیه یا Seed می‌شد. نکته فنی جالب اینجاست که در پیاده‌سازی این تابع، ۱۶ بیت پایین حالت همواره مقدار ثابتی دارد و ۳۲ بیت زمان نیز در بقیه ساختار قرار می‌گیرد.
هنگامی که نرم‌افزار بایت‌های تصادفی برای ساخت کلید تولید می‌کند، عملیات شیفت‌بیت (Bitshift) و کست کردن باعث می‌شود که بیت‌های بالای حالت هیچ تأثیری روی خروجی نداشته باشند. از آنجا که بیت‌های پایین ثابت هستند، در نهایت فقط ۹ بیت از تمپ‌استامپ زمان در مقدار نهایی کلید تأثیرگذار می‌گذارند. به عبارت دیگر، زمان‌هایی که ۵۸۲ ثانیه با هم اختلاف دارند، دقیقاً یک جریان بایت یکسان تولید می‌کنند. پژوهشگران با استفاده از یک اسکریپت ساده پایتون توانستند کل فضای کلیدهای ممکن (تنها ۵۱۲ حالت) را در حدود ۱۱ میلی‌ثانیه بروت‌فورس کرده و سند را بدون داشتن رمز عبور رمزگشایی کنند.
پیاده‌سازی آسیب‌پذیر در Foxit و PDFium
بررسی‌ها نشان داد که نرم‌افزار Foxit PDF Reader و کدهایی که از پروژه قدیمی PDFium به ارث رسیده بودند نیز مشکل مشابهی دارند. در این ابزارها، کلید فایل از طریق هش کردن یک تمپ‌استامپ ۳۲ بایتی حافظه مقداردهی‌نشده و یک رشته ثابت با تابع SHA-256 ساخته می‌شد. در عمل، بایت‌های حافظه مقداردهی‌نشده با صفر پر می‌شدند و عملاً هیچ تصادفی‌سازی واقعی رخ نمی‌داد.
مهندسان توانستند با نوشتن یک پیاده‌سازی موازي در زبان Rust و با استفاده از کتابخانه Rayon روی یک پردازنده مدرن، صدها میلیون تمپ‌استامپ در ثانیه را بررسی کنند. این کار به آن‌ها اجازه داد کلید رمزنگاری اسناد تولید شده را در کسری از ثانیه بازیابی کنند.
سایر کتابخانه‌ها: OpenPDF و iText
مشکلات مشابهی در کتابخانه‌های Java مانند OpenPDF و iText نیز کشف شد که در آن‌ها تصادفی‌سازی رمزی از طریق کلاس IVGenerator و جریان ARC4 متکی بر زمان به میلی‌ثانیه و حافظه آزاد JVM انجام می‌شد. اگرچه فضای حالت در اینجا بزرگ‌تر از مثال MuPDF است، اما باز هم نشان می‌دهد که چگونه یک منبع تصادفی‌ساز ناامن، امنیت ۲۵۶ بیتی وعده داده شده را به خطر می‌اندازد.
چرا این مسئله برای مهندسان نرم‌افزار اهمیت دارد؟
این آسیب‌پذیری‌ها درس مهمی برای طراحان سیستم‌های رمزنگاری دارد:
- اعتماد نکردن به مولدهای شبه‌تصادفی قدیمی: استفاده از LCGها یا توابع زمانی ساده برای اهداف رمزنگاری فاجعه‌بار است.
- شکست الگوهای امنیتی ظاهری: استفاده از الگوریتم قدرتمندی مثل AES-256 هیچ کمکی نمی‌کند وقتی کلید ورودی آن از یک فضای حالت بسیار کوچک و قابل پیش‌بینی مشتق شده باشد.
- اهمیت افشا و اصلاح: این موارد به سازندگان گزارش شده و برخی مانند MuPDF آن را رفع کرده‌اند، اما فایل‌های PDF قدیمی که از قبل با این نسخه‌ها تولید شده‌اند همچنان آسیب‌پذیر باقی می‌مانند.
در بحث‌های هکرنیوز نیز کاربران به این نکته اشاره کردند که این ماجرا شباهت زیادی به باگ‌های معروف انتروپی کیف پول‌های سخت‌افزاری دارد که در آن ضعف در تولید اعداد تصادفی، کل لایه امنیتی را دور می‌زند.
این مطلب به‌صورت کاملاً خودکار و با هوش مصنوعی از مقالهٔ اصلی و بحث هکرنیوز تهیه شده و ممکن است خطا داشته باشد. حقوق مطلب اصلی متعلق به نویسندهٔ آن است. قوانین و گزارش مشکل