Podpis elektroniczny z mediatorem

Z testwiki
Przejdź do nawigacji Przejdź do wyszukiwania

Podpis z mediatorem (właściwie podpis w schemacie z mediatorem) – podpis elektroniczny, którego złożenie wymaga udziału dodatkowej strony nazwanej mediatorem.

Zasady działania

Schemat podpisów z mediatorem zaproponowany został w pracy[1] jako metoda natychmiastowego blokowania możliwości składania podpisu przez wskazanych użytkowników. Blokada może być:

  • trwała: w przypadku utraty przez użytkownika urządzenia zawierającego klucz do składania podpisu,
  • tymczasowa: na przykład na wniosek użytkownika tracącego czasowo kontrolę nad urządzeniem do składania podpisu z powodu konieczności poddania się operacji chirurgicznej,
  • okresowa: stosowana np. wobec pracowników korporacji lub urzędników poza godzinami ich pracy.

W podstawowym schemacie złożenie podpisu składa się z dwóch faz:

  • wygenerowania tzw. pre-podpisu po stronie użytkownika,
  • finalizacji pre-podpisu do pełnego podpisu (lub krótko: finalizacji podpisu) dokonywanej po stronie centralnego serwera.

Efektem ubocznym zaangażowania centralnego serwera w proces tworzenia podpisu jest możliwość elastycznego zarządzania przez użytkownika atrybutami podpisu, weryfikowanymi przez centralny serwer w trakcie finalizacji podpisu[2]. Wykorzystując centralny serwer można także zaimplementować mechanizmy zwiększające bezpieczeństwo schematu podpisów[3].

Schemat podpisów z mediatorem zaproponowano początkowo[1][4] w wersji dla algorytmu RSA (wersję tę oznacza się czasem jako mRSA – od mediated RSA). Zostały również przedstawione inne schematy bazujące na podobnych zasadach[5][6].

Schemat z mediatorem można traktować jako szczególny przypadek generowania podpisów przez dwie strony protokołu: żadna ze stron protokołu nie może wygenerować podpisu samodzielnie, udział obu jest niezbędny do złożenia podpisu[7]; w schemacie z mediatorem jedna ze stron jest wyróżniona – odgrywa rolę egzekutora i strażnika polityk bezpieczeństwa.

Korzyści

Podpis z mediatorem jest generacją rozwiązań podpisu elektronicznego, której głównymi atutami są:

  • Rozdzielenie klucza podpisu pomiędzy dwie strony (wyciek klucza od jednej ze stron nie pozwala jeszcze na fałszowanie podpisów)
  • Wprowadzenie możliwości zarządzania podpisami i zwiększenie kontroli użytkownika nad wykonywanymi czynnościami kryptograficznymi[2]
  • Umożliwienie definiowania dodatkowych atrybutów wymaganych do spełnienia w momencie finalizacji podpisu
  • Umożliwienie wykonywania podpisu elektronicznego on-line wraz z natychmiastowym potwierdzeniem jego ważności. W efekcie uzyskuje się istotne uproszczenie procesu weryfikacji podpisu elektronicznego po stronie odbiorcy podpisanego dokumentu.

Koncepcja podpisu z mediatorem dla schematu RSA (mRSA) jest rozwinięciem standardowego PKI o nowe funkcjonalności związane z pełnym wykorzystaniem możliwości jakie daje globalna sieć Internet. Przede wszystkim chodzi o połączenie on-line do centralnego serwera, który odpowiedzialny jest za weryfikację nie tylko ważności i statusu certyfikatu w czasie składania podpisu, ale również sprawdzenie dodatkowych atrybutów związanych ze złożonym podpisem. Dzięki takiemu podejściu, całkowitemu odwróceniu ulega obciążenie związane z walidacją podpisu. W standardowym PKI to osoba weryfikująca podpis była obarczana koniecznością dokonania wielu sprawdzeń, dotyczących ważności certyfikatu, podpisu oraz czasu wykonania operacji. Implikowało to wykonywanie wielu takich tych samych operacji on-line (znakowanie czasem, pobranie listy CRL lub uzyskanie odpowiedzi OCSP) za każdym razem, gdy podpis był weryfikowany. Jeśli podpisany dokument otrzyma 10 osób, to wszystkie operacje muszą być wykonane również 10 razy, aby każda z osób miała pewność co do ważności podpisu. Dzięki zastosowaniu koncepcji podpisu z mediatorem, weryfikacja ważności podpisu realizowana jest już w procesie finalizacji podpisu przez serwer centralny. Osoby dokonujące sprawdzenia (ufające centrum finalizacji) muszą jedynie sprawdzić integralność podpisu, poddając go matematycznej weryfikacji off-line: matematyczna weryfikacja podpisu kluczem domniemanego podpisującego przebiega w przypadku mRSA dokładnie tak samo, jak w przypadku zwykłego RSA.

Istotnym udogodnieniem jest zagwarantowanie czasu złożenia podpisu, co ma fundamentalne znaczenie w przypadku dokonywania wszystkich transakcji elektronicznych. Realizując podpis w schemacie z mediatorem, to system centralny, któremu ufa osoba składająca podpis, zapewnia poprawność czasu wykonania operacji. Osoba weryfikująca podpis również ma pewność, że podpis został złożony w czasie, który był zgodny z zaufanym czasem serwera finalizującego podpis.

Minusy

  • Większe skomplikowanie fazy generowania kluczy i fazy składania podpisu.
  • Wydłużenie procesu podpisywania (zależne od wydajności serwera mediatora i stopnia jego obciążenia).
  • Wymagane jest zaufanie do mediatora. Stopień wymaganego zaufania można zredukować kosztem zwiększenia złożoności architektury systemu[8].
  • Podpis w obecnych uregulowaniach prawnych nie może być stosowany jako podpis kwalifikowany.
  • Schemat obecnie na etapie pomysłu teoretycznego: brak dojrzałych rozwiązań komercyjnych lub o otwartym kodzie źródłowym.

Mechanizmy podpisu w schemacie z mediatorem

Schemat podpisu z mediatorem przedstawimy na przykładzie algorytmu mRSA. Zakładamy poniżej, że w schemacie mRSA klucze generowane są w scentralizowany sposób przez zaufaną trzecią stronę, tzw. dilera kluczy. Innym podejściem jest generowanie kluczy w sposób rozproszony[9][10] tak, że żaden z wykonawców algorytmu generowania kluczy nie zna klucza prywatnego (lub równoważnie, nie zna rozkładu modułu RSA na czynniki[11]).

Przypomnijmy, że dla zwykłego RSA mamy następujące parametry przypisane do użytkownika u:

  • klucz publiczny składający się z pary liczb (eu,nu), gdzie
    • nu jest iloczynem dwóch dużych liczb pierwszych pu,qu (rozkład nu na czynniki pu,qu musi pozostać tajny[11]),
    • eu jest względnie pierwsze z φ(nu)=(pu1)(qu1),
  • klucz prywatny du=eu1modφ(nu).

Klucz publiczny jest kluczem weryfikacji podpisu, zapisanym w certyfikacie Cu użytkownika u. Klucz prywatny służy do generowania podpisu.

Generowanie podpisu RSA ma wówczas następujący przebieg (poniższy zapis jest bardzo uproszczony, por. np. format XAdES[12] oraz padding stosowany w przypadku podpisów RSA[13]):

  • użytkownik u, używając odpornej na kolizję funkcji skrótu h oblicza skrót h(m) podpisywanej wiadomości m,
  • mając h(m) użytkownik u oblicza podpis s jako
s=(h(m))dumodnu.

Matematyczna weryfikacja domniemanego podpisu s~ wykonanego przez użytkownika u na wiadomości m polega na pobraniu klucza publicznego tego użytkownika z certyfikatu Cu oraz na zweryfikowaniu, czy zachodzi równość

(s~)eu=h(m)modnu.

Poza matematyczną weryfikacją podpisu należy jeszcze zweryfikować prawdziwość certyfikatu Cu (por. budowanie ścieżki certyfikatów[14]) oraz sprawdzić, czy certyfikat ten nie został odwołany z powodu np. zgubienia przez użytkownika u karty z kluczem prywatnym du (por. mechanizmy CRL, OCSP).

Generowanie kluczy w schemacie mRSA

Protokół generowania kluczy użytkownika u przebiega następująco:

  1. Karta w procesie personalizacji komunikuje się z dilerem kluczy przekazując mu swój identyfikator i inicjując procedurę generowania kluczy.
  2. Diler generuje klucz publiczny (eu,nu) oraz klucz prywatny du. Klucz prywatny nie będzie bezpośrednio wykorzystywany do składania podpisu. Zostanie podzielony pomiędzy kartę i mediatora. Karta i mediator jedynie współdziałając będą mogli złożyć weryfikowalny podpis.
  3. Diler przekazuje mediatorowi identyfikator karty oraz długość modułu nu w bitach.
  4. Mediator generuje swój unikatowy tajny składnik du,2 klucza prywatnego dla karty o przekazanym od dilera identyfikatorze.
  5. Mediator przekazuje swój składnik klucza prywatnego dilerowi (możliwe są różne warianty tego kroku, np. wykorzystanie kryptosystemu Paillier’a[15] i późniejsze dokonywanie przez dilera obliczeń na danych zaszyfrowanych).
  6. Diler oblicza składnik klucza prywatnego karty du,1 na podstawie wartości wygenerowanej przez siebie i składnika uzyskanego od mediatora: du,1=dudu,2modφ(nu)
  7. Diler przekazuje do karty wyliczony dla niej składnik prywatny du,1 oraz klucz publiczny (eu,nu) wraz z jego certyfikatem Cu (zakładamy, że identyfikator karty jest zapisany w certyfikacie Cu).

Zauważmy, że tak mediator, jak i karta nie znają wykładnika du, oraz rozkładu modułu nu na czynniki.

Podpisywanie wiadomości w schemacie mRSA

Protokół składania podpisu przez użytkownika u przebiega następująco:

  1. Karta nawiązuje bezpieczne połączenie z mediatorem (bezpieczny kanał komunikacyjny).
  2. Użytkownik przy użyciu swojej karty (zapisanego na karcie prywatnego składnika du,1 klucza do podpisu) składa tzw. podpis częściowy pod wiadomością m (wykonuje algorytm pre-podpisu): oblicza skrót h(m) oraz pre-podpis s1=(h(m))du,1modnu.
  3. Użytkownik wysyła do mediatora pakiet zawierający następujące dane: skrót h(m) podpisywanej wiadomości, podpis częściowy s1, certyfikat Cu. Alternatywnie: certyfikat klucza publicznego może być ustalony przez system mediatora na podstawie przeprowadzanego wcześniej protokołu uwierzytelniania karty wobec systemu mediatora.
  4. Jeżeli karta nie została wcześniej zablokowana, oraz jeżeli nie minął termin jej ważności, mediator wykonuje algorytm finalizujący: s=s1(h(m))du,2modnu. Po jego wykonaniu mediator przeprowadza procedurę weryfikacji sfinalizowanego podpisu dla wartości skrótu podpisywanej wiadomości: jeśli do wykonania podpisu częściowego s1 rzeczywiście użyto składnika klucza prywatnego przechowywanego przez kartę, to sfinalizowany podpis jest poprawny. Ponadto poza poprawnością podpisu w sensie matematycznym, mediator może zweryfikować zgodność otrzymanych danych z polityką podpisu[16], z polityką certyfikacji[17], oraz z ewentualnymi wcześniejszymi decyzjami użytkownika[2].
  5. Mediator wysyła obliczony podpis s do użytkownika u.
  6. Następuje zakończenie sesji pomiędzy kartą a mediatorem.
  7. Użytkownik weryfikuje podpis.

Weryfikacja podpisu przez odbiorcę dokumentu

Weryfikacja podpisu mRSA wykonywana jest tak samo jak dla schematu RSA, jednak użytkownik nie musi już sprawdzać, czy certyfikat podpisującego nie został odwołany – sprawdzenia tego dokonał mediator podczas finalizacji podpisu.

Przypisy

Szablon:Przypisy