Podpis elektroniczny z mediatorem

Z Wikipedii, wolnej encyklopedii

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[edytuj | edytuj kod]

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[edytuj | edytuj kod]

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[edytuj | edytuj kod]

  • 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[edytuj | edytuj kod]

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

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

Klucz publiczny jest kluczem weryfikacji podpisu, zapisanym w certyfikacie użytkownika 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żywając odpornej na kolizję funkcji skrótu oblicza skrót podpisywanej wiadomości
  • mając użytkownik oblicza podpis jako

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

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

Generowanie kluczy w schemacie mRSA[edytuj | edytuj kod]

Protokół generowania kluczy użytkownika 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 oraz klucz prywatny 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 w bitach.
  4. Mediator generuje swój unikatowy tajny składnik 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 na podstawie wartości wygenerowanej przez siebie i składnika uzyskanego od mediatora:
  7. Diler przekazuje do karty wyliczony dla niej składnik prywatny oraz klucz publiczny wraz z jego certyfikatem (zakładamy, że identyfikator karty jest zapisany w certyfikacie ).

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

Podpisywanie wiadomości w schemacie mRSA[edytuj | edytuj kod]

Protokół składania podpisu przez użytkownika 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 klucza do podpisu) składa tzw. podpis częściowy pod wiadomością (wykonuje algorytm pre-podpisu): oblicza skrót oraz pre-podpis
  3. Użytkownik wysyła do mediatora pakiet zawierający następujące dane: skrót podpisywanej wiadomości, podpis częściowy certyfikat 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: Po jego wykonaniu mediator przeprowadza procedurę weryfikacji sfinalizowanego podpisu dla wartości skrótu podpisywanej wiadomości: jeśli do wykonania podpisu częściowego 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 do użytkownika
  6. Następuje zakończenie sesji pomiędzy kartą a mediatorem.
  7. Użytkownik weryfikuje podpis.

Weryfikacja podpisu przez odbiorcę dokumentu[edytuj | edytuj kod]

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[edytuj | edytuj kod]

  1. a b Dan Boneh, Xuhua Ding, Gene Tsudik, Chi Ming Wong. A method for fast revocation of public key certificates and security capabilities. „SSYM’01: Proceedings of the 10th conference on USENIX Security Symposium”, s. 297–308, 2001. Berkeley, CA, USA: USENIX Association. 
  2. a b c Michał Tabor: Electronic signature – easy as card transactions. W: Polskie Karty 2011 almanach. Medien Service Sławomir Cieśliński, s. 331–335. ISBN 978-83-924201-1-8.}
  3. Przemysław Błaśkiewicz, Przemysław Kubiak, Mirosław Kutyłowski. Digital signatures for e-government – a long-term security architecture. „China Communications”. 7(6), s. 64–70, December 2010. ISSN 1673-5447. 
  4. Dan Boneh, Xuhua Ding, Gene Tsudik. Fine-grained control of security capabilities. „ACM Trans. Internet Techn.”. 4(1), s. 60–82, 2004. 
  5. Chen Yang, Wen ping Ma, Xin mei Wang. Secure mediated certificateless signature scheme. „The Journal of China Universities of Posts and Telecommunications”. 14(2), s. 75–78, 2007. 
  6. Xuhua Ding, Gene Tsudik, Shouhuai Xu. Leak-free mediated group signatures. „J. Comput. Secur.”. 17 (4), s. 489–514, December 2009. IOS Press. 
  7. Philip D. MacKenzie, Michael K. Reiter: Two-party generation of DSA signatures. W: Joe Kilian: CRYPTO. T. 2139. Springer, 2001, s. 137–154, seria: Lecture Notes in Computer Science.
  8. Przemysław Kubiak: Algorithmic background - perspectives of PKI 2.0 (trust reduction to system components). slides from PKI 2.0 Partner Workshop, January 20, 2011, Wrocław.
  9. Ivan Damgård, Gert Læssøe Mikkelsen: Efficient, Robust and Constant-Round Distributed RSA Key Generation. W: Daniele Micciancio: TCC 2010: Proceedings of the 7th Theory of Cryptography Conference. T. 5978. Springer, 2010, s. 183–200, seria: Lecture Notes in Computer Science.
  10. Niv Gilboa: Two Party RSA Key Generation. W: Michael J. Wiener: CRYPTO 1999: Proceedings of the 19th Annual International Cryptology Conference. T. 1666. Springer, s. 116–129, seria: Lecture Notes in Computer Science.
  11. a b Jean-Sébastien Coron, Alexander May. Deterministic Polynomial-Time Equivalence of Computing the RSA Secret Key and Factoring. „J. Cryptology”. 20(1), s. 39–50, 2007. 
  12. Electronic Signatures and Infrastructures (ESI): XML Advanced Electronic Signatures (XAdES), ETSI TS 101 903 v1.4.2, European Telecommunications Standards Institute, 2010.
  13. PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories, 2002.
  14. Part 5: Certificate Path Validation. W: T7 & TELE TRUST: Common PKI Specifications for Interoperable Applications. January 2009.
  15. Pascal Paillier: Public-Key Cryptosystems Based on Composite Degree Residuosity Classes. W: Jacques Stern: EUROCRYPT’99, Proceedings of International Conference on the Theory and Application of Cryptographic Techniques. Springer, 1999, s. 223–238, seria: Lecture Notes in Computer Science.
  16. Signature Policies Report, TR 102 041 v1.1.1, European Telecommunications Standards Institute, 2002.
  17. Sharon Boeyen, Certificate Policies and Certification Practice Statements, Entrust White Paper, 1997.