Skąd ta mnogość instytucji, standardów i wymagań? Każda z oceniających instytucji ma inne, konkretnie określone oczekiwania w stosunku do rozwiązań kryptograficznych, które raczej rzadko są w pełni zgodne z potrzebami analogicznej organizacji w innym kraju. Z tego samego powodu prowadzona jest osobna certyfikacja dla wojska, a osobna dla zastosowań cywilnych.

Ponadto urządzenia podlegające certyfikacji są stosowane do ochrony najgłębiej strzeżonych sekretów każdego państwa. Historia służb specjalnych jest pełna przypadków podsuwania przeciwnikowi urządzeń wyposażonych w funkcje pozwalające na odszyfrowanie wiadomości, zdalne przejęcie kontroli nad urządzeniem lub prowadzenie sabotażu. Od wyrażania wzajemnej przyjaźni między narodami są głowy państw, gdy zaś chodzi o rozwiązania do ochrony informacji, obowiązuje najwyższa nieufność - nawet między wieloletnimi sojusznikami.

Po trzecie, udostępnienie urządzenia do certyfikacji oznacza dla producenta konieczność zaprezentowania nie tylko samego produktu, ale także informacji uważanych powszechnie za tajemnice handlowe. Dla wytwórców urządzeń sieciowych udostępnienie kluczowych informacji o swoich produktach mogłoby ujawnić zbyt wiele tajemnic: własnych lub służb swojego kraju, z którymi współpracują.

Co mówią normy

Normy - czy to ITSEC, czy Common Criteria - są zbiorem reguł określających to, jakie parametry powinny spełniać zabezpieczenia w urządzeniach przedstawionych do certyfikacji na różne poziomy. Podejście "amerykańskie" (z Orange Book) różni się tutaj od podejścia europejskiego. Normy europejskie w porównaniu z amerykańskimi są bardziej ogólne i operują na wyższym poziomie abstrakcji. Normy europejskie nie wskazują na konkretne wartości parametrów bezpieczeństwa (długość klucza, algorytm kryptograficzny). Typowe wymagania audytowe z Common Criteria brzmią np. tak w odniesieniu do rejestracji zdarzeń:

"Funkcja bezpieczeństwa ocenianego urządzenia powinna rejestrować następujące zdarzenia podlegające rejestracji: a) włączenie i wyłączenie funkcji rejestracji, b) wszystkie zdarzenia podlegające rejestracji według określonego poziomu [minimalny, podstawowy, szczegółowy, nieokreślony - przyp. aut.], (...) datę i czas zdarzenia, typ zdarzenia oraz przebieg zdarzenia (sukces, niepowodzenie)".

W odniesieniu do kryptografii mamy zaś co następuje:

"Wymagane jest zarządzanie kluczami kryptograficznymi przez cały czas ich «życia». (...). Klucze kryptograficzne powinny przechodzić minimum przez następujące fazy: generowarnie, przechowywanie, niszczenie".

Jak widać, Common Criteria nie jest zbiorem szczegółowych, technicznych zaleceń typu "minimalna długość klucza wynosi X bitów", lecz opiera się na ogólnych założeniach, które są dopiero wypełniane konkretami przez jednostkę certyfikującą urządzenie do określonego zadania i na dany poziom pewności EAL (Evaluation Assurance Level). Standard przewiduje siedem poziomów zaufania: EAL1 to poziom najniższy, zaś EAL7 - najwyższy.

Poziomy wprowadzone przez pozostałe standardy były zbliżone, np. Orange Book określa poziomy od C (najniższy) do A (najwyższy), a ITSEC - sześć poziomów od E1 (odpowiada EAL2) do E6 (odpowiada EAL7). Należy pamiętać, że poniższe porównanie certyfikatów europejskich (ITSEC i Common Criteria) z amerykańskim Orange Book jest jedynie przybliżone - ze względu na różny stopień szczegółowości narzucany przez te standardy.

Co oznacza certyfikat

Tyle o standardach. Co jednak oznacza konkretny certyfikat? Przede wszystkim certyfikatu nie należy traktować w kategoriach "magicznych". Dokument ten potwierdza jedynie (i aż!) zgodność zastosowanych przez producenta rozwiązań z określonymi normami. Mówi o możliwym poziomie zaufania, co nie jest równoznaczne z absolutną odpornością na wszelkie ataki.

Najniższy przydzielany w praktyce certyfikat C2 (wg Orange Book) w odniesieniu do systemów operacyjnych oznacza m.in. fakt zastosowania mechanizmów bezpieczeństwa, które skądinąd wydają się oczywiste. Chodzi np. o wyodrębnienie w systemie osobnych kont dla różnych użytkowników, stratyfikację przywilejów, zabezpieczenie dostępu za pomocą hasła, automatyczne blokowanie kont po określonym czasie, możliwość ustalania praw dostępu do plików itd.

W ten sposób bez problemu uzyskały certyfikaty C2 systemy, takie jak Red Hat Linux czy Windows NT - oczywiście w ściśle określonych wersjach. Nie oznacza to bynajmniej, że nie znaleziono w nich później dziur typowo "programistycznych" (w większości przypadków były to i nadal są luki umożliwiające nadpisanie bufora pamięci), które pozwalają obejść istniejące zabezpieczenia. I znów nie oznacza to, że organ certyfikujący się pomylił - on badał fakt istnienia zabezpieczeń zgodnych ze specyfikacją C2, nie prowadził zaś pełnego audytu kodu źródłowego systemu.

Nie dajmy się więc oczarować, nawet wtedy, gdy produkt ma kilkanaście certyfikatów. W dziedzinie bezpieczeństwa, jak w mało której, ilość nie przechodzi automatycznie w jakość. Trzeba też pamiętać, że posiadanie przez produkt certyfikatu nie zwalnia jego użytkowników z myślenia. Oznacza to, że tak jak każde narzędzie można go błędnie skonfigurować i/lub wręcz wyłączyć wszystkie zabezpieczenia.

Paweł Krawczyk jest niezależnym specjalistą współpracującym m.in. z firmami ABA i SecuRing.