ZUS i zabobony

Również na naszym lokalnym podwórku można znaleźć ciekawe "kwiatki" organizacyjno-programistyczne związane z szyfrowaniem. Na przykład ciągnącą się już od kilku lat sprawę specyfikacji protokołu KSI MAIL stosowanego przez program Płatnik-Teletransmisja do przesyłania danych do serwerów Zakładu Ubezpieczeń Społecznych. Stroną poszkodowaną są firmy tworzące oprogramowanie FK, które kuriozalnymi decyzjami ZUS zostały skazane na eksport danych o płatnikach składek tylko za pomocą programu napisanego przez Prokom na zlecenie ZUS-u.

Sytuacja jest absurdalna, bo ZUS ujawnił specyfikację komunikatów XML używanych do zapisywania danych płatników, ale kategorycznie odmówił ujawnienia protokołu używanego do ich wysyłania do serwera.

W trwającej od 2002 r. wymianie pism ZUS wykręcał się różnymi przyczynami - a to nie posiadał tej specyfikacji, a to nie był jej właścicielem (bo rzekomo był nim Prokom), a to jej ujawnienie naraziłoby na szwank bezpieczeństwo systemu, i tym podobne.

W końcu w 2003 r. Paweł Hikiert z Ruchu Wolnego Oprogramowania przeanalizował sposób działania KSI MAIL i rozpracował jego specyfikację, która jest obecnie dostępna publicznie w Internecie. Protokół jest standardowy - jedyną ciekawostką jest fakt, że wykorzystano szyfrowanie 3DES tylko z dwoma kluczami zamiast trzech, co daje efektywny klucz o długości 112 bitów, który do tego zastosowania jest w zasadzie wystarczający. Powód, dla którego zastosowano klucz krótszy niż standardowy klucz 168-bitowy, nie jest znany.

Po nagłośnieniu przez prasę ZUS skomentował to odkrycie stwierdzeniem, że ujawnienie metody szyfrowania nie naraża na szwank bezpieczeństwa systemu, skądinąd słusznie, ale przecząc tym samym własnej pokrętnej argumentacji sprzed kilku miesięcy. Niesmak pozostał. Czy ZUS i Prokom próbowały przed obywatelami ukryć tylko ten drobiazg, czy może jeszcze coś poważniejszego?

Standardy, które leczą

Jak sobie z tym radzić? Zaskakująco rzadko programiści i projektanci systemów informatycznych korzystają z rozwiązania najprostszego, czyli nauki na cudzych błędach (ale czy dotyczy to wyłącznie kryptografii?). Kilkanaście lat łatwego dostępu do cywilnej kryptografii umożliwiło stworzenie zestawu standardowych narzędzi poprawnie zabezpieczających dane podczas ich generowania, składowania i przesyłania w dowolnych sieciach.

Tak właśnie ewoluował opracowany przez Netscape Corporation protokół SSL. SSLv2 stosowana przez część starych serwerów WWW jest m.in. podatna na ataki MITM (Man-In-The-Middle). Kiedy wskazano te słabości, opracowana została wersja SSLv3, stosowana w praktyce bez zmian po dziś dzień. Dopiero kilka lat temu protokół "przygarnął" IETF (Internet Engineering Task Force) i opublikował go z kosmetycznymi zmianami pod nazwą TLSv1. Obecnie protokół SSL stał się standardem zabezpieczania pojedynczych połączeń TCP.

Podobną drogę przeszedł standard IPsec - pierwsze dokumenty opisujące składające się nań protokoły ESP i ISAKMP zostały wydane przez IETF w 1992 r. W tym czasie życie wymusiło wprowadzenie rozszerzeń (DPD, NAT-T), usprawnienie niektórych mechanizmów kryptograficznych, wprowadzenie nowych szyfrów (AES) i wydłużenie kluczy dla szyfrów już istniejących.

W bieżącym roku - po ponad 13 latach - ukazuje się nowa wersja dokumentów RFC opisujących architekturę IPsec oraz nowe wersje jego części składowych - IKEv2 i ESPv2.

Korzystanie ze standardowych mechanizmów kryptograficznych ma wiele zalet - przede wszystkim daje gwarancję, że zastosowany komponent jest zgodny z aktualnym stanem wiedzy i odporny na znane ataki.

Po drugie, protokół standardowy posiada szczegółową dokumentację opisującą nie tylko sposób działania, ale także znane ataki i sposoby ochrony przed nimi oraz przewidywany poziom bezpieczeństwa w przyszłości.

Posługiwanie się standardem jest użyteczne, kiedy zleceniodawca wymaga od programisty formalnego opisu zabezpieczeń, a już na pewno wtedy, gdy program ma podlegać formalnej certyfikacji. Przeprowadzenie certyfikacji poziomu ochrony kryptograficznej w ABW dla własnego protokołu kryptograficznego byłoby procesem długotrwałym i kosztownym ze względu na konieczność przeprowadzenie niezależnej kryptoanalizy.

Jeśli stosuje się protokoły standardowe, główny problem stanowi przetłumaczenie dokumentacji oraz wykazanie, że w konkretnym produkcie zastosowano dany algorytm w sposób poprawny i zgodnie z zaleceniami projektantów. Nawet jednak w przypadku produktów niepodlegających certyfikacji nie można przeceniać wagi standardowych protokołów i ich dokumentacji, która w razie jakichkolwiek problemów z bezpieczeństwem stanowi dla projektanta tarczę ochronną. Jeśli wszystkie inne argumenty wydają się mało ważne, ten jeden powinien być przekonujący.