DPKI: eliminerer manglene ved sentralisert PKI ved bruk av blokkjede

Det er ingen hemmelighet at et av de mest brukte hjelpeverktøyene, uten hvilke databeskyttelse i åpne nettverk er umulig, er digital sertifikatteknologi. Det er imidlertid ingen hemmelighet at den største ulempen med teknologien er ubetinget tillit til sentrene som utsteder digitale sertifikater. Direktør for teknologi og innovasjon ved ENCRY Andrey Chmora foreslo en ny tilnærming til organisering offentlig nøkkelinfrastruktur (Public Key Infrastructure, PKI), som vil bidra til å eliminere nåværende mangler og som bruker distribuert ledger (blockchain) teknologi. Men først ting først.

Hvis du er kjent med hvordan den nåværende offentlige nøkkelinfrastrukturen din fungerer og kjenner dens viktigste mangler, kan du gå videre til det vi foreslår å endre nedenfor.

Hva er digitale signaturer og sertifikater?Interaksjon på Internett innebærer alltid overføring av data. Vi har alle en interesse i å sikre at data overføres sikkert. Men hva er sikkerhet? De mest ettertraktede sikkerhetstjenestene er konfidensialitet, integritet og autentisitet. For dette formålet brukes for tiden metoder for asymmetrisk kryptografi, eller kryptografi med en offentlig nøkkel.

La oss starte med det faktum at for å bruke disse metodene, må interaksjonsobjektene ha to individuelle sammenkoblede nøkler - offentlige og hemmelige. Med deres hjelp tilbys sikkerhetstjenestene vi nevnte ovenfor.

Hvordan oppnås konfidensialitet ved informasjonsoverføring? Før sending av data, krypterer (transformerer) avsenderabonnenten de åpne dataene ved å bruke mottakerens offentlige nøkkel, og mottakeren dekrypterer den mottatte chifferteksten ved å bruke den parede hemmelige nøkkelen.

Hvordan oppnås integriteten og autentisiteten til den overførte informasjonen? For å løse dette problemet ble det opprettet en annen mekanisme. De åpne dataene er ikke kryptert, men resultatet av å bruke den kryptografiske hash-funksjonen - et "komprimert" bilde av inndatasekvensen - overføres i kryptert form. Resultatet av slik hashing kalles en "digest", og den krypteres ved hjelp av den hemmelige nøkkelen til avsenderabonnenten ("vitnet"). Som et resultat av kryptering av sammendraget oppnås en digital signatur. Den, sammen med klarteksten, sendes til mottakerabonnenten ("verifikator"). Han dekrypterer den digitale signaturen på vitnets offentlige nøkkel og sammenligner den med resultatet av å bruke en kryptografisk hash-funksjon, som verifikatoren beregner uavhengig basert på de mottatte åpne dataene. Hvis de samsvarer, indikerer dette at dataene ble overført i en autentisk og fullstendig form av den avsendende abonnenten, og ikke modifisert av en angriper.

De fleste ressursene som jobber med personopplysninger og betalingsinformasjon (banker, forsikringsselskaper, flyselskaper, betalingssystemer, samt offentlige portaler som skatteetaten) bruker aktivt asymmetriske kryptografimetoder.

Hva har et digitalt sertifikat med det å gjøre? Det er enkelt. Både første og andre prosess involverer offentlige nøkler, og siden de spiller en sentral rolle, er det svært viktig å sikre at nøklene faktisk tilhører avsenderen (vitnet, ved signaturverifisering) eller mottakeren, og ikke er erstattet med nøklene til angripere. Dette er grunnen til at digitale sertifikater eksisterer for å sikre autentisiteten og integriteten til den offentlige nøkkelen.

Merk: autentisiteten og integriteten til den offentlige nøkkelen bekreftes på nøyaktig samme måte som ektheten og integriteten til offentlige data, det vil si ved bruk av en elektronisk digital signatur (EDS).
Hvor kommer digitale sertifikater fra?Betrodde sertifiseringsmyndigheter, eller sertifiseringsinstanser (CA), er ansvarlige for å utstede og vedlikeholde digitale sertifikater. Søkeren ber om utstedelse av sertifikat fra CA, gjennomgår identifikasjon ved Registreringssenteret (CR) og mottar sertifikat fra CA. CA garanterer at den offentlige nøkkelen fra sertifikatet tilhører nøyaktig den enheten den ble utstedt for.

Hvis du ikke bekrefter autentisiteten til den offentlige nøkkelen, kan en angriper under overføringen/lagringen av denne nøkkelen erstatte den med sin egen. Hvis substitusjonen har funnet sted, vil angriperen kunne dekryptere alt som senderabonnenten sender til mottakerabonnenten, eller endre de åpne dataene etter eget skjønn.

Digitale sertifikater brukes overalt hvor asymmetrisk kryptografi er tilgjengelig. Et av de vanligste digitale sertifikatene er SSL-sertifikater for sikker kommunikasjon over HTTPS-protokollen. Hundrevis av selskaper registrert i ulike jurisdiksjoner er involvert i å utstede SSL-sertifikater. Hovedandelen faller på fem til ti store pålitelige sentre: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.

CA og CR er komponenter av PKI, som også inkluderer:

• Åpne katalogen – en offentlig database som gir sikker lagring av digitale sertifikater.
• Sertifikatopphevelsesliste – en offentlig database som gir sikker lagring av digitale sertifikater for tilbakekalte offentlige nøkler (for eksempel på grunn av kompromittering av en sammenkoblet privat nøkkel). Infrastrukturfag kan uavhengig få tilgang til denne databasen, eller de kan bruke den spesialiserte Online Certification Status Protocol (OCSP), som forenkler verifiseringsprosessen.
• Sertifikatbrukere – betjente PKI-subjekter som har inngått en brukeravtale med CA og verifiserer den digitale signaturen og/eller krypterer data basert på den offentlige nøkkelen fra sertifikatet.
• Følgere – betjente PKI-subjekter som eier en hemmelig nøkkel paret med den offentlige nøkkelen fra sertifikatet, og som har inngått en abonnentavtale med CA. Abonnenten kan samtidig være bruker av sertifikatet.

Dermed er pålitelige enheter i den offentlige nøkkelinfrastrukturen, som inkluderer CA-er, CR-er og åpne kataloger, ansvarlige for:

1. Verifikasjon av ektheten av søkerens identitet.
2. Profilering av det offentlige nøkkelsertifikatet.
3. Utstedelse av et offentlig nøkkelsertifikat for en søker hvis identitet er pålitelig bekreftet.
4. Endre statusen til det offentlige nøkkelsertifikatet.
5. Gi informasjon om gjeldende status for det offentlige nøkkelsertifikatet.

Ulemper med PKI, hva er de?Den grunnleggende feilen til PKI er tilstedeværelsen av pålitelige enheter.
Brukere må ubetinget stole på CA og CR. Men, som praksis viser, er ubetinget tillit full av alvorlige konsekvenser.

I løpet av de siste ti årene har det vært flere store skandaler på dette området knyttet til infrastruktursårbarhet.

— i 2010 begynte Stuxnet-malwaren å spre seg på nettet, signert med stjålne digitale sertifikater fra RealTek og JMicron.

– I 2017 anklaget Google Symantec for å ha utstedt et stort antall forfalskede sertifikater. På den tiden var Symantec en av de største CA-ene når det gjelder produksjonsvolum. I nettleseren Google Chrome 70 ble støtte for sertifikater utstedt av dette selskapet og dets tilknyttede sentre GeoTrust og Thawte stoppet før 1. desember 2017.

CA-ene ble kompromittert, og som et resultat led alle - CA-ene selv, så vel som brukere og abonnenter. Tilliten til infrastruktur har blitt svekket. I tillegg kan digitale sertifikater bli blokkert i forbindelse med politiske konflikter, noe som også vil påvirke driften av mange ressurser. Det er nettopp dette man fryktet for flere år siden i den russiske presidentadministrasjonen, hvor de i 2016 diskuterte muligheten for å opprette et statlig sertifiseringssenter som skulle utstede SSL-sertifikater til nettsteder på RuNet. Den nåværende tilstanden er slik at selv statlige portaler i Russland bruk digitale sertifikater utstedt av amerikanske selskaper Comodo eller Thawte (et datterselskap av Symantec).

Det er et annet problem - spørsmålet primær autentisering (autentisering) av brukere. Hvordan identifisere en bruker som har kontaktet CA med en forespørsel om å utstede et digitalt sertifikat uten direkte personlig kontakt? Nå er dette løst situasjonsbestemt avhengig av infrastrukturens muligheter. Noe er hentet fra åpne registre (for eksempel informasjon om juridiske personer som ber om sertifikater); i tilfeller der søkerne er enkeltpersoner, kan bankkontorer eller postkontorer brukes, der deres identitet bekreftes ved hjelp av identifikasjonsdokumenter, for eksempel pass.

Problemet med å forfalske legitimasjon i den hensikt å etterligne er et grunnleggende problem. La oss merke seg at det ikke er noen fullstendig løsning på dette problemet på grunn av informasjonsteoretiske årsaker: uten å ha pålitelig informasjon på forhånd, er det umulig å bekrefte eller avkrefte ektheten til et bestemt emne. Som regel er det for verifisering nødvendig å presentere et sett med dokumenter som beviser søkerens identitet. Det finnes mange forskjellige verifiseringsmetoder, men ingen av dem gir full garanti for dokumentenes autentisitet. Følgelig kan heller ikke ektheten til søkerens identitet garanteres.

Hvordan kan disse manglene elimineres?Hvis problemene med PKI i sin nåværende tilstand kan forklares med sentralisering, er det logisk å anta at desentralisering vil bidra til å delvis eliminere de identifiserte manglene.

Desentralisering innebærer ikke tilstedeværelsen av pålitelige enheter - hvis du oppretter desentralisert offentlig nøkkelinfrastruktur (Desentralisert offentlig nøkkelinfrastruktur, DPKI), da er verken CA eller CR nødvendig. La oss forlate konseptet med et digitalt sertifikat og bruke et distribuert register til å lagre informasjon om offentlige nøkler. I vårt tilfelle kaller vi et register en lineær database som består av individuelle poster (blokker) koblet sammen ved hjelp av blokkjedeteknologi. I stedet for et digitalt sertifikat vil vi introdusere konseptet "varsling".

Hvordan prosessen med å motta, bekrefte og kansellere varsler vil se ut i den foreslåtte DPKI:

1. Hver søker sender inn en søknad om varsling uavhengig ved å fylle ut et skjema under registreringen, hvoretter han oppretter en transaksjon som er lagret i en spesialisert pool.

2. Informasjon om den offentlige nøkkelen, sammen med eierens detaljer og andre metadata, lagres i et distribuert register, og ikke i et digitalt sertifikat, som CA er ansvarlig for i en sentralisert PKI.

3. Verifisering av autentisiteten til søkerens identitet utføres i etterkant av felles innsats fra DPKI-brukerfellesskapet, og ikke av CR.

4. Bare eieren av en slik melding kan endre statusen til en offentlig nøkkel.

5. Alle kan få tilgang til den distribuerte hovedboken og sjekke gjeldende status for den offentlige nøkkelen.

Merk: Fellesskapsbekreftelse av en søkers identitet kan virke upålitelig ved første øyekast. Men vi må huske at i dag setter alle brukere av digitale tjenester uunngåelig et digitalt fotavtrykk, og denne prosessen vil bare fortsette å ta fart. Åpne elektroniske registre over juridiske personer, kart, digitalisering av terrengbilder, sosiale nettverk – alt dette er offentlig tilgjengelige verktøy. De brukes allerede med hell under etterforskning av både journalister og rettshåndhevelsesbyråer. For eksempel er det nok å minne om undersøkelsene til Bellingcat eller det felles etterforskningsteamet JIT, som studerer omstendighetene rundt krasjet til den malaysiske Boeing.

Så hvordan ville en desentralisert offentlig nøkkelinfrastruktur fungere i praksis? La oss dvele ved beskrivelsen av selve teknologien, som vi patentert i 2018 og vi anser det med rette som vår kunnskap.

Tenk deg at det er en eier som eier mange offentlige nøkler, der hver nøkkel er en bestemt transaksjon som er lagret i registeret. I fravær av en CA, hvordan kan du forstå at alle nøklene tilhører denne spesielle eieren? For å løse dette problemet opprettes en nulltransaksjon, som inneholder informasjon om eieren og lommeboken hans (hvorfra provisjonen for å plassere transaksjonen i registeret debiteres). Nulltransaksjonen er et slags "anker" som følgende transaksjoner med data om offentlige nøkler vil bli knyttet til. Hver slik transaksjon inneholder en spesialisert datastruktur, eller med andre ord, en melding.

Varsling er et strukturert sett med data som består av funksjonelle felt og inkluderer informasjon om eierens offentlige nøkkel, hvis utholdenhet er garantert ved plassering i en av de tilknyttede postene til det distribuerte registeret.

Det neste logiske spørsmålet er hvordan dannes en nulltransaksjon? Nulltransaksjonen – som påfølgende – er en aggregering av seks datafelt. Under dannelsen av en nulltransaksjon er nøkkelparet i lommeboken involvert (offentlige og parede hemmelige nøkler). Dette nøkkelparet vises i det øyeblikket brukeren registrerer lommeboken sin, hvorfra provisjonen for å plassere en nulltransaksjon i registeret og deretter operasjoner med varsler vil bli belastet.

Som vist i figuren genereres en offentlig nøkkelsammendrag for lommeboken ved å bruke hash-funksjonene SHA256 og RIPEMD160 sekvensielt. Her er RIPEMD160 ansvarlig for den kompakte representasjonen av data, hvis bredde ikke overstiger 160 biter. Dette er viktig fordi registeret ikke er en billig database. Selve den offentlige nøkkelen legges inn i det femte feltet. Det første feltet inneholder data som etablerer en forbindelse til forrige transaksjon. For en nulltransaksjon inneholder dette feltet ingenting, noe som skiller det fra påfølgende transaksjoner. Det andre feltet er data for å sjekke tilkoblingen til transaksjoner. For korthets skyld kaller vi dataene i det første og andre feltet for henholdsvis "lenke" og "sjekk". Innholdet i disse feltene genereres av iterativ hashing, som demonstrert ved å koble den andre og tredje transaksjonen i figuren nedenfor.

Dataene fra de fem første feltene er sertifisert av en elektronisk signatur, som genereres ved hjelp av lommebokens hemmelige nøkkel.

Det er det, null-transaksjonen sendes til bassenget og etter vellykket verifisering legges inn i registeret. Nå kan du "koble" følgende transaksjoner til den. La oss vurdere hvordan andre transaksjoner enn null dannes.

Det første som sannsynligvis fanget deg er overfloden av nøkkelpar. I tillegg til det allerede kjente lommeboknøkkelparet, brukes ordinære og servicenøkkelpar.

En vanlig offentlig nøkkel er det alt ble startet for. Denne nøkkelen er involvert i ulike prosedyrer og prosesser som utspiller seg i omverdenen (bank- og andre transaksjoner, dokumentflyt, etc.). For eksempel kan en hemmelig nøkkel fra et vanlig par brukes til å generere digitale signaturer for ulike dokumenter - betalingsoppdrag osv., og en offentlig nøkkel kan brukes til å verifisere denne digitale signaturen med påfølgende utførelse av disse instruksjonene, forutsatt at den er gyldig.

Tjenesteparet utstedes til det registrerte DPKI-subjektet. Navnet på dette paret samsvarer med formålet. Merk at når du oppretter/kontrollerer en nulltransaksjon, brukes ikke tjenestenøkler.

La oss avklare formålet med nøklene igjen:

1. Lommeboknøkler brukes til å generere/verifisere både en nulltransaksjon og enhver annen ikke-nulltransaksjon. Den private nøkkelen til en lommebok er kun kjent for eieren av lommeboken, som også er eier av mange vanlige offentlige nøkler.
2. En vanlig offentlig nøkkel har samme formål som en offentlig nøkkel som et sertifikat er utstedt for i en sentralisert PKI.
3. Tjenestenøkkelparet tilhører DPKI. Den hemmelige nøkkelen utstedes til registrerte enheter og brukes ved generering av digitale signaturer for transaksjoner (bortsett fra null transaksjoner). Offentlig brukes til å verifisere den elektroniske digitale signaturen til en transaksjon før den legges inn i registeret.

Dermed er det to grupper av nøkler. Den første inkluderer tjenestenøkler og lommeboknøkler - de gir bare mening i sammenheng med DPKI. Den andre gruppen inkluderer vanlige nøkler - deres omfang kan variere og bestemmes av applikasjonsoppgavene de brukes i. Samtidig sikrer DPKI integriteten og autentisiteten til vanlige offentlige nøkler.

Merk: Tjenestenøkkelparet kan være kjent for forskjellige DPKI-enheter. Det kan for eksempel være likt for alle. Det er av denne grunn at når man genererer signaturen til hver transaksjon som ikke er null, brukes to hemmelige nøkler, hvorav den ene er lommeboknøkkelen - den er bare kjent for eieren av lommeboken, som også er eier av mange vanlige offentlige nøkler. Alle nøkler har sin egen betydning. For eksempel er det alltid mulig å bevise at transaksjonen ble registrert i registeret av en registrert DPKI-subjekt, siden signaturen også ble generert på en hemmelig tjenestenøkkel. Og det kan ikke være misbruk, for eksempel DOS-angrep, fordi eieren betaler for hver transaksjon.

Alle transaksjoner som følger null-en er dannet på lignende måte: den offentlige nøkkelen (ikke lommeboken, som i tilfellet med null-transaksjonen, men fra et vanlig nøkkelpar) kjøres gjennom to hash-funksjoner SHA256 og RIPEMD160. Dette er hvordan dataene til det tredje feltet dannes. Det fjerde feltet inneholder tilhørende informasjon (for eksempel informasjon om gjeldende status, utløpsdatoer, tidsstempel, identifikatorer for kryptoalgoritmer som brukes, etc.). Det femte feltet inneholder den offentlige nøkkelen fra tjenestenøkkelparet. Med dens hjelp vil den digitale signaturen deretter bli sjekket, så den vil bli replikert. La oss begrunne behovet for en slik tilnærming.

Husk at en transaksjon legges inn i en pool og lagres der til den er behandlet. Lagring i en pool er forbundet med en viss risiko - transaksjonsdata kan forfalskes. Eieren sertifiserer transaksjonsdataene med en elektronisk digital signatur. Den offentlige nøkkelen for å verifisere denne digitale signaturen er angitt eksplisitt i et av transaksjonsfeltene og legges deretter inn i registeret. Det særegne ved transaksjonsbehandling er slik at en angriper er i stand til å endre dataene etter eget skjønn og deretter verifisere dem ved hjelp av sin hemmelige nøkkel, og indikere en sammenkoblet offentlig nøkkel for å verifisere den digitale signaturen i transaksjonen. Hvis autentisitet og integritet utelukkende sikres gjennom digital signatur, vil en slik forfalskning gå ubemerket hen. Men hvis det i tillegg til den digitale signaturen er en ekstra mekanisme som sikrer både arkivering og persistens av den lagrede informasjonen, kan forfalskningen oppdages. For å gjøre dette er det nok å legge inn eierens ekte offentlige nøkkel i registeret. La oss forklare hvordan dette fungerer.

La angriperen forfalske transaksjonsdata. Med tanke på nøkler og digitale signaturer er følgende alternativer mulige:

1. Angriperen plasserer sin offentlige nøkkel i transaksjonen mens eierens digitale signatur forblir uendret.
2. Angriperen oppretter en digital signatur på sin private nøkkel, men lar eierens offentlige nøkkel stå uendret.
3. Angriperen oppretter en digital signatur på sin private nøkkel og plasserer en sammenkoblet offentlig nøkkel i transaksjonen.

Åpenbart er alternativene 1 og 2 meningsløse, siden de alltid vil bli oppdaget under verifiseringen av digital signatur. Bare alternativ 3 gir mening, og hvis en angriper danner en digital signatur på sin egen hemmelige nøkkel, blir han tvunget til å lagre en sammenkoblet offentlig nøkkel i transaksjonen, forskjellig fra eierens offentlige nøkkel. Dette er den eneste måten for en angriper å påtvinge forfalskede data.

La oss anta at eieren har et fast nøkkelpar – private og offentlige. La dataene bli sertifisert med digital signatur ved å bruke den hemmelige nøkkelen fra dette paret, og den offentlige nøkkelen er indikert i transaksjonen. La oss også anta at denne offentlige nøkkelen tidligere har blitt lagt inn i registeret og at dens autentisitet er pålitelig verifisert. Da vil en forfalskning indikeres ved at den offentlige nøkkelen fra transaksjonen ikke samsvarer med den offentlige nøkkelen fra registeret.

La oss oppsummere. Når du behandler eierens aller første transaksjonsdata, er det nødvendig å verifisere ektheten til den offentlige nøkkelen som er lagt inn i registeret. For å gjøre dette, les nøkkelen fra registeret og sammenlign den med den sanne offentlige nøkkelen til eieren innenfor sikkerhetsperimeteren (området med relativ usårbarhet). Hvis ektheten til nøkkelen er bekreftet og dens utholdenhet er garantert ved plassering, kan ektheten til nøkkelen fra den påfølgende transaksjonen enkelt bekreftes/avkreftes ved å sammenligne den med nøkkelen fra registeret. Nøkkelen fra registeret brukes med andre ord som et referanseeksempel. Alle andre eiertransaksjoner behandles på samme måte.

Transaksjonen er sertifisert av en elektronisk digital signatur – det er her hemmelige nøkler trengs, og ikke én, men to samtidig – en tjenestenøkkel og en lommeboknøkkel. Takket være bruken av to hemmelige nøkler sikres det nødvendige sikkerhetsnivået - tross alt kan tjenestens hemmelige nøkkel være kjent for andre brukere, mens den hemmelige nøkkelen til lommeboken kun er kjent for eieren av det ordinære nøkkelparet. Vi kalte en slik to-nøkkelsignatur en "konsolidert" digital signatur.

Verifisering av ikke-nulltransaksjoner utføres ved hjelp av to offentlige nøkler: lommeboken og tjenestenøkkelen. Verifikasjonsprosessen kan deles inn i to hovedtrinn: den første er å sjekke sammendraget av den offentlige nøkkelen til lommeboken, og den andre er å sjekke den elektroniske digitale signaturen til transaksjonen, den samme konsoliderte som ble dannet ved hjelp av to hemmelige nøkler ( lommebok og service). Hvis gyldigheten av den digitale signaturen er bekreftet, blir transaksjonen lagt inn i registeret etter ytterligere verifisering.

Et logisk spørsmål kan oppstå: hvordan sjekke om en transaksjon tilhører en bestemt kjede med "roten" i form av en null transaksjon? For dette formålet er verifiseringsprosessen supplert med ett trinn til - tilkoblingskontroll. Det er her vi vil trenge dataene fra de to første feltene, som vi så langt har ignorert.

La oss tenke oss at vi må sjekke om transaksjon nr. 3 faktisk kommer etter transaksjon nr. 2. For å gjøre dette, ved å bruke den kombinerte hashing-metoden, beregnes hash-funksjonsverdien for dataene fra det tredje, fjerde og femte feltet i transaksjon nr. 2. Deretter utføres sammenkoblingen av data fra det første feltet i transaksjon nr. 3 og den tidligere oppnådde kombinerte hashfunksjonsverdien for data fra det tredje, fjerde og femte feltet i transaksjon nr. 2. Alt dette kjøres også gjennom to hash-funksjoner SHA256 og RIPEMD160. Hvis den mottatte verdien samsvarer med dataene i det andre feltet i transaksjon nr. 2, blir kontrollen bestått og forbindelsen bekreftet. Dette vises tydeligere i figurene under.

Generelt sett ser teknologien for å generere og legge inn en melding inn i registeret akkurat slik ut. En visuell illustrasjon av prosessen med å danne en kjede av varsler er presentert i følgende figur:

I denne teksten vil vi ikke dvele ved detaljene, som utvilsomt eksisterer, og gå tilbake til å diskutere selve ideen om en desentralisert offentlig nøkkelinfrastruktur.

Så siden søkeren selv sender inn en søknad om registrering av meldinger, som ikke er lagret i CA-databasen, men i registeret, bør de viktigste arkitektoniske komponentene til DPKI vurderes:

1. Register over gyldige meldinger (RDN).
2. Register over tilbakekalte meldinger (RON).
3. Register over suspenderte varsler (RPN).

Informasjon om offentlige nøkler lagres i RDN/RON/RPN i form av hash-funksjonsverdier. Det er også verdt å merke seg at disse enten kan være forskjellige registre, eller forskjellige kjeder, eller til og med én kjede som en del av et enkelt register, når informasjon om statusen til en vanlig offentlig nøkkel (tilbakekalling, suspensjon osv.) legges inn i fjerde felt i datastrukturen i form av den tilsvarende kodeverdien. Det er mange forskjellige alternativer for den arkitektoniske implementeringen av DPKI, og valget av den ene eller den andre avhenger av en rekke faktorer, for eksempel slike optimaliseringskriterier som kostnadene for langtidsminne for lagring av offentlige nøkler, etc.

Dermed kan DPKI vise seg å være, om ikke enklere, så i det minste sammenlignbar med en sentralisert løsning når det gjelder arkitektonisk kompleksitet.

Hovedspørsmålet gjenstår - Hvilket register er egnet for å implementere teknologien?

Hovedkravet til registeret er evnen til å generere transaksjoner av enhver type. Det mest kjente eksemplet på en hovedbok er Bitcoin-nettverket. Men når du implementerer teknologien beskrevet ovenfor, oppstår det visse vanskeligheter: begrensningene til det eksisterende skriptspråket, mangelen på nødvendige mekanismer for å behandle vilkårlige sett med data, metoder for å generere transaksjoner av en vilkårlig type, og mye mer.

Vi i ENCRY prøvde å løse problemene formulert ovenfor og utviklet et register, som etter vår mening har en rekke fordeler, nemlig:

• støtter flere typer transaksjoner: den kan både utveksle eiendeler (det vil si utføre finansielle transaksjoner) og opprette transaksjoner med en vilkårlig struktur,
• utviklere har tilgang til det proprietære programmeringsspråket PrismLang, som gir nødvendig fleksibilitet ved løsning av ulike teknologiske problemer,
• en mekanisme for behandling av vilkårlige datasett er gitt.

Hvis vi tar en forenklet tilnærming, finner vi følgende handlingssekvens:

1. Søkeren registrerer seg hos DPKI og mottar en digital lommebok. Lommebokadresse er hash-verdien til lommebokens offentlige nøkkel. Den private nøkkelen til lommeboken er kun kjent for søkeren.
2. Den registrerte personen får tilgang til tjenestens hemmelige nøkkel.
3. Emnet genererer en nulltransaksjon og verifiserer den med en digital signatur ved hjelp av lommebokens hemmelige nøkkel.
4. Hvis en annen transaksjon enn null dannes, sertifiseres den av en elektronisk digital signatur ved bruk av to hemmelige nøkler: en lommebok og en tjeneste.
5. Subjektet sender inn en transaksjon til bassenget.
6. ENCRY-nettverksnoden leser transaksjonen fra bassenget og sjekker den digitale signaturen, samt tilkoblingen til transaksjonen.
7. Hvis den digitale signaturen er gyldig og forbindelsen er bekreftet, forbereder den transaksjonen for innføring i registeret.

Her fungerer registeret som en distribuert database som lagrer informasjon om gyldige, kansellerte og suspenderte varsler.

Selvfølgelig er ikke desentralisering et universalmiddel. Det grunnleggende problemet med primær brukerautentisering forsvinner ikke noe sted: hvis verifiseringen av søkeren for øyeblikket utføres av CR, foreslås det i DPKI å delegere verifiseringen til fellesskapsmedlemmer og bruke økonomisk motivasjon for å stimulere aktivitet. Åpen kildekode-verifiseringsteknologi er velkjent. Effektiviteten av slik verifisering er bekreftet i praksis. La oss igjen minne om en rekke høyprofilerte undersøkelser fra nettpublikasjonen Bellingcat.

Men generelt kommer følgende bilde frem: DPKI er en mulighet til å rette opp, om ikke alle, så mange av manglene ved sentralisert PKI.

Abonner på vår Habrablogg, vi planlegger å fortsette å aktivt dekke vår forskning og utvikling, og følge med Twitter, hvis du ikke vil gå glipp av andre nyheter om ENCRY-prosjekter.

Kilde: www.habr.com