Puncte:3

De ce este necesară o cheie efemeră pentru a dovedi posesia unei chei private statice în schemele de stabilire a cheilor

drapel br

În NIST 800-56A rev3 „Recomandare pentru schemele de stabilire a cheilor în funcție de perechi care utilizează criptografia cu logaritm discret” în secțiunea 5.6.2.2.3.2 „Destinatarul obține asigurarea [a cheii private statice] direct de la proprietarul revendicat (adică, cealaltă parte)” necesită 2 condiții care trebuie îndeplinite în timpul unei tranzacții cu acordul cheii pentru „Destinatarul cheii publice” pentru a dovedi că cealaltă parte deține cheia privată corespunzătoare. Practic, PKR trebuie să contribuie cu o cheie efemeră (condiția 1) și să confirme că cheia convenită este, de asemenea, partajată de cealaltă parte (condiția 2).

Din câte am înțeles, atâta timp cât aceste 2 condiții sunt îndeplinite, nu trebuie să verificăm în mod explicit deținerea cheii private prin alte metode, adică nu este necesară nicio provocare/răspuns suplimentar, deoarece calculele demonstrează deja posesia. Apoi listează schemele care îndeplinesc ambele condiții ca toate schemele C(1e, 2s) și C(1e, 1s), dar niciuna dintre schemele C(2e, 2s) cu cerința "trebuie angajați unul dintre următoarele”.

Adăugând la confuzie, în ipotezele schemelor C(1e, 2s), aceasta necesită ipoteza 6 „Destinatarul unei chei publice statice a obținut asigurarea că proprietarul său (revendicat) este (sau era) în posesia cheii private statice corespunzătoare. cheie, așa cum este specificat în secțiunea 5.6.2.2.3." "trebuie fi adevărat”.

Întrebările mele sunt:

  1. Calculele acordului cheii cu confirmarea cheii dovedesc, de asemenea, deținerea cheii private statice, deci nu este nevoie să puneți alte întrebări celeilalte părți, este corect?
  2. Schemele C(2e, 2s) cu confirmare bilaterală a cheii ar trebui să îndeplinească și condițiile date, nu?
  3. Mi se pare că schemele C(0e, 2s) cu confirmare bilaterală a cheii ar trebui să dovedească și deținerea cheii private statice, de ce este necesară cheia efemeră?
Puncte:2
drapel cn

Unul dintre tipurile de atacuri pe care încercăm să le prevenim aici cu astfel de mecanisme se numește „Uzurparea identității prin compromis cheie", unde o petrecere a obținut cheia dvs. privată (nu al celeilalte părți) și încearcă uzurpare identitatea altor părți pentru tine.

Acum, voi încerca să abordez diferitele tale întrebări într-o ordine diferită, deoarece are mai mult sens pentru mine și ar trebui să ajute la înțelegerea globală a condițiilor de bază:

Q.3

  1. Mi se pare că schemele C(0e, 2s) cu confirmare bilaterală a cheii ar trebui să dovedească și deținerea cheii private statice, de ce este necesară cheia efemeră?

Nu, atunci când utilizați 2 chei statice și 0 cheie efemeră, un atacator care știe doar cheia dvs. privată, dar nu cheia privată a celeilalte părți este capabil să calculeze același secret partajat ca și dvs.

Problema este oarecum ascunsă în text, de ex. în 6.3.3.3 se spune:

Finalizarea cu succes a procesului de confirmare a cheii oferă fiecărei părți asigurarea că cealaltă parte a obținut aceeași valoare secretă Z

Deci, ceea ce primești confirmare este de fapt doar asta secretul derivat este același cu al tău, dar nu că cealaltă parte și-a folosit de fapt cunoștințele despre cheia statică secretă pe care pretinde că o deține.

Deci, aici vă puteți asigura că nu există nicio Persoană din mijloc care vă modifică acordul cheie: amândoi ați obținut aceeași cheie convenită.

de ce este necesară cheia efemeră?

Deoarece este o cheie efemeră pe care tocmai am creat-o, cealaltă parte nu va ști cheia secretă efemeră corespunzătoare (presupunând că un adversar cu numai cunoașterea cheii dvs. secrete statice).
Deci, în timpul acordului de cheie, deoarece combinați cheia efemeră secretă cu cheia lor statică publică (revendicată), dacă nu își cunosc cheia statică secretă (revendicată) nu vor putea efectua aceeași derivare așa cum ați făcut folosind cheia publică efemeră pe care le-ați trimis.

Cu o cheie efemeră, iată ce se întâmplă de obicei de partea ta:

  1. combini cheia ta secretă efemeră cu cheia lor publică statică (revendicată), obții un secret $Z_e$
  2. combinați cheia dvs. secretă statică cu cheia publică statică (revendicată) a acestora, obțineți un secret $Z_s$
  3. le folosești pe amândouă $Z_e$ și $Z_s$ în procesul de derivare pentru a obține secretul final partajat $Z$
  4. utilizați un proces de confirmare a cheii pentru a vă asigura că amândoi au obținut același secret comun $Z$

Și cealaltă parte face mai mult sau mai puțin la fel, dar folosește în schimb cheia efemeră publică de-a lungul

(Acesta este un acord cheie clasic rezumat C(1e,2s).)

Acum, un adversar știind ta cheia secretă poate imita pasul 2, dar nu poate imita pasul 1, prin urmare nu poate efectua corect pasul 3 și va primi prins la pasul 4, dacă utilizați o cheie efemeră. Dar dacă nu aveți o cheie efemeră, atunci vă bazați doar pe pasul 2 din pasul 3 și, prin urmare, uzurparea identității nu este detectată la pasul 4.

Acesta este de fapt esența a ceea ce se spune în prima condiție 5.6.2.2.3.2 (sublinierea mea):

  1. Destinatarul cheii publice statice contribuie cu o cheie publică efemeră la procesul de acordare a cheii, unul care este destinat a fi combinat aritmetic cu proprietarul revendicat (adică, a celeilalte părți) cheie privată statică în calculele efectuate de proprietarul revendicat. (Dacă se utilizează o schemă adecvată de acord-cheie, proprietarul revendicat va fi provocat să demonstreze cunoștințele actuale despre cheia sa privată statică, efectuând cu succes acele calcule în timpul tranzacției.)

Aceasta înseamnă că trebuie să apară pașii 1 și 3.

Și atunci avem a doua condiție:

  1. Destinatarul cheii publice statice este, de asemenea, un destinatar de confirmare a cheii, proprietarul revendicat (adică, cealaltă parte) servind ca furnizor de confirmare a cheii. (Prin furnizarea cu succes a confirmării cheii, proprietarul revendicat poate demonstra că este proprietarul cheii publice statice primite și cunoașterea actuală a cheii private statice corespunzătoare.)

Acest lucru înseamnă practic că pasul 4 trebuie să aibă loc, oferind astfel asigurarea că procesul de derivare a cheii a fost efectuat conform așteptărilor și, astfel, asigurarea că pasul 1 nu poate fi „falsificat” de cineva care nu cunoaște cheia statică secretă a publicului static primit. cheie, ci în schimb propria ta cheie statică secretă.

Q.2

  1. Schemele C(2e, 2s) cu confirmare bilaterală a cheii ar trebui să îndeplinească și condițiile date, nu?

Da, de obicei o fac. Ele pot satisface de fapt o versiune mult mai puternică, în care obțineți și asigurarea deținerii cheii secrete efemere (revendicate). Dacă te uiți la secțiunea 5.6.2.2.4, schemele C(2e, 2s) care îndeplinesc condițiile 2 și 3 îndeplinesc în mod natural condițiile 1 și 2 din 5.6.2.2.3.2.

Observați că acolo sunt citate doar modelul DH și One Pass Unified, asta pentru că așa cum se spune în 7.1 (sublinierea mea):

Dacă o schemă MQV (MQV2 sau Full MQV) va fi folosită în timpul unei tranzacții cu un adversar care deține o cheie privată statică compromisă (sau o semnătură implicită compromisă corespunzătoare acelei chei private statice), adversarul se limitează la a se preface drept proprietarul perechii de chei compromise (sau ca proprietar al perechii de chei statice corespunzătoare semnăturii implicite compromise). Cu toate acestea, utilizarea modelului Full Unified sau a schemei dhHybrid1 oferă adversarului oportunități suplimentare de masquerading.: Dacă un adversar compromite cheia privată statică a unei entități, atunci adversarul poate fi capabil să uzurpare identitatea oricărei alte entități în timpul unei tranzacții de acord de cheie bazate pe model complet unificat sau dhHybrid1 cu acea entitate.

Schemele MQV în formele lor „două treceri” sunt deja rezistente la aceste atacuri de uzurpare prin compromitere cheie și nu necesită pasul suplimentar pe care îl fac schemele bazate pe model DH sau Full Unified, care sunt detaliate în 5.6.2.2.3.2 și 5.6.2.2.4. Acesta este probabil motivul pentru care nu sunt citate în mod explicit în 5.6.2.2.4.

Q.1

Și, în cele din urmă, cred că răspunsul la prima ta întrebare rezultă în mod natural din detaliile de mai sus:

  1. Calculele acordului cheii cu confirmarea cheii dovedesc, de asemenea, deținerea cheii private statice, deci nu este nevoie să puneți alte întrebări celeilalte părți, este corect?

Nu, nu, ar putea dovedi, de asemenea, deținerea cheii private statice. Acesta este motivul pentru care avem nevoie de pașii cheie efemeri.

drapel br
Multumesc pentru raspunsul detaliat. Dacă cineva are cheia mea privată, se poate uzurpa cu siguranță la mine, dar nu m-am gândit niciodată la posibilitatea inversă, ceea ce are sens. Înțeleg, de asemenea, de ce Unified Model nu reușește să furnizeze KCI - deoarece atacatorul își poate genera propriile chei efemere și poate calcula cu ușurință secretul - și de ce MQV reușește - deoarece atacatorul are nevoie fie de cheia privată statică a celeilalte părți, fie de cheia mea privată efemeră.
drapel br
Nu putem furniza KCI pur și simplu prin semnarea cheii publice efemere cu cheia privată statică?
drapel cn
@obareey Da, am putea, dar adăugarea unui protocol de semnătură la mix nu ar face lucrurile cu adevărat mai simple, nici din punct de vedere al analizei. De asemenea, dăunează „repudierii”, deoarece semnăturile „leagă” cheia efemeră de cheia dvs. statică pe termen lung, în timp ce o schemă bazată pe cheie efemeră nu spune care cheie a fost folosită pentru a stabili cheia convenită: ar putea fi cealaltă parte. fabricând lucruri tot timpul (nu pot dovedi că nu au făcut-o).

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.