Algorytmy współpracy z systemami zewnętrznymi. Wersja 1.00

Algorytmy współpracy z systemami zewnętrznymi Wersja 1.00

Spis treści 1. Wprowadzenie... 4 1.1 Cel... 4 1.2 Zakres... 4 1.3 Kryteria jakości... 4 2. Zidentyfikowane przypadki użycia... 5 2.1 Produkcja blankietu... 5 2.1.1 przekazuje profil karty do MSWiA... 5 2.1.2 Dostawca blankietu przekazuje informacje o wyprodukowanych blankietach do 6 2.1.3 Dostawca blankietu przekazuje informację o wygenerowaniu kluczy do... 6 2.1.4 informuje RDO o brakach w kartach wysłanych do SPD... 7 2.1.5 SPD przekazuje do informacje o otrzymaniu blankietów... 7 2.2 Personalizacja dowodu osobistego... 7 2.2.1 Odbiór zlecenia personalizacji z RDO... 8 2.2.2 Przekazanie zlecenia personalizacji do SPD... 9 2.2.3 SPD przekazuje informacje o karcie od producenta... 9 2.2.4 SPD przekazuje CSR do... 10 2.2.5 przekazuje certyfikat do SPD... 10 2.2.6 przekazuje binaria do SPD... 11 2.2.7 SPD przekazuje informacje o wyniku personalizacji do... 11 2.2.8 przekazuje informacje o wyniku personalizacji do RDO... 12 2.3 Odbiór dowodu osobistego i aktywacja certyfikatu dowodu osobistego... 12 2.3.1 Odblokowanie karty w gminie... 13 2.3.2 przekazuje informację o odblokowaniu karty do RDO... 14 2.4 Złożenie wniosku o aktywację certyfikatu podpisu osobistego... 14 2.4.1 RDO przekazuje zlecenie wygenerowania danych aktywacyjnych do... 15 2.4.2 przekazuje wygenerowane dane aktywacyjne do drukarni... 15 2.4.3 Drukarnia przekazuje do informację o wysłaniu danych aktywacyjnych. 15

2.4.4 przekazuje informację o wysłaniu danych aktywacyjnych do RDO (opcjonalne)... 16 2.5 Aktywacja certyfikatu podpisu osobistego... 16 2.5.1 Wniosek o aktywację aplikacji podpisu osobistego... 17 2.5.2 Aktywacja aplikacji podpisu osobistego... 17 2.5.3 Nadanie nowego PINu... 18 2.6 Unieważnienie DO po upływie 4 miesięcy od zmiany danych... 18 2.6.1 RDO przekazuje wniosek o unieważnienie części elektronicznej DO do.. 19 2.6.2 Przekazuje informację o unieważnieniu certyfikatów do RDO... 19 2.7 Odblokowanie aplikacji podpisu po zablokowaniu... 20 2.7.1 Karta zestawia połączenie do odblokowania dostępu... 21 3. Opis algorytmów i protokołów komunikacyjnych... 22 3.1 OASIS/DSS... 22 3.2 TSP... 22 3.3 OCSP... 23 3.4 SCVP... 23 3.5 GlobalPlatform... 24 3.6 WebService... 24 3.7 JMS, MQ... 24 4. Interoperacyjność... 25 5. Bibliografia... 26

1. Wprowadzenie 1.1 Cel Celem niniejszego dokumentu jest przedstawienie sposobu komunikacji i współpracy podsystemu PKI projektu pl.id z zewnętrznymi systemami. 1.2 Zakres Analiza architektury i przypadków użycia w celu zidentyfikowania systemów współpracujących z podsystemem PKI. Wskazanie standardów i algorytmów współpracy z zewnętrznymi systemami. Wskazanie zasad związanych z zachowaniem interoperacyjności podsystemu z innymi systemami informatycznymi. 1.3 Kryteria jakości Identyfikuje systemy współpracujące z podsystemem PKI i punkty styku systemów. Wskazuje i opisuje algorytmy współpracy ze zidentyfikowanymi systemami zewnętrznymi. Zawiera analizę interfejsów ( w tym identyfikuje zakres przekazywanych informacji, protokoły przekazywania informacji). Wskazuje warunki dla zapewnienia interoperacyjności z zewnętrznymi systemami.

2. Zidentyfikowane przypadki użycia Niniejszy rozdział wskazuje sytuacje powodujące interakcję podsystemu PKI w projekcie pl.id z zewnętrznymi w stosunku do niego systemami. 2.1 Produkcja blankietu Przedstawiony poniżej proces produkcji blankietów i obiegu związanej z tym informacji zależy w znacznym stopniu od warunków narzuconych przez ustawę o dowodach osobistych i podjęte decyzje projektowe. Model przedstawiony w tym podrozdziale może zatem ulec zmianie. sd Produkcja blankietów kart Zewnętrzne::RDO Zewnętrzne::System Personalizacji Dokumentów Z obrębu PKI:: Zewnętrzne: Producent blankietów Zewnętrzne: MSWiA Eksport profilu karty() Zlecenie produkcji blankietów() Wysłanie blankietów() Informacja o wyprodukowanych blankietach (w tym informacja o wygenerowaniu kluczy) Informacja o wysłanych blankietach() Informacja o ew. brakach() Informacja o otrzymaniu blankietów() Informacja o ew. brakach() 2.1.1 przekazuje profil karty do MSWiA MSWiA (odpowiednia jednostka organizacyjna)

W celu ułatwienia stworzenia specyfikacji na potrzeby zamówienia kart u producentów może wyeksportować profil karty. 2.1.2 Dostawca blankietu przekazuje informacje o wyprodukowanych blankietach do Dostawca blankietu Informacja o blankietach wyprodukowanych na potrzeby projektu pl.id powinna być przekazywana przez dostawców blankietów do systemu. Ma to na celu dokładną i scentralizowaną ewidencję tychże blankietów. Dla systemu istotne informacje związane są z określeniem rodzaju karty (w zależności od rodzaju karty może istnieć potrzeba przygotowania innych wersji aplikacji, a co za tym idzie personalizacja karty w dalszych procesach może przebiegać różnie), oznaczeniach karty (blankietu/mikroprocesora). Producent powinien przekazywać także klucze transportowe niezbędne do zabezpieczenia kart podczas transportu do SPD Informacja ta może być przekazywana hurtowo (dla całej partii kart). 2.1.3 Dostawca blankietu przekazuje informację o wygenerowaniu kluczy do Dostawca blankietu Jako, że możliwe są dwa scenariusze odnośnie generowania kluczy kryptograficznych dla dowodów osobistych (przy produkcji przez producenta, bądź w obrębie Centrum Certyfikacji pl.id) musi wiedzieć czy dana karta ma już wygenerowane klucze. W tym celu dostawa przekazuje informacje o tym, że dana karta ma już wygenerowane klucze (oraz parametry tychże, gdyż może to być parametr zmienny w obrębie całego systemu i 10cio letniego cyklu życia karty).

2.1.4 informuje RDO o brakach w kartach wysłanych do SPD RDO (OEWiUDO) przekazuje do RDO informacje o kartach, które zostały przez producenta wyprodukowane, ale które nie zostały wysłane do SPD. 2.1.5 SPD przekazuje do informacje o otrzymaniu blankietów SPD W celu zachowania ścisłej kontroli nad wyprodukowanymi blankietami, SPD przekazuje informacje o otrzymaniu blankietów o danych numerach do. Daje to możliwość wychwycenia blankietów zgubionych, skradzionych podczas transportu. W przypadku, gdy SPD zgłasza otrzymanie innej ilości kart, niż zostało wysłanych, generowaney jest przez RDO raport o brakach przesyłany do RDO. 2.2 Personalizacja dowodu osobistego W ramach procesu personalizacji dowodu osobistego podsystem PKI uczestniczy w przekazaniu zlecenia produkcji z RDO do SPD oraz przekazuje informacje służące do personalizacji. Szczegółowy opis algorytmów znajduje się poniżej. Poniżej zamieszczono również diagram pokazujący interakcję pomiędzy komponentami.

sd Personalizacja dokumentu Zewnętrzne::RDO Z obrębu PKI:: Zewnętrzne::System Z obrębu PKI::Szyna Personalizacji Dokumentów integracyjna podsystemu PKI Z obrębu PKI::Urząd operacyjny Zlecenie personalizacji() Zlecenie personalizacji() Wniosek o certyfikat(y) Wniosek o certyfikat() Wniosek o certyfikaty() Certyfikaty() Certyfikaty() Binaria aplikacji i certyfikaty() Informacja o wyniku personalizacji() Informacja o wyniku personalizacji() Założenia do diagramu: Zastosowanie tradycyjnego modelu składania podpisu (nie mediator), System Personalizacji Dokumentów uczestniczy aktywnie w personalizacji części elektronicznej (generuje wnioski o certyfikaty, które przekazuje do, w przypadku takiej konieczności może zwrócić się do o binaria aplikacji). 2.2.1 Odbiór zlecenia personalizacji z RDO OEWiUDO (RDO) W tym scenariuszy RDO odbiera z gminy wniosek o wydanie dowodu osobistego i zleca personalizację do komponentu. Technicznie odbywa się to przez przesłanie komunikatu w formacie XML o następującej zawartości informacyjnej: Nazwisko; Imię (imiona); Nazwisko rodowe; Imiona rodziców; Datę i miejsce urodzenia (miejscowość);

Płeć (biorąc pod uwagę przesyłanie numeru PESEL można pominąć, chyba, że zakładamy możliwość personalizacji dokumentu z błędnym numerem PESEL); Wizerunek twarzy odpowiadający wymogom biometrii; Numer PESEL; Obywatelstwo; Oznaczenie organu wydającego dokument, Informację, czy dowód ma być wydany na 5, czy 10 lat Wygenerowany w RDO numer dowodu osobistego Identyfikator zlecenia Zlecenia personalizacji z RDO przekazywane są poprzez szynę integracyjną do podsystemu PKI, gdzie przekazywane są do modułu zarządzania kartami. 2.2.2 Przekazanie zlecenia personalizacji do SPD SPD poprzez szynę integracyjną PKI przekazuje komunikat inicjujący proces personalizacji dowodu osobistego (lub poprzez bezpośredni kanał komunikacji decyzję należy podjąć po przeanalizowaniu wolumetrii przesyłanych komunikatów i możliwości w zakresie integracji systemów). SPD zwrotnie przekazuje potwierdzenie odebrania zlecenia. Zlecenie zawiera informacje przekazane do z RDO. W zależności od decyzji odnośnie sposobu komunikacji albo systemy SPD będą dostosowane do odbierania komunikatów w formacie stosowanym w, lub też szyna integracyjna PKI będzie odpowiadała za translację komunikatów na format natywny dla systemów używanych w Systemie Personalizacji Dokumentów. 2.2.3 SPD przekazuje informacje o karcie od producenta SPD

W momencie, w którym SPD pobiera dany blankiet do personalizacji następuje związanie blankietu z danymi osoby. SPD przekazuje informację do o rodzaju i oznaczeniu pobranej do personalizacji karty. W ten sposób w znajduje się informacja techniczna o rodzajach użytych kart (ma to znaczenie w przypadku kilku typów kart, gdy przygotowywane są aplikacje do umieszczenia na karcie). Do rozważenia po analizie możliwej wolumetrii komunikatów jest, czy komunikacja będzie odbywała się bezpośrednio między SPD i, czy też z udziałem szyny integracyjnej PKI. Zakres przekazywanych informacji: identyfikator blankietu umożliwiający jednoznaczne powiązanie z rekordem w bazie kart, identyfikator zlecenia personalizacji. 2.2.4 SPD przekazuje CSR do SPD W celu wykonania personalizacji części elektronicznej karty należy (m.in.) wygenerować po stronie podmiotu personalizującego karty wniosków o certyfikaty. Standardowym formatem wniosków jest PKCS#10. Wnioski (w zależności od decyzji odnośnie liczby certyfikatów 2 do 4) przekazywane są za pośrednictwem szyny integracyjnej PKI do systemu, który przekazuje je do odpowiednich CC, gdzie urzędy operacyjne generują certyfikaty i przekazuje go do SPD. 2.2.5 przekazuje certyfikat do SPD SPD

Po otrzymaniu wniosku o certyfikat Centrum Certyfikacji generuje certyfikat cyfrowy (podpisu osobistego, do uwierzytelnienia, itd.) i przekazuje go poprzez szynę integracyjną PKI do. przekazuje go do SPD. Certyfikat przekazywany do SPD w formacie PKCS#12 (format umożliwia przekazanie kilku certyfikatów w jednym pliku). Z racji na fakt, iż certyfikaty mogą pochodzić z różnych urzędów operacyjnych (zalecane) plików przekazywanych do SPD będzie maksymalnie tyle, ile będzie certyfikatów umieszczonych w warstwie elektronicznej dowodu osobistego. Certyfikaty mogą być przekazywane wraz z binariami aplikacji (patrz punkt poniżej). 2.2.6 przekazuje binaria do SPD SPD W przypadku, gdy SPD nie będzie posiadało możliwości przygotowania stosownych wersji binarnych aplikacji do umieszczenia na karcie musi umożliwiać przygotowanie i przekazanie odpowiednich danych do SPD. W takim przypadku SPD przekazuje poprzez brokera integracyjnego PKI stosowny komunikat do (komunikat musi zawierać identyfikator umożliwiający zidentyfikowanie po stronie systemu typu karty, ew. może zawierać ten typ). po przygotowaniu pliku binarnego z danymi przekazuje go do SPD, gdzie następuje umieszczenie danych na karcie. 2.2.7 SPD przekazuje informacje o wyniku personalizacji do SPD Zakończenie procesu personalizacji jest w cyklu życia karty istotnym kamieniem milowym. Informacja o zakończeniu procesu personalizacji (rozumianej jako zakończenie obu etapów personalizacji graficznej i elektronicznej) przekazywane jest z SPD poprzez szynę integracyjną PKI do systemu. Zawartość przekazywanego komunikatu to co najmniej:

identyfikator umożliwiający zidentyfikowanie karty po stronie (np. numer dowodu osobistego), informację o wyniku personalizacji (konieczne jest przekazywanie także komunikatów o ew. błędach- w przeciwnym wypadku nie będzie możliwa ponowna personalizacja na te same dane). 2.2.8 przekazuje informacje o wyniku personalizacji do RDO RDO Po otrzymaniu informacji z systemu personalizującego SPD, przekazuje do RDO komunikaty o stanie personalizacji dowodu z SPD (oraz ew. komunikaty błędów). Komunikacja ta odbywa się poprzez szynę integracyjną PKI (decyzja co do tego wymaga dalszych analizmożliwe też podłączenie bezpośrednio do szyny centralnej) i szyny centralnej. 2.3 Odbiór dowodu osobistego i aktywacja certyfikatu dowodu osobistego Ze względu na trwające prace legislacyjne trudno jest szczegółowo określić przebieg procesu aktywacji dowodu osobistego (i co za tym idzie- certyfikatu dowodu). Dokładny opis będzie możliwy po ustaleniu warunków brzegowych wynikających z (m.in.) założeń do ustawy o dowodach osobistych pl.id.

sd Odbiór dokumentu Zewnętrzne::Middleware Karty Zewnętrzne::RDO Z obrębu PKI:: Wniosek o odblokowanie karty() Proces odblokowania (podanie PIN) Odblokowanie karty() Informacja biznesowa o odblokowaniu() 2.3.1 Odblokowanie karty w gminie Karta (czytnik w gminie), RDO Zakładając, że karty wydawane w projekcie pl.id karty będą miały interfejs bezstykowy proces odblokowania karty przebiegać będzie następująco: RDO wysyła do systemu żądanie aktywacji karty po otrzymaniu uwierzytelnionego przez urzędnika gminnego wniosku. sprawdza, czy istnieją aktywne certyfikaty dla tej osoby (i jej poprzedniego dowodu osobistego) i jeśli tak, to je unieważnia (poprzez przesłanie do CC wniosku o unieważnienie). Karta nawiązuje połączenie z zaufanym czytnikiem w gminie weryfikując jego certyfikat CVC (Card Verificable Certificate). Następnie zestawiana jest sesja pomiędzy kartą, a systemem, który odblokowuje część elektroniczną karty. Dokładny opis procesu odblokowania części elektronicznej karty (możliwości wykonywania podpisu, czy uwierzytelniania obywatela) będzie możliwy dopiero po ustaleniu warunków brzegowych wynikających z projektowanych przepisów prawa (założenia do ustawy o dowodach osobistych pl.id)., decyzji technologicznych (np. rodzaj interfejsu karty).

2.3.2 przekazuje informację o odblokowaniu karty do RDO RDO Po wykonaniu technicznych czynności związanych z odblokowaniem, przekazuje do RDO informację o wykonaniu zlecenia, lub błędzie. Technicznie odbywa się to przez przesłanie podpisanego komunikatu w formacie XML do RDO zawierającego numer zlecenia, numer dowodu oraz nadany status karty. Komunikacja między RDO, a odbywa się poprzez szynę integracyjną MSWiA (po stronie RDO) i brokera integracyjnego PKI (po stronie podsystemu PKI), lub z pominięciem brokera integracyjnego PKI. 2.4 Złożenie wniosku o aktywację certyfikatu podpisu osobistego Certyfikat podpisu osobistego musi być aktywowany. Aktywacja jest tu rozumiana jako odblokowanie możliwości złożenia podpisu. Dzieje się to na wniosek obywatela. sd Wniosek o aktywację certyfikatu podpisu osobistego Zewnętrzne::RDO Z obrębu PKI:: Zewnętrzne: Drukarnia kopert PINowych Zlecenie przygotowania danych aktywacyjnych aplikacji podpisu() Przekazanie wygenerowanych danych aktywacyjnych() Informacja o wysłaniu koperty PINowej()

2.4.1 RDO przekazuje zlecenie wygenerowania danych aktywacyjnych do RDO RDO przekazuje do żądanie wygenerowania danych aktywacyjnych (np. numeru PIN). Odbywa się to po tym, jak gminny urzędnik otrzyma od obywatela wniosek o aktywację certyfikatu podpisu osobistego. 2.4.2 przekazuje wygenerowane dane aktywacyjne do drukarni Drukarnia przekazuje wygenerowane na żądanie RDO dane aktywacyjne do systemu drukującego koperty z numerami PIN. W chwili obecnej brak decyzji co do lokalizacji drukarni. 2.4.3 Drukarnia przekazuje do informację o wysłaniu danych aktywacyjnych Drukarnia Drukarnia przekazuje informację o tym, że dane aktywacyjne zostały wysłane pocztą do obywatela. Na obecnym etapie prac nie zostały podjęte decyzje odnośnie tego, czy przesyłka ma być wysyłana do obywatela, czy też do urzędu gminy.

2.4.4 przekazuje informację o wysłaniu danych aktywacyjnych do RDO (opcjonalne) RDO Po otrzymaniu informacji z drukarni o fakcie wysłania pocztą koperty z danymi aktywacyjnymi dla aplikacji podpisu osobistego, przekazuje tę informację do RDO. Jest to operacja opcjonalna- ma sens jedynie przy założeniu, że w RDO informacje o dacie wysyłki koperty PINowej będą przechowywane i udostępniane urzędnikom. 2.5 Aktywacja certyfikatu podpisu osobistego Finalny opis procesu aktywacji certyfikatu podpisu osobistego (i ew. innych certyfikatów) będzie możliwy dopiero po ustaleniu warunków prawnych w tym zakresie (Ustawa o Dowodach Osobistych). Zawarte w tym rozdziale opisy odnoszą się do sytuacji wynikającej z aktualnych na chwilę pisania dokumentu Założenia do projektu ustawy o dowodach osobistych pl.id.

sd Aktywacja certyfikatu podpisu Zewnętrzne::ZMOKU - SOO Zewnętrzne::Middleware Karty Z obrębu PKI:: Wniosek o aktywację certyfikatu() Wniosek o odblokowanie aplikacji podpisu(pin) Odblokowanie aplikacji podpisu() Zmiana numeru PIN() Nadanie nowego numeru PIN() 2.5.1 Wniosek o aktywację aplikacji podpisu osobistego ZMOKU ZMOKU przekazuje systemowi zlecenie aktywacji aplikacji podpisu osobistego..techniczna metoda realizacji wysłania zlecenia aktywacji będzie mogła być określona dopiero po ustaleniu dokładnych wymagań prawnych (Ustawa o dowodach osobistych i rozporządzenia wykonawcze). 2.5.2 Aktywacja aplikacji podpisu osobistego Karta (czytnik w gminie),, Karta (czytnik w gminie)

Karta nawiązuje połączenie z zaufanym czytnikiem w gminie weryfikując jego certyfikat CVC (Card Verificable Certificate). Następnie zestawiana jest sesja pomiędzy kartą, a systemem. Do systemu przesyłany jest PIN wprowadzany przez posiadacza karty. 2.5.3 Nadanie nowego PINu Karta (czytnik w gminie),, Karta (czytnik w gminie) Na poziomie projektowym i legislacyjnym nie zostały podjęte ostateczne decyzje co do modelu przekazywania kodów aktywacyjnych do części elektronicznej dowodu osobistego (kody aktywacyjne związane są z daną aplikacją umieszczoną w części elektronicznej karty mikroprocesorowej). W szczególności nie podjęte zostały decyzje co do tego gdzie, kiedy i kto ma nadawać nowy PIN chroniący funkcjonalność podpisu elektronicznego. Jednym z możliwych wariantów jest: Posiadacz DO wykorzystuje dedykowany punkt służący do obsługi kart DO, przykłada kartę do czytnika. Posiadacz DO podaje numer PIN u aktywacyjnego otrzymanego w kopercie (do tego celu może być wykorzystywany czytnik z zewnętrzną klawiaturą, lub klawiatura komputera), oraz nowy numer PIN używany później w celu użytkowania aplikacji podpisu. Dane te, w sposób zaszyfrowany, przekazywane są do systemu. System weryfikuje czy otrzymał zlecenie aktywacji aplikacji dla tego PIN u. W przypadku pozytywnej weryfikacji karty system nadaje nowy numer PIN dla aplikacji podpisu. 2.6 Unieważnienie DO po upływie 4 miesięcy od zmiany danych W projekcie pl.id zakładane jest w chwili obecnej, iż dowody osobiste będą automatycznie unieważniane po 4 miesiącach od zaistnienia przesłanki w postaci zmiany danych zawartych w dowodzie (np. zmiana nazwiska). Mechanizm ten zaimplementowany będzie po stronie rejestru dowodów osobistych (RDO). W chwili obecnej nie podjęto decyzji o tym, czy RDO ma komunikować się bezpośrednio z centrum certyfikacji, czy też poprzez.

sd Automatyczne unieważnienie dowodu osobistego Zewnętrzne::RDO Z obrębu PKI:: Zlecenie unieważnienia części elektronicznej DO() Potwierdzenie uniewaznienia certyfikatów() 2.6.1 RDO przekazuje wniosek o unieważnienie części elektronicznej DO do RDO W związku z automatycznym unieważnieniem dowodu osobistego RDO przekazuje do podsystemu PKI () wniosek o unieważnienie części elektronicznej DO (certyfikatów podpisu osobistego oraz dowodu osobistego, ew. innych). RDO musi przekazać informację jednoznacznie identyfikującą certyfikaty konieczne do unieważnienia (ew. jednoznacznie identyfikującą kartę). W chwili obecnej planowane jest umieszczenie w RDO informacji o certyfikatach zawartych w części elektronicznej dowodu osobistego, a zatem istnieje taka możliwość. W przeciwnym wypadku należy przekazywać komunikat z identyfikatorem jednoznacznie identyfikującym dowód lub jego posiadacza, a wewnątrz podsystemu PKI wykonywane byłoby sprawdzenie jakie certyfikaty należy unieważnić. Komunikacja między RDO, a podsystemem PKI obywa się za pośrednictwem centralnej szyny integracyjnej MSWiA. 2.6.2 Przekazuje informację o unieważnieniu certyfikatów do RDO

RDO po wykonaniu operacji unieważnienia przekazuje do RDO informację o tym fakcie. Od momentu unieważnienia certyfikaty nie będą poprawnie weryfikowane przez podsystem VA (Validation Authority). W przypadku zastosowania mechanizmów finalizacji podpisu nie będzie możliwe również wykonanie poprawnie weryfikującego się podpisu elektronicznego z wykorzystaniem danych związanych z certyfikatem podpisu osobistego. Komunikacja między RDO, a podsystemem PKI obywa się za pośrednictwem centralnej szyny integracyjnej MSWiA. 2.7 Odblokowanie aplikacji podpisu po zablokowaniu Odblokowanie dostępu do aplikacji służącej do składania podpisu osobistego jest procesem niezależnym i może zostać wywołana w dowolnym czasie okresu po wydaniu dowodu osobistego obywatelowi. sd Zmiana numeru PIN Zewnętrzne::ZMOKU - SOO Zewnętrzne::Middleware Karty Z obrębu PKI:: Wniosek o nadanie nowego numeru PIN() Zestawienie sesji i wniosek o zmianę PINu() Nadanie nowego numeru PIN()

2.7.1 Karta zestawia połączenie do odblokowania dostępu Karta Przykładowy przebieg procesu: Urzędnik loguje się do systemu i uzyskuje dostęp do aplikacji umożliwiającej odblokowanie numeru PIN. Urzędnik przykłada kartę do czytnika i zgłasza żądanie odblokowania numeru PIN. Aplikacja tworzy szyfrowane połączenie pomiędzy kartą, a systemem. Użytkownik wprowadza nowy numer PIN (np. z użyciem pin-padu, lub wirtualnego pin-padu). System nadaje nowy numer PIN aplikacji do składania podpisu osobistego. nie nada nowego numeru PIN, gdy nie otrzymał wniosku od systemu RDO (bez działania urzędnika).

3. Opis algorytmów i protokołów komunikacyjnych W niniejszym rozdziale opisane zostały algorytmy i standardy interfejsów używanych w podsystemie PKI. Zawarto przede wszystkim odniesienie do standardów, gdzie zawarty jest szczegółowy opis techniczny. 3.1 OASIS/DSS Digital Signature Services (DSS) jest standardem stworzonym przez organizację OASIS. Celem jego stworzenia było zdefiniowanie WebService ów służących do tworzenia podpisu elektronicznego, weryfikacji podpisu elektronicznego i znakowania czasem. DSS wspiera różne formaty podpisu, m.in.: W3C XML Signatures, CMS (RFC 3852) Signatures, RFC 3161, Znakowanie czasem XML (zdefiniowane w DSS), Zaawansowany podpis elektroniczny (ETSI TS 101903 i ETSI TS 101733) DSS składa się z dwóch głównych protokołów- podpis i weryfikacja podpisu. Każdy z protokołów ma dwa typy wiadomości zapytanie (request), odpowiedź (response). W podstawowym trybie działania DSS umożliwia złożenie podpisu elektronicznego poprzez przesłanie przez uwierzytelnionego użytkownika dokumentu jaki ma być podpisany do serwera podpisującego. Użytkownik otrzymuje w odpowiedzi podpis elektroniczny. Drugą podstawową usługą jest weryfikacja w której użytkownik przekazuje dokument i podpis do serwera, a w odpowiedzi otrzymuje komunikat mówiący o tym, czy podpis jest poprawny. 3.2 TSP Protokół znakowania czasem Time-Stamp Protocol (TSP), opisany został w dokumencie RFC3161. Ponadto organizacja ETSI opublikowała standard TS 101861 Time Stamping Profile. Dodatkowo w standardzie TS 102023 określone są wymagania dla polityk związanych z usługami znakowania czasem. Znakowanie czasem może być wykonywane przez wewnętrzne systemy organizacji lub przez system zaufanej trzeciej strony. Znakowanie czasem związane jest z zapewnieniem niezaprzeczalności i w kontekście podpisu elektronicznego pozwala na zaświadczenie, że podpis elektroniczny został złożony przed daną datą (co w konsekwencji umożliwia np. stwierdzenie, że został on złożony w terminie ważności certyfikatu).

Zgodnie z RFC3161 podmiot świadczący usługi znakowania czasem (TSA) zobowiązany jest do: Korzystania z zaufanego źródła czasu, Umieszczania informacji o czasie w każdym wygenerowanym tokenie, Umieszczania unikalnego, liczbowego identyfikatora dla każdego wygenerowanego tokena, Generowania tokena po otrzymaniu ważnego wniosku (jeśli tylko jest to możliwe), Umieszczanie w każdym tokenie wskazania na politykę na podstawie której został wygenerowany, Znakowania czasem jedynie skrótu z danych, wytworzonego przez odporną na kolizje funkcję jednokierunkową identyfikowaną jednoznacznie przez OID, Sprawdzania długości otrzymanego skrótu z wartością wynikającą z OID, Nie sprawdzania skrótu w inny sposób, Nie umieszczania żadnych danych identyfikujących wnioskującego, Podpisywania każdego tokena kluczem służącym wyłączenie do tego celu i mającym w certyfikacie wpisane odpowiednie przeznaczenie, Umieszczania dodatkowych informacji w tokenie, jeśli tak zawnioskuje w polach rozszerzeń użytkownik, pod warunkiem jednak, że te rozszerzenia są obsługiwane przez TSA. W przeciwnym przypadku TSA musi zwrócić komunikat błędu. Po otrzymaniu podpisanego tokena, oprogramowanie użytkownika musi zweryfikować status błędu w odpowiedzi, a jeśli odpowiedź nie zawiera błędu: Zweryfikować poprawność pól zawartych w tokenie, Zweryfikować poprawność podpisu zawartego w tokenie, Zweryfikować, że znacznik czasu odpowiada danym, które służyły do wygenerowania wniosku o znacznik. 3.3 OCSP Protokół Online Certificate Status Protocol służy do weryfikacji statusu certyfikatu cyfrowego. Jest to alternatywa dla sprawdzania ważności certyfikatu w oparciu o listy unieważnionych certyfikatów (CRL). Standard OCSP opisany został w dokumencie RFC2560. 3.4 SCVP Sever-based Certificate Validation Protocol (SCVP) jest protokołem umożliwiającym walidację ścieżki zaufania pomiędzy certyfikatem X.509 i certyfikatem urzędu root. SCVP zostało

zdefiniowane w dokumencie RFC5055. Algorytm służący do walidacji został przedstawiony w RFC5280. 3.5 GlobalPlatform GlobalPlatform dostarcza zestaw specyfikacji dla kart mikroprocesorowych. Obejmuje swoim zakresem całą infrastrukturę związaną z wydawaniem kart mikroprocesorowych i ich zarządzaniem urządzenia, karty, systemy. Wszystkie specyfikacje dostępne są pod adresem: http://www.globalplatform.org/specifications.asp 3.6 WebService Usługi sieciowe (WebService) to komponenty programowe dostarczające pewne funkcjonalności (http://www.w3.org/2002/ws/). Usługi sieciowe zdefiniowane są za pomocą standardowego języka WSDL (Web Services Description Language http://www.w3.org/tr/wsdl), opartego o XML. Usługi sieciowe publikuje się i są możliwe do wyszukania z wykorzystaniem standardowych mechanizmów (np. UDDI - Universal Description, Discovery and Integration). Wywołanie zdalne odbywa się poprzez zdefiniowany interfejs. Najczęściej aplikacje komunikują się z usługami sieciowymi z wykorzystaniem protokołu SOAP (najnowsza wersja standardu znajduje się pod adresem: http://www.w3.org/tr/soap). 3.7 JMS, MQ IBM WebSphere MQ to typ oprogramowania Message Oriented Middleware służące do przekazywania komunikatów. Komunikat jest zbiorem znaków do którego dodawana jest informacja służąca do przekazywania wiadomości. Umożliwia komunikację zgodną z JMS. JMS Java Message Service to API stanowiące implementację Message Oriented Middleware dla komponentów aplikacyjnych zbudowanych na bazie Java 2 Platform, Enterprise Edition (J2EE). Dokumentacja JMS znajduje się na stronie http://java.sun.com/products/jms/docs.html. Obecnie aktualną wersją standardu jest 1.1.

4. Interoperacyjność Niniejszy rozdział ma na celu przedstawienie zasad zachowania interoperacyjności podsystemu PKI. Punktem wyjścia do analizy warunków interoperacyjności są Europejskie Ramy Interoperacyjności (EIF), jako, że usługi udostępniane przez PKI projektu pl.id spełniają definicję Europejskiej Usługi Publicznej (ponadgraniczna, dostępna publicznie dostarczana przez administrację, której odbiorcami są inne jednostki administracji publicznej, europejskim przedsiębiorcom lub obywatelom poprzez kooperację między jednostkami administracji publicznej). Jedną z głównych rekomendacji Europejskich Ram Interoperacyjności, która jest realizowana w ramach podsystemu PKI jest szeroko rozumiana reużywalność. Podsystem PKI udostępnia mechanizmy umożliwiające bezpieczną i efektywną komunikację obywatela z administracją publiczną w sposób jednolity i możliwy do zastosowania na wszystkich szczeblach administracji. EIF rekomenduje stosowanie standardowych interfejsów i tam, gdzie to możliwe otwartego oprogramowania. Bardzo ważna jest też neutralność technologiczna, czyli nie wymuszanie przez administrację publiczną rozwiązań technicznych u swoich partnerów. Prezentowane powyżej interfejsy wpisują się w te zasady, jako, że są to standardy lub quasi-standardy przemysłowe, niezależne od użytej platformy sprzętowo-programowej. Osobną kwestią jest interoperacyjność podpisu elektronicznego. Kwestie te uregulowane są obecnie w Europie przez standardy ETSI wskazujące format podpisu XAdES (ETSI TS 101 903).

5. Bibliografia 1. RFC2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol OCSP. http://www.ietf.org/rfc/rfc2560.txt 2. RFC2986 PKCS #10: Certification Request Syntax Specification Version 1.7 3. RFC3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP). http://www.ietf.org/rfc/rfc3161.txt 4. RFC3852 Cryptographic Message Syntax (CMS). http://www.ietf.org/rfc/rfc3852.txt 5. RFC5055 Server-Based Certificate Validation Protocol (SCVP). http://www.ietf.org/rfc/rfc5055.txt 6. RFC5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. http://www.ietf.org/rfc/rfc5280.txt 7. OASIS Digital Signature Services (DSS) TC - http://www.oasisopen.org/committees/dss/ 8. Web Services Activity - http://www.w3.org/2002/ws/ 9. Web Services Description Language (WSDL) 1.1 - http://www.w3.org/tr/2001/notewsdl-20010315 10. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition) - http://www.w3.org/tr/soap12-part1/ 11. Europejskie Ramy Interoperacyjności (notka na stronie MSWiA) - http://www.mswia.gov.pl/portal/pl/256/7879/europejskie_ramy_interoperacyjnosci_2 0.html 12. PKCS#12 - Personal Information Exchange Syntax Standard. http://www.rsa.com/rsalabs/node.asp?id=2138 13. ETSI TS 101733 - Electronic Signatures and Infrastructures (ESI); Electronic Signature Formats - http://portal.etsi.org/docbox/ec_files/ec_files/ts_101733v010501p.pdf 14. ETSI TS 101861 Time Stamping Profile. http://portal.etsi.org/docbox/ec_files/ec_files/ts_101861v010201p.pdf 15. ETSI TS 101903 XML Advanced Electronic Signatures (XAdES). http://uri.etsi.org/01903/v1.2.2/ts_101903v010202p.pdf 16. ETSI TS 102023 Electronic Signatures and Infrastructures (ESI); Policy requirements for time-stamping authorities. http://portal.etsi.org/docbox/ec_files/ec_files/ts_102023v010201p.pdf 17. JMS Java Messaging Standard http://java.sun.com/products/jms/docs.html GlobalPlatform Specyfikacje http://www.globalplatform.org/specifications.asp