Det er ingen hemmelighed, at et af de almindeligt anvendte hjælpeværktøjer, uden hvilke databeskyttelse i åbne netværk er umulig, er digital certifikatteknologi. Det er dog ingen hemmelighed, at teknologiens største ulempe er ubetinget tillid til de centre, der udsteder digitale certifikater. Direktør for teknologi og innovation hos ENCRY Andrey Chmora foreslog en ny tilgang til organisering offentlig nøgleinfrastruktur (Public Key Infrastructure, PKI), som vil hjælpe med at eliminere nuværende mangler, og som bruger distribueret ledger (blockchain) teknologi. Men først ting først.
Hvis du er bekendt med, hvordan din nuværende offentlige nøgleinfrastruktur fungerer og kender dens vigtigste mangler, kan du springe videre til det, vi foreslår at ændre nedenfor.
Hvad er digitale signaturer og certifikater?Interaktion på internettet involverer altid overførsel af data. Vi har alle en interesse i at sikre, at data overføres sikkert. Men hvad er sikkerhed? De mest efterspurgte sikkerhedstjenester er fortrolighed, integritet og autenticitet. Til dette formål anvendes i øjeblikket metoder til asymmetrisk kryptografi eller kryptografi med en offentlig nøgle.
Lad os starte med det faktum, at for at bruge disse metoder, skal emnerne for interaktion have to individuelle parrede nøgler - offentlige og hemmelige. Med deres hjælp leveres de sikkerhedstjenester, vi nævnte ovenfor.
Hvordan opnås fortroligheden af informationsoverførsel? Før afsendelse af data, krypterer (transformerer) den afsendende abonnent de åbne data ved hjælp af modtagerens offentlige nøgle, og modtageren dekrypterer den modtagne chiffertekst ved hjælp af den parrede hemmelige nøgle.
Hvordan opnås integriteten og ægtheden af den transmitterede information? For at løse dette problem blev der oprettet en anden mekanisme. De åbne data er ikke krypteret, men resultatet af anvendelsen af den kryptografiske hash-funktion - et "komprimeret" billede af inputdatasekvensen - transmitteres i krypteret form. Resultatet af en sådan hashing kaldes en "digest", og det krypteres ved hjælp af den hemmelige nøgle fra den afsendende abonnent ("vidnet"). Som et resultat af kryptering af digest opnås en digital signatur. Den sendes sammen med den klare tekst til modtagerabonnenten ("verifikator"). Han dekrypterer den digitale signatur på vidnets offentlige nøgle og sammenligner den med resultatet af at anvende en kryptografisk hash-funktion, som verifikatoren beregner uafhængigt ud fra de modtagne åbne data. Hvis de matcher, indikerer dette, at dataene blev transmitteret i en autentisk og fuldstændig form af den afsendende abonnent og ikke ændret af en angriber.
De fleste ressourcer, der arbejder med persondata og betalingsoplysninger (banker, forsikringsselskaber, flyselskaber, betalingssystemer, samt offentlige portaler som skattevæsenet) bruger aktivt asymmetriske kryptografimetoder.
Hvad har et digitalt certifikat med det at gøre? Det er simpelt. Både den første og den anden proces involverer offentlige nøgler, og da de spiller en central rolle, er det meget vigtigt at sikre, at nøglerne rent faktisk tilhører afsenderen (vidnet, i tilfælde af signaturverifikation) eller modtageren og ikke er erstattet med angribernes nøgler. Dette er grunden til, at digitale certifikater eksisterer for at sikre ægtheden og integriteten af den offentlige nøgle.
Bemærk: ægtheden og integriteten af den offentlige nøgle bekræftes på nøjagtig samme måde som ægtheden og integriteten af offentlige data, det vil sige ved hjælp af en elektronisk digital signatur (EDS).
Hvor kommer digitale certifikater fra?Betroede certificeringsmyndigheder eller certificeringsmyndigheder (CA'er), er ansvarlige for at udstede og vedligeholde digitale certifikater. Ansøgeren anmoder om udstedelse af et certifikat fra CA, gennemgår identifikation i Registreringscentret (CR) og modtager et certifikat fra CA. CA garanterer, at den offentlige nøgle fra certifikatet tilhører præcis den enhed, som den blev udstedt til.
Hvis du ikke bekræfter ægtheden af den offentlige nøgle, så kan en angriber under overførslen/lagringen af denne nøgle erstatte den med sin egen. Hvis substitutionen har fundet sted, vil angriberen være i stand til at dekryptere alt, hvad den afsendende abonnent sender til den modtagende abonnent, eller ændre de åbne data efter eget skøn.
Digitale certifikater bruges overalt, hvor asymmetrisk kryptografi er tilgængelig. Et af de mest almindelige digitale certifikater er SSL-certifikater til sikker kommunikation over HTTPS-protokollen. Hundredvis af virksomheder registreret i forskellige jurisdiktioner er involveret i at udstede SSL-certifikater. Hovedandelen falder på fem til ti store betroede centre: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA og CR er komponenter i PKI, som også inkluderer:
- Åbn mappe – en offentlig database, der giver sikker opbevaring af digitale certifikater.
- Liste over tilbagekaldelse af certifikater – en offentlig database, der giver sikker opbevaring af digitale certifikater for tilbagekaldte offentlige nøgler (f.eks. på grund af kompromittering af en parret privat nøgle). Infrastrukturfag kan uafhængigt få adgang til denne database, eller de kan bruge den specialiserede Online Certification Status Protocol (OCSP), som forenkler verifikationsprocessen.
- Certifikatbrugere – servicerede PKI-personer, der har indgået en brugeraftale med CA og verificerer den digitale signatur og/eller krypterer data baseret på den offentlige nøgle fra certifikatet.
- Abonnenter – betjente PKI-personer, der ejer en hemmelig nøgle parret med den offentlige nøgle fra certifikatet, og som har indgået en abonnentaftale med CA. Abonnenten kan samtidig være bruger af certifikatet.
Således er betroede enheder i den offentlige nøgleinfrastruktur, som omfatter CA'er, CR'er og åbne mapper, ansvarlige for:
1. Verifikation af ægtheden af ansøgerens identitet.
2. Profilering af det offentlige nøglecertifikat.
3. Udstedelse af et offentligt nøglecertifikat til en ansøger, hvis identitet er blevet pålideligt bekræftet.
4. Skift status for det offentlige nøglecertifikat.
5. Oplysning om den aktuelle status for det offentlige nøglecertifikat.
Ulemper ved PKI, hvad er de?Den grundlæggende fejl ved PKI er tilstedeværelsen af betroede enheder.
Brugere skal ubetinget have tillid til CA og CR. Men som praksis viser, er ubetinget tillid fyldt med alvorlige konsekvenser.
I løbet af de seneste ti år har der været flere store skandaler på dette område relateret til infrastrukturs sårbarhed.
— i 2010 begyndte Stuxnet-malwaren at sprede sig online, underskrevet ved hjælp af stjålne digitale certifikater fra RealTek og JMicron.
- I 2017 anklagede Google Symantec for at have udstedt et stort antal forfalskede certifikater. På det tidspunkt var Symantec en af de største CA'er målt i produktionsmængder. I Google Chrome 70-browseren blev understøttelse af certifikater udstedt af denne virksomhed og dets tilknyttede centre GeoTrust og Thawte stoppet før den 1. december 2017.
CA'erne blev kompromitteret, og som et resultat led alle - CA'erne selv, såvel som brugere og abonnenter. Tilliden til infrastrukturen er blevet undermineret. Derudover kan digitale certifikater blive blokeret i forbindelse med politiske konflikter, hvilket også vil påvirke driften af mange ressourcer. Det er netop det, man frygtede for flere år siden i den russiske præsidentadministration, hvor man i 2016 diskuterede muligheden for at skabe et statsligt certificeringscenter, der ville udstede SSL-certifikater til sider på RuNet. Den aktuelle situation er sådan, at selv statsportaler i Rusland digitale certifikater udstedt af amerikanske virksomheder Comodo eller Thawte (et datterselskab af Symantec).
Der er et andet problem - spørgsmålet primær autentificering (godkendelse) af brugere. Hvordan identificerer man en bruger, der har kontaktet CA med en anmodning om at udstede et digitalt certifikat uden direkte personlig kontakt? Nu er dette løst situationsbestemt afhængigt af infrastrukturens muligheder. Noget er hentet fra åbne registre (for eksempel oplysninger om juridiske enheder, der anmoder om certifikater); i tilfælde, hvor ansøgerne er enkeltpersoner, kan bankkontorer eller posthuse bruges, hvor deres identitet bekræftes ved hjælp af identifikationsdokumenter, for eksempel et pas.
Problemet med at forfalske legitimationsoplysninger med det formål at efterligne er et grundlæggende problem. Lad os bemærke, at der ikke er nogen fuldstændig løsning på dette problem på grund af informationsteoretiske årsager: uden at have pålidelige oplysninger på forhånd er det umuligt at bekræfte eller benægte ægtheden af et bestemt emne. Som regel er det for verifikation nødvendigt at fremvise et sæt dokumenter, der beviser ansøgerens identitet. Der er mange forskellige verifikationsmetoder, men ingen af dem giver fuld garanti for dokumenternes ægthed. Derfor kan ægtheden af ansøgerens identitet heller ikke garanteres.
Hvordan kan disse mangler fjernes?Hvis problemerne med PKI i dens nuværende tilstand kan forklares ved centralisering, så er det logisk at antage, at decentralisering vil hjælpe delvist med at eliminere de identificerede mangler.
Decentralisering indebærer ikke tilstedeværelsen af betroede enheder - hvis du opretter decentraliseret offentlig nøgleinfrastruktur (Decentraliseret offentlig nøgleinfrastruktur, DPKI), så er der hverken behov for CA eller CR. Lad os opgive konceptet med et digitalt certifikat og bruge et distribueret register til at gemme oplysninger om offentlige nøgler. I vores tilfælde kalder vi et register for en lineær database bestående af individuelle poster (blokke), der er forbundet ved hjælp af blockchain-teknologi. I stedet for et digitalt certifikat introducerer vi begrebet "meddelelse".
Hvordan processen med at modtage, bekræfte og annullere meddelelser vil se ud i den foreslåede DPKI:
1. Hver ansøger indgiver selvstændigt en ansøgning om anmeldelse ved at udfylde en formular under registreringen, hvorefter han opretter en transaktion, der opbevares i en specialiseret pulje.
2. Oplysninger om den offentlige nøgle, sammen med ejerens detaljer og andre metadata, lagres i et distribueret register, og ikke i et digitalt certifikat, for hvis udstedelse i en centraliseret PKI CA er ansvarlig.
3. Verifikation af ægtheden af ansøgerens identitet udføres efter kendsgerningen af fælles indsats fra DPKI-brugerfællesskabet og ikke af CR.
4. Kun ejeren af en sådan meddelelse kan ændre status for en offentlig nøgle.
5. Alle kan få adgang til den distribuerede hovedbog og kontrollere den aktuelle status for den offentlige nøgle.
Bemærk: Fællesskabsbekræftelse af en ansøgers identitet kan virke upålidelig ved første øjekast. Men vi skal huske, at alle brugere af digitale tjenester i dag uundgåeligt efterlader et digitalt fodaftryk, og denne proces vil kun fortsætte med at tage fart. Åbne elektroniske registre over juridiske enheder, kort, digitalisering af terrænbilleder, sociale netværk - alt dette er offentligt tilgængelige værktøjer. De bruges allerede med succes under undersøgelser af både journalister og retshåndhævende myndigheder. For eksempel er det nok at minde om undersøgelserne af Bellingcat eller det fælles efterforskningshold JIT, som studerer omstændighederne ved den malaysiske Boeings styrt.
Så hvordan ville en decentraliseret offentlig nøgleinfrastruktur fungere i praksis? Lad os dvæle ved beskrivelsen af selve teknologien, som vi patenteret i 2018 og vi betragter det med rette som vores knowhow.
Forestil dig, at der er en ejer, der ejer mange offentlige nøgler, hvor hver nøgle er en bestemt transaktion, der er gemt i registreringsdatabasen. I mangel af en CA, hvordan kan du så forstå, at alle nøglerne tilhører netop denne ejer? For at løse dette problem oprettes en nultransaktion, som indeholder oplysninger om ejeren og hans tegnebog (hvorfra provisionen for at placere transaktionen i registreringsdatabasen debiteres). Nul-transaktionen er en slags "anker", hvortil følgende transaktioner med data om offentlige nøgler vil blive knyttet. Hver sådan transaktion indeholder en specialiseret datastruktur eller med andre ord en meddelelse.
Meddelelse er et struktureret sæt af data, der består af funktionelle felter og inklusive information om ejerens offentlige nøgle, hvis persistens er garanteret ved placering i en af de tilknyttede poster i det distribuerede register.
Det næste logiske spørgsmål er, hvordan dannes en nultransaktion? Nul-transaktionen - ligesom efterfølgende - er en sammenlægning af seks datafelter. Under dannelsen af en nultransaktion er nøgleparret i tegnebogen involveret (offentlige og parrede hemmelige nøgler). Dette nøglepar vises i det øjeblik, hvor brugeren registrerer sin tegnebog, hvorfra provisionen for at placere en nultransaktion i registreringsdatabasen og efterfølgende operationer med meddelelser vil blive debiteret.
Som vist i figuren genereres en offentlig tegnebogsnøglesammenfatning ved sekventielt at anvende hash-funktionerne SHA256 og RIPEMD160. Her er RIPEMD160 ansvarlig for den kompakte repræsentation af data, hvis bredde ikke overstiger 160 bit. Dette er vigtigt, fordi registreringsdatabasen ikke er en billig database. Selve den offentlige nøgle indtastes i det femte felt. Det første felt indeholder data, der etablerer en forbindelse til den tidligere transaktion. For en nultransaktion indeholder dette felt intet, hvilket adskiller det fra efterfølgende transaktioner. Det andet felt er data til kontrol af forbindelsen mellem transaktioner. For kortheds skyld kalder vi dataene i det første og andet felt for henholdsvis "link" og "check". Indholdet af disse felter genereres ved iterativ hashing, som vist ved at forbinde anden og tredje transaktion i figuren nedenfor.
Dataene fra de første fem felter er certificeret af en elektronisk signatur, som genereres ved hjælp af tegnebogens hemmelige nøgle.
Det er det, null-transaktionen sendes til puljen, og efter vellykket verifikation indtastes i registreringsdatabasen. Nu kan du "linke" følgende transaktioner til den. Lad os overveje, hvordan andre transaktioner end nul dannes.
Den første ting, der sandsynligvis fangede dit øje, er overfloden af nøglepar. Ud over det i forvejen kendte wallet-nøglepar, bruges almindelige nøglepar og servicenøgler.
En almindelig offentlig nøgle er det, alt blev startet for. Denne nøgle er involveret i forskellige procedurer og processer, der udspiller sig i omverdenen (bank- og andre transaktioner, dokumentflow osv.). For eksempel kan en hemmelig nøgle fra et almindeligt par bruges til at generere digitale signaturer til forskellige dokumenter - betalingsordrer mv., og en offentlig nøgle kan bruges til at verificere denne digitale signatur med efterfølgende udførelse af disse instruktioner, forudsat at det er gyldig.
Serviceparret udstedes til det registrerede DPKI-subjekt. Navnet på dette par svarer til dets formål. Bemærk, at når der oprettes/kontrolleres en nultransaktion, bruges servicenøgler ikke.
Lad os præcisere formålet med nøglerne igen:
- Tegnebogsnøgler bruges til at generere/bekræfte både en null-transaktion og enhver anden ikke-nul-transaktion. Den private nøgle til en pung er kun kendt af pungens ejer, som også er ejer af mange almindelige offentlige nøgler.
- En almindelig offentlig nøgle svarer til formålet med en offentlig nøgle, for hvilken et certifikat er udstedt i en centraliseret PKI.
- Servicenøgleparret tilhører DPKI. Den hemmelige nøgle udstedes til registrerede enheder og bruges ved generering af digitale signaturer for transaktioner (undtagen for nul transaktioner). Offentlig bruges til at verificere den elektroniske digitale signatur af en transaktion, før den bogføres i registret.
Der er således to grupper af nøgler. Den første inkluderer servicenøgler og tegnebogsnøgler - de giver kun mening i forbindelse med DPKI. Den anden gruppe omfatter almindelige nøgler - deres omfang kan variere og bestemmes af de applikationsopgaver, de bruges i. Samtidig sikrer DPKI integriteten og ægtheden af almindelige offentlige nøgler.
Bemærk: Servicenøgleparret kan være kendt af forskellige DPKI-enheder. Det kan for eksempel være ens for alle. Det er af denne grund, at når der genereres signaturen for hver transaktion, der ikke er nul, bruges to hemmelige nøgler, hvoraf den ene er tegnebogsnøglen - det er kun kendt for ejeren af tegnebogen, som også er ejer af mange almindelige offentlige nøgler. Alle nøgler har deres egen betydning. For eksempel er det altid muligt at bevise, at transaktionen blev indført i registret af en registreret DPKI-subjekt, da signaturen også blev genereret på en hemmelig tjenestenøgle. Og der kan ikke være misbrug, såsom DOS-angreb, fordi ejeren betaler for hver transaktion.
Alle transaktioner, der følger nul-en, er dannet på lignende måde: den offentlige nøgle (ikke tegnebogen, som i tilfældet med nul-transaktionen, men fra et almindeligt nøglepar) køres gennem to hash-funktioner SHA256 og RIPEMD160. Sådan dannes dataene i det tredje felt. Det fjerde felt indeholder ledsagende information (f.eks. information om den aktuelle status, udløbsdatoer, tidsstempel, identifikatorer for anvendte kryptoalgoritmer osv.). Det femte felt indeholder den offentlige nøgle fra tjenestenøgleparret. Med dens hjælp vil den digitale signatur derefter blive kontrolleret, så den bliver replikeret. Lad os begrunde behovet for en sådan tilgang.
Husk, at en transaktion indgår i en pulje og gemmes der, indtil den er behandlet. Lagring i en pulje er forbundet med en vis risiko - transaktionsdata kan være forfalsket. Ejeren attesterer transaktionsdataene med en elektronisk digital signatur. Den offentlige nøgle til verificering af denne digitale signatur er angivet eksplicit i et af transaktionsfelterne og indtastes efterfølgende i registret. Det særlige ved transaktionsbehandling er sådan, at en angriber er i stand til at ændre dataene efter eget skøn og derefter verificere dem ved hjælp af sin hemmelige nøgle og angive en parret offentlig nøgle til at verificere den digitale signatur i transaktionen. Hvis ægthed og integritet udelukkende sikres gennem digital signatur, vil en sådan forfalskning gå ubemærket hen. Men hvis der udover den digitale signatur er en ekstra mekanisme, der sikrer både arkivering og persistens af de lagrede informationer, så kan forfalskningen opdages. For at gøre dette er det nok at indtaste ejerens ægte offentlige nøgle i registreringsdatabasen. Lad os forklare, hvordan dette fungerer.
Lad angriberen forfalske transaktionsdata. Med hensyn til nøgler og digitale signaturer er følgende muligheder mulige:
1. Angriberen placerer sin offentlige nøgle i transaktionen, mens ejerens digitale signatur forbliver uændret.
2. Angriberen opretter en digital signatur på sin private nøgle, men efterlader ejerens offentlige nøgle uændret.
3. Angriberen opretter en digital signatur på sin private nøgle og placerer en parret offentlig nøgle i transaktionen.
Det er klart, at valgmulighed 1 og 2 er meningsløse, da de altid vil blive opdaget under verifikationen af den digitale signatur. Kun mulighed 3 giver mening, og hvis en angriber danner en digital signatur på sin egen hemmelige nøgle, så er han tvunget til at gemme en parret offentlig nøgle i transaktionen, forskellig fra ejerens offentlige nøgle. Dette er den eneste måde for en angriber at påtvinge forfalskede data.
Lad os antage, at ejeren har et fast nøglepar – private og offentlige. Lad dataene blive certificeret med digital signatur ved hjælp af den hemmelige nøgle fra dette par, og den offentlige nøgle er angivet i transaktionen. Lad os også antage, at denne offentlige nøgle tidligere er blevet indtastet i registreringsdatabasen, og dens ægthed er blevet pålideligt verificeret. Så vil en forfalskning blive indikeret ved, at den offentlige nøgle fra transaktionen ikke svarer til den offentlige nøgle fra registreringsdatabasen.
Lad os opsummere. Ved behandling af ejerens allerførste transaktionsdata er det nødvendigt at verificere ægtheden af den offentlige nøgle, der er indtastet i registreringsdatabasen. For at gøre dette skal du læse nøglen fra registreringsdatabasen og sammenligne den med ejerens sande offentlige nøgle inden for sikkerhedsperimeteren (området med relativ usårbarhed). Hvis nøglens ægthed er bekræftet, og dens vedholdenhed er garanteret ved placering, så kan ægtheden af nøglen fra den efterfølgende transaktion let bekræftes/afkræftes ved at sammenligne den med nøglen fra registreringsdatabasen. Med andre ord bruges nøglen fra registreringsdatabasen som en referenceprøve. Alle andre ejertransaktioner behandles på samme måde.
Transaktionen er certificeret af en elektronisk digital signatur – det er her hemmelige nøgler er nødvendige, og ikke én, men to på én gang – en servicenøgle og en tegnebogsnøgle. Takket være brugen af to hemmelige nøgler sikres det nødvendige sikkerhedsniveau - tjenestens hemmelige nøgle kan trods alt være kendt af andre brugere, mens tegnebogens hemmelige nøgle kun er kendt af ejeren af det almindelige nøglepar. Vi kaldte sådan en to-nøglesignatur for en "konsolideret" digital signatur.
Verifikation af ikke-nul transaktioner udføres ved hjælp af to offentlige nøgler: tegnebogen og servicenøglen. Verifikationsprocessen kan opdeles i to hovedfaser: den første er at kontrollere sammendraget af tegnebogens offentlige nøgle, og den anden er at kontrollere den elektroniske digitale signatur af transaktionen, den samme konsoliderede, der blev dannet ved hjælp af to hemmelige nøgler ( tegnebog og service). Hvis gyldigheden af den digitale signatur bekræftes, bliver transaktionen registreret i registret efter yderligere verifikation.
Et logisk spørgsmål kan opstå: hvordan kontrollerer man, om en transaktion tilhører en bestemt kæde med "roden" i form af en nultransaktion? Til dette formål suppleres verifikationsprocessen med endnu et trin - forbindelseskontrol. Det er her, vi skal bruge dataene fra de to første felter, som vi hidtil har ignoreret.
Lad os forestille os, at vi skal tjekke, om transaktion nr. 3 faktisk kommer efter transaktion nr. 2. For at gøre dette, ved hjælp af den kombinerede hashmetode, beregnes hashfunktionsværdien for dataene fra tredje, fjerde og femte felt i transaktion nr. 2. Derefter udføres sammenkædningen af data fra det første felt i transaktion nr. 3 og den tidligere opnåede kombinerede hashfunktionsværdi for data fra det tredje, fjerde og femte felt i transaktion nr. 2. Alt dette køres også gennem to hash-funktioner SHA256 og RIPEMD160. Hvis den modtagne værdi stemmer overens med dataene i det andet felt af transaktion nr. 2, passeres kontrollen, og forbindelsen bekræftes. Dette fremgår tydeligere af nedenstående figurer.
Generelt ser teknologien til at generere og indtaste en anmeldelse i registret præcis sådan ud. En visuel illustration af processen med at danne en kæde af meddelelser er præsenteret i følgende figur:
I denne tekst vil vi ikke dvæle ved detaljerne, som uden tvivl eksisterer, og vende tilbage til at diskutere selve ideen om en decentraliseret offentlig nøgleinfrastruktur.
Så da ansøgeren selv indsender en ansøgning om registrering af meddelelser, som ikke er lagret i CA-databasen, men i registret, bør de vigtigste arkitektoniske komponenter i DPKI overvejes:
1. Register over gyldige meddelelser (RDN).
2. Register over tilbagekaldte anmeldelser (RON).
3. Register over suspenderede meddelelser (RPN).
Oplysninger om offentlige nøgler gemmes i RDN/RON/RPN i form af hashfunktionsværdier. Det er også værd at bemærke, at disse enten kan være forskellige registre eller forskellige kæder, eller endda én kæde som del af et enkelt register, når oplysninger om status for en almindelig offentlig nøgle (tilbagekaldelse, suspension osv.) indtastes i fjerde felt i datastrukturen i form af den tilsvarende kodeværdi. Der er mange forskellige muligheder for den arkitektoniske implementering af DPKI, og valget af den ene eller den anden afhænger af en række faktorer, for eksempel sådanne optimeringskriterier som omkostningerne til langtidshukommelse til lagring af offentlige nøgler osv.
DPKI kan således vise sig at være, hvis ikke enklere, så i det mindste sammenlignelig med en centraliseret løsning med hensyn til arkitektonisk kompleksitet.
Hovedspørgsmålet er tilbage - Hvilket register er egnet til at implementere teknologien?
Hovedkravet til registreringsdatabasen er evnen til at generere transaktioner af enhver type. Det mest berømte eksempel på en hovedbog er Bitcoin-netværket. Men når man implementerer teknologien beskrevet ovenfor, opstår der visse vanskeligheder: begrænsningerne af det eksisterende scriptsprog, manglen på nødvendige mekanismer til behandling af vilkårlige datasæt, metoder til at generere transaktioner af en vilkårlig type og meget mere.
Vi i ENCRY forsøgte at løse de ovenfor formulerede problemer og udviklede et register, som efter vores mening har en række fordele, nemlig:
- understøtter flere typer transaktioner: den kan både udveksle aktiver (det vil sige udføre finansielle transaktioner) og skabe transaktioner med en vilkårlig struktur,
- udviklere har adgang til det proprietære programmeringssprog PrismLang, som giver den nødvendige fleksibilitet ved løsning af forskellige teknologiske problemer,
- en mekanisme til behandling af vilkårlige datasæt er tilvejebragt.
Hvis vi tager en forenklet tilgang, finder følgende rækkefølge af handlinger sted:
- Ansøgeren tilmelder sig DPKI og modtager en digital tegnebog. Tegnebogsadresse er hashværdien af tegnebogens offentlige nøgle. Pungens private nøgle er kun kendt af ansøgeren.
- Den registrerede person får adgang til tjenestens hemmelige nøgle.
- Emnet genererer en nultransaktion og verificerer den med en digital signatur ved hjælp af tegnebogens hemmelige nøgle.
- Hvis der dannes en anden transaktion end nul, bekræftes den af en elektronisk digital signatur ved hjælp af to hemmelige nøgler: en tegnebog og en tjeneste.
- Forsøgspersonen indsender en transaktion til puljen.
- ENCRY-netværksknuden læser transaktionen fra puljen og kontrollerer den digitale signatur samt transaktionens forbindelse.
- Hvis den digitale signatur er gyldig, og forbindelsen er bekræftet, forbereder den transaktionen til optagelse i registret.
Her fungerer registreringsdatabasen som en distribueret database, der gemmer oplysninger om gyldige, annullerede og suspenderede meddelelser.
Selvfølgelig er decentralisering ikke et vidundermiddel. Det grundlæggende problem med primær brugerautentificering forsvinder ikke nogen steder: Hvis verifikationen af ansøgeren i øjeblikket udføres af CR, foreslås det i DPKI at uddelegere verifikationen til fællesskabsmedlemmer og bruge økonomisk motivation til at stimulere aktivitet. Open source-verifikationsteknologi er velkendt. Effektiviteten af en sådan verifikation er blevet bekræftet i praksis. Lad os igen minde om en række højprofilerede undersøgelser fra online-publikationen Bellingcat.
Men generelt tegner sig følgende billede: DPKI er en mulighed for at rette op på, hvis ikke alle, så mange af manglerne ved centraliseret PKI.
Abonner på vores Habrablog, vi planlægger fortsat aktivt at dække vores forskning og udvikling og følge med , hvis du ikke vil gå glip af andre nyheder om ENCRY-projekter.
Kilde: www.habr.com