Raport na temat aktualnego stanu podpisu elektronicznego w Polsce

Raport na temat aktualnego stanu podpisu elektronicznego w Polsce Paweł Krawczyk Internet Society Poland Wersja 5

Wstęp... 2 Stan obecny... 3 Podstawy prawne podpisu elektronicznego... 3 Advanced Electronic Signature... 4 Qualified Certificate... 4 Secure Signature Creation Device (SSCD)... 5 Polska ustawa o podpisie elektronicznym... 5 Bezpieczne urządzenie według ustawy... 6 Czy rozporządzenie jest w ogóle potrzebne?... 6 Polskie rozporządzenie o warunkach technicznych... 8 Bezpieczne urządzenie według rozporządzenia... 9 Co mamy obecnie na rynku?... 10 Konsekwencje SSCD opartego o zwykły Windows... 11 Niech klient sam zadba o swoje urządzenie... 12 Bezpieczny inaczej... 13 Konflikt między ustawą a rozporządzeniem... 14 Inne nieścisłości... 14 Problemy z formatami...16 Trzy standardy - cztery formaty... 17 Sigillum SDOC... 18 Konsekwencje wyboru cztery firmy, cztery formaty... 18 Jaki format wybierze administracja i dlaczego wszystkie cztery?... 20 Faktury elektroniczne kwalifikowany vs niekwalifikowany... 21 Administracja publiczna dojna krowa... 22 Rozwiązania... 24 Bezpieczne urządzenie do podpisu... 25 Formaty podpisu elektronicznego... 26 PKCS7, CMS, XML... 27 Format XML (XAdEs)... 27 Który format najlepszy?... 28 Server Based Signature Services... 29 Język rozporządzenia... 29 Zakończenie... 30 Wstęp Internet Society Poland jest stowarzyszeniem, dla którego zawsze priorytetem była popularyzacja społeczeństwa informacyjnego przez promowanie technik informatycznych w życiu publicznym i biznesie. Podpis elektroniczny jest narzędziem, które ma olbrzymi potencjał i może przynieść wymierne korzyści zarówno osobom prywatnym, administracji publicznej oraz biznesowi. Obserwując aktualny stan podpisu elektronicznego dostrzegamy jednak

poważne bariery na drodze do jego poprawnego rozwoju. Ten raport szczegółowo analizuje te problemy i przedstawia propozycje rozwiązań, które zdaniem ISOC-PL mogą przyczynić się do faktycznego wprowadzenia podpisu do powszechnego użycia w Polsce i w Europie. Autor chciałby podziękować następującym osobom za wkład i uwagi do tego dokumentu: Mirosław Kutyłowski, Zbigniew Jakubowski, Piotr Waglowski, Władysław Majewski, Józef Halbersztadt, Sergiusz Pawłowicz, Marcin Cieślak, Łukasz Jachowicz. Kontakt z autorem: Paweł Krawczyk, tel. +48-602-776959, email: kravietz@post.pl Stan obecny Podstawy prawne podpisu elektronicznego Źródłem prawa o podpisie elektronicznym jest Dyrektywa Unijna 1999/93 z dnia 13 grudnia 1999 r. (DIRECTIVE 1999/93/EC OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL). Dyrektywa definiuje aspekt organizacyjny (instytucja centrów certyfikacji) i prawny podpisu elektronicznego. O dyrektywie trzeba wiedzieć dwie rzeczy: jest rekomendacją; państwa członkowskie UE (w tym Polska) powinny tworzyć prawo na podstawie, ale niekoniecznie przez skopiowanie dyrektywy jeden do jeden w praktyce tak się zwykle robi, bo jest najłatwiej ale nie zawsze, dyrektywa jest dość ogólna w zakresie technikaliów np. mówi ogólnie, że należy stosować algorytmy bezpieczne kryptograficznie, ale określenie że ma być to na przykład RSA 1536 bitów nie leży w gestii dyrektywy. Warto również wiedzieć, że dyrektywa definiuje specyficzny żargon. Do tego żargonu należy określenie electronic signature, advanced electronic signature oraz qualified certificate (na razie celowo pozostawiam bez tłumaczenia). Jaka jest różnica między electronic a advanced electronic? W rozumieniu dyrektywy napis Józef Tkaczuk napisane w ASCII pod mailem jest podpisem elektronicznym ( electronic signature ). Bo jest podpisem ( signature ), i jest elektroniczny ( electronic ). Chodzi oczywiście o to żeby w prawie istniało miejsce na różne techniki podpisu stworzone na przestrzeni lat. Np. zeskanowane podpisy odręczne w produktach Adobe.

Advanced Electronic Signature W tej analizie będziemy skupiać się tylko na podpisie advanced electronic. Dokładna definicja tego podpisu w brzmieniu Dyrektywy: advanced electronic signature means an electronic signature which meets the following requirements (art 2 pkt 2 dyrektywy) Dalej jest mowa o wymaganiach funkcjonalnych, takich jak jednoznaczne powiązanie z właścicielem itd. W praktyce wymagania te są zapewniane przez odpowiednie funkcje kryptograficzne. Jest jeszcze jeden podpis dla nas kluczowy - stanowiący silniejszą wersję advanced. Jest to podpis advanced złożony po pierwsze przy pomocy specjalnego certyfikatu, po drugie na specjalnym urządzeniu: advanced electronic signatures which are based on a qualified certificate and which are created by a secure-signature-creation device: (a) satisfy the legal requirements of a signature in relation to data in electronic form in the same manner as a handwritten signature (art 5 pkt 1 dyrektywy) Czyli, odwracając szyk zdania status prawny identyczny z podpisem odręcznym ma tylko zaawansowany podpis elektroniczny oparty o certyfikat kwalifikowany i bezpieczne urządzenie do składania podpisu. I tylko ten. Tutaj pojawiają się pojęcia qualified certificate oraz secure signature creation device (SSCD). Qualified Certificate Pierwszy termin certyfikat kwalifikowany oznacza certyfikat (klucz publiczny plus opis właściciela), który został wydany zgodnie z określoną procedurą i musi zawierać określone dane o posiadaczu. Sens tego jest taki, że tożsamość przyszłego właściciela certyfikatu musi zostać zweryfikowany (dowód osobisty, paszport, dokumenty firmy) przez uprawnioną trzecią stronę (firmę, instytucję) wydającą certyfikat kwalifikowany. Po to, byśmy mieli pewność że osoba, która go otrzyma jest tą za którą się podaje. Z tego względu zgodnie z prawem polskim certyfikatem kwalifikowanym nie jest np. klucz przechowywany w Mozilli (bo nie jest na karcie) ani wystawiony przez miejscowego informatyka, nawet na karcie (bo wujek nie jest uprawnioną instytucją).

Czy jest to konieczne? Tak, ponieważ procedury weryfikacji stosowane przez miejscowego informatyka mogą nie być wystarczające dla zapewnienia bezpieczeństwa obrotu gospodarczego. Secure Signature Creation Device (SSCD) Drugi termin bezpieczne urządzenie do składania podpisu elektronicznego (SSCD) oznacza urządzenie, które spełnia określone standardy bezpieczeństwa. Wymagania wobec SSCD są wyłożone w Annex III dyrektywy. Dodatek ten mówi m.in. o tym żeby: nie dało się odtworzyć klucza prywatnego z urządzenia klucz prywatny ma być chroniony przed niepowołanymi podpis ma być chroniony przed fałszerstwem urządzeniu nie wolno zmieniać podpisywanych danych Zwróćmy uwagę na ten ostatni punkt, który będzie kluczowy w dalszej części tej analizy. Proszę również pamiętać, że dyrektywa jest dokumentem prawnym a nie technicznym! Oznacza to, że urządzenie wcale nie musi być fizycznym urządzeniem podobnym do bankomatu, które większości speców od IT od razu staje przed oczami. Z prawnego punktu widzenia nawet słoik będzie bezpiecznym urządzeniem jeśli będzie spełniał listę wymagań określonych w dyrektywie. Zachowajmy te informacje w pamięci i podsumujmy - sama dyrektywa jest dokumentem napisanym dobrze, spójnym i nie ma co do niej zastrzeżeń. Polska ustawa o podpisie elektronicznym Polska zaimplementowała dyrektywę 1999/93/EC jako Ustawę z dnia 18. września 2001 r. o podpisie elektronicznym. Ustawa jest prawie dokładnym tłumaczeniem dyrektywy. W polskiej ustawie termin advanced electronic signature został przetłumaczony jako bezpieczny podpis elektroniczny a nie zaawansowany, co się narzuca z tłumaczenia. Zwracało na to uwagę wiele osób, m.in. prof. Kutyłowski sugerując, że jest to nieuzasadnione rozszerzenie znaczenia (gdyby autorzy dyrektywy mieli podstawy by napisać bezpieczny, to napisaliby secure, a tymczasem napisali advanced ). Wypowiedź prof. Kutyłowskiego: http://security.computerworld.pl/artykuly/49795.html Nie zmienia to jednak finalnego sensu ustawy, ponieważ dalej stwierdza ona konsekwentnie:

Dane w postaci elektronicznej opatrzone bezpiecznym podpisem elektronicznym weryfikowanym przy pomocy ważnego kwalifikowanego certyfikatu są równoważne pod względem skutków prawnych dokumentom opatrzonym podpisami własnoręcznymi (Art 5 pkt 2) Czyli polska ustawa konsekwentnie zachowuje rozróżnienie bezpieczny podpis versus bezpieczny podpis weryfikowany kwalifikowanym certyfikatem. W praktyce to drugie nazywa się potocznie podpisem kwalifikowanym. Bezpieczny podpis bez certyfikatu kwalifikowanego nazywa się podpisem niekwalifikowanym lub podpisem zwykłym. Bezpieczne urządzenie według ustawy O wiele istotniejsze są jednak przepisy dotyczące omówionego wyżej bezpiecznego urządzenia do składania podpisu. Fragment analogiczny do Appendix III dyrektywy jest w Ustawie zawarty w art. 18. Oto jak brzmi interesujący nas fragment (art. 18 pkt 1): Bezpieczne urządzenie służące do składania podpisu elektronicznego powinno co najmniej: ( ) nie zmieniać danych, które mają zostać podpisane lub poświadczone elektronicznie oraz umożliwiać przedstawienie tych danych osobie składającej podpis elektroniczny przed chwilą jego złożenia, (art. 18 pkt 1) Kluczowe jest to, że ustawę rozszerza szereg rozporządzeń. Rozporządzenia te regulują szczegóły techniczne oraz organizacyjne podpisu elektronicznego w Polsce. W założeniach ustawa określa schemat ogólny i wymagania (jak powyżej), a rozporządzenie wypełnia je treścią (konkretne zabezpieczenia). Niestety w przypadku polskiego rozporządzenia stało się inaczej. Dwa wyróżnione wyżej fragmenty są krytyczne z punktu widzenia poniższych rozważań o sprzeczności rozporządzenia z ustawą. Czy rozporządzenie jest w ogóle potrzebne? Zanim przejdziemy do dalszej analizy, zatrzymajmy się nad jeszcze jedną kwestią. Czy rozporządzenie do ustawy jest w ogóle potrzebne? Na tle innych krajów członkowskich widać, że Polska zdecydowała się na wprowadzenie restrykcyjnej wersji ustawy o podpisie elektronicznym, w którym państwo nie tylko mówi jakie własności powinien mieć bezpieczny podpis (wymogi funkcjonalne określone w Dyrektywie), ale dodatkowo narzuca jakimi środkami technicznymi ma to być osiągnięte.

Sama dyrektywa nie mówi nic o szczegółach bezpiecznego urządzenia do składania podpisu, a jedynie określa wymogi funkcjonalne wobec tego urządzenia - np. że nie powinno zmieniać danych przeznaczonych do podpisania. Rozporządzenie określające szczegóły techniczne urządzenia jest naszą rodzimą produkcją. Niektórzy europejscy ustawodawcy ograniczyli się do wdrożenia ustawy w formie niemal dosłownie przetłumaczonej z Dyrektywy unijnej. Np. w Czechach nie ma w ogóle obowiązku korzystania z bezpiecznego urządzenia w sensie odrębnej, fizycznej maszyny. Nie ma także zatem dodatkowego rozporządzenia o warunkach technicznych, określającego szczegóły takiego urządzenia. W powszechnym użyciu jest certyfikat kwalifikowany w sensie certyfikatu wystawionego z zachowaniem odpowiednich procedur określonych w Dyrektywie. Ale do składania podpisu może służyć dowolna aplikacja implementująca podpis elektroniczny Outlook Express, Mozilla, Microsoft Office, OpenOffice 2.0 itd. Przez to, że ustawodawca nie określił szczegółowo ani formatów ani technicznych parametrów bezpiecznego urządzenia, rynek wybrał je sam korzystając z powszechnie przyjętych standardów technicznych, znanych od lat (np. S/MIME). Nie oznacza to, że bezpieczeństwo podpisu elektronicznego w Czechach jest radykalnie niższe. Zgodnie z prawem urządzenie do składania podpisu (czyli np. Windows z Outlookiem) musi nadal spełniać wymogi ustawy, czyli np. nie zmieniać danych przeznaczonych do składania podpisu. Jednak sposób w jaki ten wymóg jest w praktyce realizowany zależy od samego podpisującego. To podpisujący odpowiada za bezpieczeństwo swojego klucza prywatnego i wynika to wprost z czeskiej ustawy. Podpis elektroniczny w Polsce został zdefiniowany o wiele bardziej drobiazgowo (rozporządzenie o warunkach technicznych), co miało w założeniu zapewnić jego większe bezpieczeństwo. Niestety w praktyce okazało się, że przez niefortunne wyłączenie jakiejkolwiek ochrony tzw. oprogramowania niepublicznego faktyczny stan podpisu elektronicznego w Polsce został sprowadzony do Windowsa z podłączonym czytnikiem i zainstalowaną aplikacją do podpisywania. Niestety, w odróżnieniu od rozwiązań stosowanych powszechnie na rynku, aplikacje te korzystają z uznaniowo wybranych formatów i są niewygodne w stosowaniu, a bezpieczeństwo takiego rozwiązania sprowadza się do bezpieczeństwa zwykłego biurowego czy domowego systemu Windows. Czyli, okrężną drogą, doprowadzono do tego że o bezpieczeństwie niby-bezpiecznego urządzenia i tak decyduje tylko użytkownik. Niestety, w przeciwieństwie do Czech, użytkownicy dowiedzieli się o tym nie z ustawy, tylko od centrów certyfikacji podczas kłótni wywołanym przez publikację firmy G DATA (szczegóły dalej).

Oznacza to, że Czesi, którzy pozornie wybrali rozwiązanie mniej bezpieczne, w obecnej chwili dysponują identycznym poziomem bezpieczeństwa jak my, ale bez związanych z tym problemów z kompatybilnością (które omawiamy poniżej), za to przy radykalnie większej wygodzie i praktyczności korzystania z tego podpisu. Czy czeskie rozwiązanie jest lepsze? Na pewno z punktu widzenia przejrzystości prawa tak, jest lepsze! Jeśli chodzi o bezpieczeństwo to byłoby mniej bezpieczne, gdyby nasze rozporządzenie nie wprowadziło dodatkowych zabezpieczeń, które samo potem zniosło. Jedyną istotną różnicą, która odróżnia wymogi polskie od czeski jest wynikający z polskieg rozporządzenia obowiązek przechowywania klucza prywatnego na karcie. Jest to obowiązek słuszny w przypadku podpisu kwalifikowanego, ponieważ zapewnia on realnie duże bezpieczeństwo klucza prywatnego przed kradzieżą. Kradzież klucza prywatnego miałaby bardzo poważne konsekwencje dla użytkownika (możliwość nieograniczonego składania fałszywych podpisów) i obowiązek ten jest wart utrzymania. Polskie rozporządzenie o warunkach technicznych Głównym dokumentem określającym szczegóły techniczne podpisu elektronicznego jest rozporządzenie o warunkach technicznych (pełna nazwa: Rozporządzenie Rady Ministrów z dnia 7 sierpnia 2002 r. w sprawie określenia warunków technicznych i organizacyjnych dla kwalifikowanych podmiotów świadczących usługi certyfikacyjne, polityk certyfikacji dla kwalifikowanych certyfikatów wydawanych przez te podmioty oraz warunków technicznych dla bezpiecznych urządzeń służących do składania i weryfikacji podpisu elektronicznego. ). Rozporządzenie, w odróżnieniu od ustawy, nie jest oparte o dyrektywę i zostało napisane w Polsce. Częściowo zawiera ono rozwiązania techniczne opisane w profilu bezpieczeństwa CWA 14169, zaproponowanym przez Europejski Komitet Standaryzacji (CEN). Jednak jako całość, jest ono sprzeczne zarówno z dyrektywą unijną jak i polską ustawą i to jest kluczowy problem obecnego polskiego prawodawstwa. Na czym polega ta sprzeczność? Otóż rozporządzenie wprowadza, a zaraz potem w nieuzasadniony sposób znosi wymogi bezpieczeństwa wobec bezpiecznego urządzenia narzucone przez ustawę. Daje to centrom certyfikacji prawo do sprzedawania klientom kilku klocków do budowy bezpiecznego urządzenia ze słowami sami sobie to złóżcie i zabezpieczcie. Finalny rezultat, jaki możemy oglądać w praktyce jest sprzeczny z wymogami narzuconymi przez dyrektywę, nie mówiąc już o zdrowym rozsądku i zasadach dobrej praktyki inżynierskiej w ochronie danych. Drugi problem to formaty podpisu, który opiszę później. Przejdźmy do szczegółów bezpiecznego urządzenia.

Bezpieczne urządzenie według rozporządzenia Mając cały czas w głowie odpowiedni akapit ustawy ( bezpieczne urządzenie powinno nie zmieniać danych do podpisania ) przyjrzyjmy się pewnej definicji użytej w polskim rozporządzeniu. Oprogramowanie publiczne - oprogramowanie podpisujące, do którego w normalnych warunkach eksploatacji może mieć dostęp każda osoba fizyczna; Oprogramowaniem publicznym nie jest w szczególności oprogramowanie używane w mieszkaniu prywatnym, lokalu biurowym lub telefonie komórkowym (par 1 pkt 9) Na jakiej podstawie założono, że komputer w mieszkaniu czy w biurze jest bezpieczny? W normalnych dziś warunkach eksploatacji jakim jest stałe łącze do Internetu, do komputera dostęp ma praktycznie cały świat. Codziennie tysiące komputerów domowych i biurowych na całym świecie pada ofiarą koni trojańskich. Fragment ten jest kuriozalny dlatego, że dzięki niemu ustawodawca kawałek dalej zezwolił producentom na niestosowanie zabezpieczeń w bezpiecznym urządzeniu! Jak to się stało? Otóż autor ustawy na początku wprowadził zabezpieczenia, które musi implementować bezpieczne urządzenie (omawiamy je dalej). Ale zabezpieczenia te dotyczą tylko oprogramowania publicznego. To co nie jest oprogramowaniem publicznym nie musi tych zabezpieczeń stosować. Ponieważ bezpieczne urządzenie w biurze i w domu nie jest publiczne, więc nie musi mieć zabezpieczeń. Innymi słowy, autor rozporządzenia założył, że oprogramowanie stosowane w domu lub w biurze jest bezpieczne samo przez się. Mowa tutaj o przeciętnym domowym lub biurowym Windowsie, bo tylko pod ten system są dostępne aplikacje do składania podpisu. Każdy kto ma cokolwiek wspólnego z bezpieczeństwem wie, że to właśnie komputery biurowe i domowe najczęściej padają ofiarami wirusów, rootkitów i koni trojańskich. Jak pisałem powyżej w dobie Internetu, każdy podłączony do sieci system jest publiczny! Każdy ma do niego dostęp i wynikałoby to z dosłownego brzmienia tego punktu ( ma dostęp nie powiedziano że dostęp fizyczny), gdyby zdanie dalej nie wprowadzono kuriozalnej definicji bezpieczeństwa przez mieszkanie lub biuro. Z moich doświadczeń wynika że niezałatany system Windows 2000 Server jest znajdowany przez automatyczne skanery i skutecznie infekowany w ciągu 5 minut po podłączeniu do sieci. Niezależnie od tego czy stoi w domu na pawlaczu, czy w biurze w sejfie.

W rezultacie tej nieuzasadnionej klasyfikacji rozporządzenie wyłącza spod ochrony 100% oprogramowania, które tej ochrony właśnie najbardziej potrzebuje. Od strony prawnej jest to zrealizowane następująco: rozporządzenie wprowadza pojęcie bezpiecznego kanału (par 1 pkt 13), czyli zabezpieczenia przed naruszeniem integralności podpisywanych danych po drodze między plikiem a aplikacją, następnie wprowadza obowiązek stosowania tego kanału przez oprogramowanie publiczne (par 4 pkt 4), gdzie indziej o nim nie wspominając; a zatem oprogramowanie niepubliczne nie ma obowiązku stosowania bezpiecznego kanału jako że dzięki odpowiedniej definicji niemal 100% oprogramowania stosowanego do podpisu staje się niepubliczne, pojęcie bezpiecznego kanału jest martwe! Jak pokazało życie polskie centra certyfikacji chętnie zastosowały się dwóch ostatnich punktów. W rezultacie w rozporządzeniu pominięto kwestię ochrony integralności danych wyraźnie podkreśloną zarówno w dyrektywie jak i ustawie przez kwestię bezpieczne urządzenie powinno nie zmieniać danych do podpisania rozwadniając ją do momentu gdzie straciła sens. Co w intencji autora rozporządzenia miało być oprogramowaniem publicznym?. Komputery w kafejkach internetowych lub na uczelniach? Chyba jedynie one w praktyce podpadają pod zacytowaną definicję. Ale skąd tam czytniki kart? Można sobie również wyobrazić jakieś kioski internetowe oferujące podpis elektroniczny, które też by pod to podpadały, ale zwykle są to systemy dedykowane i dobrze zabezpieczone. O wiele bardziej należy się martwić o zwykłe pecety uznane za autorów rozporządzenia za bezpieczne in statu nascendi. Co mamy obecnie na rynku? Wszystkie cztery centra certyfikacji oferują bezpieczne urządzenie do składania podpisu (SSCD) w postaci zestawu do samodzielnego montażu. Oferują, bo im wolno, dzięki takiej a nie innej konstrukcji rozporządzenia. Kupując takie urządzenie klient otrzymuje: czytnik kart elektronicznych, kartę elektroniczną z certyfikatem, oprogramowanie do składania i weryfikacji podpisu.

Oprogramowanie jest przeznaczone do instalacji na standardowym systemie Windows, wraz ze wszystkimi tego konsekwencjami. Konsekwencje SSCD opartego o zwykły Windows Aby nie być gołosłownym, w październiku 2005 roku firma G DATA ze Szczecinka zaprezentowała demonstrację, w której oprogramowanie firmy Certum zostało wykorzystane do sfałszowania podpisu elektronicznego w systemie Windows. Sfałszowanie polegało na zainstalowaniu w tym systemie rootkita, który przechwytywał wywołania systemowe Windows. W rezultacie program Certum inny plik wyświetlał użytkownikowi przed podpisaniem, a inny faktycznie podpisywał. Proszę zauważyć, że wymóg wyświetlenia dokumentu przed podpisaniem jest również narzucony przez ustawę (art. 18 pkt 1) i jest on jak najbardziej słuszny. Ale tutaj nic nie pomógł, bo rootkit inteligentnie podawał odpowiednią treść pliku w zależności od tego kto o nią prosił. Do wyświetlenia zwracał prawdziwą, do podpisania podmienioną. Demonstracja wywołała gwałtowną reakcję polskich centrów certyfikacji, które zarzuciły G DATA merkantylność, nieuctwo, szerzenie paniki itd. Odpowiedź Certum można znaleźć tutaj: http://www.unizeto.pl/unizeto/47911.xml http://www.unizeto.pl/unizeto/unizeto,pz_e_podpis_opinie.xml Podobne oświadczenie wydał m.in. KIR i Signet. Ale G DATA zademonstrowała zdarzenie, które jest jak najbardziej możliwe w rzeczywistości. Jest to zdanie osoby która z racji wykonywanego zawodu często spotyka się z rootkitami, końmi trojańskimi itp. i dobrze zna ich wysoką skuteczność w przenikaniu do systemów ofiar, niezależnie od lokalizacji. Dlatego też podjąłem decyzję o opisaniu tego przypadku na łamach Computerworld Security Online i podjąłem późniejszą polemikę z centrami certyfikacji. Zaowocowała ona ze strony centrów stworzeniem długiego dokumentu pt. Mity i fakty o podpisie elektronicznym, który jest publikowany na stronach Certum (drugi link zacytowany powyżej), KIR oraz Signet (http://www.signet.pl/info/aktualnosci.html). Wiele twierdzeń tam zawartych jest prawdziwych i nie będę z nimi polemizował. Jednak części problemów centra nie poruszyły w ogóle (formaty podpisu opisane poniżej), a część przedstawiły tak jak im wygodnie. Tak jest też z bezpiecznym urządzeniem do podpisu elektronicznego. Centra certyfikacji posługują się w swoich wypowiedziach dwoma argumentami, które powtórzę dla zwięzłości swoimi słowami:

przecież zalecamy instalację antywirusa przecież jesteśmy zgodni z rozporządzeniem Niech klient sam zadba o swoje urządzenie W poniższym akapicie będę pisał głównie o Certum, ale chciałbym na wstępie podkreślić że problem ten dotyczy wszystkich polskich centrów certyfikacji. Certum aktywnie brało w tej dyskusji udział m.in. przez swoje publikacje. Fakt ten jest godny zauważenia. Podobne oświadczenia wydawał KIR i Signet. Argument zalecamy instalacje antywirusa, jest tutaj oparty o jedno zdanie, znalezione przeze mnie w październiku w instrukcji do jednego z programów Certum (obecnie nie jest ona dostępny na stronie Certum). Równocześnie w opisanym wyżej artykule Certum przyznaje że: atak wirusa G DATA jest możliwy, ale tylko w przypadku stosowania oprogramowania niezgodnie z zaleceniami zawartymi w Podręczniku użytkownika dołączanego do produktów Unizeto Technologies SA. Niezgodnie, to znaczy jeśli w systemie nie ma antywirusa co zdaniem Certum jest gwarancją bezpieczeństwa systemu. Jest to fikcja. Większość obecnie stosowanych antywirusów nie jest w stanie wykryć rootkitów kontrolujących system, co więcej jest przez nie skutecznie unieszkodliwiana. Wykrywanie sygnaturowe na jakim polega większość antywirusów jest całkowicie nieskuteczne przeciwko nowym rootkitom, zwłaszcza spersonalizowanym pod konkretną grupę ofiar. Szczegółowe informacje o współczesnych rootkitach można znaleźć tutaj: http://security.computerworld.pl/news/85231.html W wspomnianym artykule Certum/Unizeto jest również kilka innych pomysłów jak korzystać z aplikacji bezpiecznie. Na przykład dodawać do podpisywanego dokumentu dodatkowy opis co jest w środku, odłączyć komputer od sieci czy zainstalować wspomniany antywirus i firewall. Pomysły w rodzaju dodawania dodatkowego opisu do dokumentu czy odpięcia komputera od sieci mają sens techniczny jako łatanie obecnego stanu rzeczy, ale w szerszej perspektywie brzmią śmiesznie i sprowadzają do absurdu sens stosowania podpisu elektronicznego jako łatwego i taniego. Po to mamy skrót kryptograficzny podpisany kluczem prywatnym żeby nie musieć dodawać opisu co jest w środku! Odłączając komputer od sieci nie będziemy mogli za to korzystać ze znakowania czasem, weryfikować ważności certyfikatów i tak dalej.

Jako początkowe założenie do budowy bezpiecznego urządzenia należy przyjąć że 90% klientów zainteresowanych podpisem elektronicznym nie ma zielonego pojęcia o tym jak poprawnie zabezpieczyć Windows. Sugerowanie im żeby sami zbudowali sobie takie urządzenie i jeszcze go zabezpieczyli jest nieuzasadnionym mąceniem im w głowach! Podsumowując, argument że to klient powinien dbać o swoje bezpieczne urządzenie jest chybiony z następujących powodów: powód techniczny - firewalle ani antywirusy dostępne na rynku nie są skutecznym zabezpieczeniem przed rootkitami i końmi trojańskimi stosowanymi obecnie; powód formalny - klient kupujący bezpieczne urządzenie w żadnym wypadku nie powinien otrzymywać zestawu typu zrób to sam którego bezpieczeństwo zależy od tego jakiego zainstalował antywirusa czy jak często uaktualnia regułki; Rozwijając drugi punkt: klient nie jest osobą kompetentną do budowania SSCD! Proponowanie zestawu do samodzielnego montażu i bronienie go przed racjonalnymi zarzutami przez wymyślanie coraz to kolejnych półśrodków jeszcze bardziej pogrąża podpis elektroniczny w oczach opinii publicznej. W interesie zarówno użytkowników podpisu jak i centrów certyfikacji jest by środowisko do składania podpisu było faktycznie bezpieczne, a nie bezpieczne w rozumieniu rozporządzenia. Rozwiązanie tego problemu nie jest łatwe zarówno od formalnej jak i technicznej strony. Ale jest możliwe. Swoje propozycje przedstawię pod koniec tego dokumentu. Bezpieczny inaczej Argumentacja jesteśmy bezpieczni z rozporządzeniem wychodzi od definicji w rozporządzeniu i tworzy wrażenie, że coś co nazwano bezpiecznym urządzeniem wcale wbrew nazwie nie musi być bezpieczne. Pojęcie bezpieczne w rozumieniu rozporządzenia nie ma tutaj nic wspólnego z potocznym rozumienia słowo bezpieczeństwo. We wspomnianym wyżej artykule Certum używa więc pojęcia bezpieczeństwo prawne i argumentuje, że G DATA nie zrozumiała ustawy bo przecież ich bezpieczne urządzenie jest bezpieczne w rozumieniu rozporządzenia. Można by powiedzieć bezpieczne inaczej Certum wydaje się być rozgrzeszone z tego, że nie jest bezpieczne bo przecież rozporządzenie poniekąd zwolniło ich z tego obowiązku (patrz oprogramowanie

publiczne powyżej). Poniekąd, ponieważ zgodność z rozporządzeniem nie oznacza, że można zignorować wymogi ustawy, będącej aktem nadrzędnym. Konia z rzędem temu, kto na podstawie takiego uzasadnienia wykrzesa w sobie choć trochę zaufania do podpisu elektronicznego w polskim wydaniu. Jak zobaczymy poniżej, ta nieuzasadniona interpretacja pojęcia bezpieczeństwo została wprowadzona tylko przez rozporządzenie. Ale już ustawa z której się ono wywodzi posługuje się normalnie rozumianym pojęciem bezpieczeństwa! Konflikt między ustawą a rozporządzeniem Powyższe dyskusje właściwie nie powinny w ogóle mieć miejsca w świetle wymagań, jakie nakłada ustawa czyli dokument nadrzędny w stosunku do rozporządzenia. Przypomnijmy ten fragment (art. 18 pkt 1): Bezpieczne urządzenie służące do składania podpisu elektronicznego powinno co najmniej: ( ) nie zmieniać danych, które mają zostać podpisane lub poświadczone elektronicznie oraz umożliwiać przedstawienie tych danych osobie składającej podpis elektroniczny przed chwilą jego złożenia, Urządzenie do samodzielnego montażu (pecet z Windows, czytnikiem i kartą) nigdy nie będzie w stanie praktycznie spełnić tego warunku ponieważ ryzyko zainfekowania przeciętnego Windowsa rootkitami jest duże i realne, nawet pomimo firewalli i antywirusów. Trudno również uznać za zgodne z zamysłem ustawodawcy i zdrowym rozsądkiem urządzenie, które dziś jest zgodne (bo nie jest zainfekowane i nie zmienia) a jutro nie jest zgodne (bo akurat antywirus nie zdążył z aktualizacją). Ogólnie - którego bezpieczeństwo zależy od uznaniowego zainstalowania przez użytkownika dodatkowego oprogramowania. Faktem wynikającym z prostej lektury tekstu ustawy i rozporządzenia jest że to co ustawa definiuje jednoznacznie i funkcjonalnie ( nie powinno zmieniać danych ) jest potem rozwadniane przez rozporządzenie w mętnych wywodach o oprogramowaniu publicznym. Z tego wynika, że rozporządzenie jest bezdyskusyjnie sprzeczne z ustawą i dyrektywą, z której się ona wywodzi, a obecnie oferowane bezpieczne urządzenia nie spełniają wymogów ustawy i Dyrektywy. Inne nieścisłości

Rozporządzenie w przeciwieństwie do ustawy i dyrektywy dzieli bezpieczne urządzenie na dwie części: komponent techniczny - sprzęt stosowany w celu wygenerowania lub użycia danych służących do składania bezpiecznego podpisu elektronicznego lub poświadczenia elektronicznego (par 1 pkt 6) oprogramowanie podpisujące - oprogramowanie, które przygotowuje dane, które mają zostać podpisane lub poświadczone elektronicznie, i przesyła je do komponentu technicznego (par 1 pkt 7) Dla uproszczenia będziemy mówić o komponencie sprzętowym i programowym. Rozporządzenie wprowadza również wspomniane wyżej zabezpieczenia ścieżkę i kanał: bezpieczna ścieżka - łącze zapewniające wymianę między oprogramowaniem podpisującym a komponentem technicznym informacji związanych z uwierzytelnieniem użytkownika komponentu technicznego, zabezpieczone w sposób uniemożliwiający naruszenie integralności przesyłanych danych przez jakiekolwiek oprogramowanie (par 1 pkt 12) bezpieczny kanał - łącze zapewniające wymianę między oprogramowaniem podpisującym a komponentem technicznym informacji związanych z przekazywaniem danych, które mają być podpisane lub poświadczone elektronicznie, zabezpieczone w sposób uniemożliwiający naruszenie integralności przesyłanych danych przez jakiekolwiek oprogramowanie (par 1 pkt 13) Jak widać istnieją mechanizmy zabezpieczające transmisję danych między kartą a aplikacją oraz między plikiem a aplikację. Tyle tylko że przez opisane wyżej gierki z oprogramowaniem niepublicznym zostały one w praktyce wyłączone. Również wymagania bezpieczeństwa odnośnie tych komponentów są różne. Komponent sprzętowy musi posiadać niezależny certyfikat bezpieczeństwa, zdefiniowany tak: Komponenty techniczne powinny posiadać certyfikaty zgodności, zaświadczające spełnienie wymagań określonych w Polskich Normach, a w przypadku braku takich norm, spełnienie wymagań określonych w dokumentach ( ) (par 5 pkt 2) Następnie są wymienione standardy bezpieczeństwa ITSEC-E3, Common Criteria EAL4 lub FIPS-140. Są to standardy określone przez różne międzynarodowe organizacje, zgodność z nimi jest w Polsce potwierdzana przez Departament Bezpieczeństwa Teleinformatycznego ABW. W Polsce obowiązują także certyfikaty wydane przez analogiczne instytucje NATO. Ze względu na fakt, że większość kart elektronicznych i

czytników jest wyprodukowana w krajach NATO i ma już taki certyfikat, są one uznawane u nas. Natomiast komponent programowy musi posiadać tylko i wyłącznie dobrowolną deklarację zgodności: Oprogramowanie podpisujące stosowane przy składaniu bezpiecznych podpisów elektronicznych powinno posiadać deklarację zgodności (par 7 pkt 11) Deklaracja jest wystawionym przez producenta oświadczeniem, że jego produkt jest zgodny z rozporządzeniem. Deklaracja jest jednostronicowym dokumentem, które zawiera dokładnie takie lakoniczne stwierdzenie jak powyżej deklaracje te można znaleźć na stronach poszczególnych centrów. Co jest najbardziej istotne, deklaracji tych nikt w praktyce nie weryfikuje! Problemy z formatami Jeśli przyglądamy się podpisowi elektronicznemu w Polsce z daleka to, poza problemami z bezpiecznym urządzeniem, wygląda to bardzo elegancko. Wszyscy sobie mogą podpisywać, wymieniać się dokumentami, fakturami itd. Niedługo będziemy mogli wysyłać podania do urzędów podpisane elektronicznie. Przygotowując w ubiegłym roku dla Computerworld tekst o podpisie pobrałem ze stron centrów certyfikacji aplikacje testowe, część z nich z certyfikatami testowymi. Niestety, praktyczne testy doprowadziły mnie do wniosku, że podpis elektroniczny, poza problemami z bezpiecznym urządzeniem, nie nadaje się w Polsce do praktycznego użytku. Wszyscy czterej wystawcy certyfikatów kwalifikowanych w Polsce deklarują pełną zgodność z rozporządzeniem. I faktycznie, każda z firm jest zgodna z jednym ze standardów zaleconych przez rozporządzenie. Problem polega na tym, że każda z innym! Format plików generowanych przez programy do składania bezpiecznego podpisu elektronicznego określa rozporządzenie o warunkach technicznych (par 30 pkt 1, podpunkt 1). Konkretnie, rozporządzenie dopuszcza by aplikacje do składania podpisu generowały podpis w jednym z trzech formatów:

1. CMS (Cryptographic Message Syntax), format definiowany przez normy ETSI TS 101 733 oraz RFC 3125 i RFC 3126. 2. Format oparty o XML, definiowany przez normę ETSI TS 101 903 (XAdEs) 3. PKCS7 binarny format będący podzbiorem CMS. Te trzy formaty są wzajemnie niekompatybilne. Każdy z nich ma inną strukturę i jest inaczej kodowany (CMS i PKCS7 są plikami binarnymi, a XML jest plikiem tekstowym). Formaty XML i CMS są mniej więcej równoważne funkcjonalnie, PKCS7 jest uboższy (na przykład nie przechowuje informacji o znacznikach czasowych). Trzy standardy - cztery formaty Polskie centa certyfikacji oferują oprogramowanie, które posługuje się następującymi formatami (stan na październik 2005): 1. Program procertum CombiLite zapisuje podpisy cyfrowe w formacie CMS. Żaden inny testowany program nie był w stanie zweryfikować tak złożonego podpisu. Program zapisuje pliki z rozszerzeniem SIG. 2. KIR oraz jego aplikacj SafeDevice stworzona przez firmę BSB zapisuje podpis cyfrowy w formacie PKCS7. Ten podpis jako jedyny został poprawnie zweryfikowany przez procertum CombiLite. W drugą stronę to jednak nie działa - SafeDevice nie weryfikuje podpisu w formacie CMS złożonego przez CombiLite. Można tego było oczekiwać bo CMS jest nadzbiorem PKCS7. SafeDevice również korzysta z rozszerzenia SIG przez co korzystanie z tych dwóch programów w jednym systemie jest cokolwiek niewygodne. 3. Signet Proofer nie weryfikuje żadnego z podpisów złożonych przez inne programy i trudno się dziwić bo jako jedyny korzysta z formatu XML, całkowicie odmiennego od CMS i PKCS7. Z tego samego powodu żadna z pozostałych aplikacji nie będzie w stanie zweryfikować podpisu złożonego Signet Confidantem. Program posługuje się plikami z rozszerzeniem SIGNET. Trzy wymienione wyżej aplikacje operują na dowolnych plikach, to znaczy z menu wybieramy fizyczny plik, obojętne w jakim formacie, i składamy na nim podpis. Wynik jest zapisywany albo do oddzielnego, małego pliku albo w formacie zwartym, w którym zarówno treść dokumentu jak i podpis znajdują się fizycznie w jednym pliku. Umożliwiają to wszystkie trzy standardowe formaty - CMS, PKCS7 i XML. 4. Sigillum Sign jest oryginałem wyróżniającym się spośród pozostałych programów zarówno filozofią jak i formatem zapisywanych dokumentów. Program nie operuje bowiem na plikach tylko integruje się ściśle z pakietem MS Office, pozwalając na podpisywanie dokumentów z poziomu Worda, Excella i PowerPointa. Brak jest funkcji w rodzaju "wybierz plik do podpisania". Zamiast tego w menu Worda pojawia się nowa pozycja "podpisz dokument", której

wybranie powoduje wygenerowanie graficznego obrazu każdej ze stron dokumentu czy arkusza. Są one następnie importowane do Sigillum Sign, podpisywane i zapisywane w prywatnym formacie SDOC opracowanym przez Sigillum. Sigillum SDOC Po bliższym przyjrzeniu się SDOC okazuje się że jest to archiwum w natywnym windowsowym formacie CAB, zawierające pliki graficzne reprezentujące poszczególne strony dokumentu oraz - prawdopodobnie - plik z podpisami cyfrowymi każdej z nich. Z infolinii Sigillum dowiedziałem się że jest to format prywatny opracowany przez tę firmę. Przy kolejnym telefonie powiedziano mi że jednak sam podpis cyfrowy jest zgodny z PKCS7. Ale nawet jeśli jest, to zakopany gdzieś w środku archiwum CAB. Oczywiście format SDOC nie jest akceptowany przez żaden z wymienionych wyżej programów. Słusznie zastanawiają się ci, którzy poszukują formatu SDOC na liście formatów dopuszczonych przez rozporządzenie. Nie ma go tam. Rozporządzenie dopuszcza możliwość stosowania innych formatów, ale muszą być one zarejestrowane w ISO. Dnia 11. lutego wysłałem do Sigillum zapytanie czy ten format został zarejestrowany i czekam na odpowiedź. System podpisu elektronicznego wprowadzony przez Sigillum jest rozwiązany elegancko i byłby wygodny w stosowaniu, ale tylko wówczas gdyby był jedynym formatem na świecie. Jako element rynkowej całości wprowadza tylko dodatkowe zamieszanie. Jako format narzucony prawem do stosowania z podpisem kwalifikowanym stanowi poważną barierę dla kompatybilności, dostępności i przenośności. Konsekwencje wyboru cztery firmy, cztery formaty Polskie centra certyfikacji ze wszystkich możliwych kombinacji wybrały najgorszą każde z nich korzysta z innego formatu. W rezultacie opowieści o powszechnym i łatwym stosowaniu podpisu elektronicznego w biznesie i administracji na dzień dzsiejszy należy traktować jako mrzonki. Pojedyncze wdrożenia podpisu elektronicznego, którymi chwalą się centra certyfikacji (GIIF, serwis aukcyjny zamówień publicznych, pewien bank) nie świadczą o niczym. Dotyczą one stosunkowo wąskich grup użytkowników wymieniających się tymi samymi

podpisami między sobą i nie pozwoliły im jeszcze doświadczyć w pełni problemów z formatami. Ale jeśli ktoś zechciałby skorzystać równocześnie i z GIIF, i aukcji publicznych i z w/w banku to zauważy ze zdumieniem, że są to trzy różne podpisy elektroniczne i trzy różne aplikacje. Zgodnie z tym co mamy dzisiaj, jeśli firma A kupi certyfikat w Certum, a firma B w Sigillum, to będą mogły wysyłać sobie podpisane faktury lub umowy tylko pod warunkiem że każda będzie mieć zainstalowany program do weryfikacji podpisu przeciwnika. W skrajnym przypadku będą to cztery różne programy, z czego dwa kolidujące (rozszerzenie SIG). W praktyce nie mamy więc w Polsce jednego podpisu elektronicznego. Mamy ich cztery: podpis wg Certum, podpis wg Sigillum, podpis wg Signetu, podpis wg KIR. Pociąga to za sobą szereg problemów natury praktycznej: konieczność instalacji oprogramowania firmy, której certyfikatem będziemy podpisywać nasze dokumenty (co jest zrozumiałe), konieczność instalacji oprogramowania każdej z firm, której certyfikatem będą podpisywać swoje dokumenty nasi kontrahenci (co jest już sporą niedogodnością), problemy z używaniem równocześnie oprogramowania Certum i KIR, ponieważ obie aplikacje zawłaszczają sobie rozszerzenie SIG. Problemy te brzmią niepoważnie w XXI wieku, kiedy cały świat zmierza w kierunku otwartych standardów i wzajemnej kompatybilności. Internet wielokrotnie przechodził boje o kompatybilność ( wojny przeglądarek HTML, SSL vs PCT, IPSec vs PPTP i inne) i na dzień dzisiejszy nawet Microsoft w dużym stopniu stosuje się do powszechnie uznanych standardów (standardowy HTML w MSIE, migracja do XML w MS Office). Kolejnym problemem jest również narzucenie systemu Windows jako obowiązkowego elementu bezpiecznego urządzenia ponieważ centra certyfikacji dostarczają oprogramowanie podpisujące tylko pod ten system. Jest to sprzeczne z ideą neutralności technologicznej państwa i powtarza np. znany konflikt wokół Płatnika ZUS. Z drugiej strony warto pamiętać, że Windows stanowi nadal większość desktopów w biznesie i robienie tutaj czegoś na siłę również jest błędem (więcej na ten temat w rozdziale Rozwiązania).

Poza tym całe prawodawstwo podpisu elektronicznego jest oparte o powszechnie dostępne standardy. Zamieszanie wprowadzono dopiero na najniższym poziomie, formatów plików zastosowano kilka niekompatybilnych standardów. Zamieszanie wprowadzono w naszym rozporządzeniu dopuszczając trzy niekompatybilne formaty i dając centrom certyfikacji swobodę ich wyboru. A te wybrały sobie po jednym formacie, każde inny. Jaki format wybierze administracja i dlaczego wszystkie cztery? W kontekście planowanego wprowadzenia podpisu elektronicznego do administracji publicznej nasuwa się kilka pytań: którego z czterech dostawców, a co za tym idzie, który format wybierze administracja publiczna? czy każda jednostka administracji publicznej wybierze tego samego dostawcę, czyli ten sam format? co będzie się działo jeśli różne organy administracji wybiorą różnych dostawców? i, co gorsza, co będzie się działo jeśli te same organy w różnych miejscach wybiorą różnych dostawców? Najgorszy możliwy scenariusz jest taki, że do 16. sierpnia nie stanie się nic (czas w pewnym sensie działa na rękę centrom certyfikacji) i po tym dniu będziemy mieli na przykład następujące możliwości: kupić certyfikat i zestaw do podpisu w Certum, żeby wysyłać PIT do urzędu skarbowego w Rzeszowie (ale już np. Katowice będzie obsługiwać KIR), kupić drugi certyfikat i zestaw do podpisu w Sigillum, żeby złożyć wniosek o ścięcie drzewa na posesji w naszej gminie (ale już sąsiednią obsługuje np. Signet), kupić trzeci certyfikat i zestaw do podpisu w KIR, żeby wysłać przelew bankowy (KIR raczej nie ma konkurencji w bankach), kupić czwarty certyfikat i zestaw do podpisu w Signecie, żeby wysłać wniosek o wymianę prawa jazdy w urzędzie wojewódzkim; i tutaj się okaże, że na jednym komputerze to nie zadziała, bo program Signetu koliduje z programem Certum (oba wykorzystują rozszerzenie SIG). Taka segmentacja rynku leży w pewnym sensie w interesie centrów certyfikacji, bo zamiast jednego zestawu część instytucji będzie musiała kupić wszystkie cztery (patrz poniżej rozdział Dojna krowa ). Ale to zadziała tylko pod jednym warunkiem że uda się właśnie zmusić rynek do wykorzystywania podpisu elektronicznego w wyżej wymienionych zastosowaniach.