Puncte:3

Există o modalitate de a „eticheta” o cheie într-un mod care să împiedice reutilizarea acesteia?

drapel br

Să presupunem că am o pereche de chei publice și private asociate cu o resursă (de exemplu, un certificat TLS pentru un site web mycoolsite.com). Sunt liber să iau acele chei și să le refolosesc pentru o altă resursă (de exemplu, pentru anotherneatsite.net). Întrebarea mea este: există o modalitate eficientă de a „eticheta” cheile originale cu datele „această cheie este pentru mycoolsite.com”, astfel încât eliminarea etichetei ar invalida cheile?

Ideea ar fi să permită unui sistem de autentificare să respingă o cheie publică dacă ar fi reutilizată pentru un alt cont. Pentru a fi clar, aceasta este o întrebare generală despre sistemele de criptare cu chei publice, nu doar TLS.

kelalaka avatar
drapel in
https://sectigostore.com/page/one-ssl-certificate-for-multiple-domains/
Puncte:4
drapel in

Întrebarea mea este: există o modalitate eficientă de a „eticheta” cheile originale cu datele „această cheie este pentru mycoolsite.com”, astfel încât eliminarea etichetei ar invalida cheile?

Da, asta este practic ceea ce fac certificatele, unde poți avea un nume de domeniu în stilul X500 RDN (Relative Distinguished Name). De asemenea, este posibil să aveți extensii (critice) care conțin date suplimentare, cum ar fi numele alternativ al subiectului sau utilizarea cheii. „Critic” înseamnă că extensia nu trebuie ignorată chiar dacă extensia este necunoscută. Toate aceste date sunt semnate de CA care emite certificatul și TREBUIE să fie validate de un verificator.

Desigur, chiar și un MUST din cadrul unei proceduri de verificare a certificatului poate fi ignorat. Nu este posibilă invalidarea cheii în sine, și nu puteți forța un sistem să ignore datele trimise către acesta din exterior (cu excepția cazului în care vă sandbox sistemul presupun).

Nici nu este posibil să interziceți utilizatorului să copieze cheia publică sau să solicite un certificat în altă parte. Uneori, anumite CA-uri vor păstra un ID al cheilor în cadrul certificatelor pe care le-au semnat. În acest caz, un CA ar putea alege să ignori o solicitare de certificat cu o cheie „veche” - deși din experiența mea este mai mult despre evitarea erorilor în sistem.

Și, în sfârșit, nu este posibil să restricționați utilizarea unei chei private. Deținătorul unei chei private RSA ar putea folosi acea cheie pentru semnare sau pentru stabilirea cheii, chiar dacă informațiile certificatului indică altfel. Certificatul precizează doar pentru ce poate fi folosită perechea de chei, dar rămâne la latitudinea părții care primește, validează și are încredere în certificat să pună în aplicare acest lucru.

drapel br
Deci, lăsând deoparte sistemul social al autorităților de certificare, nu există nicio modalitate criptografică cunoscută de a lega o cheie de o informație?
Maarten Bodewes avatar
drapel in
O informație în acest caz fiind resursa în întrebarea pe care mi-o imaginez? Pentru că altfel ar deveni o altă întrebare.
drapel br
Da -- cazul de utilizare aici este un sistem în care clientul generează singur cheia fără a consulta o autoritate centralizată. Deci nu mă pot baza pe infrastructura socială de care se bucură certificatele TLS (și nu este clar că nici măcar acea infrastructură poate impune acest lucru, vezi de exemplu această situație https://koen.engineer/a-tale-of-private-key- reutilizare-8ff0cb766fa5).
knaccc avatar
drapel es
@IanH Doar pentru că aveți nevoie de un CA, nu înseamnă că aveți nevoie de un CA terță parte. Veți avea un certificat CA autosemnat pe care ați avea controlul pentru propria infrastructură. Și dacă nu doriți să utilizați deloc un CA, puteți avea doar un certificat autosemnat care restricționează utilizarea cheii publice. În esență, răspunsul la întrebarea dvs. este că trebuie să combinați câteva metadate cu cheia publică pentru a restricționa utilizarea acesteia, ceea ce face un certificat.
Puncte:1
drapel ph
jpa

O modalitate este aceasta:

  1. Clientul generează cheia privată și publică.
  2. Clientul trimite cheia publică către server.
  3. Serverul generează o cheie derivată din cheia publică a clientului și un nonce aleatoriu.
  4. Serverul trimite nonce înapoi clientului, care îl poate folosi pentru a crea o cheie privată derivată.

În acest fel, atât clientul, cât și serverul contribuie aleatoriu la cheie, astfel încât clientul nu poate alege singur o cheie de proastă calitate sau reutilizată. În același timp, serverul nu cunoaște niciodată cheia privată.

Cum se efectuează pasul 3 depinde de algoritmul utilizat. Există câteva exemple în răspunsuri la această întrebare.

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.