Meandry klucza publicznego

Osoba, przed którą stanęło zadanie wdrożenia systemu bezpieczeństwa wykorzystującego infrastruktury PKI, w pierwszej chwili będzie zaskoczona ogromną ilością czynności, które należy wykonać, aby osiągnąć pozornie prosty cel.

Osoba, przed którą stanęło zadanie wdrożenia systemu bezpieczeństwa wykorzystującego infrastruktury PKI, w pierwszej chwili będzie zaskoczona ogromną ilością czynności, które należy wykonać, aby osiągnąć pozornie prosty cel.

Choć sama idea szyfrowania z kluczem publicznym jest stosunkowo prosta, to spełniając kolejne wymagania mające na celu ochronę przed konkretnymi zagrożeniami administrator nagle znajduje się w miejscu, w którym otaczające go detale przysłaniają ogólny sens wykonywanych czynności. Jest to niestety nieunikniona cecha każdej zaawansowanej technologicznie konstrukcji, do których PKI z pewnością należy. Każdy z misternych detali PKI spełnia określoną rolę i trudno rozpatrywać jego funkcję bez zrozumienia całości. Oprócz tego e-podpis wciąż nie jest technologią dojrzałą. Postęp techniczny w branży IT jest niezwykle szybki, a jeszcze szybciej niż technologia zmieniają się spełniane przez nią zadania. Dlatego w specyfikacji podstawowego dzisiaj standardu PKI, jakim jest X.509, znajdziemy wiele pułapek.

Krytyczne flagi

Analizując specyfikację X.509 natrafimy na flagę keyUsage, wskazującą dopuszczalne zastosowania klucza związanego z certyfikatem. Najczęstsze wartości to digitalSignature i nonRepudiation. Wbrew temu, co można pomyśleć, ich faktyczne znaczenie to niepodpisywanie i zapewnienie niezaprzeczalności. Pierwsza oznacza zastosowanie metody podpisywania cyfrowego (m.in. RSA) np. do uwierzytelnienia. Druga za to oznacza właśnie podpisanie jakiejś treści w celu ochrony jej autentyczności, przy czym niekoniecznie musi to mieć cokolwiek wspólnego z niezaprzeczalnością jako taką.

Drugą potencjalną pułapką jest flaga basicConstraints, która - pomimo dość niezobowiązującej nazwy - spełnia krytyczną rolę w bezpieczeństwie całego drzewa zaufania zapewnianego przez X.509. Warto pamiętać, że flagi tej w ogóle nie było w pierwszej wersji specyfikacji X.509 (v1). Dlaczego jest ona tak ważna? Bo wyznacza granice, w których możemy poruszać się, poświadczając autentyczność cudzych certyfikatów. Flaga basicConstraints może przyjmować dwie wartości, z których najważniejsza jest opcja CA. Jeśli ma ona wartość TRUE, to tak oznaczony certyfikat może być wykorzystywany do poświadczania innych certyfikatów.

Jeśli flaga ta nie ma wartości TRUE, to certyfikat taki nie może poświadczać innych certyfikatów - popularne aplikacje nazywają go wówczas certyfikatem End Point, czyli certyfikatem końcowego użytkownika. Świadomie unikam tutaj stosowania czasownika "podpisywać", bo podpis jako taki składamy kluczem prywatnym, a nie certyfikatem, który zawiera klucz publiczny. Certyfikat uczestniczy w procesie podpisywania w X.509 o tyle, że kopiowane są z niego dane podpisującego, a często jest on w całości dodawany do podpisanego pliku.

Certyfikat End Point jest poświadczony przez stojące wyżej CA, ale sam poświadczać nikogo nie może. Dlaczego ta flaga jest tak istotna? Z dwóch powodów - po pierwsze, gdyby nie ona, to centra certyfikacji nie miałyby co robić. Każdy posiadacz certyfikatu X.509 mógłby bowiem poświadczać certyfikaty swoich znajomych - ponieważ "nad nim" stoją zaufane CA, więc jego certyfikat jest zaufany. Podpisane przez niego certyfikaty miałyby więc weryfikujące się "do góry" poprawne drzewo zaufania.

Trzeba też pamiętać o tym, że flaga basicConstraints jest tylko niewielką wartością binarną w pliku certyfikatu. Czy certyfikatem niezawierającym wartości CA:TRUE, czyli teoretycznie do tego nieuprawnionym - można poświadczyć inny certyfikat? Oczywiście, że tak - przecież taka operacja to kwestia podpisania tego innego certyfikatu kluczem prywatnym, który jest pewną liczbą, przechowywaną zresztą zwykle oddzielnie niż związany z nim certyfikat. Za pomocą programu OpenSSL można to zrobić w 30 s, co już w 2002 r. zademonstrowałem przy okazji dziury w MSIE, podpisując fałszywy certyfikat "oficjalnym" certyfikatem zaprzyjaźnionej firmy podpisanym przez Thawte (http://ipsec.pl/msiemitm/msiemitm.pl.php).

Jeśli więc technicznie możemy oszukiwać z łatwością, to jak zabezpieczyć się przed takim fałszerstwem? Otóż cała faktyczna odpowiedzialność za sprawdzenie jej wartości spoczywa więc na oprogramowaniu weryfikującym ścieżkę certyfikacji. Jeśli jest ono napisane niezgodnie z obowiązującymi procedurami lub jest napisane niechlujnie, to cała misterna konstrukcja może się zawalić. A procedury kryptograficzne zmieniają się wraz z postępem nauki. W 2003 r. łatano wiele implementacji algorytmu RSA w związku z tzw. atakiem Bleichenbachera, z kolei w 2006 r. aktualizowano procedury Common Criteria, według których należy testować implementację RSA w związku z odkryciem kolejnych problemów.

Błędy implementacyjne

Przykładem problemu z implementacją była dziura odkryta w 2002 r. przez Mike'a Benhama (http://www.securityfocus.com/bid/5410 ) w oprogramowaniu Microsoftu. Okazało się, że przeglądarka Microsoft Internet Explorer 5 (w rzeczywistości problem dotyczył również Konquerora i BEA Weblogic) ignoruje obecność - lub nieobecność - flagi basicConstraints w drzewie certyfikatów, co de facto niweczyło sens istnienia całej struktury PKI. Każdy mógł, bowiem stworzyć serwis nazywający się "http://www.ABCbank.com ", wygenerować fałszywy certyfikat dla tej nazwy, a następnie podpisać go innym, podpisanym przez zaufane CA certyfikatem. Koszt ataku był więc taki, że należało kupić "oficjalny" certyfikat na dowolną nazwę, bo nie była ona w takim fałszerstwie weryfikowana. Można go również było ukraść z jakiegoś innego serwisu...

Błąd ten powinien uświadamiać nam, jaka odpowiedzialność spoczywa na autorze oprogramowania do weryfikacji podpisu elektronicznego, zwłaszcza że w przypadku podpisu kwalifikowanego procedura weryfikacji jest jeszcze bardziej skomplikowana (trzeba weryfikować ważność certyfikatów w drzewie). Świadomość tej właśnie odpowiedzialności kazała autorom polskich i europejskich regulacji dotyczących podpisu kwalifikowanego wymagać, by oprogramowanie używane do składania i weryfikacji podpisu miało tzw. deklarację zgodności, w której producent pod odpowiedzialnością finansową gwarantuje, że dochował wymaganych prawem procedur (komponenty sprzętowe wymagają jeszcze bardziej sformalizowanych certyfikatów według procedur ITSEC lub Common Criteria).


TOP 200