DPKI: elimineer die tekortkominge van gesentraliseerde PKI met behulp van blockchain

Dit is geen geheim dat een van die algemeen gebruikte hulpinstrumente, waarsonder databeskerming in oop netwerke onmoontlik is, digitale sertifikaattegnologie is. Dit is egter geen geheim dat die grootste nadeel van die tegnologie onvoorwaardelike vertroue is in die sentrums wat digitale sertifikate uitreik nie. Direkteur van Tegnologie en Innovasie by ENCRY Andrey Chmora het 'n nuwe benadering tot organisering voorgestel publieke sleutel infrastruktuur (Publieke Sleutel Infrastruktuur, PKI), wat sal help om huidige tekortkominge uit te skakel en wat verspreide grootboek (blockchain) tegnologie gebruik. Maar eerste dinge eerste.

As jy vertroud is met hoe jou huidige publieke sleutelinfrastruktuur werk en die belangrikste tekortkominge daarvan ken, kan jy voortgaan na wat ons hieronder voorstel om te verander.

Wat is digitale handtekeninge en sertifikate?Interaksie op die internet behels altyd die oordrag van data. Ons het almal 'n belang daarin om te verseker dat data veilig oorgedra word. Maar wat is sekuriteit? Die mees gesogte sekuriteitsdienste is vertroulikheid, integriteit en egtheid. Vir hierdie doel word tans metodes van asimmetriese kriptografie, of kriptografie met 'n publieke sleutel, gebruik.

Kom ons begin met die feit dat om hierdie metodes te gebruik, die onderwerpe van interaksie twee individuele gepaarde sleutels moet hê - publiek en geheim. Met hul hulp word die sekuriteitsdienste wat ons hierbo genoem het, verskaf.

Hoe word vertroulikheid van inligtingoordrag verkry? Voordat data gestuur word, enkripteer (transformeer kriptografies) die intekenaar die oop data met behulp van die ontvanger se publieke sleutel, en die ontvanger dekripteer die ontvangde syferteks deur die gepaarde geheime sleutel te gebruik.

Hoe word die integriteit en egtheid van die oorgedra inligting bereik? Om hierdie probleem op te los, is 'n ander meganisme geskep. Die oop data word nie geïnkripteer nie, maar die resultaat van die toepassing van die kriptografiese hash-funksie - 'n "saamgeperste" beeld van die invoerdatareeks - word in geënkripteerde vorm oorgedra. Die resultaat van sulke hashing word 'n "digest" genoem en dit word geënkripteer met die geheime sleutel van die sender-intekenaar ("die getuie"). As gevolg van die enkripteer van die digest, word 'n digitale handtekening verkry. Dit word saam met die duidelike teks aan die ontvanger-intekenaar (“verifier”) oorgedra. Hy dekripteer die digitale handtekening op die getuie se publieke sleutel en vergelyk dit met die resultaat van die toepassing van 'n kriptografiese hash-funksie, wat die verifieerder onafhanklik bereken op grond van die ontvangde oop data. As hulle ooreenstem, dui dit aan dat die data in 'n outentieke en volledige vorm deur die sender-intekenaar versend is, en nie deur 'n aanvaller gewysig is nie.

Die meeste hulpbronne wat met persoonlike data en betalingsinligting werk (banke, versekeringsmaatskappye, lugdienste, betalingstelsels, sowel as regeringsportale soos die belastingdiens) gebruik aktief asimmetriese kriptografiemetodes.

Wat het 'n digitale sertifikaat daarmee te doen? Dis eenvoudig. Beide die eerste en tweede prosesse behels publieke sleutels, en aangesien hulle 'n sentrale rol speel, is dit baie belangrik om te verseker dat die sleutels werklik aan die sender (die getuie, in die geval van handtekeningverifikasie) of die ontvanger behoort, en nie vervang met die sleutels van aanvallers. Dit is hoekom digitale sertifikate bestaan ​​om die egtheid en integriteit van die publieke sleutel te verseker.

Let wel: die egtheid en integriteit van die publieke sleutel word op presies dieselfde manier bevestig as die egtheid en integriteit van publieke data, dit wil sê met behulp van 'n elektroniese digitale handtekening (EDS).
Waar kom digitale sertifikate vandaan?Betroubare sertifiseringsowerhede, of Sertifiseringsowerhede (CA's), is verantwoordelik vir die uitreiking en instandhouding van digitale sertifikate. Die aansoeker versoek die uitreiking van 'n sertifikaat van die GR, ondergaan identifikasie by die Registrasiesentrum (CR) en ontvang 'n sertifikaat van die GR. Die CA waarborg dat die publieke sleutel van die sertifikaat aan presies die entiteit behoort waarvoor dit uitgereik is.

As jy nie die egtheid van die publieke sleutel bevestig nie, dan kan 'n aanvaller tydens die oordrag/berging van hierdie sleutel dit met sy eie vervang. Indien die vervanging plaasgevind het, sal die aanvaller in staat wees om alles wat die sender intekenaar aan die ontvangende intekenaar oordra, te dekripteer, of die oop data na eie goeddunke te verander.

Digitale sertifikate word gebruik waar asimmetriese kriptografie ook al beskikbaar is. Een van die mees algemene digitale sertifikate is SSL-sertifikate vir veilige kommunikasie oor die HTTPS-protokol. Honderde maatskappye wat in verskeie jurisdiksies geregistreer is, is betrokke by die uitreiking van SSL-sertifikate. Die hoofaandeel val op vyf tot tien groot vertroude sentrums: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.

CA en CR is komponente van PKI, wat ook die volgende insluit:

• Maak gids oop – 'n publieke databasis wat veilige berging van digitale sertifikate bied.
• Sertifikaat herroepingslys – 'n publieke databasis wat veilige berging van digitale sertifikate van herroepe publieke sleutels verskaf (byvoorbeeld as gevolg van die kompromie van 'n gepaarde private sleutel). Infrastruktuurvakke kan onafhanklik toegang tot hierdie databasis verkry, of hulle kan die gespesialiseerde Online Sertifisering Status Protocol (OCSP) gebruik, wat die verifikasieproses vergemaklik.
• Sertifikaat gebruikers – PKI-vakke bedien wat 'n gebruikersooreenkoms met die GR aangegaan het en die digitale handtekening verifieer en/of data enkripteer gebaseer op die publieke sleutel van die sertifikaat.
• Volgers – bediende PKI-vakke wat 'n geheime sleutel besit wat met die publieke sleutel van die sertifikaat gepaar is, en wat 'n intekenaarooreenkoms met die GR aangegaan het. Die intekenaar kan terselfdertyd 'n gebruiker van die sertifikaat wees.

Dus, vertroude entiteite van die publieke sleutelinfrastruktuur, wat GR'e, CR'e en oop gidse insluit, is dus verantwoordelik vir:

1. Verifikasie van die egtheid van die aansoeker se identiteit.
2. Profilering van die publieke sleutelsertifikaat.
3. Uitreiking van 'n publieke sleutelsertifikaat vir 'n aansoeker wie se identiteit betroubaar bevestig is.
4. Verander die status van die publieke sleutelsertifikaat.
5. Die verskaffing van inligting oor die huidige status van die publieke sleutelsertifikaat.

Nadele van PKI, wat is dit?Die fundamentele fout van PKI is die teenwoordigheid van betroubare entiteite.
Gebruikers moet die CA en CR onvoorwaardelik vertrou. Maar, soos die praktyk toon, is onvoorwaardelike vertroue belaai met ernstige gevolge.

Oor die afgelope tien jaar was daar verskeie groot skandale op hierdie gebied wat verband hou met infrastruktuurkwesbaarheid.

- in 2010 het die Stuxnet-wanware aanlyn begin versprei, onderteken met gesteelde digitale sertifikate van RealTek en JMicron.

- In 2017 het Google Symantec daarvan beskuldig dat hy 'n groot aantal vervalste sertifikate uitgereik het. Symantec was destyds een van die grootste GR'e wat produksievolumes betref. In die Google Chrome 70-blaaier is ondersteuning vir sertifikate uitgereik deur hierdie maatskappy en sy geaffilieerde sentrums GeoTrust en Thawte voor 1 Desember 2017 gestaak.

Die CA's is gekompromitteer, en gevolglik het almal gely – die CA's self, sowel as gebruikers en intekenare. Vertroue in infrastruktuur is ondermyn. Daarbenewens kan digitale sertifikate geblokkeer word in die konteks van politieke konflikte, wat ook die werking van baie hulpbronne sal beïnvloed. Dit is presies wat verskeie jare gelede gevrees is in die Russiese presidensiële administrasie, waar hulle in 2016 die moontlikheid bespreek het om 'n staatsertifiseringsentrum te skep wat SSL-sertifikate aan webwerwe op die RuNet sou uitreik. Die huidige stand van sake is so dat selfs staat portale in Rusland gebruik digitale sertifikate uitgereik deur Amerikaanse maatskappye Comodo of Thawte ('n filiaal van Symantec).

Daar is nog 'n probleem - die vraag primêre verifikasie (verifikasie) van gebruikers. Hoe om 'n gebruiker te identifiseer wat die GR gekontak het met 'n versoek om 'n digitale sertifikaat uit te reik sonder direkte persoonlike kontak? Nou word dit situasioneel opgelos, afhangende van die vermoëns van die infrastruktuur. Iets word uit oop registers geneem (byvoorbeeld inligting oor regspersone wat sertifikate aanvra); in gevalle waar die aansoekers individue is, kan bankkantore of poskantore gebruik word, waar hul identiteit bevestig word met identifikasiedokumente, byvoorbeeld 'n paspoort.

Die probleem van die vervalsing van geloofsbriewe vir die doel van nabootsing is 'n fundamentele een. Kom ons let daarop dat daar weens inligtingsteoretiese redes geen volledige oplossing vir hierdie probleem is nie: sonder om a priori betroubare inligting te hê, is dit onmoontlik om die egtheid van 'n bepaalde onderwerp te bevestig of te ontken. As 'n reël, vir verifikasie is dit nodig om 'n stel dokumente voor te lê wat die identiteit van die aansoeker bewys. Daar is baie verskillende verifikasiemetodes, maar nie een van hulle bied 'n volle waarborg van die egtheid van dokumente nie. Gevolglik kan die egtheid van die aansoeker se identiteit ook nie gewaarborg word nie.

Hoe kan hierdie tekortkominge uitgeskakel word?As die probleme van PKI in sy huidige toestand verklaar kan word deur sentralisasie, dan is dit logies om aan te neem dat desentralisasie die geïdentifiseerde tekortkominge gedeeltelik sal help uitskakel.

Desentralisasie impliseer nie die teenwoordigheid van vertroude entiteite nie - as jy skep gedesentraliseerde publieke sleutelinfrastruktuur (Gedesentraliseerde publieke sleutelinfrastruktuur, DPKI), dan is nóg CA nóg CR nodig. Kom ons laat vaar die konsep van 'n digitale sertifikaat en gebruik 'n verspreide register om inligting oor publieke sleutels te stoor. In ons geval noem ons 'n register 'n lineêre databasis wat bestaan ​​uit individuele rekords (blokke) wat met blokkettingtegnologie gekoppel is. In plaas van 'n digitale sertifikaat, sal ons die konsep van "kennisgewing" bekendstel.

Hoe die proses om kennisgewings te ontvang, te verifieer en te kanselleer sal lyk in die voorgestelde DPKI:

1. Elke aansoeker dien onafhanklik 'n aansoek om 'n kennisgewing in deur 'n vorm tydens registrasie in te vul, waarna hy 'n transaksie skep wat in 'n gespesialiseerde poel gestoor word.

2. Inligting oor die publieke sleutel, tesame met die eienaar se besonderhede en ander metadata, word in 'n verspreide register gestoor, en nie in 'n digitale sertifikaat nie, vir die uitreiking waarvan in 'n gesentraliseerde PKI die CA verantwoordelik is.

3. Verifikasie van die egtheid van die aansoeker se identiteit word ná die feit uitgevoer deur die gesamentlike pogings van die DPKI-gebruikersgemeenskap, en nie deur die CR nie.

4. Slegs die eienaar van so 'n kennisgewing kan die status van 'n publieke sleutel verander.

5. Enigeen kan toegang tot die verspreide grootboek kry en die huidige status van die publieke sleutel nagaan.

Let wel: Gemeenskapsverifikasie van 'n aansoeker se identiteit kan met die eerste oogopslag onbetroubaar lyk. Maar ons moet onthou dat alle gebruikers van digitale dienste deesdae onvermydelik 'n digitale voetspoor laat, en hierdie proses sal net voortgaan om momentum te kry. Oop elektroniese registers van regspersone, kaarte, digitalisering van terreinbeelde, sosiale netwerke - dit alles is publiek beskikbare hulpmiddels. Hulle word reeds suksesvol gebruik tydens ondersoeke deur beide joernaliste en wetstoepassingsagentskappe. Dit is byvoorbeeld genoeg om die ondersoeke van Bellingcat of die gesamentlike ondersoekspan JIT te onthou, wat die omstandighede van die ongeluk van die Maleisiese Boeing bestudeer.

So, hoe sou 'n gedesentraliseerde publieke sleutel-infrastruktuur in die praktyk werk? Laat ons stilstaan ​​by die beskrywing van die tegnologie self, wat ons gepatenteer in 2018 en ons beskou dit tereg as ons kundigheid.

Stel jou voor dat daar 'n eienaar is wat baie publieke sleutels besit, waar elke sleutel 'n sekere transaksie is wat in die register gestoor word. In die afwesigheid van 'n GR, hoe kan jy verstaan ​​dat al die sleutels aan hierdie spesifieke eienaar behoort? Om hierdie probleem op te los, word 'n nultransaksie geskep, wat inligting oor die eienaar en sy beursie bevat (waaruit die kommissie vir die plasing van die transaksie in die register gedebiteer word). Die nultransaksie is 'n soort "anker" waaraan die volgende transaksies met data oor publieke sleutels geheg sal word. Elke sodanige transaksie bevat 'n gespesialiseerde datastruktuur, of met ander woorde, 'n kennisgewing.

Kennisgewing is 'n gestruktureerde stel data wat bestaan ​​uit funksionele velde en insluitend inligting oor die eienaar se publieke sleutel, waarvan die volharding gewaarborg word deur plasing in een van die gepaardgaande rekords van die verspreide register.

Die volgende logiese vraag is hoe word 'n nultransaksie gevorm? Die nultransaksie - soos daaropvolgendes - is 'n samevoeging van ses datavelde. Tydens die vorming van 'n nultransaksie is die sleutelpaar van die beursie betrokke (openbare en gepaarde geheime sleutels). Hierdie sleutelpaar verskyn op die oomblik wanneer die gebruiker sy beursie registreer, waaruit die kommissie vir die plasing van 'n nultransaksie in die register en, gevolglik, bedrywighede met kennisgewings gedebiteer sal word.

Soos getoon in die figuur, word 'n beursie publieke sleutel-samevatting gegenereer deur die SHA256- en RIPEMD160-hash-funksies opeenvolgend toe te pas. Hier is RIPEMD160 verantwoordelik vir die kompakte voorstelling van data, waarvan die breedte nie 160 bisse oorskry nie. Dit is belangrik omdat die register nie 'n goedkoop databasis is nie. Die publieke sleutel self word in die vyfde veld ingevoer. Die eerste veld bevat data wat 'n verbinding met die vorige transaksie tot stand bring. Vir 'n nultransaksie bevat hierdie veld niks, wat dit onderskei van daaropvolgende transaksies. Die tweede veld is data om die konnektiwiteit van transaksies na te gaan. Vir bondigheid sal ons die data in die eerste en tweede velde onderskeidelik "skakel" en "kontroleer" noem. Die inhoud van hierdie velde word gegenereer deur iteratiewe hashing, soos gedemonstreer deur die tweede en derde transaksies in die figuur hieronder te koppel.

Die data van die eerste vyf velde word gesertifiseer deur 'n elektroniese handtekening, wat met die beursie se geheime sleutel gegenereer word.

Dit is dit, die nultransaksie word na die poel gestuur en na suksesvolle verifikasie word dit in die register ingevoer. Nou kan jy die volgende transaksies daaraan “koppel”. Kom ons kyk hoe transaksies anders as nul gevorm word.

Die eerste ding wat waarskynlik jou oog gevang het, is die oorvloed sleutelpare. Benewens die reeds bekende beursiesleutelpaar, word gewone en dienssleutelpare gebruik.

'n Gewone publieke sleutel is waarvoor alles begin is. Hierdie sleutel is betrokke by verskeie prosedures en prosesse wat in die buitewêreld ontvou (bank- en ander transaksies, dokumentvloei, ens.). Byvoorbeeld, 'n geheime sleutel van 'n gewone paar kan gebruik word om digitale handtekeninge vir verskeie dokumente te genereer - betalingsopdragte, ens., en 'n publieke sleutel kan gebruik word om hierdie digitale handtekening te verifieer met die daaropvolgende uitvoering van hierdie instruksies, mits dit is geldig.

Die dienspaar word aan die geregistreerde DPKI-vak uitgereik. Die naam van hierdie paar stem ooreen met sy doel. Let daarop dat wanneer 'n nultransaksie gevorm/gekontroleer word, dienssleutels nie gebruik word nie.

Kom ons verduidelik weer die doel van die sleutels:

1. Beursiesleutels word gebruik om beide 'n nultransaksie en enige ander nie-nultransaksie te genereer/verifieer. Die private sleutel van 'n beursie is slegs bekend aan die eienaar van die beursie, wat ook die eienaar van baie gewone publieke sleutels is.
2. 'n Gewone publieke sleutel is soortgelyk in doel aan 'n publieke sleutel waarvoor 'n sertifikaat in 'n gesentraliseerde PKI uitgereik word.
3. Die dienssleutelpaar behoort aan DPKI. Die geheime sleutel word aan geregistreerde entiteite uitgereik en word gebruik wanneer digitale handtekeninge vir transaksies gegenereer word (behalwe vir geen transaksies). Publiek word gebruik om die elektroniese digitale handtekening van 'n transaksie te verifieer voordat dit in die register geplaas word.

Daar is dus twee groepe sleutels. Die eerste sluit dienssleutels en beursiesleutels in - hulle maak net sin in die konteks van DPKI. Die tweede groep sluit gewone sleutels in – hul omvang kan verskil en word bepaal deur die toepassingstake waarin dit gebruik word. Terselfdertyd verseker DPKI die integriteit en egtheid van gewone publieke sleutels.

Let wel: Die dienssleutelpaar kan aan verskillende DPKI-entiteite bekend wees. Dit kan byvoorbeeld vir almal dieselfde wees. Dit is om hierdie rede dat wanneer die handtekening van elke nie-nul transaksie gegenereer word, twee geheime sleutels gebruik word, waarvan een die beursie sleutel is - dit is slegs bekend aan die eienaar van die beursie, wat ook die eienaar van baie gewone publieke sleutels. Alle sleutels het hul eie betekenis. Dit is byvoorbeeld altyd moontlik om te bewys dat die transaksie deur 'n geregistreerde DPKI-onderwerp in die register ingevoer is, aangesien die handtekening ook op 'n geheime dienssleutel gegenereer is. En daar kan geen misbruik, soos DOS-aanvalle, wees nie, want die eienaar betaal vir elke transaksie.

Alle transaksies wat die nul een volg, word op 'n soortgelyke manier gevorm: die publieke sleutel (nie die beursie, soos in die geval van die nultransaksie nie, maar van 'n gewone sleutelpaar) word deur twee hash-funksies SHA256 en RIPEMD160 uitgevoer. Dit is hoe die data van die derde veld gevorm word. Die vierde veld bevat gepaardgaande inligting (byvoorbeeld inligting oor die huidige status, vervaldatums, tydstempel, identifiseerders van kripto-algoritmes wat gebruik word, ens.). Die vyfde veld bevat die publieke sleutel van die dienssleutelpaar. Met die hulp daarvan sal die digitale handtekening dan nagegaan word, so dit sal gerepliseer word. Laat ons die behoefte aan so 'n benadering regverdig.

Onthou dat 'n transaksie in 'n poel aangegaan en daar gestoor word totdat dit verwerk is. Berging in 'n poel word geassosieer met 'n sekere risiko - transaksiedata kan vervals word. Die eienaar sertifiseer die transaksiedata met 'n elektroniese digitale handtekening. Die publieke sleutel vir die verifikasie van hierdie digitale handtekening word uitdruklik in een van die transaksievelde aangedui en word daarna in die register ingevoer. Die eienaardighede van transaksieverwerking is sodanig dat 'n aanvaller in staat is om die data na eie goeddunke te verander en dit dan met behulp van sy geheime sleutel te verifieer, en 'n gepaarde publieke sleutel aan te dui om die digitale handtekening in die transaksie te verifieer. As egtheid en integriteit uitsluitlik deur digitale handtekening verseker word, sal so 'n vervalsing ongemerk verbygaan. As daar egter, benewens die digitale handtekening, 'n bykomende meganisme is wat beide argivering en volharding van die gestoorde inligting verseker, dan kan die vervalsing opgespoor word. Om dit te doen, is dit genoeg om die eienaar se ware publieke sleutel in die register in te voer. Kom ons verduidelik hoe dit werk.

Laat die aanvaller transaksiedata vervals. Vanuit die oogpunt van sleutels en digitale handtekeninge is die volgende opsies moontlik:

1. Die aanvaller plaas sy publieke sleutel in die transaksie terwyl die eienaar se digitale handtekening onveranderd bly.
2. Die aanvaller skep 'n digitale handtekening op sy private sleutel, maar laat die eienaar se publieke sleutel onveranderd.
3. Die aanvaller skep 'n digitale handtekening op sy private sleutel en plaas 'n gepaarde publieke sleutel in die transaksie.

Uiteraard is opsies 1 en 2 betekenisloos, aangesien hulle altyd tydens die verifikasie van digitale handtekening opgespoor sal word. Slegs opsie 3 maak sin, en as 'n aanvaller 'n digitale handtekening op sy eie geheime sleutel vorm, dan word hy gedwing om 'n gepaarde publieke sleutel in die transaksie te stoor, anders as die eienaar se publieke sleutel. Dit is die enigste manier vir 'n aanvaller om vervalste data op te lê.

Kom ons neem aan dat die eienaar 'n vaste paar sleutels het - privaat en publiek. Laat die data gesertifiseer word deur digitale handtekening deur die geheime sleutel van hierdie paar te gebruik, en die publieke sleutel word in die transaksie aangedui. Kom ons neem ook aan dat hierdie publieke sleutel voorheen in die register ingevoer is en die egtheid daarvan is betroubaar geverifieer. Dan sal 'n vervalsing aangedui word deur die feit dat die publieke sleutel van die transaksie nie ooreenstem met die publieke sleutel van die register nie.

Kom ons vat dit op. Wanneer die eienaar se heel eerste transaksiedata verwerk word, is dit nodig om die egtheid van die publieke sleutel wat in die register ingevoer is, te verifieer. Om dit te doen, lees die sleutel uit die register en vergelyk dit met die ware publieke sleutel van die eienaar binne die sekuriteitsomtrek (gebied van relatiewe onkwesbaarheid). As die egtheid van die sleutel bevestig word en die volharding daarvan word gewaarborg by plasing, dan kan die egtheid van die sleutel van die daaropvolgende transaksie maklik bevestig/weerlê word deur dit met die sleutel uit die register te vergelyk. Met ander woorde, die sleutel uit die register word as 'n verwysingsmonster gebruik. Alle ander eienaartransaksies word op soortgelyke wyse verwerk.

Die transaksie word gesertifiseer deur 'n elektroniese digitale handtekening - dit is waar geheime sleutels benodig word, en nie een nie, maar twee gelyktydig - 'n dienssleutel en 'n beursiesleutel. Danksy die gebruik van twee geheime sleutels word die nodige vlak van sekuriteit verseker - die diens geheime sleutel kan immers aan ander gebruikers bekend wees, terwyl die geheime sleutel van die beursie slegs aan die eienaar van die gewone sleutelpaar bekend is. Ons het so 'n tweesleutelhandtekening 'n "gekonsolideerde" digitale handtekening genoem.

Verifikasie van nie-nul transaksies word uitgevoer met behulp van twee publieke sleutels: die beursie en die dienssleutel. Die verifikasieproses kan in twee hooffases verdeel word: die eerste is die kontrolering van die bundel van die publieke sleutel van die beursie, en die tweede is die kontrolering van die elektroniese digitale handtekening van die transaksie, dieselfde gekonsolideerde een wat met twee geheime sleutels gevorm is ( beursie en diens). As die geldigheid van die digitale handtekening bevestig word, word die transaksie na bykomende verifikasie in die register ingevoer.

'n Logiese vraag kan ontstaan: hoe om te kontroleer of 'n transaksie aan 'n spesifieke ketting behoort met die "wortel" in die vorm van 'n nultransaksie? Vir hierdie doel word die verifikasieproses aangevul met nog 'n stadium - konneksiekontrolering. Dit is waar ons die data van die eerste twee velde sal benodig, wat ons tot dusver geïgnoreer het.

Kom ons stel ons voor dat ons moet kyk of transaksie nr. 3 werklik ná transaksie nr. 2 kom. Om dit te doen, met behulp van die gekombineerde hash-metode, word die hash-funksiewaarde vir die data van die derde, vierde en vyfde velde van transaksie nr. 2 bereken. Dan word die samevoeging van data van die eerste veld van transaksie nr. 3 en die voorheen verkry gekombineerde hash-funksiewaarde vir data van die derde, vierde en vyfde velde van transaksie nr. 2 uitgevoer. Dit alles word ook deur twee hash-funksies SHA256 en RIPEMD160 uitgevoer. As die ontvangde waarde ooreenstem met die data in die tweede veld van transaksie nr. 2, dan word die tjek geslaag en die verbinding word bevestig. Dit word duideliker in die onderstaande figure getoon.

In algemene terme lyk die tegnologie om 'n kennisgewing in die register te genereer en in te voer presies so. 'n Visuele illustrasie van die proses om 'n ketting van kennisgewings te vorm, word in die volgende figuur aangebied:

In hierdie teks gaan ons nie stilstaan ​​by die besonderhede, wat ongetwyfeld bestaan ​​nie, en terugkeer na die idee van 'n gedesentraliseerde publieke sleutelinfrastruktuur.

Dus, aangesien die aansoeker self 'n aansoek vir registrasie van kennisgewings indien, wat nie in die GR-databasis nie, maar in die register gestoor word, moet die hoofargitektoniese komponente van DPKI oorweeg word:

1. Register van geldige kennisgewings (RDN).
2. Register van herroepe kennisgewings (RON).
3. Register van opgeskorte kennisgewings (RPN).

Inligting oor publieke sleutels word in RDN/RON/RPN gestoor in die vorm van hash-funksiewaardes. Dit is ook opmerklik dat dit óf verskillende registers, óf verskillende kettings, of selfs een ketting as deel van 'n enkele register kan wees, wanneer inligting oor die status van 'n gewone publieke sleutel (herroeping, opskorting, ens.) in die vierde veld van die datastruktuur in die vorm van die ooreenstemmende kodewaarde. Daar is baie verskillende opsies vir die argitektoniese implementering van DPKI, en die keuse van die een of die ander hang af van 'n aantal faktore, byvoorbeeld optimeringskriteria soos die koste van langtermyngeheue vir die berging van publieke sleutels, ens.

DPKI kan dus blyk te wees, indien nie eenvoudiger nie, dan ten minste vergelykbaar met 'n gesentraliseerde oplossing in terme van argitektoniese kompleksiteit.

Die hoofvraag bly staan ​​- Watter register is geskik vir die implementering van die tegnologie?

Die belangrikste vereiste vir die register is die vermoë om transaksies van enige tipe te genereer. Die bekendste voorbeeld van 'n grootboek is die Bitcoin-netwerk. Maar by die implementering van die tegnologie wat hierbo beskryf word, ontstaan ​​sekere probleme: die beperkings van die bestaande skriftaal, die gebrek aan nodige meganismes vir die verwerking van arbitrêre stelle data, metodes om transaksies van 'n arbitrêre tipe te genereer, en nog baie meer.

Ons by ENCRY het probeer om die probleme wat hierbo geformuleer is op te los en 'n register ontwikkel wat, na ons mening, 'n aantal voordele inhou, naamlik:

• ondersteun verskeie tipes transaksies: dit kan beide bates uitruil (dit wil sê finansiële transaksies uitvoer) en transaksies met 'n arbitrêre struktuur skep,
• ontwikkelaars het toegang tot die eie PrismLang-programmeertaal, wat die nodige buigsaamheid bied wanneer verskeie tegnologiese probleme opgelos word,
• 'n meganisme vir die verwerking van arbitrêre datastelle word verskaf.

As ons 'n vereenvoudigde benadering volg, vind die volgende volgorde van aksies plaas:

1. Die aansoeker registreer by DPKI en ontvang 'n digitale beursie. Wallet-adres is die hash-waarde van die beursie se publieke sleutel. Die private sleutel van die beursie is slegs aan die aansoeker bekend.
2. Die geregistreerde onderwerp kry toegang tot die diens geheime sleutel.
3. Die onderwerp genereer 'n nultransaksie en verifieer dit met 'n digitale handtekening deur die beursie se geheime sleutel te gebruik.
4. As 'n transaksie anders as nul gevorm word, word dit gesertifiseer deur 'n elektroniese digitale handtekening met behulp van twee geheime sleutels: 'n beursie en 'n diens een.
5. Die subjek dien 'n transaksie by die poel in.
6. Die ENCRY-netwerknodus lees die transaksie uit die poel en kontroleer die digitale handtekening, sowel as die konnektiwiteit van die transaksie.
7. As die digitale handtekening geldig is en die verbinding is bevestig, dan berei dit die transaksie voor vir inskrywing in die register.

Hier dien die register as 'n verspreide databasis wat inligting oor geldige, gekanselleerde en opgeskorte kennisgewings stoor.

Natuurlik is desentralisasie nie 'n wondermiddel nie. Die fundamentele probleem van primêre gebruikersverifikasie verdwyn nêrens nie: as tans die verifikasie van die aansoeker deur die CR uitgevoer word, word daar in DPKI voorgestel om die verifikasie aan gemeenskapslede te delegeer, en finansiële motivering te gebruik om aktiwiteit te stimuleer. Oopbronverifikasietegnologie is welbekend. Die doeltreffendheid van sodanige verifikasie is in die praktyk bevestig. Kom ons onthou weer 'n aantal hoëprofiel-ondersoeke deur die aanlyn publikasie Bellingcat.

Maar oor die algemeen kom die volgende prentjie na vore: DPKI is 'n geleentheid om, indien nie almal nie, dan baie van die tekortkominge van gesentraliseerde PKI reg te stel.

Teken in op ons Habrablog, ons beplan om voort te gaan om ons navorsing en ontwikkeling aktief te dek, en te volg Twitter, as jy nie ander nuus oor ENCRY-projekte wil mis nie.

Bron: will.com