חוקרי אוניברסיטת מסריק חשפו מידע חשוב על פגיעות ב שונות אנייישומים של אלגוריתם ייצור החתימות הדיגיטליות ECDSA / EdDSA, המאפשר לשחזר את ערך המפתח הפרטי בהתבסס על ניתוח דליפות מידע על סיביות בודדות המופיעות בעת החלת שיטות ניתוח בערוצי צד שלישי. נקודות התורפה נקראות בשם מינרווה.
הפרויקטים המפורסמים ביותר שמשפיעים שיטת ההתקפה המוצעת היא OpenJDK, OracleJDK (CVE-2019-2894) והספריה libgcrypt (CVE-2019-13627) בשימוש ב- GnuPG. הבעיות הן רגישים גם לספריות MatrixSSL, Crypto ++, wolfCrypt, אליפטי, jsrsasign, Python-ECDSA, ruby_ecdsa, fastecdsa וגם כמה כרטיסים חכמים אתנה IDProtect, כרטיס משוריין TecSec, SafeNet eToken 4300, Valid S / A IDflex V.
בנוסף לפגיעות שהוזכרו כרגע הן לא מושפעות OpenSSL, Botan, mbedTLS ו- BoringSSL. Mozilla NSS, LibreSSL, Nettle, BearSSL, cryptlib, OpenSSL במצב FIPS. קריפטו של .NET של מיקרוסופט, ליבת הליבה של לינוקס לינוקס, נתרן ו- GnuTLS טרם נבדקו.
מצאנו יישומים שמאבדים את אורך הסיביות של הסקלר במהלך הכפל הסקלרי ב- ECC. דליפה זו עשויה להיראות זעירה מכיוון שאורך הסיביות מכיל כמות קטנה מאוד של מידע בסקלר. עם זאת, במקרה של יצירת חתימות ECDSA / EdDSA, סינון אורך הסיביות של ה- nonce האקראי מספיק להתאוששות מלאה של המפתח הפרטי המשמש לאחר התבוננות בכמה מאות עד כמה אלפי חתימות בהודעות ידועות, עקב היישום של כמה טכניקות.
אנו מאמינים כי כל הכרטיסים הקודמים מושפעים מכיוון שהם חולקים רכיב ECDSA משותף (מודול FIPS 214), המתואר כמרכיב אתנה OS2 ECDSA755 ב- Inside Secure AT90SC A1.0 (קושחה). בדקנו את הפגיעות רק בכרטיס אתנה IDProtect עם נתוני CPLC ו- ATR
הבעיה נגרמת על ידי היכולת לקבוע ערכי ביט בודדים במהלך הכפל בסקלר במהלך המסחר ב- ECC. נעשה שימוש בשיטות עקיפות, כמו אומדן העיכוב בביצוע חישובים, להפקת מידע מקבצים.
התקפה דורשת גישה בלתי מורשית למארח בה נוצרת החתימה הדיגיטלית (התקפה מרחוק אינה נכללת, אך היא מסובכת מאוד ודורשת כמות גדולה של נתונים לצורך ניתוח, ולכן היא יכולה להיחשב בלתי סבירה).
למרות גודלה הקטן של הדליפה, ל- ECDSA די בהגדרה של אפילו כמה סיביות עם מידע על וקטור האתחול (nonce) בכדי לבצע התקפה כדי לשחזר ברצף את המפתח הפרטי השלם.
לדברי מחברי השיטה, לצורך התאוששות מפתח מוצלחת, מספיק ניתוח של כמה מאות עד כמה אלפי חתימות דיגיטליות שנוצרו להודעות הידועות לתוקף. לדוגמה, כדי לקבוע את המפתח הפרטי המשמש בכרטיס החכם אתנה IDProtect בהתבסס על השבב Inside Secure AT90SC, תוך שימוש בעקומת האליפטית secp256r1, נותחו 11 אלף חתימות דיגיטליות. זמן ההתקפה הכולל היה 30 דקות.
קוד ההתקפה וההוכחה שלנו הם בהשראת שיטת ברומלי וטוברי.
הבעיה כבר תוקנה ב- libgcrypt 1.8.5 וב- wolfCrypt 4.1.0, פרויקטים אחרים עדיין לא יצרו עדכונים. ניתן גם לעקוב אחר תיקון הפגיעות בחבילת libgcrypt בהפצות בדפים אלה: דביאן, אובונטו, רהל, פדורה, openSUSE / SUSE, FreeBSD, קֶשֶׁת.
החוקרים בדקו גם כרטיסים וספריות אחרים, אשר הדברים הבאים אינם פגיעים מהם:
- OpenSSL 1.1.1d
- טירה קופצנית 1.58
- BoringSSL 974f4dddf
- libtomcrypt 1.18.2
- בוטן 2.11.0
- מיקרוסופט CNG
- mbedTLS 2.16.0
- אינטל IPP-Crypto
כרטיסים
- DHW ACOSJ 40K
- פייטיאן A22CR
- G&D SmartCafe 6.0
- G&D SmartCafe 7.0
- אינפיניאון CJTOP 80K INF SLJ 52GLA080AL M8.4
- אינפיניון SLE78 יוניברסל JCard
- NXP JCOP31 גרסה 2.4.1
- NXP JCOP CJ2A081
- NXP JCOP v2.4.2 R2
- NXP JCOP v2.4.2 R3
- הכספת TaiOME של SIMOME
אם אתה רוצה לדעת יותר על ההתקפה בה נעשה שימוש והפגיעויות שזוהו, תוכל לעשות זאת ב הקישור הבא. הכלים המשמשים לשכפול ההתקפה זמינים להורדה.