Nem titok, hogy az egyik leggyakrabban használt segédeszköz, amely nélkül lehetetlen az adatvédelem nyílt hálózatokban, a digitális tanúsítvány technológia. Nem titok azonban, hogy a technológia fő hátránya a digitális tanúsítványokat kibocsátó központokba vetett feltétlen bizalom. Andrey Chmora, az ENCRY technológiai és innovációs igazgatója új megközelítést javasolt a szervezésben nyilvános kulcsú infrastruktúra (Nyilvános kulcsú infrastruktúra, PKI), amely segít kiküszöbölni a jelenlegi hiányosságokat, és amely elosztott főkönyvi (blokklánc) technológiát használ. De először a dolgok.
Ha ismeri jelenlegi nyilvános kulcsú infrastruktúrájának működését, és ismeri annak fő hiányosságait, az alábbiakban átugorhatja az általunk javasolt változtatásokat.
Mik azok a digitális aláírások és tanúsítványok?Az internetes interakció mindig adattovábbítással jár. Mindannyiunk érdeke az adatok biztonságos továbbítása. De mi a biztonság? A legkeresettebb biztonsági szolgáltatások a titoktartás, az integritás és a hitelesség. Erre a célra jelenleg az aszimmetrikus vagy nyilvános kulccsal történő kriptográfiai módszereket alkalmazzák.
Kezdjük azzal a ténnyel, hogy ezeknek a módszereknek a használatához az interakció alanyainak két egyedi, párosított kulccsal kell rendelkezniük - nyilvános és titkos. Segítségükkel biztosítjuk az általunk fentebb említett biztonsági szolgáltatásokat.
Hogyan valósul meg az információátadás titkossága? Az adatküldés előtt a küldő előfizető a nyitott adatokat a fogadó nyilvános kulcsával titkosítja (kriptográfiailag átalakítja), a fogadó pedig a párosított titkos kulcs segítségével visszafejti a kapott rejtjelezett szöveget.
Hogyan érhető el a továbbított információ sértetlensége és hitelessége? A probléma megoldására egy másik mechanizmust hoztak létre. A nyílt adatokat nem titkosítják, de a kriptográfiai hash függvény alkalmazásának eredménye - a bemeneti adatsor „tömörített” képe - titkosított formában kerül továbbításra. Az ilyen kivonatolás eredményét „kivonatnak” nevezik, és a küldő előfizető („a tanú”) titkos kulcsával titkosítják. A kivonat titkosítása eredményeként digitális aláírást kapunk. Ezt a világos szöveggel együtt továbbítják a fogadó előfizetőnek ("ellenőrző"). Dekódolja a tanú nyilvános kulcsán lévő digitális aláírást, és összehasonlítja egy kriptográfiai hash függvény alkalmazásának eredményével, amelyet a hitelesítő önállóan számít ki a kapott nyílt adatok alapján. Ha megegyeznek, ez azt jelzi, hogy az adatokat a küldő előfizető hiteles és teljes formában továbbította, és nem a támadó módosította.
A legtöbb személyes adatokkal és fizetési információval dolgozó erőforrás (bankok, biztosítótársaságok, légitársaságok, fizetési rendszerek, valamint kormányzati portálok, például az adószolgálat) aktívan használ aszimmetrikus kriptográfiai módszereket.
Mi köze ehhez a digitális tanúsítványnak? Ez egyszerű. Mind az első, mind a második folyamatban nyilvános kulcsok szerepelnek, és mivel ezek központi szerepet töltenek be, nagyon fontos annak biztosítása, hogy a kulcsok valóban a feladóhoz (aláírás-ellenőrzés esetén a tanúhoz) vagy a címzetthez tartozzanak, és ne a támadók kulcsaira cserélték. Ezért léteznek digitális tanúsítványok, amelyek biztosítják a nyilvános kulcs hitelességét és integritását.
Megjegyzés: a nyilvános kulcs hitelességét és sértetlenségét pontosan ugyanúgy ellenőrizzük, mint a nyilvános adatok hitelességét és sértetlenségét, azaz elektronikus digitális aláírással (EDS).
Honnan származnak a digitális tanúsítványok?A digitális tanúsítványok kiadásáért és karbantartásáért a megbízható hitelesítésszolgáltatók vagy hitelesítésszolgáltatók (CA-k) felelősek. A kérelmező tanúsítvány kiállítását kéri a CA-tól, a Regisztrációs Központban (CR) azonosításon esik át, és tanúsítványt kap a CA-tól. A CA garantálja, hogy a tanúsítványból származó nyilvános kulcs pontosan ahhoz az entitáshoz tartozik, amelyhez azt kiállították.
Ha nem erősíti meg a nyilvános kulcs hitelességét, akkor a támadó a kulcs átvitele/tárolása során lecserélheti azt a sajátjára. Ha a helyettesítés megtörtént, a támadó képes lesz visszafejteni mindazt, amit a küldő előfizető továbbít a fogadó előfizetőnek, vagy saját belátása szerint módosíthatja a nyílt adatokat.
A digitális tanúsítványokat mindenhol használják, ahol elérhető aszimmetrikus kriptográfia. Az egyik legelterjedtebb digitális tanúsítvány a HTTPS protokollon keresztüli biztonságos kommunikációt szolgáló SSL-tanúsítványok. Az SSL-tanúsítványok kiadásában több száz különböző joghatóságban bejegyzett cég vesz részt. A fő részesedés öt-tíz nagy megbízhatósági központra esik: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
A CA és a CR a PKI összetevői, amely a következőket is tartalmazza:
- Nyissa meg a könyvtárat – nyilvános adatbázis, amely a digitális tanúsítványok biztonságos tárolását biztosítja.
- Tanúsítvány visszavonási lista – nyilvános adatbázis, amely a visszavont nyilvános kulcsok digitális tanúsítványainak biztonságos tárolását biztosítja (például egy párosított privát kulcs kompromittálódása miatt). Az infrastruktúra alanyai önállóan hozzáférhetnek ehhez az adatbázishoz, vagy használhatják a speciális Online Certification Status Protocol-t (OCSP), amely leegyszerűsíti az ellenőrzési folyamatot.
- Tanúsítvány felhasználók – kiszolgált PKI alanyok, akik felhasználói szerződést kötöttek a CA-val, és a tanúsítvány nyilvános kulcsa alapján ellenőrzik a digitális aláírást és/vagy titkosítják az adatokat.
- Követők – kiszolgálta azokat a PKI alanyokat, akik a tanúsítványból származó nyilvános kulccsal párosított titkos kulccsal rendelkeznek, és a CA-val előfizetői szerződést kötöttek. Az előfizető egyidejűleg a tanúsítvány felhasználója is lehet.
Így a nyilvános kulcsú infrastruktúra megbízható entitásai, amelyek magukban foglalják a CA-kat, a CR-eket és a nyílt könyvtárakat, felelősek a következőkért:
1. A kérelmező személyazonosságának ellenőrzése.
2. A nyilvános kulcsú tanúsítvány profilozása.
3. Nyilvános kulcsú tanúsítvány kiadása olyan kérelmező számára, akinek személyazonosságát megbízhatóan megerősítették.
4. Módosítsa a nyilvános kulcs tanúsítvány állapotát.
5. Információk megadása a nyilvános kulcsú tanúsítvány aktuális állapotáról.
A PKI hátrányai, mik ezek?A PKI alapvető hibája a megbízható entitások jelenléte.
A felhasználóknak feltétel nélkül bízniuk kell a CA-ban és a CR-ben. De amint azt a gyakorlat mutatja, a feltétel nélküli bizalom súlyos következményekkel jár.
Az elmúlt tíz évben több nagy botrány is történt ezen a területen az infrastruktúra sebezhetőségével kapcsolatban.
- 2010-ben a Stuxnet malware elkezdett terjedni az interneten, amelyet a RealTek és a JMicron ellopott digitális tanúsítványaival írtak alá.
- 2017-ben a Google azzal vádolta meg a Symantecet, hogy nagyszámú hamisított tanúsítványt adott ki. Abban az időben a Symantec volt az egyik legnagyobb hitelesítésszolgáltató a gyártási mennyiségeket tekintve. A Google Chrome 70 böngészőben 1. december 2017. előtt leállt az e cég, valamint a hozzá kapcsolódó GeoTrust és Thawte által kiadott tanúsítványok támogatása.
A hitelesítésszolgáltatók veszélybe kerültek, és ennek eredményeként mindenki szenvedett – maguk a CA-k, valamint a felhasználók és az előfizetők. Az infrastruktúrába vetett bizalom aláásott. Emellett politikai konfliktusok esetén a digitális tanúsítványok blokkolására is sor kerülhet, ami számos erőforrás működését is érinti. Pontosan ettől tartottak évekkel ezelőtt az orosz elnöki adminisztráció, ahol 2016-ban egy olyan állami hitelesítési központ létrehozásának lehetőségéről tárgyaltak, amely SSL-tanúsítványokat adna ki a RuNet webhelyeinek. A dolgok jelenlegi állása olyan, hogy Oroszországban még az állami portálok is a Comodo vagy a Thawte (a Symantec leányvállalata) amerikai cégek által kibocsátott digitális tanúsítványok.
Van egy másik probléma - a kérdés a felhasználók elsődleges hitelesítése (hitelesítés).. Hogyan lehet azonosítani azt a felhasználót, aki közvetlen személyes kapcsolat nélkül digitális tanúsítvány kiadására irányuló kéréssel fordult a CA-hoz? Most ez az infrastruktúra adottságaitól függően helyzetileg megoldott. Valamit a nyílt nyilvántartásokból vesznek át (például az igazolást kérő jogi személyekre vonatkozó információkat); magánszemélyek kérelmezőiben banki irodák vagy postahivatalok használhatók, ahol személyazonosságukat személyazonosító okmányokkal, például útlevéllel igazolják.
A személyi adatok visszaélés céljából történő meghamisításának problémája alapvető probléma. Vegyük észre, hogy erre a problémára információelméleti okok miatt nincs teljes megoldás: eleve megbízható információ nélkül lehetetlen egy adott téma hitelességét megerősíteni vagy cáfolni. Az ellenőrzéshez általában be kell mutatni a kérelmező személyazonosságát igazoló dokumentumokat. Számos különböző ellenőrzési módszer létezik, de egyik sem nyújt teljes körű garanciát a dokumentumok hitelességére. Ennek megfelelően a kérelmező személyazonosságának hitelessége sem garantálható.
Hogyan lehet ezeket a hiányosságokat kiküszöbölni?Ha a PKI jelenlegi állapotának problémái a centralizációval magyarázhatók, akkor logikus az a feltételezés, hogy a decentralizáció segíti a feltárt hiányosságok részbeni kiküszöbölését.
A decentralizáció nem jelenti a megbízható entitások jelenlétét – ha létrehoz decentralizált nyilvános kulcsú infrastruktúra (Decentralizált nyilvános kulcsú infrastruktúra, DPKI), akkor sem CA-ra, sem CR-re nincs szükség. Hagyjuk fel a digitális tanúsítvány fogalmát, és használjunk elosztott nyilvántartást a nyilvános kulcsokkal kapcsolatos információk tárolására. Esetünkben regiszternek nevezünk egy lineáris adatbázist, amely blokklánc technológiával összekapcsolt egyedi rekordokból (blokkokból) áll. A digitális tanúsítvány helyett bevezetjük az „értesítés” fogalmát.
Hogyan fog kinézni az értesítések fogadásának, ellenőrzésének és visszavonásának folyamata a javasolt DPKI-ben:
1. Minden pályázó önállóan nyújt be bejelentési kérelmet a regisztráció során egy űrlap kitöltésével, majd létrehoz egy tranzakciót, amelyet egy speciális tárhelyen tárol.
2. A nyilvános kulcsra vonatkozó információk, a tulajdonos adataival és egyéb metaadataival együtt egy elosztott nyilvántartásban tárolódnak, nem pedig digitális tanúsítványban, amelynek kibocsátásáért egy központi PKI-ben a CA felelős.
3. A kérelmező személyazonosságának hitelességének ellenőrzése utólag a DPKI felhasználói közösség, és nem a CR közös erőfeszítésével történik.
4. Csak az ilyen értesítés tulajdonosa módosíthatja a nyilvános kulcs állapotát.
5. Bárki hozzáférhet az elosztott főkönyvhöz, és ellenőrizheti a nyilvános kulcs aktuális állapotát.
Megjegyzés: A kérelmező személyazonosságának közösségi ellenőrzése első pillantásra megbízhatatlannak tűnhet. De nem szabad elfelejtenünk, hogy manapság a digitális szolgáltatások minden felhasználója óhatatlanul digitális lábnyomot hagy maga után, és ez a folyamat csak tovább fog lendülni. Nyílt elektronikus nyilvántartások a jogi személyekről, térképek, terepképek digitalizálása, közösségi hálózatok – mindezek nyilvánosan elérhető eszközök. Ezeket már sikeresen alkalmazzák a nyomozások során mind az újságírók, mind a rendvédelmi szervek. Elég például felidézni a Bellingcat vagy a malajziai Boeing lezuhanásának körülményeit tanulmányozó JIT közös nyomozócsoport vizsgálatait.
Tehát hogyan működne a gyakorlatban egy decentralizált nyilvános kulcsú infrastruktúra? Maradjunk inkább magának a technológiának a leírásánál, amelyet mi 2018-ban szabadalmaztatták és joggal tekintjük tudásunknak.
Képzelje el, hogy van egy tulajdonos, akinek sok nyilvános kulcsa van, ahol minden kulcs egy bizonyos tranzakció, amelyet a rendszerleíró adatbázisban tárolnak. CA hiányában hogyan lehet megérteni, hogy az összes kulcs ehhez a tulajdonoshoz tartozik? A probléma megoldására nulla tranzakció jön létre, amely információkat tartalmaz a tulajdonosról és a pénztárcájáról (amelyből a tranzakció nyilvántartásba vételének jutaléka kerül levonásra). A null tranzakció egyfajta „horgony”, amelyhez a következő, nyilvános kulcsokra vonatkozó adatokat tartalmazó tranzakciók csatolják. Minden ilyen tranzakció speciális adatstruktúrát, vagy más szóval értesítést tartalmaz.
Az értesítés funkcionális mezőkből álló, a tulajdonos nyilvános kulcsára vonatkozó információkat tartalmazó strukturált adathalmaz, amelynek fennmaradását az elosztott nyilvántartás valamelyik kapcsolódó rekordjában való elhelyezés garantálja.
A következő logikus kérdés az, hogy hogyan jön létre a nulla tranzakció? A null tranzakció – a későbbiekhez hasonlóan – hat adatmező összesítése. A nulla tranzakció kialakítása során a pénztárca kulcspárja vesz részt (nyilvános és páros titkos kulcsok). Ez a kulcspár abban a pillanatban jelenik meg, amikor a felhasználó regisztrálja pénztárcáját, amelyből levonják a nulla tranzakció nyilvántartásba vételének jutalékát, és ezt követően az értesítésekkel végzett műveleteket.
Amint az ábrán látható, a Wallet nyilvános kulcsának kivonatát az SHA256 és a RIPEMD160 hash függvények egymás utáni alkalmazásával állítják elő. Itt a RIPEMD160 felelős az adatok kompakt megjelenítéséért, amelyek szélessége nem haladja meg a 160 bitet. Ez azért fontos, mert a rendszerleíró adatbázis nem olcsó adatbázis. Maga a nyilvános kulcs az ötödik mezőbe kerül. Az első mező olyan adatokat tartalmaz, amelyek kapcsolatot létesítenek az előző tranzakcióval. Nulla tranzakció esetén ez a mező nem tartalmaz semmit, ami megkülönbözteti a későbbi tranzakcióktól. A második mező a tranzakciók összekapcsolhatóságának ellenőrzésére szolgáló adatok. A rövidség kedvéért az első és a második mezőben található adatokat „link”-nek, illetve „check”-nek nevezzük. Ezeknek a mezőknek a tartalma iteratív kivonatozással jön létre, amint azt az alábbi ábra második és harmadik tranzakciójának összekapcsolása szemlélteti.
Az első öt mező adatait elektronikus aláírás igazolja, amelyet a pénztárca titkos kulcsával generálnak.
Ez az, a null tranzakció elküldésre kerül a készletbe, és a sikeres ellenőrzés után bekerül a rendszerleíró adatbázisba. Most már a következő tranzakciókat is „kapcsolhatja” hozzá. Nézzük meg, hogyan jönnek létre a nullától eltérő tranzakciók.
Az első dolog, amelyre valószínűleg felfigyelt, az a kulcspárok bősége. A már megszokott pénztárcakulcspár mellett a szokásos és a szervizkulcspárok használatosak.
Egy közönséges nyilvános kulcs az, amiért minden elindult. Ez a kulcs a külvilágban kibontakozó különféle eljárásokban, folyamatokban vesz részt (banki és egyéb tranzakciók, dokumentumáramlás stb.). Például egy közönséges párból származó titkos kulcs felhasználható digitális aláírás létrehozására különféle dokumentumokhoz - fizetési megbízásokhoz stb., és egy nyilvános kulccsal ellenőrizhető ez a digitális aláírás az utasítások későbbi végrehajtásával, feltéve, hogy az érvényes.
A szolgáltatáspár a regisztrált DPKI alany számára kerül kiadásra. Ennek a párnak a neve megfelel a céljának. Ne feledje, hogy nulla tranzakció létrehozásakor/ellenőrzésekor a szolgáltatáskulcsok nem használatosak.
Tisztázzuk még egyszer a kulcsok célját:
- A pénztárcakulcsok nulla tranzakciók és bármely más nem nulla tranzakció generálására/ellenőrzésére szolgálnak. A pénztárca privát kulcsát csak a pénztárca tulajdonosa ismeri, aki számos közönséges nyilvános kulcs tulajdonosa is.
- A közönséges nyilvános kulcs célját tekintve hasonló egy nyilvános kulcshoz, amelyhez egy központi PKI-ben adnak ki tanúsítványt.
- A szolgáltatási kulcspár a DPKI-hez tartozik. A titkos kulcsot a regisztrált entitások adják ki, és a tranzakciók digitális aláírásának generálásakor használják (kivéve a nulla tranzakciókat). A nyilvános a tranzakció elektronikus digitális aláírásának ellenőrzésére szolgál, mielőtt az a nyilvántartóba kerül.
Így a kulcsoknak két csoportja van. Az első a szervizkulcsokat és a pénztárcakulcsokat tartalmazza – ezeknek csak a DPKI kontextusában van értelme. A második csoportba tartoznak a közönséges kulcsok – hatókörük változhat, és az alkalmazási feladatok határozzák meg, amelyekben használják őket. A DPKI ugyanakkor biztosítja a közönséges nyilvános kulcsok integritását és hitelességét.
Megjegyzés: A szolgáltatáskulcs-párt különböző DPKI entitások ismerhetik. Például lehet, hogy mindenkinél ugyanaz. Ez az oka annak, hogy minden nem nulla tranzakció aláírásának generálásakor két titkos kulcsot használnak, amelyek közül az egyik a pénztárca kulcsa - ezt csak a pénztárca tulajdonosa ismeri, aki egyben sok közönséges tulajdonos is. nyilvános kulcsok. Minden kulcsnak megvan a maga jelentése. Például mindig lehet bizonyítani, hogy a tranzakciót egy regisztrált DPKI alany vitte be a nyilvántartásba, mivel az aláírás is titkosszolgálati kulcson keletkezett. És nem lehet visszaélés, például DOS támadás, mert a tulajdonos fizet minden egyes tranzakcióért.
Minden tranzakció, amely a nulla egyet követi, hasonló módon jön létre: a nyilvános kulcs (nem a pénztárca, mint a nulla tranzakció esetében, hanem egy közönséges kulcspárból) két SHA256 és RIPEMD160 hash függvényen keresztül fut. Így keletkeznek a harmadik mező adatai. A negyedik mező tartalmazza a kísérő információkat (például információkat az aktuális állapotról, lejárati dátumokról, időbélyegzőről, a használt kripto-algoritmusok azonosítóiról stb.). Az ötödik mező tartalmazza a szolgáltatási kulcspár nyilvános kulcsát. Segítségével ezután a digitális aláírás ellenőrzésre kerül, így replikálódik. Indokoljuk meg egy ilyen megközelítés szükségességét.
Emlékezzünk vissza, hogy a tranzakció egy készletbe kerül, és ott tárolódik a feldolgozásig. A poolban való tárolás bizonyos kockázattal jár – a tranzakciós adatok meghamisíthatók. A tranzakció adatait a tulajdonos elektronikus digitális aláírással igazolja. A digitális aláírás ellenőrzésére szolgáló nyilvános kulcs kifejezetten fel van tüntetve az egyik tranzakciós mezőben, és ezt követően bekerül a nyilvántartásba. A tranzakciófeldolgozás sajátosságaiból adódóan a támadó saját belátása szerint módosíthatja az adatokat, majd titkos kulcsával ellenőrizheti azokat, és a tranzakcióban szereplő digitális aláírás ellenőrzésére egy páros nyilvános kulcsot jelezhet. Ha a hitelességet és az integritást kizárólag digitális aláírással biztosítják, akkor az ilyen hamisítás észrevétlen marad. Ha azonban a digitális aláíráson kívül van egy további mechanizmus, amely biztosítja a tárolt információk archiválását és fennmaradását, akkor a hamisítás kimutatható. Ehhez elegendő a tulajdonos valódi nyilvános kulcsát megadni a rendszerleíró adatbázisban. Magyarázzuk el, hogyan működik ez.
Hagyja, hogy a támadó hamisítsa meg a tranzakciós adatokat. A kulcsok és a digitális aláírások szempontjából a következő lehetőségek lehetségesek:
1. A támadó elhelyezi nyilvános kulcsát a tranzakcióban, miközben a tulajdonos digitális aláírása változatlan marad.
2. A támadó digitális aláírást hoz létre a privát kulcsán, de a tulajdonos nyilvános kulcsát változatlanul hagyja.
3. A támadó digitális aláírást hoz létre a privát kulcsán, és egy párosított nyilvános kulcsot helyez el a tranzakcióban.
Nyilvánvaló, hogy az 1. és 2. opció értelmetlen, mivel a digitális aláírás ellenőrzése során mindig észlelésre kerülnek. Csak a 3. lehetőségnek van értelme, és ha a támadó digitális aláírást hoz létre a saját titkos kulcsán, akkor kénytelen elmenteni egy páros nyilvános kulcsot a tranzakció során, amely eltér a tulajdonos nyilvános kulcsától. Ez az egyetlen módja annak, hogy a támadó hamis adatokat kényszerítsen ki.
Tegyük fel, hogy a tulajdonosnak fix kulcspárja van – privát és nyilvános. Legyen az adatok digitális aláírással hitelesítve az ebből a párból származó titkos kulccsal, és a nyilvános kulcs kerüljön feltüntetésre a tranzakcióban. Tételezzük fel azt is, hogy ezt a nyilvános kulcsot korábban bevitték a nyilvántartásba, és hitelességét megbízhatóan ellenőrizték. Ekkor hamisítást jelez az a tény, hogy a tranzakcióból származó nyilvános kulcs nem egyezik meg a nyilvántartás nyilvános kulcsával.
Összefoglaljuk. A tulajdonos legelső tranzakciós adatainak feldolgozásakor szükséges a nyilvántartásba bevitt nyilvános kulcs hitelességének ellenőrzése. Ehhez olvassa el a kulcsot a rendszerleíró adatbázisból, és hasonlítsa össze a tulajdonos valódi nyilvános kulcsával a biztonsági területen (a relatív sebezhetőség területén). Ha a kulcs hitelessége megerősítést nyer, és annak fennmaradása az elhelyezéskor garantált, akkor a későbbi tranzakcióból származó kulcs hitelessége könnyen megerősíthető/cáfolható a nyilvántartásból származó kulccsal való összehasonlítással. Más szavakkal, a rendszerleíró adatbázis kulcsa referenciamintaként szolgál. Az összes többi tulajdonosi tranzakció feldolgozása hasonlóan történik.
A tranzakciót elektronikus digitális aláírás igazolja - itt van szükség titkos kulcsokra, és nem egy, hanem egyszerre kettő - szervizkulcsra és pénztárcakulcsra. A két titkos kulcs használatának köszönhetően biztosított a szükséges biztonsági szint - elvégre a szolgáltatás titkos kulcsát a többi felhasználó ismerheti, míg a pénztárca titkos kulcsát csak a közönséges kulcspár tulajdonosa ismeri. Az ilyen kétkulcsos aláírást „konszolidált” digitális aláírásnak neveztük.
A nem nulla tranzakciók ellenőrzése két nyilvános kulccsal történik: a pénztárca és a szervizkulcs segítségével. Az ellenőrzési folyamat két fő szakaszra osztható: az első a pénztárca nyilvános kulcsának kivonatának ellenőrzése, a második pedig a tranzakció elektronikus digitális aláírásának ellenőrzése, ugyanaz az összevont, amely két titkos kulcs felhasználásával jött létre ( pénztárca és szerviz). Ha a digitális aláírás érvényessége megerősítést nyer, akkor további ellenőrzést követően a tranzakció bekerül a nyilvántartásba.
Felmerülhet egy logikus kérdés: hogyan lehet ellenőrizni, hogy egy tranzakció egy adott lánchoz tartozik-e, amelynek „gyökere” nulla tranzakció formájában? Ebből a célból az ellenőrzési folyamat egy további lépéssel – a kapcsolódási ellenőrzéssel – egészül ki. Itt lesz szükségünk az első két mező adataira, amelyeket eddig figyelmen kívül hagytunk.
Képzeljük el, hogy ellenőriznünk kell, hogy a 3. tranzakció valóban a 2. tranzakció után jön-e. Ehhez a kombinált kivonatolási módszerrel a 2. számú tranzakció harmadik, negyedik és ötödik mezőjének adataihoz kiszámítják a hash függvény értékét. Ezután a 3. számú tranzakció első mezőjéből származó adatok és a 2. számú tranzakció harmadik, negyedik és ötödik mezőjének adataihoz korábban kapott kombinált hash függvényérték összefűzése történik. Mindezt két hash-függvényen keresztül is lefuttatja az SHA256 és a RIPEMD160. Ha a kapott érték megegyezik a 2. számú tranzakció második mezőjében szereplő adatokkal, akkor az ellenőrzés sikeres és a kapcsolat megerősítésre kerül. Ez az alábbi ábrákon világosabban látható.
Általánosságban elmondható, hogy a bejelentések létrehozásának és nyilvántartásba vételének technológiája pontosan így néz ki. Az értesítési lánc kialakításának folyamatát az alábbi ábra szemlélteti:
Ebben a szövegben nem foglalkozunk a kétségtelenül létező részletekkel, hanem visszatérünk a decentralizált nyilvános kulcsú infrastruktúra gondolatának megvitatásához.
Tehát, mivel a kérelmező maga nyújt be kérelmet olyan bejelentések nyilvántartásba vételére, amelyeket nem a CA-adatbázisban, hanem a nyilvántartásban tárolnak, figyelembe kell venni a DPKI fő építészeti összetevőit:
1. Érvényes értesítések nyilvántartása (RDN).
2. A visszavont bejelentések nyilvántartása (RON).
3. Felfüggesztett értesítések nyilvántartása (RPN).
A nyilvános kulcsokkal kapcsolatos információkat az RDN/RON/RPN tárolja hash függvényértékek formájában. Azt is érdemes megjegyezni, hogy ezek lehetnek különböző nyilvántartások, vagy különböző láncok, vagy akár egyetlen lánc egy nyilvántartás részeként is, amikor egy közönséges nyilvános kulcs állapotára vonatkozó információkat (visszavonás, felfüggesztés stb.) viszünk be a rendszerbe. az adatstruktúra negyedik mezője a megfelelő kódérték formájában. A DPKI architekturális megvalósításának számos különböző lehetősége van, és az egyik vagy a másik kiválasztása számos tényezőtől függ, például olyan optimalizálási kritériumoktól, mint a nyilvános kulcsok tárolására szolgáló hosszú távú memória költsége stb.
Így a DPKI ha nem is egyszerűbbnek, de legalábbis összevethetőnek bizonyulhat az építészeti komplexitás szempontjából egy központosított megoldással.
A fő kérdés továbbra is az - Melyik nyilvántartás alkalmas a technológia megvalósítására?
A rendszerleíró adatbázissal szembeni fő követelmény az, hogy bármilyen típusú tranzakciót generálhasson. A főkönyv leghíresebb példája a Bitcoin hálózat. A fent leírt technológia megvalósítása során azonban bizonyos nehézségek merülnek fel: a meglévő szkriptnyelv korlátai, a tetszőleges adatkészletek feldolgozásához szükséges mechanizmusok hiánya, tetszőleges típusú tranzakciók generálására szolgáló módszerek és még sok más.
Mi az ENCRY-nél megpróbáltuk megoldani a fent megfogalmazott problémákat, és kifejlesztettünk egy nyilvántartást, amely véleményünk szerint számos előnnyel jár, nevezetesen:
- többféle tranzakciót támogat: egyszerre cserélhet eszközöket (vagyis pénzügyi tranzakciókat hajthat végre), és tetszőleges szerkezetű tranzakciókat hozhat létre,
- a fejlesztők hozzáférhetnek a szabadalmaztatott PrismLang programozási nyelvhez, amely biztosítja a szükséges rugalmasságot a különféle technológiai problémák megoldása során,
- biztosított egy mechanizmus tetszőleges adathalmazok feldolgozására.
Ha egyszerűsített megközelítést alkalmazunk, akkor a következő műveletsor történik:
- A jelentkező regisztrál a DPKI-nál, és digitális pénztárcát kap. A pénztárca címe a pénztárca nyilvános kulcsának hash értéke. A pénztárca privát kulcsát csak a kérelmező ismeri.
- A regisztrált alany hozzáférést kap a szolgáltatás titkos kulcsához.
- Az alany nulla tranzakciót generál, és azt digitális aláírással igazolja a pénztárca titkos kulcsával.
- Ha nullától eltérő tranzakció jön létre, akkor azt elektronikus digitális aláírással igazolják két titkos kulccsal: egy pénztárca és egy szolgáltatási kulccsal.
- Az alany tranzakciót nyújt be a poolnak.
- Az ENCRY hálózati csomópont beolvassa a tranzakciót a készletből, és ellenőrzi a digitális aláírást, valamint a tranzakció csatlakoztathatóságát.
- A digitális aláírás érvényessége és a kapcsolat megerősítése esetén előkészíti a tranzakciót a nyilvántartásba vételre.
Itt a rendszerleíró adatbázis elosztott adatbázisként működik, amely információkat tárol az érvényes, törölt és felfüggesztett értesítésekről.
Természetesen a decentralizáció nem csodaszer. Az elsődleges felhasználói hitelesítés alapvető problémája nem tűnik el sehol: ha jelenleg a kérelmező ellenőrzését a CR végzi, akkor a DPKI-ben javasolt a hitelesítést közösségi tagokra delegálni, és az anyagi motivációt az aktivitás ösztönzésére használni. A nyílt forráskódú hitelesítési technológia jól ismert. Az ilyen ellenőrzés hatékonyságát a gyakorlat is megerősítette. Emlékezzünk vissza a Bellingcat online kiadvány számos nagy horderejű vizsgálatára.
Általánosságban azonban a következő kép rajzolódik ki: A DPKI lehetőséget kínál a központosított PKI, ha nem is az összes, de sok hiányosság kijavítására.
Iratkozzon fel Habrablogunkra, tervezzük, hogy továbbra is aktívan tudósítunk kutatásunkról és fejlesztésünkről, és követjük , ha nem akarsz lemaradni az ENCRY projektekkel kapcsolatos egyéb hírekről.
Forrás: will.com