Mediated RSA i Identity-Based Cryptography

Obecnie stosowane mechanizmy PKI sprowadzają się zazwyczaj do wystawienia pracownikom odpowiednich certyfikatów. Zazwyczaj wykorzystuje się taki certyfikat do logowania do firmowych systemów; dużo rzadziej - do składania podpisu lub szyfrowania.

Ze względu na ograniczoną popularność elektronicznego podpisywania dokumentów na rynku podpisu elektronicznego do niedawna panowała stagnacja. Wraz z wprowadzeniem ustawy o podpisie elektronicznym i możliwości przesyłania podpisanych elektronicznie dokumentów do polskich urzędów sytuacja ulega jednak powoli zmianie. Dodatkowo na uproszczenie i upowszechnienie e-podpisu może pozytywnie wpłynąć, zapowiadana już od kilku lat, nowelizacja tej ustawy. W tej sytuacji coraz częściej biznes zaczyna interesować się tym zagadnieniem.

W przypadku aktualnie stosowanych algorytmów e-podpisu powstaje problem weryfikacji, czy wykorzystywany certyfikat osoby podpisującej jest wiarygodny i nie został unieważniony. Teoretycznie służą do tego usługi takie, jak OCSP, DVCS czy listy CRL; w praktyce jednak zdarza się, że odbiorca podpisanego dokumentu pomija taką weryfikację. Dodatkowo istnieje problem określenia czasu złożenia podpisu - weryfikacja może bowiem nastąpić już po wygaśnięciu certyfikatu i dać wynik negatywny, pomimo, że samo złożenie podpisu nastąpiło jeszcze w okresie jego ważności. Ten problem z kolei stara się rozwiązać z wykorzystaniem usługi znacznika czasu.

W przypadku komunikacji między różnymi podmiotami pojawia się dodatkowo konieczność wzajemnego zaufania między odpowiednimi korporacyjnymi urzędami certyfikacji i zapewnienia kanałów komunikacyjnych, umożliwiających pobranie list CRL czy skorzystanie z OCSP.

W ramach prac nad wskazanymi problemami opracowano propozycję architektury SEMA (SEcurity Mediator Architecture) i odpowiednie algorytmy podpisu elektronicznego. Niewątpliwą zaletą SEMA jest jej zgodność z dotychczasową infrastrukturą PKI - wykorzystywany, zmodyfikowany algorytm RSA jest kompatybilny ze swoją pierwotną wersją, można też wykorzystywać certyfikaty X.509 i powiązane z nimi usługi.

SEMA zostało opracowane z myślą o środowisku korporacyjnym. Idea zakłada, że do złożenia podpisu niezbędny jest udział zarówno użytkownika, jak i tzw. mediatora bezpieczeństwa (Security Mediator). Klucz prywatny dzielony jest na dwie części: jedną z nich dysponuje użytkownik, a drugą mediator. W momencie składania podpisu użytkownik przesyła do mediatora skrót danych do podpisania. Mediator sprawdza, czy certyfikat użytkownika jest ważny (a więc czy na przykład pracownik nie został zwolniony); jeśli tak, to generuje podpis z wykorzystaniem swojej części klucza prywatnego. Następnie użytkownik tak otrzymany podpis przekształca z wykorzystaniem swojej części klucza - i w ten sposób uzyskuje podpis RSA pod odpowiednim dokumentem.

Omówiony schemat ma następujące cechy charakterystyczne:
1. Uniemożliwia złożenie podpisu z wykorzystaniem nieważnego certyfikatu (przy założeniu, że mediator jest uczciwy);
2. Eliminuje konieczność korzystania z usług typu OCSP czy list CRL (choć mogą one być nadal wykorzystywane jako dodatkowy mechanizm weryfikacyjny);
3. Jest kompatybilny z aktualnie wykorzystywaną infrastrukturą PKI;
4. Można ograniczyć możliwość złożenia podpisu tylko do osób znajdujących się w zasięgu infrastruktury mediatora (a więc np. uniemożliwić składanie podpisu poza siedzibą firmy).

Powyższe cechy mogą wyglądać interesująco, jednakże moim zdaniem ich praktyczne zastosowanie nie jest zbyt duże. W oparciu o te podstawy można jednak budować inne, znacznie ciekawsze mechanizmy. Pisze o nich m.in. Xuhua Ding i Gene Tsudik w artykule Simple Identity-Based Cryptography with Mediated RSA. Opisana w artykule metoda kryptografii opartej na tożsamości (Identity-Based Mediated RSA, IB mRSA) pozwala na uzyskanie klucza publicznego wykorzystujących ją podmiotów na podstawie ich danych, na przykład - adresu e-mail. Dodatkowo wykorzystywany jest, publicznie dostępny i jednakowy dla wszystkich użytkowników, moduł przekształcenia RSA n (co samo w sobie jest niebezpieczne, jeśli intruz uzyskałby parę klucza prywatnego i publicznego - ale ponieważ klucze prywatne są rozdzielone między użytkownikiem a mediatorem, musiałby on włamać się do mediatora). Tak skonstruowany system pozwala na wysłanie zaszyfrowanej poczty do każdego korzystającego z niego podmiotu, bez konieczności uzyskania jego certyfikatu (co obecnie jest dość kłopotliwe).

Podsumowując, wskazane algorytmy stanowią miłą ciekawostkę, jednakże moim zdaniem związane są ze zbytnim ryzykiem. Można wprawdzie wyobrazić sobie mediatora zaimplementowanego w module HSM, ale podchodzę do takich rozwiązań z dość znacznym sceptycyzmem (choćby ze względu na doniesienia o złamaniu RFID, co każe zachować sceptycyzm w przypadku rozwiązań nawet znanych producentów). W opisanej formie nie rozwiązują zatem istniejących problemów współczesnej kryptografii; mogą jednak stanowić ciekawe podwaliny dla dalszych prac w tym zakresie.

Dodaj komentarz

Markdown

  • Quick Tips:
    • Two or more spaces at a line's end = Line break
    • Double returns = Paragraph
    • *Single asterisks* or _single underscores_ = Emphasis
    • **Double** or __double__ = Strong
    • This is [a link](http://the.link.example.com "The optional title text")
    For complete details on the Markdown syntax, see the Markdown documentation and Markdown Extra documentation for tables, footnotes, and more.

Filtered HTML

  • Adresy internetowe są automatycznie zamieniane w odnośniki, które można kliknąć.
  • Dozwolone znaczniki HTML: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd> <small>
  • Znaki końca linii i akapitu dodawane są automatycznie.

Plain text

  • Znaczniki HTML niedozwolone.
  • Adresy internetowe są automatycznie zamieniane w odnośniki, które można kliknąć.
  • Znaki końca linii i akapitu dodawane są automatycznie.
CAPTCHA
Proszę, przepisz napis z obrazka do okienka poniżej. Sprawdzamy w ten sposób, czy nie jesteś aby robotem. Wielkość znaków ma znaczenie!
By submitting this form, you accept the Mollom privacy policy.