E-podpisowy groch z kapustą

Wszyscy czterej wystawcy certyfikatów kwalifikowanych w Polsce deklarują pełną zgodność ze standardami. I faktycznie, każda z firm jest zgodna ze standardami zaleconymi przez ustawę o podpisie elektronicznym. Problem polega na tym że każda z innym...

Podpis elektroniczny znowu zyskał popularność w mediach po tym jak podpisane zostało rozporządzenie o e-fakturach.

Teraz wszyscy przedsiębiorcy mogą wysyłać sobie faktury w formie elektronicznej podpisane bezpiecznymi certyfikatami kwalifikowanymi. Szybko, bezpiecznie, tanio. Taka przynajmniej jest teoria. Przechodząc od gładkiej teorii do znienawidzonej praktyki zauważymy że rzeczywistość wcale nie jest taka różowa.

Format plików generowanych przez programy do składania bezpiecznego podpisu elektronicznego określa rozporządzenie o warunkach technicznych do ustawy o podpisie elektronicznym. 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.
3. PKCS7 binarny format będący poprzednikiem 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, PKCS7 jest uboższy (na przykład nie przechowuje informacji o znacznikach czasowych). Dlaczego ustawodawca dał narodowi taką dowolność? Trudno powiedzieć. W każdym razie srogo się to zemściło, ale o tym dalej.

W świecie idealnych systemów informatycznych (który na pewno gdzieś istnieje) księgowa firmy "A" mogłaby kupić certyfikat kwalifikowany w jednej z czterech uprawnionych do tego firm, zainstalować oferowaną przez nich aplikację i zacząć wysyłać e-faktury z bezpiecznym podpisem cyfrowym.

Kontrahent z firmy "B" nie musi kupować certyfikatu w tej samej firmie, a wręcz nie musi go kupować wcale tylko po to by sprawdzać poprawność faktur wysłanych przez "A". Jeśli chciałby również wystawiać bezpieczne podpisy to proszę bardzo - może kupić sobie certyfikat w innej firmie i przy jego pomocy podpisywać faktury i wysyłać je do "A". Ponieważ wszędzie posługujemy się standardami, każda ze stron powinna być w stanie zweryfikować podpis złożony za pomocą certyfikatu innego wystawcy. Format certyfikatu jest przecież standardowy, na każdym kroku mamy standardy - PKCS12, PKCS10, PKCS7, X.509, S/MIME i inne. Wszystkie otwarte i ogólnodostępne.

Postanowiliśmy sprawdzić jak wygląda wzajemna kompatybilność podpisów cyfrowych generowanych przez programy czterech polskich wystawców certyfikatów. W testach braliśmy pod uwagę następujące firmy i oferowane przez nie programy (co było uzależnione od tego jakie programy są dostępne za darmo ze stron poszczególnych firm):

1. Certum oferuje darmowe certyfikaty testowe i darmowy program proCertum CombiLite, testowaliśmy składanie i weryfikację podpisów.

2. Signet oferuje darmowe certyfikaty testowe oraz dwa programy - Signet Confidant (do podpisywania) oraz Singet Proofer (do weryfikacji). Ponieważ do testów dostępny jest tylko ten drugi, testowaliśmy tylko weryfikację.

3. Krajowa Izba Rozliczeniowa (KIR) oferuje program SafeDevice w wersji demo wraz z testowym certyfikatem, mogliśmy więc przetestować podpisywanie oraz weryfikację podpisów.

4. Sigillum oferuje darmową wersję programu Sigillum Sign do podpisywania i weryfikacji, ale ponieważ nie udostępnia certyfikatów testowych więc przetestowaliśmy tylko weryfikację.

Wszystkie aplikacje instalują się i działają bez problemu. Składanie podpisów i ich weryfikacja w ramach jednego wystawcy certyfikatów działa jak po maśle. Problemy pojawiają się jeśli chcemy wymieniać się podpisami między poszczególnymi firmami.

A co ze standardami? Okazuje się że każda firm co prawda formalnie zastosowała się do rozporządzenia o warunkach technicznych ale... każda wybrała sobie inny format! Paranoik mógłby pomyśleć że się ze sobą umówiły tak żeby przypadkiem ich systemy podpisów nie były ze sobą kompatybilne.

Jednak ponieważ formaty do wyboru były trzy, a firm cztery więc powstał problem. Jak nie dopuścić do tego by dwóch wystawców implementowało ten sam standard? Okazuje się że Polak potrafi i ten problem udało się kreatywnie rozwiązać, wymyślając własny format niekompatybilny z żadnym poprzednim!

1. Program proCertum CombiLite zapisuje podpisy cyfrowe w formacie CMS. Żaden inny testowany program nie był w stanie zweryfikować tak złożonego podpisu.

2. KIR oraz jego aplikacj SafeDevice stworzona przez firmę BSB zapisuje podpis cyfrowy w formacie PKCS7. Ten podpis okazał się rodzynkiem bo 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. Może to stwarzać problemy ponieważ obydwa programy przywłaszczają sobie prawo do plików z rozszerzeniem SIG.

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. Przypuszczamy że 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 plikach, to znaczy z menu wybieramy fizyczny plik 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 plików.

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.

Po bliższym przyjrzeniu się SDOC okazuje się że jest to po prostu 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. Kontakt z infolinią Sigillum potwierdził że jest to format opracowany przez tę firmę jednak podpis cyfrowy jest zgodny z PKCS7. Z braku możliwości przetestowania tego w praktyce nie jesteśmy w stanie jednoznacznie stwierdzić że format SDOC jest niekompatybilny z czymkolwiek innym ale jest to prawdopodobne biorąc pod uwagę że Sigillum Sign nie chce wczytywać plików z podpisem wygenerowanych przez żaden inny program. Program oczekuje tylko i wyłącznie plików SDOC. Czyli CAB. Oczywiście każdy z programów podpisuje pliki tylko certyfikatem wystawionym przez swojego producenta.

Jak widać rodzimi producenci oprogramowania po raz kolejny wykazali się ambicją i uznali że wszelkie kompromisy lub zgodność formatów są dla mięczaków. Teoretycznie można było się dogadać i wybrać jeden z zaproponowanych przez ustawodawcę formatów tak by uzyskać wzajemną kompatybilność cyfrowych sygnatur. Jednak czy to z powodu niefrasobliwości czy też zmowy cztery firmy starające się promować podpis wśród przedsiębiorców oferują cztery niekompatybilne formaty plików spośród trzech dopuszczonych przez ustawodawcę.

Jak to wygląda z punktu przedsiębiorcy, który chciałby korzystać z podpisu elektronicznego? Załóżmy że firma zainteresowana wystawianiem e-faktur zakupi certyfikat np. w Certum, otrzyma program proCertum Signer i będzie wysyłać podpisane faktury do kontrahenta. Ten będzie musiał zainstalować proCertum CombiLite żeby je weryfikować. Jeśli kontrahent również będzie wysyłać podpisane dokumenty ale przypadkiem kupi certyfikat np. w KIR to powstanie absurdalny, asymetryczny układ w którym każda z firm będzie podpisy wystawiać jednym programem, a weryfikować drugim.

Jeśli przedsiębiorca będzie od jednego kontrahenta otrzymywać dokumenty podpisane certyfikatem Certum a od drugiego certyfikatem KIR to powstawnie konflikt, bo obie wzajemnie niekompatybilne aplikacje zawłaszczają sobie pliki z rozszerzeniem SIG.

Sytuacja w której firma otrzymuje dokumenty podpisane certyfikatami każdej z czterech firm jest nie do pozazdroszczenia, bo trzeba będzie zainstalować wszystkie cztery programy do weryfikacji. I w tej właśnie sytuacji znajdą się na pewno inspektorzy skarbowi, którzy będą kontrolowali poprawność faktur.

Każdy z producentów znajdzie zapewne dziesiątki powodów dlaczego "jego" format jest lepszy od innych. Jednak jako zbiorowość zapomnieli oni o tym że oprogramowanie, które tworzą ma służyć użytkownikom którzy mogą mieć różne preferencje odnośnie wyboru usługodawcy. Wielkie firmy software'owe również prowadziły w latach 90-tych "wojny na standardy", które skończyły się tym że nawet Microsoft z podkulonym ogonem przestał wprowadzać prywatne protokoły i oparł się o otwarte standardy tworzone przez instytucje takie jak W3C i IETF.

Dzięki temu email podpisany elektronicznie w programie Outlook zgodnie ze standardem S/MIME będzie bez problemu odczytany w Mozilli pod Windows, Linuksem czy na Macintoshu. Tak też powinno być z e-podpisem. Dokument podpisany programem KIR powinno się dać zweryfikować programem każdego z trzech pozostałych wystawców. Nie ma ku temu przeszkód technicznych, bo wszystkie programy korzystają z tyc samych algorytmów kryptograficznych i protokołów. Niekompatybilność wprowadzono dopiero na poziomie reprezentacji pliku wynikowego.

Proszę się zatem nie dziwić że przedsiębiorcy nadal, od czterech lat, patrzą na podpis elektroniczny jak na drogi i dziwaczny gadżet.