Puncte:2

Cum este protejat schimbul de chei RSA împotriva falsificării?

drapel ec

Cheia publică este definită de (N, e) Unde N este produsul a două numere prime mari și e este ales astfel încât e.d = 1 (mod phi(N)) Unde phi(N) este funcția totient a lui Euler. e este exponentul de criptare și d este exponentul de decriptare.

Presupune X este cheia simetrică care este criptată ca c = x^e mod(N). Cum este manipularea acestui text cifrat c prevenit?

kelalaka avatar
drapel in
Acesta este manual RSA, nu îl folosim. Avem umpluturi precum PKCS#5v.1.5 și OAEP pentru criptare și PSS pentru semnătură. Lasă-mă să-ți găsesc un prost. **Ce vrei să spui mai exact prin manipulare?** [RSA OAEP este securizat Ind-CPA](https://crypto.stackexchange.com/q/35171/18298) dacă vorbești doar despre integritate, ai nevoie de MAC. Și [cel puțin aceste atacuri sunt posibile pe manualul RSA](https://crypto.stackexchange.com/q/20085/18298) pe care umpluturile le previn, totuși căptușeala nu acoperă atacurile pe canalul lateral.
Abhisek Dash avatar
drapel ec
Mă refeream la integritate. Cum este implementat MAC împreună cu RSA? Sunt conștient de implementarea MAC în cazul criptării simetrice, dar nu îmi pot imagina cum s-ar face MAC în contextul RSA și al criptării asimetrice în general.
kelalaka avatar
drapel in
Criptare-Apoi-MAC.Întrebarea dvs. este practic înșelată de acest lucru [Ar trebui să criptăm MAC-atunci sau criptăm-apoi-MAC?](https://crypto.stackexchange.com/q/202/18298) și nu folosim RSA nici măcar pentru criptare deși pot fi sigure cu căptușeală adecvată. Folosim criptare hibridă... **Ce încerci să obții?**
kelalaka avatar
drapel in
Și, fără umplutura adecvată, nu puteți preveni manualul RSA împotriva atacurilor.
Abhisek Dash avatar
drapel ec
În criptarea simetrică, integritatea mesajului este protejată de schemele pe care le-ați descris în comentariul dvs. anterior. Deci, presupunând că nu folosesc manual RSA și folosesc o schemă de umplutură adecvată, ceea ce împiedică un atacator să schimbe textul cifrat căptușit. Există ceva în schema de umplutură care împiedică manipularea textului cifrat?
kelalaka avatar
drapel in
Vedeți [Cum rezolvă PKCS 1.5 nesiguranța RSA a manualelor?](https://crypto.stackexchange.com/q/66722/18298)
Abhisek Dash avatar
drapel ec
Linkul descrie metode folosite pentru a ataca RSA, cum ar fi atacul lui Bleichenbacher. Să presupunem că atacatorul nu dorește să recupereze cheia simetrică. Tot ce vor să facă este să perturbe comunicarea. Deci atacatorul poate schimba textul cifrat căptușit. După decriptarea și eliminarea umpluturii, celălalt punct final va primi un mesaj/cheie incorectă, deoarece textul cifrat a fost modificat. Cum va ști receptorul că textul cifrat a fost manipulat? În cazul criptării simetrice, aceasta poate fi gestionată prin criptarea hash-ului mesajului cu cheia simetrică. Care este mecanismul aici?
kelalaka avatar
drapel in
nu este clar că structura de umplutură va eșua similar cu eșecul MAC?
Puncte:2
drapel in

După cum se indică în comentariile de mai jos, RSA nu este utilizat în mod obișnuit ca exponențiere modulară a unei chei simetrice. În schimb, fie cheia este criptată folosind umplutura PKCS#1 v1.5 sau - de preferință - OAEP, fie un secret partajat cu o valoare randomizată în interval $\mare[0, N\mare)$ este utilizat pentru exponentiația modulară. În acest din urmă caz, o cheie reală este derivată folosind o KDF (funcție de derivare a cheii), uneori numită și simplu „PRF” (a se vedea, de exemplu, TLS 1.2). Acesta este cunoscut sub numele de RSA-KEM.

Există, practic, două moduri prin care manipularea cheii printr-un atac de tip man-in-the-middle (MitM) poate fi evitată:

  1. stabilirea încrederii în cheia publică RSA;
  2. verificarea secretelor partajate și/sau a cheilor derivate.

Dacă partajați în prealabil și aveți încredere într-o cheie publică a unei perechi de chei statice, atunci ați avea un schimb de chei statice, adică cheia publică este de încredere, dar nu veți oferi securitate directă. Aceasta înseamnă că fiecare cheie simetrică ulterioară poate fi calculată dacă cheia privată este cunoscută de adversar.

Încrederea cheii publice poate fi stabilită în diferite moduri. Pentru o pereche de chei statice, cheia publică poate fi de încredere folosind PKI. Dacă trebuie să aveți încredere într-o cheie publică efemeră, destinatarul o poate semna cu o cheie privată care face parte dintr-o pereche de chei care este de încredere.


O altă modalitate este să verificați ulterior cheia de sesiune stabilită. Acest lucru se poate face fie explicit, fie implicit.

În verificarea explicită a secretului partajat, partea care a decriptat cheia o folosește pentru a genera un MAC peste date statice cunoscute de ambele părți și trimite MAC. Acea parte poate fi acum sigură că a fost stabilită cheia simetrică corectă.

În verificarea implicită, cheia este pur și simplu folosită pentru a trimite mesaje autentificate înainte și înapoi. Verificarea autentificării acestor pachete indică faptul că a fost stabilită cheia potrivită.


Desigur, este autentificată doar partea căreia se are încredere în cheia publică. În mod similar, dacă orice MAC este verificat, atunci asta arată doar că partea care deține cheia privată a putut decripta. Deci, dacă aveți nevoie de autentificarea părții rămase, atunci aceasta trebuie tratată separat.

În TLS, acest lucru se realizează pur și simplu prin faptul că cealaltă parte creează o semnătură care poate fi verificată. Acest lucru necesită, de asemenea, ca cheia publică a acelei perechi de chei să fie de încredere în prealabil; în cele din urmă trebuie să stabilești întotdeauna încredere în ceva înainte de a putea autentifica petrecerea.

Autentificarea clientului TLS este aproape niciodată utilizată. În schimb, este înlocuit de cadre de autentificare sau de autentificare bazată pe parolă. Sau identitatea clientului nu este deloc stabilită - până oricum nu se face o achiziție.


Rețineți că autentificarea cheilor stabilite folosind stabilirea cheilor RSA nu este diferită de stabilirea cheilor cu, de exemplu, Diffie-Hellman - deși cu acesta din urmă există două perechi de chei de luat în considerare. În cele din urmă, același tip de tehnici pot fi folosite.

Abhisek Dash avatar
drapel ec
Imaginează-ți următorul scenariu. Serverul își trimite cheia publică către client. Clientul își verifică autenticitatea utilizând PKI. Clientul criptează o cheie simetrică folosind cheia publică folosind PKCS v1.5. Un om din mijloc interceptează acest pachet și își criptează propria cheie simetrică folosind cheia publică a serverului. Va cauza asta vreo problemă?
Maarten Bodewes avatar
drapel in
Da, bun comentariu. De fapt, acesta este ceva care se poate întâmpla de ex. browsere web, de asemenea. Chestia este că clientul rămâne de obicei neautentificat (autentificarea client TLS nu este obișnuită). De obicei, aceasta nu este o problemă dacă cealaltă parte este de ex. un magazin online: clientul se autentifică folosind nume de utilizator/parolă dacă are un cont (prin conexiunea altfel securizată) și/sau își furnizează informațiile pur și simplu în timpul plății. Voi ajusta răspunsul mai târziu pentru a indica faptul că încrederea trebuie stabilită pentru oricare dintre părți - dar, desigur, cel puțin pentru partea care partajează cheia publică.
Abhisek Dash avatar
drapel ec
Cred că am înțeles. Îngrijorarea mea a fost că ce se întâmplă dacă un om din mijloc modifică textul cifrat PKCS v1.5 care conține cheia simetrică. Dar, după decriptare, este posibil ca textul simplu să nu fie compatibil cu PKCS v1.5. Presupunând că este dificil să modificați textul cifrat în așa fel încât să devină compatibil PKCS v1.5 după decriptare, PKCS v1.5 oferă un fel de cod de autentificare a mesajului pentru cheia simetrică criptată. Am dreptate să presupun asta?
Maarten Bodewes avatar
drapel in
Nu, deoarece un atacator poate pur și simplu să cripteze altceva cu cheia publică. Deci, chiar dacă această rezistență la manipulare există - și este - nu contează, atacatorul poate înlocui textul cifrat în întregime. Este posibil să *ai încredere în altă parte* numai dacă efectuează un fel de procedură de autentificare. Aceasta poate fi o operațiune cu cheie privată sau furnizarea unei fraze de acces stabilite anterior.

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.