Minerva: o serie de vulnerabilități în implementările ECDSA / EdDSA

Minerva

Cercetătorii Universității Masaryk au dezvăluit informații important despre vulnerabilitățile din diverse iImplementări ale algoritmului de generare a semnăturii digitale ECDSA / EdDSA, care permite recuperarea valorii cheii private pe baza analizei scurgerilor de informații pe biți individuali care apar la aplicarea metodelor de analiză prin canale terțe. Vulnerabilitățile sunt denumite în cod Minerva.

Cele mai cunoscute proiecte care afectează metoda de atac propusă sunt OpenJDK, OracleJDK (CVE-2019-2894) și biblioteca libgcrypt (CVE-2019-13627) utilizat în GnuPG. Problemele sunt susceptibil și pentru biblioteci MatrixSSL, Crypto ++, wolfCrypt, eliptic, jsrsasign, Python-ECDSA, ruby_ecdsa, fastecdsa și, de asemenea, niște carduri inteligente Athena IDProtect, Card blindat TecSec, SafeNet eToken 4300, S / A valid IDflex V.

Pe lângă vulnerabilitățile menționate în acest moment, acestea nu sunt afectate OpenSSL, Botan, mbedTLS și BoringSSL. Mozilla NSS, LibreSSL, Nettle, BearSSL, cryptlib, OpenSSL în modul FIPS. Criptarea Microsoft .NET, kernel-ul Linux libkcapi, Sodium și GnuTLS nu au fost încă testate.

Am găsit implementări care pierd lungimea de biți a scalarului în timpul multiplicării scalare în ECC. Această scurgere poate părea minusculă, deoarece lungimea bitului are o cantitate foarte mică de informații prezente în scalar. Cu toate acestea, în cazul generării de semnături ECDSA / EdDSA, filtrarea lungimii aleatorii de biți nonce este suficientă pentru recuperarea completă a cheii private folosite după observarea a câteva sute până la câteva mii de semnături în mesajele cunoscute, datorită aplicării unor tehnici .

Credem că toate cardurile anterioare sunt afectate deoarece au o componentă comună ECDSA (modulul FIPS 214), care este descrisă ca componentă Athena OS2 ECDSA755 în Inside Secure AT90SC A1.0 (Firmware). Am testat vulnerabilitatea numai pe cardul Athena IDProtect cu date CPLC și ATR

Problema este cauzată de capacitatea de a determina valorile de biți individuale în timpul multiplicării cu un scalar în timpul tranzacționării ECC. Metode indirecte, cum ar fi estimarea întârzierii în efectuarea calculelor, sunt folosite pentru a extrage informații de biți.

Un atac necesită acces fără privilegii la gazdă în care este generată semnătura digitală (nu este exclus un atac la distanță, dar este foarte complicat și necesită o cantitate mare de date pentru analiză, prin urmare poate fi considerat puțin probabil).

În ciuda dimensiunii reduse a scurgerii, pentru ECDSA, definiția chiar și a câtorva biți cu informații despre vectorul de inițializare (nonce) este suficientă pentru a efectua un atac pentru a restabili secvențial cheia privată completă.

Potrivit autorilor metodei, pentru recuperarea cu succes a cheii, este suficientă analiza a câteva sute până la câteva mii de semnături digitale generate pentru mesaje cunoscute de atacator. De exemplu, pentru a determina cheia privată utilizată în cardul inteligent Athena IDProtect pe baza cipului Inside Secure AT90SC, utilizând curba eliptică secp256r1, au fost analizate 11 mii de semnături digitale. Timpul total de atac a fost de 30 de minute.

Codul nostru de atac și dovada conceptului sunt inspirate din metoda Brumley & Tuveri.

Problema a fost deja rezolvată în libgcrypt 1.8.5 și wolfCrypt 4.1.0, alte proiecte nu au generat încă actualizări. De asemenea, este posibil să urmăriți remedierea vulnerabilității în pachetul libgcrypt din distribuțiile de pe aceste pagini: Debian, Ubuntu, RHEL, Fedora, openSUSE / SUSE, FreeBSD, Arc.

Cercetătorii au testat și alte carduri și biblioteci, dintre care următoarele nu sunt vulnerabile:

  • OpenSSL 1.1.1d
  • Castelul Bouncy 1.58
  • BoringSSL 974f4dddf
  • libtomcrypt 1.18.2
  • Boot 2.11.0
  • Microsoft CNG
  • mbedTLS 2.16.0
  • Intel IPP-Crypto

Carduri

  • ACM ACOSJ 40K
  • Feitian A22CR
  • G&D SmartCafe 6.0
  • G&D SmartCafe 7.0
  • Infineon CJTOP 80K INF SLJ 52GLA080AL M8.4
  • Infineon SLE78 Universal JCard
  • NXP JCOP31 v2.4.1
  • NXP JCOP CJ2A081
  • NXP JCOP v2.4.2 R2
  • NXP JCOP v2.4.2 R3
  • SIMOME TaiSYS Vault

Dacă doriți să aflați mai multe despre atacul utilizat și vulnerabilitățile detectate, puteți face acest lucru în următorul link. Instrumentele folosite pentru a replica atacul sunt disponibile pentru descărcare.


Lasă comentariul tău

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *

*

*

  1. Responsabil pentru date: Miguel Ángel Gatón
  2. Scopul datelor: Control SPAM, gestionarea comentariilor.
  3. Legitimare: consimțământul dvs.
  4. Comunicarea datelor: datele nu vor fi comunicate terților decât prin obligație legală.
  5. Stocarea datelor: bază de date găzduită de Occentus Networks (UE)
  6. Drepturi: în orice moment vă puteți limita, recupera și șterge informațiile.