Poate atacatorul să fure date din tabelul criptat AES fără să cunoască cheia?

Mă gândesc la o situație în care atacatorul poate fura date din tabelul criptat AES fără să cunoască cheia. Am încercat să caut pe internet, dar nu am găsit nimic despre asta (s-ar putea că nu am folosit cuvântul cheie corect), apreciez foarte mult dacă cineva poate face lumină asupra lui.

Presupunând că tabelul este criptat cu aceeași cheie, dar diferit IV:

1. Atacatorul se înscrie pentru un cont nou într-o aplicație în mod normal.
2. Aplicația creează contul și inserează un nou rând (al doilea rând din tabelul de mai jos)
3. Atacatorul a găsit cumva o vulnerabilitate în aplicație pentru a rula injecția SQL
4. Prin injecție SQL, atacatorul înlocuiește cifra rândului său cu valoarea Victimei de exemplu. aes_cipher_2 -> aes_cipher_1 și iv_2 -> iv_1
5. Atacatorul se semnează în propriul său cont
6. Atacatorul merge la pagina de profil, apoi aplicația decriptează datele Victimei (aes_cipher_1) și îi arată textul simplu.

Da, atacul din întrebare ar putea funcționa, în ipotezele menționate. Criptarea AES-CTR a câmpurilor bazei de date este nerecomandată, din acest motiv și altele.

O posibilă atenuare parțială este utilizarea criptare autentificată, de exemplu AES-GCM și inclusiv ID și Nume de utilizator câmpul din datele autentificate. Efectul net este că datele criptate (într-un Abordare câmp) modificat în orice fel, inclusiv disociat de original ID sau Nume de utilizator sau IV, va eșua decriptarea cu certitudine criptografică.

Autentificarea va crește dimensiunea criptogramei (datele dintr-un Abordare câmp) cu 12 octeți (acesta este un parametru), indiferent de dimensiunea ID și Nume de utilizator camp. Creșterea ușoară a dimensiunii poate fi atenuată prin realizarea unei părți IV a criptogramei, ceea ce este recomandabil oricum, fie doar pentru că este mai puțin probabil ca legătura dintre criptogramă și IV sa se piardă. Punerea IV-ului la începutul datelor criptate printr-un cifru bloc este oricum practica standard.

Criptarea autentificată oferă o protecție mult mai bună decât derivarea cheii AES-CTR dintr-o cheie principală și Id sau și Nume de utilizator: dacă adversarii pot reuși să schimbe datele criptate CTR și să observe comportamentul unui sistem IT asupra datelor descifrate, atunci este de teamă că pot afla ceva despre date. De exemplu, dacă octetul „<” din datele descifrate provoacă un comportament recunoscut, atunci este nevoie de aproximativ 30 de încercări pe caracter pentru a descifra; exact ca in filme. Criptarea autentificată protejează împotriva acestui lucru, cheile derivate nu.

Sunt departe de a afirma că criptarea autentificată a intrărilor confidențiale din bazele de date este sigură. Nu oferă protecție împotriva multor persoane din interior. Nici măcar nu oferă o protecție bună pentru copii de rezervă, deoarece prea des cheia va fi în backup (din acest motiv, susțin criptarea backup-urilor bazei de date cu cheie publică și criptare hibridă). Și criptarea autentificată poate fi adesea ocolită. De exemplu, cu acces de citire la o bază de date care include o parolă hashing, atacatorii ar putea adesea să monteze o căutare prin parolă care să găsească parolele unor utilizatori, apoi să se autentifice ca unul dintre acești utilizatori. Și cu acces de scriere, atacatorii ar putea schimba hash-urile parolei cu cea a unei parole pe care o cunosc și să se conecteze ca orice utilizator ales de ei.

Din nou: criptografia nu ar trebui să fie prima linie de apărare pentru o bază de date. Nu ar trebui să fie accesibil în citire, cu atât mai puțin accesibil în scriere de către atacatori.Și baza de date folosește un limbaj text pentru interogări (o greșeală de design înrădăcinată în practicile IT actuale, care a permis și permite încă nenumărate atacuri și provoacă risipă uriașă de resurse de calcul în generarea și analizarea interogărilor), apoi cel puțin un proiect atent proiectat și revizuit. Stratul software de generare de interogări trebuie să impună separarea datelor de limbajul de interogare.