(12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego:

Transkrypt

1 RZECZPOSPOLITA POLSKA (12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (96) Data i numer zgłoszenia patentu europejskiego: (13) (51) T3 Int.Cl. H04L 29/06 ( ) H04L 29/12 ( ) Urząd Patentowy Rzeczypospolitej Polskiej (97) O udzieleniu patentu europejskiego ogłoszono: Europejski Biuletyn Patentowy 2013/37 EP B1 (54) Tytuł wynalazku: Delegacja adresu IP (30) Pierwszeństwo: (43) Zgłoszenie ogłoszono: w Europejskim Biuletynie Patentowym nr 2010/46 (45) O złożeniu tłumaczenia patentu ogłoszono: Wiadomości Urzędu Patentowego 2014/02 (73) Uprawniony z patentu: Telefonaktiebolaget L M Ericsson (PUBL), Stockholm, SE (72) Twórca(y) wynalazku: PL/EP T3 GONZALO CAMARILLO GONZALEZ, Helsinki, FI PEKKA NIKANDER, Jorvas, FI (74) Pełnomocnik: rzecz. pat. Anna Stenzel JWP RZECZNICY PATENTOWI DOROTA RZĄŻEWSKA SP. J. ul. Żelazna 28/30 Sienna Center Warszawa Uwaga: W ciągu dziewięciu miesięcy od publikacji informacji o udzieleniu patentu europejskiego, każda osoba może wnieść do Europejskiego Urzędu Patentowego sprzeciw dotyczący udzielonego patentu europejskiego. Sprzeciw wnosi się w formie uzasadnionego na piśmie oświadczenia. Uważa się go za wniesiony dopiero z chwilą wniesienia opłaty za sprzeciw (Art. 99 (1) Konwencji o udzielaniu patentów europejskich).

2 17380/13/P-RO/AS EP Opis Dziedzina techniki Delegacja adresu IP [0001] Wynalazek dotyczy delegacji adresu IP, a zwłaszcza delegacji odpowiedzialności za adres generowany kryptograficznie od węzła mającego ten adres do węzła dalszego. Tło [0002] Adresy IPv6 mają 128 bitów długości. Pierwsze 64 bity adresu tworzą prefiks trasujący, który w sposób jednoznaczny identyfikuje węzeł dostępowy do Internetu (lub tak zwane "łącze lokalne") stosowany przez terminal lub węzeł IP, podczas gdy ostatnie 64 bity tworzą sufiks hosta, który w sposób jednoznaczny identyfikuje terminal mobilny dla węzła dostępowego (lub wewnątrz łącza lokalnego). Sufiks hosta określany jest jako "identyfikator interfejsu", ponieważ identyfikuje on hosta w sposób jednoznaczny przez interfejs dostępowy. Standardowo, gdy host rejestruje się w węźle dostępowym, host odczytuje prefiks trasujący węzła dostępowego z komunikatu ogłoszeniowego wysłanego z węzła dostępowego. Według IETF RFC3041 host generuje wówczas swój identyfikator interfejsu stosując liczbę losową wygenerowaną przez hosta. Dodatkowo, host może zastosować adres warstwy łącza, aby wygenerować identyfikator interfejsu, przy czym adres warstwy łącza jest na przykład adresem warstwy MAC stosowanym przez sieć dostępową. [0003] Dokument WO02/ opisuje to, jak węzeł może wygenerować kryptograficzną wersję identyfikatora interfejsu, stosując jednostronną funkcję kodującą, taką jak funkcja haszująca, i dostarczyć ją innemu użytkownikowi równorzędnemu, który następnie może zweryfikować, czy węzeł jest właścicielem części adresu IP odpowiadającej za identyfikator interfejsu. Tego typu adresy generowane kryptograficznie znane są jako CGA. Adresy CGA zapewniają pewien poziom bezpieczeństwa po to, by pomóc zapobiegać, na przykład, atakowi polegającemu na odmowie usługi, w którym atakujący twierdzi, iż jest właścicielem adresu IP, który węzeł chce zastosować. Podejście typu CGA zostało ustandaryzowane w IETF RFC3972 i stosowane jest między innymi w protokole Bezpiecznego Wykrywania Sąsiada (SeND, ang. Secure Neighbor Discovery) ustandaryzowanym w IETF RFC [0004] Według RFC 3972, CGA generowane są następująco: Hash1 = hash(modyfikator prefiks klucz publiczny rozszerzenie) Adres IPv6 = prefiks Hash 1 (przy pewnych bitach ustawionych zgodnie z poziomem bezpieczeństwa i innymi wymogami). [0005] Tam gdzie jest "prefiks" to jest to sieciowy prefiks trasujący, "hash" to kryptograficzna funkcja haszująca (SHA-1), "klucz publiczny" to klucz publiczny węzła generującego adres, a "rozszerzenia" to obecnie niestosowane pole do przenoszenia informacji ustandaryzowanej. "Modyfikator" to wartość 128-bitowa wygenerowana przez węzeł po to, aby zarówno zwiększyć bezpieczeństwo, jak i wzmocnić przypadkowość. Bardziej szczegółowo, w zależności od wymaganego poziomu bezpieczeństwa, wybrana jest taka wartość modyfikatora, w wyniku której powstaje pewne łączenie danych (w tym modyfikatora i

3 2 klucza publicznego) haszująca do wartości ("Hash2") mającej określoną ilość "0" w bitach położonych skrajnie po lewej. [0006] Dokument WO2007/ ujawnia sposób delegowania z węzła mobilnego do routera mobilnego tak, aby wysyłać w jego imieniu aktualizacje lokalizacji za pomocą certyfikatu delegacji. [0007] Aby udowodnić własność CGA, węzeł musi być w stanie dostarczyć certyfikat zawierający część adresu CGA odpowiedzialną za identyfikator interfejsu (IID), modyfikator, klucz publiczny i jakiekolwiek rozszerzenie zorganizowane jako struktura danych CGA. Certyfikat zawiera podpis elektroniczny (SHA-1) pobrany z komunikatu dla wysłania (łączonym z 128-bitowym znacznikiem typu CGA) z zastosowaniem prywatnego klucza węzła. Równorzędny węzeł przyjmujący certyfikat najpierw oblicza Hash2 i weryfikuje, czy ma on właściwą ilość "0" w bitach położonych skrajnie po lewej. Jeśli tak jest, oblicza Hash1 i porównuje go z IID, tym samym weryfikując, czy IID należy do pary klucz publicznyprywatny, a następnie weryfikuje podpis odwracając proces podpisywania z zastosowaniem zweryfikowanego klucza publicznego. Ten drugi etap udowadnia, że nadawca rzeczywiście ma klucz publiczny a nie jedynie przywłaszczył go sobie, oraz udowadnia, że komunikat pochodził od deklarującego się jako nadawca. [0008] Host mający CGA (węzeł "delegujący") może delegować odpowiedzialność za ten adres do pewnego dalszego węzła (węzła "delegowanego"), na przykład, aby pozwolić węzłowi delegowanemu zażądać, by ruch przekierowany był do węzła delegującego. Osiągnięte jest to przez dostarczanie węzłowi delegowanemu certyfikatu zawierającego CGA, strukturę danych CGA, tożsamość węzła delegowanego oraz podpis utworzony z zastosowaniem klucza prywatnego węzła delegującego. Aby udowodnić stronie trzeciej, że pozwala jej się na zastosowanie zadeklarowanego CGA, węzeł delegowany dostarcza stronie trzeciej certyfikat, który może zweryfikować, czy IID należy do klucza publicznego, i czy certyfikat podpisany jest, w sposób ważny, przez właściciela klucza publicznego. W przypadku, gdy tożsamością jest klucz publiczny węzła delegowanego, węzeł delegowany może podpisać jakiekolwiek żądanie powiązane z CGA swoim kluczem prywatnym, co za tym idzie pozwalając stronie trzeciej udowodnić, iż węzeł delegowany ma zadeklarowaną tożsamość. [0009] Problem z takim podejściem do delegacji polega na tym, że certyfikat dostarczony przez węzeł delegujący do węzła delegowanego przywiązany jest do pojedynczego CGA. W wypadku, w którym węzeł delegujący zmienia swój adres IPv6, np. ze względu na mobilność i zastosowanie przez niego nowego sieciowego prefiksu trasującego, nowy certyfikat musi być dostarczony do węzła delegowanego. Podsumowanie [0010] Według pierwszego przedmiotu wynalazku, zapewniony jest sposób weryfikacji żądania dokonanego w stosunku do adresu IPv6, zawierającego sieciowy prefiks trasujący oraz kryptograficznie generowany identyfikator interfejsu. Żądanie zawiera certyfikat delegacji, zawierający co najmniej klucz publiczny hosta, jeden lub więcej dalszych

4 3 parametrów lub wzór, lub wzory, dla generowania jednego lub większej ilości dalszych parametrów, specyfikację zakresu lub zestawu sieciowych prefiksów trasujących IPv6, tożsamość hosta delegowanego oraz podpis cyfrowy pobrany co najmniej w kwestii tożsamości, a specyfikacja zakresu lub zestaw sieciowych prefiksów trasujących IPv6 stosuje klucz prywatny powiązany z kluczem publicznym. Sposób obejmuje weryfikowanie, czy sieciowy prefiks trasujący adresu IPv6 zawarty jest w specyfikacji, weryfikowanie, czy klucz publiczny i dalsze parametry (dalszy parametr) mogą być stosowane do generowania kryptograficznie generowanego identyfikatora interfejsu, oraz weryfikowanie podpisu stosującego klucz publiczny. [0011] Przykłady wykonania wynalazku pozwalają hostowi delegować odpowiedzialność za adresy IPv6 do dalszego hosta, nawet gdy adresy te nie zostały jeszcze wygenerowane. Gdy adres zastosowany jest w użyciu, następujące sygnały pomiędzy hostami są zredukowane lub nawet wyeliminowane. [0012] Według korzystnego przykładu wykonania, jeden, lub więcej, dalszych parametrów zawiera modyfikator, który wprowadza pewien stopień przypadkowości do procesu generowania adresu. Bardziej korzystnie, certyfikat zawiera wzór do generowania modyfikatora tak, że modyfikator zmienia się za każdym razem, gdy wygenerowany jest identyfikator interfejsu. Jeden lub więcej dalszych parametrów może także zawierać jedno lub więcej rozszerzeń. [0013] Zakres lub zestaw sieciowych prefiksów trasujących IPv6 może być podzestawem wszystkich dostępnych prefiksów trasujących. Alternatywnie, specyfikacja zakresu lub zestawu sieciowych prefiksów trasujących IPv6 może określać wszystkie dostępne prefiksy trasujące, tj. certyfikat autoryzuje węzeł delegowany do działania w stosunku do wszystkich prefiksów trasujących. [0014] Etap weryfikowania, czy klucz publiczny i dalsze parametry (dalszy parametr) mogą być zastosowane do generowania kryptograficznie generowanego identyfikatora interfejsu, może obejmować zastosowanie sieciowego prefiksu trasującego adresu IPv6 w procesie weryfikacji oraz zastosowanie algorytmu haszującego. Algorytm haszujący może być także zastosowany do zweryfikowania podpisu z zastosowaniem klucza publicznego. [0015] Według drugiego przedmiotu wynalazku, zapewniony jest host IPv6 zawierający pierwszy procesor skonfigurowany do generowania certyfikatu delegacji, przy czym certyfikat zawiera co najmniej klucz publiczny hosta, jeden lub więcej dalszych parametrów lub wzór lub wzory dla generowania jednego lub większej ilości dalszych parametrów, specyfikację zakresu lub zestawu sieciowych prefiksów trasujących IPv6, tożsamość hosta delegowanego oraz podpis cyfrowy pobrany co najmniej w kwestii tożsamości i specyfikacji zakresu lub zestawu sieciowych prefiksów trasujących IPv6 stosujących klucz prywatny powiązany z kluczem publicznym. Klucz publiczny i jeden lub więcej dalszych parametrów mogą być stosowane do obliczenia części adresu generowanego kryptograficznie Identyfikatora Interfejsu. Host dalej zawiera dane wyjściowe dla dostarczenia certyfikatu do hosta delegowanego, a drugi procesor jest skonfigurowany do generowania identyfikatora

5 4 interfejsu, stosujący co najmniej klucz publiczny i jeden lub więcej dalszych parametrów, i do łączenia Identyfikatora Interfejsu z sieciowym prefiksem trasującym zawartym w zakresie lub zestawie prefiksów, aby wygenerować adres generowany kryptograficznie. Dane wyjściowe mogą być dalej skonfigurowane do wysyłania do hosta delegowanego powiadomienia, gdy adres generowany kryptograficznie został wygenerowany, przy czym powiadomienie zawiera adres generowany kryptograficznie. [0016] Według trzeciego przedmiotu wynalazku, zapewniony jest host IPv6 zawierający pierwsze dane wejściowe dla przyjmowania od hosta równorzędnego IPv6 certyfikatu delegacji, przy czym certyfikat zawiera co najmniej klucz publiczny hosta równorzędnego, jeden lub więcej dalszych parametrów lub wzór lub wzory dla generowania jednego lub większej ilości dalszych parametrów, specyfikację zakresu lub zestawu sieciowych prefiksów trasujących IPv6, tożsamość hosta przyjmującego oraz podpis cyfrowy pobrany co najmniej w kwestii tożsamości i specyfikacji zakresu lub zestawu sieciowych prefiksów trasujących IPv6 stosujących klucz prywatny powiązany z kluczem publicznym. Host dodatkowo zawiera drugie dane wejściowe dla przyjmowania od hosta równorzędnego powiadomienia, że host równorzędny stosuje do certyfikatu mapowanie adresu generowanego kryptograficznie, i dane wyjściowe dla wysyłania żądania w stosunku do adresu generowanego kryptograficznie do węzła strony trzeciej i dla umieszczania certyfikatu w żądaniu. [0017] Według czwartego przedmiotu wynalazku, zapewniony jest nośnik pamięci komputerowej, na którym przechowywany jest certyfikat delegacji, zawierający co najmniej klucz publiczny hosta, jeden lub więcej dalszych parametrów lub wzór lub wzory dla generowania jednego lub większej ilości dalszych parametrów, specyfikację zakresu lub zestawu sieciowych prefiksów trasujących IPv6, tożsamość hosta delegowanego oraz podpis cyfrowy pobrany co najmniej w kwestii tożsamości i specyfikacji zakresu lub zestawu sieciowych prefiksów trasujących IPv6 stosujących klucz prywatny powiązany z kluczem publicznym. Krótki opis rysunków [0018] Fig. 1 schematycznie przedstawia przykładową strukturę nowego certyfikatu delegacji CGA; Fig. 2 schematycznie przedstawia elementy systemu komunikacji związanego z generowaniem i zastosowaniem certyfikatu delegacji CGA; i Fig. 3 to schemat blokowy przedstawiający proces stwierdzający ważność żądania wysłanego w stosunku do adresu IPv6. Opis szczegółowy [0019] Aby pozwolić węzłowi lub hostowi IPv6 (węzeł "delegujący") na umożliwienie delegowania odpowiedzialności za póki co nieokreślony adres IP generowany kryptograficznie (CGA, ang. Cryptographically Generated IP addresses) do pewnego dalszego węzła (węzeł "delegowany"), zaproponowany jest tu mechanizm, który obejmuje

6 5 generowanie w węźle delegującym certyfikatu, który zawiera informację wymaganą do wygenerowania tych nieokreślonych CGA. Certyfikat zawiera podpis utworzony z kluczem prywatnym węzła delegującego, i dostarczony jest do węzła delegowanego. Prezentując certyfikat stronie trzeciej, węzeł delegowany następnie może udowodnić swoją delegowaną odpowiedzialność za deklarowany CGA. [0020] Rozważając mechanizm delegacji bardziej szczegółowo, węzeł chcący delegować odpowiedzialność za póki co nieokreślone CGA, generuje certyfikat mający strukturę danych przedstawioną na Fig. 1. Certyfikat zawiera nową strukturę danych CGA i tożsamość węzła delegowanego. Tożsamość ta może być kluczem publicznym należącym do węzła delegowanego. Nowa struktura danych zawiera modyfikator, klucz publiczny węzła delegującego, jakiekolwiek rozszerzenia i zakres, zestaw lub inną definicję dopuszczalnych sieciowych prefiksów trasujących. Dopuszczalne prefiksy mogą być zdefiniowane algorytmicznie, np. stosując filtr Blooma, lub ze swojej natury struktura danych może zawierać wskazanie, że wszystkie prefiksy są dopuszczalne. Zamiast definiować wartość pojedynczego modyfikatora, struktura danych może zidentyfikować środek do generowania modyfikatora, np. algorytm lub odwołanie do algorytmu, gdzie modyfikator wygenerowany może być deterministycznie ze znanych wartości danych wejściowych, np. sieciowego prefiksu trasującego i aktualnego czasu. Jeśli zastosowany będzie czas, wówczas CGA będą uzależnione od czasu. Należy zastosować odpowiednio duże przedziały, np. interwały jednogodzinne. Podobnie, jakiekolwiek stosowane rozszerzenia mogą być zdefiniowane algorytmicznie. Zakładając, że poziom bezpieczeństwa wymagany dla CGA ustalony jest na swej najniższej wartości (tj. sec = 0 według RFC3972), algorytm dla generowania modyfikatora może być łatwo zdefiniowany. Bardziej złożone czynniki zachodzą, gdy sec > 0. [0021] Węzeł delegujący zawiera w certyfikacie podpis utworzony ze swoim kluczem prywatnym i dostarcza certyfikat do węzła delegowanego. Może być to wykonane przez jakikolwiek właściwy mechanizm, np. przez zastosowanie mechanizmu opisanego w Sekcji 6 IETF RFC3972. Znawcy dobrze widzą, że podpis uzależniony jest od struktury danych CGA. W pewnym późniejszym punkcie w czasie, węzeł delegujący wygeneruje CGA dla siebie. Aby to zrobić, w razie konieczności, wygeneruje modyfikator (i jakiekolwiek rozszerzenia) stosując wskazany algorytm (wskazane algorytmy) i wybierze, lub wygeneruje, właściwy sieciowy prefiks trasujący oraz wypełni procedurę wyszczególnioną w Sekcji 4 RFC [0022] W tym czasie węzeł delegujący powiadomi węzeł delegowany o swoim nowym adresie IPv6. Następnie, gdy węzeł delegowany zachce zażądać od węzła strony trzeciej (węzeł "weryfikujący") działania w stosunku do nowego CGA, węzeł delegowany powinien dołączyć do żądania certyfikat. Aby zweryfikować żądanie, węzeł weryfikujący wykonuje następujące działania: Wyodrębnia sieciowy prefiks trasujący z CGA i weryfikuje, czy wypada on w jakimkolwiek zestawie lub zakresie zdefiniowanym w strukturze danych CGA certyfikatu.

7 6 Następnie wyodrębnia lub generuje modyfikator ze struktury danych, wraz z wyodrębnieniem klucza publicznego węzła delegującego i jakiegokolwiek rozszerzenia (rozszerzeń). Ponieważ rzeczywista wartość ilości konfliktów zastosowana podczas generowania CGA nie będzie znana w czasie weryfikacji, węzeł weryfikujący musi kolejno ustawiać ilość konfliktów na 1, 1, i 2, a następnie przeprowadzić algorytm z Sekcji 5 IETF RFC3972, aby zweryfikować, czy CGA należy do klucza publicznego węzła delegującego. W wypadku, gdy CGA zweryfikowany jest prawidłowo, węzeł weryfikujący następnie próbuje zweryfikować, czy podpis zawarty w certyfikacie został wygenerowany z zastosowaniem klucza prywatnego odpowiadającego kluczowi publicznemu węzła delegującego. W wypadku, gdy podpis zweryfikowany jest prawidłowo, węzeł weryfikujący może spróbować zweryfikować, czy nadawca żądania, tj. węzeł delegowany, jest właścicielem tożsamości zawartej w certyfikacie. Tam, gdzie ta tożsamość jest dalszym kluczem publicznym, może to objąć weryfikację dalszego podpisu zawartego w żądaniu wygenerowanym z zastosowaniem klucza prywatnego węzła delegującego. [0023] Zakładając, że poziom bezpieczeństwa ustawiony jest na niski, tj. sec = 0, nie ma potrzeby, by węzeł weryfikujący obliczał Hash2. Jednak, jeśli sec > 0, musi zostać przeprowadzona procedura opisana w etapach 6 i 7, Sekcja 5 RFC3972. [0024] Fig. 2 schematycznie przedstawia węzeł delegujący 1 zawierający pierwszy procesor 2 skonfigurowany do generowania certyfikatu delegacji, jak opisano powyżej. Drugi procesor 3 skonfigurowany do generowania CGA stosując parametry zawarte w certyfikacie. Zarówno certyfikat, jak i powiadomienie o wygenerowaniu CGA przesłane są przez dane wyjściowe 4 do węzła delegowanego 5. Ten węzeł 5 przyjmuje certyfikat przy pierwszych danych wejściowych 6 i przyjmuje powiadomienia przy drugich danych wejściowych 7. Procesor 9 odpowiedzialny jest za generowanie żądań w stosunku do delegowanego CGA i za przesyłanie ich do węzła weryfikującego 10 wraz z certyfikatem. Żądania przyjmowane są przez węzeł weryfikujący 10 przy danych wejściowych 11. Wobec certyfikatu przeprowadzany jest trzyetapowy proces weryfikacji, mianowicie: weryfikowanie, czy wewnątrz zakresu 12 jest umiejscowiony prefiks trasujący, weryfikowanie, czy IID pasuje do klucza publicznego 13 i weryfikowanie podpisu 14. [0025] Fig. 3 to diagram blokowy przedstawiający proces weryfikacji certyfikatu. Przedstawione etapy obejmują przyjęcie żądania (w stosunku do CGA) w węźle weryfikującym od węzła delegowanego (etap 100), wyodrębnienie prefiksu trasującego od CGA (etap 101), weryfikowanie, czy prefiks trasujący jest umieszczony w zakresie określonym w certyfikacie (etap 102), weryfikowanie IID z CGA (etap 103), i weryfikowanie podpisu (etap 104). Jeśli na jakimkolwiek etapie weryfikacja zawiedzie, żądanie jest odrzucone (etap 106). Jeśli wszystkie etapy weryfikacji są udane, żądanie jest zaakceptowane i przetworzone (etap 105).

8 7 [0026] Znawcom w dziedzinie wiadome jest, że w stosunku do powyżej opisanych przykładów wykonania dokonane mogą być różne modyfikacje bez odchodzenia od zakresu wynalazku. Sporządziła i zweryfikowała Anna Stenzel Rzecznik patentowy

9 8 Zastrzeżenia patentowe 1. Sposób weryfikacji żądania dokonanego w stosunku do adresu IPv6 zawierającego sieciowy prefiks trasujący i kryptograficznie generowany identyfikator interfejsu, przy czym żądanie zawiera certyfikat delegacji, zawierający co najmniej klucz publiczny hosta delegującego, jeden lub więcej dalszych parametrów lub wzór lub wzory dla generowania jednego lub większej ilości dalszych parametrów, specyfikację zakresu lub zestawu sieciowych prefiksów trasujących IPv6, tożsamość hosta delegowanego i podpis cyfrowy pobrany co najmniej w kwestii tożsamości i specyfikacji zakresu lub zestawu sieciowych prefiksów trasujących IPv6 stosujących klucz prywatny powiązany z kluczem publicznym, przy czym sposób obejmuje etapy: weryfikowania, czy sieciowy prefiks trasujący adresu IPv6 zawarty jest w zakresie lub zestawie; weryfikowania, czy klucz publiczny i dalszy parametr lub parametry mogą być stosowane do generowania kryptograficznie generowanego identyfikatora interfejsu; i weryfikowania podpisu z zastosowaniem klucza publicznego. 2. Sposób według zastrz. 1, w którym jeden lub więcej dalszych parametrów obejmuje modyfikator. 3. Sposób według zastrz. 2, w którym certyfikat zawiera wzór dla generowania modyfikatora tak, że modyfikator zmienia się za każdym razem, gdy generowany jest identyfikator interfejsu. 4. Sposób według któregokolwiek z poprzednich zastrzeżeń, w którym jeden lub więcej dalszych parametrów obejmuje jedno lub więcej rozszerzeń. 5. Sposób według któregokolwiek z poprzednich zastrzeżeń, w którym zakres lub zestaw sieciowych prefiksów trasujących IPv6 jest podzestawem wszystkich dostępnych prefiksów trasujących. 6. Sposób według któregokolwiek z poprzednich zastrzeżeń, w którym specyfikacja zakresu lub zestawu sieciowych prefiksów trasujących IPv6 określa wszystkie dostępne prefiksy trasujące. 7. Sposób według któregokolwiek z poprzednich zastrzeżeń, w którym etap weryfikowania, czy klucz publiczny i dalszy parametr lub parametry mogą być stosowane do generowania kryptograficznie generowanego identyfikatora interfejsu, obejmuje zastosowanie, w procesie weryfikacji, sieciowego prefiksu trasującego adresu IPv6. 8. Sposób według któregokolwiek z poprzednich zastrzeżeń, w którym zarówno etapy weryfikowania, czy klucz publiczny i dalszy parametr lub parametry mogą być stosowane do generowania kryptograficznie generowanego identyfikatora interfejsu, jak

10 9 i weryfikowania podpisu z zastosowaniem klucza publicznego, stosują algorytm haszujący. 9. Host IPv6 zawierający: pierwszy procesor skonfigurowany do generowania certyfikatu delegacji, przy czym certyfikat zawiera co najmniej klucz publiczny hosta, jeden lub więcej dalszych parametrów lub wzór lub wzory dla generowania jednego lub większej ilości dalszych parametrów, specyfikację zakresu lub zestawu sieciowych prefiksów trasujących IPv6, tożsamość hosta delegowanego i podpis cyfrowy pobrany co najmniej w kwestii tożsamości i specyfikacji zakresu, lub zestawu sieciowych prefiksów trasujących IPv6, stosujących klucz prywatny powiązany z kluczem publicznym, przy czym klucz publiczny i jeden lub więcej dalszych parametrów mogą być stosowane do obliczenia części identyfikatora interfejsu adresu generowanego kryptograficznie; dane wyjściowe dla dostarczenia certyfikatu do hosta delegowanego; i drugi procesor skonfigurowany do generowania identyfikatora interfejsu, stosujący co najmniej klucz publiczny i jeden lub więcej dalszych parametrów, i do łączenia identyfikatora interfejsu z sieciowym prefiksem trasującym zawartym w zakresie lub zestawie prefiksów, dla generowania adresu generowanego kryptograficznie. 10. Host IPv6 według zastrz. 9, w którym dane wyjściowe są dalej do wysyłania powiadomienia do hosta delegowanego, gdy adres generowany kryptograficznie został wygenerowany, przy czym powiadomienie zawiera adres generowany kryptograficznie. 11. Host IPv6 zawierający: pierwsze dane wejściowe dla przyjmowania od równorzędnego hosta IPv6 certyfikatu delegacji, przy czym certyfikat zawiera co najmniej klucz publiczny hosta równorzędnego, jeden lub więcej dalszych parametrów lub wzór lub wzory dla generowania jednego lub większej ilości dalszych parametrów, specyfikację zakresu lub zestawu sieciowych prefiksów trasujących IPv6, tożsamość hosta przyjmującego oraz podpis cyfrowy pobrany co najmniej w kwestii tożsamości i specyfikacji zakresu lub zestawu sieciowych prefiksów trasujących IPv6 stosujących klucz prywatny powiązany z kluczem publicznym; drugie dane wejściowe dla przyjmowania z hosta równorzędnego powiadomienia, że host równorzędny stosuje do certyfikatu mapowanie adresu generowanego kryptograficznie; i dane wyjściowe dla wysyłania do węzła strony trzeciej żądania w stosunku do adresu generowanego kryptograficznie i dla umieszczania certyfikatu w żądaniu. 12. Nośnik pamięci komputerowej, na którym przechowywany jest certyfikat delegacji, przy czym certyfikat delegacji zawiera co najmniej klucz publiczny hosta, jeden lub

11 10 więcej dalszych parametrów lub wzór lub wzory dla generowania jednego lub większej ilości dalszych parametrów, specyfikację zakresu lub zestawu sieciowych prefiksów trasujących IPv6, tożsamość hosta delegowanego i podpis cyfrowy pobrany co najmniej w kwestii tożsamości i specyfikacji zakresu lub zestawu sieciowych prefiksów trasujących IPv6 stosujących klucz prywatny powiązany z kluczem publicznym. Sporządziła i zweryfikowała Anna Stenzel Rzecznik patentowy

12 11

13 12