popularne komentowane nowości

popularne

Najczęściej czytane

Jak skutecznie chronić się przed DDoS? (czytane 1240 razy)
Na co zwrócić uwagę przy wdrożeniu IPS i DLP? (czytane 279 razy)
Krajowe Ramy Interoperacyjności opublikowane (czytane 40 razy)

więcej...

Biblioteka Wiedzy poleca

Office 365 - podręcznik użytkownika

Ta książka pokaże Ci, jak wykorzystać chmurowe przetwarzanie danych - a konkretnie Office 365 - aby robić więcej, współpracować łatwiej i działać...
pobierz »

Jak zwiększyć wydajność infrastruktury serwerowej oszczędzając czas i pieniądze? Nowoczesne rozwiązania serwerowe

Niniejszy dokument ma na celu zaprezentowanie sposobów na poprawę funkcjonowania i efektywności działania infrastruktury serwerowej w firmie lub...
pobierz »

Dlaczego warto korzystać z Office 365?

Jakie funkcje i możliwości Microsoft Office 365 decydują o tym, że warto wybrać to rozwiązanie zamiast tradycyjnego pakietu Office i rozwiązań...
pobierz »

Więcej bezpłatnych raportów w serwisie

powiększ tekst

ARCHIWUM

Meandry klucza publicznego

24 kwietnia 2007

Paweł Krawczyk

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.

Computerworld — 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 (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 ( 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ę " 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).

Tekst pochodzi z serwisu Computerworld

12 dalej »