Nobena skrivnost ni, da je eno od pogosto uporabljenih pomožnih orodij, brez katerega je zaščita podatkov v odprtih omrežjih nemogoča, tehnologija digitalnih potrdil. Ni pa skrivnost, da je glavna pomanjkljivost tehnologije brezpogojno zaupanje v centre, ki izdajajo digitalna potrdila. Direktor tehnologije in inovacij pri ENCRY Andrey Chmora je predlagal nov pristop k organizaciji infrastruktura javnih ključev (Infrastruktura javnih ključev, PKI), ki bo pomagal odpraviti trenutne pomanjkljivosti in ki uporablja tehnologijo porazdeljene knjige (blockchain). Ampak najprej.
Če ste seznanjeni s tem, kako deluje vaša trenutna infrastruktura javnih ključev, in poznate njene ključne pomanjkljivosti, lahko preskočite na tisto, kar predlagamo za spremembo spodaj.
Kaj so digitalni podpisi in potrdila?Interakcija na internetu vedno vključuje prenos podatkov. Vsi imamo interes, da zagotovimo varen prenos podatkov. Toda kaj je varnost? Najbolj iskane varnostne storitve so zaupnost, integriteta in avtentičnost. V ta namen se trenutno uporabljajo metode asimetrične kriptografije oziroma kriptografije z javnim ključem.
Začnimo z dejstvom, da morajo imeti subjekti interakcije za uporabo teh metod dva posamezna seznanjena ključa - javni in tajni. Z njihovo pomočjo se zagotavljajo varnostne storitve, ki smo jih omenili zgoraj.
Kako se doseže zaupnost prenosa informacij? Naročnik pošiljatelj pred pošiljanjem podatkov šifrira (kriptografsko preoblikuje) odprte podatke z javnim ključem prejemnika, prejemnik pa dešifrira prejeto šifrirano besedilo s pomočjo seznanjenega tajnega ključa.
Kako se doseže celovitost in verodostojnost posredovanih informacij? Za rešitev tega problema je bil ustvarjen drug mehanizem. Odprti podatki niso šifrirani, ampak se rezultat uporabe kriptografske zgoščevalne funkcije - "stisnjena" slika zaporedja vhodnih podatkov - prenaša v šifrirani obliki. Rezultat takega zgoščevanja se imenuje "povzetek" in je šifriran s skrivnim ključem naročnika pošiljatelja ("priča"). Kot rezultat šifriranja povzetka se pridobi digitalni podpis. Skupaj s čistim besedilom se posreduje prejemnemu naročniku (»verifikatorju«). Dešifrira digitalni podpis na javnem ključu priče in ga primerja z rezultatom uporabe kriptografske zgoščevalne funkcije, ki jo preveritelj samostojno izračuna na podlagi prejetih odprtih podatkov. Če se ujemajo, to pomeni, da je podatke v verodostojni in popolni obliki posredoval naročnik pošiljatelj in jih ni spremenil napadalec.
Večina virov, ki delajo z osebnimi podatki in informacijami o plačilih (banke, zavarovalnice, letalske družbe, plačilni sistemi, pa tudi vladni portali, kot je davčna služba), aktivno uporabljajo metode asimetrične kriptografije.
Kaj ima digitalno potrdilo s tem? Enostavno je. Tako prvi kot drugi postopek vključujeta javne ključe in ker imajo osrednjo vlogo, je zelo pomembno zagotoviti, da ključi dejansko pripadajo pošiljatelju (priči, v primeru preverjanja podpisa) ali prejemniku in ne zamenjati s ključi napadalcev. Zato obstajajo digitalna potrdila, ki zagotavljajo pristnost in celovitost javnega ključa.
Opomba: pristnost in celovitost javnega ključa se potrjujeta na popolnoma enak način kot pristnost in celovitost javnih podatkov, to je z elektronskim digitalnim podpisom (EDS).
Od kod prihajajo digitalna potrdila?Zaupanja vredni certifikacijski organi ali certifikacijski organi (CA) so odgovorni za izdajo in vzdrževanje digitalnih potrdil. Prosilec zaprosi za izdajo potrdila od CA, opravi identifikacijo v Registracijskem centru (CR) in prejme potrdilo od CA. CA jamči, da javni ključ iz certifikata pripada natanko tistemu subjektu, za katerega je bil izdan.
Če ne potrdite pristnosti javnega ključa, ga lahko napadalec med prenosom/shranjevanjem tega ključa zamenja s svojim. Če je prišlo do zamenjave, bo napadalec lahko dešifriral vse, kar naročnik pošiljatelj posreduje prejemnemu naročniku, ali po lastni presoji spremenil odprte podatke.
Digitalna potrdila se uporabljajo povsod, kjer je na voljo asimetrična kriptografija. Ena najpogostejših digitalnih potrdil so SSL potrdila za varno komunikacijo po protokolu HTTPS. Pri izdajanju SSL certifikatov se ukvarja na stotine podjetij, registriranih v različnih jurisdikcijah. Glavni delež odpade na pet do deset velikih zaupanja vrednih centrov: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA in CR sta komponenti PKI, ki vključuje tudi:
- Odpri imenik – javna zbirka podatkov, ki zagotavlja varno hrambo digitalnih potrdil.
- Seznam preklicanih potrdil – javno zbirko podatkov, ki zagotavlja varno hrambo digitalnih potrdil preklicanih javnih ključev (na primer zaradi ogrožanja seznanjenega zasebnega ključa). Infrastrukturni subjekti lahko samostojno dostopajo do te podatkovne baze ali pa uporabijo specializirani protokol Online Certification Status Protocol (OCSP), ki poenostavi postopek preverjanja.
- Uporabniki certifikatov – servisirani subjekti PKI, ki imajo s CA sklenjeno uporabniško pogodbo in preverjajo digitalni podpis in/ali šifrirajo podatke na podlagi javnega ključa iz potrdila.
- Naročniki – oskrbovane subjekte PKI, ki imajo tajni ključ v paru z javnim ključem iz potrdila in imajo s CA sklenjeno naročniško pogodbo. Naročnik je lahko hkrati tudi uporabnik potrdila.
Tako so zaupanja vredne entitete infrastrukture javnih ključev, ki vključujejo CA, CR in odprte imenike, odgovorne za:
1. Preverjanje pristnosti prijaviteljeve identitete.
2. Profiliranje potrdila javnega ključa.
3. Izdaja potrdila javnega ključa za prosilca, katerega identiteta je zanesljivo potrjena.
4. Spremenite status potrdila javnega ključa.
5. Zagotavljanje informacij o trenutnem statusu potrdila javnega ključa.
Kakšne so slabosti PKI?Temeljna pomanjkljivost PKI je prisotnost zaupanja vrednih entitet.
Uporabniki morajo brezpogojno zaupati CA in CR. Toda, kot kaže praksa, je brezpogojno zaupanje polno resnih posledic.
V zadnjih desetih letih je bilo na tem področju kar nekaj velikih škandalov, povezanih z ranljivostjo infrastrukture.
— leta 2010 se je po spletu začela širiti zlonamerna programska oprema Stuxnet, podpisana z ukradenimi digitalnimi potrdili RealTek in JMicron.
- Leta 2017 je Google obtožil Symantec, da je izdal veliko število ponarejenih potrdil. Takrat je bil Symantec eden največjih CA po obsegu proizvodnje. V brskalniku Google Chrome 70 je bila pred 1. decembrom 2017 ustavljena podpora za certifikate, ki jih je izdalo to podjetje in njegova povezana centra GeoTrust in Thawte.
CA-ji so bili ogroženi, zaradi česar so trpeli vsi – CA-ji sami, pa tudi uporabniki in naročniki. Zaupanje v infrastrukturo je omajano. Poleg tega so lahko digitalna potrdila blokirana v kontekstu političnih konfliktov, kar bo vplivalo tudi na delovanje številnih virov. Prav tega so se pred leti bali v administraciji ruskega predsednika, kjer so leta 2016 razpravljali o možnosti ustanovitve državnega certifikacijskega centra, ki bi izdajal SSL certifikate mestom v Runetu. Trenutno stanje je takšno, da tudi državni portali v Rusiji digitalna potrdila, ki jih izdajata ameriška podjetja Comodo ali Thawte (podružnica Symanteca).
Obstaja še en problem - vprašanje primarna avtentikacija (avtentikacija) uporabnikov. Kako prepoznati uporabnika, ki se je obrnil na CA z zahtevo za izdajo digitalnega potrdila brez neposrednega osebnega stika? Zdaj se to rešuje situacijsko glede na zmogljivosti infrastrukture. Nekaj se vzame iz odprtih registrov (na primer podatki o pravnih osebah, ki zahtevajo potrdila), v primerih, ko so prosilci fizične osebe, se lahko uporabijo bančni uradi ali pošte, kjer se njihova identiteta potrdi z identifikacijskimi dokumenti, na primer potnim listom.
Težava ponarejanja poverilnic z namenom lažnega predstavljanja je temeljna. Naj opozorimo, da popolne rešitve tega problema ni zaradi informacijsko-teoretičnih razlogov: brez zanesljivih informacij a priori je nemogoče potrditi ali zanikati pristnost določenega predmeta. Praviloma je za preverjanje potrebno predložiti vrsto dokumentov, ki dokazujejo identiteto prosilca. Obstaja veliko različnih metod preverjanja, vendar nobena od njih ne zagotavlja popolnega jamstva za pristnost dokumentov. V skladu s tem tudi ni mogoče zagotoviti pristnosti prijaviteljeve identitete.
Kako te pomanjkljivosti odpraviti?Če je težave PKI v sedanjem stanju mogoče pojasniti s centralizacijo, potem je logično domnevati, da bi decentralizacija pripomogla k delni odpravi ugotovljenih pomanjkljivosti.
Decentralizacija ne pomeni prisotnosti zaupanja vrednih subjektov - če ustvarite decentralizirana infrastruktura javnih ključev (decentralizirana infrastruktura javnih ključev, DPKI), potem nista potrebna niti CA niti CR. Opustimo koncept digitalnega potrdila in uporabimo porazdeljeni register za shranjevanje informacij o javnih ključih. V našem primeru register imenujemo linearna baza podatkov, sestavljena iz posameznih zapisov (blokov), povezanih s tehnologijo veriženja blokov. Namesto digitalnega potrdila bomo uvedli pojem »obvestilo«.
Kako bo izgledal postopek sprejemanja, preverjanja in preklica obvestil v predlaganem DPKI:
1. Vsak prijavitelj samostojno odda vlogo za obvestilo, tako da ob registraciji izpolni obrazec, nato pa ustvari transakcijo, ki se shrani v specializiranem bazenu.
2. Podatki o javnem ključu, skupaj s podatki o lastniku in drugimi metapodatki, so shranjeni v porazdeljenem registru in ne v digitalnem potrdilu, za izdajo katerega je v centralizirani PKI odgovoren CA.
3. Preverjanje avtentičnosti prijaviteljeve identitete se izvede naknadno s skupnimi močmi skupnosti uporabnikov DPKI in ne CR.
4. Samo lastnik takšnega obvestila lahko spremeni status javnega ključa.
5. Vsak lahko dostopa do porazdeljene knjige in preveri trenutno stanje javnega ključa.
Opomba: preverjanje identitete prosilca v skupnosti se na prvi pogled morda zdi nezanesljivo. Ne smemo pa pozabiti, da dandanes vsi uporabniki digitalnih storitev neizogibno pustijo digitalni odtis in ta proces bo le še pridobival zagon. Odprti elektronski registri pravnih oseb, zemljevidi, digitalizacija terenskih posnetkov, socialna omrežja – vse to so javno dostopna orodja. Med preiskavami jih že uspešno uporabljajo tako novinarji kot organi pregona. Dovolj je na primer spomniti na preiskave Bellingcata oziroma skupne preiskovalne skupine JIT, ki preučuje okoliščine strmoglavljenja malezijskega boeinga.
Kako bi torej decentralizirana infrastruktura javnih ključev delovala v praksi? Posvetimo se opisu same tehnologije, ki smo jo patentiran leta 2018 in to upravičeno štejemo za naše znanje in izkušnje.
Predstavljajte si, da obstaja lastnik, ki ima veliko javnih ključev, kjer je vsak ključ določena transakcija, ki je shranjena v registru. Če CA ni, kako lahko razumete, da vsi ključi pripadajo temu določenemu lastniku? Za rešitev te težave se ustvari ničelna transakcija, ki vsebuje podatke o lastniku in njegovi denarnici (iz katere se bremeni provizija za vpis transakcije v register). Ničelna transakcija je nekakšno "sidro", na katerega bodo pritrjene naslednje transakcije s podatki o javnih ključih. Vsaka takšna transakcija vsebuje posebno podatkovno strukturo ali z drugimi besedami obvestilo.
Obvestilo je strukturiran nabor podatkov, sestavljen iz funkcionalnih polj in vključuje informacije o javnem ključu lastnika, katerega obstojnost je zagotovljena z umestitvijo v enega od povezanih zapisov porazdeljenega registra.
Naslednje logično vprašanje je, kako se oblikuje ničelna transakcija? Ničelna transakcija – tako kot naslednje – je združevanje šestih podatkovnih polj. Med oblikovanjem ničelne transakcije je vključen par ključev denarnice (javni in seznanjeni tajni ključ). Ta par ključev se pojavi v trenutku, ko uporabnik registrira svojo denarnico, iz katere se bremeni provizija za vnos ničelne transakcije v register in posledično operacije z obvestili.
Kot je prikazano na sliki, se izvleček javnega ključa denarnice ustvari z zaporedno uporabo zgoščevalnih funkcij SHA256 in RIPEMD160. Tu je RIPEMD160 odgovoren za kompaktno predstavitev podatkov, katerih širina ne presega 160 bitov. To je pomembno, ker register ni poceni zbirka podatkov. V peto polje se vnese sam javni ključ. Prvo polje vsebuje podatke, ki vzpostavljajo povezavo s prejšnjo transakcijo. Za ničelno transakcijo to polje ne vsebuje ničesar, kar ga razlikuje od naslednjih transakcij. Drugo polje so podatki za preverjanje povezljivosti transakcij. Zaradi jedrnatosti bomo podatke v prvem in drugem polju imenovali »povezava« oziroma »preveri«. Vsebina teh polj je ustvarjena z iterativnim zgoščevanjem, kot je prikazano s povezovanjem druge in tretje transakcije na spodnji sliki.
Podatki iz prvih petih polj so potrjeni z elektronskim podpisom, ki se generira s skrivnim ključem denarnice.
To je to, ničelna transakcija se pošlje v bazen in po uspešnem preverjanju vnese v register. Zdaj lahko z njim »povežete« naslednje transakcije. Razmislimo, kako se oblikujejo transakcije, ki niso nič.
Prva stvar, ki vam bo verjetno padla v oči, je obilica parov ključev. Poleg že znanega para ključev denarnice se uporablja navaden in servisni par ključev.
Navaden javni ključ je tisto, zaradi česar se je vse začelo. Ta ključ je vpleten v različne postopke in procese, ki se odvijajo v zunanjem svetu (bančne in druge transakcije, pretok dokumentov itd.). Na primer, tajni ključ iz navadnega para se lahko uporablja za generiranje digitalnih podpisov za različne dokumente - plačilne naloge ipd., javni ključ pa se lahko uporablja za preverjanje tega digitalnega podpisa z naknadno izvedbo teh navodil, pod pogojem, da velja.
Servisni par se izda registriranemu subjektu DPKI. Ime tega para ustreza njegovemu namenu. Upoštevajte, da se pri oblikovanju/preverjanju ničelne transakcije servisni ključi ne uporabljajo.
Ponovno razjasnimo namen ključev:
- Ključi denarnice se uporabljajo za ustvarjanje/preverjanje ničelne transakcije in katere koli druge transakcije, ki ni ničelna. Zasebni ključ denarnice pozna le lastnik denarnice, ki je tudi lastnik številnih navadnih javnih ključev.
- Navadni javni ključ je po namenu podoben javnemu ključu, za katerega je izdano potrdilo v centralizirani PKI.
- Par servisnih ključev pripada DPKI. Tajni ključ se izda registriranim subjektom in se uporablja pri generiranju digitalnih podpisov za transakcije (razen za ničelne transakcije). Javno se uporablja za preverjanje elektronskega digitalnega podpisa transakcije pred objavo v registru.
Tako obstajata dve skupini ključev. Prvi vključuje servisne ključe in ključe denarnice – smiselni so samo v kontekstu DPKI. Druga skupina vključuje navadne ključe - njihov obseg je lahko različen in je odvisen od aplikacijskih nalog, v katerih se uporabljajo. Hkrati DPKI zagotavlja celovitost in pristnost navadnih javnih ključev.
Opomba: Par servisnih ključev je lahko znan različnim entitetam DPKI. Na primer, lahko je enako za vse. Prav zaradi tega se pri generiranju podpisa vsake neničelne transakcije uporabljata dva skrivna ključa, od katerih je eden ključ denarnice - pozna ga le lastnik denarnice, ki je tudi lastnik številnih navadnih javnih ključev. Vse tipke imajo svoj pomen. Na primer, vedno je mogoče dokazati, da je transakcijo v register vpisal registrirani subjekt DPKI, saj je bil podpis generiran tudi na ključu tajne službe. In ne more biti zlorab, kot so napadi DOS, ker lastnik plača vsako transakcijo.
Vse transakcije, ki sledijo nulti ena, so oblikovane na podoben način: javni ključ (ne denarnice, kot v primeru nulte transakcije, ampak iz navadnega para ključev) poteka preko dveh zgoščevalnih funkcij SHA256 in RIPEMD160. Tako se oblikujejo podatki tretjega polja. Četrto polje vsebuje spremljajoče podatke (na primer podatke o trenutnem statusu, datume poteka, časovni žig, identifikatorje uporabljenih kriptoalgoritmov itd.). Peto polje vsebuje javni ključ iz para servisnih ključev. Z njegovo pomočjo bo nato preverjen digitalni podpis, zato bo repliciran. Utemeljimo potrebo po takšnem pristopu.
Spomnimo se, da se transakcija vnese v bazen in tam shrani, dokler ni obdelana. Shranjevanje v bazenu je povezano z določenim tveganjem – transakcijski podatki so lahko ponarejeni. Lastnik transakcijske podatke overi z elektronskim digitalnim podpisom. Javni ključ za preverjanje tega digitalnega podpisa je izrecno naveden v enem od transakcijskih polj in se naknadno vnese v register. Posebnosti obdelave transakcije so takšne, da lahko napadalec po lastni presoji spremeni podatke in jih nato preveri s svojim skrivnim ključem ter v transakciji navede parni javni ključ za preverjanje digitalnega podpisa. Če sta pristnost in celovitost zagotovljeni izključno z digitalnim podpisom, bo takšno ponarejanje ostalo neopaženo. Če pa poleg digitalnega podpisa obstaja še kakšen dodaten mehanizem, ki zagotavlja tako arhiviranje kot obstojnost shranjenih informacij, potem je ponaredek mogoče odkriti. Če želite to narediti, je dovolj, da v register vnesete pristen javni ključ lastnika. Razložimo, kako to deluje.
Naj napadalec ponaredi podatke o transakciji. Z vidika ključev in digitalnega podpisa so možne naslednje možnosti:
1. Napadalec v transakcijo vstavi svoj javni ključ, digitalni podpis lastnika pa ostane nespremenjen.
2. Napadalec ustvari digitalni podpis na svojem zasebnem ključu, lastnikov javni ključ pa pusti nespremenjen.
3. Napadalec ustvari digitalni podpis na svojem zasebnem ključu in v transakcijo vstavi seznanjeni javni ključ.
Očitno sta možnosti 1 in 2 nesmiselni, saj bosta vedno zaznani med preverjanjem digitalnega podpisa. Smiselna je samo možnost 3 in če napadalec oblikuje digitalni podpis na lastnem tajnem ključu, potem je prisiljen v transakcijo shraniti seznanjen javni ključ, ki se razlikuje od javnega ključa lastnika. To je edini način, da napadalec vsili ponarejene podatke.
Predpostavimo, da ima lastnik fiksen par ključev – zasebnega in javnega. Naj bodo podatki potrjeni z digitalnim podpisom s tajnim ključem iz tega para, javni ključ pa je naveden v transakciji. Predpostavimo tudi, da je bil ta javni ključ predhodno vnesen v register in je bila njegova pristnost zanesljivo preverjena. Takrat bo na ponaredek kazalo dejstvo, da se javni ključ iz transakcije ne ujema z javnim ključem iz registra.
Povejmo. Pri obdelavi lastnikovih prvih transakcijskih podatkov je potrebno preveriti pristnost javnega ključa, vnesenega v register. Če želite to narediti, preberite ključ iz registra in ga primerjajte z resničnim javnim ključem lastnika znotraj varnostnega perimetra (območje relativne neranljivosti). Če je pristnost ključa potrjena in je zagotovljena njegova obstojnost ob namestitvi, potem lahko pristnost ključa iz naslednje transakcije enostavno potrdimo/ovržemo s primerjavo s ključem iz registra. Z drugimi besedami, ključ iz registra se uporablja kot referenčni vzorec. Vse druge transakcije lastnika se obdelajo podobno.
Transakcija je potrjena z elektronskim digitalnim podpisom - tukaj so potrebni skrivni ključi, in ne enega, ampak dva hkrati - servisni ključ in ključ denarnice. Zahvaljujoč uporabi dveh skrivnih ključev je zagotovljena potrebna raven varnosti - navsezadnje je skrivni ključ storitve lahko znan drugim uporabnikom, medtem ko je skrivni ključ denarnice znan le lastniku običajnega para ključev. Tak podpis z dvema ključema smo poimenovali »konsolidirani« digitalni podpis.
Preverjanje neničelnih transakcij se izvaja z uporabo dveh javnih ključev: denarnice in servisnega ključa. Postopek preverjanja lahko razdelimo na dve glavni stopnji: prva je preverjanje povzetka javnega ključa denarnice, druga pa preverjanje elektronskega digitalnega podpisa transakcije, istega konsolidiranega, ki je bil oblikovan z uporabo dveh tajnih ključev ( denarnica in storitev). Če je veljavnost digitalnega podpisa potrjena, se po dodatni verifikaciji transakcija vpiše v register.
Lahko se pojavi logično vprašanje: kako preveriti, ali transakcija pripada določeni verigi s "korenom" v obliki ničelne transakcije? V ta namen je postopek preverjanja dopolnjen s še eno stopnjo - preverjanjem povezljivosti. Tukaj bomo potrebovali podatke iz prvih dveh polj, ki smo ju do sedaj ignorirali.
Predstavljajmo si, da moramo preveriti, ali transakcija št. 3 dejansko sledi transakciji št. 2. Za to se z uporabo metode kombiniranega zgoščevanja izračuna vrednost zgoščevalne funkcije za podatke iz tretjega, četrtega in petega polja transakcije št. 2. Nato se izvede veriženje podatkov iz prvega polja transakcije št. 3 in predhodno pridobljene skupne vrednosti zgoščevalne funkcije za podatke iz tretjega, četrtega in petega polja transakcije št. 2. Vse to poteka tudi prek dveh zgoščevalnih funkcij SHA256 in RIPEMD160. Če se prejeta vrednost ujema s podatki v drugem polju transakcije št. 2, je preverjanje opravljeno in povezava potrjena. To je bolj jasno prikazano na spodnjih slikah.
V splošnem je tehnologija generiranja in vnosa obvestila v register videti točno tako. Vizualna ilustracija procesa oblikovanja verige obvestil je predstavljena na naslednji sliki:
V tem besedilu se ne bomo spuščali v podrobnosti, ki nedvomno obstajajo, in se vrnili k razpravi o sami ideji decentralizirane infrastrukture javnih ključev.
Torej, ker vlagatelj sam vloži vlogo za registracijo obvestil, ki niso shranjena v bazi podatkov CA, ampak v registru, je treba upoštevati glavne arhitekturne komponente DPKI:
1. Register veljavnih prijav (RDN).
2. Register preklicanih priglasitev (RON).
3. Register začasno zadržanih prijav (RPN).
Informacije o javnih ključih so shranjene v RDN/RON/RPN v obliki vrednosti zgoščene funkcije. Omeniti velja tudi, da so to lahko bodisi različni registri, bodisi različne verige ali celo ena veriga kot del enega samega registra, ko se podatki o statusu navadnega javnega ključa (preklic, začasna blokada itd.) vnesejo v četrto polje podatkovne strukture v obliki ustrezne kodne vrednosti. Obstaja veliko različnih možnosti za arhitekturno izvedbo DPKI, izbira enega ali drugega pa je odvisna od številnih dejavnikov, na primer od takih kriterijev optimizacije, kot so stroški dolgoročnega pomnilnika za shranjevanje javnih ključev itd.
Tako se lahko izkaže, da je DPKI po arhitekturni zahtevnosti, če že ne enostavnejši, pa vsaj primerljiv s centralizirano rešitvijo.
Glavno vprašanje ostaja - Kateri register je primeren za implementacijo tehnologije?
Glavna zahteva za register je zmožnost generiranja transakcij katere koli vrste. Najbolj znan primer glavne knjige je omrežje Bitcoin. Toda pri izvajanju zgoraj opisane tehnologije se pojavijo določene težave: omejitve obstoječega skriptnega jezika, pomanjkanje potrebnih mehanizmov za obdelavo poljubnih nizov podatkov, metode za generiranje transakcij poljubnega tipa in še veliko več.
V podjetju ENCRY smo poskušali rešiti zgoraj formulirane težave in razvili register, ki ima po našem mnenju številne prednosti, in sicer:
- podpira več vrst transakcij: lahko izmenjuje sredstva (torej izvaja finančne transakcije) in ustvarja transakcije s poljubno strukturo,
- razvijalci imajo dostop do lastniškega programskega jezika PrismLang, ki zagotavlja potrebno fleksibilnost pri reševanju različnih tehnoloških problemov,
- zagotovljen je mehanizem za obdelavo poljubnih nizov podatkov.
Če uporabimo poenostavljen pristop, potem poteka naslednje zaporedje dejanj:
- Prosilec se registrira pri DPKI in prejme digitalno denarnico. Naslov denarnice je zgoščena vrednost javnega ključa denarnice. Zasebni ključ denarnice pozna samo prosilec.
- Registrirani subjekt dobi dostop do tajnega ključa storitve.
- Subjekt ustvari ničelno transakcijo in jo potrdi z digitalnim podpisom s skrivnim ključem denarnice.
- Če se oblikuje transakcija, ki ni nič, se potrdi z elektronskim digitalnim podpisom z uporabo dveh tajnih ključev: denarničnega in storitvenega.
- Subjekt odda transakcijo v skupino.
- Omrežno vozlišče ENCRY prebere transakcijo iz bazena in preveri digitalni podpis ter povezljivost transakcije.
- Če je digitalni podpis veljaven in je povezava potrjena, pripravi transakcijo za vnos v register.
Tukaj register deluje kot porazdeljena zbirka podatkov, ki shranjuje informacije o veljavnih, preklicanih in začasno ustavljenih obvestilih.
Decentralizacija seveda ni rešitev. Temeljni problem avtentikacije primarnega uporabnika ne izgine nikamor: če trenutno preverjanje prosilca izvaja CR, potem v DPKI predlagajo, da se preverjanje prenese na člane skupnosti in uporabi finančno motivacijo za spodbujanje dejavnosti. Odprtokodna tehnologija preverjanja je dobro poznana. Učinkovitost takega preverjanja je bila potrjena v praksi. Ponovno spomnimo na številne odmevne preiskave spletne publikacije Bellingcat.
Toda na splošno se pokaže naslednja slika: DPKI je priložnost, da popravimo, če ne vse, pa številne pomanjkljivosti centraliziranega PKI.
Naročite se na naš Habrablog, načrtujemo, da bomo še naprej aktivno pokrivali naše raziskave in razvoj ter spremljajte , če ne želite zamuditi drugih novic o projektih ENCRY.
Vir: www.habr.com