كشف باحثون من جامعة مصاريك عن معلومات مهم حول نقاط الضعف في مختلف أناتطبيقات خوارزمية توليد التوقيع الرقمي ECDSA / EdDSA ، يسمح باسترداد قيمة المفتاح الخاص بناءً على تحليل تسريبات المعلومات على وحدات البت الفردية التي تظهر عند تطبيق أساليب التحليل من خلال قنوات الجهات الخارجية. الثغرات الأمنية هي الاسم الرمزي مينيرفا.
أشهر المشاريع ذلك يؤثر طريقة الهجوم المقترحة هي OpenJDK و OracleJDK (CVE-2019-2894) والمكتبة ليجبكريبت (CVE-2019-13627) المستخدمة في GnuPG. المشاكل أيضا عرضة للمكتبات MatrixSSL و Crypto ++ و wolfCrypt و elliptical و jsrsasign و Python-ECDSA و ruby_ecdsa و fastecdsa وكذلك بعض البطاقات الذكية Athena IDProtect، TecSec Armored Card، SafeNet eToken 4300، Valid S / A IDflex V.
بالإضافة إلى نقاط الضعف المذكورة في الوقت الحالي فهي لا تتأثر OpenSSL و Botan و mbedTLS و BoringSSL. Mozilla NSS و LibreSSL و Nettle و BearSSL و cryptlib و OpenSSL في وضع FIPS. تشفير Microsoft .NET و Linux kernel libkcapi و Sodium و GnuTLS لم يتم اختبارها بعد.
لقد وجدنا تطبيقات تفقد طول بت من العدد القياسي أثناء الضرب القياسي في ECC. قد يبدو هذا التسرب ضئيلًا نظرًا لأن طول البت يحتوي على كمية صغيرة جدًا من المعلومات الموجودة في القياس. ومع ذلك ، في حالة إنشاء توقيع ECDSA / EdDSA ، فإن تصفية طول البت للقيمة العشوائية غير كافية للاسترداد الكامل للمفتاح الخاص المستخدم بعد مراقبة بضع مئات إلى بضعة آلاف من التوقيعات في الرسائل المعروفة ، بسبب لتطبيق بعض التقنيات.
نعتقد أن جميع البطاقات السابقة قد تأثرت لأنها تشترك في مكون ECDSA مشترك (وحدة FIPS 214) ، والذي تم وصفه على أنه مكون Athena OS2 ECDSA755 في Inside Secure AT90SC A1.0 (البرامج الثابتة). لقد اختبرنا الثغرة الأمنية فقط على بطاقة Athena IDProtect باستخدام بيانات CPLC و ATR
سبب المشكلة هو القدرة على تحديد قيم البت الفردية خلال عملية الضرب بواسطة عددي أثناء تداول ECC. تُستخدم الطرق غير المباشرة ، مثل تقدير التأخير في إجراء الحسابات ، لاستخراج المعلومات من البتات.
يتطلب الهجوم وصولاً غير مميز إلى المضيف يتم فيه إنشاء التوقيع الرقمي (لا يتم استبعاد الهجوم عن بعد ، ولكنه معقد للغاية ويتطلب قدرًا كبيرًا من البيانات للتحليل ، وبالتالي يمكن اعتباره غير مرجح).
على الرغم من صغر حجم التسرب ، بالنسبة لـ ECDSA ، فإن تعريف حتى عدد قليل من البتات مع معلومات حول ناقل التهيئة (nonce) يكفي لتنفيذ هجوم لاستعادة المفتاح الخاص الكامل بالتتابع.
وفقًا لمؤلفي الطريقة ، لاستعادة المفاتيح بنجاح ، يكفي تحليل عدة مئات إلى عدة آلاف من التوقيعات الرقمية المولدة للرسائل التي يعرفها المهاجم. على سبيل المثال ، لتحديد المفتاح الخاص المستخدم في بطاقة Athena IDProtect الذكية بناءً على شريحة Inside Secure AT90SC ، باستخدام المنحنى البيضاوي secp256r1 ، تم تحليل 11 ألف توقيع رقمي. كان إجمالي وقت الهجوم 30 دقيقة.
رمز الهجوم وإثبات المفهوم مستوحى من طريقة Brumley & Tuveri.
تم إصلاح المشكلة بالفعل في libgcrypt 1.8.5 و wolfCrypt 4.1.0، لم يتم إنشاء تحديثات لمشاريع أخرى. من الممكن أيضًا تتبع إصلاح الثغرة الأمنية في حزمة libgcrypt في التوزيعات على هذه الصفحات: ديبيان, أوبونتو, RHEL, فيدورا, openSUSE / SUSE, فري, القوس.
اختبر الباحثون أيضًا بطاقات ومكتبات أخرى ، والتي لا تعتبر التالية عرضة للخطر:
- برنامج OpenSSL 1.1.1d
- BouncyCastle 1.58 تحديث
- BoringSSL 974f4dddf
- ليبتومكربت 1.18.2
- بوتان 2.11.0
- مايكروسوفت CNG
- mbedTLS 2.16.0
- إنتل IPP-Crypto
بطاقات
- ACS ACOSJ 40 كيلو
- فيتيان A22CR
- G&D SmartCafe 6.0 تحديث
- G&D SmartCafe 7.0 تحديث
- إنفينيون CJTOP 80K INF SLJ 52GLA080AL M8.4
- إنفينيون SLE78 يونيفرسال جي كارد
- نكسب JCOP31 v2.4.1
- إن إكس بي جيكوب CJ2A081
- NXP JCOP v2.4.2 R2
- NXP JCOP v2.4.2 R3
- SIMOME TaiSYS Vault
إذا كنت تريد معرفة المزيد عن الهجوم المستخدم ونقاط الضعف التي تم اكتشافها ، فيمكنك القيام بذلك في الرابط التالي. الأدوات المستخدمة لتكرار الهجوم متاحة للتنزيل.