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

Transkrypt

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
CAMS przekazuje profil karty do MSWiA ....................................................... 5
2.1.2
Dostawca blankietu przekazuje informacje o wyprodukowanych blankietach do
CAMS
6
2.1.3
Dostawca blankietu przekazuje informację o wygenerowaniu kluczy do CAMS ... 6
2.1.4
CAMS informuje RDO o brakach w kartach wysłanych do SPD ......................... 7
2.1.5
SPD przekazuje do CAMS 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 CAMS .................................................................. 10
2.2.5
CAMS przekazuje certyfikat do SPD ........................................................... 10
2.2.6
CAMS przekazuje binaria do SPD............................................................... 11
2.2.7
SPD przekazuje informacje o wyniku personalizacji do CAMS ........................ 11
2.2.8
CAMS 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
CAMS 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 CAMS ..... 15
2.4.2
CAMS przekazuje wygenerowane dane aktywacyjne do drukarni ................... 15
2.4.3
Drukarnia przekazuje do CAMS informację o wysłaniu danych aktywacyjnych . 15
2.4.4
CAMS 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 CAMS .. 19
2.6.2
CAMS Przekazuje informację o unieważnieniu certyfikatów do RDO ............... 19
2.7
Odblokowanie aplikacji podpisu po zablokowaniu .......................................................... 20
2.7.1
3.
Karta zestawia połączenie do odblokowania dostępu .................................... 21
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 Produkcj a blankietów kart
Zewnętrzne::RDO
Zewnętrzne::System
Personalizacji
Dokumentów
Z obrębu PKI::CAMS
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 CAMS przekazuje profil karty do MSWiA
Źródło informacji
Odbiorca informacji
CAMS
MSWiA (odpowiednia jednostka
organizacyjna)
Opis:
W celu ułatwienia stworzenia specyfikacji na potrzeby zamówienia kart u producentów CAMS
może wyeksportować profil karty.
2.1.2 Dostawca blankietu przekazuje informacje o wyprodukowanych blankietach
do CAMS
Odbiorca informacji
Dostawca blankietu
CAMS
Opis:
Informacja o blankietach wyprodukowanych na potrzeby projektu pl.ID powinna być
przekazywana przez dostawców blankietów do systemu CAMS. Ma to na celu dokładną i
scentralizowaną ewidencję tychże blankietów. Dla systemu CAMS 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 CAMS
Odbiorca informacji
Dostawca blankietu
CAMS
Opis:
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) CAMS 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 CAMS informuje RDO o brakach w kartach wysłanych do SPD
Odbiorca informacji
CAMS
RDO (OEWiUDO)
Opis:
CAMS 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 CAMS informacje o otrzymaniu blankietów
Odbiorca informacji
SPD
CAMS
Opis:
W celu zachowania ścisłej kontroli nad wyprodukowanymi blankietami, SPD przekazuje
informacje o otrzymaniu blankietów o danych numerach do CAMS. 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 Personalizacj a dokumentu
Zewnętrzne::RDO
Z obrębu PKI::CAMS
Zewnętrzne::System
Personalizacji Dokumentów
Z obrębu PKI::Szyna
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 CAMS, w przypadku takiej konieczności
może zwrócić się do CAMS o binaria aplikacji).
2.2.1 Odbiór zlecenia personalizacji z RDO
Odbiorca informacji
OEWiUDO (RDO)
CAMS
Opis:
W tym scenariuszy RDO odbiera z gminy wniosek o wydanie dowodu osobistego i zleca
personalizację do komponentu CAMS. 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 CAMS.
2.2.2 Przekazanie zlecenia personalizacji do SPD
Odbiorca informacji
CAMS
SPD
Opis:
CAMS 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 CAMS 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 CAMS, 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
Odbiorca informacji
SPD
CAMS
Opis:
W momencie, w którym SPD pobiera dany blankiet do personalizacji następuje związanie
blankietu z danymi osoby. SPD przekazuje informację do CAMS o rodzaju i oznaczeniu
pobranej do personalizacji karty. W ten sposób w CAMS 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 CAMS, czy też z udziałem szyny integracyjnej PKI.
Zakres przekazywanych informacji: identyfikator blankietu umożliwiający jednoznaczne
powiązanie z rekordem w bazie kart CAMS, identyfikator zlecenia personalizacji.
2.2.4 SPD przekazuje CSR do CAMS
Odbiorca informacji
SPD
CAMS
Opis:
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 CAMS, który przekazuje je do
odpowiednich CC, gdzie urzędy operacyjne generują certyfikaty i przekazuje go do SPD.
2.2.5 CAMS przekazuje certyfikat do SPD
Odbiorca informacji
CAMS
SPD
Opis:
Po otrzymaniu wniosku o certyfikat Centrum Certyfikacji generuje certyfikat cyfrowy (podpisu
osobistego, do uwierzytelnienia, itd.) i przekazuje go poprzez szynę integracyjną PKI do
CAMS. CAMS 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 CAMS przekazuje binaria do SPD
Odbiorca informacji
CAMS
SPD
Opis:
W przypadku, gdy SPD nie będzie posiadało możliwości przygotowania stosownych wersji
binarnych aplikacji do umieszczenia na karcie CAMS musi umożliwiać przygotowanie i
przekazanie odpowiednich danych do SPD. W takim przypadku SPD przekazuje poprzez
brokera integracyjnego PKI stosowny komunikat do CAMS (komunikat musi zawierać
identyfikator umożliwiający zidentyfikowanie po stronie systemu CAMS typu karty, ew. może
zawierać ten typ). CAMS 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 CAMS
Odbiorca informacji
SPD
CAMS
Opis:
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 CAMS. Zawartość przekazywanego komunikatu to co najmniej:
identyfikator umożliwiający zidentyfikowanie karty po stronie CAMS (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 CAMS przekazuje informacje o wyniku personalizacji do RDO
Odbiorca informacji
CAMS
RDO
Opis:
Po otrzymaniu informacji z systemu personalizującego SPD, CAMS 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::CAMS
Wniosek o odblokowanie karty()
Proces odblokowania (podanie PIN)
Odblokowanie karty()
Informacja biznesowa o odblokowaniu()
2.3.1 Odblokowanie karty w gminie
Odbiorca informacji
Karta (czytnik w gminie), RDO
CAMS
Opis:
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 CAMS żądanie aktywacji karty po otrzymaniu uwierzytelnionego przez
urzędnika gminnego wniosku.
CAMS 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
CAMS, 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 CAMS przekazuje informację o odblokowaniu karty do RDO
Odbiorca informacji
CAMS
RDO
Opis:
Po wykonaniu technicznych czynności związanych z odblokowaniem, CAMS 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 CAMS 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 aktyw acj ę certyfikatu podpisu osobistego
Zewnętrzne::RDO
Z obrębu PKI::CAMS
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 CAMS
Odbiorca informacji
RDO
CAMS
Opis:
RDO przekazuje do CAMS żą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 CAMS przekazuje wygenerowane dane aktywacyjne do drukarni
Odbiorca informacji
CAMS
Drukarnia
Opis:
CAMS 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 CAMS informację o wysłaniu danych aktywacyjnych
Odbiorca informacji
Drukarnia
CAMS
Opis:
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 CAMS przekazuje informację o wysłaniu danych aktywacyjnych do RDO
(opcjonalne)
Odbiorca informacji
CAMS
RDO
Opis:
Po otrzymaniu informacji z drukarni o fakcie wysłania pocztą koperty z danymi aktywacyjnymi
dla aplikacji podpisu osobistego, CAMS 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 Aktyw acj a certyfikatu podpisu
Zewnętrzne::ZMOKU SOO
Karty
Z obrębu PKI::CAMS
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
Odbiorca informacji
ZMOKU
CAMS
Opis:
ZMOKU przekazuje systemowi CAMS 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
Odbiorca informacji
Karta (czytnik w gminie), CAMS
CAMS, Karta (czytnik w gminie)
Opis:
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
CAMS. Do systemu CAMS przesyłany jest PIN wprowadzany przez posiadacza karty.
2.5.3 Nadanie nowego PINu
Odbiorca informacji
Karta (czytnik w gminie), CAMS
CAMS, Karta (czytnik w gminie)
Opis:
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 CAMS. System weryfikuje czy otrzymał
zlecenie aktywacji aplikacji dla tego PIN’u. W przypadku pozytywnej weryfikacji karty system
CAMS 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 CAMS.
sd Automatyczne uniew ażnienie dow odu osobistego
Zewnętrzne::RDO
Z obrębu PKI::CAMS
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 CAMS
Odbiorca informacji
RDO
CAMS
Opis:
W związku z automatycznym unieważnieniem dowodu osobistego RDO przekazuje do
podsystemu PKI (CAMS) 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 CAMS Przekazuje informację o unieważnieniu certyfikatów do RDO
Odbiorca informacji
CAMS
RDO
Opis:
CAMS 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
Karty
Z obrębu PKI::CAMS
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
Odbiorca informacji
Karta
CAMS
Opis:
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 CAMS. Użytkownik wprowadza nowy numer PIN (np. z użyciem pin-padu, lub
wirtualnego pin-padu). System CAMS nadaje nowy numer PIN aplikacji do składania podpisu
osobistego. CAMS 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

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

Transkrypt

Podobne dokumenty

Opinia w sprawie archiwizacji wyników badań pracowni serologii

_ wii*

http://ezd.nauka.gov.pl/ePUAP/ViewProxy.aspx

Szykuje się rewolucja w dowodach osobistych

Przetarg na PKI w MSWiA pod Microsoft?

Biblioteki programistyczne us∏ug infrastruktury klucza