Ei ole mikään salaisuus, että yksi yleisesti käytetyistä apuvälineistä, jota ilman tietosuoja avoimissa verkoissa on mahdotonta, on digitaalinen varmennetekniikka. Ei ole kuitenkaan mikään salaisuus, että tekniikan suurin haittapuoli on ehdoton luottamus digitaalisia varmenteita myöntäviin keskuksiin. ENCRY:n teknologia- ja innovaatiojohtaja Andrey Chmora ehdotti uutta lähestymistapaa järjestämiseen julkisen avaimen infrastruktuuri (Julkinen avaininfrastruktuuri, PKI), joka auttaa poistamaan nykyiset puutteet ja joka käyttää hajautettua pääkirja- (blockchain) -tekniikkaa. Mutta ensin asiat ensin.
Jos tunnet nykyisen julkisen avaimen infrastruktuurisi ja tiedät sen tärkeimmät puutteet, voit siirtyä eteenpäin ehdottamaansa muutosta alla.
Mitä ovat digitaaliset allekirjoitukset ja varmenteet?Vuorovaikutus Internetissä sisältää aina tiedonsiirron. Olemme kaikki kiinnostuneita varmistamaan, että tiedot siirretään turvallisesti. Mutta mitä on turvallisuus? Halutuimpia turvallisuuspalveluita ovat luottamuksellisuus, eheys ja aitous. Tähän tarkoitukseen käytetään tällä hetkellä epäsymmetrisen salauksen menetelmiä tai salausta julkisella avaimella.
Aloitetaan siitä, että näiden menetelmien käyttämiseksi vuorovaikutuksen kohteilla on oltava kaksi yksittäistä parillista avainta - julkinen ja salainen. Heidän avullaan tarjotaan yllä mainitsemamme turvallisuuspalvelut.
Miten tiedonsiirron luottamuksellisuus saavutetaan? Ennen tiedon lähettämistä lähettävä tilaaja salaa (salakirjoituksella) avoimen tiedon vastaanottajan julkisella avaimella ja vastaanottaja purkaa vastaanotetun salatekstin pariksi liitetyn salaisen avaimen avulla.
Miten välitetyn tiedon eheys ja aitous saavutetaan? Tämän ongelman ratkaisemiseksi luotiin toinen mekanismi. Avointa dataa ei salata, vaan kryptografisen hajautusfunktion soveltamisen tulos - "pakattu" kuva syötetietosekvenssistä - välitetään salatussa muodossa. Tällaisen tiivistyksen tulosta kutsutaan "tiivisteeksi", ja se salataan lähettävän tilaajan ("todistajan") salaisella avaimella. Tiivistelmän salauksen tuloksena saadaan digitaalinen allekirjoitus. Se yhdessä selkeän tekstin kanssa välitetään vastaanottavalle tilaajalle ("todentaja"). Hän purkaa todistajan julkisella avaimella olevan digitaalisen allekirjoituksen ja vertaa sitä kryptografisen hajautusfunktion tulokseen, jonka todentaja laskee itsenäisesti vastaanotetun avoimen tiedon perusteella. Jos ne täsmäävät, tämä tarkoittaa, että lähettävä tilaaja on välittänyt tiedot aidossa ja täydellisessä muodossa, eikä hyökkääjä ole niitä muuttanut.
Useimmat henkilö- ja maksutietojen kanssa toimivat resurssit (pankit, vakuutusyhtiöt, lentoyhtiöt, maksujärjestelmät sekä valtion portaalit, kuten veropalvelu) käyttävät aktiivisesti epäsymmetrisiä salausmenetelmiä.
Mitä tekemistä digitaalisella sertifikaatilla on sen kanssa? Se on yksinkertaista. Sekä ensimmäisessä että toisessa prosessissa käytetään julkisia avaimia, ja koska niillä on keskeinen rooli, on erittäin tärkeää varmistaa, että avaimet todella kuuluvat lähettäjälle (allekirjoituksen vahvistamisen tapauksessa todistajalle) tai vastaanottajalle, eivätkä ne ole korvataan hyökkääjien avaimilla. Tästä syystä on olemassa digitaalisia varmenteita, jotka varmistavat julkisen avaimen aitouden ja eheyden.
Huomautus: julkisen avaimen aitous ja eheys varmistetaan täsmälleen samalla tavalla kuin julkisen tiedon aitous ja eheys, eli käyttämällä sähköistä digitaalista allekirjoitusta (EDS).
Mistä digitaaliset varmenteet tulevat?Luotetut varmentajat tai varmenneviranomaiset (CA:t) ovat vastuussa digitaalisten varmenteiden myöntämisestä ja ylläpidosta. Hakija pyytää varmentajan myöntämistä varmentajalta, käy läpi rekisteröintikeskuksen (CR) tunnistautumisen ja saa varmentajan varmenteen. Varmentaja takaa, että varmenteen julkinen avain kuuluu juuri sille taholle, jolle se on myönnetty.
Jos et vahvista julkisen avaimen aitoutta, hyökkääjä voi tämän avaimen siirron/tallennuksen aikana korvata sen omalla avaimellaan. Jos korvaaminen on tapahtunut, hyökkääjä voi purkaa kaiken, mitä lähettävä tilaaja lähettää vastaanottavalle tilaajalle, tai muuttaa avoimia tietoja oman harkintansa mukaan.
Digitaalisia varmenteita käytetään aina, kun epäsymmetrinen salaus on saatavilla. Yksi yleisimmistä digitaalisista varmenteista on SSL-sertifikaatit suojattua viestintää varten HTTPS-protokollan kautta. Sadat eri lainkäyttöalueilla rekisteröidyt yritykset ovat mukana SSL-varmenteiden myöntämisessä. Pääosuus kuuluu viidestä kymmeneen suurelle luotettavalle keskukselle: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA ja CR ovat PKI:n osia, joka sisältää myös:
- Avaa hakemisto – julkinen tietokanta, joka tarjoaa digitaalisten sertifikaattien turvallisen tallennuksen.
- Varmenteen peruutusluettelo – julkinen tietokanta, joka tarjoaa suojatun tallennuksen peruutettujen julkisten avainten digitaalisille sertifikaateille (esimerkiksi pariksi liitetyn yksityisen avaimen vaarantumisen vuoksi). Infrastruktuurin tutkijat voivat käyttää tätä tietokantaa itsenäisesti tai he voivat käyttää erikoistunutta Online Certification Status Protocol (OCSP) -protokollaa, joka yksinkertaistaa varmennusprosessia.
- Varmenteen käyttäjät – varmentajan kanssa käyttösopimuksen tehneitä palvelevia PKI-kohteita, jotka varmistavat digitaalisen allekirjoituksen ja/tai salaavat tiedot varmenteen julkisen avaimen perusteella.
- seuraajaa – palveli PKI-kohteita, jotka omistavat salaisen avaimen, joka on yhdistetty varmenteen julkiseen avaimeen ja jotka ovat tehneet tilaajasopimuksen Varmentajan kanssa. Tilaaja voi olla samanaikaisesti varmenteen käyttäjä.
Näin ollen julkisen avaimen infrastruktuurin luotetut yksiköt, joihin kuuluvat CA:t, CR:t ja avoimet hakemistot, ovat vastuussa:
1. Hakijan henkilöllisyyden aitouden varmistaminen.
2. Julkisen avaimen varmenteen profilointi.
3. Julkisen avaimen varmenteen myöntäminen hakijalle, jonka henkilöllisyys on varmistettu luotettavasti.
4. Muuta julkisen avaimen varmenteen tilaa.
5. Tietojen antaminen julkisen avaimen varmenteen nykyisestä tilasta.
PKI:n haitat, mitä ne ovat?PKI:n perusvika on luotettujen entiteettien läsnäolo.
Käyttäjien on luotettava ehdoitta varmentajaan ja CR:ään. Mutta kuten käytäntö osoittaa, ehdoton luottamus on täynnä vakavia seurauksia.
Viimeisten kymmenen vuoden aikana tällä alueella on ollut useita suuria infrastruktuurin haavoittuvuuteen liittyviä skandaaleja.
— vuonna 2010 Stuxnet-haittaohjelma alkoi levitä verkossa, ja se allekirjoitettiin RealTekin ja JMicronin varastetuilla digitaalisilla varmenteilla.
- Vuonna 2017 Google syytti Symantecia suuren määrän väärennettyjä varmenteita myöntämisestä. Symantec oli tuolloin yksi suurimmista varmentajista tuotantomäärillä mitattuna. Google Chrome 70 -selaimessa tämän yrityksen ja sen tytäryhtiöiden GeoTrustin ja Thawten myöntämien sertifikaattien tuki lopetettiin ennen 1. joulukuuta 2017.
Varmentajat vaarantuivat, ja sen seurauksena kaikki kärsivät – varmentajat itse, samoin kuin käyttäjät ja tilaajat. Luottamus infrastruktuuriin on heikentynyt. Lisäksi digitaaliset varmenteet voivat jäädä poliittisten konfliktien yhteydessä, mikä vaikuttaa myös monien resurssien toimintaan. Juuri tätä pelättiin useita vuosia sitten Venäjän presidentin hallinnossa, jossa vuonna 2016 keskusteltiin mahdollisuudesta perustaa valtion varmennekeskus, joka myöntäisi SSL-varmenteita RuNetin sivustoille. Nykyinen tilanne on sellainen, että jopa valtion portaalit Venäjällä amerikkalaisten Comodon tai Thawten (Symantecin tytäryhtiö) myöntämät digitaaliset sertifikaatit.
On toinenkin ongelma - kysymys käyttäjien ensisijainen todennus (todennus).. Kuinka tunnistaa käyttäjä, joka on ottanut yhteyttä varmentajaan ja pyytää digitaalisen varmenteen myöntämistä ilman suoraa henkilökohtaista yhteyttä? Nyt tämä ratkaistaan tilannekohtaisesti infrastruktuurin ominaisuuksien mukaan. Jotain otetaan avoimista rekistereistä (esimerkiksi tiedot varmenteita pyytävistä oikeushenkilöistä); tapauksissa, joissa hakijat ovat yksityishenkilöitä, voidaan käyttää pankkikonttoreita tai postitoimistoja, joissa heidän henkilöllisyytensä varmistetaan henkilöllisyysasiakirjoilla, esimerkiksi passilla.
Valtuustietojen väärentäminen toisena henkilönä esiintymistä varten on perustavanlaatuinen ongelma. Huomattakoon, että tähän ongelmaan ei ole täydellistä ratkaisua informaatioteoreettisista syistä: ilman luotettavaa tietoa etukäteen on mahdotonta vahvistaa tai kiistää tietyn kohteen aitoutta. Pääsääntöisesti todentamista varten on esitettävä joukko asiakirjoja, jotka todistavat hakijan henkilöllisyyden. Varmistusmenetelmiä on monia, mutta mikään niistä ei takaa täyttä takuuta asiakirjojen aitoudesta. Näin ollen myös hakijan henkilöllisyyden aitoutta ei voida taata.
Miten nämä puutteet voidaan poistaa?Jos PKI:n nykytilan ongelmat ovat selitettävissä keskittämisellä, niin on loogista olettaa, että hajauttaminen auttaisi osittain poistamaan havaitut puutteet.
Hajauttaminen ei tarkoita luotettujen entiteettien läsnäoloa - jos luot hajautettu julkisen avaimen infrastruktuuri (Hajautettu julkisen avaimen infrastruktuuri, DPKI), silloin CA:ta tai CR:tä ei tarvita. Hylätään digitaalisen varmenteen käsite ja käytetään hajautettua rekisteriä julkisten avainten tietojen tallentamiseen. Rekisteriksi kutsumme tapauksessamme lineaarista tietokantaa, joka koostuu yksittäisistä tietueista (lohkoista), jotka on linkitetty lohkoketjuteknologialla. Digitaalisen varmenteen sijaan otamme käyttöön "ilmoituksen" käsitteen.
Miltä ilmoitusten vastaanotto-, vahvistus- ja peruutusprosessi näyttää ehdotetussa DPKI:ssä:
1. Kukin hakija jättää ilmoitushakemuksen itsenäisesti täyttämällä rekisteröinnin yhteydessä lomakkeen, jonka jälkeen hän luo tapahtuman, joka tallennetaan erityiseen pooliin.
2. Tiedot julkisesta avaimesta sekä omistajan tiedot ja muut metatiedot tallennetaan hajautettuun rekisteriin, ei digitaaliseen varmenteeseen, jonka myöntämisestä keskitetyssä PKI:ssä Varmentaja vastaa.
3. Hakijan henkilöllisyyden aitouden varmennus suoritetaan jälkikäteen DPKI:n käyttäjäyhteisön yhteisin ponnisteluin, ei CR:n toimesta.
4. Vain tällaisen ilmoituksen omistaja voi muuttaa julkisen avaimen tilaa.
5. Kuka tahansa voi käyttää hajautettua pääkirjaa ja tarkistaa julkisen avaimen nykyisen tilan.
Huomautus: Yhteisön suorittama hakijan henkilöllisyyden todentaminen saattaa vaikuttaa ensi silmäyksellä epäluotettavalta. Mutta on muistettava, että nykyään kaikki digitaalisten palvelujen käyttäjät jättävät väistämättä digitaalisen jalanjäljen, ja tämä prosessi vain kiihtyy. Avoimet sähköiset oikeushenkilörekisterit, kartat, maastokuvien digitointi, sosiaaliset verkostot - kaikki nämä ovat julkisesti saatavilla olevia työkaluja. Sekä toimittajat että lainvalvontaviranomaiset käyttävät niitä jo menestyksekkäästi tutkinnassa. Esimerkiksi Bellingcatin tai malesialaisen Boeingin turman olosuhteita tutkivan yhteisen tutkintaryhmän JIT:n tutkimukset riittää.
Joten miten hajautettu julkisen avaimen infrastruktuuri toimisi käytännössä? Pysähdytään itse tekniikan kuvaukseen, jonka me patentoitu vuonna 2018 ja pidämme sitä oikeutetusti tietoomme.
Kuvittele, että joku omistaja omistaa useita julkisia avaimia, joissa jokainen avain on tietty tapahtuma, joka on tallennettu rekisteriin. Kuinka voit ymmärtää varmentajan puuttuessa, että kaikki avaimet kuuluvat tälle tietylle omistajalle? Tämän ongelman ratkaisemiseksi luodaan nollatapahtuma, joka sisältää tiedot omistajasta ja hänen lompakosta (josta veloitetaan palkkio tapahtuman sijoittamisesta rekisteriin). Nollatapahtuma on eräänlainen "ankkuri", johon seuraavat julkisia avaimia koskevat tiedot liitetään. Jokainen tällainen tapahtuma sisältää erikoistuneen tietorakenteen eli toisin sanoen ilmoituksen.
Ilmoitus on jäsennelty tietojoukko, joka koostuu toiminnallisista kentistä ja sisältää tietoja omistajan julkisesta avaimesta ja jonka säilyvyys taataan sijoittamalla johonkin hajautetun rekisterin siihen liittyvistä tietueista.
Seuraava looginen kysymys on, kuinka nollatapahtuma muodostetaan? Nollatapahtuma – kuten myöhemmät tapahtumat – on kuuden tietokentän yhdistelmä. Nollatapahtuman muodostamisessa on mukana lompakon avainpari (julkiset ja parilliset salaiset avaimet). Tämä avainpari ilmestyy sillä hetkellä, kun käyttäjä rekisteröi lompakkonsa, josta veloitetaan palkkio nollatapahtuman sijoittamisesta rekisteriin ja sen jälkeen ilmoitustoiminnoista.
Kuten kuvasta näkyy, lompakon julkisen avaimen tiivistelmä luodaan käyttämällä peräkkäin SHA256- ja RIPEMD160-hajautusfunktioita. Tässä RIPEMD160 vastaa tiedon kompaktista esityksestä, jonka leveys ei ylitä 160 bittiä. Tämä on tärkeää, koska rekisteri ei ole halpa tietokanta. Itse julkinen avain syötetään viidenteen kenttään. Ensimmäinen kenttä sisältää tiedot, jotka muodostavat yhteyden edelliseen tapahtumaan. Jos tapahtuma on nolla, tämä kenttä ei sisällä mitään, mikä erottaa sen myöhemmistä tapahtumista. Toinen kenttä on tiedot tapahtumien liitettävyyden tarkistamiseksi. Lyhytyyden vuoksi kutsumme ensimmäisessä ja toisessa kentässä olevia tietoja "linkki" ja "tarkista". Näiden kenttien sisältö luodaan iteratiivisella hajautustekniikalla, kuten alla olevan kuvan toisen ja kolmannen tapahtuman linkittäminen osoittaa.
Viiden ensimmäisen kentän tiedot on varmennettu sähköisellä allekirjoituksella, joka luodaan lompakon salaisella avaimella.
Siinä kaikki, nollatapahtuma lähetetään pooliin ja onnistuneen tarkistuksen jälkeen kirjataan rekisteriin. Nyt voit "linkittää" siihen seuraavat tapahtumat. Tarkastellaan, kuinka muut kuin nollatapahtumat muodostuvat.
Ensimmäinen asia, joka todennäköisesti kiinnitti huomiotasi, on avainparien runsaus. Jo tutun lompakon avainparin lisäksi käytetään tavallisia ja palveluavainpareja.
Tavallinen julkinen avain on se, mitä varten kaikki aloitettiin. Tämä avain on mukana erilaisissa ulkomaailmassa tapahtuvissa prosesseissa (pankki- ja muut tapahtumat, asiakirjavirta jne.). Esimerkiksi tavallisen parin salaisella avaimella voidaan luoda digitaalisia allekirjoituksia erilaisille asiakirjoille - maksumääräyksille jne., ja julkista avainta voidaan käyttää tämän digitaalisen allekirjoituksen vahvistamiseen näiden ohjeiden myöhemmän suorittamisen yhteydessä, jos se on voimassa.
Palvelupari myönnetään rekisteröidylle DPKI-kohteelle. Tämän parin nimi vastaa sen tarkoitusta. Huomaa, että nollatapahtumaa muodostettaessa/tarkistaessa palveluavaimia ei käytetä.
Selvennetään vielä kerran näppäinten tarkoitusta:
- Lompakkoavaimia käytetään sekä tyhjän tapahtuman että muiden ei-nollatapahtumien luomiseen/tarkistamiseen. Lompakon yksityinen avain on vain lompakon omistajan tiedossa, joka on myös useiden tavallisten julkisten avainten omistaja.
- Tavallinen julkinen avain on tarkoitukseltaan samanlainen kuin julkinen avain, jolle myönnetään varmenne keskitetyssä PKI:ssä.
- Palveluavainpari kuuluu DPKI:lle. Salainen avain myönnetään rekisteröidyille yksiköille, ja sitä käytetään digitaalisten allekirjoitusten luomiseen tapahtumille (paitsi nollatapahtumille). Julkista käytetään tapahtuman sähköisen digitaalisen allekirjoituksen tarkistamiseen ennen sen sijoittamista rekisteriin.
Näin ollen avaimia on kaksi ryhmää. Ensimmäinen sisältää palveluavaimet ja lompakkoavaimet – niillä on järkeä vain DPKI:n yhteydessä. Toinen ryhmä sisältää tavalliset avaimet - niiden laajuus voi vaihdella ja määräytyy sovellustehtävien mukaan, joissa niitä käytetään. Samalla DPKI varmistaa tavallisten julkisten avainten eheyden ja aitouden.
Huomautus: Palveluavainpari voivat olla eri DPKI-yksiköiden tiedossa. Se voi esimerkiksi olla sama kaikille. Tästä syystä jokaisen ei-nollatapahtuman allekirjoituksen luomisessa käytetään kahta salaista avainta, joista toinen on lompakon avain - sen tietää vain lompakon omistaja, joka on myös monien tavallisten julkisia avaimia. Kaikilla avaimilla on oma merkityksensä. On esimerkiksi aina mahdollista todistaa, että tapahtuma on rekisteröity DPKI-subjektit syöttänyt rekisteriin, koska allekirjoitus on luotu myös salaisen palvelun avaimelle. Eikä voi olla väärinkäyttöä, kuten DOS-hyökkäyksiä, koska omistaja maksaa jokaisesta tapahtumasta.
Kaikki nollaykköstä seuraavat tapahtumat muodostetaan samalla tavalla: julkinen avain (ei lompakko, kuten nollatapahtuman tapauksessa, vaan tavallisesta avainparista) ajetaan kahden hash-funktion SHA256 ja RIPEMD160 kautta. Näin muodostuu kolmannen kentän tiedot. Neljäs kenttä sisältää liitetiedot (esimerkiksi tiedot nykyisestä tilasta, vanhenemispäivämääristä, aikaleimasta, käytettyjen krypto-algoritmien tunnisteet jne.). Viides kenttä sisältää julkisen avaimen palveluavainparista. Sen avulla digitaalinen allekirjoitus tarkistetaan, joten se kopioidaan. Perustelkaamme tällaisen lähestymistavan tarve.
Muista, että tapahtuma kirjataan pooliin ja tallennetaan sinne, kunnes se käsitellään. Varastointiin poolissa liittyy tietty riski - tapahtumatietoja voidaan väärentää. Omistaja varmentaa tapahtumatiedot sähköisellä digitaalisella allekirjoituksella. Julkinen avain tämän digitaalisen allekirjoituksen varmentamiseen on merkitty nimenomaisesti yhteen tapahtumakentistä, ja se syötetään myöhemmin rekisteriin. Tapahtuman käsittelyn erityispiirteet ovat sellaisia, että hyökkääjä voi muuttaa tietoja oman harkintansa mukaan ja sitten tarkistaa ne salaisella avaimellaan ja ilmoittaa parillisen julkisen avaimen digitaalisen allekirjoituksen tarkistamiseksi tapahtumassa. Jos aitous ja eheys varmistetaan yksinomaan digitaalisella allekirjoituksella, tällainen väärennös jää huomaamatta. Kuitenkin, jos digitaalisen allekirjoituksen lisäksi on lisämekanismi, joka varmistaa sekä arkistoinnin että tallennettujen tietojen pysyvyyden, niin väärennös voidaan havaita. Tätä varten riittää, että syötät rekisteriin omistajan aidon julkisen avaimen. Selitetään, miten tämä toimii.
Anna hyökkääjän väärentää tapahtumatietoja. Avainten ja digitaalisten allekirjoitusten kannalta seuraavat vaihtoehdot ovat mahdollisia:
1. Hyökkääjä sijoittaa julkisen avaimensa tapahtumaan omistajan digitaalisen allekirjoituksen pysyessä muuttumattomana.
2. Hyökkääjä luo digitaalisen allekirjoituksen yksityiselle avaimelleen, mutta jättää omistajan julkisen avaimen ennalleen.
3. Hyökkääjä luo digitaalisen allekirjoituksen yksityiselle avaimelleen ja sijoittaa tapahtumaan parin julkisen avaimen.
Ilmeisesti vaihtoehdot 1 ja 2 ovat merkityksettömiä, koska ne tunnistetaan aina digitaalisen allekirjoituksen tarkistuksen aikana. Vain vaihtoehto 3 on järkevä, ja jos hyökkääjä muodostaa digitaalisen allekirjoituksen omalle salaiselle avaimelleen, hänen on tallennettava tapahtumaan parillinen julkinen avain, joka eroaa omistajan julkisesta avaimesta. Tämä on ainoa tapa, jolla hyökkääjä voi määrätä väärennettyjä tietoja.
Oletetaan, että omistajalla on kiinteä avainpari - yksityinen ja julkinen. Varmennetaan tiedot digitaalisella allekirjoituksella tämän parin salaisella avaimella ja julkinen avain ilmoitetaan tapahtumassa. Oletetaan myös, että tämä julkinen avain on aiemmin syötetty rekisteriin ja sen aitous on varmistettu luotettavasti. Tällöin väärennöksestä ilmaistaan se, että tapahtuman julkinen avain ei vastaa rekisterin julkista avainta.
Yhteenveto. Omistajan ensimmäisiä tapahtumatietoja käsiteltäessä on tarpeen varmistaa rekisteriin syötetyn julkisen avaimen aitous. Voit tehdä tämän lukemalla avain rekisteristä ja vertaamalla sitä omistajan todelliseen julkiseen avaimeen suojausalueella (suhteellisen haavoittuvuuden alueella). Jos avaimen aitous varmistetaan ja sen pysyvyys taataan sijoittamisen yhteydessä, avaimen aitous myöhemmästä tapahtumasta voidaan helposti vahvistaa/kiistää vertaamalla sitä rekisterin avaimeen. Toisin sanoen rekisterin avainta käytetään vertailunäytteenä. Kaikki muut omistajatapahtumat käsitellään samalla tavalla.
Tapahtuma varmennetaan sähköisellä digitaalisella allekirjoituksella - tässä tarvitaan salaisia avaimia, eikä yhtä, vaan kahta kerralla - palveluavain ja lompakkoavain. Kahden salaisen avaimen käytön ansiosta varmistetaan tarvittava turvallisuustaso - palvelun salainen avain voi loppujen lopuksi olla muiden käyttäjien tiedossa, kun taas lompakon salainen avain on vain tavallisen avainparin omistajan tiedossa. Kutsuimme tällaista kahden avaimen allekirjoitusta "konsolidoiduksi" digitaaliseksi allekirjoitukseksi.
Ei-nollatapahtumien varmennus suoritetaan kahdella julkisella avaimella: lompakolla ja palveluavaimella. Varmennusprosessi voidaan jakaa kahteen päävaiheeseen: ensimmäinen on lompakon julkisen avaimen tiivistelmän tarkistaminen ja toinen tapahtuman sähköisen digitaalisen allekirjoituksen tarkistaminen, sama konsolidoitu, joka muodostettiin käyttämällä kahta salaista avainta ( lompakko ja palvelu). Jos digitaalisen allekirjoituksen pätevyys varmistetaan, tapahtuma kirjataan rekisteriin lisätarkastuksen jälkeen.
Voi syntyä looginen kysymys: kuinka tarkistaa, kuuluuko tapahtuma tiettyyn ketjuun, jonka "juuri" on nollatapahtuman muodossa? Tätä tarkoitusta varten varmennusprosessia täydennetään vielä yhdellä vaiheella - yhteystarkastuksella. Tähän tarvitsemme tiedot kahdesta ensimmäisestä kentästä, jotka olemme toistaiseksi jättäneet huomiotta.
Oletetaan, että meidän on tarkistettava, tuleeko tapahtuma 3 todella tapahtuman 2 jälkeen. Tätä varten yhdistetyn hajautusmenetelmän avulla tiivistefunktion arvo lasketaan tapahtuman nro 2 kolmannen, neljännen ja viidennen kentän tiedoille. Sitten suoritetaan datan ketjutus tapahtuman nro 3 ensimmäisestä kentästä ja aiemmin saatu yhdistetty hash-funktion arvo tapahtuman nro 2 kolmannen, neljännen ja viidennen kentän datalle. Kaikki tämä suoritetaan myös kahden hash-funktion SHA256 ja RIPEMD160 kautta. Jos vastaanotettu arvo vastaa tapahtuman nro 2 toisen kentän tietoja, tarkistus läpäistään ja yhteys vahvistetaan. Tämä näkyy selvemmin alla olevissa kuvissa.
Yleisesti ottaen teknologia ilmoituksen luomiseksi ja syöttämiseksi rekisteriin näyttää täsmälleen tältä. Visuaalinen esitys ilmoitusketjun muodostusprosessista on esitetty seuraavassa kuvassa:
Tässä tekstissä emme viivyttele yksityiskohdissa, jotka epäilemättä ovat olemassa, vaan palaamme keskustelemaan hajautetun julkisen avaimen infrastruktuurin ideasta.
Joten koska hakija itse jättää hakemuksen ilmoitusten rekisteröimiseksi, joita ei ole tallennettu CA-tietokantaan, vaan rekisteriin, DPKI:n tärkeimmät arkkitehtoniset komponentit on otettava huomioon:
1. Voimassa olevien ilmoitusten rekisteri (RDN).
2. Peruttujen ilmoitusten rekisteri (RON).
3. Keskeytettyjen ilmoitusten rekisteri (RPN).
Tiedot julkisista avaimista tallennetaan RDN/RON/RPN:ään hash-funktioarvojen muodossa. On myös syytä huomioida, että nämä voivat olla joko erilaisia rekistereitä tai eri ketjuja tai jopa yhtä ketjua osana yhtä rekisteriä, kun tavallisen julkisen avaimen tilasta (peruuttaminen, keskeyttäminen jne.) syötetään tietoa. tietorakenteen neljäs kenttä vastaavan koodiarvon muodossa. DPKI:n arkkitehtoniseen toteutukseen on olemassa monia erilaisia vaihtoehtoja, ja jommankumman valinta riippuu useista tekijöistä, esimerkiksi sellaisista optimointikriteereistä kuin julkisten avainten tallentamiseen käytettävän pitkäaikaisen muistin kustannukset jne.
Siten DPKI voi osoittautua ellei yksinkertaisemmiksi, niin arkkitehtonisesti monimutkaisuudeltaan ainakin verrattavissa keskitettyyn ratkaisuun.
Pääkysymys jää - Mikä rekisteri soveltuu tekniikan toteuttamiseen?
Rekisterin päävaatimus on kyky luoda kaikentyyppisiä tapahtumia. Tunnetuin esimerkki reskontrasta on Bitcoin-verkko. Mutta yllä kuvattua tekniikkaa toteutettaessa syntyy tiettyjä vaikeuksia: olemassa olevan komentosarjakielen rajoitukset, tarvittavien mekanismien puute mielivaltaisten tietojoukkojen käsittelemiseksi, menetelmät mielivaltaisen tyyppisten tapahtumien luomiseksi ja paljon muuta.
Me ENCRY:llä yritimme ratkaista yllä muotoiltuja ongelmia ja kehitimme rekisterin, jolla on mielestämme useita etuja, nimittäin:
- tukee usean tyyppisiä transaktioita: se voi sekä vaihtaa omaisuutta (eli suorittaa rahoitustapahtumia) että luoda liiketoimia, joilla on mielivaltainen rakenne,
- kehittäjillä on pääsy omaan ohjelmointikieleen PrismLang, joka tarjoaa tarvittavan joustavuuden erilaisten teknisten ongelmien ratkaisemisessa,
- tarjotaan mekanismi mielivaltaisten tietojoukkojen käsittelemiseksi.
Jos otamme yksinkertaistetun lähestymistavan, tapahtuu seuraava toimintosarja:
- Hakija rekisteröityy DPKI:hen ja saa digitaalisen lompakon. Lompakon osoite on lompakon julkisen avaimen hash-arvo. Lompakon yksityinen avain on vain hakijan tiedossa.
- Rekisteröidylle henkilölle annetaan pääsy palvelun salaiseen avaimeen.
- Kohde luo nollatapahtuman ja vahvistaa sen digitaalisella allekirjoituksella lompakon salaisella avaimella.
- Jos muodostuu muu kuin nollatapahtuma, se varmennetaan sähköisellä digitaalisella allekirjoituksella kahdella salaisella avaimella: lompakko- ja palveluavaimella.
- Kohde lähettää tapahtuman poolille.
- ENCRY-verkkosolmu lukee tapahtuman poolista ja tarkistaa digitaalisen allekirjoituksen sekä tapahtuman liitettävyyden.
- Jos digitaalinen allekirjoitus on voimassa ja yhteys on vahvistettu, se valmistelee tapahtuman rekisteröintiä varten.
Tässä rekisteri toimii hajautettuna tietokantana, joka tallentaa tietoja voimassa olevista, peruutetuista ja keskeytetyistä ilmoituksista.
Tietenkin hajauttaminen ei ole ihmelääke. Ensisijaisen käyttäjän autentikoinnin perusongelma ei katoa mihinkään: jos tällä hetkellä hakijan varmentamisesta vastaa CR, niin DPKI:ssä ehdotetaan, että varmennus delegoidaan yhteisön jäsenille ja toiminnan kannustamiseen käytetään taloudellista motivaatiota. Avoimen lähdekoodin varmennustekniikka tunnetaan hyvin. Tällaisen tarkastuksen tehokkuus on vahvistettu käytännössä. Muistakaamme jälleen useita Bellingcat-verkkojulkaisun korkean profiilin tutkimuksia.
Mutta yleisesti ottaen syntyy seuraava kuva: DPKI on mahdollisuus korjata, jos ei kaikki, niin monet keskitetyn PKI:n puutteet.
Tilaa Habrablogimme, aiomme jatkossakin kattaa aktiivisesti tutkimus- ja kehitystyömme ja seurata , jos et halua missata muita uutisia ENCRY-projekteista.
Lähde: will.com