DPKI: eliminera bristerna med centraliserad PKI med blockchain

Det är ingen hemlighet att ett av de vanligaste hjälpverktygen, utan vilka dataskydd i öppna nätverk är omöjligt, är digital certifikatteknologi. Det är dock ingen hemlighet att den största nackdelen med tekniken är ett ovillkorligt förtroende för de centra som utfärdar digitala certifikat. Director of Technology and Innovation på ENCRY Andrey Chmora föreslog ett nytt sätt att organisera offentlig nyckelinfrastruktur (Public Key Infrastructure, PKI), som kommer att hjälpa till att eliminera nuvarande brister och som använder distribuerad ledger-teknik (blockchain). Men först till kvarn.

Om du är bekant med hur din nuvarande offentliga nyckelinfrastruktur fungerar och känner till dess viktigaste brister, kan du hoppa vidare till det vi föreslår att ändra nedan.

Vad är digitala signaturer och certifikat?Interaktion på Internet innebär alltid överföring av data. Vi har alla ett intresse av att se till att data överförs säkert. Men vad är säkerhet? De mest eftertraktade säkerhetstjänsterna är konfidentialitet, integritet och autenticitet. För detta ändamål används för närvarande metoder för asymmetrisk kryptografi, eller kryptografi med en offentlig nyckel.

Låt oss börja med det faktum att för att använda dessa metoder måste interaktionsämnena ha två individuella parade nycklar - offentliga och hemliga. Med deras hjälp tillhandahålls säkerhetstjänsterna vi nämnde ovan.

Hur uppnås konfidentialitet för informationsöverföring? Innan data skickas krypterar (omvandlar) den sändande abonnenten den öppna datan med hjälp av mottagarens publika nyckel, och mottagaren dekrypterar den mottagna chiffertexten med hjälp av den parade hemliga nyckeln.

Hur uppnås integriteten och autenticiteten hos den överförda informationen? För att lösa detta problem skapades en annan mekanism. Öppna data krypteras inte, men resultatet av att tillämpa den kryptografiska hashfunktionen - en "komprimerad" bild av indatasekvensen - överförs i krypterad form. Resultatet av sådan hash kallas "sammandrag", och det krypteras med den hemliga nyckeln för den sändande abonnenten ("vittnet"). Som ett resultat av kryptering av sammandraget erhålls en digital signatur. Den, tillsammans med den klara texten, överförs till mottagarabonnenten ("verifierare"). Han dekrypterar den digitala signaturen på vittnets publika nyckel och jämför den med resultatet av att tillämpa en kryptografisk hashfunktion, som verifieraren beräknar oberoende baserat på mottagna öppna data. Om de matchar, indikerar detta att data överfördes i en autentisk och fullständig form av den sändande abonnenten och inte modifierad av en angripare.

De flesta resurser som arbetar med personuppgifter och betalningsinformation (banker, försäkringsbolag, flygbolag, betalningssystem, samt statliga portaler som skatteverket) använder aktivt asymmetriska kryptografimetoder.

Vad har ett digitalt certifikat med det att göra? Det är enkelt. Både den första och den andra processen involverar offentliga nycklar, och eftersom de spelar en central roll är det mycket viktigt att säkerställa att nycklarna faktiskt tillhör avsändaren (vittnet, vid signaturverifiering) eller mottagaren och inte är ersättas med nycklar från angripare. Det är därför digitala certifikat finns för att säkerställa äktheten och integriteten för den publika nyckeln.

Notera: äktheten och integriteten för den publika nyckeln bekräftas på exakt samma sätt som äktheten och integriteten för offentliga data, det vill säga med hjälp av en elektronisk digital signatur (EDS).
Var kommer digitala certifikat ifrån?Betrodda certifikatutfärdare, eller certifikatutfärdare (CA), ansvarar för att utfärda och underhålla digitala certifikat. Sökanden begär utfärdande av ett certifikat från CA, genomgår identifiering på Registration Center (CR) och får ett certifikat från CA. CA garanterar att den publika nyckeln från certifikatet tillhör exakt den enhet för vilken den utfärdades.

Om du inte bekräftar äktheten av den publika nyckeln kan en angripare under överföringen/lagringen av denna nyckel ersätta den med sin egen. Om substitutionen har ägt rum kommer angriparen att kunna dekryptera allt som den sändande abonnenten sänder till den mottagande abonnenten, eller ändra öppna data efter eget gottfinnande.

Digitala certifikat används överallt där asymmetrisk kryptografi är tillgänglig. Ett av de vanligaste digitala certifikaten är SSL-certifikat för säker kommunikation över HTTPS-protokollet. Hundratals företag registrerade i olika jurisdiktioner är involverade i att utfärda SSL-certifikat. Huvudandelen faller på fem till tio stora betrodda centra: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.

CA och CR är komponenter i PKI, som även inkluderar:

• Öppna katalogen – en offentlig databas som tillhandahåller säker lagring av digitala certifikat.
• Certifikatspärrlista – en offentlig databas som tillhandahåller säker lagring av digitala certifikat för återkallade offentliga nycklar (till exempel på grund av att en ihopparad privat nyckel har komprometterats). Infrastrukturämnen kan självständigt komma åt denna databas, eller så kan de använda det specialiserade Online Certification Status Protocol (OCSP), vilket förenklar verifieringsprocessen.
• Certifikatanvändare – betjänade PKI-subjekt som har ingått ett användaravtal med CA och verifierar den digitala signaturen och/eller krypterar data baserat på den publika nyckeln från certifikatet.
• Anhängare – betjänade PKI-subjekt som äger en hemlig nyckel parad med den publika nyckeln från certifikatet, och som har ingått ett abonnentavtal med CA. Abonnenten kan samtidigt vara en användare av certifikatet.

Sålunda är betrodda enheter i den offentliga nyckelinfrastrukturen, som inkluderar CA, CR och öppna kataloger, ansvariga för:

1. Verifiering av äktheten av den sökandes identitet.
2. Profilering av certifikatet för den offentliga nyckeln.
3. Utfärdande av ett certifikat för en publik nyckel för en sökande vars identitet har bekräftats på ett tillförlitligt sätt.
4. Ändra statusen för certifikatet för den offentliga nyckeln.
5. Tillhandahålla information om den aktuella statusen för certifikatet för den offentliga nyckeln.

Nackdelar med PKI, vilka är de?Den grundläggande bristen i PKI är närvaron av betrodda enheter.
Användare måste ovillkorligen lita på CA och CR. Men, som praxis visar, är ovillkorligt förtroende fyllt av allvarliga konsekvenser.

Under de senaste tio åren har det förekommit flera stora skandaler inom detta område relaterade till sårbarhet i infrastruktur.

— 2010 började skadlig programvara Stuxnet spridas online, signerad med stulna digitala certifikat från RealTek och JMicron.

– Under 2017 anklagade Google Symantec för att ha utfärdat ett stort antal förfalskade certifikat. Vid den tiden var Symantec en av de största CA sett till produktionsvolymer. I webbläsaren Google Chrome 70 stoppades stödet för certifikat utfärdade av detta företag och dess anslutna centra GeoTrust och Thawte före den 1 december 2017.

CA:erna komprometterades, och som ett resultat led alla - CA:erna själva, såväl som användare och prenumeranter. Förtroendet för infrastrukturen har underminerats. Dessutom kan digitala certifikat blockeras i samband med politiska konflikter, vilket också kommer att påverka driften av många resurser. Det är precis vad man fruktade för flera år sedan i den ryska presidentadministrationen, där man 2016 diskuterade möjligheten att skapa ett statligt certifieringscenter som skulle utfärda SSL-certifikat till sajter på RuNet. Det nuvarande tillståndet är sådant att även statliga portaler i Ryssland begagnade digitala certifikat utfärdade av amerikanska företag Comodo eller Thawte (ett dotterbolag till Symantec).

Det finns ett annat problem - frågan primär autentisering (autentisering) av användare. Hur identifierar man en användare som har kontaktat CA med en begäran om att utfärda ett digitalt certifikat utan direkt personlig kontakt? Nu löses detta situationsmässigt beroende på infrastrukturens kapacitet. Något är hämtat från öppna register (till exempel information om juridiska personer som begär intyg); i de fall de sökande är privatpersoner kan bankkontor eller postkontor användas, där deras identitet bekräftas med hjälp av identifikationshandlingar, till exempel ett pass.

Problemet med att förfalska autentiseringsuppgifter i syfte att efterlikna sig är ett grundläggande problem. Låt oss notera att det inte finns någon fullständig lösning på detta problem på grund av informationsteoretiska skäl: utan att ha tillförlitlig information a priori är det omöjligt att bekräfta eller förneka äktheten av ett visst ämne. Som regel är det för verifiering nödvändigt att presentera en uppsättning dokument som styrker sökandens identitet. Det finns många olika verifieringsmetoder, men ingen av dem ger en fullständig garanti för dokumentens äkthet. Följaktligen kan äktheten av sökandens identitet inte heller garanteras.

Hur kan dessa brister elimineras?Om problemen med PKI i dess nuvarande tillstånd kan förklaras av centralisering, så är det logiskt att anta att decentralisering skulle bidra till att delvis eliminera de identifierade bristerna.

Decentralisering innebär inte närvaron av betrodda enheter - om du skapar decentraliserad infrastruktur för offentlig nyckel (Decentraliserad infrastruktur för offentlig nyckel, DPKI), då behövs varken CA eller CR. Låt oss överge konceptet med ett digitalt certifikat och använda ett distribuerat register för att lagra information om publika nycklar. I vårt fall kallar vi ett register för en linjär databas som består av enskilda poster (block) länkade med blockkedjeteknik. Istället för ett digitalt certifikat kommer vi att introducera begreppet "avisering".

Hur processen för att ta emot, verifiera och avbryta meddelanden kommer att se ut i den föreslagna DPKI:

1. Varje sökande lämnar in en ansökan om anmälan självständigt genom att fylla i ett formulär under registreringen, varefter han skapar en transaktion som lagras i en specialiserad pool.

2. Information om den publika nyckeln, tillsammans med ägarens uppgifter och annan metadata, lagras i ett distribuerat register, och inte i ett digitalt certifikat, för vilket utfärdandet i en centraliserad PKI CA är ansvarig.

3. Verifiering av äktheten av den sökandes identitet utförs i efterhand genom gemensamma ansträngningar från DPKI-användargemenskapen, och inte av CR.

4. Endast ägaren av ett sådant meddelande kan ändra statusen för en offentlig nyckel.

5. Vem som helst kan komma åt den distribuerade huvudboken och kontrollera den aktuella statusen för den publika nyckeln.

Obs: Gemenskapsverifiering av en sökandes identitet kan verka opålitlig vid första anblicken. Men vi måste komma ihåg att nuförtiden lämnar alla användare av digitala tjänster oundvikligen ett digitalt fotavtryck, och denna process kommer bara att fortsätta ta fart. Öppna elektroniska register över juridiska personer, kartor, digitalisering av terrängbilder, sociala nätverk - allt detta är allmänt tillgängliga verktyg. De används redan framgångsrikt under utredningar av både journalister och brottsbekämpande myndigheter. Till exempel räcker det med att påminna om utredningarna av Bellingcat eller det gemensamma utredningsteamet JIT, som studerar omständigheterna kring kraschen av den malaysiska Boeing.

Så hur skulle en decentraliserad offentlig nyckelinfrastruktur fungera i praktiken? Låt oss uppehålla oss vid beskrivningen av själva tekniken, som vi patenterade 2018 och vi anser det med rätta vara vårt kunnande.

Föreställ dig att det finns någon ägare som äger många publika nycklar, där varje nyckel är en viss transaktion som lagras i registret. I avsaknad av en CA, hur kan du förstå att alla nycklar tillhör just denna ägare? För att lösa detta problem skapas en nolltransaktion, som innehåller information om ägaren och hans plånbok (från vilken provisionen för att placera transaktionen i registret debiteras). Nolltransaktionen är ett slags "ankare" till vilket följande transaktioner med data om publika nycklar kommer att kopplas. Varje sådan transaktion innehåller en specialiserad datastruktur, eller med andra ord, ett meddelande.

Notifiering är en strukturerad uppsättning data som består av funktionella fält och inklusive information om ägarens publika nyckel, vars beständighet garanteras genom placering i en av de tillhörande posterna i det distribuerade registret.

Nästa logiska fråga är hur bildas en nolltransaktion? Nolltransaktionen – liksom efterföljande transaktioner – är en aggregering av sex datafält. Under bildandet av en nolltransaktion är nyckelparet i plånboken involverat (offentliga och parade hemliga nycklar). Detta nycklar visas i det ögonblick då användaren registrerar sin plånbok, från vilken provisionen för att placera en nolltransaktion i registret och därefter operationer med aviseringar kommer att debiteras.

Som visas i figuren genereras en plånboksnyckelsammandragning genom att sekventiellt tillämpa hashfunktionerna SHA256 och RIPEMD160. Här är RIPEMD160 ansvarig för den kompakta representationen av data, vars bredd inte överstiger 160 bitar. Detta är viktigt eftersom registret inte är en billig databas. Själva den publika nyckeln anges i det femte fältet. Det första fältet innehåller data som upprättar en anslutning till den föregående transaktionen. För en nolltransaktion innehåller detta fält ingenting, vilket skiljer det från efterföljande transaktioner. Det andra fältet är data för att kontrollera anslutningen av transaktioner. För korthetens skull kallar vi uppgifterna i det första och andra fältet för "länk" respektive "kontroll". Innehållet i dessa fält genereras av iterativ hashning, vilket visas genom att länka den andra och tredje transaktionen i figuren nedan.

Data från de första fem fälten certifieras av en elektronisk signatur, som genereras med hjälp av plånbokens hemliga nyckel.

Det är allt, nolltransaktionen skickas till poolen och efter framgångsrik verifiering läggs den in i registret. Nu kan du "länka" följande transaktioner till den. Låt oss överväga hur andra transaktioner än noll bildas.

Det första som förmodligen fångade dig är överflöd av nyckelpar. Utöver det redan välkända plånboksnyckelparet används vanliga nyckelpar och servicenyckelpar.

En vanlig offentlig nyckel är vad allting startade för. Denna nyckel är involverad i olika procedurer och processer som utvecklas i omvärlden (banktransaktioner och andra transaktioner, dokumentflöde, etc.). Till exempel kan en hemlig nyckel från ett vanligt par användas för att generera digitala signaturer för olika dokument - betalningsuppdrag etc., och en publik nyckel kan användas för att verifiera denna digitala signatur med efterföljande exekvering av dessa instruktioner, förutsatt att den är giltig.

Tjänsteparet utfärdas till den registrerade DPKI-subjektet. Namnet på detta par motsvarar dess syfte. Observera att vid bildande/kontroll av en nolltransaktion används inte servicenycklar.

Låt oss förtydliga syftet med nycklarna igen:

1. Plånboksnycklar används för att generera/verifiera både en nolltransaktion och alla andra icke-nulltransaktioner. Den privata nyckeln till en plånbok är känd endast för ägaren av plånboken, som också är ägare till många vanliga offentliga nycklar.
2. En vanlig publik nyckel liknar i syfte en publik nyckel för vilken ett certifikat utfärdas i en centraliserad PKI.
3. Servicenyckelparet tillhör DPKI. Den hemliga nyckeln utfärdas till registrerade enheter och används vid generering av digitala signaturer för transaktioner (förutom för nolltransaktioner). Offentlig används för att verifiera den elektroniska digitala signaturen för en transaktion innan den läggs upp i registret.

Det finns alltså två grupper av nycklar. Den första inkluderar servicenycklar och plånboksnycklar - de är bara vettiga i DPKI-sammanhang. Den andra gruppen inkluderar vanliga nycklar - deras omfattning kan variera och bestäms av applikationsuppgifterna där de används. Samtidigt säkerställer DPKI integriteten och äktheten hos vanliga publika nycklar.

Obs: Servicenyckelparet kan vara känt för olika DPKI-enheter. Det kan till exempel vara lika för alla. Det är av denna anledning som när man genererar signaturen för varje transaktion som inte är noll, används två hemliga nycklar, varav en är plånboksnyckeln - den är endast känd för ägaren av plånboken, som också är ägare till många vanliga offentliga nycklar. Alla nycklar har sin egen betydelse. Det är till exempel alltid möjligt att bevisa att transaktionen registrerades i registret av en registrerad DPKI-subjekt, eftersom signaturen även genererades på en säkerhetsnyckel. Och det kan inte förekomma något missbruk, såsom DOS-attacker, eftersom ägaren betalar för varje transaktion.

Alla transaktioner som följer noll-ettan bildas på liknande sätt: den publika nyckeln (inte plånboken, som i fallet med nolltransaktionen, utan från ett vanligt nyckelpar) körs genom två hashfunktioner SHA256 och RIPEMD160. Så här bildas data i det tredje fältet. Det fjärde fältet innehåller åtföljande information (till exempel information om aktuell status, utgångsdatum, tidsstämpel, identifierare för använda kryptoalgoritmer, etc.). Det femte fältet innehåller den publika nyckeln från tjänstnyckelparet. Med dess hjälp kommer den digitala signaturen sedan att kontrolleras, så att den replikeras. Låt oss motivera behovet av ett sådant tillvägagångssätt.

Kom ihåg att en transaktion läggs in i en pool och lagras där tills den behandlas. Att lagra i en pool är förknippat med en viss risk – transaktionsdata kan förfalskas. Ägaren certifierar transaktionsdata med en elektronisk digital signatur. Den publika nyckeln för att verifiera denna digitala signatur anges explicit i ett av transaktionsfälten och läggs därefter in i registret. Det speciella med transaktionsbearbetning är sådana att en angripare kan ändra data efter eget gottfinnande och sedan verifiera den med hjälp av sin hemliga nyckel, och indikera en parad offentlig nyckel för att verifiera den digitala signaturen i transaktionen. Om äkthet och integritet säkerställs uteslutande genom digital signatur, kommer en sådan förfalskning att gå obemärkt förbi. Men om det, förutom den digitala signaturen, finns en ytterligare mekanism som säkerställer både arkivering och beständighet av den lagrade informationen, kan förfalskningen upptäckas. För att göra detta räcker det att ange ägarens äkta publika nyckel i registret. Låt oss förklara hur detta fungerar.

Låt angriparen förfalska transaktionsdata. Med tanke på nycklar och digitala signaturer är följande alternativ möjliga:

1. Angriparen placerar sin publika nyckel i transaktionen medan ägarens digitala signatur förblir oförändrad.
2. Angriparen skapar en digital signatur på sin privata nyckel, men lämnar ägarens publika nyckel oförändrad.
3. Angriparen skapar en digital signatur på sin privata nyckel och placerar en parad offentlig nyckel i transaktionen.

Uppenbarligen är alternativ 1 och 2 meningslösa, eftersom de alltid kommer att upptäckas under den digitala signaturverifieringen. Endast alternativ 3 är vettigt, och om en angripare bildar en digital signatur på sin egen hemliga nyckel, tvingas han spara en parad offentlig nyckel i transaktionen, som skiljer sig från ägarens publika nyckel. Detta är det enda sättet för en angripare att införa förfalskade data.

Låt oss anta att ägaren har ett fast nycklar - privata och offentliga. Låt data certifieras med digital signatur med den hemliga nyckeln från detta par, och den publika nyckeln indikeras i transaktionen. Låt oss också anta att denna publika nyckel tidigare har skrivits in i registret och att dess äkthet har verifierats på ett tillförlitligt sätt. Då kommer en förfalskning att indikeras genom att den publika nyckeln från transaktionen inte motsvarar den publika nyckeln från registret.

Låt oss sammanfatta. Vid bearbetning av ägarens allra första transaktionsdata är det nödvändigt att verifiera äktheten av den publika nyckeln som införts i registret. För att göra detta, läs nyckeln från registret och jämför den med ägarens sanna offentliga nyckel inom säkerhetsperimetern (området med relativ osårbarhet). Om nyckelns äkthet bekräftas och dess beständighet garanteras vid placering, kan äktheten av nyckeln från den efterföljande transaktionen enkelt bekräftas/motbevisas genom att jämföra den med nyckeln från registret. Med andra ord, nyckeln från registret används som ett referensexempel. Alla andra ägartransaktioner behandlas på liknande sätt.

Transaktionen är certifierad av en elektronisk digital signatur - det är här hemliga nycklar behövs, och inte en, utan två på en gång - en servicenyckel och en plånboksnyckel. Tack vare användningen av två hemliga nycklar säkerställs den nödvändiga säkerhetsnivån - trots allt kan tjänstens hemliga nyckel vara känd för andra användare, medan den hemliga nyckeln till plånboken endast är känd för ägaren av det vanliga nyckelparet. Vi kallade en sådan tvånyckelsignatur för en "konsoliderad" digital signatur.

Verifiering av icke-nulltransaktioner utförs med två offentliga nycklar: plånboken och servicenyckeln. Verifieringsprocessen kan delas upp i två huvudsteg: det första är att kontrollera sammanfattningen av plånbokens publika nyckel, och det andra är att kontrollera transaktionens elektroniska digitala signatur, samma konsoliderade som bildades med två hemliga nycklar ( plånbok och service). Om giltigheten av den digitala signaturen bekräftas, läggs transaktionen in i registret efter ytterligare verifiering.

En logisk fråga kan uppstå: hur kontrollerar man om en transaktion tillhör en specifik kedja med "roten" i form av en nolltransaktion? För detta ändamål kompletteras verifieringsprocessen med ytterligare ett steg - anslutningskontroll. Det är här vi kommer att behöva data från de två första fälten, som vi hittills har ignorerat.

Låt oss föreställa oss att vi måste kontrollera om transaktion nr 3 faktiskt kommer efter transaktion nr 2. För att göra detta, med hjälp av den kombinerade hashmetoden, beräknas hashfunktionsvärdet för data från det tredje, fjärde och femte fältet i transaktion nr 2. Därefter utförs sammankopplingen av data från det första fältet i transaktion nr 3 och det tidigare erhållna kombinerade hashfunktionsvärdet för data från det tredje, fjärde och femte fältet i transaktion nr 2. Allt detta körs också genom två hash-funktioner SHA256 och RIPEMD160. Om det mottagna värdet stämmer överens med data i det andra fältet i transaktion nr 2, passerar kontrollen och anslutningen bekräftas. Detta visas tydligare i figurerna nedan.

Generellt sett ser tekniken för att generera och föra in en anmälan i registret ut exakt så här. En visuell illustration av processen att bilda en kedja av meddelanden presenteras i följande figur:

I den här texten kommer vi inte att uppehålla oss vid detaljerna, som utan tvekan finns, och återgå till att diskutera själva idén om en decentraliserad infrastruktur för offentlig nyckel.

Så eftersom sökanden själv lämnar in en ansökan om registrering av meddelanden, som inte lagras i CA-databasen, utan i registret, bör de viktigaste arkitektoniska komponenterna i DPKI beaktas:

1. Register över giltiga anmälningar (RDN).
2. Register över återkallade anmälningar (RON).
3. Register över avstängda meddelanden (RPN).

Information om publika nycklar lagras i RDN/RON/RPN i form av hashfunktionsvärden. Det är också värt att notera att dessa antingen kan vara olika register, eller olika kedjor, eller till och med en kedja som en del av ett enda register, när information om statusen för en vanlig offentlig nyckel (återkallelse, avstängning etc.) läggs in i fjärde fältet i datastrukturen i form av motsvarande kodvärde. Det finns många olika alternativ för den arkitektoniska implementeringen av DPKI, och valet av det ena eller det andra beror på ett antal faktorer, till exempel sådana optimeringskriterier som kostnaden för långtidsminne för lagring av publika nycklar, etc.

Således kan DPKI visa sig vara, om inte enklare, så åtminstone jämförbar med en centraliserad lösning vad gäller arkitektonisk komplexitet.

Huvudfrågan kvarstår - Vilket register är lämpligt för att implementera tekniken?

Huvudkravet för registret är förmågan att generera transaktioner av alla slag. Det mest kända exemplet på en reskontra är Bitcoin-nätverket. Men när man implementerar tekniken som beskrivs ovan uppstår vissa svårigheter: begränsningarna av det befintliga skriptspråket, bristen på nödvändiga mekanismer för att bearbeta godtyckliga uppsättningar av data, metoder för att generera transaktioner av en godtycklig typ och mycket mer.

Vi på ENCRY försökte lösa problemen formulerade ovan och utvecklade ett register, som enligt vår uppfattning har ett antal fördelar, nämligen:

• stöder flera typer av transaktioner: det kan både utbyta tillgångar (det vill säga utföra finansiella transaktioner) och skapa transaktioner med en godtycklig struktur,
• utvecklare har tillgång till det proprietära programmeringsspråket PrismLang, som ger den nödvändiga flexibiliteten vid lösning av olika tekniska problem,
• en mekanism för behandling av godtyckliga datamängder tillhandahålls.

Om vi ​​tar ett förenklat tillvägagångssätt, sker följande sekvens av åtgärder:

1. Den sökande registrerar sig hos DPKI och får en digital plånbok. Plånboksadress är hashvärdet för plånbokens publika nyckel. Den privata nyckeln till plånboken är endast känd för sökanden.
2. Den registrerade personen ges tillgång till tjänstens hemliga nyckel.
3. Ämnet genererar en nolltransaktion och verifierar den med en digital signatur med hjälp av plånbokens hemliga nyckel.
4. Om en annan transaktion än noll bildas, certifieras den av en elektronisk digital signatur med två hemliga nycklar: en plånbok och en tjänst.
5. Försökspersonen lämnar in en transaktion till poolen.
6. ENCRY-nätverksnoden läser transaktionen från poolen och kontrollerar den digitala signaturen, såväl som transaktionens anslutning.
7. Om den digitala signaturen är giltig och anslutningen bekräftas, förbereder den transaktionen för införande i registret.

Här fungerar registret som en distribuerad databas som lagrar information om giltiga, avbrutna och inställda meddelanden.

Naturligtvis är decentralisering inget universalmedel. Det grundläggande problemet med primär användarautentisering försvinner inte någonstans: om verifieringen av sökanden för närvarande utförs av CR, föreslås det i DPKI att delegera verifieringen till gemenskapsmedlemmar och använda ekonomisk motivation för att stimulera aktivitet. Verifieringsteknik med öppen källkod är välkänd. Effektiviteten av en sådan kontroll har bekräftats i praktiken. Låt oss återigen minnas ett antal högprofilerade undersökningar av onlinepublikationen Bellingcat.

Men generellt sett framträder följande bild: DPKI är en möjlighet att rätta till, om inte alla, så många av bristerna med centraliserad PKI.

Prenumerera på vår Habrablogg, vi planerar att fortsätta att aktivt täcka vår forskning och utveckling och följa Twitter, om du inte vill missa andra nyheter om ENCRY-projekt.

Källa: will.com