Podpisywanie dokumentów multimedialnych na przykładzie HTML

Stanąłem kiedyś przed zadaniem podpisania (z wykorzystaniem bezpiecznego podpisu elektronicznego w formacie XAdES) prostego pliku XML. Wyglądał mniej-więcej tak:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="https://www.klimek.ws/test/test.xsl"?>
<dokument>
<aaa>fdgsdfgs</aaa>
</dokument>

Zadanie na pierwszy rzut oka wydaje się banalne. Wystarczy bowiem wykorzystać jedną z dostępnych powszechnie bibliotek, służących do obsługi tego formatu podpisu, zbudować odpowiednią strukturę podpisu i wydać polecenie "Podpisz".

Po wykonaniu prostego podpisu, dumny z (pozornie) szybkiego załatwienia sprawy, spojrzałem do wymagań polskiej ustawy o podpisie elektronicznym i wydanych do niej rozporządzeń. Znalazłem tam między innymi zapis: Bezpieczne urządzenia do składania podpisów elektronicznych zapewniają możliwość prezentacji przeznaczonych do podpisania danych... Podobne zapisy pojawiają się też w kontekście weryfikacji podpisu.

W tej chwili zacząłem się zastanawiać, czy jestem w stanie w jakikolwiek sposób spełnić ten wymóg. Przecież za wizualizację tego dokumentu XML odpowiada zewnętrzny względem niego plik XSL, który może być dowolnie zmieniany i modyfikowany. W ten sposób aplikacje podpisujące i weryfikujące nie będą miały pewności, że w czasie weryfikacji prezentowane są te same dane, które były prezentowane przy podpisywaniu. Nie za bardzo da się też przerzucić odpowiedzialność za dostępność i poprawność odpowiedniego pliku XSL na użytkownika - w końcu XSL może znajdować się na zewnętrznym serwerze WWW, pozostającym poza jego kontrolą. Pojawia się więc potencjalne pole do nadużyć.

Rozwiązaniem, które okazało się być pomocne, było podpisanie zewnętrznej referencji do dokumentu za pomocą elementu Reference. W efekcie jakakolwiek modyfikacja zawartości pliku XSL powoduje błąd weryfikacji złożonego podpisu. Takie rozwiązanie nie jest, niestety, idealne - uniemożliwia bowiem jakąkolwiek modyfikację i uaktualnienie XSL. Istnieje również ryzyko, że nieświadomy administrator serwera wprowadzi w nim niewiele znaczące modyfikacje, w wyniku czego wartość dowodowa wszystkich podpisanych wcześniej dokumentów ulegnie znacznemu obniżeniu. Na dzień dzisiejszy nie udało mi się jednak znaleźć innego rozwiązania - no, może za wyjątkiem e-Paczki, która wzbudza moje wątpliwości z punktu widzenia funkcjonalności i ergonomii jej wykorzystania, i przyjętego przez MSWiA rozwiązania, zakładającego publikowanie wzorcowego pliku XSL w publicznie dostępnym miejscu - Centralnym Repozytorium Dokumentów. Rozwiązanie ministerialne także nie jest pozbawione wad - ile procent użytkowników będzie sprawdzać, czy XSL jest zgodny z opublikowanym w repozytorium?

Tak czy inaczej - wypracowane zostało pewne rozwiązanie problemu. Jednakże okazuje się, że nie jest ono idealne. XSL służył bowiem do przekształcenia dokumentu XML do formatu HTML, który z kolei był prezentowany w oknie przeglądarki internetowej. Technologia HTML ma zaś to do siebie, że umożliwia wprowadzanie dalszych odwołań do obiektów zewnętrznych: obrazków, styli CSS, skryptów JavaScript, stron w ramkach (frame), a nawet apletów Java czy kontrolek ActiveX. Co więcej, niektóre z wymienionych mogą z kolei wykorzystywać kolejne obiekty. Jeśli obiekty te mogą zostać pobrane i zabezpieczone w ramach generowanego podpisu, to problem nie jest zbyt duży - sprowadza się jedynie do programistycznego opracowania odpowiedniego rozwiązania (choć nie słyszałem, by ktoś coś takiego zrobił). Gorzej, gdy pobierane elementy mogą się za każdym razem zmieniać (na przykład obrazki typu CAPTCHA, które dla każdego żądania są inne) lub tworzone są w sposób dynamiczny, a nawet interaktywny, poprzez "dyskusję" z użytkownikiem. W praktyce nie da się takich danych podpisać.

Podpisanie dodatkowych obiektów zwiększa też ryzyko ich przypadkowej modyfikacji, a więc utraty przez cały dokument wartości dowodowej. W tej sytuacji pewnym rozwiązaniem może okazać się stworzenie odpowiedniego narzędzia do weryfikacji, informującego o ewentualnych błędach weryfikacji w sposób maksymalnie "inteligentny", pozwalający zaufać użytkownikowi nawet po modyfikacji niektórych powiązanych obiektów. Niestety, nie tylko aplikacje, ale i polskie przepisy takiego scenariusza nie przewidują.

Oczywiście trzeba mieć świadomość, że zasugerowane ataki na są na dzień dzisiejszy czysto abstrakcyjne - choć moim zdaniem dość proste do przeprowadzenia. Z formalnego punktu widzenia dostawcy oprogramowania podpisującego mogą się zabezpieczyć przed takimi atakami, twierdząc, że podpisywanymi danymi jest kod XML (i umożliwiając wizualizację tego kodu XML przed podpisem). Podejście takie, choć powszechnie stosowane w branży IT, kłóci się jednak z zasadami szeroko rozumianej "używalności" i ergonomii. Rozwiązania zrobione pod prawników, a nie pod użytkowników, nie mają prawa przyczynić się do popularyzacji stosowania podpisu elektronicznego.

Omawiany problem nie dotyczy tylko dokumentów XML czy HTML. Z podobną sytuacją mamy do czynienia na przykład przy podpisywaniu dokumentów Worda czy OpenOffice, a także wielu innych aplikacji. To już jednak temat do kolejnych badań i na oddzielny artykuł.

Komentarze

Ale podpisywanie Reference do XSL wcale nie jest takie złe. Problem zmian XSL można łatwo obejść stosując wersjonowanie tego pliku oraz jego nazwy. Dzięki temu podpisany dokument zawsze będzie wizualizowany za pomocą dokładnie tej wersji, z którą został podpisany.

Co do Centralnego Repozytorium Dokumentów to najpierw musiałoby działać - przez ostatnie kilka miesięcy serwer www.crd.gov.pl w ogóle nie działał, od paru dni ten adres jest przekierowany na stronę e-PUAPu, który... też raczej nie działa :)

Ale podpisywanie Reference do XSL wcale nie jest takie złe.

Wiem, i właśnie takie rozwiązanie zazwyczaj promuję w praktyce - co wcale nie znaczy, że jest ono idealne :).

1) Załącznik w postaci PDF z konferencji e-Administracja nie jest dostępny bez zalogowania, a opcji logowania na stronie nie ma :) Proponuję OpenID.

2) Captcha tekstowe powinno unikać podobnych znaków np. l (małe L) i I, które wyglądają w nim tak samo.

napisał Pan "jedną z dostępnych powszechnie bibliotek". Z tego co widzę to to potrafi ona składać podpis w formacie xmldsig a z tego co wyczytałem w dokumentach dotyczacych o e-administracji wymagany jest chyba XADES (a dokładniej chyba XADES-T). I tu moje pytanie - czy zna Pan takie darmowe biblioteki, które realizują podpis w formacie XADES? I na ile generowane przez nie dokumenty są zgodne z polskim prawem? Widziałem w sieci jedynie projekt OpenXades, ale jest to chyba nie w pełni zgodna ze standardem implementacja (stosowana w Estonii). Jeżeli to możliwe to liczę na odpowiedź w tym wątku.

Witam

Złożenie podpisu XAdES-BES przy dostępności bibliotek xmldsig nie jest wcale skomplikowane (choć nieco pracochłonne). Nieco większym wyzwaniem jest zbudowanie struktur XAdES-T, ale jest to także możliwe. Dostępne są biblioteki komercyjne - ja zetknąłem się z implementacją IAIK XAdES.

Jako ciekawostkę można tu wymienić biblioteki udostępniane przez PEMI - ale na ich temat nie mogę się wypowiedzieć, bo ich nie testowałem. Nie udało mi się też znaleźć linku do ich pobrania ani żadnej dokumentacji (choć nie szukałem zbyt intensywnie).

Ja też szukałem i na stronach PEMI tych bibliotek póki co nie znajdziesz, informacja o nich jest tam już od co najmniej roku. Znalazłem za to kilka innych projektów, jednak nie wiem dokładnie jak sprawdzić ich zgodność z tym czego wymaga się w naszym prawie, bo jak wiadomo implementacje różnią się między sobą.

ciekawostka: do zastosowań open-source biblioteki IAIK są dostępne nieodpłatnie

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.