Het is geen geheim dat een van de meest gebruikte hulpmiddelen, zonder welke gegevensbescherming in open netwerken onmogelijk is, de digitale certificaattechnologie is. Het is echter geen geheim dat het belangrijkste nadeel van de technologie het onvoorwaardelijke vertrouwen is in de centra die digitale certificaten uitgeven. Directeur Technologie en Innovatie bij ENCRY Andrey Chmora stelde een nieuwe benadering van organiseren voor openbare sleutelinfrastructuur (Openbare sleutelinfrastructuur, PKI), dat de huidige tekortkomingen zal helpen elimineren en dat gebruik maakt van gedistribueerde grootboektechnologie (blockchain). Maar eerst dingen eerst.
Als u bekend bent met hoe uw huidige publieke-sleutelinfrastructuur werkt en de belangrijkste tekortkomingen ervan kent, kunt u doorgaan met wat we hieronder voorstellen te veranderen.
Wat zijn digitale handtekeningen en certificaten?Bij interactie op internet gaat het altijd om de overdracht van gegevens. We hebben er allemaal belang bij dat gegevens veilig worden verzonden. Maar wat is veiligheid? De meest gewilde beveiligingsdiensten zijn vertrouwelijkheid, integriteit en authenticiteit. Voor dit doel worden momenteel methoden van asymmetrische cryptografie, oftewel cryptografie met een publieke sleutel, gebruikt.
Laten we beginnen met het feit dat om deze methoden te gebruiken, de onderwerpen van interactie twee individuele gepaarde sleutels moeten hebben: openbaar en geheim. Met hun hulp worden de hierboven genoemde veiligheidsdiensten geleverd.
Hoe wordt de vertrouwelijkheid van informatieoverdracht bereikt? Voordat gegevens worden verzonden, codeert (cryptografisch transformeert) de verzendende abonnee de open gegevens met behulp van de openbare sleutel van de ontvanger, en de ontvanger decodeert de ontvangen cijfertekst met behulp van de gepaarde geheime sleutel.
Hoe wordt de integriteit en authenticiteit van de verzonden informatie bereikt? Om dit probleem op te lossen, werd een ander mechanisme gecreëerd. De open data zijn niet gecodeerd, maar het resultaat van het toepassen van de cryptografische hashfunctie – een “gecomprimeerd” beeld van de invoergegevensreeks – wordt in gecodeerde vorm verzonden. Het resultaat van een dergelijke hashing wordt een “digest” genoemd en wordt gecodeerd met behulp van de geheime sleutel van de verzendende abonnee (“de getuige”). Als gevolg van het versleutelen van de samenvatting wordt een digitale handtekening verkregen. Deze wordt, samen met de duidelijke tekst, verzonden naar de ontvangende abonnee (“verifier”). Hij decodeert de digitale handtekening op de publieke sleutel van de getuige en vergelijkt deze met het resultaat van het toepassen van een cryptografische hashfunctie, die de verificateur zelfstandig berekent op basis van de ontvangen open data. Als ze overeenkomen, geeft dit aan dat de gegevens in authentieke en volledige vorm zijn verzonden door de verzendende abonnee en niet zijn gewijzigd door een aanvaller.
De meeste bronnen die werken met persoonlijke gegevens en betalingsinformatie (banken, verzekeringsmaatschappijen, luchtvaartmaatschappijen, betalingssystemen, maar ook overheidsportals zoals de belastingdienst) maken actief gebruik van asymmetrische cryptografiemethoden.
Wat heeft een digitaal certificaat ermee te maken? Het is makkelijk. Bij zowel het eerste als het tweede proces zijn publieke sleutels betrokken, en aangezien deze een centrale rol spelen, is het erg belangrijk om ervoor te zorgen dat de sleutels daadwerkelijk toebehoren aan de afzender (de getuige, in het geval van handtekeningverificatie) of aan de ontvanger, en niet vervangen door de sleutels van aanvallers. Dit is de reden waarom er digitale certificaten bestaan om de authenticiteit en integriteit van de publieke sleutel te garanderen.
Let op: de authenticiteit en integriteit van de publieke sleutel wordt op precies dezelfde manier bevestigd als de authenticiteit en integriteit van publieke gegevens, dat wil zeggen met behulp van een elektronische digitale handtekening (EDS).
Waar komen digitale certificaten vandaan?Vertrouwde certificeringsinstanties, of certificeringsinstanties (CA's), zijn verantwoordelijk voor het uitgeven en onderhouden van digitale certificaten. De aanvrager vraagt de afgifte van een certificaat aan bij de CA, ondergaat identificatie bij het Registratiecentrum (CR) en ontvangt een certificaat van de CA. De CA garandeert dat de publieke sleutel uit het certificaat precies toebehoort aan de entiteit waarvoor deze is uitgegeven.
Als u de authenticiteit van de openbare sleutel niet bevestigt, kan een aanvaller tijdens de overdracht/opslag van deze sleutel deze vervangen door zijn eigen sleutel. Als de vervanging heeft plaatsgevonden, kan de aanvaller alles wat de verzendende abonnee naar de ontvangende abonnee verzendt, ontsleutelen of de open data naar eigen inzicht wijzigen.
Digitale certificaten worden overal gebruikt waar asymmetrische cryptografie beschikbaar is. Een van de meest voorkomende digitale certificaten zijn SSL-certificaten voor veilige communicatie via het HTTPS-protocol. Honderden bedrijven die in verschillende rechtsgebieden zijn geregistreerd, zijn betrokken bij de uitgifte van SSL-certificaten. Het grootste aandeel valt op vijf tot tien grote vertrouwde centra: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA en CR zijn componenten van PKI, die ook het volgende omvatten:
- Map openen – een openbare database die veilige opslag van digitale certificaten biedt.
- Certificaatintrekkingslijst – een openbare database die veilige opslag biedt van digitale certificaten van ingetrokken openbare sleutels (bijvoorbeeld als gevolg van het compromitteren van een gepaarde privésleutel). Infrastructuuronderwerpen hebben zelfstandig toegang tot deze database, of ze kunnen gebruik maken van het gespecialiseerde Online Certification Status Protocol (OCSP), dat het verificatieproces vereenvoudigt.
- Certificaat gebruikers – onderhouden PKI-subjecten die een gebruikersovereenkomst hebben gesloten met de CA en de digitale handtekening verifiëren en/of gegevens versleutelen op basis van de publieke sleutel uit het certificaat.
- Volgers – PKI-subjecten bediend die een geheime sleutel bezitten die is gekoppeld aan de publieke sleutel van het certificaat, en die een abonneeovereenkomst hebben gesloten met de CA. De abonnee kan tegelijkertijd gebruiker van het certificaat zijn.
Vertrouwde entiteiten van de openbare-sleutelinfrastructuur, waaronder CA's, CR's en open directory's, zijn dus verantwoordelijk voor:
1. Verificatie van de authenticiteit van de identiteit van de aanvrager.
2. Profilering van het publieke sleutelcertificaat.
3. Het uitgeven van een publieke sleutelcertificaat voor een aanvrager wiens identiteit op betrouwbare wijze is bevestigd.
4. Wijzig de status van het publieke sleutelcertificaat.
5. Het verstrekken van informatie over de huidige status van het publieke sleutelcertificaat.
Nadelen van PKI, wat zijn dat?Het fundamentele gebrek van PKI is de aanwezigheid van vertrouwde entiteiten.
Gebruikers moeten de CA en CR onvoorwaardelijk vertrouwen. Maar zoals de praktijk laat zien, heeft onvoorwaardelijk vertrouwen ernstige gevolgen.
De afgelopen tien jaar hebben zich op dit gebied verschillende grote schandalen voorgedaan die verband houden met de kwetsbaarheid van de infrastructuur.
— in 2010 begon de Stuxnet-malware zich online te verspreiden, ondertekend met gestolen digitale certificaten van RealTek en JMicron.
- In 2017 beschuldigde Google Symantec ervan een groot aantal vervalste certificaten uit te geven. Destijds was Symantec een van de grootste CA's qua productievolumes. In de Google Chrome 70-browser werd de ondersteuning voor certificaten uitgegeven door dit bedrijf en de aangesloten centra GeoTrust en Thawte vóór 1 december 2017 stopgezet.
De CA's werden gecompromitteerd en als gevolg daarvan leed iedereen: de CA's zelf, maar ook de gebruikers en abonnees. Het vertrouwen in de infrastructuur is ondermijnd. Bovendien kunnen digitale certificaten worden geblokkeerd in de context van politieke conflicten, wat ook de werking van veel bronnen zal beïnvloeden. Dit is precies wat enkele jaren geleden werd gevreesd binnen de Russische presidentiële regering, waar ze in 2016 de mogelijkheid bespraken om een staatscertificeringscentrum op te richten dat SSL-certificaten zou uitgeven aan sites op het RuNet. De huidige stand van zaken is zodanig dat zelfs staatsportalen in Rusland digitale certificaten uitgegeven door de Amerikaanse bedrijven Comodo of Thawte (een dochteronderneming van Symantec).
Er is nog een probleem: de vraag primaire authenticatie (authenticatie) van gebruikers. Hoe kan ik een gebruiker identificeren die contact heeft opgenomen met de CA met het verzoek om een digitaal certificaat uit te geven zonder direct persoonlijk contact? Nu wordt dit situationeel opgelost, afhankelijk van de mogelijkheden van de infrastructuur. Er wordt iets uit open registers gehaald (bijvoorbeeld informatie over rechtspersonen die certificaten aanvragen); in gevallen waarin de aanvragers natuurlijke personen zijn, kunnen bankkantoren of postkantoren worden gebruikt, waarbij hun identiteit wordt bevestigd met behulp van identificatiedocumenten, bijvoorbeeld een paspoort.
Het probleem van het vervalsen van legitimatiebewijzen met het oog op nabootsing van identiteit is van fundamenteel belang. Laten we opmerken dat er geen volledige oplossing voor dit probleem bestaat vanwege informatietheoretische redenen: zonder a priori betrouwbare informatie te hebben, is het onmogelijk om de authenticiteit van een bepaald onderwerp te bevestigen of te ontkennen. In de regel is het voor verificatie noodzakelijk om een reeks documenten te overleggen die de identiteit van de aanvrager bewijzen. Er zijn veel verschillende verificatiemethoden, maar geen enkele biedt een volledige garantie voor de authenticiteit van documenten. De authenticiteit van de identiteit van verzoeker kan dan ook niet worden gegarandeerd.
Hoe kunnen deze tekortkomingen worden geëlimineerd?Als de problemen van PKI in de huidige staat kunnen worden verklaard door centralisatie, dan is het logisch om aan te nemen dat decentralisatie de geïdentificeerde tekortkomingen gedeeltelijk zou kunnen wegnemen.
Decentralisatie impliceert niet de aanwezigheid van vertrouwde entiteiten - als u deze creëert gedecentraliseerde publieke sleutelinfrastructuur (Gedecentraliseerde publieke sleutelinfrastructuur, DPKI), dan zijn noch CA noch CR nodig. Laten we het concept van een digitaal certificaat achterwege laten en een gedistribueerd register gebruiken om informatie over publieke sleutels op te slaan. In ons geval noemen we een register een lineaire database die bestaat uit individuele records (blokken) die met behulp van blockchain-technologie met elkaar zijn verbonden. In plaats van een digitaal certificaat introduceren we het concept ‘melding’.
Hoe het proces van het ontvangen, verifiëren en annuleren van meldingen eruit zal zien in de voorgestelde DPKI:
1. Elke aanvrager dient zelfstandig een meldingsaanvraag in door tijdens de registratie een formulier in te vullen, waarna hij een transactie aanmaakt die wordt opgeslagen in een gespecialiseerde pool.
2. Informatie over de publieke sleutel wordt, samen met de gegevens van de eigenaar en andere metadata, opgeslagen in een gedistribueerd register, en niet in een digitaal certificaat, voor de uitgifte waarvan in een gecentraliseerde PKI de CA verantwoordelijk is.
3. Verificatie van de authenticiteit van de identiteit van de aanvrager wordt achteraf uitgevoerd door de gezamenlijke inspanningen van de DPKI-gebruikersgemeenschap, en niet door de CR.
4. Alleen de eigenaar van een dergelijke melding kan de status van een publieke sleutel wijzigen.
5. Iedereen heeft toegang tot het gedistribueerde grootboek en kan de huidige status van de publieke sleutel controleren.
Opmerking: de communautaire verificatie van de identiteit van een aanvrager kan op het eerste gezicht onbetrouwbaar lijken. Maar we moeten niet vergeten dat alle gebruikers van digitale diensten tegenwoordig onvermijdelijk een digitale voetafdruk achterlaten, en dat dit proces alleen maar aan kracht zal winnen. Open elektronische registers van rechtspersonen, kaarten, digitalisering van terreinafbeeldingen, sociale netwerken - dit zijn allemaal openbaar beschikbare hulpmiddelen. Ze worden al met succes gebruikt tijdens onderzoeken door zowel journalisten als wetshandhavingsinstanties. Het volstaat bijvoorbeeld om de onderzoeken van Bellingcat of het gezamenlijke onderzoeksteam JIT in herinnering te brengen, dat de omstandigheden van de crash van de Maleisische Boeing bestudeert.
Hoe zou een gedecentraliseerde publieke sleutelinfrastructuur in de praktijk werken? Laten we stilstaan bij de beschrijving van de technologie zelf, die wij gepatenteerd in 2018 en we beschouwen het terecht als onze knowhow.
Stel je voor dat er een eigenaar is die veel openbare sleutels bezit, waarbij elke sleutel een bepaalde transactie is die in het register is opgeslagen. Hoe kunt u, als er geen CA aanwezig is, begrijpen dat alle sleutels eigendom zijn van deze specifieke eigenaar? Om dit probleem op te lossen, wordt een nultransactie gemaakt, die informatie bevat over de eigenaar en zijn portemonnee (waarvan de commissie voor het plaatsen van de transactie in het register wordt afgeschreven). De nultransactie is een soort ‘anker’ waaraan de volgende transacties met gegevens over publieke sleutels worden gekoppeld. Elke dergelijke transactie bevat een gespecialiseerde datastructuur, of met andere woorden, een melding.
Melding is een gestructureerde set gegevens bestaande uit functionele velden en inclusief informatie over de openbare sleutel van de eigenaar, waarvan de persistentie wordt gegarandeerd door plaatsing in een van de bijbehorende records van het gedistribueerde register.
De volgende logische vraag is: hoe komt een nultransactie tot stand? De nultransactie is, net als de daaropvolgende transacties, een samenvoeging van zes gegevensvelden. Bij het tot stand komen van een nultransactie is het sleutelpaar van de portemonnee betrokken (openbare en gepaarde geheime sleutels). Dit paar sleutels verschijnt op het moment dat de gebruiker zijn portemonnee registreert, waarvan de commissie voor het plaatsen van een nultransactie in het register en vervolgens de handelingen met meldingen worden afgeschreven.
Zoals weergegeven in de afbeelding, wordt een publieke sleuteloverzicht van een portemonnee gegenereerd door sequentieel de hashfuncties SHA256 en RIPEMD160 toe te passen. Hier is RIPEMD160 verantwoordelijk voor de compacte weergave van gegevens, waarvan de breedte niet groter is dan 160 bits. Dit is belangrijk omdat het register geen goedkope database is. De publieke sleutel zelf wordt in het vijfde veld ingevoerd. Het eerste veld bevat gegevens die een verbinding tot stand brengen met de vorige transactie. Bij een nultransactie bevat dit veld niets, wat het onderscheidt van daaropvolgende transacties. Het tweede veld zijn gegevens voor het controleren van de connectiviteit van transacties. Kortheidshalve noemen we de gegevens in het eerste en tweede veld respectievelijk “link” en “check”. De inhoud van deze velden wordt gegenereerd door iteratieve hashing, zoals blijkt uit het koppelen van de tweede en derde transactie in de onderstaande figuur.
De gegevens uit de eerste vijf velden worden gecertificeerd door een elektronische handtekening, die wordt gegenereerd met behulp van de geheime sleutel van de portemonnee.
Dat is alles, de nultransactie wordt naar de pool gestuurd en na succesvolle verificatie in het register ingevoerd. Nu kunt u de volgende transacties eraan “koppelen”. Laten we eens kijken hoe andere transacties dan nul worden gevormd.
Het eerste dat waarschijnlijk opvalt, is de overvloed aan sleutelparen. Naast het reeds bekende portemonneesleutelpaar worden gewone en servicesleutelparen gebruikt.
Een gewone publieke sleutel is waar alles voor is begonnen. Deze sleutel is betrokken bij verschillende procedures en processen die zich in de buitenwereld afspelen (bank- en andere transacties, documentstroom, enz.). Een geheime sleutel van een gewoon paar kan bijvoorbeeld worden gebruikt om digitale handtekeningen te genereren voor verschillende documenten (betalingsopdrachten, enz.), en een publieke sleutel kan worden gebruikt om deze digitale handtekening te verifiëren bij de daaropvolgende uitvoering van deze instructies, op voorwaarde dat deze is geldig.
Het servicepaar wordt uitgegeven aan het geregistreerde DPKI-onderwerp. De naam van dit paar komt overeen met het doel ervan. Let op: bij het vormen/controleren van een nultransactie worden er geen servicesleutels gebruikt.
Laten we het doel van de sleutels nogmaals verduidelijken:
- Wallet-sleutels worden gebruikt om zowel een nultransactie als elke andere niet-nultransactie te genereren/verifiëren. De privésleutel van een portemonnee is alleen bekend bij de eigenaar van de portemonnee, die ook eigenaar is van veel gewone openbare sleutels.
- Een gewone publieke sleutel heeft qua doel een soortgelijk doel als een publieke sleutel waarvoor een certificaat wordt uitgegeven in een gecentraliseerde PKI.
- Het servicesleutelpaar is eigendom van DPKI. De geheime sleutel wordt uitgegeven aan geregistreerde entiteiten en wordt gebruikt bij het genereren van digitale handtekeningen voor transacties (behalve voor nultransacties). Openbaar wordt gebruikt om de elektronische digitale handtekening van een transactie te verifiëren voordat deze in het register wordt geplaatst.
Er zijn dus twee groepen sleutels. De eerste omvat servicesleutels en portemonneesleutels - deze hebben alleen zin in de context van DPKI. De tweede groep omvat gewone sleutels - hun reikwijdte kan variëren en wordt bepaald door de toepassingstaken waarin ze worden gebruikt. Tegelijkertijd garandeert DPKI de integriteit en authenticiteit van gewone publieke sleutels.
Opmerking: het servicesleutelpaar kan bekend zijn bij verschillende DPKI-entiteiten. Het kan bijvoorbeeld voor iedereen hetzelfde zijn. Het is om deze reden dat bij het genereren van de handtekening van elke transactie die niet nul is, twee geheime sleutels worden gebruikt, waarvan er één de portemonneesleutel is - deze is alleen bekend bij de eigenaar van de portemonnee, die ook de eigenaar is van veel gewone sleutels. openbare sleutels. Alle toetsen hebben hun eigen betekenis. Zo is het altijd mogelijk om te bewijzen dat de transactie door een geregistreerde DPKI-ondernemer in het register is ingevoerd, aangezien de handtekening ook op een geheime dienstsleutel is gegenereerd. En er kan geen sprake zijn van misbruik, zoals DOS-aanvallen, omdat de eigenaar voor elke transactie betaalt.
Alle transacties die volgen op de nul-één worden op een vergelijkbare manier gevormd: de publieke sleutel (niet de portemonnee, zoals in het geval van de nul-transactie, maar van een gewoon sleutelpaar) wordt door twee hash-functies SHA256 en RIPEMD160 gevoerd. Dit is hoe de gegevens van het derde veld worden gevormd. Het vierde veld bevat begeleidende informatie (bijvoorbeeld informatie over de huidige status, vervaldata, tijdstempel, identificatiegegevens van gebruikte crypto-algoritmen, enz.). Het vijfde veld bevat de publieke sleutel van het servicesleutelpaar. Met behulp hiervan wordt de digitale handtekening vervolgens gecontroleerd, zodat deze wordt gerepliceerd. Laten we de noodzaak van een dergelijke aanpak rechtvaardigen.
Bedenk dat een transactie in een pool wordt ingevoerd en daar wordt opgeslagen totdat deze wordt verwerkt. Het opslaan in een pool houdt een bepaald risico in: transactiegegevens kunnen vervalst worden. De eigenaar certificeert de transactiegegevens met een elektronische digitale handtekening. De publieke sleutel voor het verifiëren van deze digitale handtekening wordt expliciet aangegeven in één van de transactievelden en wordt vervolgens in het register ingevoerd. De bijzonderheden van transactieverwerking zijn zodanig dat een aanvaller de gegevens naar eigen goeddunken kan wijzigen en deze vervolgens kan verifiëren met behulp van zijn geheime sleutel, en een gepaarde openbare sleutel kan aangeven voor het verifiëren van de digitale handtekening in de transactie. Als authenticiteit en integriteit uitsluitend door middel van een digitale handtekening worden gewaarborgd, zal een dergelijke vervalsing onopgemerkt blijven. Als er echter naast de digitale handtekening een extra mechanisme is dat zowel de archivering als de persistentie van de opgeslagen informatie garandeert, kan de vervalsing worden gedetecteerd. Om dit te doen, volstaat het om de echte openbare sleutel van de eigenaar in het register in te voeren. Laten we uitleggen hoe dit werkt.
Laat de aanvaller transactiegegevens vervalsen. Vanuit het oogpunt van sleutels en digitale handtekeningen zijn de volgende opties mogelijk:
1. De aanvaller plaatst zijn publieke sleutel in de transactie terwijl de digitale handtekening van de eigenaar ongewijzigd blijft.
2. De aanvaller maakt een digitale handtekening op zijn privésleutel, maar laat de openbare sleutel van de eigenaar ongewijzigd.
3. De aanvaller creëert een digitale handtekening op zijn private sleutel en plaatst een gepaarde publieke sleutel in de transactie.
Het is duidelijk dat opties 1 en 2 zinloos zijn, omdat ze altijd zullen worden gedetecteerd tijdens de verificatie van de digitale handtekening. Alleen optie 3 heeft zin, en als een aanvaller een digitale handtekening op zijn eigen geheime sleutel vormt, wordt hij gedwongen een gepaarde publieke sleutel in de transactie op te slaan, die verschilt van de publieke sleutel van de eigenaar. Dit is de enige manier waarop een aanvaller vervalste gegevens kan opleggen.
Laten we aannemen dat de eigenaar een vast paar sleutels heeft: privé en openbaar. Laat de gegevens certificeren door middel van een digitale handtekening met behulp van de geheime sleutel van dit paar, en de publieke sleutel wordt aangegeven in de transactie. Laten we ook aannemen dat deze openbare sleutel eerder in het register is ingevoerd en dat de authenticiteit ervan op betrouwbare wijze is geverifieerd. Dan zal er sprake zijn van vervalsing doordat de publieke sleutel uit de transactie niet overeenkomt met de publieke sleutel uit het register.
Laten we het samenvatten. Bij het verwerken van de allereerste transactiegegevens van de eigenaar is het noodzakelijk om de authenticiteit van de in het register ingevoerde openbare sleutel te verifiëren. Om dit te doen, leest u de sleutel uit het register en vergelijkt u deze met de echte openbare sleutel van de eigenaar binnen de beveiligingsperimeter (gebied van relatieve onkwetsbaarheid). Als de authenticiteit van de sleutel wordt bevestigd en de persistentie ervan bij plaatsing wordt gegarandeerd, kan de authenticiteit van de sleutel uit de daaropvolgende transactie eenvoudig worden bevestigd/weerlegd door deze te vergelijken met de sleutel uit het register. Met andere woorden: de sleutel uit het register wordt gebruikt als referentievoorbeeld. Alle andere eigenaartransacties worden op dezelfde manier verwerkt.
De transactie wordt gecertificeerd door een elektronische digitale handtekening - dit is waar geheime sleutels nodig zijn, en niet één, maar twee tegelijk: een servicesleutel en een portemonneesleutel. Dankzij het gebruik van twee geheime sleutels wordt het noodzakelijke beveiligingsniveau gewaarborgd: de geheime dienstsleutel kan immers bekend zijn bij andere gebruikers, terwijl de geheime sleutel van de portemonnee alleen bekend is bij de eigenaar van het gewone sleutelpaar. We noemden zo’n handtekening met twee sleutels een ‘geconsolideerde’ digitale handtekening.
Verificatie van niet-null-transacties wordt uitgevoerd met behulp van twee openbare sleutels: de portemonnee en de servicesleutel. Het verificatieproces kan in twee hoofdfasen worden verdeeld: de eerste is het controleren van de samenvatting van de openbare sleutel van de portemonnee, en de tweede is het controleren van de elektronische digitale handtekening van de transactie, dezelfde geconsolideerde handtekening die is gevormd met behulp van twee geheime sleutels ( portemonnee en service). Als de geldigheid van de digitale handtekening wordt bevestigd, wordt de transactie na aanvullende verificatie in het register opgenomen.
Er kan een logische vraag rijzen: hoe controleer je of een transactie tot een specifieke keten behoort met de ‘root’ in de vorm van een nultransactie? Voor dit doel wordt het verificatieproces aangevuld met nog een fase: connectiviteitscontrole. Dit is waar we de gegevens uit de eerste twee velden nodig hebben, die we tot nu toe hebben genegeerd.
Laten we ons voorstellen dat we moeten controleren of transactie nr. 3 daadwerkelijk na transactie nr. 2 komt. Om dit te doen, wordt met behulp van de gecombineerde hashmethode de hashfunctiewaarde berekend voor de gegevens uit het derde, vierde en vijfde veld van transactie nr. 2. Vervolgens wordt de aaneenschakeling van gegevens uit het eerste veld van transactie nr. 3 en de eerder verkregen gecombineerde hashfunctiewaarde voor gegevens uit het derde, vierde en vijfde veld van transactie nr. 2 uitgevoerd. Dit alles wordt ook uitgevoerd via twee hashfuncties SHA256 en RIPEMD160. Als de ontvangen waarde overeenkomt met de gegevens in het tweede veld van transactie nr. 2, is de controle geslaagd en wordt de verbinding bevestigd. In onderstaande figuren wordt dit duidelijker weergegeven.
In grote lijnen ziet de technologie voor het genereren en invoeren van een melding in het register er precies zo uit. Een visuele illustratie van het proces van het vormen van een keten van meldingen wordt weergegeven in de volgende afbeelding:
In deze tekst zullen we niet ingaan op de details, die ongetwijfeld bestaan, en terugkeren naar het bespreken van het idee zelf van een gedecentraliseerde publieke sleutelinfrastructuur.
Aangezien de aanvrager zelf een aanvraag indient voor registratie van kennisgevingen, die niet in de CA-database, maar in het register zijn opgeslagen, moeten de belangrijkste architecturale componenten van DPKI in overweging worden genomen:
1. Register van geldige meldingen (RDN).
2. Register van ingetrokken meldingen (RON).
3. Register opgeschorte meldingen (RPN).
Informatie over publieke sleutels wordt in RDN/RON/RPN opgeslagen in de vorm van hashfunctiewaarden. Het is ook vermeldenswaard dat dit verschillende registers kunnen zijn, of verschillende ketens, of zelfs één keten als onderdeel van één register, wanneer informatie over de status van een gewone publieke sleutel (intrekking, opschorting, enz.) wordt ingevoerd in de vierde veld van de datastructuur in de vorm van de corresponderende codewaarde. Er zijn veel verschillende opties voor de architectonische implementatie van DPKI, en de keuze voor de een of de ander hangt af van een aantal factoren, bijvoorbeeld optimalisatiecriteria als de kosten van langetermijngeheugen voor het opslaan van openbare sleutels, enz.
DPKI kan dus, zo niet eenvoudiger, dan op zijn minst vergelijkbaar zijn met een gecentraliseerde oplossing in termen van architectonische complexiteit.
De belangrijkste vraag blijft: Welk register is geschikt om de technologie te implementeren?
De belangrijkste vereiste voor het register is de mogelijkheid om transacties van welk type dan ook te genereren. Het bekendste voorbeeld van een grootboek is het Bitcoin-netwerk. Maar bij het implementeren van de hierboven beschreven technologie doen zich bepaalde problemen voor: de beperkingen van de bestaande scripttaal, het ontbreken van noodzakelijke mechanismen voor het verwerken van willekeurige gegevenssets, methoden voor het genereren van transacties van een willekeurig type, en nog veel meer.
Wij van ENCRY hebben geprobeerd de hierboven geformuleerde problemen op te lossen en hebben een register ontwikkeld, dat naar onze mening een aantal voordelen heeft, namelijk:
- ondersteunt verschillende soorten transacties: het kan zowel activa uitwisselen (dat wil zeggen financiële transacties uitvoeren) als transacties creëren met een willekeurige structuur,
- ontwikkelaars hebben toegang tot de eigen programmeertaal PrismLang, die de nodige flexibiliteit biedt bij het oplossen van verschillende technologische problemen,
- er wordt voorzien in een mechanisme voor het verwerken van willekeurige datasets.
Als we een vereenvoudigde aanpak volgen, vindt de volgende reeks acties plaats:
- De aanvrager meldt zich aan bij DPKI en ontvangt een digitale portemonnee. Het portemonnee-adres is de hashwaarde van de openbare sleutel van de portemonnee. De privésleutel van de portemonnee is alleen bekend bij de aanvrager.
- De geregistreerde persoon krijgt toegang tot de geheime dienstsleutel.
- De proefpersoon genereert een nultransactie en verifieert deze met een digitale handtekening met behulp van de geheime sleutel van de portemonnee.
- Als er een andere transactie dan nul wordt uitgevoerd, wordt deze gecertificeerd door een elektronische digitale handtekening met behulp van twee geheime sleutels: een portemonnee en een servicesleutel.
- De proefpersoon dient een transactie in bij de pool.
- Het ENCRY-netwerkknooppunt leest de transactie uit de pool en controleert de digitale handtekening, evenals de connectiviteit van de transactie.
- Als de digitale handtekening geldig is en de verbinding is bevestigd, wordt de transactie voorbereid voor opname in het register.
Hier fungeert het register als een gedistribueerde database waarin informatie wordt opgeslagen over geldige, geannuleerde en opgeschorte meldingen.
Natuurlijk is decentralisatie geen wondermiddel. Het fundamentele probleem van primaire gebruikersauthenticatie verdwijnt nergens: als de verificatie van de aanvrager momenteel wordt uitgevoerd door de CR, dan wordt in DPKI voorgesteld om de verificatie te delegeren aan leden van de gemeenschap, en financiële motivatie te gebruiken om activiteit te stimuleren. Open source-verificatietechnologie is algemeen bekend. De effectiviteit van een dergelijke verificatie is in de praktijk bevestigd. Laten we nogmaals een aantal spraakmakende onderzoeken van de online publicatie Bellingcat in herinnering brengen.
Maar over het algemeen komt het volgende beeld naar voren: DPKI is een kans om, zo niet alle, veel van de tekortkomingen van gecentraliseerde PKI te corrigeren.
Abonneer u op onze Habrablog, we zijn van plan ons onderzoek en ontwikkeling actief te blijven volgen en te volgen , als je geen ander nieuws over ENCRY-projecten wilt missen.
Bron: www.habr.com