înregistrare Logare
Puncte:1
avatar Crypto

Este sigur să folosiți RSA pentru a schimba cheia AES?

drapel jp
user99011

Trebuie să creez o aplicație client-server folosind Java și vreau să fac comunicarea în siguranță. M-am gândit să folosesc AES pentru a cripta mesajele și pentru schimbul de chei fac următorii pași:

  • Clientul generează chei RSA și trimite cheia publică la server
  • Serverul va cripta cheia AES cu cheia publică RSA (cheia AES este generată aleatoriu pentru fiecare client)
  • Clientul decriptează mesajul cu cheia privată RSA și apoi toate mesajele vor fi criptate cu AES

Întrebarea mea este: este o practică bună?

124
0 + 0
Swashbuckler avatar
drapel mc
Swashbuckler
Practic, ceea ce ați descris este împachetarea cheii folosind o cheie publică/privată. Se poate face și cu chei simetrice. În loc să inventați propriul mod de a face acest lucru și, eventual, să faceți o greșeală, ar trebui să luați o implementare existentă dintr-o bibliotecă cripto bună și să o utilizați.
3
Răspunde
Maarten Bodewes avatar
drapel in
Maarten Bodewes
Întrebarea adevărată este: cum vei avea încredere în cheia publică pe care o primești? Poate fi unul creat de un adversar. Aici intervine, de obicei, PKI - destul de des PKIX cu certificate X.509, așa cum este folosit de ex. browserul dvs. pentru autentificare TLS (server).
3
Răspunde
Maarten Bodewes avatar
drapel in
Maarten Bodewes
În caz contrar, da, RSA poate fi folosit pentru stabilirea cheilor, cu principalul dezavantaj că generarea perechii de chei este destul de lentă - așa că dacă doriți să utilizați o nouă pereche de chei pentru fiecare conectare pentru securitatea directă, este posibil să aveți o problemă de eficiență. Acesta este motivul pentru care se folosește în mod obișnuit (EC)DH.
1
Răspunde
kelalaka avatar
drapel in
kelalaka
Răspunde asta la întrebarea ta? [Este sigură criptarea directă RSA a cheilor AES?](https://crypto.stackexchange.com/questions/76855/is-direct-rsa-encryption-of-aes-keys-secure)
2
Răspunde
Puncte:2
avatar Crypto
drapel kr
mentallurg

Nu, nu este o practică bună.

  1. Este predispus la bărbatul din mijloc atac. Când serverul primește o cheie publică, nu știe dacă această cheie provine de la un client sau de la „omul din mijloc”. Astfel, „omul din mijloc” poate intercepta traficul dintre client și server, pentru client poate simula server, pentru server poate simula client. Astfel, întreaga comunicare va fi 1) cunoscută de MitM și 2) datele transmise în ambele direcții pot fi modificate de MitM.
  • --> Puteți evita acest lucru, dacă autentificați clienții la server sau autentificați serverul la clienți utilizând certificate de cheie publică.
  1. Este predispus la reluare atac. Să presupunem că un client trimite comanda „transfer 1000 USD în contul 123456789”. Aceasta poate fi o operațiune legitimă. Dar dacă un atacator interceptează traficul și îl retrimite într-un timp relativ scurt (astfel încât serverul încă folosește aceeași cheie pentru criptarea AES pentru acest client), atunci serverul nu va putea distinge dacă acest trafic provine de la clientul de la atacatorul și va executa comanda.Chiar dacă autentificați clienții la server sau autentificați serverul la clienți, această problemă va persista.
  • --> Îl poți evita, dacă folosești nonce.

  1. Lucrul bun: abordarea ta actuală este relativ bună secretul direct: sesiunile anterioare sunt protejate împotriva compromisurilor viitoare ale cheilor clientului sau parolelor de sesiune. Dar dacă abordați problema 1 menționată mai sus (autentificare) și începeți să utilizați aceeași cheie RSA în mai multe sesiuni, atunci veți pierde secretul direct. Dacă un atacator obține cheie privată, toate sesiunile anterioare pot fi decriptate. Pentru a o preveni, veți avea nevoie de măsuri suplimentare, de ex. efemer Schimb de chei Diffie-Hellman.

  2. Independent de toate problemele de mai sus, este important să utilizați corect RSA, așa cum a menționat @kelalaka. Vezi detalii Aici și Aici.

Astfel, poate fi mult mai sigur să utilizați implementarea TLS furnizată de Java, în loc să implementați propriul protocol.

0 + 0
drapel cn
tylo
Poate puteți adăuga: pentru TLS 1.3, comitetul de standardizare a renunțat complet la RSA pentru acordul cheie. Ce a arătat istoria atacurilor PKCS#1 și Bleichenbacher: RSA ar putea fi doar o alegere proastă pentru schimbul de chei și nu merită bătaia de cap pentru a o rezolva corect, când toate problemele sunt mult mai ușor de rezolvat atunci când utilizați alte metode
0
Răspunde
drapel romania
SEF 777
întrebarea această in alte limbi:

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.