, Kutyłowski Miroslaw, Strothmann Willy Kryptografia 

[ Pobierz całość w formacie PDF ]
.W szyfrowanej wiadomości zawieramyinformacje o Bobie, by uniemo\liwić Malletowi nawiązanie z Alicekomunikacji za pomocą tego samego klucza.Protokół 2:1.Bob wysyła Alice ciąg N.Ciąg ten nie mógł być wcześniej u\yty dotego celu.N nie musi być zaszyfrowany.2.Alice wybiera losowo klucz Y, szyfruje wiadomość zło\oną z T,N iidentyfikatora Boba za pomocą klucza k i otrzymany kryp-togramprzesyła Alice.3.Bob deszyfruje Y.W powy\szym protokole Mallet nie mo\e zastosować ataku przez po-wtórzenie, Bob za ka\dym razem generuje inny ciąg N.Protokół 3:1.Alice wybiera losowy ciąg Y (albo ciąg określający bie\ący czas) iprzesyła go Bobowi w niezaszyfrowanej postaci.2.Zarówno Alice, jak i Bob obliczają wartość funkcji hashującej dlaciągu zło\onego z r A i wspólnego klucza k.Wartość ta jest ustalonymwspólnym kluczem.154 KryptografiaUstalenie klucza za pomocą pośredniczącego serwera: w praktyceniewiele par u\ytkowników dysponuje wspólnym, wcześniej ustalonymkluczem.Klucze takie łatwiej ustalić pomiędzy ka\dym z u\ytkownikówlokalnego systemu a specjalnie chronionym serwerem.W takim przypadkumo\na przerobić protokoły 1 i 2 w następujący sposób: jeśli Alice chceprzesłać bezpiecznie wiadomość do Boba, to wysyła ją do serwerazaszyfrowaną za pomocą klucza słu\ącego do komunikacji z serwerem.Serwer deszyfruje tę wiadomość i zaszyfrowuje ją ponownie za pomocąklucza słu\ącego do komunikacji z Bobem.Bob otrzymuje ten kryptogram iodzyskuje wiadomość wysłaną przez Alice.10.2.2.Uzgadnianie klucza przez szyfrowanieasymetryczneJednym z najwa\niejszych w praktyce zastosowań algorytmów asyme-trycznych jest uzgadnianie kluczy.Protokoły są w tym przypadku bardzoproste, zakładają jedynie dostępność kluczy publicznych (i ewentualnieinformacji potrzebnych do sprawdzenia podpisów cyfrowych).Protokół bez podpisywania:1.Alice ustala klucz k i szyfruje za pomocą publicznego klucza Bobawiadomość(Jfc,ID(Alice)),gdzie ID(Alice) jest identyfikatorem Alice.2.Bob deszyfruje wiadomość od Alice.Gdyby w powy\szym protokole nie był zawarty identyfikator Alice, toMallet mógłby wysłać zaszyfrowany klucz k do Boba (jakkolwiek sam gonie zna).Na tej podstawie mógłby otrzymać od Boba plik zaszyfrowanykluczem k, który mógłby posłu\yć do kryptoanalizy i złamania klucza k.155 M.Kutyłowski, W.-B.StrothmannProtokół z podpisem:1.Alice ustala klucz k i szyfruje za pomocą publicznego klucza Bobawiadomość(M,sigAlice(ID(Alice),U)),gdzie t jest aktualnym czasem, ID(Alice) oznacza identyfikator Alice,sig jest podpisem cyfrowym.2.Bob deszyfruje wiadomość od Alice, sprawdza podpis i o ile wiadomość ma postać taką, jaka wynika z protokołu, to akceptuje kjako klucz.W powy\szym protokole dodaliśmy informacje o momencie wysłaniaklucza, dla zapewnienia jego  świe\ości".Podpis cyfrowy Alice podinformacjami o k i t gwarantuje, \e wiadomość istotnie pochodzi od Alice.Ostatni protokół mo\na zmodyfikować w ten sposób, \e podpis cyfrowy niejest szyfrowany wraz z kluczem k.Jest to, oczywiście, tylko wtedy mo\liwe,gdy podpis nie zdradza treści podpisywanego tekstu.10.2.3.Atak man in the middleProtokoły uzgadniania kluczy nie korzystające z uprzednio znanych se-kretów napotykają niebezpieczeństwo ataku typu man in the middle.Dlaopisania jego mechanizmu rozpatrzmy następującą sytuację.Alice i Bobpragną wymienić tajne informacje.Wykorzystują do tego następujący,zdawałoby się, bezpieczny protokół:1.Bob przesyła Alice swój klucz publiczny.2.Alice wybiera losowo x, klucz sesyjny.3.Alice szyfruje x za pomocą klucza publicznego Boba i przesyłaotrzymany kryptogram Bobowi.4.Bob deszyfruje x za pomocą swego klucza prywatnego.5.Alice i Bob u\ywają klucza sesyjnego x do dalszego komunikowaniasię.156 KryptografiaJest to pierwszy opisany przez nas protokół z tą ró\nicą, \e Alice przedrozpoczęciem procedury nie posiada klucza Boba.Załó\my \e Mallet jestzłowrogim przeciwnikiem kontrolującym linię komunikacyjną, poprzezktórą Bob i Alice przesyłają sobie pakiety.Mallet bywa te\ nazywany manin the middle, gdy\ znajduje się między Alice i Bobem i kontrolujekomunikaty, jakie między sobą wymieniają.Mallet mo\e niepostrze\enie wpłynąć na przebieg powy\szego protokołu:1.Bob przesyła Alice swój klucz publiczny.Mallet przechwytuje list od Boba i przesyła Alice klucz publiczny y, doktórego zna odpowiadający klucz prywatny.2.Alice wybiera losowo klucz sesyjny x.3.Alice szyfruje x za pomocą y myśląc, \e to klucz publiczny Boba iwysyła Bobowi zaszyfrowany klucz x.Mallet przechwytuje ten list, deszyfruje list za pomocą znanego mu klu-cza prywatnego.Następnie Mallet szyfruje x za pomocą publicznegoklucza Boba i wysyła Bobowi otrzymany kryptogram.4.Bob deszyfruje x za pomocą swego klucza prywatnego.5.Alice i Bob u\ywają klucz sesyjny x do dalszego komunikowania się.Mallet podsłuchuje komunikację pomiędzy Alice i Bobem, dziękiznajomości x mo\e deszyfrować ka\dą przesyłaną wiadomość.Malletmo\e nawet przechwytywać wiadomości, deszyfrować, dowolnie mody-fikować, szyfrować z powrotem za pomocą x i wysyłać dalej.Interesującym aspektem powy\szego protokołu jest to, \e o ile Mallet niemodyfikuje listów szyfrowanych za pomocą x, to Alice i Bob nie mają szanszorientować się, \e ktoś ich podsłuchuje;.Obrona przed atakiem man in the middle jest bardzo trudna.Jedna zmo\liwych strategii obrony polega na podpisywaniu wiadomości tak, jak wdrugim prezentowanym protokole.W tym przypadku jednak musi istniećmo\liwość weryfikacji podpisów.Wiarygodny sposób polega na korzystaniuz certyfikatów (patrz rozdział 13.2.3.1).Bezpieczny mechanizm weryfikacji podpisów mo\na zorganizować wnastępujący sposób: specjalnie zabezpieczony serwer wydaje certyfikat157 M.Kutyłowski, W.-B.Strothmannka\demu u\ytkownikowi.Certyfikat zawiera dane u\ytkownika i parametrykonieczne do weryfikacji jego podpisu.Certyfikat jest podpisany przezserwer.Gdy Alice pragnie podpisać tekst Z, wtedy oprócz samego podpisupod Z przesyła tak\e (w jawny sposób) swój certyfikat.Odbiorca sprawdzacertyfikat (metoda potwierdzania podpisu serwera jest bowiem powszechnieznana), a następnie sprawdza podpis pod listem od Alice za pomocąparametrów zawartych w certyfikacie.10.2.4.Protokół Diffie-Hellmana i jego pochodneDotychczas omówione metody uzgadniania klucza wymagają, by kluczeprzeznaczone do bezpiecznej komunikacji istniały przed rozpoczęciemprotokołu.Zadziwiające jest to, \e nie jest to wcale konieczne:Protokół Diffie-Hellmana: publicznie znane są p, która jest wystarczającodu\ą liczbą pierwszą, oraz generator a dla Zp.Protokół ma następującąpostać:1 [ Pobierz całość w formacie PDF ]
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • anikol.xlx.pl