Inwencja "łamaczy" wydaje się nie mieć granic. Architektury, algorytmy, szyfry, systemy, aplikacje itd., które zwykliśmy uważać za bezpieczne, okazują się z biegiem czasu podatne na różnego rodzaju działania zaczepne. Czy z metod, jakimi posługują się "łamacze", producenci oprogramowania mogą wyciągnąć jakieś wnioski?

Co człowiek wymyślił, człowiek złamie - ten argument słyszy się często przy okazji dyskusji na temat szyfrowania i ochrony informacji. Czy tak jest faktycznie? Praktyka pokazuje, że niestety tak, ale atak następuje zwykle z zupełnie innej strony, niż byśmy się spodziewali. Mówiąc o szyfrowaniu danych, w pierwszej chwili myślimy zwykle o jakimś algorytmie szyfrującym, jak 3DES czy AES. Algorytmy te uważane są za bezpieczne. Czy to znaczy, że dane są bezpieczne? Niekoniecznie. Zapominamy bowiem, że sam szyfr to tylko trybik w maszynie przekształcającej tajną informację w zaszyfrowaną.

Skąd przychodzi informacja do zaszyfrowania? Jak jest przetwarzana w pamięci? W jakim trybie przetwarza ją szyfr? Skąd jest brane hasło? Jaki jest faktycznie klucz szyfrujący? Co się dzieje z danymi tymczasowymi lub z hasłem po zakończeniu szyfrowania? Te pozorne drobiazgi to właśnie być albo nie być bezpiecznego systemu ochrony informacji. Każdy z nich w ciągu ostatnich lat doprowadził do ujawnienia informacji z jakiegoś programu bez ataku na sam szyfr. Po prostu dane było łatwiej wykraść innym sposobem, niż łamanie klucza szyfrującego.

Hak się zawsze znajdzie

Z punktu widzenia projektanta świat wygląda zupełnie inaczej, niż z punktu widzenia osoby próbującej uzyskać dostęp do chronionej informacji. Nawet jeśli program używa dobrego szyfru i wymusza stosowanie silnego hasła, niewiele to znaczy, jeśli hasło to po użyciu pozostaje w nieużywanym obszarze pamięci, który następnie jest zapisywany do pliku wymiany na dysku. A może używaliśmy tego samego hasła w komunikatorze, który zapisał je sobie do pliku konfiguracyjnego? Wystarczy tylko dobrze poszukać - w ten sposób policja uzyskiwała cenny materiał dowodowy w kilkudziesięciu głośnych sprawach w USA i w Niemczech. Nawet jeśli producent chwali się zastosowaniem silnego szyfru, to nic straconego. Może tak jak Microsoft w Office 2000, nieumiejętnie go zastosował?

W tym ostatnim przypadku takie samo hasło generowało zawsze taki sam ciąg kluczowy dla algorytmu RC4, który ma tę szczególną cechę, że szyfrowanie nim jest przemienne. Jeśli mamy dwa różne dokumenty zaszyfrowane tym samym hasłem, to dodając je za pomocą operacji XOR zdejmujemy z dokumentów ciąg kluczowy.

Podobny błąd popełnili autorzy szyfrowania WEP dla sieci bezprzewodowych - program implementujący statystyczny atak na RC4 w sieciach WLAN radzi sobie z większością kluczy w czasie od kilkunastu minut do kilku godzin.

Szyfrowy majster-klepka

Szyfr RC4 wynaleziony przez Ronalda Rivesta, współautora słynnego algorytmu klucza publicznego RSA, jest szyfrem strumieniowym o prostej konstrukcji i bardzo wydajnym. Firma Rivesta nie ujawniła go jednak - specyfikacja szyfru przez kilka lat pozostawała tajna, a producenci oprogramowania mogli korzystać wyłącznie z modułów binarnych.

Tak było do 1994 r., kiedy na grupie dyskusyjnej sci.crypt w Usenecie opublikowano anonimowo kod źródłowy szyfru, odtworzony zapewne za pomocą deasemblacji modułu binarnego. Od tej pory rozpoczęto faktycznie analizować ten algorytm - okazało się, że posiada on pewne słabości, jednak żadna z nich nie kompromitowała go we wszystkich zastosowaniach i od razu. I to chyba było największą pułapką na autorów oprogramowania...

Stosowanie RC4 wymaga od projektanta zachowania szeregu ścisłych zasad bezpieczeństwa właśnie poza samym szyfrowaniem bloku danych, na który intuicyjnie zwraca się największą uwagę. Zmiana klucza szyfrującego za pomocą wektora inicjującego (IV - Initialization Vector) i unikanie szyfrowania różnych danych tym samym kluczem to dwie kluczowe "zasady BHP", odnoszące się do RC4.

Jeśli się owych zasad nie dochowa, całość rozwiązania wykorzystującego RC4, który jest sam w sobie szyfrem nie najgorszym, bierze w łeb. Jak pokazuje przykład Office i WEP - nawet zespoły sprawiające wrażenie kompetentnych mogą o tym zapomnieć. Microsoft zresztą powtórzył analogiczny błąd jeszcze kilka razy - m.in. w PPTP i w szyfrowaniu haseł w Windows NT.

Czy każdy dziurawy program zostanie złamany? Na pewno nie. Decyduje o tym bowiem motywacja kierująca tymi, którzy są w stanie poświęcić rok pracy dla złamania algorytmu generowania kodów wbudowanego w blokady niemieckiej wypożyczalni rowerów (przypadek opisany niedawno na CW Online). Ci, którzy mogą sobie na to pozwolić, zwykle robią to z ciekawości, albo traktują jako wyzwanie intelektualne.

Jeśli więc, drogi Czytelniku, zastanawiałeś się kiedyś, czy komukolwiek będzie się chciało łamać Twój własny - nie tak dobry jak profesjonalne, ale przecież i nie taki znowu słaby szyfr - przypomnij sobie, jak odnosiłeś się w dzieciństwie do czasochłonnego, ale jakże ciekawego rozkładania na elementy pierwsze zabawek lub urządzeń. Na to zawsze starczało czasu.

Koniec ery samoróbek

Czy z tak szybkich postępów w kryptoanalizie producenci oprogramowania mogą wyciągnąć jakieś wnioski? Niewątpliwie tak - i niektórzy wyciągają. Duzi producenci oprogramowania zauważyli w końcu, że opracowywanie własnych metod kryptograficznych jest nieopłacalne.

Lepiej, by zajmowały się tym wyspecjalizowane firmy i instytuty badawcze, które udostępniają gotowe szyfry, protokoły i algorytmy. Analiza bezpieczeństwa nowego protokołu lub kryptoanaliza nowego szyfru to długotrwały i kosztowny proces. Mało komu - poza instytucjami rządowymi - opłaca się to robić na własną rękę, zwłaszcza gdy wiadomo, że dostępne są gotowe algorytmy, które ten proces już przeszły, i to razem z kodem źródłowym.

Kilka lat temu głównym dostawcą standardów kryptograficznych był amerykański Narodowy Instytut Standardów i Technologii (NIST), będący "cywilnym" ramieniem supertajnej jeszcze w latach 80. Narodowej Agencji Bezpieczeństwa (NSA). Agencja jest pracodawcą dla największej na świecie liczby matematyków i kryptologów, a od kiedy "wyszła z podziemia" - wspomaga także sektor publiczny doradztwem w zakresie ochrony informacji.

Do końca lat 90. standardem szyfrowania był algorytm DES (Data Encryption Standard), opracowany przez IBM jeszcze w latach 70., oczywiście przy starannie ukrywanej współpracy NSA. Później nastąpiła rewolucja - w ogłoszonym przez NIST konkursie na następcę DES wygrał szyfr Rijndael wymyślony przez... Holendrów, co dla wielu amerykańskich producentów oprogramowania było szokiem. Ale Rijndael przemianowany później na AES (Advanced Encryption Standard) zyskał bardzo szybko popularność jako algorytm szybki i bezpieczny.

Z promowania własnych algorytmów kryptograficznych zrezygnowali najwięksi gracze na rynku i, co ciekawe, we wszystkich przypadkach historia była podobna. Szybki szyfr strumieniowy FWZ-1 promowany przez Check Point w swoich urządzeniach VPN był tajny - tzn. nie był nigdy opublikowany ani poddany publicznej kryptoanalizie. Jednak w lipcu 2000 r. jego specyfikacja odzyskana znowuż prawdopodobnie za pomocą debuggera została opublikowana anonimowo w grupie dyskusyjnej sci.crypt. Wkrótce potem Check Point ograniczył obsługę FWZ-1 do zachowania wstecznej kompatybilności i zaczął zachęcać użytkowników do używania 3DES i AES.

Podobnie było z algorytmem używanym do generowania haseł jednorazowych w tokenach RSA SecurID, który również był tajny, dopóki nie odtworzono go i nie opublikowano w Usenecie. Obecnie RSA używa jawnego algorytmu generowania haseł opartego na AES. Podobne przykłady można mnożyć. Kto pamięta dzisiaj o protokole PCT (Private Communications Transport), opracowanym w czasie "wojny przeglądarek" i promowanym przez Microsoft jako alternatywa dla wymyślonego przez Netscape SSL (Secure Sockets Layer)?

Równie marginalne zastosowania ma obecnie protokół szyfrowanych tuneli PPTP (Point-to-point Tunneling Protocol) i związanym z nim MPPE (Microsoft Point-to-point Encryption). Spore znaczenie miał tutaj fakt, że rozwój tych protokołów był prowadzony w typowy dla Microsoftu sposób - to znaczy zatajano fragmenty specyfikacji lub w ogóle jej nie udostępniano. Nie bez znaczenia był również fakt, że obie wersje PPTP - pierwsza i druga - okazały się dziurawe jak sito.

Reguły konkursowe

We wszystkich tych przypadkach z własną inwencją programistów małych i dużych firm wygrał model rozwoju oparty na całkowitej jawności algorytmu i jego kryptoanalizy.

Dominują tutaj dwa modele - konkurs, w którym wybierane są całościowe rozwiązania opracowane przez konkurujące ze sobą firmy (tak przebiegał konkurs na AES) lub komitet ekspertów, który opracowuje protokół od początku do końca.

Życie pokazało, że model "konkursowy" jest zdecydowanie efektywniejszy niż kolegia eksertów - konkurs na AES doprowadził do wyłonienia dobrego algorytmu bez opóźnień i zgodnie z założonym harmonogramem. Główną zaletą konkursu jest to, że firmy zgłaszają do niego produkty, które są spójne i odpowiadają założeniom - jeśli nie, propozycje są eliminowane na wejściu.