تم تقديم ورقة (Forging 1024-bit RSA signatures in nearly SNFS time) الصادرة عن فريق بحث من جامعة UC San Diego وفريق INRIA الفرنسي بتاريخ 20 سبتمبر 2026، وتم إدراجها في أرشيف IACR Cryptology ePrint Archive بتاريخ 22 سبتمبر. في بيئة اختبارية، تعامل الفريق مع HSM كآلة توقيعية (signature oracle)، وأجرى ما يقارب 2^32 مرة (حوالي 4.3 مليار مرة) من استعلامات التوقيع الأصلية باستخدام مفاتيح اختبار ذاتية من نوع RSA بطول 1024 بت، وصولاً إلى تزوير التوقيعات. وتبلغ التكلفة الحسابية الإجمالية المذكورة في الورقة حوالي 1380 سنة من وحدات CPU (CPU cores)، استغرقت قرابة خمسة أشهر، وكان الجزء الأكبر منها مخصصاً للحسابات التحضيرية. الورقة هي نسخة ما قبل النشر وليست النسخة النهائية الخاضعة لمراجعة الأقران بعد.
تحدد القيود أنه لا ينبغي فهمها على أنها “تم اختراق المحفظة/الوسيلة الأمنية العتادية”. تستهدف الهجمة واجهات فك تشفير أو توقيع RSA غير مضاف إليها حشو (un-padded/raw) أو واجهات فك تشفير يمكن الوصول إليها. وتذكر Decrypt أن التجارب أغلقت وضع FIPS في HSM للسماح بتوقيع البيانات غير المُنسَّقة، وأن الفريق استخدم مفاتيح الاختبار الخاصة به. وتقول الورقة إن آليات حشو RSA الشائعة لا توفر الواجهة القابلة للاستغلال نفسها، وتعتقد أنه لا توجد تهديدات فورية لمعظم عمليات نشر RSA الحديثة. لم يتم اختراق أي مزود استضافة/خدمات إنتاجية، ولم يتم استخراج أي مفاتيح خاصة.
【تحليلي】
تشير هذه النتيجة إلى مخاطر تتعلق بالإعداد والواجهة: إذ إن العتاد يحتفظ بالمفتاح الخاص داخل الشريحة ولا يضمن تلقائيًا أن جميع طلبات التوقيع تكون آمنة؛ فإذا كانت الواجهة الخارجية تسمح للمهاجمين باستدعاء عمليات RSA الأولية بكميات كبيرة، فقد تتحول القدرة النظرية على التوقيع عبر ما يُشبه "الصندوق الأسود" إلى سطح هجوم. ولا يعني ذلك أن توقيعات سلاسل البيتكوين أو الإيثيريوم على السلسلة قد تم اختراقها—فإنهما تستخدمان عادةً توقيعات المنحنيات البيضاوية (ECDSA)، وليست RSA محل الدراسة في الورقة.
ترتبط هذه القصة بشكل واقعي أكثر بالاستخدامات لدى مزودي الاستضافة ومنصات التداول والجهات التي تدير الخلفيات المؤسسية، عبر الشهادات والتحقق من الهوية أو خدمات التوقيع. لتحديد ما إذا كان الأمر مؤثرًا، يجب النظر إلى الجهاز المحدد والخوارزمية ووضع الحشو وإعدادات FIPS وأذونات واجهة البرمجة (API)؛ ولا يمكن الوصول إلى نتيجة منطقية من مجرد "استخدام HSM" أو "استخدام RSA" وحده.
【فحوصات قابلة للتنفيذ】
يجب على فرق الاستضافة والبنية التحتية جرد المفاتيح ومنافذ التوقيع الخاصة بـ RSA التي لا تزال قيد الاستخدام، والتأكد من أن HSM في الإنتاج ترفض طلبات raw RSA، وتمكين إعدادات الحشو والتحقق المناسبة، وتقييد أذونات التوقيع ومراقبة أحجام الاستدعاءات غير الطبيعية؛ والاستغناء عن مفاتيح 1024 بت الموروثة، مع إدراج انتقال ما بعد التشفير (ما بعد الكم) ضمن خطة طويلة الأجل. يمكن لخفض معدل الطلبات أن يكون خط دفاع إضافيًا فقط، ولا يغني عن الإعداد الصحيح للحشو والواجهة.
ينبغي للفرق البحثية المخصصة للمتابعة مراقبة ما إذا كانت ستصدر نسخة خاضعة للتحكيم من النظراء، وما إذا كانت فرق أخرى قادرة على إعادة الإنتاج، وما إذا كان كبار مصنعي HSM سيقومون بتحديث توصياتهم الأمنية الخاصة بواجهة raw RSA. إذا تم تعديل استنتاجات الورقة، أو أكد المصنعون وجود ثغرة قابلة للاستغلال عن بُعد ضمن إعدادات الإنتاج القياسية، فيجب ترقية تقدير المخاطر؛ أما إذا كانت المشكلة مقتصرة على إيقاف FIPS وفتح واجهة توقيع أولية في اختبارات/نشر خاص، فلا ينبغي تعميم ذلك على أن أنظمة الاستضافة السائدة قد فشلت على نطاق واسع.
المصدر: IACR Cryptology ePrint Archive، الورقة 2026/2131 (تم تقديمها 2026-09-20، وتم قبولها 2026-09-22): https://eprint.iacr.org/2026/2131
تقرير Decrypt، 2026-09-28: https://decrypt.co/379505/rsa-attack-without-stealing-key-what-it-means-crypto
ملاحظة: الورقة هي نسخة أولية قبل النشر (preprint)؛ ولم تتم الإشارة إلى رموز/عملات محددة لأن الورقة لم تحدد أي توكن أو سلسلة بعينها تتأثر. هذه قراءة وتحليل شخصي، ولا تشكل نصيحة استثمارية.