DPKI: eliminimi i mangësive të PKI të centralizuar duke përdorur blockchain

Nuk është sekret që një nga mjetet ndihmëse të përdorura zakonisht, pa të cilin mbrojtja e të dhënave në rrjetet e hapura është e pamundur, është teknologjia e certifikatës dixhitale. Megjithatë, nuk është sekret se pengesa kryesore e teknologjisë është besimi i pakushtëzuar në qendrat që lëshojnë certifikata dixhitale. Drejtori i Teknologjisë dhe Inovacionit në ENCRY Andrey Chmora propozoi një qasje të re për organizimin infrastruktura e çelësit publik (Infrastruktura e çelësit publik, PKI), i cili do të ndihmojë në eliminimin e mangësive aktuale dhe që përdor teknologjinë e librit të shpërndarë (blockchain). Por gjërat e para së pari.

Nëse jeni njohur me mënyrën se si funksionon infrastruktura juaj aktuale e çelësit publik dhe i dini mangësitë kryesore të saj, mund të kaloni përpara tek ajo që ne po propozojmë të ndryshojmë më poshtë.

Çfarë janë nënshkrimet dhe certifikatat dixhitale?Ndërveprimi në internet përfshin gjithmonë transferimin e të dhënave. Të gjithë ne kemi interes të sigurojmë që të dhënat të transmetohen në mënyrë të sigurt. Por çfarë është siguria? Shërbimet më të kërkuara të sigurisë janë konfidencialiteti, integriteti dhe autenticiteti. Për këtë qëllim, aktualisht përdoren metoda të kriptografisë asimetrike, ose kriptografisë me çelës publik.

Le të fillojmë me faktin se për të përdorur këto metoda, subjektet e ndërveprimit duhet të kenë dy çelësa individualë të çiftuar - publik dhe sekret. Me ndihmën e tyre ofrohen shërbimet e sigurisë që përmendëm më lart.

Si arrihet konfidencialiteti i transferimit të informacionit? Para dërgimit të të dhënave, pajtimtari dërgues kodon (transformon në mënyrë kriptografike) të dhënat e hapura duke përdorur çelësin publik të marrësit dhe marrësi deshifron tekstin e shifruar të marrë duke përdorur çelësin sekret të çiftuar.

Si arrihet integriteti dhe autenticiteti i informacionit të transmetuar? Për të zgjidhur këtë problem, u krijua një mekanizëm tjetër. Të dhënat e hapura nuk janë të koduara, por rezultati i aplikimit të funksionit hash kriptografik - një imazh "i ngjeshur" i sekuencës së të dhënave hyrëse - transmetohet në formë të koduar. Rezultati i një hashimi të tillë quhet "digest" dhe është i koduar duke përdorur çelësin sekret të pajtimtarit dërgues ("dëshmitari"). Si rezultat i kriptimit të digestit, merret një nënshkrim dixhital. Ai, së bashku me tekstin e qartë, i transmetohet pajtimtarit marrës ("verifikuesi"). Ai deshifron nënshkrimin dixhital në çelësin publik të dëshmitarit dhe e krahason atë me rezultatin e aplikimit të një funksioni hash kriptografik, të cilin verifikuesi e llogarit në mënyrë të pavarur bazuar në të dhënat e hapura të marra. Nëse ato përputhen, kjo tregon se të dhënat janë transmetuar në një formë autentike dhe të plotë nga pajtimtari dërgues dhe nuk janë modifikuar nga një sulmues.

Shumica e burimeve që punojnë me të dhënat personale dhe informacionin e pagesave (bankat, kompanitë e sigurimeve, linjat ajrore, sistemet e pagesave, si dhe portalet qeveritare si shërbimi tatimor) përdorin në mënyrë aktive metodat e kriptografisë asimetrike.

Çfarë lidhje ka një certifikatë dixhitale me të? Është e thjeshtë. Si procesi i parë ashtu edhe i dyti përfshijnë çelësat publikë dhe duke qenë se ata luajnë një rol qendror, është shumë e rëndësishme të sigurohet që çelësat i përkasin dërguesit (dëshmitarit, në rastin e verifikimit të nënshkrimit) ose marrësit dhe nuk janë zëvendësohet me çelësat e sulmuesve. Kjo është arsyeja pse certifikatat dixhitale ekzistojnë për të siguruar origjinalitetin dhe integritetin e çelësit publik.

Shënim: autenticiteti dhe integriteti i çelësit publik konfirmohet saktësisht në të njëjtën mënyrë si origjinaliteti dhe integriteti i të dhënave publike, domethënë duke përdorur një nënshkrim elektronik dixhital (EDS).
Nga vijnë certifikatat dixhitale?Autoritetet e besuara të certifikimit, ose Autoritetet e Certifikimit (CA-të), janë përgjegjëse për lëshimin dhe mirëmbajtjen e certifikatave dixhitale. Aplikanti kërkon lëshimin e një certifikate nga AK, i nënshtrohet identifikimit në Qendrën e Regjistrimit (QR) dhe merr një vërtetim nga AK. AK garanton që çelësi publik nga certifikata i përket pikërisht subjektit për të cilin është lëshuar.

Nëse nuk konfirmoni vërtetësinë e çelësit publik, atëherë një sulmues gjatë transferimit/ruajtjes së këtij çelësi mund ta zëvendësojë atë me të tijin. Nëse zëvendësimi ka ndodhur, sulmuesi do të jetë në gjendje të deshifrojë gjithçka që pajtimtari dërgues i transmeton pajtimtarit marrës, ose të ndryshojë të dhënat e hapura sipas gjykimit të tij.

Certifikatat dixhitale përdoren kudo ku disponohet kriptografia asimetrike. Një nga certifikatat dixhitale më të zakonshme janë certifikatat SSL për komunikim të sigurt përmes protokollit HTTPS. Qindra kompani të regjistruara në juridiksione të ndryshme janë të përfshira në lëshimin e certifikatave SSL. Pjesa kryesore bie në pesë deri në dhjetë qendra të mëdha të besuara: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.

CA dhe CR janë përbërës të PKI, i cili gjithashtu përfshin:

• Hap drejtorinë – një bazë të dhënash publike që siguron ruajtje të sigurt të certifikatave dixhitale.
• Lista e revokimit të certifikatës – një bazë të dhënash publike që siguron ruajtje të sigurt të certifikatave dixhitale të çelësave publikë të revokuar (për shembull, për shkak të komprometimit të një çelësi privat të çiftuar). Subjektet e infrastrukturës mund të hyjnë në mënyrë të pavarur në këtë bazë të dhënash, ose mund të përdorin Protokollin e Statusit të Certifikimit Online (OCSP), i cili thjeshton procesin e verifikimit.
• Përdoruesit e certifikatës – subjektet e shërbimit PKI që kanë lidhur një marrëveshje përdoruesi me AK-në dhe verifikojnë nënshkrimin dixhital dhe/ose enkriptojnë të dhënat bazuar në çelësin publik nga certifikata.
• Friends – u shërbeu subjekteve të PKI-së që zotërojnë një çelës sekret të çiftuar me çelësin publik nga certifikata dhe që kanë lidhur një marrëveshje pajtimtari me AK-në. Abonenti mund të jetë njëkohësisht përdorues i certifikatës.

Kështu, entitetet e besuara të infrastrukturës së çelësit publik, të cilat përfshijnë CA, CR dhe drejtoritë e hapura, janë përgjegjës për:

1. Verifikimi i autenticitetit të identitetit të aplikantit.
2. Profilizimi i certifikatës së çelësit publik.
3. Lëshimi i një certifikate të çelësit publik për një aplikant identiteti i të cilit është konfirmuar në mënyrë të besueshme.
4. Ndryshoni statusin e certifikatës së çelësit publik.
5. Sigurimi i informacionit për statusin aktual të certifikatës së çelësit publik.

Disavantazhet e PKI, cilat janë ato?E meta themelore e PKI është prania e subjekteve të besuara.
Përdoruesit duhet t'i besojnë pa kushte CA dhe CR. Por, siç tregon praktika, besimi i pakushtëzuar është i mbushur me pasoja të rënda.

Gjatë dhjetë viteve të fundit, ka pasur disa skandale të mëdha në këtë fushë në lidhje me cenueshmërinë e infrastrukturës.

— në vitin 2010, malware Stuxnet filloi të përhapet në internet, i nënshkruar duke përdorur certifikata dixhitale të vjedhura nga RealTek dhe JMicron.

- Në vitin 2017, Google akuzoi Symantec për lëshimin e një numri të madh certifikatash të falsifikuara. Në atë kohë, Symantec ishte një nga AK-të më të mëdha për sa i përket vëllimit të prodhimit. Në shfletuesin Google Chrome 70, mbështetja për certifikatat e lëshuara nga kjo kompani dhe qendrat e saj të lidhura GeoTrust dhe Thawte u ndërpre përpara datës 1 dhjetor 2017.

CA-të u komprometuan dhe si rezultat vuajtën të gjithë—vetë CA-të, si dhe përdoruesit dhe pajtimtarët. Besimi në infrastrukturë është minuar. Përveç kësaj, certifikatat dixhitale mund të bllokohen në kontekstin e konflikteve politike, gjë që do të ndikojë gjithashtu në funksionimin e shumë burimeve. Kjo është pikërisht ajo që u frikësua disa vite më parë në administratën presidenciale ruse, ku në vitin 2016 ata diskutuan mundësinë e krijimit të një qendre certifikimi shtetëror që do të lëshonte certifikata SSL në faqet në RuNet. Gjendja aktuale e punëve është e tillë që edhe portalet shtetërore në Rusi përdorim certifikata dixhitale të lëshuara nga kompanitë amerikane Comodo ose Thawte (një degë e Symantec).

Ekziston një problem tjetër - pyetja vërtetimi (autentifikimi) primar i përdoruesve. Si të identifikoni një përdorues që ka kontaktuar AK-në me një kërkesë për të lëshuar një certifikatë dixhitale pa kontakt të drejtpërdrejtë personal? Tani kjo zgjidhet situativisht në varësi të aftësive të infrastrukturës. Diçka merret nga regjistrat e hapur (për shembull, informacione për personat juridikë që kërkojnë certifikata); në rastet kur aplikantët janë individë, mund të përdoren zyra bankare ose poste, ku identiteti i tyre konfirmohet duke përdorur dokumente identifikimi, për shembull, pasaportë.

Problemi i falsifikimit të kredencialeve me qëllim të imitimit është një problem thelbësor. Le të theksojmë se nuk ka zgjidhje të plotë për këtë problem për arsye informacioni-teorike: pa pasur informacion të besueshëm apriori, është e pamundur të konfirmohet ose mohohet vërtetësia e një subjekti të caktuar. Si rregull, për verifikim është e nevojshme të paraqitet një grup dokumentesh që vërtetojnë identitetin e aplikantit. Ka shumë metoda të ndryshme verifikimi, por asnjëra prej tyre nuk siguron një garanci të plotë të origjinalitetit të dokumenteve. Prandaj, autenticiteti i identitetit të aplikantit gjithashtu nuk mund të garantohet.

Si mund të eliminohen këto mangësi?Nëse problemet e PKI-së në gjendjen e saj aktuale mund të shpjegohen me centralizimin, atëherë është logjike të supozohet se decentralizimi do të ndihmonte pjesërisht në eliminimin e mangësive të identifikuara.

Decentralizimi nuk nënkupton praninë e subjekteve të besuara - nëse krijoni infrastruktura e decentralizuar e çelësit publik (Infrastruktura e decentralizuar e çelësit publik, DPKI), atëherë nuk nevojiten as CA dhe as CR. Le të braktisim konceptin e një certifikate dixhitale dhe të përdorim një regjistër të shpërndarë për të ruajtur informacionin rreth çelësave publikë. Në rastin tonë, ne e quajmë një regjistër një bazë të dhënash lineare që përbëhet nga regjistrime (blloqe) individuale të lidhura duke përdorur teknologjinë blockchain. Në vend të një certifikate dixhitale, ne do të prezantojmë konceptin e "njoftimit".

Si do të duket procesi i marrjes, verifikimit dhe anulimit të njoftimeve në DPKI-në e propozuar:

1. Çdo aplikant paraqet një aplikim për njoftim në mënyrë të pavarur duke plotësuar një formular gjatë regjistrimit, pas së cilës krijon një transaksion që ruhet në një pishinë të specializuar.

2. Informacioni për çelësin publik, së bashku me të dhënat e pronarit dhe metadatat e tjera, ruhen në një regjistër të shpërndarë, dhe jo në një certifikatë dixhitale, për lëshimin e së cilës në një PKI të centralizuar është përgjegjës AK-ja.

3. Verifikimi i autenticitetit të identitetit të aplikantit kryhet pas faktit me përpjekjet e përbashkëta të komunitetit të përdoruesve të DPKI, dhe jo nga CR.

4. Vetëm zotëruesi i një njoftimi të tillë mund të ndryshojë statusin e një çelësi publik.

5. Çdokush mund të hyjë në librin e shpërndarë dhe të kontrollojë statusin aktual të çelësit publik.

Shënim: Verifikimi nga komuniteti i identitetit të një aplikanti mund të duket jo i besueshëm në shikim të parë. Por duhet të kujtojmë se në ditët e sotme të gjithë përdoruesit e shërbimeve dixhitale lënë në mënyrë të pashmangshme një gjurmë dixhitale dhe ky proces vetëm sa do të vazhdojë të fitojë vrull. Hapja e regjistrave elektronikë të personave juridikë, hartat, dixhitalizimi i imazheve të terrenit, rrjetet sociale - të gjitha këto janë mjete të disponueshme për publikun. Ato tashmë përdoren me sukses gjatë hetimeve si nga gazetarët ashtu edhe nga agjencitë e zbatimit të ligjit. Për shembull, mjafton të kujtojmë hetimet e Bellingcat apo grupit të përbashkët hetimor JIT, i cili po studion rrethanat e rrëzimit të Boeing-ut malajzian.

Pra, si do të funksiononte në praktikë një infrastrukturë e decentralizuar e çelësit publik? Le të ndalemi në përshkrimin e vetë teknologjisë, të cilën ne patentuar në 2018 dhe ne me të drejtë e konsiderojmë atë njohurinë tonë.

Imagjinoni që ka një pronar që zotëron shumë çelësa publikë, ku çdo çelës është një transaksion i caktuar që ruhet në regjistër. Në mungesë të një AK, si mund ta kuptoni se të gjithë çelësat i përkasin këtij pronari të veçantë? Për të zgjidhur këtë problem, krijohet një transaksion zero, i cili përmban informacione për pronarin dhe portofolin e tij (nga i cili debitohet komisioni për vendosjen e transaksionit në regjistër). Transaksioni null është një lloj "ankorimi" të cilit do t'i bashkëngjiten transaksionet e mëposhtme me të dhëna për çelësat publikë. Çdo transaksion i tillë përmban një strukturë të specializuar të dhënash, ose me fjalë të tjera, një njoftim.

Njoftimi është një grup i strukturuar i të dhënave që përbëhet nga fusha funksionale dhe përfshin informacione për çelësin publik të pronarit, qëndrueshmëria e të cilit garantohet nga vendosja në një nga regjistrat shoqërues të regjistrit të shpërndarë.

Pyetja tjetër logjike është se si formohet një transaksion zero? Transaksioni null - si ato të mëvonshme - është një grumbullim i gjashtë fushave të të dhënave. Gjatë formimit të një transaksioni zero, përfshihet çifti i çelësave të portofolit (çelësat sekretë publikë dhe të çiftuar). Ky çift çelësash shfaqet në momentin kur përdoruesi regjistron portofolin e tij, nga i cili do të debitohet komisioni për vendosjen e një transaksioni zero në regjistër dhe, më pas, operacionet me njoftime.

Siç tregohet në figurë, një përmbledhje e çelësit publik të portofolit krijohet duke aplikuar në mënyrë sekuenciale funksionet hash SHA256 dhe RIPEMD160. Këtu RIPEMD160 është përgjegjës për paraqitjen kompakte të të dhënave, gjerësia e të cilave nuk i kalon 160 bit. Kjo është e rëndësishme sepse regjistri nuk është një bazë të dhënash e lirë. Vetë çelësi publik futet në fushën e pestë. Fusha e parë përmban të dhëna që krijojnë një lidhje me transaksionin e mëparshëm. Për një transaksion zero, kjo fushë nuk përmban asgjë, gjë që e dallon atë nga transaksionet e mëvonshme. Fusha e dytë janë të dhënat për kontrollimin e lidhjes së transaksioneve. Për shkurtësi, të dhënat në fushën e parë dhe të dytë do t'i quajmë përkatësisht "lidhje" dhe "kontroll". Përmbajtja e këtyre fushave gjenerohet nga hashimi përsëritës, siç tregohet duke lidhur transaksionet e dyta dhe të treta në figurën më poshtë.

Të dhënat nga pesë fushat e para vërtetohen nga një nënshkrim elektronik, i cili gjenerohet duke përdorur çelësin sekret të portofolit.

Kjo është e gjitha, transaksioni null dërgohet në pishinë dhe pas verifikimit të suksesshëm futet në regjistër. Tani mund të "lidhni" transaksionet e mëposhtme me të. Le të shqyrtojmë se si formohen transaksione të tjera përveç zeros.

Gjëja e parë që ndoshta ju ka rënë në sy është bollëku i çifteve të çelësave. Përveç çiftit tashmë të njohur të çelësave të portofolit, përdoren çiftet e çelësave të zakonshëm dhe të shërbimit.

Një çelës publik i zakonshëm është ajo për të cilën filloi gjithçka. Ky çelës është i përfshirë në procedura dhe procese të ndryshme që zhvillohen në botën e jashtme (transaksione bankare dhe të tjera, rrjedha e dokumenteve, etj.). Për shembull, një çelës sekret nga një çift i zakonshëm mund të përdoret për të gjeneruar nënshkrime dixhitale për dokumente të ndryshme - urdhërpagesa, etj., dhe një çelës publik mund të përdoret për të verifikuar këtë nënshkrim dixhital me ekzekutimin e mëvonshëm të këtyre udhëzimeve, me kusht që ai eshte e vlefshme.

Çifti i shërbimit i lëshohet subjektit të regjistruar DPKI. Emri i këtij çifti korrespondon me qëllimin e tij. Vini re se kur formoni/kontrolloni një transaksion zero, çelësat e shërbimit nuk përdoren.

Le të sqarojmë përsëri qëllimin e çelësave:

1. Çelësat e portofolit përdoren për të gjeneruar/verifikuar si një transaksion null ashtu edhe për çdo transaksion tjetër jonul. Çelësi privat i një portofol është i njohur vetëm për pronarin e portofolit, i cili është gjithashtu pronar i shumë çelësave të zakonshëm publikë.
2. Një çelës publik i zakonshëm është i ngjashëm në qëllim me një çelës publik për të cilin një certifikatë lëshohet në një PKI të centralizuar.
3. Çifti i çelësave të shërbimit i përket DPKI. Çelësi sekret i lëshohet subjekteve të regjistruara dhe përdoret kur gjenerohen nënshkrime dixhitale për transaksione (përveç transaksioneve zero). Publiku përdoret për të verifikuar nënshkrimin elektronik dixhital të një transaksioni përpara se të vendoset në regjistër.

Kështu, ekzistojnë dy grupe çelësash. E para përfshin çelësat e shërbimit dhe çelësat e portofolit - ato kanë kuptim vetëm në kontekstin e DPKI. Grupi i dytë përfshin çelësat e zakonshëm - fushëveprimi i tyre mund të ndryshojë dhe përcaktohet nga detyrat e aplikimit në të cilat ato përdoren. Në të njëjtën kohë, DPKI siguron integritetin dhe autenticitetin e çelësave të zakonshëm publikë.

Shënim: Çifti i çelësave të shërbimit mund të jetë i njohur për entitete të ndryshme DPKI. Për shembull, mund të jetë e njëjtë për të gjithë. Është për këtë arsye që kur gjenerohet nënshkrimi i çdo transaksioni jo zero, përdoren dy çelësa sekretë, njëri prej të cilëve është çelësi i portofolit - ai dihet vetëm për pronarin e portofolit, i cili është gjithashtu pronar i shumë të zakonshëm çelësat publikë. Të gjithë çelësat kanë kuptimin e tyre. Për shembull, është gjithmonë e mundur të vërtetohet se transaksioni është futur në regjistër nga një subjekt i regjistruar i DPKI-së, pasi nënshkrimi është krijuar edhe në një çelës shërbimi sekret. Dhe nuk mund të ketë abuzime, siç janë sulmet DOS, sepse pronari paguan për çdo transaksion.

Të gjitha transaksionet që pasojnë atë zero formohen në mënyrë të ngjashme: çelësi publik (jo portofoli, si në rastin e transaksionit zero, por nga një çift i zakonshëm çelësash) kryhet përmes dy funksioneve hash SHA256 dhe RIPEMD160. Kështu formohen të dhënat e fushës së tretë. Fusha e katërt përmban informacion shoqërues (për shembull, informacion në lidhje me statusin aktual, datat e skadencës, vulën kohore, identifikuesit e kripto-algoritmeve të përdorura, etj.). Fusha e pestë përmban çelësin publik nga çifti i çelësave të shërbimit. Me ndihmën e tij, nënshkrimi dixhital më pas do të kontrollohet, kështu që do të përsëritet. Le të justifikojmë nevojën për një qasje të tillë.

Kujtoni që një transaksion futet në një grup dhe ruhet atje derisa të përpunohet. Ruajtja në një pishinë shoqërohet me një rrezik të caktuar - të dhënat e transaksionit mund të falsifikohen. Pronari vërteton të dhënat e transaksionit me një nënshkrim elektronik dixhital. Çelësi publik për verifikimin e këtij nënshkrimi dixhital tregohet në mënyrë eksplicite në një nga fushat e transaksionit dhe më pas futet në regjistër. Veçoritë e përpunimit të transaksionit janë të tilla që një sulmues është në gjendje të ndryshojë të dhënat sipas gjykimit të tij dhe më pas t'i verifikojë ato duke përdorur çelësin e tij sekret dhe të tregojë një çelës publik të çiftuar për verifikimin e nënshkrimit dixhital në transaksion. Nëse autenticiteti dhe integriteti sigurohen ekskluzivisht përmes nënshkrimit dixhital, atëherë një falsifikim i tillë do të kalojë pa u vënë re. Megjithatë, nëse, përveç nënshkrimit dixhital, ekziston një mekanizëm shtesë që siguron arkivimin dhe qëndrueshmërinë e informacionit të ruajtur, atëherë falsifikimi mund të zbulohet. Për ta bërë këtë, mjafton të futni në regjistër çelësin publik të vërtetë të pronarit. Le të shpjegojmë se si funksionon kjo.

Lëreni sulmuesin të falsifikojë të dhënat e transaksionit. Nga pikëpamja e çelësave dhe nënshkrimeve dixhitale, opsionet e mëposhtme janë të mundshme:

1. Sulmuesi vendos çelësin e tij publik në transaksion ndërsa nënshkrimi dixhital i pronarit mbetet i pandryshuar.
2. Sulmuesi krijon një nënshkrim dixhital në çelësin e tij privat, por e lë çelësin publik të pronarit të pandryshuar.
3. Sulmuesi krijon një nënshkrim dixhital në çelësin e tij privat dhe vendos një çelës publik të çiftuar në transaksion.

Natyrisht, opsionet 1 dhe 2 janë të pakuptimta, pasi ato gjithmonë do të zbulohen gjatë verifikimit të nënshkrimit dixhital. Vetëm opsioni 3 ka kuptim, dhe nëse një sulmues formon një nënshkrim dixhital në çelësin e tij sekret, atëherë ai detyrohet të ruajë një çelës publik të çiftuar në transaksion, të ndryshëm nga çelësi publik i pronarit. Kjo është mënyra e vetme që një sulmues të imponojë të dhëna të falsifikuara.

Le të supozojmë se pronari ka një palë çelësash fikse - privat dhe publik. Lërini të dhënat të vërtetohen me nënshkrim dixhital duke përdorur çelësin sekret nga ky çift, dhe çelësi publik tregohet në transaksion. Le të supozojmë gjithashtu se ky çelës publik është futur më parë në regjistër dhe autenticiteti i tij është verifikuar me besueshmëri. Atëherë një falsifikim do të tregohet nga fakti që çelësi publik nga transaksioni nuk korrespondon me çelësin publik nga regjistri.

Le të përmbledhim. Kur përpunohen të dhënat e transaksionit të parë të pronarit, është e nevojshme të verifikohet vërtetësia e çelësit publik të futur në regjistër. Për ta bërë këtë, lexoni çelësin nga regjistri dhe krahasoni atë me çelësin e vërtetë publik të pronarit brenda perimetrit të sigurisë (zona e paprekshmërisë relative). Nëse vërtetohet autenticiteti i çelësit dhe garantohet qëndrueshmëria e tij me vendosjen, atëherë vërtetësia e çelësit nga transaksioni i mëpasshëm mund të konfirmohet/refuzohet lehtësisht duke e krahasuar atë me çelësin nga regjistri. Me fjalë të tjera, çelësi nga regjistri përdoret si një mostër referencë. Të gjitha transaksionet e tjera të pronarëve përpunohen në mënyrë të ngjashme.

Transaksioni vërtetohet nga një nënshkrim elektronik dixhital - këtu nevojiten çelësa sekretë, dhe jo një, por dy menjëherë - një çelës shërbimi dhe një çelës portofol. Falë përdorimit të dy çelësave sekretë, sigurohet niveli i nevojshëm i sigurisë - në fund të fundit, çelësi sekret i shërbimit mund të njihet për përdoruesit e tjerë, ndërsa çelësi sekret i portofolit është i njohur vetëm për pronarin e çiftit të zakonshëm të çelësave. Ne e quajtëm një nënshkrim të tillë me dy çelësa një nënshkrim dixhital "të konsoliduar".

Verifikimi i transaksioneve jo-nul kryhet duke përdorur dy çelësa publikë: portofolin dhe çelësin e shërbimit. Procesi i verifikimit mund të ndahet në dy faza kryesore: e para është kontrollimi i përmbledhjes së çelësit publik të portofolit, dhe e dyta është kontrollimi i nënshkrimit elektronik dixhital të transaksionit, i njëjti i konsoliduar që u formua duke përdorur dy çelësa sekretë ( portofolin dhe shërbimin). Nëse vërtetohet vlefshmëria e nënshkrimit dixhital, atëherë pas verifikimit shtesë transaksioni futet në regjistër.

Mund të lindë një pyetje logjike: si të kontrolloni nëse një transaksion i përket një zinxhiri specifik me "rrënjën" në formën e një transaksioni zero? Për këtë qëllim, procesi i verifikimit plotësohet me një fazë tjetër - kontrollin e lidhjes. Këtu do të na duhen të dhënat nga dy fushat e para, të cilat deri tani i kemi injoruar.

Le të imagjinojmë se duhet të kontrollojmë nëse transaksioni nr. 3 vjen në të vërtetë pas transaksionit nr. 2. Për ta bërë këtë, duke përdorur metodën e kombinuar të hashimit, vlera e funksionit hash llogaritet për të dhënat nga fushat e tretë, të katërt dhe të pestë të transaksionit nr. 2. Më pas kryhet lidhja e të dhënave nga fusha e parë e transaksionit nr.3 dhe vlera e funksionit hash të kombinuar më parë për të dhënat nga fushat e tretë, të katërt dhe të pestë të transaksionit nr.2. E gjithë kjo kryhet gjithashtu përmes dy funksioneve hash SHA256 dhe RIPEMD160. Nëse vlera e marrë përputhet me të dhënat në fushën e dytë të transaksionit nr. 2, atëherë kontrolli kalon dhe lidhja konfirmohet. Kjo tregohet më qartë në figurat e mëposhtme.

Në përgjithësi, teknologjia për gjenerimin dhe futjen e një njoftimi në regjistër duket pikërisht kështu. Një ilustrim vizual i procesit të formimit të një zinxhiri njoftimesh është paraqitur në figurën e mëposhtme:

Në këtë tekst, ne nuk do të ndalemi në detajet, të cilat padyshim ekzistojnë, dhe do të kthehemi në diskutimin e vetë idesë së një infrastrukture të decentralizuar të çelësit publik.

Pra, duke qenë se vetë aplikanti paraqet një aplikim për regjistrimin e njoftimeve, të cilat ruhen jo në bazën e të dhënave të AK-së, por në regjistër, duhet të merren parasysh përbërësit kryesorë arkitekturorë të DPKI:

1. Regjistri i njoftimeve të vlefshme (RDN).
2. Regjistri i njoftimeve të revokuara (RON).
3. Regjistri i njoftimeve të pezulluara (RPN).

Informacioni rreth çelësave publik ruhet në RDN/RON/RPN në formën e vlerave të funksionit hash. Vlen gjithashtu të theksohet se këto mund të jenë ose regjistra të ndryshëm, ose zinxhirë të ndryshëm, ose edhe një zinxhir si pjesë e një regjistri të vetëm, kur informacioni për statusin e një çelësi publik të zakonshëm (revokimi, pezullimi, etj.) futet në fusha e katërt e strukturës së të dhënave në formën e vlerës përkatëse të kodit. Ekzistojnë shumë opsione të ndryshme për zbatimin arkitektonik të DPKI, dhe zgjedhja e njërës ose tjetrës varet nga një numër faktorësh, për shembull, kritere të tilla optimizimi si kostoja e memories afatgjatë për ruajtjen e çelësave publikë, etj.

Kështu, DPKI mund të rezultojë të jetë, nëse jo më e thjeshtë, atëherë të paktën e krahasueshme me një zgjidhje të centralizuar për sa i përket kompleksitetit arkitektonik.

Pyetja kryesore mbetet - Cili regjistër është i përshtatshëm për zbatimin e teknologjisë?

Kërkesa kryesore për regjistrin është aftësia për të gjeneruar transaksione të çdo lloji. Shembulli më i famshëm i një libri kryesor është rrjeti Bitcoin. Por gjatë zbatimit të teknologjisë së përshkruar më sipër, lindin disa vështirësi: kufizimet e gjuhës ekzistuese të skriptimit, mungesa e mekanizmave të nevojshëm për përpunimin e grupeve arbitrare të të dhënave, metodat për gjenerimin e transaksioneve të një lloji arbitrar dhe shumë më tepër.

Ne në ENCRY u përpoqëm të zgjidhnim problemet e formuluara më sipër dhe zhvilluam një regjistër, i cili, sipas mendimit tonë, ka një sërë avantazhesh, përkatësisht:

• mbështet disa lloje transaksionesh: mund të shkëmbejë aktive (d.m.th., të kryejë transaksione financiare) dhe të krijojë transaksione me një strukturë arbitrare,
• zhvilluesit kanë akses në gjuhën e programimit të pronarit PrismLang, e cila siguron fleksibilitetin e nevojshëm kur zgjidhin probleme të ndryshme teknologjike,
• ofrohet një mekanizëm për përpunimin e grupeve arbitrare të të dhënave.

Nëse marrim një qasje të thjeshtuar, atëherë ndodh sekuenca e mëposhtme e veprimeve:

1. Aplikanti regjistrohet në DPKI dhe merr një portofol dixhital. Adresa e portofolit është vlera hash e çelësit publik të portofolit. Çelësi privat i portofolit është i njohur vetëm për aplikantin.
2. Subjektit të regjistruar i jepet akses në çelësin sekret të shërbimit.
3. Subjekti gjeneron një transaksion zero dhe e verifikon atë me një nënshkrim dixhital duke përdorur çelësin sekret të portofolit.
4. Nëse formohet një transaksion i ndryshëm nga zero, ai vërtetohet nga një nënshkrim elektronik dixhital duke përdorur dy çelësa sekretë: një portofol dhe një shërbim.
5. Subjekti paraqet një transaksion në grup.
6. Nyja e rrjetit ENCRY lexon transaksionin nga grupi dhe kontrollon nënshkrimin dixhital, si dhe lidhjen e transaksionit.
7. Nëse nënshkrimi dixhital është i vlefshëm dhe lidhja konfirmohet, atëherë ai përgatit transaksionin për regjistrim në regjistër.

Këtu regjistri vepron si një bazë të dhënash e shpërndarë që ruan informacione rreth njoftimeve të vlefshme, të anuluara dhe të pezulluara.

Natyrisht, decentralizimi nuk është një ilaç. Problemi themelor i vërtetimit parësor të përdoruesit nuk zhduket askund: nëse aktualisht verifikimi i aplikantit kryhet nga CR, atëherë në DPKI propozohet që verifikimi të delegohet tek anëtarët e komunitetit dhe të përdoret motivimi financiar për të stimuluar aktivitetin. Teknologjia e verifikimit me burim të hapur është e njohur. Efektiviteti i një verifikimi të tillë është konfirmuar në praktikë. Le të kujtojmë sërish një sërë hetimesh të profilit të lartë nga botimi në internet Bellingcat.

Por në përgjithësi, shfaqet pamja e mëposhtme: DPKI është një mundësi për të korrigjuar, nëse jo të gjitha, atëherë shumë nga mangësitë e PKI të centralizuar.

Abonohuni në Habrablogun tonë, ne planifikojmë të vazhdojmë të mbulojmë në mënyrë aktive kërkimin dhe zhvillimin tonë dhe ta ndjekim Cicëroj, nëse nuk doni të humbisni lajme të tjera rreth projekteve të ENCRY.

Burimi: www.habr.com