Není žádným tajemstvím, že jedním z běžně používaných pomocných nástrojů, bez kterých se ochrana dat v otevřených sítích neobejde, je technologie digitálních certifikátů. Není však žádným tajemstvím, že hlavní nevýhodou technologie je bezpodmínečná důvěra v centra, která vydávají digitální certifikáty. Ředitel pro technologie a inovace ve společnosti ENCRY Andrey Chmora navrhl nový přístup k organizaci infrastruktura veřejného klíče (Infrastruktura veřejného klíče, PKI), která pomůže odstranit současné nedostatky a která využívá technologii distribuované účetní knihy (blockchain). Ale nejdřív.
Pokud jste obeznámeni s tím, jak vaše současná infrastruktura veřejných klíčů funguje, a znáte její hlavní nedostatky, můžete přeskočit k tomu, co navrhujeme změnit níže.
Co jsou digitální podpisy a certifikáty?Interakce na internetu vždy zahrnuje přenos dat. Všichni máme zájem na zajištění bezpečného přenosu dat. Ale co je bezpečnost? Mezi nejžádanější bezpečnostní služby patří důvěrnost, integrita a autenticita. K tomuto účelu se v současnosti používají metody asymetrické kryptografie, případně kryptografie s veřejným klíčem.
Začněme tím, že pro použití těchto metod musí mít subjekty interakce dva jednotlivé párové klíče – veřejný a tajný. S jejich pomocí jsou poskytovány bezpečnostní služby, které jsme uvedli výše.
Jak je dosaženo důvěrnosti přenosu informací? Před odesláním dat odesílající účastník zašifruje (kryptograficky transformuje) otevřená data pomocí veřejného klíče příjemce a příjemce přijatý šifrovaný text dešifruje pomocí spárovaného tajného klíče.
Jak je dosaženo integrity a autenticity přenášených informací? K vyřešení tohoto problému byl vytvořen další mechanismus. Otevřená data nejsou šifrována, ale výsledek použití kryptografické hašovací funkce – „komprimovaný“ obraz sekvence vstupních dat – je přenášen v zašifrované podobě. Výsledek takového hašování se nazývá „digest“ a je zašifrován pomocí tajného klíče odesílajícího účastníka („svědka“). V důsledku zašifrování výtahu je získán digitální podpis. Spolu s nešifrovaným textem je předán přijímajícímu účastníkovi („ověřovateli“). Dešifruje digitální podpis na veřejném klíči svědka a porovná jej s výsledkem použití kryptografické hašovací funkce, kterou ověřovatel vypočítá nezávisle na základě přijatých otevřených dat. Pokud se shodují, znamená to, že data byla odeslána v autentické a úplné podobě odesílajícím účastníkem a nebyla upravena útočníkem.
Většina zdrojů, které pracují s osobními údaji a platebními informacemi (banky, pojišťovny, letecké společnosti, platební systémy, ale i vládní portály jako daňová služba), aktivně využívá metody asymetrické kryptografie.
Co s tím má společného digitální certifikát? Je to jednoduché. První i druhý proces zahrnují veřejné klíče, a protože hrají ústřední roli, je velmi důležité zajistit, aby klíče skutečně patřily odesílateli (svědkovi, v případě ověření podpisu) nebo příjemci, a nikoli nahrazeny klíči útočníků. To je důvod, proč existují digitální certifikáty pro zajištění pravosti a integrity veřejného klíče.
Poznámka: Autenticita a integrita veřejného klíče se potvrzuje přesně stejným způsobem jako pravost a integrita veřejných dat, tedy pomocí elektronického digitálního podpisu (EDS).
Odkud pocházejí digitální certifikáty?Za vydávání a údržbu digitálních certifikátů jsou odpovědné důvěryhodné certifikační autority nebo certifikační autority (CA). Žadatel požádá o vydání certifikátu od CA, podrobí se identifikaci v Registračním centru (CR) a obdrží certifikát od CA. CA garantuje, že veřejný klíč z certifikátu patří přesně té entitě, pro kterou byl vydán.
Pokud nepotvrdíte pravost veřejného klíče, pak ho může útočník při přenosu/ukládání tohoto klíče nahradit svým vlastním. Pokud k substituci došlo, útočník bude moci dešifrovat vše, co odesílající účastník předá přijímajícímu účastníkovi, nebo změnit otevřená data podle vlastního uvážení.
Digitální certifikáty se používají všude tam, kde je dostupná asymetrická kryptografie. Jedním z nejběžnějších digitálních certifikátů jsou certifikáty SSL pro zabezpečenou komunikaci přes protokol HTTPS. Stovky společností registrovaných v různých jurisdikcích se zabývají vydáváním certifikátů SSL. Hlavní podíl připadá na pět až deset velkých důvěryhodných center: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA a CR jsou součástí PKI, která také zahrnuje:
- Otevřete adresář – veřejná databáze, která poskytuje bezpečné ukládání digitálních certifikátů.
- Seznam zneplatněných certifikátů – veřejná databáze, která poskytuje bezpečné uložení digitálních certifikátů zrušených veřejných klíčů (například kvůli kompromitaci spárovaného soukromého klíče). Subjekty infrastruktury mohou k této databázi přistupovat samostatně nebo mohou využít specializovaný protokol OCSP (Online Certification Status Protocol), který zjednodušuje proces ověřování.
- Uživatelé certifikátů – obsluhované subjekty PKI, které uzavřely uživatelskou smlouvu s CA a ověřují digitální podpis a/nebo šifrují data na základě veřejného klíče z certifikátu.
- následovníci – obsluhovala subjekty PKI, které vlastní tajný klíč spárovaný s veřejným klíčem z certifikátu a které uzavřely účastnickou smlouvu s CA. Předplatitel může být současně uživatelem certifikátu.
Důvěryhodné entity infrastruktury veřejných klíčů, které zahrnují CA, CR a otevřené adresáře, jsou tedy odpovědné za:
1. Ověření pravosti totožnosti žadatele.
2. Profilování certifikátu veřejného klíče.
3. Vydání certifikátu veřejného klíče žadateli, jehož totožnost byla spolehlivě potvrzena.
4. Změňte stav certifikátu veřejného klíče.
5. Poskytování informací o aktuálním stavu certifikátu veřejného klíče.
Nevýhody PKI, jaké jsou?Základní chybou PKI je přítomnost důvěryhodných subjektů.
Uživatelé musí bezpodmínečně důvěřovat CA a CR. Ale jak ukazuje praxe, bezpodmínečná důvěra je plná vážných následků.
Za posledních deset let došlo v této oblasti k několika velkým skandálům souvisejícím se zranitelností infrastruktury.
— v roce 2010 se malware Stuxnet začal šířit online, podepsaný pomocí ukradených digitálních certifikátů od společností RealTek a JMicron.
– V roce 2017 Google obvinil Symantec z vydávání velkého množství padělaných certifikátů. Symantec byl v té době jednou z největších CA z hlediska objemu výroby. V prohlížeči Google Chrome 70 byla před 1. prosincem 2017 zastavena podpora certifikátů vydávaných touto společností a jejími přidruženými centry GeoTrust a Thawte.
CA byly kompromitovány a v důsledku toho trpěli všichni – samotné CA, stejně jako uživatelé a předplatitelé. Důvěra v infrastrukturu byla narušena. Kromě toho mohou být digitální certifikáty zablokovány v souvislosti s politickými konflikty, což také ovlivní provoz mnoha zdrojů. Právě toho se před několika lety obávala ruská prezidentská administrativa, kde v roce 2016 jednali o možnosti vytvoření státního certifikačního centra, které by vydávalo SSL certifikáty webům na RuNetu. Současný stav je takový, že i státní portály v Rusku digitální certifikáty vydané americkými společnostmi Comodo nebo Thawte (dceřiná společnost Symantec).
Je tu další problém – otázka primární autentizace (autentizace) uživatelů. Jak identifikovat uživatele, který kontaktoval CA s žádostí o vydání digitálního certifikátu bez přímého osobního kontaktu? Nyní se to řeší situačně v závislosti na možnostech infrastruktury. Něco se přebírá z otevřených rejstříků (například informace o právnických osobách požadujících certifikáty), v případech, kdy jsou žadateli fyzické osoby, lze využít bankovní úřady nebo pošty, kde je jejich totožnost potvrzena pomocí identifikačních dokladů, například cestovního pasu.
Problém falšování pověřovacích údajů za účelem předstírání identity je zásadní. Připomeňme, že z informačně-teoretických důvodů neexistuje úplné řešení tohoto problému: bez a priori spolehlivých informací není možné potvrdit nebo vyvrátit autenticitu konkrétního subjektu. K ověření je zpravidla nutné předložit soubor dokumentů prokazujících totožnost žadatele. Existuje mnoho různých metod ověřování, ale žádná z nich neposkytuje plnou záruku pravosti dokumentů. V důsledku toho nelze zaručit ani pravost identity žadatele.
Jak lze tyto nedostatky odstranit?Pokud lze problémy PKI v současném stavu vysvětlit centralizací, pak je logické předpokládat, že decentralizace by pomohla zjištěné nedostatky částečně odstranit.
Decentralizace neznamená přítomnost důvěryhodných subjektů – pokud vytvoříte decentralizovaná infrastruktura veřejného klíče (Decentralizovaná infrastruktura veřejného klíče, DPKI), pak není potřeba CA ani CR. Opusťme koncept digitálního certifikátu a použijme distribuovaný registr k ukládání informací o veřejných klíčích. Registrem v našem případě nazýváme lineární databázi skládající se z jednotlivých záznamů (bloků) propojených pomocí technologie blockchain. Místo digitálního certifikátu zavedeme pojem „notifikace“.
Jak bude proces přijímání, ověřování a rušení oznámení vypadat v navrhovaném DPKI:
1. Žádost o notifikaci podává každý žadatel samostatně vyplněním formuláře při registraci, poté vytvoří transakci, která je uložena ve specializovaném poolu.
2. Informace o veřejném klíči spolu s podrobnostmi o vlastníkovi a dalšími metadaty jsou uloženy v distribuovaném registru, nikoli v digitálním certifikátu, za jehož vydání v centralizovaném PKI odpovídá CA.
3. Ověření pravosti identity žadatele se provádí dodatečně společným úsilím komunity uživatelů DPKI, nikoli ČR.
4. Stav veřejného klíče může změnit pouze vlastník takového oznámení.
5. Kdokoli může přistupovat k distribuované účetní knize a kontrolovat aktuální stav veřejného klíče.
Poznámka: Komunitní ověření totožnosti žadatele se může na první pohled zdát nespolehlivé. Musíme však mít na paměti, že v dnešní době všichni uživatelé digitálních služeb nevyhnutelně zanechávají digitální stopu a tento proces bude nadále nabírat na síle. Otevřené elektronické registry právnických osob, mapy, digitalizace snímků terénu, sociální sítě – to vše jsou veřejně dostupné nástroje. Už je úspěšně používají při vyšetřování jak novináři, tak i orgány činnými v trestním řízení. Stačí si připomenout například vyšetřování Bellingcatu nebo společného vyšetřovacího týmu JIT, který studuje okolnosti pádu malajsijského boeingu.
Jak by tedy decentralizovaná infrastruktura veřejného klíče fungovala v praxi? Zastavme se u popisu samotné technologie, kterou jsme patentováno v roce 2018 a právem to považujeme za naše know-how.
Představte si, že existuje nějaký vlastník, který vlastní mnoho veřejných klíčů, kde každý klíč je určitá transakce, která je uložena v registru. Jak můžete při absenci CA pochopit, že všechny klíče patří tomuto konkrétnímu vlastníkovi? K vyřešení tohoto problému je vytvořena nulová transakce, která obsahuje informace o majiteli a jeho peněžence (ze které se odečítá provize za umístění transakce do registru). Nulová transakce je jakousi „kotvou“, ke které budou připojeny následující transakce s daty o veřejných klíčích. Každá taková transakce obsahuje specializovanou datovou strukturu nebo jinými slovy oznámení.
Notifikace je strukturovaný soubor dat skládající se z funkčních polí a obsahující informace o veřejném klíči vlastníka, jehož trvalost je zaručena umístěním do jednoho z přidružených záznamů distribuovaného registru.
Další logickou otázkou je, jak se tvoří nulová transakce? Nulová transakce – stejně jako následné transakce – je agregací šesti datových polí. Při vytváření nulové transakce je zapojen klíčový pár peněženky (veřejný a párový tajný klíč). Tato dvojice klíčů se objeví v okamžiku, kdy uživatel zaregistruje svou peněženku, ze které bude stržena provize za umístění nulové transakce do registru a následně operace s upozorněními.
Jak je znázorněno na obrázku, přehled veřejného klíče peněženky je generován postupným aplikováním hashovacích funkcí SHA256 a RIPEMD160. Zde je RIPEMD160 zodpovědný za kompaktní reprezentaci dat, jejichž šířka nepřesahuje 160 bitů. To je důležité, protože registr není levná databáze. Samotný veřejný klíč se zadává do pátého pole. První pole obsahuje data, která navazují spojení s předchozí transakcí. U nulové transakce toto pole neobsahuje nic, co by ji odlišovalo od následných transakcí. Druhým polem jsou údaje pro kontrolu konektivity transakcí. Pro stručnost budeme údaje v prvním a druhém poli nazývat „odkaz“ a „kontrola“. Obsah těchto polí je generován iterativním hašováním, jak ukazuje propojení druhé a třetí transakce na obrázku níže.
Data z prvních pěti polí jsou certifikována elektronickým podpisem, který je generován pomocí tajného klíče peněženky.
To je vše, nulová transakce je odeslána do fondu a po úspěšném ověření je vložena do registru. Nyní s ním můžete „propojit“ následující transakce. Uvažujme, jak se tvoří transakce jiné než nulové.
První věc, která vás pravděpodobně zaujala, je množství klíčových párů. Kromě již známého páru klíčů peněženky se používají páry běžných a servisních klíčů.
Vše, kvůli čemu bylo spuštěno, je obyčejný veřejný klíč. Tento klíč se podílí na různých procedurách a procesech probíhajících ve vnějším světě (bankovní a jiné transakce, tok dokumentů atd.). Například tajný klíč z obyčejného páru lze použít pro generování digitálních podpisů pro různé dokumenty - platební příkazy apod. a veřejný klíč lze použít k ověření tohoto digitálního podpisu s následným provedením těchto pokynů za předpokladu, že je platná.
Servisní pár se vydává registrovanému subjektu DPKI. Název této dvojice odpovídá jejímu účelu. Všimněte si, že při vytváření/kontrole nulové transakce se nepoužívají servisní klíče.
Pojďme si znovu ujasnit účel klíčů:
- Klíče peněženky se používají ke generování/ověření jak nulové transakce, tak jakékoli jiné nenulové transakce. Soukromý klíč peněženky zná pouze majitel peněženky, který je také vlastníkem mnoha běžných veřejných klíčů.
- Běžný veřejný klíč je svým účelem podobný veřejnému klíči, pro který je vydán certifikát v centralizovaném PKI.
- Pár klíčů služby patří DPKI. Tajný klíč se vydává registrovaným subjektům a používá se při generování digitálních podpisů pro transakce (s výjimkou nulových transakcí). Veřejné se používá k ověření elektronického digitálního podpisu transakce před jejím zveřejněním v registru.
Existují tedy dvě skupiny klíčů. První zahrnuje servisní klíče a klíče od peněženky – ty mají smysl pouze v kontextu DPKI. Do druhé skupiny patří běžné klíče – jejich rozsah se může lišit a je dán aplikačními úlohami, ve kterých se používají. DPKI zároveň zajišťuje integritu a autenticitu běžných veřejných klíčů.
Poznámka: Pár servisních klíčů může být znám různým entitám DPKI. Například to může být pro všechny stejné. Právě z tohoto důvodu se při generování podpisu každé nenulové transakce používají dva tajné klíče, z nichž jeden je klíč k peněžence - zná jej pouze majitel peněženky, který je také vlastníkem mnoha běžných veřejné klíče. Všechny klíče mají svůj význam. Vždy je například možné prokázat, že transakce byla zapsána do registru registrovaným subjektem DPKI, protože podpis byl vygenerován i na klíč tajné služby. A nemůže dojít ke zneužití, jako jsou útoky DOS, protože majitel platí za každou transakci.
Všechny transakce, které následují po nulové jedničce, jsou tvořeny podobným způsobem: veřejný klíč (nikoli peněženka, jako v případě nulové transakce, ale z obyčejného páru klíčů) je spuštěn dvěma hashovacími funkcemi SHA256 a RIPEMD160. Takto se tvoří data třetího pole. Čtvrté pole obsahuje doprovodné informace (například informace o aktuálním stavu, datech expirace, časovém razítku, identifikátorech použitých krypto-algoritmů atd.). Páté pole obsahuje veřejný klíč z dvojice klíčů služby. S jeho pomocí pak dojde ke kontrole digitálního podpisu, takže dojde k jeho replikaci. Zdůvodněme potřebu takového přístupu.
Připomeňme, že transakce je vložena do fondu a tam uložena, dokud není zpracována. Ukládání do poolu je spojeno s určitým rizikem – transakční data mohou být zfalšována. Majitel potvrdí data transakce elektronickým digitálním podpisem. Veřejný klíč pro ověření tohoto digitálního podpisu je výslovně uveden v jednom z polí transakce a následně je zapsán do registru. Zvláštnosti zpracování transakcí jsou takové, že útočník je schopen změnit data podle vlastního uvážení a následně je ověřit pomocí svého tajného klíče a uvést spárovaný veřejný klíč pro ověření digitálního podpisu v transakci. Pokud je pravost a integrita zajištěna výhradně digitálním podpisem, pak takový padělek zůstane bez povšimnutí. Pokud však kromě digitálního podpisu existuje další mechanismus, který zajišťuje archivaci i perzistenci uložených informací, pak lze padělek odhalit. K tomu stačí zadat do registru skutečný veřejný klíč vlastníka. Pojďme si vysvětlit, jak to funguje.
Nechte útočníka zfalšovat transakční data. Z hlediska klíčů a digitálních podpisů jsou možné následující možnosti:
1. Útočník vloží svůj veřejný klíč do transakce, zatímco digitální podpis vlastníka zůstane nezměněn.
2. Útočník vytvoří digitální podpis na svém soukromém klíči, ale ponechá veřejný klíč vlastníka beze změny.
3. Útočník vytvoří digitální podpis na svém soukromém klíči a vloží do transakce spárovaný veřejný klíč.
Je zřejmé, že možnosti 1 a 2 jsou bezvýznamné, protože budou vždy detekovány během ověřování digitálního podpisu. Pouze možnost 3 dává smysl, a pokud útočník vytvoří digitální podpis na svém vlastním tajném klíči, je nucen v transakci uložit spárovaný veřejný klíč, odlišný od veřejného klíče vlastníka. Toto je jediný způsob, jak může útočník uložit zfalšovaná data.
Předpokládejme, že vlastník má pevně daný pár klíčů – soukromý a veřejný. Nechte data certifikovat digitálním podpisem pomocí tajného klíče z tohoto páru a veřejný klíč je uveden v transakci. Předpokládejme také, že tento veřejný klíč byl již dříve zadán do registru a jeho pravost byla spolehlivě ověřena. Pak bude padělek označen tím, že veřejný klíč z transakce neodpovídá veřejnému klíči z registru.
Abych to shrnul. Při zpracování vůbec prvních transakčních dat vlastníka je nutné ověřit pravost veřejného klíče zapsaného do registru. Chcete-li to provést, přečtěte si klíč z registru a porovnejte jej se skutečným veřejným klíčem vlastníka v rámci bezpečnostního perimetru (oblast relativní nezranitelnosti). Pokud je potvrzena pravost klíče a je zaručena jeho perzistence při umístění, pak lze pravost klíče z následné transakce snadno potvrdit/vyvrátit jeho porovnáním s klíčem z registru. Jinými slovy, klíč z registru se používá jako referenční vzorek. Všechny ostatní transakce vlastníka jsou zpracovány podobně.
Transakce je certifikována elektronickým digitálním podpisem - zde jsou potřeba tajné klíče, a ne jeden, ale dva najednou - servisní klíč a klíč k peněžence. Díky použití dvou tajných klíčů je zajištěna potřebná úroveň zabezpečení - vždyť tajný klíč služby mohou znát ostatní uživatelé, zatímco tajný klíč peněženky zná pouze majitel běžného páru klíčů. Takovýto dvouklíčový podpis jsme nazvali „konsolidovaný“ digitální podpis.
Ověření nenulových transakcí se provádí pomocí dvou veřejných klíčů: peněženky a servisního klíče. Proces ověření lze rozdělit do dvou hlavních fází: první je kontrola výtahu veřejného klíče peněženky a druhá kontrola elektronického digitálního podpisu transakce, stejného konsolidovaného, který byl vytvořen pomocí dvou tajných klíčů ( peněženka a servis). Pokud je potvrzena platnost digitálního podpisu, je po dodatečném ověření transakce zapsána do registru.
Může vyvstat logická otázka: jak zkontrolovat, zda transakce patří do konkrétního řetězce s „kořenem“ ve formě nulové transakce? Za tímto účelem je ověřovací proces doplněn o další fázi - kontrolu konektivity. Zde budeme potřebovat údaje z prvních dvou polí, které jsme dosud ignorovali.
Představme si, že potřebujeme zkontrolovat, zda transakce č. 3 skutečně následuje po transakci č. 2. K tomu se pomocí kombinované metody hašování vypočítá hodnota hašovací funkce pro data ze třetího, čtvrtého a pátého pole transakce č. 2. Poté se provede zřetězení dat z prvního pole transakce č. 3 a dříve získaná hodnota kombinované hashovací funkce pro data ze třetího, čtvrtého a pátého pole transakce č. 2. To vše je také spuštěno prostřednictvím dvou hashovacích funkcí SHA256 a RIPEMD160. Pokud se přijatá hodnota shoduje s údaji ve druhém poli transakce č. 2, pak kontrola projde a spojení je potvrzeno. To je jasněji znázorněno na obrázcích níže.
Obecně řečeno, technologie pro generování a zadávání oznámení do registru vypadá přesně takto. Vizuální ilustrace procesu vytváření řetězce oznámení je uvedena na následujícím obrázku:
V tomto textu se nebudeme zdržovat detaily, které nepochybně existují, a vrátíme se k diskusi o samotné myšlence decentralizované infrastruktury veřejného klíče.
Vzhledem k tomu, že žadatel sám podává žádost o registraci oznámení, která nejsou uložena v databázi CA, ale v registru, je třeba vzít v úvahu hlavní architektonické součásti DPKI:
1. Registr platných oznámení (RDN).
2. Registr zrušených oznámení (RON).
3. Registr pozastavených oznámení (RPN).
Informace o veřejných klíčích jsou uloženy v RDN/RON/RPN ve formě hodnot hashovací funkce. Za zmínku také stojí, že se může jednat buď o různé registry, nebo o různé řetězce, nebo dokonce o jeden řetězec jako součást jednoho registru, kdy se do registru zadávají informace o stavu běžného veřejného klíče (zrušení, pozastavení atd.). čtvrté pole datové struktury ve formě odpovídající hodnoty kódu. Existuje mnoho různých možností pro architektonickou implementaci DPKI a výběr jedné nebo druhé závisí na řadě faktorů, například takových optimalizačních kritériích, jako jsou náklady na dlouhodobou paměť pro ukládání veřejných klíčů atd.
DPKI se tedy může ukázat jako, když ne jednodušší, tak alespoň srovnatelné s centralizovaným řešením z hlediska architektonické složitosti.
Hlavní otázkou zůstává - Jaký registr je vhodný pro implementaci technologie?
Hlavním požadavkem na registr je schopnost generovat transakce jakéhokoli typu. Nejznámějším příkladem účetní knihy je bitcoinová síť. Při implementaci výše popsané technologie však vznikají určité potíže: omezení existujícího skriptovacího jazyka, nedostatek nezbytných mechanismů pro zpracování libovolných sad dat, metody pro generování transakcí libovolného typu a mnoho dalšího.
V ENCRY jsme se pokusili vyřešit výše formulované problémy a vyvinuli registr, který má podle našeho názoru řadu výhod, a to:
- podporuje několik typů transakcí: může jak směňovat aktiva (tj. provádět finanční transakce), tak vytvářet transakce s libovolnou strukturou,
- vývojáři mají přístup k proprietárnímu programovacímu jazyku PrismLang, který poskytuje potřebnou flexibilitu při řešení různých technologických problémů,
- je poskytován mechanismus pro zpracování libovolných datových souborů.
Pokud použijeme zjednodušený přístup, dojde k následujícímu sledu akcí:
- Žadatel se zaregistruje u DPKI a obdrží digitální peněženku. Adresa peněženky je hashová hodnota veřejného klíče peněženky. Soukromý klíč peněženky zná pouze žadatel.
- Registrovaný subjekt získá přístup k tajnému klíči služby.
- Subjekt vygeneruje nulovou transakci a ověří ji digitálním podpisem pomocí tajného klíče peněženky.
- Pokud vznikne jiná transakce než nula, je certifikována elektronickým digitálním podpisem pomocí dvou tajných klíčů: peněženky a služebního.
- Subjekt odešle transakci do fondu.
- Síťový uzel ENCRY čte transakci z fondu a kontroluje digitální podpis a také konektivitu transakce.
- Pokud je digitální podpis platný a spojení je potvrzeno, připraví transakci pro zápis do registru.
Registr zde funguje jako distribuovaná databáze, která uchovává informace o platných, zrušených a pozastavených oznámeních.
Decentralizace samozřejmě není všelék. Nikde nezmizí zásadní problém primární autentizace uživatele: pokud v současnosti ověřování žadatele provádí ČR, pak se v DPKI navrhuje delegovat ověřování na členy komunity a stimulovat aktivitu pomocí finanční motivace. Technologie open source ověřování je dobře známá. Účinnost takového ověření byla v praxi potvrzena. Připomeňme si znovu řadu významných vyšetřování online publikace Bellingcat.
Obecně se ale ukazuje následující obrázek: DPKI je příležitostí k nápravě, ne-li všech, pak mnoha nedostatků centralizovaného PKI.
Přihlaste se k odběru našeho Habrablogu, plánujeme i nadále aktivně pokrývat náš výzkum a vývoj a sledovat jej , pokud si nechcete nechat ujít další novinky o projektech ENCRY.
Zdroj: www.habr.com