Nije tajna da je jedan od često korištenih pomoćnih alata, bez kojih je zaštita podataka u otvorenim mrežama nemoguća, tehnologija digitalnih certifikata. No, nije tajna da je glavni nedostatak tehnologije bezuvjetno povjerenje u centre koji izdaju digitalne certifikate. Direktor tehnologije i inovacija u tvrtki ENCRY Andrey Chmora predložio je novi pristup organiziranju infrastruktura javnih ključeva (Infrastruktura javnih ključeva, PKI), koji će pomoći u uklanjanju trenutnih nedostataka i koji koristi tehnologiju distribuirane knjige (blockchain). Ali prvo o svemu.
Ako ste upoznati s načinom na koji vaša trenutna infrastruktura javnih ključeva funkcionira i znate njene ključne nedostatke, možete prijeći na ono što predlažemo promijeniti u nastavku.
Što su digitalni potpisi i certifikati?Interakcija na internetu uvijek uključuje prijenos podataka. Svima nam je u interesu osigurati siguran prijenos podataka. Ali što 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ć pružaju se sigurnosne usluge koje smo gore spomenuli.
Kako se postiže povjerljivost prijenosa informacija? Prije slanja podataka, pretplatnik pošiljatelj šifrira (kriptografski transformira) otvorene podatke korištenjem javnog ključa primatelja, a primatelj dekriptira primljeni šifrirani tekst korištenjem uparenog tajnog ključa.
Kako se postiže cjelovitost i autentičnost prenesenih informacija? Da bi se riješio ovaj problem, stvoren je još jedan mehanizam. Otvoreni podaci nisu kriptirani, već se rezultat primjene kriptografske hash funkcije - "komprimirana" slika niza ulaznih podataka - prenosi u kriptiranom obliku. Rezultat takvog raspršivanja naziva se "sažetak", a šifriran je pomoću tajnog ključa pretplatnika koji šalje ("svjedok"). Kao rezultat šifriranja sažetka dobiva se digitalni potpis. On se, zajedno s čistim tekstom, prenosi pretplatniku primatelju ("verifikator"). On dekriptira digitalni potpis na javnom ključu svjedoka i uspoređuje ga s rezultatom primjene kriptografske hash funkcije koju verifikator samostalno izračunava na temelju primljenih otvorenih podataka. Ako se podudaraju, to znači da je pretplatnik pošiljatelj podatke prenio u autentičnom i potpunom obliku, a ne da ih je izmijenio napadač.
Većina resursa koji rade s osobnim podacima i informacijama o plaćanju (banke, osiguravajuća društva, zračni prijevoznici, sustavi plaćanja, kao i državni portali poput porezne službe) aktivno koriste metode asimetrične kriptografije.
Kakve veze ima digitalni certifikat? Jednostavno je. I prvi i drugi proces uključuju javne ključeve, a budući da oni imaju središnju ulogu, vrlo je važno osigurati da ključevi zapravo pripadaju pošiljatelju (svjedoku, u slučaju provjere potpisa) ili primatelju, a ne zamijenjeni ključevima napadača. Zbog toga postoje digitalni certifikati koji osiguravaju autentičnost i integritet javnog ključa.
Napomena: autentičnost i cjelovitost javnog ključa potvrđuje se na potpuno isti način kao i autentičnost i cjelovitost javnih podataka, odnosno elektroničkim digitalnim potpisom (EDS).
Odakle dolaze digitalni certifikati?Pouzdana certifikacijska tijela ili certifikacijska tijela (CA) odgovorna su za izdavanje i održavanje digitalnih certifikata. Podnositelj zahtijeva izdavanje potvrde od CA, prolazi identifikaciju u Registracijskom centru (CR) i dobiva potvrdu od CA. CA jamči da javni ključ iz certifikata pripada upravo onom entitetu za kojeg je izdan.
Ako ne potvrdite autentičnost javnog ključa, tada ga napadač tijekom prijenosa/pohrane ovog ključa može zamijeniti svojim. Ako je došlo do zamjene, napadač će moći dešifrirati sve što pretplatnik pošiljatelj prenosi pretplatniku primatelju ili mijenjati otvorene podatke prema vlastitom nahođenju.
Digitalni certifikati koriste se svugdje gdje je dostupna asimetrična kriptografija. Jedan od najčešćih digitalnih certifikata su SSL certifikati za sigurnu komunikaciju preko HTTPS protokola. Stotine tvrtki registriranih u različitim jurisdikcijama uključene su u izdavanje SSL certifikata. 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-ja, koji također uključuje:
- Otvori imenik – javna baza podataka koja omogućuje sigurnu pohranu digitalnih certifikata.
- Popis opozvanih certifikata – javna baza podataka koja omogućuje sigurnu pohranu digitalnih certifikata opozvanih javnih ključeva (primjerice zbog kompromitacije uparenog privatnog ključa). Infrastrukturni subjekti ovoj bazi podataka mogu pristupiti samostalno ili koristiti specijalizirani Online Certification Status Protocol (OCSP) koji pojednostavljuje proces verifikacije.
- Korisnici certifikata – servisirani PKI subjekti koji imaju sklopljen korisnički ugovor s CA te provjeravaju digitalni potpis i/ili kriptiraju podatke temeljem javnog ključa iz certifikata.
- Sljedbenici – opsluženi PKI subjekti koji posjeduju tajni ključ uparen s javnim ključem iz certifikata, a s CA su sklopili pretplatnički ugovor. Pretplatnik može istovremeno biti i korisnik certifikata.
Stoga su pouzdani entiteti infrastrukture javnih ključeva, koji uključuju CA-ove, CR-ove i otvorene imenike, odgovorni za:
1. Provjera vjerodostojnosti identiteta podnositelja zahtjeva.
2. Profiliranje certifikata javnog ključa.
3. Izdavanje certifikata javnog ključa za podnositelja 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?Temeljna mana PKI-ja je prisutnost entiteta od povjerenja.
Korisnici moraju bezuvjetno vjerovati CA i CR. Ali, kao što pokazuje praksa, bezuvjetno povjerenje prepuno je ozbiljnih posljedica.
U proteklih desetak godina dogodilo se nekoliko velikih skandala na ovom području vezanih uz ranjivost infrastrukture.
— 2010. zlonamjerni softver Stuxnet počeo se širiti internetom, potpisan ukradenim digitalnim certifikatima RealTeka i JMicrona.
- Google je 2017. godine optužio Symantec za izdavanje velikog broja krivotvorenih certifikata. U to je vrijeme Symantec bio jedan od najvećih CA-a u smislu količine proizvodnje. U pregledniku Google Chrome 70 podrška za certifikate koje je izdala ova tvrtka i njeni povezani centri GeoTrust i Thawte prekinuta je prije 1. prosinca 2017.
CA-ovi su bili ugroženi, a kao rezultat toga svi su patili - sami CA-i, kao i korisnici i pretplatnici. Povjerenje u infrastrukturu je potkopano. Osim toga, digitalni certifikati mogu biti blokirani u kontekstu političkih sukoba, što će također utjecati na rad mnogih resursa. To je upravo ono čega su se bojali prije nekoliko godina u ruskoj predsjedničkoj administraciji, gdje su 2016. raspravljali o mogućnosti stvaranja državnog centra za izdavanje certifikata koji bi izdavao SSL certifikate stranicama na Runetu. Trenutno stanje stvari je takvo da čak i državni portali u Rusiji digitalni certifikati koje izdaju američke tvrtke Comodo ili Thawte (podružnica Symanteca).
Postoji još jedan problem – pitanje primarna autentifikacija (autentifikacija) korisnika. Kako identificirati korisnika koji se obratio CA sa zahtjevom za izdavanje digitalnog certifikata bez izravnog osobnog kontakta? Sada se to rješava situacijski ovisno o mogućnostima infrastrukture. Nešto se uzima iz otvorenih registara (primjerice, podaci o pravnim osobama koje traže potvrde), au slučajevima kada su podnositelji zahtjeva fizičke osobe mogu se koristiti poslovnice banaka ili poštanskih ureda, gdje se njihov identitet potvrđuje identifikacijskim dokumentima, primjerice putovnicom.
Problem krivotvorenja vjerodajnica u svrhu lažnog predstavljanja temeljni je. Napomenimo da ne postoji cjelovito rješenje ovog problema zbog informacijsko-teorijskih razloga: bez pouzdanih informacija a priori nemoguće je potvrditi ili opovrgnuti autentičnost određenog predmeta. U pravilu je za provjeru potrebno predočiti skup dokumenata koji dokazuju identitet podnositelja zahtjeva. Postoji mnogo različitih metoda provjere, ali nijedna od njih ne daje potpuno jamstvo autentičnosti dokumenata. Sukladno tome, također se ne može jamčiti autentičnost identiteta podnositelja zahtjeva.
Kako se ovi nedostaci mogu otkloniti?Ako se problemi PKI-ja u sadašnjem stanju mogu objasniti centralizacijom, onda je logično pretpostaviti da bi decentralizacija pomogla djelomičnom otklanjanju uočenih nedostataka.
Decentralizacija ne podrazumijeva prisutnost pouzdanih subjekata - ako ih stvorite decentralizirana infrastruktura javnih ključeva (Decentralizirana infrastruktura javnih ključeva, 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 pomoću blockchain tehnologije. Umjesto digitalnog certifikata uvest ćemo pojam “obavijest”.
Kako će izgledati proces zaprimanja, provjere i otkazivanja obavijesti u predloženom DPKI-ju:
1. Svaki podnositelj zahtjeva samostalno podnosi zahtjev za obavijest popunjavanjem obrasca prilikom registracije, nakon čega kreira transakciju koja se pohranjuje u specijalizirani pool.
2. Informacije o javnom ključu, zajedno s podacima o vlasniku i ostalim metapodacima, pohranjuju se u distribuirani registar, a ne u digitalni certifikat, za čije je izdavanje u centraliziranom PKI-ju odgovoran CA.
3. Provjera vjerodostojnosti identiteta podnositelja zahtjeva naknadno se provodi zajedničkim naporima zajednice korisnika DPKI, a ne CR.
4. Samo vlasnik takve obavijesti može promijeniti status javnog ključa.
5. Svatko može pristupiti distribuiranoj knjizi i provjeriti trenutni status javnog ključa.
Napomena: Provjera identiteta podnositelja zahtjeva od strane zajednice može se na prvi pogled činiti nepouzdanom. Ali moramo imati na umu da u današnje vrijeme svi korisnici digitalnih usluga neizbježno ostavljaju digitalni trag, a taj će proces samo nastaviti dobivati na zamahu. Otvoreni elektronički registri pravnih osoba, karte, digitalizacija snimaka terena, društvene mreže - sve su to javno dostupni alati. Već ih uspješno koriste tijekom istraga i novinari i agencije za provođenje zakona. Primjerice, dovoljno je prisjetiti se istraživanja Bellingcata ili zajedničkog istražnog tima JIT koji proučava okolnosti pada malezijskog Boeinga.
Dakle, kako bi decentralizirana infrastruktura javnih ključeva funkcionirala u praksi? Zadržimo se na opisu same tehnologije koju mi patentiran 2018 i to s pravom 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 shvatiti da svi ključevi pripadaju ovom određenom vlasniku? Kako bi se riješio ovaj problem, kreira se nulta transakcija koja sadrži podatke o vlasniku i njegovom novčaniku (iz kojeg se tereti provizija za stavljanje transakcije u registar). Nulta transakcija je svojevrsno "sidro" na koje će se vezati sljedeće transakcije s podacima o javnim ključevima. Svaka takva transakcija sadrži specijaliziranu strukturu podataka, 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 zajamčena postavljanjem u jedan od pridruženih zapisa distribuiranog registra.
Sljedeće logično pitanje je kako se formira nulta transakcija? Nulta transakcija - kao i one naredne - skup je šest podatkovnih polja. Tijekom formiranja nulte transakcije uključen je par ključeva novčanika (javni i upareni tajni ključ). Ovaj par ključeva pojavljuje se u trenutku kada korisnik registrira svoj novčanik, iz kojeg će se teretiti provizija za stavljanje nulte transakcije u registar i, naknadno, operacije s obavijestima.
Kao što je prikazano na slici, sažetak javnog ključa novčanika generira se uzastopnom primjenom hash funkcija SHA256 i RIPEMD160. Ovdje je RIPEMD160 odgovoran za kompaktni prikaz podataka čija širina ne prelazi 160 bita. Ovo je važno jer registar nije jeftina baza podataka. U peto polje upisuje se sam javni ključ. Prvo polje sadrži podatke koji uspostavljaju vezu s prethodnom transakcijom. Za nultu transakciju ovo polje ne sadrži ništa, što ga razlikuje od sljedećih transakcija. Drugo polje su podaci za provjeru povezanosti transakcija. Radi sažetosti, podatke u prvom i drugom polju nazvat ćemo "link" odnosno "provjera". Sadržaj ovih polja generira se iterativnim raspršivanjem, kao što je prikazano povezivanjem druge i treće transakcije na donjoj slici.
Podaci iz prvih pet polja ovjereni su elektroničkim potpisom koji se generira pomoću tajnog ključa novčanika.
To je to, null transakcija se šalje u pool i nakon uspješne verifikacije upisuje se u registar. Sada s njim možete "povezati" sljedeće transakcije. Razmotrimo kako se formiraju transakcije različite od nule.
Prvo što vam je vjerojatno zapelo za oko je obilje parova ključeva. Uz već poznati par novčanika, koriste se obični i servisni parovi ključeva.
Obični javni ključ je ono zbog čega je sve pokrenuto. Ovaj ključ je uključen u razne procedure i procese koji se odvijaju u vanjskom svijetu (bankarske i druge transakcije, protok dokumenata itd.). Na primjer, tajni ključ iz običnog para može poslužiti za generiranje digitalnih potpisa za različite dokumente – naloge za plaćanje i sl., a javni ključ za provjeru tog digitalnog potpisa uz naknadno izvršavanje ovih instrukcija, pod uvjetom da vrijedi.
Servisni par izdaje se registriranom DPKI subjektu. Naziv ovog para odgovara njegovoj namjeni. Imajte na umu da se prilikom formiranja/provjere nulte transakcije ne koriste servisni ključevi.
Pojasnimo ponovno svrhu ključeva:
- Ključevi novčanika koriste se za generiranje/provjeru nulte transakcije i bilo koje druge transakcije koja nije nulta. Privatni ključ novčanika poznat je samo vlasniku novčanika, koji je također vlasnik mnogih običnih javnih ključeva.
- Obični javni ključ slične je namjene javnom ključu za koji se izdaje certifikat u centraliziranom PKI-ju.
- Par servisnih ključeva pripada DPKI-ju. Tajni ključ se izdaje registriranim subjektima i koristi se prilikom generiranja digitalnih potpisa za transakcije (osim za nulte transakcije). Javno se koristi za provjeru elektroničkog digitalnog potpisa transakcije prije njezina upisa u registar.
Dakle, postoje dvije skupine ključeva. Prvi uključuje servisne ključeve i ključeve novčanika - oni imaju smisla samo u kontekstu DPKI-ja. Druga skupina uključuje obične ključeve - njihov opseg može varirati i određen je aplikacijskim zadacima 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 koja nije nula koriste dva tajna ključa, od kojih je jedan ključ novčanika - poznat je samo vlasniku novčanika, koji je ujedno i vlasnik mnogih običnih javnih ključeva. Sve tipke imaju svoje značenje. Primjerice, uvijek je moguće dokazati da je transakciju u registar unio registrirani DPKI subjekt, budući da je potpis generiran i na ključu tajne službe. I tu ne može biti zloporaba, poput DOS napada, 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) provodi se kroz dvije hash funkcije SHA256 i RIPEMD160. Tako nastaju podaci trećeg polja. Četvrto polje sadrži popratne informacije (primjerice 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ć potom će se provjeriti digitalni potpis, pa će se replicirati. Opravdajmo potrebu za takvim pristupom.
Podsjetimo se da se transakcija unosi u skup i tamo pohranjuje dok se ne obradi. Pohranjivanje u bazenu povezano je s određenim rizikom - podaci o transakciji mogu biti krivotvoreni. Vlasnik podatke o transakciji ovjerava elektroničkim digitalnim potpisom. Javni ključ za provjeru ovog digitalnog potpisa izričito je naznačen u jednom od transakcijskih polja te se naknadno upisuje u registar. Osobitosti obrade transakcija su takve da napadač može promijeniti podatke po vlastitom nahođenju i zatim 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 cjelovitost osiguravaju isključivo digitalnim potpisom, onda će takva krivotvorina proći nezapaženo. Međutim, ako uz digitalni potpis postoji dodatni mehanizam koji osigurava i arhiviranje i postojanost pohranjenih podataka, tada se krivotvorina može otkriti. Da biste to učinili, dovoljno je unijeti izvorni javni ključ vlasnika u registar. Objasnimo kako ovo funkcionira.
Neka napadač krivotvori podatke o transakciji. S glediš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č stvara digitalni potpis na svom privatnom ključu, ali ostavlja javni ključ vlasnika nepromijenjen.
3. Napadač stvara digitalni potpis na svom privatnom ključu i stavlja upareni javni ključ u transakciju.
Očito su opcije 1 i 2 besmislene, jer će uvijek biti detektirane tijekom provjere digitalnog potpisa. Samo opcija 3 ima smisla, a ako napadač formira digitalni potpis na vlastitom tajnom ključu, tada je prisiljen u transakciji spremiti upareni javni ključ, različit od vlasnikovog javnog ključa. To je jedini način da napadač nametne krivotvorene 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 također da je taj javni ključ prethodno upisan u registar i da je njegova autentičnost pouzdano provjerena. Tada će na krivotvorinu upućivati činjenica da javni ključ iz transakcije ne odgovara javnom ključu iz registra.
Zaključimo. Prilikom obrade prvih transakcijskih podataka vlasnika potrebno je provjeriti vjerodostojnost javnog ključa upisanog 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 zajamčena njegova postojanost nakon postavljanja, tada se autentičnost ključa iz naknadne transakcije može jednostavno potvrditi/opovrgnuti usporedbom s ključem iz registra. Drugim riječima, ključ iz registra koristi se kao referentni uzorak. Sve ostale transakcije vlasnika obrađuju se na sličan način.
Transakcija je ovjerena elektroničkim digitalnim potpisom - tu su potrebni tajni ključevi, i to ne jedan, već dva odjednom - servisni ključ i ključ novčanika. Zahvaljujući korištenju dva tajna ključa, osigurana je potrebna razina sigurnosti - uostalom, servisni tajni ključ može biti poznat drugim korisnicima, dok je tajni ključ novčanika poznat samo vlasniku običnog para ključeva. Takav potpis s dva ključa nazvali smo "konsolidiranim" digitalnim potpisom.
Provjera ne-null transakcija provodi se pomoću dva javna ključa: novčanika i servisnog ključa. Proces verifikacije može se podijeliti u dvije glavne faze: prva je provjera sažetka javnog ključa novčanika, a druga je provjera elektroničkog digitalnog potpisa transakcije, istog konsolidiranog koji je formiran pomoću dva tajna ključa ( novčanik i servis). Ako je valjanost digitalnog potpisa potvrđena, tada 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, postupak verifikacije dopunjen je još jednom fazom - provjerom povezanosti. Ovdje će nam trebati podaci iz prva dva polja koja smo do sada zanemarivali.
Zamislimo da trebamo provjeriti dolazi li transakcija br. 3 doista nakon transakcije br. 2. Da biste to učinili, koristeći kombiniranu metodu raspršivanja, izračunava se vrijednost funkcije raspršivanja za podatke iz trećeg, četvrtog i petog polja transakcije br. 2. Zatim se vrši ulančavanje podataka iz prvog polja transakcije br. 3 i prethodno dobivene kombinirane vrijednosti hash funkcije za podatke iz trećeg, četvrtog i petog polja transakcije br. 2. Sve se to također izvodi kroz dvije hash funkcije SHA256 i RIPEMD160. Ako primljena vrijednost odgovara podacima u drugom polju transakcije br. 2, provjera je prošla i veza je potvrđena. Ovo je jasnije prikazano na slikama ispod.
Općenito, tehnologija generiranja i unosa obavijesti u registar izgleda upravo ovako. Vizualni prikaz procesa formiranja lanca obavijesti prikazan je na sljedećoj slici:
U ovom tekstu nećemo se zadržavati na detaljima, koji nesumnjivo postoje, i vratiti se na raspravu o samoj ideji decentralizirane infrastrukture javnih ključeva.
Dakle, budući da sam podnositelj zahtjeva podnosi zahtjev za registraciju obavijesti, koje nisu pohranjene u bazi podataka CA, već u registru, treba razmotriti glavne arhitektonske komponente DPKI-ja:
1. Registar važećih obavijesti (RDN).
2. Registar opozvanih notifikacija (RON).
3. Registar obustavljenih obavijesti (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 jednog registra, kada se podaci o statusu običnog javnog ključa (opoziv, suspenzija itd.) unose u četvrto polje podatkovne strukture u obliku odgovarajuće vrijednosti koda. Postoji mnogo različitih opcija za arhitektonsku implementaciju DPKI-ja, a izbor jedne ili druge ovisi o nizu čimbenika, na primjer, takvim kriterijima optimizacije kao što je cijena dugoročne memorije za pohranu javnih ključeva itd.
Stoga se DPKI može pokazati, ako ne jednostavnijim, onda barem usporedivim s centraliziranim rješenjem u smislu arhitektonske složenosti.
Glavno pitanje ostaje - Koji je registar prikladan za implementaciju tehnologije?
Glavni zahtjev za registar je mogućnost generiranja transakcija bilo koje vrste. Najpoznatiji primjer knjige je Bitcoin mreža. Ali pri implementaciji gore opisane tehnologije pojavljuju se određene poteškoće: ograničenja postojećeg skriptnog jezika, nedostatak potrebnih mehanizama za obradu proizvoljnih skupova podataka, metoda za generiranje transakcija proizvoljne vrste i još mnogo toga.
Mi u ENCRY-u pokušali smo riješiti gore navedene probleme i razvili smo registar koji, po našem mišljenju, ima niz prednosti, naime:
- podržava nekoliko vrsta transakcija: može i razmjenjivati imovinu (odnosno obavljati financijske transakcije) i kreirati transakcije s proizvoljnom strukturom,
- programeri imaju pristup vlastitom programskom jeziku PrismLang koji pruža potrebnu fleksibilnost pri rješavanju raznih tehnoloških problema,
- osiguran je mehanizam za obradu proizvoljnih skupova podataka.
Ako uzmemo pojednostavljeni pristup, tada se odvija sljedeći slijed radnji:
- Podnositelj zahtjeva se registrira kod DPKI i dobiva digitalni novčanik. Adresa novčanika je hash vrijednost javnog ključa novčanika. Privatni ključ novčanika poznat je samo podnositelju zahtjeva.
- Registrirani subjekt dobiva pristup tajnom ključu usluge.
- Subjekt generira nultu transakciju i potvrđuje je digitalnim potpisom pomoću tajnog ključa novčanika.
- Ako se formira transakcija različita od nule, ona se ovjerava elektroničkim digitalnim potpisom pomoću dva tajna ključa: novčanika i servisa.
- Subjekt predaje transakciju skupu.
- Mrežni čvor ENCRY čita transakciju iz bazena i provjerava digitalni potpis, kao i povezanost transakcije.
- Ako je digitalni potpis valjan i veza je potvrđena, tada priprema transakciju za upis u registar.
Ovdje registar djeluje kao distribuirana baza podataka koja pohranjuje informacije o valjanim, poništenim i obustavljenim obavijestima.
Naravno, decentralizacija nije lijek za sve. Temeljni problem primarne autentifikacije korisnika nigdje ne nestaje: ako trenutačno provjeru podnositelja zahtjeva provodi CR, tada se u DPKI-ju predlaže delegiranje provjere članovima zajednice i korištenje financijske motivacije za poticanje aktivnosti. Tehnologija provjere otvorenog koda dobro je poznata. Učinkovitost takve provjere potvrđena je u praksi. Ponovno se prisjetimo niza visokoprofilnih istraživanja internetske publikacije Bellingcat.
Ali općenito, pojavljuje se sljedeća slika: DPKI je prilika da se isprave, ako ne svi, onda mnogi nedostaci centraliziranog PKI-ja.
Pretplatite se na naš Habrablog, planiramo nastaviti aktivno pokrivati naše istraživanje i razvoj i pratiti , ako ne želite propustiti druge vijesti o ENCRY projektima.
Izvor: www.habr.com