Za niedawnymi problemami z bezpieczeństwem niemieckich elektronicznych kart identyfikacyjnych nieuchronnie muszą pojawić się analogiczne wątpliwości odnośnie pl.ID. Computer Chaos Club zademonstrował jak z niemieckich kart można ściągnąć dane biometryczne oraz kod PIN. Ekstrapolowanie tych problemów na projekt pl.ID nie jest uzasadnione bo polskie karty nie będą ani bezstykowe ani nie będą zawierać danych biometrycznych.
Informacje na stronach CPI są cokolwiek szczątkowe. Jedyne informacje na temat bezpieczeństwa kart są sformułowane ogólnikowo i nie poparte żadnymi argumentam: “obywatel nie będzie mógł odczytać danych zapisanych w warstwie elektronicznej”, “dowód osobisty będzie zabezpieczony zarówno w warstwie graficznej, jak i w części elektronicznej” (Ochrona danych). Zabawnym przykładem urzędniczej mowy konspiracyjnej jest sekcja Technologia, w której autor na swoje pytanie (“Jakie parametry techniczne będzie posiadał elektroniczny dowód osobisty”) sam sobie udziela odpowiedzi nie na temat (“Jednostką, która zajmuje się koordynacją działań…”).
Wiemy, że w polskiej administracji publicznej nie ma tradycji traktowania obywatela jako interesariusza projektów robionych deklaratywnie dla niego. Gdyby jednak CPI chciało wyjść na przeciw oczekiwaniom społeczeństwa informacyjnego i zapewnić sobie miękkie lądowanie w razie odkrycia błędów w przyszłości to warto by podjęło następujące działania:
- Sporządzenie jakościowej analizy ryzyka systemu pl.ID. Umożliwi zademonstrowanie, że CPI zidentyfikowało ryzyka, na które narażony jest system i odpowiednio się przed nimi zabezpieczyło, zaś urzędnicy i obywatele będą świadomi przed czym system chroni, a przed czym nie. W szczególności umożliwi to uniknięcie w przyszłości żenujących sporów w rodzaju kłótni o różne znaczenia "bezpiecznego urządzenia" (G DATA vs Certum).
- Zamówienie niezależnej oceny bezpieczeństwa architektury projektu. Pozwoli to zademonstrować, że architektura nie jest oparta o widzimisię studenta ostatniego roku AGH zatrudnionego przez wiodącą polską spółkę informatyczną na stanowisku senior security architect.
- Zamówienie niezależnego testu penetracyjnego systemu. Pozwoli to zademonstrować, że CPI uniknęło popełnienia błędów implementacyjnych np. w wyniku nieroztropnego zawierzenia producentowi jednej z technologii. Na dłuższą metę pozwoli to również uniknąć żenujących tłumaczeń, że "z prawnego punktu widzenia wszystko jest w porządku" i konieczności dołożenia do budżetu zakończonego już projektu kolejnego miliona na załatanie dziur przez tego samego producenta (ZTM). </ul> Oczywiście mam świadomość, że np. testy penetracyjne są często prowadzone tak czy inaczej. Niestety przykład uruchomienia ePUAP sprzed dwóch lat pokazuje, że marnowany jest cały ich potencjał jako narzędzia dającego projektantom podstawę do twierdzenia "tak, dochowaliśmy najwyższej staranności". Wyduszona z zamawiającego odpowiedź "testy zostaną przeprowadzone", anonimowy wykonawca testu, nieopublikowane wyniki (executive summary) i ogólna atmosfera ściemniania nie budują zaufania do produktu jak i administracji jako takiej. Tymczasem administracja publiczna, jako dysponent środków publicznych, powinien dokładać szczególnych starań by przekonać obywatela, że jednak warto na to państwo płacić podatki.