Vagla zwraca uwagę na nieścisłości w przepisach regulujących kwestię składania wniosków do urzędów drogą elektroniczną. Ja się za to zastanawiam, kto i ile wziął pieniędzy za te wszystkie wynalazki. Nie można było prościej?
Wymagana infrastruktura
- Jeden miejski (bądź centralny) urząd ewidencji ludności;
- Jeden serwer kluczy PGP administrowany przez tenże urząd;
- Jedna para kluczy (klucz publiczny i prywatny) PGP wygenerowana przez tenże urząd i fakt udostępnienia klucza publicznego na serwerze urzędu, zaś jego identyfikatora odcisku na stronie tegoż urzędu;
- Jedna baza danych, która pozwala do każdego klucza publicznego przypisać jeden identyfikator PESEL;
- Jedna pani w okienku
Rejestracja wzoru podpisu
- Obywatel generuje parę kluczy PGP o okresie ważności nie dłuższym niż przewidziany ustawowo (powiedzmy, że będzie to kwartał);
- Obywatel generuje zlecenie unieważnienia swojego klucza publicznego;
- Obywatel drukuje zlecenie unieważnienia w formie przyswajalnej przez komputer, na przykład w postaci kodu kreskowego, co pozwoli skorzystać z niego w okienku (po okazaniu dowodu osobistego) w przypadku utracenia wyłącznej kontroli nad kluczem prywatnym;
- Obywatel umieszcza swój klucz publiczny na serwerze kluczy dostarczonym przez urząd;
- Obywatel drukuje identyfikator odcisku swojego klucza publicznego w formie przyswajalnej przez komputer (kod kreskowy) na wniosku o poświadczenie odcisku klucza;
- Obywatel z wydrukowanym powyżej wnioskiem udaje się do urzędu, gdzie składa wniosek legitymując się dowodem osobistym;
- Pani w okienku przykłada formularz do czytnika, jej komputer pobiera informacje o kluczu z serwera urzędu i pozwala na potwierdzenie imienia i nazwiska z formularzem i okazanym dokumentem tożsamości;
- Serwer podpisuje wskazany klucz publiczny obywatela z poświadczeniem pełnego zaufania dla umieszczonych tam danych za pomocą klucza prywatnego urzędu, po czym publikuje go ponownie na serwerze urzędu;
- Serwer umieszcza w swojej bazie danych informację o skojarzeniu danego klucza z numerem PESEL nadanym obywatelowi;
Złożenie podpisu pod dokumentem
- Obywatel pobiera bądź tworzy dokument, który ma następnie zostać podpisany;
- Obywatel podpisuje dokument za pomocą klucza prywatnego odpowiadającego kluczowi umieszczonemu i podpisanemu wcześniej na serwerze urzędu;
- Obywatel dokument wraz z podpisem przesyła do urzędu;
- Urząd przesyła obywatelowi poświadczenie w postaci złożonego wcześniej podpisu podpisanego ponownie kluczem prywatnym urzędu;
Unieważnienie wzoru podpisu
Zawsze może zdarzyć się tak, że obywatel utraci swój klucz prywatny lub klucz ten wpadnie w ręce osób trzecich. Wersja pierwsza:
- Obywatel generuje zlecenie unieważnienia klucza publicznego za pomocą swojej kopii klucza prywatnego;
- Obywatel importuje unieważnienie do swojego lokalnego pęku kluczy, tym samym unieważniając lokalną kopię swojego klucza publicznego;
- Obywatel publikuje ponownie swój klucz publiczny na serwerze urzędu, tym samym unieważniając swój wzór podpisu;
- Ponowne złożenie podpisu wymaga ponownego przejścia przez procedurę rejestracji wzoru podpisu;
Wersja druga:
- Ponieważ obywatel utracił swoją kopię klucza prywatnego (na przykład w wyniku kradzieży), udaje się do urzędu z wydrukowanym wcześniej unieważnieniem klucza;
- Pani w okienku przeciąga unieważnienie przez czytnik;
- Serwer importuje unieważnienie, a następnie ponownie publikuje unieważniony już klucz na serwerze kluczy;
- Pani mówi
dziękuję, następny;
- Ponowne złożenie podpisu wymaga ponownego przejścia przez procedurę rejestracji wzoru podpisu;
Wersja trzecia:
- Ponieważ obywatel utracił swoją kopię klucza prywatnego i zgubił wydrukowane wcześniej zlecenie unieważnienia, wypełnia formularz unieważnienia na papierze, podając powód i swoje dane osobowe i udaje się z nim do urzędu;
- Pani w okienku sprawdza zgodność danych na wniosku, dokumencie tożsamości i w bazie danych;
- Serwer unieważnia swój wcześniejszy podpis zaufania pod kluczami publicznymi skojarzonymi z numerem PESEL obywatela, a następnie publikuje je ponownie, tym samym wyłączając je z użytku jako podpis akceptowany przez urzędy;
- Ponowne złożenie podpisu wymaga ponownego przejścia przez procedurę rejestracji wzoru podpisu;
Wersja czwarta:
- Wygasa data ważności klucza obywatela;
- Ponowne złożenie podpisu wymaga ponownego przejścia przez procedurę rejestracji wzoru podpisu;
Zmiana klucza prywatnego urzędu
Para kluczy urzędu ze względów bezpieczeństwa również powinna mieć ograniczony czas ważności. Może się również zdarzyć, że klucz prywatny urzędu dostanie się w niepowołane ręce:
- Urząd generuje nową parę kluczy GPG;
- Nowy klucz publiczny urzędu zostaje opublikowany na serwerze kluczy;
- Identyfikator odcisku klucza publicznego zostaje opublikowany na stronie urzędu;
- Serwer podpisuje dotychczas podpisane klucze publiczne obywateli za pomocą nowego klucza prywatnego urzędu, udzielając im pełnego zaufania;
- Serwer unieważnia dotychczas używany klucz publiczny urzędu za pomocą jego klucza prywatnego, jako powód podając zastąpienie go nowym kluczem;
Różnice w stosunku do stanu obecnego
- Koszty utrzymania infrastruktury są praktycznie zerowe;
- Fizyczny koszt uzyskania wzoru podpisu przez obywatela jest zerowy;
- Nakład urzędu w celu przyjęcia bądź unieważnienia wzoru podpisu jest minimalny;
- Forma ta nie faworyzuje żadnych podmiotów gospodarczych;
- Całość działa również poza platformą Windows;
- Stosowne aplikacje klienckie można przygotować w ciągu jednego wieczoru, w dowolnym języku programowania i nie wymaga to milionowych przetargów;
- Wiele innych serwisów (nie tylko państwowych) może użyć kluczy podpisanych urzędowo choćby w celu weryfikacji rejestrujących się użytkowników (serwis nie dostaje żadnych informacji o obywatelu poza jego imieniem i nazwiskiem, ale zaufanie urzędu gwarantuje, że organy ścigania są w stanie — na podstawie odcisku klucza — ustalić tożsamość podejrzanego);
- Update: Pozwala podpisać ten sam dokument dowolnej liczbie osób;
Co kwartał jeździć do urzędu i składać nowy wniosek?
Dla ludzi zatrudnionych na pełnym etacie / mających dalej do urzędów to męczące. Nie da się tego jakoś uniknąć?
Najchętniej bym widział jednak jakieś rozwiązanie z fizycznym kluczoidentyfikatorem. Klucz przechowywany na komputerze to jednak łatwy łup dla trojanów, zwłaszcza gdyby Państwo opracowało jakieś swoje standardowe narzędzie do zarządzania kluczami/podpisywania dokumentów.
I chyba zbyt optymistycznie szacujesz znikomy koszt oprogramowania — nie wierzę, że ktoś da radę w ciągu wieczora skrobnąć na przykład stronę, która generuje Ci wnioski o “key renewal” z kodami kreskowymi etc. Chyba, że bardzo luzacko podchodzisz do jakości kodu i tzw. “audytowalności”.
W porównaniu do obecnego systemu, to ten koszt rzeczywiście byłby niemal zerowy…
Co do piątej różnicy - czyżby znów casus programu “płatnik”? Z elektronicznego podpisu się poważnie nie da korzystać na systemach bez logo microsoftu?
Hoppke:
Ustalenie ważności klucza na kwartał to termin wzięty z powietrza. W praktyce byłaby to pewnie wielokrotność roku (przy generowaniu klucza sam możesz sobie dowolnie ten termin skrócić).
Przechowywanie na fizycznym nośniku to kwestia drugoplanowa. Każdy klucz wymaga jakiegoś zabezpieczenia, czy to będzie certyfikat użytkownika, czy klucz GPG, czy fizyczny klucz do skrytki w banku.
Koszt oprogramowania naprawdę jest znikomy, przenośne implementacje PGP z w pełni otwartym kodem istnieją od dawna, są też w powszechnym użyciu w innych aplikacjach (klient e-mail, komunikator).
Wniosek to zwykły PDF z imieniem, nazwiskiem, PESELem i datą ważności, a kod kreskowy nie jest niczym tajnym, bo jest tam identyfikator klucza publicznego, który nie zawiera więcej informacji niż właśnie imię i nazwisko. ReportLab z odpowiednią czcionką dla kodów kreskowych pozwoli ci zmieścić całość w +/- 100 liniach kodu Pythona. Kod kreskowy zaproponowałem tylko po to, żeby pani w okienku nie musiała przepisywać ciągów szesnastkowych ręcznie.
mt3o:
Nie wiem, jak jest przy składaniu podań, tam prawo jest mocno nieprecyzyjne. Za to ustawa o podpisie elektronicznym wymaga użycia kwalifikowanego “bezpiecznego urządzenia,” co w praktyce oznacza programy dostarczone przez wystawcę certyfikatu. Wystawców mamy czterech, mamy też cztery różne programy. Każdy tylko i wyłącznie pod Windows.
Dobrze pomyślane Patrysie, podpisuję się ;) pod nim rękami i nogami. Teraz trzeba to podrzucić gdzieś do organów państwowych, niech się zastanowią nad tym rozwiązaniem…
A przy okazji z klucza GPG obywatela urząd mógłby wyciągnąć jego adres e-mail i jeszcze bardziej usprawnić komunikację… Co prawda centralna sieć serwerów email/IM ma swoje zalety (a dodanie jeszcze jednego serwera SMTP/POP3/IMAP do swojego klienta poczty to pestka), ale z drugiej strony to ogromna pokusa dla crackerów i innych…
Jeśli chodzi o przechowywanie klucza, to bierz pod uwagę najsłabszy element takiego systemu - użytkownika. Wiadomo, jaka jest wiedza informatyczna w społeczeństwie… Projektując system trzeba brać pod uwagę słabości ludzi. Osobiście takie rozwiązanie wydaje mi się ryzykowne.
Bartłomiej:
Klucz trzeba przechowywać tak samo jak certyfikat. Użycie GPG nie wyklucza tu użycia zewnętrznego urządzenia. Z drugiej strony, klucz prywatny jest zabezpieczony hasłem, więc nikt nie będzie masowo kradł kluczy, bo nie starczy mu mocy na próby ich łamania.
Jeśli do wyboru jest:
- klucz przechowywany nie wiadomo gdzie, bo raz na USB, raz na karcie chipowej, raz w katalogu z pr0nem a raz … etc
- 1337 dostępnych programów obsługujących kodowanie za pomocą klucza
lub
- jeden z 4rech programów każdy powiązany ze specyficznym kluczem używanym w określonych momentach
i jeśli pamiętać, że przeciętny ZU jest fanem przechowywania wirusów, trojanów i keyloggerów w swoim komputerze to … rozwiązanie Patrysa wcale nie wydaje mi się mniej bezpieczne.
@Patrys: rok czy dwa ważności dałoby się już przełknąć.
Ale trzeba pamiętać o specyfice użytkowników. To powinno być coś fizycznego, jak dowód osobisty czy karta kredytowa. To komplikuje oczywiście cały proces i podnosi koszt, ale trzeba pamiętać, że potencjalni użytkownicy będą przypominać raczej klientów naszej-klasy niż czytelników tego bloga.
A wychodzę z założenia, że statystyczny Polak łatwiej zabezpieczy przed kradzieżą kartę w swoim portfelu niż plik na swoim dysku.
Z tego samego powodu, jeśli trzymać się PGP, od razu musiałbyś mieć kryteria określające “dostatecznie mocne” hasło i nie pozwalające użyć kluczy słabo zabezpieczonych (względnie proste jeśli klucz przechowywany jest na karcie chipowej, trudniejsze jeśli utrzymujesz go w postaci pliku na prywatnym komputerze) . Inaczej użytkownicy pójdą po najmniejszej linii oporu i nie zabezpieczą hasłem w ogóle, lub użyją hasła ze słownika. I założenie “nikt nie będzie kradł kluczy, bo nie wystarczy mu mocy na łamanie haseł” stanie się fantazją.
Niestety nie można tu powiedzieć “jak się nie zabezpieczysz odpowiednio to sam sobie jesteś winien”, bo system implementowany na taką skalę powinien jednak wymuszać pewien minimalny poziom bezpieczeństwa.
“Przenośne implementacje PGP z w pełni otwartym kodem istnieją od dawna”
Pewnie, że tak. Kryptografia też stoi mocno, mamy nawet w Polsce masę ludzi którzy się naprawdę na tym znają. Problem w tym, że nie ma odpowiedniego nasycenia fachowcami w tych warstwach, które podejmują decyzje, hmm, “administracyjne”. Myślę, że w takich projektach większy udział powinny brać ośrodki akademickie. Może nawet na zasadzie opracowywania konkurencyjnych rozwiązań (Kraków kontra Warszawa kontra Wrocław…). Oczywiście bez dodatkowych dotacji ze skarbu państwa, dla samego prestiżu. No, zwycięzca mógłby dostać jakiś grant uznaniowy.
Implementację może już potem robić firma z przetargu, ale architekturę powinni opracowywać naukowcy i specjaliści z danej dziedziny (i oczywiście API/protokoły powinny być jawne).
“są też w powszechnym użyciu w innych aplikacjach (klient e-mail, komunikator)”
W powszechnym użyciu jest też SMTP, a wiadomo jakie są z nim problemy… ;)
Mi sie wydaje, ze glownym problemem, o ktorym sie nie mowi publicznie, a ktorego boi sie rzad, jest stworzenie serwera z kluczami publicznymi dla milionow polakow… Obciazenie - pierwszy problem. Drugi to bezpieczenstwo danych (a jak rzad NIE potrafi ochraniac danych dobrze wiadomo), trzeci to kwestia operowania na tak wielkiej bazie (tego ja sie boje - stworza jedna tabele, sekretarka niechcacy wpisze truncate…)… Dla informatykow to nie problem, ale rzad ma to do siebie, ze zatrudnia jako wykonawcow cieniasow.
Z kolei tez Polska nie jest chyba do konca gotowa na taka rewolucje - panie za okienkami, ktore super widza bledy w pitach, nagle trzeba bedzie wyszkolic do obslugi komputera - a to dodatkowe koszty.
Podsumowujac, nie wierze w szybkie zinformatyzowanie tego kraju :/
Chris:
Mój klucz publiczny jest powszechnie dostępny, nie trzeba go chronić. Do podpisania potrzebny jest klucz prywatny, którego nie zamierzam rządowi nigdy pokazywać (na tym polega cała idea PGP).
@Chris
Gdzie niby ta Pani ma wpisać ‘truncate’ ? To się na na poziomie MySQL/phpMyAdmin wyłączyć (nie wierzę, że tego nie wiesz), poza tym Pani nie będzie miała dostępu do RDBMSa, tylko do ładnego GUI do procedur składowanych i tyle… poza tym - wierz lub nie - ale administracja ma do dyspozycji naprawdę dobrych specjalistów; dość, by to co opisał Patrys wdrożyć. Tylko że fatalnie z nich korzysta, a poza tym w takim układzie nie zarobiłby żadnen Prokom - więc sprawa nie przejdzie. W Polsce to nie technika, ani nawet nie kapitał są barierami - tyklo mentalność i KULTURA ORGANIZACYJNA. I tak w Polsce jedną prostą korwetę buduje się tyle, co we Francji atomowy okręt podwodny, a w rok naprawia tyle torów kolejowych, ile Brytyjczycy wymieniają w weekend.
@Patrys
Informatyzacja to nie jest przenoszenie istniejącego bałaganu do komputerów, ew. tworzenie nowego… problem polega na tym, że w Polsce NIPów, PESELi (a jak masz działalność, to i REGONów) masz stanowczo za dużo. Wystarczyłby, po amerykańsku jeden identyfikator jawny (np. PESEL(2)) i jeden klucz, zapisany na JEDNYM dokumencie którym byłby dowód osobisty w postaci karty mikroprocesorowej. Zauważ, że poręczny kod kreskowy mógłby być indentyfikatorem jawnym - służącym tylko do wskazania lokalizacji / nazwy klucza w systemie. Takie narodowe OpenID…
Budyń:
Z czym zostanie połączony klucz to jedna kwestia. Mi chodzi bardziej o to, że PGP nadaje się do składania podpisów, ma dużo szersze zastosowania niż kwalifikowane certyfikaty i przede wszystkim dużo prościej jest taki klucz unieważnić i wymienić.
A to prawda. PGP jako implementacja kluczy obywatelskich i mechanizm podpisu elektronicznego to bardzo dobry pomysł.
I podzielam zdanie Budynia — ograniczyć burdel robiąc jeden identyfikator — mikrochipowy dowód osobisty, który jednocześnie byłby elektronicznym sygnetem, a przy okazji może nawet dałoby się jakoś e-voting na tym oprzeć i ustrzelić dwa ptaki jednym strzałem? (choć to już całkiem insza inszość).
Budyń napisał bardzo ważną rzecz. Staram się i staram - i nie rozumiem, po co mi jednocześnie PESEL i NIP. W kontakcie z urzędem skarbowym podaję jedno i drugie - po kiego ch…?
Rozumiem, że NIP to coś więcej, dotyczy też osób prawnych itd. Ale skoro mnie identyfikuje, to po co mi PESEL? Że PESEL dostaję przy urodzeniu, a NIP nie? Skoro są procedury nadawania PESELU przy urodzeniu, to nadawajmy w ten sam sposób NIP i tyle. Czepianie się do nazwy (Numer Identyfikacyjny Podatnika) puszczam mimo uszu.
Hoppke - to nie jest insza inszość.
Ja bym wolał jednolitą identyfikację na potrzeby wszystkich uprawnionych urzędów i niech się ode mnie odczepią raz na zawsze. Raz, a dobrze rozwiązać kwestię identyfikacji elektronicznej osoby i dać nam spokój - czy to nie byłoby piękne?
Tylko NIP i PESEL… szczęśliwi z was ludzie, niektórzy mają jeszcze REGON :).
Najbardziej mnie bawią te radosne druki z ZUSu (nota bene, nie można ich wydrukować samemu co uważam za totalny absurd), kiedyś wypełniłem wszystkie okienka i mnie odesłali, bo “za dużo danych i niezgodnie z instrukcją”. Instrukcja jest taka: “Wpisać NIP i REGON, a w razie gdy płatnikowi składek nie nadano tych numerów lub jednego z nich - numer PESEL; jeśli płatnikowi nie nadano również numeru PESEL - serię i numer dowodu osobistego albo paszportu. Tym samym numer PESEL, seria i numer dowodu osobistego albo paszportu powinny być podawane jedynie wówczas, gdy płatnik nie posiada identyfikatorów NIP i REGON lub jednego z nich”… Po prostu piękne.
A co do ustawy, to pewnie największy problem z propozycją Patrysa byłby w pogodzeniu jej z ustawą o ochoronie danych. Nie dotarłem wprawdzie do tego jak jest teraz, ale w/g pomyłu Patrysa wszyscy dostają przynajmniej interfejs do tłumaczenia klucz publiczny -> imie i nazwisko + pewnie jeszcze jaką informacja, bo np. Janów Kowalskich to trochę jest. Pewnie lepszym rozwiązaniem byłoby api w stylu klucz + imie + nazwisko + pesel/nr. dowodu/cokolwiek -> weryfikacja zgodności (tu dochodzi konieczność zmiany klucza przy zmianie innych danych). No bo na wprowadzenie jednego numeru na chipie w dowodzie liczyć w najbliższej przyszłości nie można.