Kryptografia towarzyszy nam niemal wszędzie, a jednak nie czujemy się bezpieczni. Być może dlatego, że wielu ludziom wciąż wydaje się, że ich świetne pomysły są na pewno lepsze niż standardy.

Szyfrowanie danych robi się coraz bardziej modne, co ma związek z dostępnością odpowiednich narzędzi i bibliotek. Szyfrować dane potrafi już obecnie prawie każda aplikacja biurowa, system biznesowy czy nawet popularny komunikator tekstowy. Wciąż pojawiają się nowe programy do zabezpieczania danych. Niestety, większość tych zabezpieczeń - zazwyczaj projektowanych na własną rękę - szybko okazuje się niewystarczająca. Gdy to wychodzi na jaw, autor szybko przygotowuje poprawkę łatającą jeden konkretny błąd. Wkrótce pojawia się jednak następny - i tak bez końca.

Nie może być inaczej, faktem jest bowiem, że autorzy dostępnych w Internecie programów - a nawet wielcy producenci oprogramowania - popełniają błędy kardynalne. Lista jest długa: generują klucze bez danych losowych, korzystają z egzotycznych szyfrów, które okazują się potem słabe, korzystają z dobrych szyfrów, ale w błędny sposób... Podejmują zresztą wiele innych, dziwnych, bezpiecznych jedynie w ich mniemaniu zabiegów, które można porównać do zakładania zamka szyfrowego na pozbijanych byle jak z desek drzwiczkach do komórki z węglem.

O jeden błąd za daleko

W styczniu bieżącego roku ujawniono, że szyfrowanie dokumentów w Wordzie i Excelu posiada poważną lukę, która powstała właśnie z powodu błędnego zastosowania dobrego szyfru.

Dokument zapisany z hasłem jest szyfrowany za pomocą algorytmu RC4, który jest względnie bezpieczny jako taki, ale ponieważ samo szyfrowanie jest realizowane przez odwracalną operację logiczną XOR, z jego stosowaniem wiąże się w praktyce spore niebezpieczeństwo.

Jeśli dwa różne teksty zaszyfrujemy z użyciem tego samego hasła, połączenie dwóch szyfrogramów i wykonanie na ich sumie operacji XOR "zedrze" z nich losowość wprowadzoną przez szyfrowanie. Brak losowości w ciągu bitów to pierwszy krok do wykonywania na nim wielu prób statystycznych, mogących doprowadzić nie tylko do poznania treści szyfrogramu.

Dokładnie ten błąd popełnili programiści Microsoftu w Wordzie i Excelu. Dodajmy, że zabezpieczenie hasłem tych dokumentów jest też słabe, choć z innego powodu. Klucz szyfrujący w funkcji RC4 ma długość raptem 40 bitów, a to według dzisiejszych standardów bezpieczeństwa informacji niewiele. A tak na marginesie, 40-bitowy klucz w RC4 stoi w kontraście z faktem, że wprowadzane przez użytkownika hasło jest przekształcane za pomocą funkcji skrótu MD5, dającej wynik o długości 128 bitów.

Takie błędy nie powinny się zdarzać w ogóle - tym bardziej w firmie o takim udziale w rynku informatyki dla biznesu i tak dużej renomie. Niestety, zdarza się to już jej co najmniej trzeci raz. W pierwszej wersji opracowanego przez koncern z Redmond protokołu PPTP (Point-to-Point Tunneling Protocol - protokół opracowany przez Microsoft na potrzeby zestawiania kanałów VPN) dwa strumienie danych były również szyfrowane za pomocą RC4 i również za pomocą identycznego klucza. Później analogiczny błąd odnaleziono w funkcji SYSKEY stosowanej do szyfrowania haseł w Windows NT.

Błędem innego rodzaju, ale o wiele poważniejszych konsekwencjach była luka w Internet Explorerze ujawniona w 2003 r. Przeglądarka nie dość dokładnie sprawdzała certyfikat serwera przy połączeniach SSL. W rezultacie użytkownikowi IE można było "podstawić" fałszywy serwer z fałszywym certyfikatem. Wystarczyło jedynie, by był on podpisany przez dowolny autentyczny certyfikat innego serwera WWW, wystawiony przez Thawte, Verisign lub innego wystawcę.

Istota błędu polegała na tym, że certyfikat przyznany jednemu serwerowi nie może służyć do podpisywania innych certyfikatów. Nie może, ale Explorer nie raczył się tym przejmować. Do czasu naprawienia błąd ten niweczył całkowicie zabezpieczenia dawane przez infrastrukturę klucza publicznego (PKI) i po raz kolejny podważył zaufanie do niej.

Chłopiec do bicia

Algorytm WEP przeznaczony do szyfrowania danych w sieciach WLAN został opracowany przez międzynarodową grupę roboczą złożoną z producentów sprzętu do sieci bezprzewodowych. Ze względu na ograniczenia sprzętowe (mała wydajność procesorów i mała ilość pamięci) szyfrowanie WEP było z założenia okrojone. Tu również wykorzystywało algorytm RC4. Nie byłoby to może takie złe, bo w tym konkretnym przypadku szyfr RC4 byłby wystarczający. Byłby - gdyby w samym sposobie konstruowania zaszyfrowanych pakietów nie popełniono kardynalnych błędów, które w konsekwencji doprowadziły do pojawienia się programów łamiących szyfrowanie WEP w kilka, a co najwyżej kilkadziesiąt minut.

Głównym problemem jest fakt, że WEP jest zwykle implementowany w sprzęcie, a więc nie da się go naprawić przez uaktualnienie oprogramowania firmware. Stojąc pod ścianą, producenci rozwiązań WLAN rozpoczęli rozpaczliwe łatanie WEP. Pole manewru - z racji błędów popełnionych w samej architekturze - było mocno ograniczone. Każda poważniejsza zmiana oznaczałaby brak wstecznej kompatybilności, czego producenci starali się za wszelką cenę uniknąć.

Jako protezę do oprogramowania urządzeń WLAN wprowadzono algorytm TKIP (Temporary Key Integrity Protocol), którego zadaniem jest - w uproszczeniu - dynamiczna zmiana kluczy WEP na tyle często, by potencjalny włamywacz nie zdążył ich złamać. Niezależnie od TKIP, jako jego uzupełnienie/wzmocnienie, powstało około dwudziestu różnych, wzajemnie niekompatybilnych, protokołów uwierzytelniania użytkownika. Jak na ironię, część z nich okazała się niecałkiem doskonała, np. LEAP.

Błędów tych jest pozbawiony nowy protokół szyfrowania CCMP wykorzystujący szyfr AES. Jego największą wadą jest to, że... jest on słabo rozpowszechniony. Większość urządzeń oferuje nadal jedynie oryginalny WEP i jego wersję "połataną", to znaczy z TKIP. A ten jest nadal podatny na wiele starych ataków, bo TKIP tak naprawdę rozwiązał tylko jeden problem - podatność na atak Fluhrera, Mantina i Shamira. Ale inne pozostały - na przykład ataki umożliwiające rozszyfrowywanie pakietów przez odsyłanie ich z odpowiednimi modyfikacjami do stacji bazowej WLAN.

Patrząc z perspektywy kilku lat, można zaryzykować stwierdzenie, że beztroska, jaka towarzyszyła opracowaniu WEP, położyła na łopatki ekonomiczną przewagę sieci WLAN nad sieciami kablowymi. Oszczędności na okablowaniu, jakie osiągniętowdrażając sieć WLAN, zostały w dużej mierze "zjedzone" przez konieczność wymiany sprzętu i oprogramowania radiowego na obsługujące TKIP, a obecnie być może po raz kolejny, w związku z wejściem do użytku protokołu 802.11i.