Nu este un secret pentru nimeni că unul dintre instrumentele auxiliare utilizate în mod obișnuit, fără de care protecția datelor în rețelele deschise este imposibilă, este tehnologia certificatelor digitale. Cu toate acestea, nu este un secret pentru nimeni că principalul dezavantaj al tehnologiei este încrederea necondiționată în centrele care eliberează certificate digitale. Directorul de Tehnologie și Inovare la ENCRY Andrey Chmora a propus o nouă abordare a organizării Infrastructură de cheie publică (Infrastructură de cheie publică, PKI), care va ajuta la eliminarea deficiențelor actuale și care utilizează tehnologia registrului distribuit (blockchain). Dar mai întâi lucrurile.
Dacă sunteți familiarizat cu modul în care funcționează actuala infrastructură a cheii publice și cunoașteți principalele deficiențe ale acesteia, puteți trece mai departe la ceea ce vă propunem să modificăm mai jos.
Ce sunt semnăturile și certificatele digitale?Interacțiunea pe Internet implică întotdeauna transferul de date. Cu toții avem interes să ne asigurăm că datele sunt transmise în siguranță. Dar ce este securitatea? Cele mai căutate servicii de securitate sunt confidențialitatea, integritatea și autenticitatea. În acest scop, în prezent sunt utilizate metode de criptografie asimetrică sau criptografia cu cheie publică.
Să începem cu faptul că, pentru a folosi aceste metode, subiecții de interacțiune trebuie să aibă două chei individuale împerecheate - publică și secretă. Cu ajutorul lor se asigură serviciile de securitate pe care le-am menționat mai sus.
Cum se realizează confidențialitatea transferului de informații? Înainte de a trimite date, abonatul care trimite criptează (transformă criptografic) datele deschise folosind cheia publică a destinatarului, iar destinatarul decriptează textul cifrat primit folosind cheia secretă împerecheată.
Cum se realizează integritatea și autenticitatea informațiilor transmise? Pentru a rezolva această problemă, a fost creat un alt mecanism. Datele deschise nu sunt criptate, dar rezultatul aplicării funcției hash criptografice - o imagine „comprimată” a secvenței de date de intrare - este transmis în formă criptată. Rezultatul unui astfel de hashing se numește „rezumat” și este criptat folosind cheia secretă a abonatului care trimite („martorul”). Ca rezultat al criptării rezumatului, se obține o semnătură digitală. Acesta, împreună cu textul clar, este transmis abonatului destinatar („verificator”). El decriptează semnătura digitală de pe cheia publică a martorului și o compară cu rezultatul aplicării unei funcții hash criptografice, pe care verificatorul o calculează independent pe baza datelor deschise primite. Dacă se potrivesc, aceasta indică faptul că datele au fost transmise într-o formă autentică și completă de către abonatul expeditor și nu au fost modificate de către un atacator.
Majoritatea resurselor care lucrează cu date personale și informații de plată (bănci, companii de asigurări, companii aeriene, sisteme de plată, precum și portaluri guvernamentale, cum ar fi serviciul fiscal) utilizează în mod activ metode de criptare asimetrică.
Ce legătură are un certificat digital cu el? E simplu. Atât primul, cât și cel de-al doilea proces implică chei publice și, întrucât joacă un rol central, este foarte important să ne asigurăm că cheile aparțin efectiv expeditorului (martorului, în cazul verificării semnăturii) sau destinatarului și nu sunt înlocuite cu cheile atacatorilor. Acesta este motivul pentru care există certificate digitale pentru a asigura autenticitatea și integritatea cheii publice.
Notă: autenticitatea și integritatea cheii publice este confirmată exact în același mod ca și autenticitatea și integritatea datelor publice, adică folosind o semnătură digitală electronică (EDS).
De unde provin certificatele digitale?Autoritățile de certificare de încredere sau autoritățile de certificare (CA) sunt responsabile pentru emiterea și menținerea certificatelor digitale. Solicitantul solicită eliberarea unui certificat de la CA, este supus identificării la Centrul de Înregistrare (CR) și primește un certificat de la CA. CA garantează că cheia publică din certificat aparține exact entității pentru care a fost emisă.
Dacă nu confirmați autenticitatea cheii publice, atunci un atacator în timpul transferului/stochării acestei chei o poate înlocui cu propria sa. Dacă înlocuirea a avut loc, atacatorul va putea să decripteze tot ceea ce abonatul expeditor transmite abonatului care îl primește sau să modifice datele deschise la propria discreție.
Certificatele digitale sunt folosite oriunde este disponibilă criptografia asimetrică. Unul dintre cele mai comune certificate digitale este certificatele SSL pentru comunicarea sigură prin protocolul HTTPS. Sute de companii înregistrate în diferite jurisdicții sunt implicate în emiterea certificatelor SSL. Ponderea principală revine cinci până la zece centre mari de încredere: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA și CR sunt componente ale PKI, care include, de asemenea:
- Deschide directorul – o bază de date publică care asigură stocarea în siguranță a certificatelor digitale.
- Lista de revocare a certificatelor – o bază de date publică care asigură stocarea în siguranță a certificatelor digitale ale cheilor publice revocate (de exemplu, din cauza compromiterii unei chei private asociate). Subiecții din infrastructură pot accesa în mod independent această bază de date sau pot folosi protocolul specializat de stare de certificare online (OCSP), care simplifică procesul de verificare.
- Utilizatori de certificate – subiecții PKI deserviți care au încheiat un acord de utilizare cu CA și verifică semnătura digitală și/sau criptează datele pe baza cheii publice din certificat.
- Urmaritori – subiecții PKI deserviți care dețin o cheie secretă asociată cu cheia publică din certificat și care au încheiat un acord de abonat cu CA. Abonatul poate fi simultan utilizator al certificatului.
Astfel, entitățile de încredere ale infrastructurii cu chei publice, care includ CA, CR și directoare deschise, sunt responsabile pentru:
1. Verificarea autenticității identității solicitantului.
2. Profilarea certificatului de cheie publică.
3. Eliberarea unui certificat de cheie publică pentru un solicitant a cărui identitate a fost confirmată în mod sigur.
4. Modificați starea certificatului de cheie publică.
5. Furnizarea de informații despre starea curentă a certificatului de cheie publică.
Dezavantajele PKI, care sunt acestea?Defectul fundamental al PKI este prezența entităților de încredere.
Utilizatorii trebuie să aibă încredere necondiționată în CA și CR. Dar, după cum arată practica, încrederea necondiționată este plină de consecințe grave.
În ultimii zece ani, au existat mai multe scandaluri majore în acest domeniu legate de vulnerabilitatea infrastructurii.
— în 2010, malware-ul Stuxnet a început să se răspândească online, semnat folosind certificate digitale furate de la RealTek și JMicron.
- În 2017, Google a acuzat Symantec că a emis un număr mare de certificate falsificate. La acea vreme, Symantec era una dintre cele mai mari CA-uri în ceea ce privește volumele de producție. În browserul Google Chrome 70, suportul pentru certificatele emise de această companie și de centrele sale afiliate GeoTrust și Thawte a fost oprit înainte de 1 decembrie 2017.
CA-urile au fost compromise și, în consecință, toată lumea a avut de suferit – CA-urile înșiși, precum și utilizatorii și abonații. Încrederea în infrastructură a fost subminată. În plus, certificatele digitale pot fi blocate în contextul conflictelor politice, ceea ce va afecta și funcționarea multor resurse. Tocmai de asta se temea în urmă cu câțiva ani în administrația prezidențială rusă, unde în 2016 au discutat despre posibilitatea creării unui centru de certificare de stat care să elibereze certificate SSL site-urilor de pe RuNet. Starea actuală a lucrurilor este de așa natură încât chiar și portalurile de stat din Rusia certificate digitale emise de companiile americane Comodo sau Thawte (o subsidiară a Symantec).
Există o altă problemă - întrebarea autentificarea primară (autentificarea) utilizatorilor. Cum se identifică un utilizator care a contactat CA cu o solicitare de eliberare a unui certificat digital fără contact personal direct? Acum acest lucru se rezolvă situațional, în funcție de capacitățile infrastructurii. Ceva este preluat din registrele deschise (de exemplu, informații despre persoane juridice care solicită certificate); în cazurile în care solicitanții sunt persoane fizice, se pot folosi birouri bancare sau oficii poștale, unde identitatea acestora este confirmată cu ajutorul documentelor de identificare, de exemplu, un pașaport.
Problema falsificării acreditărilor în scopul uzurparei identității este una fundamentală. Să remarcăm că nu există o soluție completă la această problemă din motive teoretice informaționale: fără a avea informații fiabile a priori, este imposibil să se confirme sau să infirme autenticitatea unui anumit subiect. De regulă, pentru verificare este necesară prezentarea unui set de documente care să ateste identitatea solicitantului. Există multe metode de verificare diferite, dar niciuna dintre ele nu oferă o garanție deplină a autenticității documentelor. În consecință, nici autenticitatea identității solicitantului nu poate fi garantată.
Cum pot fi eliminate aceste neajunsuri?Dacă problemele PKI în starea sa actuală pot fi explicate prin centralizare, atunci este logic să presupunem că descentralizarea ar ajuta la eliminarea parțială a deficiențelor identificate.
Descentralizarea nu implică prezența unor entități de încredere – dacă creați infrastructură descentralizată cu cheie publică (Infrastructură cu cheie publică descentralizată, DPKI), atunci nu sunt necesare nici CA, nici CR. Să renunțăm la conceptul de certificat digital și să folosim un registru distribuit pentru a stoca informații despre cheile publice. În cazul nostru, numim un registru o bază de date liniară constând din înregistrări individuale (blocuri) legate folosind tehnologia blockchain. În locul unui certificat digital, vom introduce conceptul de „notificare”.
Cum va arăta procesul de primire, verificare și anulare a notificărilor în DPKI propus:
1. Fiecare solicitant depune o cerere de notificare independent prin completarea unui formular în timpul înregistrării, după care creează o tranzacție care este stocată într-un pool specializat.
2. Informațiile despre cheia publică, împreună cu detaliile proprietarului și alte metadate, sunt stocate într-un registru distribuit, și nu într-un certificat digital, de a cărui eliberare într-o PKI centralizată este responsabilă CA.
3. Verificarea autenticității identității solicitantului se realizează ulterior prin eforturile comune ale comunității de utilizatori DPKI, și nu de către CR.
4. Numai proprietarul unei astfel de notificări poate schimba starea unei chei publice.
5. Oricine poate accesa registrul distribuit și poate verifica starea curentă a cheii publice.
Notă: verificarea comunitară a identității unui solicitant poate părea nesigură la prima vedere. Dar trebuie să ne amintim că în zilele noastre toți utilizatorii de servicii digitale lasă inevitabil o amprentă digitală, iar acest proces va continua doar să câștige avânt. Registre electronice deschise ale persoanelor juridice, hărți, digitizarea imaginilor de teren, rețele sociale - toate acestea sunt instrumente disponibile publicului. Ele sunt deja folosite cu succes în timpul investigațiilor atât de către jurnaliști, cât și de către agențiile de aplicare a legii. De exemplu, este suficient să ne amintim de investigațiile Bellingcat sau ale echipei mixte de investigații JIT, care studiază circumstanțele prăbușirii Boeing-ului malaezian.
Deci, cum ar funcționa în practică o infrastructură cu cheie publică descentralizată? Să ne oprim pe descrierea tehnologiei în sine, pe care noi brevetat în 2018 și pe bună dreptate îl considerăm know-how-ul nostru.
Imaginează-ți că există un proprietar care deține multe chei publice, unde fiecare cheie este o anumită tranzacție care este stocată în registru. În absența unui CA, cum puteți înțelege că toate cheile aparțin acestui proprietar? Pentru a rezolva această problemă, se creează o tranzacție zero, care conține informații despre proprietar și portofelul acestuia (din care se debitează comisionul pentru plasarea tranzacției în registru). Tranzacția nulă este un fel de „ancoră” la care se vor atașa următoarele tranzacții cu date despre cheile publice. Fiecare astfel de tranzacție conține o structură de date specializată, sau cu alte cuvinte, o notificare.
Notificarea este un set structurat de date constând din câmpuri funcționale și care includ informații despre cheia publică a proprietarului, a căror persistență este garantată prin plasarea într-una dintre înregistrările asociate ale registrului distribuit.
Următoarea întrebare logică este cum se formează o tranzacție zero? Tranzacția nulă - ca și cele ulterioare - este o agregare a șase câmpuri de date. În timpul formării unei tranzacții zero, este implicată perechea de chei a portofelului (chei publice și secrete asociate). Această pereche de chei apare în momentul în care utilizatorul își înregistrează portofelul, din care se va debita comisionul pentru plasarea unei tranzacții zero în registru și, ulterior, operațiunile cu notificări.
După cum se arată în figură, un rezumat al cheii publice de portofel este generat prin aplicarea secvenţială a funcţiilor hash SHA256 şi RIPEMD160. Aici RIPEMD160 este responsabil pentru reprezentarea compactă a datelor, a căror lățime nu depășește 160 de biți. Acest lucru este important deoarece registrul nu este o bază de date ieftină. Cheia publică în sine este introdusă în al cincilea câmp. Primul câmp conține date care stabilesc o conexiune cu tranzacția anterioară. Pentru o tranzacție zero, acest câmp nu conține nimic, ceea ce îl deosebește de tranzacțiile ulterioare. Al doilea câmp este datele pentru verificarea conectivității tranzacțiilor. Pentru concizie, vom numi datele din primul și al doilea câmp „link” și, respectiv, „verificare”. Conținutul acestor câmpuri este generat prin hashing iterativ, așa cum se demonstrează prin legarea celei de-a doua și a treia tranzacții din figura de mai jos.
Datele din primele cinci câmpuri sunt certificate printr-o semnătură electronică, care este generată folosind cheia secretă a portofelului.
Asta este, tranzacția nulă este trimisă la pool și după verificarea cu succes este introdusă în registru. Acum puteți „lega” următoarele tranzacții la acesta. Să luăm în considerare modul în care se formează alte tranzacții decât zero.
Primul lucru care v-a atras probabil atenția este abundența perechilor de chei. Pe lângă perechea de chei deja familiară pentru portofel, sunt utilizate perechi de chei obișnuite și de serviciu.
O cheie publică obișnuită este ceea ce a început totul. Această cheie este implicată în diverse proceduri și procese care se desfășoară în lumea exterioară (bancare și alte tranzacții, flux de documente etc.). De exemplu, o cheie secretă dintr-o pereche obișnuită poate fi folosită pentru a genera semnături digitale pentru diverse documente - ordine de plată etc., iar o cheie publică poate fi folosită pentru a verifica această semnătură digitală cu executarea ulterioară a acestor instrucțiuni, cu condiția ca este valabil.
Perechea de servicii este emisă subiectului DPKI înregistrat. Numele acestei perechi corespunde scopului ei. Rețineți că la formarea/verificarea unei tranzacții zero, cheile de serviciu nu sunt utilizate.
Să clarificăm din nou scopul tastelor:
- Cheile de portofel sunt folosite pentru a genera/verifica atât o tranzacție nulă, cât și orice altă tranzacție nenulă. Cheia privată a unui portofel este cunoscută numai de proprietarul portofelului, care este și proprietarul multor chei publice obișnuite.
- O cheie publică obișnuită este similară ca scop cu o cheie publică pentru care este emis un certificat într-o PKI centralizată.
- Perechea de chei de serviciu aparține DPKI. Cheia secretă este emisă entităților înregistrate și este utilizată la generarea semnăturilor digitale pentru tranzacții (cu excepția tranzacțiilor zero). Public este folosit pentru a verifica semnătura digitală electronică a unei tranzacții înainte ca aceasta să fie publicată în registru.
Astfel, există două grupuri de chei. Primul include chei de serviciu și chei de portofel - au sens doar în contextul DPKI. Al doilea grup include chei obișnuite - domeniul lor poate varia și este determinat de sarcinile aplicației în care sunt utilizate. În același timp, DPKI asigură integritatea și autenticitatea cheilor publice obișnuite.
Notă: Perechea de chei de serviciu poate fi cunoscută de diferite entități DPKI. De exemplu, poate fi la fel pentru toată lumea. Din acest motiv, atunci când se generează semnătura fiecărei tranzacții diferite de zero, sunt utilizate două chei secrete, dintre care una este cheia portofelului - este cunoscută numai de proprietarul portofelului, care este și proprietarul multor chei obișnuite. chei publice. Toate cheile au propriul lor sens. De exemplu, este întotdeauna posibil să se dovedească că tranzacția a fost introdusă în registru de către un subiect DPKI înregistrat, deoarece semnătura a fost generată și pe o cheie de serviciu secret. Și nu poate exista abuz, cum ar fi atacurile DOS, deoarece proprietarul plătește pentru fiecare tranzacție.
Toate tranzacțiile care urmează celei zero sunt formate într-un mod similar: cheia publică (nu portofelul, ca în cazul tranzacției zero, ci dintr-o pereche de chei obișnuită) este rulată prin două funcții hash SHA256 și RIPEMD160. Așa se formează datele celui de-al treilea câmp. Al patrulea câmp conține informații însoțitoare (de exemplu, informații despre starea curentă, datele de expirare, marcajul temporal, identificatorii cripto-algoritmilor utilizați etc.). Al cincilea câmp conține cheia publică din perechea de chei de serviciu. Cu ajutorul ei, semnătura digitală va fi apoi verificată, deci va fi replicată. Să justificăm necesitatea unei astfel de abordări.
Amintiți-vă că o tranzacție este introdusă într-un pool și stocată acolo până când este procesată. Stocarea într-un pool este asociată cu un anumit risc - datele tranzacției pot fi falsificate. Proprietarul certifică datele tranzacției cu o semnătură digitală electronică. Cheia publică pentru verificarea acestei semnături digitale este indicată în mod explicit într-unul dintre câmpurile tranzacției și este ulterior introdusă în registru. Particularitățile procesării tranzacțiilor sunt de așa natură încât un atacator este capabil să modifice datele la propria discreție și apoi să le verifice folosind cheia sa secretă și să indice o cheie publică asociată pentru verificarea semnăturii digitale în tranzacție. Dacă autenticitatea și integritatea sunt asigurate exclusiv prin semnătură digitală, atunci un astfel de fals va trece neobservat. Dacă însă, pe lângă semnătura digitală, există un mecanism suplimentar care asigură atât arhivarea, cât și persistența informațiilor stocate, atunci falsul poate fi detectat. Pentru a face acest lucru, este suficient să introduceți cheia publică autentică a proprietarului în registru. Să explicăm cum funcționează.
Lăsați atacatorul să falsifice date despre tranzacții. Din punct de vedere al cheilor și al semnăturilor digitale, sunt posibile următoarele opțiuni:
1. Atacatorul își plasează cheia publică în tranzacție, în timp ce semnătura digitală a proprietarului rămâne neschimbată.
2. Atacatorul creează o semnătură digitală pe cheia sa privată, dar lasă cheia publică a proprietarului neschimbată.
3. Atacatorul creează o semnătură digitală pe cheia sa privată și plasează o cheie publică asociată în tranzacție.
Evident, opțiunile 1 și 2 sunt lipsite de sens, deoarece vor fi întotdeauna detectate în timpul verificării semnăturii digitale. Doar opțiunea 3 are sens, iar dacă un atacator formează o semnătură digitală pe propria sa cheie secretă, atunci el este forțat să salveze o cheie publică asociată în tranzacție, diferită de cheia publică a proprietarului. Acesta este singurul mod prin care un atacator poate impune date falsificate.
Să presupunem că proprietarul are o pereche fixă de chei - private și publice. Lasă datele să fie certificate prin semnătură digitală folosind cheia secretă de la această pereche, iar cheia publică este indicată în tranzacție. Să presupunem, de asemenea, că această cheie publică a fost introdusă anterior în registru și că autenticitatea ei a fost verificată în mod fiabil. Atunci o falsificare va fi indicată prin faptul că cheia publică din tranzacție nu corespunde cheii publice din registru.
Să rezumăm. Atunci când procesează datele primei tranzacții ale proprietarului, este necesar să se verifice autenticitatea cheii publice introduse în registru. Pentru a face acest lucru, citiți cheia din registru și comparați-o cu adevărata cheie publică a proprietarului în perimetrul de securitate (zona de invulnerabilitate relativă). Dacă autenticitatea cheii este confirmată și persistența acesteia este garantată la plasare, atunci autenticitatea cheii din tranzacția ulterioară poate fi ușor confirmată/infirmată prin compararea acesteia cu cheia din registru. Cu alte cuvinte, cheia din registry este folosită ca eșantion de referință. Toate celelalte tranzacții ale proprietarului sunt procesate în mod similar.
Tranzacția este certificată printr-o semnătură digitală electronică - aici sunt necesare cheile secrete, și nu una, ci două deodată - o cheie de serviciu și o cheie de portofel. Datorită utilizării a două chei secrete, este asigurat nivelul necesar de securitate - la urma urmei, cheia secretă a serviciului poate fi cunoscută de alți utilizatori, în timp ce cheia secretă a portofelului este cunoscută doar de proprietarul perechii de chei obișnuite. Am numit o astfel de semnătură cu două chei semnătură digitală „consolidată”.
Verificarea tranzacțiilor non-nule se realizează folosind două chei publice: portofelul și cheia de serviciu. Procesul de verificare poate fi împărțit în două etape principale: prima este verificarea rezumatului cheii publice a portofelului, iar a doua este verificarea semnăturii digitale electronice a tranzacției, aceeași consolidată care s-a format folosind două chei secrete ( portofel și serviciu). Dacă validitatea semnăturii digitale este confirmată, atunci după o verificare suplimentară tranzacția este înscrisă în registru.
Poate apărea o întrebare logică: cum să verificați dacă o tranzacție aparține unui anumit lanț cu „rădăcină” sub forma unei tranzacții zero? În acest scop, procesul de verificare este completat cu încă o etapă - verificarea conectivității. Aici vom avea nevoie de datele din primele două câmpuri, pe care le-am ignorat până acum.
Să ne imaginăm că trebuie să verificăm dacă tranzacția nr. 3 vine de fapt după tranzacția nr. 2. Pentru a face acest lucru, folosind metoda hash combinată, valoarea funcției hash este calculată pentru datele din câmpurile al treilea, al patrulea și al cincilea ale tranzacției nr. 2. Apoi se realizează concatenarea datelor din primul câmp al tranzacției nr. 3 și valoarea funcției hash combinată obținută anterior pentru datele din al treilea, al patrulea și al cincilea câmp al tranzacției nr. 2. Toate acestea sunt, de asemenea, rulate prin două funcții hash SHA256 și RIPEMD160. Dacă valoarea primită se potrivește cu datele din al doilea câmp al tranzacției nr. 2, atunci verificarea este trecută și conexiunea este confirmată. Acest lucru este arătat mai clar în figurile de mai jos.
În termeni generali, tehnologia de generare și introducere a unei notificări în registru arată exact așa. O ilustrare vizuală a procesului de formare a unui lanț de notificări este prezentată în următoarea figură:
În acest text, nu ne vom opri asupra detaliilor, care există, fără îndoială, și ne vom întoarce la discutarea însăși ideea unei infrastructuri cu cheie publică descentralizată.
Deci, întrucât solicitantul însuși depune o cerere de înregistrare a notificărilor, care nu sunt stocate în baza de date CA, ci în registru, ar trebui luate în considerare principalele componente arhitecturale ale DPKI:
1. Registrul notificărilor valide (RDN).
2. Registrul notificărilor revocate (RON).
3. Registrul notificărilor suspendate (RPN).
Informațiile despre cheile publice sunt stocate în RDN/RON/RPN sub formă de valori ale funcției hash. De asemenea, este de remarcat faptul că acestea pot fi fie registre diferite, fie lanțuri diferite, fie chiar un lanț ca parte a unui singur registru, atunci când informații despre starea unei chei publice obișnuite (revocare, suspendare etc.) sunt introduse în al patrulea câmp al structurii de date sub forma valorii codului corespunzătoare. Există multe opțiuni diferite pentru implementarea arhitecturală a DPKI, iar alegerea unuia sau celuilalt depinde de o serie de factori, de exemplu, criterii de optimizare precum costul memoriei pe termen lung pentru stocarea cheilor publice etc.
Astfel, DPKI se poate dovedi a fi, dacă nu mai simplu, atunci cel puțin comparabil cu o soluție centralizată din punct de vedere al complexității arhitecturale.
Principala întrebare rămâne - Ce registru este potrivit pentru implementarea tehnologiei?
Principala cerință pentru registru este capacitatea de a genera tranzacții de orice tip. Cel mai faimos exemplu de registru este rețeaua Bitcoin. Dar la implementarea tehnologiei descrise mai sus apar anumite dificultăți: limitările limbajului de scripting existent, lipsa mecanismelor necesare pentru procesarea seturilor arbitrare de date, metode de generare a tranzacțiilor de tip arbitrar și multe altele.
Noi, cei de la ENCRY, am încercat să rezolvăm problemele formulate mai sus și am dezvoltat un registru care, în opinia noastră, are o serie de avantaje și anume:
- acceptă mai multe tipuri de tranzacții: poate atât schimbă active (adică efectua tranzacții financiare), cât și poate crea tranzacții cu o structură arbitrară,
- dezvoltatorii au acces la limbajul de programare proprietar PrismLang, care oferă flexibilitatea necesară atunci când rezolvă diverse probleme tehnologice,
- este prevăzut un mecanism de procesare a seturilor de date arbitrare.
Dacă adoptăm o abordare simplificată, atunci are loc următoarea secvență de acțiuni:
- Solicitantul se înregistrează la DPKI și primește un portofel digital. Adresa portofelului este valoarea hash a cheii publice a portofelului. Cheia privată a portofelului este cunoscută doar de solicitant.
- Subiectului înregistrat i se oferă acces la cheia secretă a serviciului.
- Subiectul generează o tranzacție zero și o verifică cu o semnătură digitală folosind cheia secretă a portofelului.
- Dacă se formează o tranzacție diferită de zero, aceasta este certificată printr-o semnătură digitală electronică folosind două chei secrete: un portofel și una de serviciu.
- Subiectul trimite o tranzacție la pool.
- Nodul de rețea ENCRY citește tranzacția din pool și verifică semnătura digitală, precum și conectivitatea tranzacției.
- Dacă semnătura digitală este validă și conexiunea este confirmată, atunci pregătește tranzacția pentru intrarea în registru.
Aici registrul acționează ca o bază de date distribuită care stochează informații despre notificările valide, anulate și suspendate.
Desigur, descentralizarea nu este un panaceu. Problema fundamentală a autentificării utilizatorului primar nu dispare nicăieri: dacă în prezent verificarea solicitantului este efectuată de CR, atunci în DPKI se propune delegarea verificării membrilor comunității și utilizarea motivației financiare pentru a stimula activitatea. Tehnologia de verificare open source este binecunoscută. Eficacitatea unei astfel de verificări a fost confirmată în practică. Să ne amintim din nou o serie de investigații importante ale publicației online Bellingcat.
Dar, în general, apare următoarea imagine: DPKI este o oportunitate de a corecta, dacă nu toate, atunci multe dintre deficiențele PKI centralizate.
Abonați-vă la Habrablogul nostru, intenționăm să continuăm să ne acoperim în mod activ cercetarea și dezvoltarea și să urmărim , dacă nu vrei să ratezi alte știri despre proiectele ENCRY.
Sursa: www.habr.com