DPKI: eliminiranje nedostataka centraliziranog PKI-a korištenjem blockchaina

Nije tajna da je jedan od najčešće korištenih pomoćnih alata, bez kojih je zaštita podataka u otvorenim mrežama nemoguća, tehnologija digitalnih certifikata. Međutim, nije tajna da je glavni nedostatak tehnologije bezuvjetno povjerenje u centre koji izdaju digitalne certifikate. Direktor tehnologije i inovacija u ENCRY Andrey Chmora predložio je novi pristup organizaciji infrastruktura javnog ključa (infrastruktura javnog ključa, PKI), koji će pomoći u otklanjanju trenutnih nedostataka i koji koristi tehnologiju distribuirane knjige (blockchain). Ali prvo stvari.

Ako ste upoznati s načinom na koji vaša trenutna infrastruktura javnih ključeva funkcionira i znate njene ključne nedostatke, možete preskočiti na ono što predlažemo da promijenite u nastavku.

Šta su digitalni potpisi i sertifikati?Interakcija na Internetu uvijek uključuje prijenos podataka. Svi smo u interesu da osiguramo da se podaci prenose bezbedno. Ali šta je sigurnost? Najtraženije sigurnosne usluge su povjerljivost, integritet i autentičnost. U tu svrhu trenutno se koriste metode asimetrične kriptografije, odnosno kriptografije s javnim ključem.

Počnimo s činjenicom da za korištenje ovih metoda subjekti interakcije moraju imati dva pojedinačna uparena ključa - javni i tajni. Uz njihovu pomoć obezbjeđuju se sigurnosne usluge koje smo spomenuli.

Kako se postiže povjerljivost prijenosa informacija? Prije slanja podataka, pretplatnik koji šalje šifrira (kriptografski transformira) otvorene podatke koristeći javni ključ primatelja, a primalac dešifruje primljeni šifrirani tekst koristeći upareni tajni ključ.

Kako se postiže integritet i autentičnost prenesenih informacija? Za rješavanje ovog problema stvoren je još jedan mehanizam. Otvoreni podaci nisu šifrirani, ali se rezultat primjene kriptografske hash funkcije - "komprimirana" slika niza ulaznih podataka - prenosi u šifriranom obliku. Rezultat takvog heširanja naziva se „dajdžest“ i šifrira se pomoću tajnog ključa pretplatnika koji šalje („svjedoka“). Kao rezultat šifriranja sažetka, dobiva se digitalni potpis. On se, zajedno sa jasnim tekstom, prenosi do pretplatnika primaoca („verifikator“). On dešifruje digitalni potpis na javnom ključu svjedoka i upoređuje ga s rezultatom primjene kriptografske hash funkcije, koju verifikator samostalno izračunava na osnovu primljenih otvorenih podataka. Ako se poklapaju, to znači da je pretplatnik koji šalje podatke prenio u autentičnom i potpunom obliku, a da ih nije modificirao napadač.

Većina resursa koji rade sa ličnim podacima i informacijama o plaćanju (banke, osiguravajuća društva, avio kompanije, platni sistemi, kao i vladini portali kao što je poreska služba) aktivno koriste metode asimetrične kriptografije.

Kakve veze digitalni certifikat ima s tim? To je jednostavno. I prvi i drugi proces uključuju javne ključeve, a budući da oni igraju centralnu ulogu, vrlo je važno osigurati da ključevi zaista pripadaju pošiljaocu (svjedoku, u slučaju provjere potpisa) ili primaocu, a ne zamijenjen ključevima napadača. Zbog toga postoje digitalni certifikati koji osiguravaju autentičnost i integritet javnog ključa.

Napomena: autentičnost i integritet javnog ključa potvrđuje se na potpuno isti način kao i autentičnost i integritet javnih podataka, odnosno korištenjem elektronskog digitalnog potpisa (EDS).
Odakle potiču digitalni certifikati?Pouzdana sertifikaciona tijela, ili Certification Authorities (CA), odgovorna su za izdavanje i održavanje digitalnih certifikata. Podnosilac zahteva zahteva izdavanje sertifikata od CA, prolazi identifikaciju u Registracionom centru (CR) i dobija sertifikat od CA. CA jamči da javni ključ iz certifikata pripada upravo onom entitetu za koji je izdat.

Ako ne potvrdite autentičnost javnog ključa, napadač ga tokom prijenosa/čuvanja ovog ključa može zamijeniti svojim vlastitim. Ako je došlo do zamjene, napadač će moći dešifrirati sve što pretplatnik šalje pretplatniku primatelju ili promijeniti otvorene podatke prema vlastitom nahođenju.

Digitalni sertifikati se koriste svuda gde je dostupna asimetrična kriptografija. Jedan od najčešćih digitalnih sertifikata su SSL sertifikati za sigurnu komunikaciju preko HTTPS protokola. Stotine kompanija registrovanih u različitim jurisdikcijama uključene su u izdavanje SSL sertifikata. Glavni udio otpada na pet do deset velikih pouzdanih centara: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.

CA i CR su komponente PKI-a, koji također uključuje:

• Otvorite direktorij – javnu bazu podataka koja obezbeđuje sigurno skladištenje digitalnih sertifikata.
• Lista opoziva certifikata – javna baza podataka koja obezbeđuje sigurno skladištenje digitalnih sertifikata opozvanih javnih ključeva (na primer, zbog kompromitovanja uparenog privatnog ključa). Subjekti infrastrukture mogu samostalno pristupiti ovoj bazi podataka, ili mogu koristiti specijalizovani Online Certification Status Protocol (OCSP), koji pojednostavljuje proces verifikacije.
• Korisnici certifikata – servisirani PKI subjekti koji su sklopili korisnički ugovor sa CA i verifikovali digitalni potpis i/ili šifrovali podatke na osnovu javnog ključa iz sertifikata.
• Podpisčiki – opslužuju PKI subjekte koji poseduju tajni ključ uparen sa javnim ključem iz sertifikata, a koji su sklopili pretplatnički ugovor sa CA. Pretplatnik može istovremeno biti i korisnik certifikata.

Dakle, pouzdani entiteti infrastrukture javnih ključeva, koji uključuju CA, CR i otvorene direktorije, odgovorni su za:

1. Provjera autentičnosti identiteta podnosioca zahtjeva.
2. Profiliranje certifikata javnog ključa.
3. Izdavanje certifikata javnog ključa za podnosioca zahtjeva čiji je identitet pouzdano potvrđen.
4. Promijenite status certifikata javnog ključa.
5. Pružanje informacija o trenutnom statusu certifikata javnog ključa.

Nedostaci PKI-ja, koji su oni?Osnovna mana PKI-ja je prisustvo entiteta od poverenja.
Korisnici moraju bezuslovno vjerovati CA i CR. Ali, kako praksa pokazuje, bezuslovno povjerenje je preplavljeno ozbiljnim posljedicama.

U proteklih deset godina u ovoj oblasti bilo je nekoliko velikih skandala vezanih za ranjivost infrastrukture.

— 2010. zlonamjerni softver Stuxnet je počeo da se širi na mreži, potpisan ukradenim digitalnim certifikatima od RealTek-a i JMicron-a.

- Google je 2017. godine optužio Symantec za izdavanje velikog broja falsifikovanih sertifikata. U to vrijeme, Symantec je bio jedan od najvećih CA u smislu obima proizvodnje. U pretraživaču Google Chrome 70 podrška za certifikate koje izdaje ova kompanija i njeni pridruženi centri GeoTrust i Thawte obustavljena je prije 1. decembra 2017. godine.

CA-ovi su bili kompromitovani, i kao rezultat toga svi su patili - sami CA-ovi, kao i korisnici i pretplatnici. Povjerenje u infrastrukturu je narušeno. Osim toga, digitalni certifikati mogu biti blokirani u kontekstu političkih sukoba, što će također utjecati na rad mnogih resursa. Upravo su se toga bojali prije nekoliko godina u administraciji ruskog predsjednika, gdje su 2016. razgovarali o mogućnosti stvaranja državnog centra za sertifikaciju koji bi izdavao SSL certifikate stranicama na Runetu. Trenutno stanje je takvo da čak i državni portali u Rusiji koristiti digitalni sertifikati koje izdaju američke kompanije Comodo ili Thawte (podružnica Symanteca).

Postoji još jedan problem - pitanje primarna autentifikacija (autentifikacija) korisnika. Kako identificirati korisnika koji je kontaktirao CA sa zahtjevom za izdavanje digitalnog certifikata bez direktnog ličnog kontakta? Sada se to rješava situacijski ovisno o mogućnostima infrastrukture. Nešto se uzima iz otvorenih registara (na primjer, podaci o pravnim licima koja traže potvrde); u slučajevima kada su podnosioci zahtjeva fizička lica mogu se koristiti poslovnice banke ili pošte, gdje se njihov identitet potvrđuje identifikacionim dokumentima, na primjer pasošom.

Problem falsifikovanja akreditiva u svrhu lažnog predstavljanja je fundamentalan. Napominjemo da iz informacijsko-teorijskih razloga nema potpunog rješenja ovog problema: bez a priori pouzdanih informacija nemoguće je potvrditi ili poreći autentičnost određenog subjekta. Po pravilu, za provjeru je potrebno predočiti set dokumenata kojima se dokazuje identitet podnosioca zahtjeva. Postoji mnogo različitih metoda provjere, ali nijedan od njih ne pruža potpunu garanciju autentičnosti dokumenata. Shodno tome, autentičnost identiteta podnosioca predstavke takođe se ne može garantovati.

Kako se ovi nedostaci mogu otkloniti?Ako se problemi PKI-a u sadašnjem stanju mogu objasniti centralizacijom, onda je logično pretpostaviti da bi decentralizacija pomogla da se djelimično otklone uočeni nedostaci.

Decentralizacija ne podrazumijeva prisustvo pouzdanih entiteta - ako kreirate decentralizovana infrastruktura javnog ključa (decentralizovana infrastruktura javnog ključa, DPKI), tada nisu potrebni ni CA ni CR. Napustimo koncept digitalnog certifikata i koristimo distribuirani registar za pohranu informacija o javnim ključevima. U našem slučaju, registar nazivamo linearnom bazom podataka koja se sastoji od pojedinačnih zapisa (blokova) povezanih korištenjem blockchain tehnologije. Umjesto digitalnog sertifikata, uvešćemo koncept „obaveštenja“.

Kako će izgledati proces primanja, provjere i otkazivanja obavještenja u predloženom DPKI:

1. Svaki podnosilac prijave samostalno podnosi prijavu za obavještenje popunjavanjem obrasca prilikom registracije, nakon čega kreira transakciju koja se pohranjuje u specijaliziranom pulu.

2. Informacije o javnom ključu, zajedno sa podacima o vlasniku i drugim metapodacima, pohranjuju se u distribuirani registar, a ne u digitalni certifikat, za čije je izdavanje u centraliziranom PKI-ju odgovoran CA.

3. Provjera autentičnosti identiteta podnosioca zahtjeva se vrši naknadno, zajedničkim naporima korisničke zajednice DPKI, a ne CR.

4. Samo vlasnik takve obavijesti može promijeniti status javnog ključa.

5. Svako može pristupiti distribuiranoj knjizi i provjeriti trenutni status javnog ključa.

Napomena: provjera identiteta podnositelja zahtjeva u zajednici može izgledati nepouzdano na prvi pogled. Ali moramo imati na umu da u današnje vrijeme svi korisnici digitalnih usluga neizbježno ostavljaju digitalni otisak, a ovaj proces će samo nastaviti da dobija zamah. Otvoreni elektronski registri pravnih lica, karte, digitalizacija slika terena, društvene mreže - sve su to javno dostupni alati. Oni se već uspješno koriste tokom istraga od strane novinara i agencija za provođenje zakona. Na primjer, dovoljno je podsjetiti se na istrage Bellingcata ili zajedničkog istražnog tima JIT-a, koji proučava okolnosti pada malezijskog Boeinga.

Dakle, kako bi decentralizovana infrastruktura javnog ključa funkcionirala u praksi? Hajde da se zadržimo na opisu same tehnologije koju mi patentiran 2018 i s pravom to smatramo svojim znanjem i iskustvom.

Zamislite da postoji neki vlasnik koji posjeduje mnogo javnih ključeva, gdje je svaki ključ određena transakcija koja je pohranjena u registru. U nedostatku CA, kako možete razumjeti da svi ključevi pripadaju ovom konkretnom vlasniku? Da bi se riješio ovaj problem, kreira se nulta transakcija koja sadrži podatke o vlasniku i njegovom novčaniku (sa kojeg se naplaćuje provizija za stavljanje transakcije u registar). Null transakcija je svojevrsno „sidro“ na koje će biti vezane sljedeće transakcije sa podacima o javnim ključevima. Svaka takva transakcija sadrži specijaliziranu strukturu podataka, ili drugim riječima, obavijest.

Obavijest je strukturirani skup podataka koji se sastoji od funkcionalnih polja i uključuje informacije o javnom ključu vlasnika, čija je postojanost zagarantovana smještajem u jedan od povezanih zapisa distribuiranog registra.

Sljedeće logično pitanje je kako se formira nulta transakcija? Null transakcija—kao i naknadne—je agregacija šest polja podataka. Prilikom formiranja nulte transakcije uključen je par ključeva novčanika (javni i upareni tajni ključevi). Ovaj par ključeva se pojavljuje u trenutku kada korisnik registruje svoj novčanik, sa kojeg će se teretiti provizija za stavljanje nulte transakcije u registar, a potom i operacije sa obaveštenjima.

Kao što je prikazano na slici, sažetak javnog ključa novčanika se generiše uzastopnom primjenom heš funkcija SHA256 i RIPEMD160. Ovdje je RIPEMD160 odgovoran za kompaktno predstavljanje podataka čija širina ne prelazi 160 bita. Ovo je važno jer registar nije jeftina baza podataka. Sam javni ključ se upisuje u peto polje. Prvo polje sadrži podatke koji uspostavljaju vezu sa prethodnom transakcijom. Za nultu transakciju, ovo polje ne sadrži ništa, što ga razlikuje od narednih transakcija. Drugo polje su podaci za provjeru povezanosti transakcija. Radi kratkoće, podatke u prvom i drugom polju ćemo nazvati “link” i “check”, respektivno. Sadržaj ovih polja je generisan iterativnim heširanjem, kao što je prikazano povezivanjem druge i treće transakcije na slici ispod.

Podaci iz prvih pet polja ovjereni su elektronskim potpisom, koji se generira pomoću tajnog ključa novčanika.

To je to, nulta transakcija se šalje u bazen i nakon uspješne verifikacije se upisuje u registar. Sada sa njim možete „povezati“ sljedeće transakcije. Razmotrimo kako se formiraju transakcije različite od nule.

Prva stvar koja vam je vjerovatno upala u oči je obilje ključnih parova. Pored već poznatog para ključeva za novčanik, koriste se obični i servisni parovi ključeva.

Običan javni ključ je ono zbog čega je sve pokrenuto. Ovaj ključ je uključen u različite procedure i procese koji se odvijaju u vanjskom svijetu (bankarske i druge transakcije, tok dokumenata, itd.). Na primjer, tajni ključ iz običnog para može se koristiti za generiranje digitalnih potpisa za različite dokumente - naloge za plaćanje i sl., a javni ključ se može koristiti za provjeru ovog digitalnog potpisa uz naknadno izvršavanje ovih instrukcija, pod uslovom da se važi.

Servisni par se izdaje registrovanom DPKI subjektu. Naziv ovog para odgovara njegovoj nameni. Imajte na umu da se prilikom formiranja/provjere nulte transakcije ne koriste servisni ključevi.

Pojasnimo ponovo svrhu tipki:

1. Ključevi novčanika se koriste za generiranje/verifikaciju i nulte transakcije i bilo koje druge transakcije koje nisu nule. Privatni ključ novčanika poznat je samo vlasniku novčanika, koji je i vlasnik mnogih običnih javnih ključeva.
2. Obični javni ključ je sličan po namjeni javnom ključu za koji se izdaje certifikat u centraliziranom PKI-ju.
3. Par servisnih ključeva pripada DPKI. Tajni ključ se izdaje registrovanim subjektima i koristi se prilikom generisanja digitalnih potpisa za transakcije (osim za nulte transakcije). Public se koristi za provjeru elektronskog digitalnog potpisa transakcije prije nego što se ista objavi u registru.

Dakle, postoje dvije grupe ključeva. Prvi uključuje servisne ključeve i ključeve novčanika - oni imaju smisla samo u kontekstu DPKI-ja. Druga grupa uključuje obične ključeve - njihov opseg može varirati i određen je zadacima aplikacije u kojima se koriste. Istovremeno, DPKI osigurava integritet i autentičnost običnih javnih ključeva.

Napomena: Par servisnih ključeva može biti poznat različitim DPKI entitetima. Na primjer, može biti isto za sve. Iz tog razloga se prilikom generiranja potpisa svake transakcije različitoj od nule koriste dva tajna ključa, od kojih je jedan ključ novčanika - poznat je samo vlasniku novčanika, koji je i vlasnik mnogih običnih javni ključevi. Svi ključevi imaju svoje značenje. Na primjer, uvijek je moguće dokazati da je transakciju u registar upisao registrirani DPKI subjekt, budući da je potpis generiran i na ključu tajne službe. I ne može biti zloupotreba, kao što su DOS napadi, jer vlasnik plaća svaku transakciju.

Sve transakcije koje slijede nakon nulte jedinice formiraju se na sličan način: javni ključ (ne novčanik, kao u slučaju nulte transakcije, već iz običnog para ključeva) se pokreće kroz dvije hash funkcije SHA256 i RIPEMD160. Tako se formiraju podaci trećeg polja. Četvrto polje sadrži prateće informacije (na primjer, informacije o trenutnom statusu, datumima isteka, vremenskoj oznaci, identifikatorima korištenih kripto-algoritama itd.). Peto polje sadrži javni ključ iz para servisnih ključeva. Uz njegovu pomoć, digitalni potpis će se zatim provjeriti, pa će se replicirati. Hajde da opravdamo potrebu za takvim pristupom.

Podsjetimo da se transakcija unosi u skup i tamo pohranjuje dok se ne obradi. Pohranjivanje u bazen je povezano s određenim rizikom - podaci o transakcijama mogu biti krivotvoreni. Vlasnik ovjerava podatke o transakciji elektronskim digitalnim potpisom. Javni ključ za provjeru ovog digitalnog potpisa je eksplicitno naznačen u jednom od transakcijskih polja i naknadno se unosi u registar. Posebnosti obrade transakcije su takve da napadač može promijeniti podatke po vlastitom nahođenju i potom ih provjeriti pomoću svog tajnog ključa, te naznačiti upareni javni ključ za provjeru digitalnog potpisa u transakciji. Ako se autentičnost i integritet osiguravaju isključivo digitalnim potpisom, onda će takvo krivotvorenje proći nezapaženo. Međutim, ako pored digitalnog potpisa postoji dodatni mehanizam koji osigurava i arhiviranje i postojanost pohranjenih informacija, tada se krivotvorina može otkriti. Da biste to učinili, dovoljno je unijeti vlasnički originalni javni ključ u registar. Hajde da objasnimo kako ovo funkcioniše.

Neka napadač krivotvori podatke o transakciji. Sa stanovišta ključeva i digitalnih potpisa, moguće su sljedeće opcije:

1. Napadač stavlja svoj javni ključ u transakciju dok digitalni potpis vlasnika ostaje nepromijenjen.
2. Napadač kreira digitalni potpis na svom privatnom ključu, ali ostavlja vlasnikov javni ključ nepromijenjen.
3. Napadač kreira digitalni potpis na svom privatnom ključu i stavlja upareni javni ključ u transakciju.

Očigledno, opcije 1 i 2 su besmislene, jer će uvijek biti otkrivene tokom verifikacije digitalnog potpisa. Samo opcija 3 ima smisla, a ako napadač formira digitalni potpis na svom tajnom ključu, onda je primoran da u transakciji sačuva upareni javni ključ, različit od javnog ključa vlasnika. Ovo je jedini način da napadač nametne lažne podatke.

Pretpostavimo da vlasnik ima fiksni par ključeva – privatni i javni. Neka podaci budu ovjereni digitalnim potpisom pomoću tajnog ključa iz ovog para, a javni ključ je naznačen u transakciji. Pretpostavimo i da je ovaj javni ključ prethodno unesen u registar i da je njegova autentičnost pouzdano provjerena. Tada će se na krivotvorenje ukazivati ​​činjenica da javni ključ iz transakcije ne odgovara javnom ključu iz registra.

Hajde da sumiramo. Prilikom obrade prvih podataka o transakciji vlasnika potrebno je provjeriti autentičnost javnog ključa unesenog u registar. Da biste to učinili, pročitajte ključ iz registra i usporedite ga s pravim javnim ključem vlasnika unutar sigurnosnog perimetra (područje relativne neranjivosti). Ako je autentičnost ključa potvrđena i njegova postojanost je zagarantovana pri postavljanju, onda se autentičnost ključa iz naknadne transakcije može lako potvrditi/pobiti upoređivanjem sa ključem iz registra. Drugim riječima, ključ iz registra se koristi kao referentni uzorak. Sve ostale vlasničke transakcije se obrađuju na sličan način.

Transakcija je ovjerena elektronskim digitalnim potpisom - tu su potrebni tajni ključevi, i to ne jedan, već dva odjednom - servisni ključ i ključ novčanika. Zahvaljujući upotrebi dva tajna ključa, osiguran je potreban nivo sigurnosti - uostalom, tajni ključ usluge može biti poznat i drugim korisnicima, dok je tajni ključ novčanika poznat samo vlasniku običnog para ključeva. Takav potpis sa dva ključa nazvali smo „konsolidovanim“ digitalnim potpisom.

Verifikacija transakcija koje nisu nulte vrši se pomoću dva javna ključa: novčanika i servisnog ključa. Proces verifikacije se može podijeliti u dvije glavne faze: prva je provjera sažetka javnog ključa novčanika, a druga je provjera elektronskog digitalnog potpisa transakcije, istog konsolidovanog koji je formiran pomoću dva tajna ključa ( novčanik i servis). Ako se potvrdi valjanost digitalnog potpisa, onda se nakon dodatne provjere transakcija upisuje u registar.

Može se postaviti logično pitanje: kako provjeriti pripada li transakcija određenom lancu s "korijenom" u obliku nulte transakcije? U tu svrhu, proces verifikacije je dopunjen još jednom fazom - provjerom povezanosti. Tu će nam trebati podaci iz prva dva polja, koja smo do sada zanemarili.

Zamislimo da trebamo provjeriti da li transakcija br. 3 zaista dolazi nakon transakcije br. 2. Da bi se to postiglo, koristeći kombinovani metod heširanja, izračunava se vrednost heš funkcije za podatke iz trećeg, četvrtog i petog polja transakcije br. 2. Zatim se vrši konkatenacija podataka iz prvog polja transakcije br. 3 i prethodno dobijene kombinovane vrednosti heš funkcije za podatke iz trećeg, četvrtog i petog polja transakcije br. 2. Sve ovo se također izvodi kroz dvije hash funkcije SHA256 i RIPEMD160. Ako primljena vrijednost odgovara podacima u drugom polju transakcije br. 2, tada je provjera prošla i veza je potvrđena. Ovo je jasnije prikazano na slikama ispod.

Uopšteno govoreći, tehnologija generisanja i unosa obaveštenja u registar izgleda upravo ovako. Vizuelna ilustracija procesa formiranja lanca notifikacija prikazana je na sljedećoj slici:

U ovom tekstu nećemo se zadržavati na detaljima, koji nesumnjivo postoje, već se vraćamo na samu ideju ​​decentralizovane infrastrukture javnog ključa.

Dakle, budući da sam podnosilac zahtjeva podnosi zahtjev za registraciju obavijesti, koje se ne pohranjuju u CA bazi podataka, već u registru, treba uzeti u obzir glavne arhitektonske komponente DPKI-a:

1. Registar važećih obavještenja (RDN).
2. Registar opozvanih obavijesti (RON).
3. Registar obustavljenih obavještenja (RPN).

Informacije o javnim ključevima pohranjuju se u RDN/RON/RPN u obliku vrijednosti hash funkcije. Također je vrijedno napomenuti da to mogu biti ili različiti registri, ili različiti lanci, ili čak jedan lanac kao dio jedinstvenog registra, kada se informacija o statusu običnog javnog ključa (opozivanje, suspenzija, itd.) unese u četvrto polje strukture podataka u obliku odgovarajuće vrijednosti koda. Postoji mnogo različitih opcija za arhitektonsku implementaciju DPKI-ja, a izbor jedne ili druge ovisi o brojnim faktorima, na primjer, takvim kriterijima optimizacije kao što je trošak dugoročne memorije za pohranjivanje javnih ključeva, itd.

Dakle, DPKI može biti, ako ne jednostavniji, onda barem uporediv sa centraliziranim rješenjem u smislu arhitektonske složenosti.

Glavno pitanje ostaje - Koji registar je pogodan za implementaciju tehnologije?

Glavni zahtjev za registar je sposobnost generiranja transakcija bilo koje vrste. Najpoznatiji primjer knjige je Bitcoin mreža. Ali prilikom implementacije gore opisane tehnologije javljaju se određene poteškoće: ograničenja postojećeg skriptnog jezika, nedostatak potrebnih mehanizama za obradu proizvoljnih skupova podataka, metode za generiranje transakcija proizvoljnog tipa i još mnogo toga.

Mi u ENCRY smo pokušali da rešimo gore formulisane probleme i razvili smo registar koji, po našem mišljenju, ima niz prednosti, a to su:

• podržava nekoliko vrsta transakcija: može i razmjenjivati ​​sredstva (tj. obavljati finansijske transakcije) i kreirati transakcije sa proizvoljnom strukturom,
• programeri imaju pristup vlasničkom programskom jeziku PrismLang, koji pruža potrebnu fleksibilnost pri rješavanju različitih tehnoloških problema,
• obezbeđen je mehanizam za obradu proizvoljnih skupova podataka.

Ako uzmemo pojednostavljeni pristup, tada se odvija sljedeći slijed radnji:

1. Podnosilac zahtjeva se registruje kod DPKI i dobija digitalni novčanik. Adresa novčanika je heš vrijednost javnog ključa novčanika. Privatni ključ novčanika poznat je samo podnosiocu zahtjeva.
2. Registrovanom subjektu se daje pristup tajnom ključu usluge.
3. Subjekt generiše nultu transakciju i verifikuje je digitalnim potpisom koristeći tajni ključ novčanika.
4. Ako se formira transakcija različita od nule, ona se ovjerava elektronskim digitalnim potpisom pomoću dva tajna ključa: novčanika i servisnog.
5. Subjekt predaje transakciju grupi.
6. Mrežni čvor ENCRY čita transakciju iz skupa i provjerava digitalni potpis, kao i povezanost transakcije.
7. Ako je digitalni potpis ispravan i veza je potvrđena, tada se priprema transakcija za upis u registar.

Ovdje registar djeluje kao distribuirana baza podataka koja pohranjuje informacije o važećim, otkazanim i suspendiranim obavještenjima.

Naravno, decentralizacija nije panaceja. Osnovni problem primarne autentifikacije korisnika ne nestaje nigdje: ako trenutno verifikaciju podnosioca zahtjeva provodi CR, onda se u DPKI-u predlaže da se verifikacija delegira članovima zajednice, a finansijska motivacija se koristi za stimulaciju aktivnosti. Tehnologija verifikacije otvorenog koda je dobro poznata. Efikasnost takve provjere je potvrđena u praksi. Podsjetimo se još jednom na brojna istraživanja visokog profila internetske publikacije Bellingcat.

Ali općenito se pojavljuje sljedeća slika: DPKI je prilika za ispravljanje, ako ne svih, onda mnogih nedostataka centraliziranog PKI-a.

Pretplatite se na naš Habrablog, planiramo i dalje aktivno pratiti naše istraživanje i razvoj i pratiti Twitter, ako ne želite da propustite druge vesti o ENCRY projektima.

izvor: www.habr.com