Paweł Krawczyk

Transkrypt

1 Paweł Krawczyk

2 Ustawa z dnia 18 września 2001 r. o podpisie elektronicznym (Dz. U. z dnia 15 listopada 2001 r.) Rozporządzenie Rady Ministrów z dnia 7 sierpnia 2002 r. w sprawie określenia warunków technicznych i organizacyjnych ( ) dla bezpiecznych urządzeń służących do składania i weryfikacji podpisu elektronicznego. (Dz. U. z dnia 12 sierpnia 2002 r.)

3 Security Administration Guide for Adobe Acrobat and Adobe Reader Version 8, Adobe, 2007 Digital Signature User Guide for Adobe Acrobat and Adobe Reader version 8.x, Adobe, 2007 Document Security User Guide for Adobe Acrobat and Adobe Reader version 8.x, Adobe, 2007 Digital signatures in Acrobat, Adobe, 2007 Digital signatures in XFA documents, Adobe, 2007 Digital signatures in the PDF language, Adobe, 2006 Acrobat SDK, Digital signature appearances, Adobe, 2006 Acrobat Digital Signature API Reference, Technical Note #5192, Adobe, 2003

4 IETF RFC 3778, The application/pdf Media Type RFC 3280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile por. X.509v3 Adobe Inc., PDF Reference - Sixth Edition - Version 1.7 (listopad 2006) ISO 32000, oparte o PDF 1.7 z poprawkami PKCS#7 Cryptographic Message Standard, RSA Laboratories, 1993 Uwaga: nazwa CMS używana dla ETSI TS (RFC 3369)

5 Sytuacja Acrobata w polskim prawie

6 Rozszerzenia, formaty danych i formaty podpisu w polskiej administracji publicznej 1. ZSI - XML-DSig generowany w UPO skrzynki podawczej Zeto Białystok (np. UMK) 2. signpro - S/MIME enkapsulujący dokument podpisany programem Sigillum Sign Pro 3. XML - XAdES enkapsulujący dokument podpisany programem Sigillum Sign Pro 4. XML - XAdES generowany w UPO skrzynki podawczej Certum (np. ZUS) 5. SDOC - binarny format enkapsulujący dokument podpisany starą wersją Sigillum Sign SIG - binarny CMS enkapsulujący dokument podpisany programem Certum Sign oraz nową wersją Sigillum Sign Pro 6. SIG - binarny PKCS#7 enkapsulująćy dokument podpisany programem KIR SafeDevice 7. SIG -XAdES, używany przez TPSA do zapisywania zewnętrznego podpisu do faktury elektronicznej (na komponentach Sigillum) 8. P7 - PKCS#7 enkapsulujący dokument podpisany programem Sigillum Sign Pro 9. XADES - XAdES enkapsulujący dokument podpisany programem nową wersją KIR SafeDevice Fakt konieczna standardyzacja Wspólna deklaracja polskich CA, E-faktura: fakty i mity, 2005

7 Acrobat 8 a podpis elektroniczny Bogata biblioteka funkcji związanych z podpisem Różne warianty np. weryfikacji podpisu Mogą one zaspokoić różnorodne wymagania Różne wymagania w różnych krajach Brak spójności nawet w ramach UE Zgodność z regulacjami lokalnymi Wybór ściśle określonego podzbioru funkcji Acrobata W praktyce zapewniana przez pluginy Analogiczne projekty w Niemczech, Włoszech

8 Gdzie lokuje się w polskim prawie Acrobat? Bezpieczny podpis wymaga Kwalifikowanego certyfikatu Bezpiecznego urządzenia do składania podpisu Bezpieczne urządzenie to Komponent techniczny - karta z kluczem prywatnym Oprogramowanie podpisujące Analogicznie b.u. do weryfikacji Acrobat jest oprogramowaniem podpisującym i weryfikującym

9 Podmiot może wprowadzić na rynek nowe bezpieczne urządzenie W praktyce Komponent techniczny zapewniany przez CA Swoboda we wprowadzaniu oprogramowania podpisującego Obowiązki dostawcy oprogramowania Deklaracja zgodności Deklaracja, że oprogramowanie składa (weryfikuje) podpis zgodnie z wymaganiami ustawy

10 Jednostronna, nie weryfikowana z góry Znacznie mniej zachodu niż certyfikat Oparta o fakty Audyt wewnętrzny lub zewnętrzny Wyraża przekonanie dostawcy o zgodności Dołożenie najwyższej staranności w jej zapewnieniu

11 Ścisła (dosłowna) realizacja wymagań w aplikacjach udostępnianych przez centra Mimo tego różnice w interpretacji oraz braki Niska używalność i ergonomia Luźniejsza realizacja wymagań w aplikacjach firm trzecich Wyższa używalność i ergonomia Czasem w ogóle brak publicznie dostępnej deklaracji zgodności

12 Wymagania dotyczące środowiska Realizowane przez zalecenia co do sposobu używania Wymagania dotyczące formy Np. prezentacja dokumentu, komunikaty, ostrzeżenia, wynik weryfikacji Wymagania związane z PKI Specyfika weryfikacji ścieżki

13 Czyli o oprogramowaniu publicznym i niepublicznym

14 Rozporządzenie wyróżnia podział na Oprogramowanie publiczne Oprogramowanie niepubliczne Pojęcie wywodzące się ze standardów unijnych CWA Guidelines for the implementation of Secure Signature-Creation Devices Cele Gradacja profilu ryzyka Gradacja poziomu zabezpieczeń Gradacja kosztu platformy Według kryterium środowiska, w jakim jest stosowane

15 Kryterium dostęp dla każdej osoby Prawdopodobne przykłady Kiosk internetowy, urzędomat Wyższe wymagania bezpieczeństwa Bezpieczny kanał, bezpieczna ścieżka Zaufany kanał karta-program i plik-program W praktyce: specjalizowany system operacyjny, MAC (Mandatory Access Control) Niewielka praktyka

16 Kryterium W normalnych warunkach nie ma dostępu każdy W szczególności oprogramowanie w domu, biurze, komórce Niższe wymagania Brak obowiązku bezpiecznego kanału i ścieżki W praktyce Jedyna możliwość prawna by podpisywać na zwykłym laptopie z Windows i czytnikiem

17 Podział archaiczny w XXI wieku Co do znaczy dostęp? Do laptopa z publicznym IP ma dostęp każdy Powszechność koni trojańskich, rootkitów, łamania haseł Systemy biurowe jak najbardziej zasługują na bezpieczny kanał i ścieżkę ale gdyby tego wymagano to nie można byłoby ich używać Brak takich mechanizmów w popularnych systemach operacyjnych ze względu na nieużywalność

18 Może być taki lub taki! W zależności od sposobu użycia przez użytkownika Program ma niewielki wpływ na środowisko w jakim jest używany Rozwiązanie Zapis w licencji i podręczniku nie jest oprogramowaniem publicznym w rozumieniu przepisu powinno być stosowane w środowisku wolnym od złośliwego oprogramowania, wyposażonym w firewall Że to żadne zabezpieczenie w praktyce? Być może, ale powszechnie stosowane Inaczej się nie da Ograniczenie odpowiedzialności dostawcy

19 Interakcja Acrobata z kartą kryptograficzną

20 Komponent techniczny (karta) Przez aplikację widziany jako middleware (PKCS#11 lub CSP) Niewielka kontrola aplikacji nad komponentem technicznym Ograniczona do możliwości wyboru middleware Niewielki faktyczny wpływ na bezpieczeństwo W systemie Windows szerokie możliwości przejmowania wywołań API Ograniczenie używalności

21 Utrudnienie praktyczne Konieczność ustalenia a priori listy dopuszczanych sterowników Centra mogą wprowadzać nowe karty konieczność aktualizacji Co z centrami zagranicznymi (art. 4 ustawy)? Zalecane rozwiązanie prawne stosowanie tylko z komponentem technicznym zgodnym z wymaganiami ustawy... Zalecane rozwiązanie techniczne Możliwość składania podpisu tylko certyfikatem kwalifikowanym Implikuje komponent techniczny zgodny z ustawą ale co to znaczy certyfikat kwalifikowany omówimy później

22 Zapewnienie zgodności z ustawą o podpisie elektronicznym

23 Wiele różnych form podpisu Długa tradycja graficznego faksymile podpisu Też digital signature.. Specyficzne nazewnictwo, nie zawsze zbieżne z PKI Możliwość połączenia digital digital i digital faksymile

24 Podział funkcjonalny Certification signature (DocMDP, author signature ) Jeden na dokument, np. poświadczenie autentyczności Approval signature Możliwe wiele podpisów approval w dokumencie, np. aprobata treści Podział techniczny FieldMDP podpis z blokadą niektórych pól Reader-enabled włącza funkcje podpisu w Readerze przez dodanie odpowiedniego pola w dokumencie/formularzu (UR3) Data signature podpis pod danymi z formularza XFA wysłanym przez HTTP

25 Możliwość łączenia różnych form podpisu w jednym dokumencie Po podpisaniu zawsze możliwy podgląd wersji podpisanej ( preview mode, view signed version )

26 Format PDF (ISO PDF 1.7+) jako kontener Treści dokumentu Pustego formularza Danych wpisanych do formularza Podpisu elektronicznego PKCS#7 - formatu podpisu w PDF (RFC 3778) Zgodny z rozporządzeniem XML-DSig - format podpisu formularza XFA Przy wysyłaniu XFA po HTTP (XML) Punkt wyjścia do XAdES (ETSI TS ), wymaganego przez rozporządzenie

27 Ogromna biblioteka funkcji PKI w Acrobacie Domyślnie ustalony pewien podzbiór ustawień Miejscami niezgodny z polską ustawą Możliwość dodania własnego handlera podpisu Nie wydaje się konieczne wobec funkcji dostępnych w Acrobacie Ogromna liczba ustawień przez rejestr Ustalenie i zablokowanie ustawień zgodnych z ustawą 95% konfiguracji przez rejestr (np. adresy CRL), 5% dostępne przez GUI

28 HKCU\Software\ Adobe\Acrobat Reader\8.0\Security caspki Inne Dokumentacja Administrator Guide Zaleta Możliwość aktualizacji, np. certyfikatów nowych CA, adresów CRL

29 Tylko podpis w kontenerze PDF głównie ustawienia rejestrowe Ustawienia składania i weryfikacji podpisu Certyfikaty polskich CA (też przez rejestr) Adresy CRL, OCSP, serwery TSP Formularze XFA wysyłane po HTTP Ustawienia rejestrowe j.w. Plugin implementujący XAdES Konieczność odtwarzania ustawień rejestru przy każdym uruchomieniu Plugin

30 Konkretne wymagania techniczne wobec Acrobata

31 prezentacja podpisywanej treści użytkownikowi przed podpisaniem przyjęcie od użytkownika kodu PIN i uwierzytelnienie go na karcie kryptograficznej przesłanie skrótu podpisywanych danych do karty pobranie z karty podpisanego skrótu, formatowanie i dołączenie go do dokumentu

32 Użytkownik musi widzieć co podpisuje Ryzyko podpisania niekorzystnej treści Zagrożenie ze strony aktywnych treści Ryzyko podmiany fragmentów tekstu przez skrypty Różnica między tym co widoczne, a tym co faktycznie jest w treści Konieczność ustalenia ( zamrożenia ) treści przed podpisaniem

33 Aplikacja musi umożliwić prezentację danych Przed podpisaniem Po weryfikacji Dlaczego tylko umożliwić prezentację a nie musi prezentować? Podpis wielokrotny (multisign) Podpisywanie serii dokumentów (e-faktura)

34 PDF umożliwia embedowanie multimediów oraz skryptów JavaScript, FormCalc Implementacja Acrobata Elastyczna bezpieczeństwo, ale i używalność Podpis zamrożonej, statycznej wizualizacji dokumentu (wygląda jak wydruk) Konwersja filmów na postery pierwsza klatka jako statyczny obraz Podpisana treść tylko do odczytu Późniejsze zmiany możliwe, ale wyraźnie widoczne Zależy też od rodzaju podpisu ( certification vs approval ) Specyfikacja celu podpisania dokumentu otrzymałem, przeczytałem i zgadzam się, jestem autorem, chcę zapewnić autentyczność i integralność różne formy niezaprzeczalności (lub jej brak)

35 Formularz podpisany Formularz aktywny

36 Wariant PDF/SigQ (PDF 1.7) Poziomy zgodności ( SigQ compliance ) SigQ 1-A Dokument nie zawierający treści dynamicznych lub odwołujących się do zasobów zewnętrznych SigQ 1-B Dokument zawiera treści dynamiczne, ale są one wyłączone w trybie przeglądu ( preview ) Weryfikacji poziomu zgodności dla konkretnego dokumentu Ustawienia dokumentu z poziomu LiveCycle Designera mają duży wpływ na jego statyczność Formularze e-deklaracji weryfikują się jako SigQ 1-B compliant

37 Poprzedzenie podpisu wyraźnym ostrzeżeniem Zapis w ustawie, nie w rozporządzeniu Różna praktyka Nowe okno kontynuacja operacji będzie równoważna kliknij OK Sigillum Sign Pro, Certum Sign, KIR SafeDevice, e-deklaracje Brak specjalnych okien ebcommunicator Realizacja możliwa za pomocą Mechanizm lokalizacji Acrobata Plugin (jak w e-deklaracjach)

38 Wymagania techniczne wobec procesu weryfikacji podpisu

39 Dwa rodzaje wymagań ustawowych Niskopoziomowe cechy PKI Np. algorytmy, długość kluczy, Realizowane przez poprawną implementację standardów PKI Udowodnienie niemożliwe bez kodu źródłowego Możliwa deklaracja zgodności na podstawie dokumentacji Adobe Wymagania organizacyjne wobec PKI Np. procedura weryfikacji ścieżki Realizowane przez wybór jednego sposobu postępowania z wielu możliwych w Acrobacie Wskazanie sposobu postępowania Acrobatowi przez rejestr Możliwa weryfikacja poprawności przy pomocy testu lub audytu Podstawa do wystawienia deklaracji zgodności

40 Sprawdzenie ważności całej ścieżki Weryfikacja list CRL i ARL zawsze Konieczna zmiana domyślnego zachowania ( jeśli dostępne ) Przez rejestr Konieczność wskazania list CRL Brak opcji w GUI Przez rejestr, według adresów URL Zalecane wskazanie polityk Brak opcji w GUI Przez rejestr, według OIDów

41 Wynik weryfikacji według ustawy Poprawnie zweryfikowany Negatywnie zweryfikowany Niekompletnie zweryfikowany Wszystkie programu na rynku stosują się do tego dosłownie W fabrycznym Acrobacie 8.0 Niejasne tłumaczenie ( zatwierdź podpis ) Brak jednoznacznej prezentacji w/w wyniku Kolorowe ikonki, punkty w oknie weryfikacji

42 Rozszerzenia X.509 basicconstraints, keyusage Acrobat - zgodnie z PKI Pola certyfikatów Właściciel, Wystawca, Dwa podejścia do weryfikacji pól Ufamy centrom Certyfikat jest zadeklarowany jako kwalifikowany Zakładamy że jest zgodny z ustawą Łatwa akceptacja certyfikatów zagranicznych, jeśli root będzie w ścieżce (ważne z uwagi na art. 4 ustawy) Zgodnie z ustawą Weryfikacja dosłownie według litery rozporządzenia Problem z atrybutami NIP, PESEL w polu Właściciel i Nr wpisu w polu Wystawca

43 FeatureLockdown Zablokowanie zmiany ustawień przez GUI Odświeżanie ustawień rejestru Przy każdym uruchomieniu aplikacji Realizowane przez plugin Gwarantuje zgodność po aktualizacjach programu Możliwość aktualizacji i zmiany ustawień Adresy URL - CRL, ARL, OCSP, TSP Certyfikaty root centrów kwalifikowanych Polityki certyfikacji

44 bselfsigncertgen=0 imsstoretrusted=0 bcertstoreimport=0 asignhash=sha1 asignformat=adbe.pkcs7.detached bisenabled=1 benforcesecurechannel=1 TSP/iHashAlgo=SHA1 ballowreasonwhensigning=1 ishowdocumentwarnings=1 averifyusealways=1 ivaliditymodel=0 isigverificationtime=1 cverify\ireqrevcheck=3 csign\ireqrevcheck=2 bcheckcabasicconstraints=1 iusearchivedrevinfo=1

45 Paweł Krawczyk