Partea 2: Genesis of Ledger Recover – Distribuirea în siguranță a acțiunilor | Registrul mare

Bine ați revenit la a doua parte a seriei noastre de bloguri despre Ledger Recuperaregeneza lui! Scopul nostru este de a explora numeroasele obstacole tehnice întâlnite la construirea unui serviciu de recuperare a semințelor și modul în care Ledger Recover le rezolvă cu un design și o infrastructură sigure.

În partea anterioară, am examinat cum să faceți backup unei expresii de recuperare secretă prin împărțirea acesteia și cum o face Ledger Recover pentru dvs. folosind Partajare secretă verificabilă Pedersen.

Acum că aveți trei acțiuni, următoarea întrebare este: cum le puteți distribui în siguranță furnizorilor dvs. de rezervă? Într-adevăr, dacă o parte rău intenționată interceptează toate acțiunile în timp ce le transmiteți, aceasta înfrânge scopul de a împărți sămânța în primul rând. În securitatea cibernetică, aceasta se numește a Atacul de la Omul din mijloc, unde un atacator se află între tine și destinatarul tău și modifică comunicarea pentru a încerca să descopere secrete.

Când utilizați Ledger Recover, transmiterea semințelor dvs. se realizează printr-un mecanism de distribuție securizat. Se bazează pe mai multe instrumente criptografice și concepte matematice pe care le vom explica pe larg.

Vom începe prin a descrie problema în detaliu. Apoi, vom introduce mai multe instrumente criptografice și concepte matematice pe care Ledger Recover le folosește pentru a distribui în siguranță acțiunile dvs. de bază către furnizorii de backup.

Courier-In-The-Middle: Un exemplu real

Cel mai evident mod de a te proteja de un intermediar rău intenționat este să nu ai deloc. Puteți merge singur la casele prietenilor dvs. sau puteți să-i adunați în aceeași locație închisă pentru a livra acțiunile. Dar acest lucru devine mult mai greu dacă nu ești colocat și vrei să trimiți acțiunile unei cunoștințe de la distanță.

Presupunând că rețeaua prin care comunicăm (de exemplu, serviciul poștal) este în mod inerent nedemn de încredere, cum putem garanta că interceptatorii nu vor vedea niciodată acțiunile noastre secrete?

Este timpul să îi prezentăm pe Alice și Bob și pe infama Eve, trei personaje de criptografie bine-cunoscute. Alice are un secret pe care vrea să-l împărtășească cu Bob și nu are de ales decât să-l trimită prin Eve, curierul lor de neîncredere. În cuvinte criptografice, Alice și Bob vor să stabilească un canal de comunicare sigur unul cu celălalt pentru a-și schimba secretul în siguranță.

Iată ce ar putea face Alice și Bob:

• Alice își pune secretul într-o cutie, îl încuie cu lacătul personal, înainte de a-l trimite lui Bob.
• Când Bob primește cutia, adaugă propriul său lacăt și îl trimite înapoi.
• Alice își poate folosi acum cheia pentru a-și scoate lacătul din cutie înainte de a-l trimite pentru ultima dată.
• Pentru a termina procesul, Bob își folosește pur și simplu cheia pentru a-și scoate lacătul și pentru a recupera – în cele din urmă – secretul de la Alice.

Pe tot parcursul schimbului, ori de câte ori Eve a avut cutia în mâini, aceasta a fost întotdeauna protejată, fie de lacătul lui Alice, fie de cel al lui Bob, fie de ambele.

Deși acesta este un început excelent, mai rămân câteva probleme de rezolvat în acest scenariu:

• Autentificare reciprocă: Alice și Bob au nevoie de modalități sigure pentru a verifica dacă fiecare lacăt provine cu adevărat de la cealaltă parte. În caz contrar, Eve ar putea să-l schimbe cu propria ei cutie și lacăt și să o păcălească pe Alice sau pe Bob să creadă că ea este cealaltă parte.
• Secretul direct: Dacă Eve a furat cutia încuiată și mai târziu a furat cheia lui Alice sau lui Bob, ea ar putea recupera secretul inițial. În schimb, dorim să ne asigurăm că scurgerile viitoare de chei pe termen lung nu pot compromite pachetele mai vechi furate.
• Păstrarea confidențialității: În acest scenariu, adresele lui Alice și Bob sunt dezvăluite curierului. În echivalentul digital al acestui proces, dorim un protocol care să nu dezvăluie nimic despre destinatari.

Securizarea mesajelor digitale

În securitatea digitală, a canal securizat este o modalitate de a transfera date între doi autentificata părțile astfel încât datele confidențialitate și integritate sunt garantate. Atunci când utilizați un canal securizat, atacatorii nu pot intercepta sau modifica comunicarea dvs.

Protocolul Ledger Recover atât pentru backup, cât și pentru restaurare se bazează pe a Protocolul de canal securizat, sau SCP. Folosește mai multe instrumente ale cutiei de instrumente moderne de criptare, cum ar fi criptarea simetrică și asimetrică, certificatele și semnăturile digitale.
Următoarele secțiuni vă vor oferi o introducere rapidă asupra tuturor acestor concepte, ceea ce vă va permite să înțelegeți întreaga schemă de securitate utilizată în Ledger Recover.

Criptografia simetrică: un instrument puternic, dar limitat

Pentru a garanta confidențialitatea datelor schimbate între două părți, datele sunt de obicei criptate și decriptate cu aceeași cheie secretă.
Acest proces este denumit criptografie simetrică, care este studiul primitivelor care implică o singură cheie secretă pentru a garanta una sau mai multe dintre proprietățile unui canal securizat.

Deși este un instrument puternic pentru a vă proteja comunicațiile, criptografia simetrică are câteva limitări evidente: Să presupunem că Alice dorește să schimbe mai multe mesaje criptate cu Bob. Ea alege mai întâi o cheie secretă, apoi o împărtășește lui Bob, înainte de a începe să trimită mesaje.
Bineînțeles că problema devine acum: Cum partajează Alice cheia secretă în siguranță cu Bob? Dacă cineva pune mâna pe cheie, comunicarea lui Alice și Bob nu va mai fi confidențială.
Alice l-ar putea întâlni pe Bob în persoană pentru a-i da cheia, dar, în acest caz, de ce să nu aibă discuția lor, departe de urechile indiscrete?

Pentru comunicațiile digitale, avem nevoie de o metodă sigură pentru a partaja cheia simetrică și a iniția schimbul de date protejate. Este timpul să prezentăm munca a doi titani ai criptografiei moderne, Whitfield Diffie și Martin Hellman.

Criptografia asimetrică: ascunderea părților personale

Acordul cheie Diffie-Hellman

Cu Public Key Cryptography, Diffie și Hellman au venit cu o abordare nouă pentru securizarea comunicațiilor. Ei au definit un protocol cu ​​două chei distincte pentru criptare și decriptare. Cele două taste sunt numite în mod obișnuit chei publice și private, formând o pereche care poate fi folosită pentru a cripta/decripta și semna/verifica datele.

Chei publice și private
Criptografia cu cheie publică este baza majorității securității noastre digitale. Este folosit pentru a vă proteja pe web și este, de asemenea, modul în care dovediți deținerea monedelor și jetoanelor pe toate blockchain-urile publice.

Aflați mai multe despre acest subiect pe Ledger Academy!

Ceea ce este cu adevărat convingător pentru noi este modul în care Diffie și Hellman au sugerat utilizarea criptografiei cu chei publice pentru a distribui cheile simetrice. Metoda lor, cunoscută ca Schimb de chei Diffie-Hellman, constă în schimburi dus-întors între două părți pentru a conveni în cele din urmă asupra unui secret comun. Dacă sunt efectuate corect, interlocutorii nu sunt capabili să calculeze același secret comun din informațiile pe care le aud.

TL;DR este că, în diagrama de mai sus, Eve este incapabilă din punct de vedere matematic să descopere secretul k chiar dacă are acces la toate comunicările lui Alice și Bob. Pentru a înțelege de ce acest secret împărtășit este ferit de orice interceptare, trebuie să cercetăm puțin teoria grupului. 

Securitatea schimbului de chei Diffie-Hellman se bazează pe complexitatea problemei logaritmului discret asupra unui grup ciclic. Un grup ciclic este un grup generat de un singur element.
Pe scurt, Alice și Bob execută următorii pași pentru a conveni asupra unui secret comun k:

1. Alice și Bob sunt de acord asupra unui grup ciclic G de ordine n generat de un element g
2. Alice extrage la întâmplare un număr 0 < a < n și trimite pa = ga ∈ G lui Bob
3. Bob trage un număr la întâmplare 0 < b < n și trimite pb = gb ∈ G lui Alice
4. Alice calculează secretul partajat k =(pb )a ∈ G
5. Bob calculează secretul partajat k =(pa )b ∈ G

Securitatea protocolului depinde de duritatea găsirii k =gab dat g, ga, gb. Aceasta se numește Calcul ipoteza Diffie-Hellman (CDH). Ipoteza că CDH este greu de rezolvat presupune că problema logaritmului discret este greu de rezolvat.

În această schemă, deși secretul partajat este protejat de interceptări, nu există nicio garanție cu privire la originea datelor care sunt schimbate. Pentru ca interacțiunea să fie sigură, Alice și Bob trebuie să-și demonstreze cumva identitatea unul altuia.

Autentificare reciprocă și semnătură digitală

O semnătură de mână este de obicei folosită pentru a recunoaște și accepta conținutul unui document. Doar semnatarul poate produce semnătura, dar oricine „știe” cum arată semnătura poate verifica dacă documentul a fost semnat de persoana potrivită.

Deși are proprietăți similare, o semnătură digitală oferă garanții puternice suplimentare prin valorificarea criptografiei asimetrice:

• Autenticitate: oricine poate verifica dacă mesajul a fost semnat cu cheia privată corespunzătoare cheii publice specificate.
• Non-repudierea: semnatarul nu poate nega că a semnat și trimis mesajul.
• Integritate: mesajul nu a fost modificat în timpul transmiterii.

Acum, atâta timp cât cunoaștem și avem încredere în cheia publică a corespondentului nostru, putem verifica autenticitatea tuturor mesajelor prin verificarea semnăturii lor digitale.
Cu toate acestea, în majoritatea cazurilor din lumea reală, fie nu ne cunoaștem îndeaproape corespondentul, fie ar putea fi nevoie să-și schimbe regulat perechea de chei private/publice din motive de securitate. Acest lucru necesită un nivel suplimentar de verificare și încredere sub formă de certificate, care conțin descrierea unei entități și cheia publică a acesteia.

Fiecare certificat este semnat de o cheie publică părinte. Având o autoritate de certificare rădăcină (sau CA rădăcină) în care avem întotdeauna încredere, putem crea un lanț de încredere folosind semnături digitale succesive.

Curbe eliptice: criptografia cu cheie publică de nivel următor

Criptografia cu curbe eliptice (ECC) este o subdomenie a Criptografiei cu chei publice care constă în utilizarea curbelor eliptice pentru aplicații criptografice, de exemplu pentru scheme de criptare sau semnătură. 
Bazat pe matematica înțeleasă în prezent, ECC oferă o bază mult mai sigură decât sistemele anterioare de criptare cu cheie publică, cum ar fi RSA.

Cu același nivel de securitate, ECC implică lungimi de chei mai mici în comparație cu alte criptosisteme asimetrice, ceea ce îl face o alegere bună pentru sistemele încorporate cu resurse limitate.
Dacă doriți să aflați mai multe, acest articol poate ajuta la o mai bună înțelegere a curbelor eliptice.

Ordinea unei curbe eliptice
Ordinea unui element g al unui grup este un parametru important al schimbului de chei Diffie-Hellman. Când grupul este o curbă eliptică, acel element este un punct, iar ordinea lui este de câte ori poate fi adăugat la el însuși înainte de a face buclă în jurul valorii sale inițiale.
Rețineți că această adunare nu are nimic de-a face cu suma dvs. obișnuită asupra numerelor reale, dar are proprietăți similare de aditivitate.

Să luăm curba eliptică E: da2 =x3 +2x +3 peste câmp 𝔽97 ca exemplu. Ca funcție discretă, este reprezentată de punctele din figura de mai jos. Ne vom concentra asupra subiectului P =(3, 6) și toți multiplii săi.

Vedem că după 5.P, ne-am întors la început și am lovit aceleași puncte ca înainte. Indiferent de valoarea scalarului P este înmulțit cu, vom atinge întotdeauna unul dintre cele 5 puncte inițiale ale noastre.
Astfel ordinul de P este 5, iar subgrupul pe care îl generează conține exact 5 puncte. Pentru aplicațiile criptografice, totuși, ordinea este mult mai mare decât 5, crescând aleatorietatea.

Îmbrăcați totul: ECDH cu autentificare

Acum avem toate instrumentele de care avem nevoie pentru a crea un protocol excelent de schimb de chei:  Curba eliptică Diffie-Hellman (ECDH).

ECDH este o schemă criptografică standardizată care implementează schimbul de chei Diffie-Hellman pe care l-am descris mai sus, utilizând criptografia cu curbă eliptică pentru a genera perechile de chei și secretul partajat.

Începe prin selectarea unei curbe eliptice și a punctului său generator. Cele două părți fac apoi schimb de certificate de încredere, ceea ce le permite să verifice autenticitatea cheilor publice respective. Odată autentificați, pot genera un secret k partajat care este calculat ca:

k = dA . dB . G
dA: Cheia privată a lui Alice
dB: Cheia privată a lui Bob
G: Punct CE

Pentru a realiza secretul direct proprietate, perechea de chei atât a lui Alice cât și a lui Bob ar trebui să fie efemeră, adică sunt generate pe loc și utilizate pentru o singură execuție a protocolului. Vorbim despre o curbă eliptică Diffie-Hellman Ephemeral (ECDHE). În acest scenariu, cheile efemere semnate atât de cheile statice de pe dispozitiv, cât și de HSM-uri, permițând o autentificare puternică a cheilor. Chiar dacă accesul neautorizat la cheile statice ar avea loc în viitor, acesta nu ar acorda capabilități de decriptare pentru schimburile protejate de cheile efemere.

În plus, am implementat o îmbunătățire notabilă a protocolului prin ascunderea cheilor statice ale dispozitivelor în canalul securizat. Această măsură de precauție împiedică atacatorii să obțină vizibilitate pe certificatul static al dispozitivelor, ceea ce, la rândul său, ar putea duce la scurgerea de identificatori unici utilizați în timpul operațiunilor de backup/restaurare.

Înapoi la Ledger Recover: Călătoria unei semințe

Bine, este timpul să facem o pauză de un minut.

Am acoperit o mulțime de subiecte, care țin atât de securitate, cât și de matematică, iar rezultatul este un protocol pentru a comunica în siguranță prin orice rețea nesigură. Să rezumam ceea ce am văzut până acum:

Două entități pot avea o comunicare securizată printr-un canal nesecurizat prin acordul asupra unui secret unic mulțumită ECDHE, care este o implementare a protocolului de acord cheie Diffie-Hellman care utilizează chei efemere pentru a proteja secretul direct. Fiecare entitate este capabilă verifica autenticitatea a corespondentului lor datorită unei inițiale Verificarea certificatului.

În cazul Ledger Recover, am stabilit patru canale securizate utilizând protocolul Secure Channel. Aceste canale conectează dispozitivul la fiecare dintre furnizorii de backup și la orchestrator, toate fiind echipate cu module de securitate hardware (HSM).

Fiecare actor își păstrează certificatul personal, semnat de un Certificat Ledger care acționează ca rădăcină a lanțului de încredere. Când dispozitivul utilizatorului transmite pentru prima dată intenția sa de a efectua o copie de rezervă către Orchestrator, acesta inițiază un ECDHE autentificat. Sub acestea mTLS sesiuni, Orchestratorul transmite informații care vor lega viitoarele canale securizate de cererea de rezervă particulară a utilizatorului, împreună cu identitatea utilizatorului care va fi solicitată pentru validare atunci când se efectuează o restaurare ulterioară a semințelor.

Totul este pregătit pentru a efectua în sfârșit partea cea mai critică a întregii operațiuni: transmiterea celor trei părţi din sămânţa utilizatorului.

Încă o dată, creăm noi canale securizate, dar de data aceasta între dispozitivul Ledger al utilizatorului și HSM-urile furnizorilor de backup. direct. Cotele de semințe sunt transmise într-un canal criptat end-to-end către locul lor final de stocare, garantând în același timp că ajung la destinația corectă (aici este în cazul în care verificabilitatea Partajării secrete Pedersen a fost introdusă în parte 1 e folositor).
Dispozitivul utilizatorului autentifică HSM-urile Furnizorilor de Backup unul câte unul, iar Furnizorii de Backup știu că fac schimb cu dispozitivul Ledger oficial unic care a inițiat această solicitare specifică de backup.
Nimeni, în afară de dispozitivul utilizatorului și HSM-urile furnizorilor de backup, nu va vedea vreodată partajele de început criptate de cheile simetrice ale acestor canale securizate autentificate reciproc, nici măcar Orchestrator.

Primit în siguranță... și stocat?

În această parte, am introdus câteva concepte noi, dintre care unele sunt destul de tehnice. Fiecare dintre aceste concepte este necesar pentru a stabili o transmisie sigură care să garanteze confidențialitatea și integritatea schimbului. Indiferent de siguranța rețelei, acum putem trimite acțiunile noastre secrete fără teama că ar putea fi manipulate sau interceptate. Acesta este un upgrade!

Întregul proces este susținut de criptografie de sunet și hardware securizat, sub forma dispozitivului dvs. hardware Ledger și a HSM-urilor deținute de fiecare furnizor de backup.

Acum este timpul să trecem la recuperarea cotelor de semințe! Tot ce trebuie să facem este să cerem furnizorilor de backup să ne trimită înapoi acțiunile pe care le stochează în infrastructura lor...

Dar așteptați: cum stochează exact aceste date foarte sensibile? Nu ne-ar ajuta la nimic dacă am avea cele mai sigure canale de comunicare, dar furnizorii noștri de rezervă păstrau doar acțiunile în text simplu, implorând să fie furați.

Deci, înainte de a vorbi despre recuperare – vom ajunge acolo, promit! –, trebuie să facem un ocol rapid în partea 3 pentru a discuta despre securitatea cotelor noastre de semințe în repaus. Rămâneţi aproape!

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• PlatoData.Network Vertical Generative Ai. Împuterniciți-vă. Accesați Aici.
• PlatoAiStream. Web3 Intelligence. Cunoștințe amplificate. Accesați Aici.
• PlatoESG. Automobile/VE-uri, carbon, CleanTech, Energie, Mediu inconjurator, Solar, Managementul deșeurilor. Accesați Aici.
• BlockOffsets. Modernizarea proprietății de compensare a mediului. Accesați Aici.
• Sursa: https://www.ledger.com/blog/part-2-genesis-of-ledger-recover-securely-distributing-the-shares