Jaka karta do dowodu?

Problemy z pamięcią

Jaka karta do dowodu?

Porównanie standardów kart inteligentnych

Jednym z ograniczeń technicznych, które skutkują koniecznością recertyfikacji karty Java po każdej zmianie aplikacji, jest fakt, że karta tego standardu nie chroni pamięci. Oznacza to, że każda z aplikacji musi być certyfikowana, ponadto należy ponownie certyfikować kartę po każdej zmianie oprogramowania. Na karcie nie wbudowano mechanizmów ochrony pamięci i komunikacji, zatem aplikacje muszą być dokładnie sprawdzone, by nie naruszały wzajemnie swoich zasobów, a następnie certyfikowane. W pewnych przypadkach generuje to duże koszty. Przykładem niezbyt korzystnej umowy może być wdrożenie kart Java w jednej z pomorskich uczelni - koszty wgrywania informacji do karty, wykonywane co semestr, są bardzo duże w skali uczelni, gdyż nie dysponuje ona pełną kontrolą nad informacją umieszczaną na karcie.

Całe państwo zależne od jednej firmy

O wiele ważniejszym problemem od zablokowania modyfikacji kart jest uzależnienie podmiotu państwowego od pojedynczego dostawcy.

O ile w przypadku kart Java można choćby w pewnym zakresie przygotować projekt przy użyciu kart różnych dostawców (napisanie aplikacji w języku Java), o tyle karty natywne muszą być oprogramowane przy wykorzystaniu narzędzi dostarczonych przez producenta karty. Jeśli wierzyć nieoficjalnym informacjom, chęć uczestnictwa w projekcie pl.ID zgłosiły podmioty związane pośrednio i bezpośrednio tylko z jednym zagranicznym producentem kart natywnych. Wdrożenie nowych dowodów osobistych jest największym tego typu projektem związanym z kartami w Europie i ewenementem byłby brak kontroli państwa nad tym, co jest instalowane w kartach. Nie wszystkie platformy kart natywnych są certyfikowane, podobnie trudno spotkać przypadek audytu kodu karty przez niezależnych ekspertów - oprogramowanie kart natywnych jest własnościowym know-how producenta. W przypadku kart Java jest nieco lepiej, ale producenci nie informują odbiorców, że nie ma pełnej interoperacyjności między platformami kart dla każdej aplikacji - aby aplikacja mogła być przeniesiona do karty Java innego dostawcy, niezbędna jest jej rekompilacja.

Opcje zbliżeniowe

Bardzo dobrym pomysłem jest połączenie funkcji stykowych związanych na przykład z podpisem elektronicznym z opcjami połączeń bezstykowych, przydatnych m.in. w uwierzytelnieniu do urządzeń bardzo niskiego ryzyka. Należy przy tym zapewnić nie tylko certyfikację aplikacji, ale także ochronę dostępu do poszczególnych interfejsów, by aplikacje można było podzielić na te, które mają dostęp stykowy, bezstykowy lub oba, a także na te, które mogą kontrolować wbudowany osobno moduł prostego uwierzytelnienia bezstykowego. Karta zamknięta nie obsłuży żadnego z tych rozwiązań, podstawowe opcje można osiągnąć za pomocą kart Java, najbardziej zaawansowanym certyfikowanym standardem jest nowszy Multos.

Java, karty natywne, a może ktoś trzeci?

Obecnie dyskusja na temat dowodu osobistego koncentruje się między wyborem kart Java a zamkniętych i mało wspomina się o zaawansowanym standardzie, który wydaje się stworzony do potrzeb elektronicznego uwierzytelnienia w nowym dowodzie. Jest to standard Multos, który umożliwia wgranie aplikacji bez konieczności recertyfikowania karty, zabezpiecza dostęp do interfejsów dla aplikacji, a także umożliwia kontrolę pracy i zarządzanie aplikacjami.


TOP 200