
Acest conținut a fost generat cu ajutorul inteligenței artificiale și publicat fără o verificare umană prealabilă. Poate conține erori și nu constituie consultanță profesională. Semnalați o problemă: info@delionsoft.com.
O echipă de la Universitatea din California, San Diego, a descris un atac care generează semnături RSA valide fără a recupera vreodată cheia privată. Conform raportului original, metoda este aplicabilă în prezent împotriva cheilor de 1024 de biți și reduce nivelul estimat de securitate al cheilor de 2048 și 4096 de biți sub nivelurile acceptate de organismele de standardizare. Cercetarea se aplică doar unei clase restrânse de implementări RSA și trebuie încă să treacă de evaluarea colegială.
Ce s-a întâmplat
Până acum, ipoteza de lucru era că spargerea RSA însemna factorizarea modulului. Lucrarea, având-o pe Laura Shea ca autoare principală și pe Nadia Heninger printre coautori, utilizează o variantă a metodei „special number field sieve” din 2007, combinată cu un oracol — un protocol care răspunde la interogările alese de atacator — pentru a falsifica semnăturile în mod direct.
Cifrele din raport reprezintă partea interesantă. Factorizarea unei chei de 1024 de biți este estimată la aproximativ 2^80 de operații și între 500.000 și 1 milion de ani-nucleu de procesor. Falsificarea a necesitat aproximativ 2^65 de operații și 1.380 de ani-nucleu, adică câteva luni pe un cluster academic. Securitatea efectivă scade la aproximativ 2^65, 2^90 și 2^119 pentru cheile de 1024, 2048 și 4096 de biți, față de o cerință de cel puțin 2^128 impusă de NSA, NIST și agenția UE. Autorii menționează că au scris totul manual, fără GPU-uri, astfel încât cifrele ar putea scădea și mai mult.
Limitarea importantă: atacul vizează semnătura oarbă (blind-signature) sau RSA „clasic” — fără umplere PKCS sau PSS. Marea majoritate a sistemelor RSA aflate în producție utilizează umplere și nu par a fi amenințate în practică. Cea mai cunoscută excepție menționată este Privacy Pass, protocolul de autentificare anonimă utilizat de Apple, Cloudflare și alții. În acest caz, un atacator ar avea nevoie de aproximativ 2^43 de cereri de tokenuri, ceea ce cercetătorii compară cu traficul înregistrat de Cloudflare într-o zi. Rotirea regulată a cheilor reduce considerabil riscul, fără a-l elimina însă complet.
De ce este important
Pentru majoritatea sistemelor IMM-urilor, acest lucru nu schimbă nimic din punct de vedere operațional în prezent. TLS, semnarea codului, semnăturile JWT și cheile SSH cu umplere standard nu sunt afectate de ceea ce a fost publicat. Ceea ce se schimbă este ipoteza care stă la baza planificării dumneavoastră: marja de securitate a unei chei RSA nu mai este definită exclusiv de dificultatea factorizării, iar o nouă clasă de atacuri a apărut într-un sistem criptografic considerat a fi bine înțeles.
Acest lucru contează din două motive practice. În primul rând, echipele care au implementat RSA fără umplere pentru semnături oarbe sau tokenuri anonime — de obicei în funcții de confidențialitate sau de limitare a ratei — se află acum într-o situație diferită față de săptămâna trecută. În al doilea rând, dacă tratați migrarea post-cuantică ca pe o problemă pentru anii 2030, acesta este un memento că și atacurile clasice pot evolua.
Ce trebuie făcut
- Inventariați unde și cum este utilizat RSA. Marcați orice element care utilizează semnături RSA brute sau „oarbe” fără umplutură PKCS#1 v1.5 sau PSS, inclusiv schemele interne de tokenuri și integrările mai vechi.
- Retrageți din uz orice chei de 1024 de biți rămase. Acestea erau deja depășite; raportul arată că falsificarea lor necesită doar un buget de calcul modest.
- Dacă operați un serviciu de semnături oarbe sau de tokenuri anonime, scurtați intervalele de rotație a cheilor și adăugați limitarea ratei de emitere a tokenurilor per client.
- Tratați agilitatea criptografică ca o cerință de proiectare în următorul ciclu al planului de dezvoltare: fixați algoritmii în configurație, nu în cod, astfel încât schimbarea schemelor de semnătură să fie o operațiune de implementare, nu o rescriere.
