Nie jest tajemnicą, że jednym z powszechnie stosowanych narzędzi pomocniczych, bez którego ochrona danych w sieciach otwartych nie jest możliwa, jest technologia certyfikatów cyfrowych. Nie jest jednak tajemnicą, że główną wadą tej technologii jest bezwarunkowe zaufanie do ośrodków wydających certyfikaty cyfrowe. Dyrektor ds. Technologii i Innowacji w ENCRY Andrey Chmora zaproponował nowe podejście do organizacji infrastrukturę klucza publicznego (Infrastruktura Klucza Publicznego, PKI), co pomoże wyeliminować obecne niedociągnięcia i które wykorzystuje technologię rozproszonego rejestru (blockchain). Ale najpierw sprawy.
Jeśli wiesz, jak działa Twoja obecna infrastruktura klucza publicznego i znasz jej najważniejsze wady, możesz przejść od razu do tego, co proponujemy zmienić poniżej.
Co to są podpisy cyfrowe i certyfikaty?Interakcja w Internecie zawsze wiąże się z przesyłaniem danych. Wszyscy jesteśmy zainteresowani zapewnieniem bezpieczeństwa przesyłania danych. Ale czym jest bezpieczeństwo? Najbardziej poszukiwanymi usługami bezpieczeństwa są poufność, integralność i autentyczność. W tym celu wykorzystuje się obecnie metody kryptografii asymetrycznej, czyli kryptografii z kluczem publicznym.
Zacznijmy od tego, że aby skorzystać z tych metod, podmioty interakcji muszą posiadać dwa indywidualne sparowane klucze – publiczny i tajny. Za ich pomocą świadczone są usługi bezpieczeństwa, o których wspomniałem powyżej.
W jaki sposób zapewniana jest poufność przekazu informacji? Przed wysłaniem danych abonent wysyłający szyfruje (przekształca kryptograficznie) otwarte dane za pomocą klucza publicznego odbiorcy, a odbiorca odszyfrowuje otrzymany tekst zaszyfrowany za pomocą sparowanego tajnego klucza.
W jaki sposób osiągana jest integralność i autentyczność przesyłanych informacji? Aby rozwiązać ten problem, stworzono inny mechanizm. Otwarte dane nie są szyfrowane, ale wynik zastosowania kryptograficznej funkcji skrótu – „skompresowany” obraz wejściowej sekwencji danych – przesyłany jest w postaci zaszyfrowanej. Wynik takiego mieszania nazywany jest „streszczeniem” i jest szyfrowany przy użyciu tajnego klucza abonenta wysyłającego („świadka”). W wyniku zaszyfrowania skrótu uzyskiwany jest podpis cyfrowy. Wraz z czystym tekstem jest on przesyłany do abonenta odbiorcy („weryfikatora”). Odszyfrowuje podpis cyfrowy na kluczu publicznym świadka i porównuje go z wynikiem zastosowania kryptograficznej funkcji skrótu, który weryfikator oblicza samodzielnie na podstawie otrzymanych otwartych danych. Jeśli są zgodne, oznacza to, że dane zostały przesłane w autentycznej i kompletnej formie przez abonenta wysyłającego i nie zostały zmodyfikowane przez osobę atakującą.
Większość zasobów pracujących z danymi osobowymi i informacjami o płatnościach (banki, firmy ubezpieczeniowe, linie lotnicze, systemy płatności, a także portale rządowe, takie jak służba podatkowa) aktywnie wykorzystuje metody kryptografii asymetrycznej.
Co ma z tym wspólnego certyfikat cyfrowy? To proste. Zarówno pierwszy, jak i drugi proces wykorzystują klucze publiczne, a ponieważ odgrywają one kluczową rolę, bardzo ważne jest, aby klucze faktycznie należały do nadawcy (świadka w przypadku weryfikacji podpisu) lub odbiorcy, a nie zastąpione kluczami atakujących. Właśnie dlatego istnieją certyfikaty cyfrowe zapewniające autentyczność i integralność klucza publicznego.
Uwaga: autentyczność i integralność klucza publicznego potwierdza się dokładnie w taki sam sposób, jak autentyczność i integralność danych publicznych, czyli za pomocą elektronicznego podpisu cyfrowego (EDS).
Skąd pochodzą certyfikaty cyfrowe?Zaufane urzędy certyfikacji, czyli urzędy certyfikacji (CA), są odpowiedzialne za wydawanie i utrzymywanie certyfikatów cyfrowych. Wnioskodawca zwraca się do urzędu certyfikacji o wydanie certyfikatu, przechodzi identyfikację w Centrum Rejestracji (CR) i otrzymuje certyfikat z urzędu certyfikacji. Urząd certyfikacji gwarantuje, że klucz publiczny z certyfikatu należy dokładnie do podmiotu, dla którego został wydany.
Jeśli nie potwierdzisz autentyczności klucza publicznego, osoba atakująca podczas przesyłania/przechowywania tego klucza może zastąpić go własnym. Jeśli doszło do podstawienia, atakujący będzie mógł odszyfrować wszystko, co abonent wysyłający przesyła do abonenta odbierającego lub zmienić otwarte dane według własnego uznania.
Certyfikaty cyfrowe są stosowane wszędzie tam, gdzie dostępna jest kryptografia asymetryczna. Jednym z najpopularniejszych certyfikatów cyfrowych są certyfikaty SSL umożliwiające bezpieczną komunikację poprzez protokół HTTPS. W wydawanie certyfikatów SSL zaangażowane są setki firm zarejestrowanych w różnych jurysdykcjach. Główny udział przypada na pięć do dziesięciu dużych zaufanych centrów: IdenTrust, Comodo, GoDaddy, GlobalSign, DigiCert, CERTUM, Actalis, Secom, Trustwave.
CA i CR są składnikami infrastruktury PKI, która obejmuje również:
- Otwarty katalog – publiczna baza danych zapewniająca bezpieczne przechowywanie certyfikatów cyfrowych.
- Lista unieważnionych certyfikatów – publiczna baza danych zapewniająca bezpieczne przechowywanie cyfrowych certyfikatów unieważnionych kluczy publicznych (na przykład w wyniku naruszenia sparowanego klucza prywatnego). Podmioty zajmujące się infrastrukturą mogą samodzielnie uzyskać dostęp do tej bazy danych lub mogą skorzystać ze specjalistycznego protokołu statusu certyfikacji online (OCSP), który upraszcza proces weryfikacji.
- Użytkownicy certyfikatów – obsługiwane podmioty PKI, które zawarły umowę użytkownika z Urzędem certyfikacji i weryfikują podpis cyfrowy i/lub szyfrują dane w oparciu o klucz publiczny z certyfikatu.
- Następni – obsługiwane podmioty PKI, które posiadają tajny klucz sparowany z kluczem publicznym z certyfikatu i które zawarły umowę subskrypcyjną z urzędem certyfikacji. Subskrybent może być jednocześnie użytkownikiem certyfikatu.
Zatem zaufane podmioty infrastruktury klucza publicznego, do których zaliczają się urzędy certyfikacji, CR i otwarte katalogi, odpowiadają za:
1. Weryfikacja autentyczności tożsamości wnioskodawcy.
2. Profilowanie certyfikatu klucza publicznego.
3. Wydanie certyfikatu klucza publicznego dla wnioskodawcy, którego tożsamość została wiarygodnie potwierdzona.
4. Zmień status certyfikatu klucza publicznego.
5. Przekazywanie informacji o aktualnym statusie certyfikatu klucza publicznego.
Wady PKI – jakie są?Podstawową wadą PKI jest obecność zaufanych podmiotów.
Użytkownicy muszą bezwarunkowo ufać urządowi certyfikacji i CR. Ale, jak pokazuje praktyka, bezwarunkowe zaufanie niesie ze sobą poważne konsekwencje.
W ciągu ostatnich dziesięciu lat w tym obszarze doszło do kilku poważnych skandalów związanych z podatnością na zagrożenia infrastruktury.
— w 2010 roku w Internecie zaczęło rozprzestrzeniać się szkodliwe oprogramowanie Stuxnet, podpisane przy użyciu skradzionych certyfikatów cyfrowych firm RealTek i JMicron.
- W 2017 roku Google oskarżył firmę Symantec o wydawanie dużej liczby sfałszowanych certyfikatów. W tamtym czasie Symantec był jednym z największych CA pod względem wielkości produkcji. W przeglądarce Google Chrome 70 obsługa certyfikatów wydawanych przez tę firmę i jej stowarzyszone centra GeoTrust i Thawte została zatrzymana przed 1 grudnia 2017 roku.
Urzędy certyfikacji zostały naruszone, w wyniku czego ucierpieli wszyscy — same urzędy certyfikacji, a także użytkownicy i abonenci. Zaufanie do infrastruktury zostało podważone. Dodatkowo certyfikaty cyfrowe mogą zostać zablokowane w kontekście konfliktów politycznych, co również będzie miało wpływ na działanie wielu zasobów. Tego właśnie obawiano się kilka lat temu w rosyjskiej administracji prezydenckiej, gdzie w 2016 roku dyskutowano nad możliwością utworzenia państwowego centrum certyfikacji, które wystawiałoby certyfikaty SSL witrynom w RuNet. Obecny stan rzeczy jest taki, że nawet portale państwowe w Rosji certyfikaty cyfrowe wydawane przez amerykańskie firmy Comodo czy Thawte (spółka zależna Symanteca).
Jest jeszcze jeden problem – pytanie pierwotne uwierzytelnianie (uwierzytelnianie) użytkowników. Jak zidentyfikować użytkownika, który zwrócił się do urzędu certyfikacji z prośbą o wydanie certyfikatu cyfrowego bez bezpośredniego kontaktu osobistego? Teraz jest to rozwiązywane sytuacyjnie w zależności od możliwości infrastruktury. Coś jest pobierane z otwartych rejestrów (na przykład informacje o osobach prawnych występujących o zaświadczenia); w przypadku, gdy wnioskodawcami są osoby fizyczne, można skorzystać z oddziałów bankowych lub urzędów pocztowych, gdzie ich tożsamość potwierdzana jest za pomocą dokumentów tożsamości, na przykład paszportu.
Problem fałszowania danych uwierzytelniających w celu podszywania się pod inne osoby jest problemem zasadniczym. Zauważmy, że nie ma pełnego rozwiązania tego problemu ze względów informacyjno-teoretycznych: bez posiadania a priori wiarygodnych informacji nie można potwierdzić ani zaprzeczyć autentyczności konkretnego tematu. Co do zasady, do weryfikacji konieczne jest przedstawienie kompletu dokumentów potwierdzających tożsamość wnioskodawcy. Metod weryfikacji jest wiele, jednak żadna z nich nie daje pełnej gwarancji autentyczności dokumentów. W związku z tym nie można zagwarantować również autentyczności tożsamości wnioskodawcy.
Jak wyeliminować te niedociągnięcia?Jeżeli problemy PKI w jej obecnym stanie można wytłumaczyć centralizacją, logiczne jest założenie, że decentralizacja pomogłaby częściowo wyeliminować zidentyfikowane niedociągnięcia.
Decentralizacja nie oznacza obecności zaufanych podmiotów – jeśli tworzysz zdecentralizowana infrastruktura klucza publicznego (Zdecentralizowana infrastruktura klucza publicznego, DPKI), wówczas nie jest potrzebny ani CA, ani CR. Porzućmy koncepcję certyfikatu cyfrowego i wykorzystajmy rozproszony rejestr do przechowywania informacji o kluczach publicznych. W naszym przypadku rejestr nazywamy liniową bazą danych składającą się z pojedynczych rekordów (bloków) połączonych za pomocą technologii blockchain. Zamiast certyfikatu cyfrowego wprowadzimy pojęcie „powiadomienia”.
Jak będzie wyglądał proces przyjmowania, weryfikowania i anulowania powiadomień w proponowanym DPKI:
1. Każdy wnioskodawca samodzielnie składa wniosek o zgłoszenie, wypełniając formularz podczas rejestracji, po czym tworzy transakcję, która jest przechowywana w specjalistycznej puli.
2. Informacje o kluczu publicznym wraz z danymi właściciela i innymi metadanymi przechowywane są w rejestrze rozproszonym, a nie w certyfikacie cyfrowym, za którego wydanie w scentralizowanym PKI odpowiada urząd certyfikacji.
3. Weryfikacja autentyczności tożsamości wnioskodawcy następuje po fakcie wspólnym wysiłkiem społeczności użytkowników DPKI, a nie CR.
4. Jedynie właściciel takiego powiadomienia może zmienić status klucza publicznego.
5. Każdy może uzyskać dostęp do księgi rozproszonej i sprawdzić aktualny stan klucza publicznego.
Uwaga: Wspólnotowa weryfikacja tożsamości wnioskodawcy może na pierwszy rzut oka wydawać się niewiarygodna. Musimy jednak pamiętać, że obecnie wszyscy użytkownicy usług cyfrowych nieuchronnie pozostawiają cyfrowy ślad, a proces ten będzie nabierał tempa. Otwarte elektroniczne rejestry osób prawnych, mapy, digitalizacja zdjęć terenu, sieci społecznościowe – to wszystko są narzędzia ogólnodostępne. Są już z powodzeniem wykorzystywane podczas dochodzeń zarówno przez dziennikarzy, jak i organy ścigania. Wystarczy choćby przypomnieć śledztwa Bellingcat czy wspólnego zespołu dochodzeniowo-śledczego JIT, który bada okoliczności katastrofy malezyjskiego Boeinga.
Jak więc zdecentralizowana infrastruktura klucza publicznego działałaby w praktyce? Zatrzymajmy się na opisie samej technologii, którą my opatentowany w 2018 roku i słusznie uważamy to za nasze know-how.
Wyobraź sobie, że istnieje właściciel będący właścicielem wielu kluczy publicznych, a każdy klucz to określona transakcja przechowywana w rejestrze. Jak w przypadku braku urzędu certyfikacji można zrozumieć, że wszystkie klucze należą do tego konkretnego właściciela? Aby rozwiązać ten problem, tworzona jest transakcja zerowa, która zawiera informacje o właścicielu i jego portfelu (z którego pobierana jest prowizja za umieszczenie transakcji w rejestrze). Transakcja zerowa jest swego rodzaju „kotwicą”, do której będą dołączane kolejne transakcje z danymi o kluczach publicznych. Każda taka transakcja zawiera wyspecjalizowaną strukturę danych, czyli inaczej powiadomienie.
Powiadomienie to ustrukturyzowany zbiór danych składający się z pól funkcjonalnych i zawierający informację o kluczu publicznym właściciela, którego trwałość jest gwarantowana poprzez umieszczenie w jednym z powiązanych rekordów rejestru rozproszonego.
Następne logiczne pytanie brzmi: w jaki sposób powstaje transakcja zerowa? Transakcja zerowa – podobnie jak kolejne – jest agregacją sześciu pól danych. Podczas tworzenia transakcji zerowej bierze się pod uwagę parę kluczy portfela (klucz publiczny i sparowany klucz tajny). Ta para kluczy pojawia się w momencie rejestracji przez użytkownika swojego portfela, z której zostanie pobrana prowizja za umieszczenie w rejestrze transakcji zerowej, a następnie operacji z powiadomieniami.
Jak pokazano na rysunku, skrót klucza publicznego portfela jest generowany poprzez sekwencyjne zastosowanie funkcji skrótu SHA256 i RIPEMD160. Tutaj RIPEMD160 odpowiada za zwartą reprezentację danych, których szerokość nie przekracza 160 bitów. Jest to o tyle istotne, że rejestr nie jest tanią bazą danych. Sam klucz publiczny wpisywany jest w piątym polu. Pierwsze pole zawiera dane nawiązujące połączenie z poprzednią transakcją. Dla transakcji zerowej pole to nie zawiera niczego, co odróżnia ją od kolejnych transakcji. Drugie pole to dane umożliwiające sprawdzenie powiązania transakcji. Dla uproszczenia dane w pierwszym i drugim polu nazwiemy odpowiednio „link” i „check”. Zawartość tych pól jest generowana poprzez iteracyjne hashowanie, co pokazano poprzez połączenie drugiej i trzeciej transakcji na poniższym rysunku.
Dane z pierwszych pięciu pól są potwierdzane podpisem elektronicznym, który generowany jest przy użyciu tajnego klucza portfela.
To wszystko, transakcja zerowa zostaje wysłana do puli i po pomyślnej weryfikacji wpisana do rejestru. Teraz możesz „powiązać” z nim następujące transakcje. Zastanówmy się, jak powstają transakcje inne niż zero.
Pierwszą rzeczą, która prawdopodobnie rzuciła Ci się w oczy, jest obfitość par kluczy. Oprócz znanej już pary kluczy portfela stosowane są pary kluczy zwykłych i serwisowych.
Wszystko zaczęło się od zwykłego klucza publicznego. Klucz ten jest związany z różnymi procedurami i procesami zachodzącymi w świecie zewnętrznym (transakcje bankowe i inne, obieg dokumentów itp.). Na przykład tajny klucz ze zwykłej pary może służyć do generowania podpisów cyfrowych dla różnych dokumentów - zleceń płatniczych itp., A klucz publiczny może służyć do weryfikacji tego podpisu cyfrowego przy późniejszym wykonaniu tych instrukcji, pod warunkiem, że jest ważna.
Para usług jest wydawana zarejestrowanemu podmiotowi DPKI. Nazwa tej pary odpowiada jej przeznaczeniu. Należy pamiętać, że podczas tworzenia/sprawdzania transakcji zerowej nie są używane klucze serwisowe.
Wyjaśnijmy jeszcze raz cel kluczy:
- Klucze portfela służą do generowania/weryfikacji zarówno transakcji zerowej, jak i wszelkich innych transakcji o wartości innej niż null. Klucz prywatny portfela znany jest tylko właścicielowi portfela, który jest jednocześnie właścicielem wielu zwykłych kluczy publicznych.
- Zwykły klucz publiczny ma podobne przeznaczenie do klucza publicznego, dla którego wydawany jest certyfikat w scentralizowanej PKI.
- Para kluczy serwisowych należy do DPKI. Tajny klucz wydawany jest zarejestrowanym podmiotom i służy do generowania podpisów cyfrowych dla transakcji (z wyjątkiem transakcji zerowych). Publiczny służy do weryfikacji elektronicznego podpisu cyfrowego transakcji przed umieszczeniem jej w rejestrze.
Zatem istnieją dwie grupy kluczy. Do pierwszego zaliczają się klucze serwisowe i klucze portfela – mają one sens jedynie w kontekście DPKI. Do drugiej grupy zaliczają się zwykłe klucze – ich zakres może być różny i zależny od zadań aplikacji, w jakich są wykorzystywane. Jednocześnie DPKI zapewnia integralność i autentyczność zwykłych kluczy publicznych.
Uwaga: Para kluczy usługi może być znana różnym podmiotom DPKI. Na przykład może być taki sam dla wszystkich. Z tego właśnie powodu przy generowaniu podpisu każdej niezerowej transakcji wykorzystywane są dwa tajne klucze, z czego jeden jest kluczem do portfela – znany jest jedynie właścicielowi portfela, który jest jednocześnie właścicielem wielu zwykłych klucze publiczne. Wszystkie klawisze mają swoje znaczenie. Przykładowo zawsze można wykazać, że transakcja została wpisana do rejestru przez zarejestrowanego podmiotu DPKI, gdyż podpis został wygenerowany również na kluczu tajnych służb. I nie może być mowy o nadużyciach typu ataki DOS-owe, bo za każdą transakcję płaci właściciel.
Wszystkie transakcje następujące po jedynce są tworzone w podobny sposób: klucz publiczny (nie portfel, jak w przypadku transakcji zerowej, ale zwykła para kluczy) jest uruchamiany przez dwie funkcje mieszające SHA256 i RIPEMD160. W ten sposób powstają dane trzeciego pola. Czwarte pole zawiera informacje towarzyszące (np. informacje o aktualnym statusie, dacie wygaśnięcia, znaczniku czasu, identyfikatorach zastosowanych algorytmów kryptograficznych itp.). Piąte pole zawiera klucz publiczny z pary kluczy usługi. Za jego pomocą zostanie następnie sprawdzony podpis cyfrowy, dzięki czemu zostanie on zreplikowany. Uzasadnijmy potrzebę takiego podejścia.
Przypomnijmy, że transakcja jest zapisywana w puli i tam przechowywana do czasu jej przetworzenia. Przechowywanie w puli wiąże się z pewnym ryzykiem – dane transakcyjne mogą zostać sfałszowane. Właściciel potwierdza dane transakcyjne elektronicznym podpisem cyfrowym. Klucz publiczny służący do weryfikacji tego podpisu cyfrowego jest wyraźnie wskazany w jednym z pól transakcji, a następnie jest wprowadzany do rejestru. Specyfika przetwarzania transakcji polega na tym, że atakujący może zmienić dane według własnego uznania, a następnie zweryfikować je za pomocą swojego tajnego klucza i wskazać sparowany klucz publiczny w celu weryfikacji podpisu cyfrowego w transakcji. Jeśli autentyczność i integralność zostanie zapewniona wyłącznie poprzez podpis cyfrowy, wówczas takie fałszerstwo pozostanie niezauważone. Jeśli jednak oprócz podpisu cyfrowego istnieje dodatkowy mechanizm zapewniający zarówno archiwizację, jak i trwałość przechowywanych informacji, wówczas fałszerstwo można wykryć. Aby to zrobić, wystarczy wpisać do rejestru prawdziwy klucz publiczny właściciela. Wyjaśnijmy, jak to działa.
Pozwól atakującemu sfałszować dane transakcji. Z punktu widzenia kluczy i podpisów cyfrowych możliwe są następujące opcje:
1. Osoba atakująca umieszcza w transakcji swój klucz publiczny, natomiast podpis cyfrowy właściciela pozostaje niezmieniony.
2. Osoba atakująca tworzy podpis cyfrowy na swoim kluczu prywatnym, ale pozostawia klucz publiczny właściciela bez zmian.
3. Osoba atakująca tworzy podpis cyfrowy na swoim kluczu prywatnym i umieszcza w transakcji sparowany klucz publiczny.
Oczywiście opcje 1 i 2 są bez znaczenia, ponieważ zawsze zostaną wykryte podczas weryfikacji podpisu cyfrowego. Tylko opcja 3 ma sens i jeśli atakujący złoży podpis cyfrowy na swoim własnym tajnym kluczu, wówczas jest zmuszony zapisać w transakcji sparowany klucz publiczny, inny niż klucz publiczny właściciela. Tylko w ten sposób atakujący może narzucić fałszywe dane.
Załóżmy, że właściciel ma ustaloną parę kluczy – prywatny i publiczny. Niech dane zostaną poświadczone podpisem cyfrowym przy użyciu tajnego klucza z tej pary, a klucz publiczny zostanie wskazany w transakcji. Załóżmy też, że ten klucz publiczny został już wcześniej wpisany do rejestru i rzetelnie zweryfikowano jego autentyczność. Wówczas o fałszerstwie będzie świadczyć fakt, że klucz publiczny z transakcji nie odpowiada kluczowi publicznemu z rejestru.
Podsumujmy. Podczas przetwarzania pierwszych danych transakcyjnych właściciela konieczna jest weryfikacja autentyczności klucza publicznego wpisanego do rejestru. Aby to zrobić, odczytaj klucz z rejestru i porównaj go z prawdziwym kluczem publicznym właściciela w obrębie obszaru bezpieczeństwa (obszar względnej nietykalności). Jeżeli autentyczność klucza zostanie potwierdzona i zapewniona zostanie jego trwałość po umieszczeniu, wówczas autentyczność klucza z kolejnej transakcji można łatwo potwierdzić/zaprzeczyć, porównując go z kluczem z rejestru. Innymi słowy, klucz z rejestru służy jako próbka referencyjna. Wszystkie pozostałe transakcje właściciela są przetwarzane w podobny sposób.
Transakcja jest potwierdzona elektronicznym podpisem cyfrowym – tutaj potrzebne są tajne klucze, a nie jeden, ale dwa na raz – klucz serwisowy i klucz do portfela. Dzięki zastosowaniu dwóch tajnych kluczy zapewniony jest niezbędny poziom bezpieczeństwa - wszak tajny klucz usługi może być znany innym użytkownikom, natomiast tajny klucz portfela znany jest tylko właścicielowi zwykłej pary kluczy. Taki podpis dwukluczowy nazwaliśmy „skonsolidowanym” podpisem cyfrowym.
Weryfikacja transakcji o wartości innej niż null odbywa się przy użyciu dwóch kluczy publicznych: portfela i klucza usługi. Proces weryfikacji można podzielić na dwa główne etapy: pierwszy to sprawdzenie skrótu klucza publicznego portfela, drugi to sprawdzenie elektronicznego podpisu cyfrowego transakcji, tego samego skonsolidowanego, który został utworzony przy użyciu dwóch tajnych kluczy ( portfel i serwis). Jeżeli ważność podpisu cyfrowego zostanie potwierdzona, wówczas po dodatkowej weryfikacji transakcja zostaje wpisana do rejestru.
Może pojawić się logiczne pytanie: jak sprawdzić, czy transakcja należy do konkretnego łańcucha z „korzeniem” w postaci transakcji zerowej? W tym celu proces weryfikacji uzupełniany jest o jeszcze jeden etap – sprawdzenie łączności. Tutaj będą nam potrzebne dane z dwóch pierwszych pól, które do tej pory ignorowaliśmy.
Wyobraźmy sobie, że musimy sprawdzić, czy transakcja nr 3 faktycznie następuje po transakcji nr 2. W tym celu, stosując kombinowaną metodę mieszającą, obliczana jest wartość funkcji skrótu dla danych z trzeciego, czwartego i piątego pola transakcji nr 2. Następnie następuje konkatenacja danych z pierwszego pola transakcji nr 3 oraz otrzymanej wcześniej połączonej wartości funkcji skrótu dla danych z trzeciego, czwartego i piątego pola transakcji nr 2. Wszystko to jest również uruchamiane przez dwie funkcje skrótu SHA256 i RIPEMD160. Jeżeli otrzymana wartość jest zgodna z danymi w drugim polu transakcji nr 2, wówczas weryfikacja zostaje zaliczona i połączenie zostaje potwierdzone. Lepiej widać to na poniższych rysunkach.
W ogólnym ujęciu technologia generowania i wprowadzania zgłoszenia do rejestru wygląda właśnie tak. Wizualną ilustrację procesu tworzenia łańcucha powiadomień przedstawia poniższy rysunek:
W tym tekście nie będziemy rozwodzić się nad szczegółami, które niewątpliwie istnieją, a powrócimy do omówienia samej idei zdecentralizowanej infrastruktury klucza publicznego.
Ponieważ zatem wnioskodawca sam składa wniosek o rejestrację powiadomień, które są przechowywane nie w bazie danych urzędu certyfikacji, ale w rejestrze, należy wziąć pod uwagę główne elementy architektoniczne DPKI:
1. Rejestr ważnych zgłoszeń (RDN).
2. Rejestr wycofanych zgłoszeń (RON).
3. Rejestr zawieszonych powiadomień (RPN).
Informacje o kluczach publicznych przechowywane są w RDN/RON/RPN w postaci wartości funkcji skrótu. Warto także zaznaczyć, że mogą to być albo różne rejestry, albo różne łańcuchy, albo nawet jeden łańcuch w ramach jednego rejestru, gdy do rejestru wprowadzana jest informacja o statusie zwykłego klucza publicznego (unieważnienie, zawieszenie itp.). czwarte pole struktury danych w postaci odpowiedniej wartości kodu. Istnieje wiele różnych opcji architektonicznej implementacji DPKI, a wybór jednego lub drugiego zależy od wielu czynników, na przykład takich kryteriów optymalizacji, jak koszt pamięci długoterminowej do przechowywania kluczy publicznych itp.
Tym samym DPKI może okazać się jeśli nie prostsze, to przynajmniej porównywalne z rozwiązaniem scentralizowanym pod względem złożoności architektonicznej.
Pozostaje główne pytanie - Który rejestr jest odpowiedni do wdrożenia technologii?
Głównym wymaganiem wobec rejestru jest możliwość generowania transakcji dowolnego typu. Najbardziej znanym przykładem księgi głównej jest sieć Bitcoin. Jednak przy wdrażaniu opisanej powyżej technologii pojawiają się pewne trudności: ograniczenia istniejącego języka skryptowego, brak niezbędnych mechanizmów przetwarzania dowolnych zestawów danych, metody generowania transakcji dowolnego typu i wiele więcej.
W ENCRY próbowaliśmy rozwiązać sformułowane powyżej problemy i opracowaliśmy rejestr, który naszym zdaniem ma szereg zalet, a mianowicie:
- obsługuje kilka rodzajów transakcji: może zarówno wymieniać aktywa (czyli dokonywać transakcji finansowych), jak i tworzyć transakcje o dowolnej strukturze,
- programiści mają dostęp do autorskiego języka programowania PrismLang, który zapewnia niezbędną elastyczność przy rozwiązywaniu różnorodnych problemów technologicznych,
- zapewniony jest mechanizm przetwarzania dowolnych zbiorów danych.
Jeśli przyjmiemy podejście uproszczone, wówczas ma miejsce następująca sekwencja działań:
- Wnioskodawca rejestruje się w DPKI i otrzymuje portfel cyfrowy. Adres portfela to wartość skrótu klucza publicznego portfela. Klucz prywatny portfela znany jest tylko wnioskodawcy.
- Zarejestrowany podmiot otrzymuje dostęp do tajnego klucza usługi.
- Podmiot generuje transakcję zerową i weryfikuje ją podpisem cyfrowym przy użyciu tajnego klucza portfela.
- W przypadku zawarcia transakcji innej niż zero, jest ona potwierdzana elektronicznym podpisem cyfrowym przy użyciu dwóch tajnych kluczy: portfelowego i serwisowego.
- Podmiot przesyła transakcję do puli.
- Węzeł sieci ENCRY odczytuje transakcję z puli i sprawdza podpis cyfrowy oraz łączność transakcji.
- Jeżeli podpis cyfrowy jest ważny i połączenie zostanie potwierdzone, przygotowuje transakcję do wpisu do rejestru.
W tym przypadku rejestr pełni rolę rozproszonej bazy danych, w której przechowywane są informacje o ważnych, anulowanych i zawieszonych powiadomieniach.
Oczywiście decentralizacja nie jest panaceum. Zasadniczy problem pierwotnego uwierzytelnienia użytkownika nigdzie nie znika: jeśli obecnie weryfikację wnioskodawcy przeprowadza CR, to w DPKI proponuje się delegowanie weryfikacji członkom społeczności i wykorzystanie motywacji finansowej do pobudzenia aktywności. Technologia weryfikacji typu open source jest dobrze znana. Skuteczność takiej weryfikacji została potwierdzona w praktyce. Przypomnijmy jeszcze raz kilka głośnych dochodzeń przeprowadzonych przez publikację internetową Bellingcat.
Ale ogólnie rzecz biorąc, wyłania się następujący obraz: DPKI to szansa na skorygowanie, jeśli nie wszystkich, to wielu niedociągnięć scentralizowanej infrastruktury PKI.
Subskrybuj nasz Habrablog, planujemy nadal aktywnie omawiać nasze badania i rozwój oraz śledzić , jeśli nie chcesz przegapić innych aktualności na temat projektów ENCRY.
Źródło: www.habr.com