Rozwiązanie podpisu cyfrowego w COIG


Wstęp

Analiza SWAT

Generalnie mamy do czynienia z takimi "show stopperami":

1. Wymagania prawne odnośnie podpisu i wymaganej od aplikacji deklaracji zgodności - nie do końca je znamy, są one dostępne na stronach Sigillum i SputnikSoftware, ale nie wiemy co tak naprawdę jest ważne.
2. Problem uzyskania zgodności z ustawą...
3. Proces instalowania podpisu cyfrowego u klienta jest pracochłonny i wymaga zainstalowanie oprogramowania dodatkowego oraz poprawnego skonfigurowania w systemie. Być może nawet pomocy technicznej np. coś w rodzaju naszego "maximo"
4. Stosowanie klienta Cisco VPN skutecznie wyklucza sprawdzenie ważności certyfikaty z listą CRL (VPN wyłącza dostęp do witryny świadczącej usługi sprawdzenia CRL)
5. Przeglądarki internetowe nie potrafią w prosty sposób (na poziome zwykłego użytkownika) dostać się do zasobów lokalnych komputera klienckiego
6. Poza platformą MS Windows brak powszechnego wsparcia implementacji procedur kryptograficznych w postaci zintegrowanych, gotowych do wykorzystania z poziomu systemu operacyjnego a nie wywołań funkcji bibliotecznych komponentów, które uzyskały aprobatę w oczach ustawodawców (mających certyfikaty). Dlatego OpenSSL mimo, że jest wspaniałą biblioteką nie jest gotowa do obsługi.
7. Brak dostępu do sterowników obsługujących czytniki smart card na naszym rynku w środowisku Unix/Linux (producenci tychże czytników dostarczają sterowników wyłącznie pod Windows)
8. Brak certyfikatu do podpisywania kodu własnego oprogramowania udostępnianego publicznie klientom (musimy zakupić taki certyfikat aby zwiększyć wiarygodność)
9. Jak i co podpisywać cały dokument czy jego fragment i jakiego formatu użyć (formaty wykorzystujące XML pozwalają podpisywać fragmenty dokumentów)
10. Czy używać znakowania czasem, jeżeli tak to jakie rozwiązanie wybrać (opłata czy własny serwer czasu), stowarzyszenie PEMI wyraża chęć pomocy (oni przez pewien czas utrzymywali taki serwer ale nie było zainteresowania)
11. Wybór systemu operacyjnego użytkownika oraz określenie przeglądarki internetowej
12. Wybór dostawcy certyfikatu (tzw. urząd certyfikacyjny) w pewnym sensie determinuje sposób obsługi certyfikatu u klienta. Są dwa: Sigillum i Certum
13. Wybór urządzenia smart cart i karty inteligentnej jeszcze bardziej zawęża wybór rozwiązania tej obsługi. Są dwa rozwiązania. Jedno bazuje na sterownikach PC-SC (dll) drugia na JavaCard (ale mało popularne)
14. Co wybierze nasz klient, pod tym kątem musimy przygotować oprogramowanie
15. Wybóry powyższe determinują rozwiązanie obsługi ceryfikatów i podpisu w naszych aplikacjach
16. Coś za coś - wybrawszy dostawcę możemy liczyć na jego wsparcie i dostajemy dużo narzędzi do instalacji, konfiguracjie, testowania certyfikatów a także aplikacje wspomagające np. CryptoCard Monitor, ale kosztem bardziej skomplikowanej procedury instalacyjnej i konfiguracyjnej
17. Wsparcie (Sigillum i Certum) polega na dostarczeniu bezpłatnej aplikacji w grubym kliencie do podpisu i weryfikacji dokumentów lokalnych. To niewybrednym klientom wystarcza, resztę załatwiają przy pomocy poczty elektronicznej.
18. Na szczęście każdy dostawca dostarcza własne biblioteki obsługi oraz sterowniki (czasami odpłatnie) wraz z homologacją
19. Na nieszczęście każde rozwiązanie jest inne, brak uniwersalnego rozwiązania (czasami zdarzają sie biblioteki uniwersalne - patrz Sigillum)
20. W MS Windows jest wbudowana obsługa podpisu i certyfikatów poprzez odpowiednio zdefiniowane warstwy
    
21. Należy unikać "szarlatańskich" rozwiązań z Internetu, które działają w pewnych tylko przypadkach, choć istnieje pewne prawdopodobieństwo, że przy odrobinie wysiłku można je przystosować i rozwinąć dla własnych potrzeb. Sprawdziłem - prosto jedynie można podpisać gdy certyfikat nie jest na karcie a jedynie w repozytorium Windows
22. Prawdziwe i pełne oprogramowanie podpisu nie może sie obejść bez głębokiego wniknięcia w programowanie (szczególnie jeżeli chodzi o przygotowanie komponentów) na poziomie Java lub .NET. Dlatego konieczne są szkolenia
23. Rozwiązania z internetu (każde inne):
    
    1. http://www.nakov.com/documents-signing/demo/SmartCardSignerApplet-demo.html
    2. http://www.developer.com/java/web/article.php/3298051
    3. http://www.developer.com/security/article.php/11580_3587361_1
    4. http://rcardon.free.fr/
    5. http://www.podpiselektroniczny.pl
    6. http://www.trustedwebservices.org/content/view/48
       

Można udostępnić całościowe ale hermetyczne rozwiązanie albo wiele różnych wihajstrów do wykorzystania. Oba te rozwiązania są pożyteczne.


Część kliencka podpisu

Do podpisywania (i tylko do tego bo można jeszcze szyfrować) służy bezpieczne urządzanie tj. zestaw: system operacyjny, czytnik smart card/karta inteligentna oraz aplikacja. Miejsce podpisywania - wyłącznie u klienta. Konieczna jest wizualizacja dokumentu przed podpisem. Wszystkie inne funkcje związane z podpisem mogą być realizowane w innym miejscu np. na serwerze. Problem podpisu możemy rozwiązać na dwa sposoby.

1. Podejście brutalne - wykorzystanie istniejących w systemie Windows uniwersalnych komponentów do obsługi całego (kompletnego) procesu składania i sprawdzania podpisu. Komponenty te można zabudować we własnych aplikacjach. Te komponenty to:
   1. Wbudowany w MS Windows moduł CAPI oraz interface do niego CAPICOM (czyli udostępnienie interfejsu Crypto API poprzez architekturę COM) który zapewnia wszystkie podstawowe funkcje związane z podpisem i sprawdzaniem dokumentu oraz obsługą repozytorium certyfikatów. Dokładnie mówiąć CAPICOM pozwala na "przeźroczystą" obsługę konkretnych urządzeń kryptograficznych dostępnych przez CSP. Jest to dla środowiska MS Windows Client jedyny wbudowany komponent do obsługi podpisu cyfrowego. Dla środowiska Linux / Unix nie ma takiego komponentu, jedynie aplikacje w Javie coś takiego mają. Należy pamiętać, że Microsoft ogłosił plany stopniowego wygaszania wsparcie dla CAPICOM począwszy od systemów operacyjnych po Viscie (ale CAPICOM w Viście jest wspierany, a to dlatego, że całkiem po prostu nie ma jeszcze pełnego wsparcia dla obsługi certyfikatów kwalifikowanych tj. mających zabezpieczone przed pobraniem klucze prywatne - tego jeszcze na platformie .NET nawet w nowej wersji 3.5 nie ma! Sam sprawdziłem, mówi się, że trzeba poczekać na SP1 do Visty. W Viscie jest nowy moduł, zgodny z CAPICOM i nosi nazwę CNG (Cryptography API: Next Generation) - wykorzystuje on nowsze, certyfikowane przez National Security Agency (NSA) algorytmy, jest bezpieczniejszy i szybszy (dzięki wykorzystanie tzw. Elliptic Curve Cryptography). Ale jest jeszcze niedopracowany (czekamy na SP1). Dlatego jedyne na obecną chwilę rozwiązanie w środowisku .NET poza CAPICOM to skorzystanie z dostępnych bibliotek firm dostarczających certyfikaty np. biblioteki Sigillum. Możliwości CAPICOM:
      1. Dostęp do:
         1. Certyfikatu oraz ścieżki certyfikacyjnej
         2. Danych o podpisującym
         3. Danych o wystawcy
         4. Danych o datach ważności informacji
         5. Klucza publicznego
      2. Realizacja podpisu pod dokumentem:
         1. Wbudowanego (tzw. attached, powstaje nowy, znacznie większy o ok. 3 razy dokument, który jest samowystarczalny tj. niesie informację o dokumencie podstawowym, się może być sprawdzony na nienaruszalność danych i zawiera informacje kto, kiedy podpisał
         2. Pomocniczy (tzw. detached, znacznie mniejszy ok. 20-30 KB, do weryfikacji potrzebny jest dokument podstawowy)
      3. Weryfikacji dokumentu - sprawdzenia czy dokument uległ zmianie.
      4. Kopertowanie (envelope) - dodatkowa funkcja szyfrowania danych kluczem publicznym odbiorcy, wtedy tylko odbiorca może dokument odczytać
      5. Brak bardziej zaawansowanych funkcji: znacznika czasu i sprawdzenia (online poprzez OCSP lub pobranej periodycznie listy CRL) czy certyfikat nie został odwołany
   2. Biblioteki zewnętrzne (przykład - zakupiona przez ZA biblioteka Sigillum), realizuje ona wszystko to co ma CAPICOM i ma mnóstwo rozszerzeń m.in. znakowanie czasem, walidacja ważności certyfikatu online (poprzez OCSP), wsparcie certyfikatów innych wystawców, podpis wielokrotny. Zaletą tej biblioteki jest oparcie jej o nowy standard bezpieczeństwa wykorzystujący platformę .NET, będącej podstawą kolejnych edycji MS Windows. Nie rozpoznałem możliwości biblioteki drugiego dostawcy certyfikatów Certum z uwagi na utrudniony dostęp do informacji (znam jedynie cenę biblioteki ok. 7 tyś. zł. W czasie rozmów z przedstawicielami Certum w Katowicach przedstawiono nam warunki dostępu - podpisanie umowy partnerskiej.
2. Podejście ambitne - stworzenie własnej, uniwersalnej biblioteki co wiąże się z dużymi nakładami. Biblioteka może być rozwijana na platformie MS (wykorzystywać trzeba będzie już chyba nie CAPICOM ale .NET) lub Java na platformie Linux/Unix. W tym ostatnim przypadku brakuje natywnych sterowników do czytników smart card obecnie na rynku no i brak naszego doświadczenia. Probowałem się skontaktować z przedstawcielami SputnikSoftware jedynej w Polsce firmy mającej rozwiązanie pod Linux. Poza rozmowy przez telefon i wysłania im e-maila z zapytaniem o współpracę brak odpowiedzi.

Studium przypadków

Rozwiązania kompleksowe (ale przez to nieco hermetyczne), przetestowane w Portalu AS:

1. Aplikacja kameleon w "grubym kliencie" implementująca na formularzu komponent webBrowser (silnik IE 6/7) do wyświetlania witryny AS (użytkownik ma całkowite złudzenie, że korzysta z przeglądarki internetowej), która przechwytuje zdarzenia w przeglądarce i obsługuje lokalne zasoby, w tym przypadku czytnik smart card i wszystkie biblioteki (.dll czy .ocx) Windows. Była to wersja I podpisu cyfrowego dokumentów zamówień w Portalu AS. Eksploatowana od 2006 roku. Wynik:
   1. Zalety:
      1. Zero niespodzianek i potrzeb zdobywania nowych "doświadczeń" od strony użytkownika
      2. Doskonała współpraca z urządzaniami peryferyjnymi i komponentami Windows
      3. Bezproblemowa komunikacja z czytnikiem
      4. Bezpieczeństwo - użytkownik ma dostęp do jedynie tych adresów URL na które mu zezwolimy
   2. Wady:
      
      1. Potrzeba instalacja (użytkownik musi pobrać z witryny i zainstalować u siebie aplikację) chociaż wykorzystywane przeze mnie narzędzie do tworzenia instalacji sprowadza jej proces do bezmyślnego klikania OK),
      2. W jednym przypadku (opcja upoważnień witryna się zawieszała),
      3. Być może do był powód poprzedniego problemu - zła obsługa wielu instancji okien przeglądarkowych
   3. Werdykt - rozwiązanie niezłe, przy odrobinie samozaparcie można problem ten zbadać i albo go usunąć albo znaleźć obejście.
2. Aplikacja natywna w "grubym kliencie". Jest to rasowa aplikacja wykonana w WinForm w środowisku .NET. Wszystkie kontrolki potrzebujące danych z bazy (np. listy rozwijane, tabele/gridy) są zasilane poprzez technologię AJAX z baz po stronie portalu, czyli aplikacja wszystkie świeże dane ściąga z witryny poprzez prymitywną usługę webową. Dalej jak powyżej, dostęp do wszystkich zasobów lokalnych jest bez ograniczeń. Była to wersja II podpisu cyfrowego dokumentów zamówień w Portalu AS. Eksploatowana od 2007 roku. Wynik:
   1. Zalety:
      1. Doskonała współpraca z zasobami lokalnymi i sieciowymi oraz komponentami Windows
      2. Bezproblemowa komunikacja z czytnikiem
      3. Bezpieczeństwo - pełna kontrola nad użytkownikiem
      4. Zgodność z wymaganiami MS dla aplikacji klienckich
      5. Wykorzystanie biblioteki Sigillum z jej pełnym zestawem możliwości np. realizacja podpisu wielokrotnego
      6. Możliwość łatwego generowania wydruków pod katem użytkownika lub nawet przez użytkownika (dostępny jest generator wydruków)
   2. Wady:
      1. Potrzeba instalacja (użytkownik musi pobrać z witryny i zainstalować u siebie aplikację) chociaż wykorzystywane przeze mnie narzędzie do tworzenia instalacji sprowadza jej proces do bezmyślnego klikania OK. W przypadku .NET ułatwieniem może być automatyczna aktualizacja programu bezpośrednio z witryny Portalu.
      2. Brak pełnej funkcjonalności portalu - udostępnia jedynie jego wąski skrawek, są użytkownicy chcący spojrzeć szerzej na portal - dla nich trzeba by dopisać coś więcej, chociaż z drugiej strony można im udostępnić komponent w innym WinForm komponent webBrowser z rozwiązania nr.1.
   3. Werdykt - rozwiązanie niezłe i jednocześnie nowoczesne udostępniające pełną gamę funkcji związanych z podpisem. Należy nadal rozwijać
3. Podpis poprzez ActiveX - użytkownik ma możliwość wykonania wszelkich prac związanych ze składaniem podpisu i weryfikacją bezpośrednio w przeglądarce pracując w portalu dziedzinowym. Dostęp do tych funkcji ma poprzez osadzenie na stronie internetowej kontrolki ActiveX (CAPICOM lub Sigillum). Metoda eksploatowana w Portalu AS od 2007 roku w przypadku ok. 15% klientów.
1. Zalety:
   1. Zero niespodzianek i potrzeb zdobywania nowych "doświadczeń" od strony użytkownika
   2. Przeźroczyste dla użytkownika - nic nie musi instalować
   3. Dostęp z poziomu przeglądarki do wszystkich funkcji jak w przypadku "grubego klienta"
2. Wady:
1. Potrzeba zgody użytkownika na zainstalowanie "obcej" kontrolki
2. Potrzeba skorygowania często niepoprawnie działającej konfiguracji przeglądarki
3. Potrzeba skonfigurowania poziomu zabezpieczeń przeglądarki aby zezwalała na dostęp do repozytorium certyfikatów i samego czytnika
4. Trudność dokonania diagnozy i zdalnej konfiguracji w przypadku niedoświadczonych użytkowników
3. Werdykt - rozwiązanie działa poprawnie w środowisku przeglądarki MS IE i lokalnej sieci gdzie administrator ma kontrolę nad instalacjami
4. Podpis poprzez applet Java - dostęp do w/w funkcji odbywa się poprzez podpisany zaufanym certyfikatem specjalny applet w języku Java. Komunikacja z czytnikiem wygląda tak:
   1. Strona internetowa przekazuje żądanie do appletu wraz z kluczem do dokumentu źródłowego,
   2. Applet uruchamia i przekazuje ten klucz do komponentu lokalnego (np. dll)
   3. Komponent lokalny (opakowana funkcjonalność CAPICOM lub Sbibiloteki Sigillum w .dll) - który na jego podstawie pobiera z Internetu dokument, podpisuje go i odsyła z powrotem.
   4. Applet jest niewizualny (nie ma interfejsu graficznego) jego zadaniem jest łączenie strony internetowej ze środowiskiem lokalnym.
   5. Rozwiązanie nie wdrożone (działa prototyp).
   6. Wady:
      1. Potrzeba zakupu certyfikatu Authenticode do podpisania appletu
      2. Potrzeba zgody użytkownika na zainstalowanie "obcego" appletu
   7. Zalety:
      1. Otwartość i uniwersalność - działa w każdej przeglądarce
      2. Przeźroczyste dla użytkownika - nic nie musi instalować (no musi zainstalować .dll ale to można zautomatyzować)
   8. Werdykt - rozwiązanie nie gotowe ale o potencjalnie dużych możliwościach

Rozwiązania cząstkowe

Narzędzia do wykorzystania:

1. Baza danych dla dokumentów źródłowych i podpisanych
2. Własne biblioteki .dll opakowująca funkcjonalność CAPICOM i Sigillum
3. Rozwiązanie 1-4 są dostępne do analizy
4. Pobieranie i sprawdzanie certyfikatu z listami CRL (program w Javie poprzez połączenie z Internetem ściąga plik CRL)
5. Serwer sprawdzający certyfikat jw ale z wykorzystaniem OCSP i biblioteki Sigillum (usługa webowa na platformie .NET - wymaga MS Windows Server)
   

Wnioski

1. Wybór technologii:
   1. Rozwiązania .NET i Java są jeszcze niedojrzałe (brakuje im specjalizacji np. obsługi urządzeń, uwzględnienia specyfiki wymagań podpisu krajowego).
   2. Obiecująco wygląda rozwiązanie oparte o Javę, jest otwarte i ciągle rozwijane poprzez prace środowiska open-source
   3. Rozwiązanie oparte o CAPICOM jest dojrzałe i sprawdzone ale ma dwie wady: nie jest dalej rozwijane przez MS (w jego miejsce ma wejść .NET ale nie jest jeszcze gotowe)
   4. Rozwiązanie zamknięte wykorzystujące biblioteki dostawcy sprzętowego jest chyba na chwilę dzisiejszą najbardziej obiecujące, załatwia wszystkie potrzeby odnośnie podpisu oraz uwzględnia specyfikę krajowego ustawodawstwa. Ale jest mało mało uniwersalne.