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

Transkrypt

1 PL/EP T3 RZECZPOSPOLITA POLSKA (12) TŁUMACZENIE PATENTU EUROPEJSKIEGO (19) PL (11) PL/EP (13) T3 (96) Data i numer zgłoszenia patentu europejskiego: (1) Int. Cl. H04L9/08 (06.01) (97) O udzieleniu patentu europejskiego ogłoszono: Urząd Patentowy Rzeczypospolitej Polskiej Europejski Biuletyn Patentowy 09/26 EP B1 (4) Tytuł wynalazku: Sposób kodowania i przesyłu danych pomiędzy nadawcą a odbiorcą przy wykorzystaniu sieci () Pierwszeństwo: GB (43) Zgłoszenie ogłoszono: Europejski Biuletyn Patentowy 07/07 (4) O złożeniu tłumaczenia patentu ogłoszono: Wiadomości Urzędu Patentowego 12/09 (73) Uprawniony z patentu: Gcrypt Limited, London, GB (72) Twórca (y) wynalazku: ALCULUMBRE Michael, London, GB (74) Pełnomocnik: LDS Łazewski Depo i Wspólnicy rzecz. pat. Łazewski Marek Warszawa Mysłowicka 1 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 1 EP Z-6374/09 Sposób kodowania i przesyłu danych pomiędzy nadawcą a odbiorcą przy wykorzystaniu sieci Niniejszy wynalazek stanowi sposób kodowania i przesyłu danych pomiędzy nadawcą a odbiorcą przy wykorzystaniu do tego celu sieci, uzyskując w ten sposób bezpieczną transmisję danych. W obecnych czasach wzrasta ilość poufnych danych, które przesyłane są pomiędzy nadawcą a odbiorcą drogą elektroniczną. W związku z tym, jest to bardzo istotne, aby takie dane nie zostały przechwycone i odczytane przez osoby do tego nieupoważnione. Dane muszą być przesyłane w sposób bezpieczny, aby ich odczytanie mogło nastąpić jedynie przez nadawcę i odbiorcę. Możliwe jest ustanowienie bezpiecznego połączenia pomiędzy nadawcą A, a odbiorcą B, zanim nastąpi przesył danych. Jednakże, w sytuacji, kiedy powiedzmy osób z danego biura zechce nawiązać dwukierunkowe połączenie i przesłać poufne dane pomiędzy sobą oraz do kolejnych osób znajdujących się w innym biurze, wówczas ustanowienie tak dużej ilości bezpiecznych połączeń wymaga większych nakładów sprzętowych i programowych, co jest niewątpliwą wadą. Ponadto, wymagane są w takiej sytuacji także zwiększone nakłady sprzętowe oraz czasowe, konieczne do utrzymania bezpiecznych połączeń i powiązanych z nimi systemów zarządzania hasłami. Taka sytuacja ma miejsce zwłaszcza w przypadku, gdy osoby w poszczególnych biurach połączone są ze sobą przy pomocy sieci Intranet lub Ethernet i komunikacja pomiędzy biurami odbywa się przy wykorzystaniu sieci Internet. Rozwiązanie takie wymaga także wyposażenia zarówno nadawcy jak i odbiorcy w zaawansowane oprogramowanie służące do kodowania i odkodowania danych, co oznacza wymóg posiadania dodatkowych systemów sprzętowych i programowych, a także wiąże się z dodatkowymi kosztami serwisowymi. Inny scenariusz zakłada, że jeden nadawca zechce przesłać różne dane wielu niejawnym odbiorcom. Mamy w tym przypadku do czynienia z takimi samymi wadami, jak w opisywanej poprzednio sytuacji, a w szczególności nakładany jest na nadawcę obowiązek zapewnienia zaawansowanego systemu bezpieczeństwa, aby chronić hasła przed dostępem osób trzecich. Ponadto, funkcjonowanie opisywanego systemu wymaga zastosowania

3 2 1 2 dodatkowych systemów sprzętowych i programowych, które będą odpowiedzialne za poprawne działanie systemu bezpiecznego przesyłania danych. Ogólnie dostępne obecnie urządzenia mobilne, takie jak palmtopy czy telefony komórkowe z dostępem do Internetu i wbudowanym klientem , mają ograniczoną pamięć oraz możliwości obliczeniowe, i dlatego też względy techniczne decydują o tym, że funkcja ustanawiania dwukierunkowego bezpiecznego połączenia, wymagającego wysokiego poziomu kodowania i odkodowania, nie jest często udostępniana. Mimo, że do obniżenia poziomu wymaganych zasobów technicznych po stronie zarówno serwera jak i odbiorcy możliwe jest wykorzystanie cyfrowych certyfikatów, wiąże się to z dodatkowymi kosztami ponoszonymi przez odbiorcę, które często są dla niego nieuzasadnione, nawet jeśli są niewielkie. Alternatywą jest rozwiązanie zakładające, że to nadawca zakoduje dane a następnie prześle je przy użyciu sieci. Także w tym przypadku, jednakże, odbiorca jest zmuszony do uruchomienia zasobów sprzętowych oraz wykorzystującego zasoby pamięciowe odpowiedniego oprogramowania w celu przeprowadzenia procesu odkodowania zakodowanych danych. Ponadto, z uwagi na fakt, że urządzenie odbiorcy może posiadać relatywnie niskie zasoby sprzętowe, takie rozwiązanie również nie jest rozpowszechnione, gdyż wymaga ono stosowania kosztownych zasobów umożliwiających bezpieczny przesył danych. Wykorzystanie zaawansowanych sposobów kodowania i odkodowania danych wiąże się z koniecznością instalacji odpowiedniego oprogramowania na urządzeniach nadawcy i odbiorcy. Jest to zarówno mało wygodne jak i kosztowne. Co więcej, procedura instalacyjna może być skomplikowana i czasochłonna, a oprogramowanie może powodować konflikty z zainstalowanymi uprzednio programami. Dodatkowe oprogramowanie wymaga także zwiększonej mocy obliczeniowej, która może nie być dostępna w danym urządzeniu, a także zwiększonych nakładów pamięciowych. Taka sytuacja ma często miejsce w przypadku wspomnianych urządzeń mobilnych. Z opisanych powyżej przykładów jasno wynika, że znane dotychczas sposoby i systemy bezpiecznego przesyłania danych wymagają zaawansowanej organizacji, a także znacznych zasobów obliczeniowych i pamięciowych. Jest to szczególnie niekomfortowe w sytuacji, gdy nadawca i/lub odbiorca dysponują ograniczoną ilością wspomnianych zasobów technicznych. Istnieje, zatem, zapotrzebowanie na sposób i system bezpiecznego przesyłania danych, który ograniczałby wykorzystanie zasobów technicznych wykorzystywanych przez urządzenie nadawcy i/lub odbiorcy. W przypadku wykorzystywania publicznych/prywatnych kluczy

4 3 1 2 kodowania, nadawca musi być pewny, że klucz publiczny, należący do odbiorcy, nie został wymieniony na inny klucz publiczny przez nieuprawnioną do tego osobę trzecią. Cechy znanych metod kodowania i przesyłu danych pomiędzy nadawcą a odbiorcą przy wykorzystaniu sieci zostały zdefiniowane w części wstępnej zastrzeżenia 1 i pochodzą ze zgłoszenia US 03/ , w którym opisany został bezpieczny system przesyłania danych pomiędzy urządzeniem klienckim a odbiorcą przy pomocy bezpiecznego serwera dystrybucyjnego. Urządzenie klienckie koduje dane przy użyciu poufnego klucza a następnie koduje poufny klucz przy pomocy publicznego klucza powiązanego z bezpiecznym serwerem dystrybucyjnym. Zakodowana informacja, zakodowany poufny klucz, oraz dane odbiorcy wysyłane są do bezpiecznego serwera dystrybucyjnego, którego zadaniem jest odkodowanie poufnego klucza. Następnie bezpieczny serwer dystrybucyjny koduje odkodowany poufny klucz przy pomocy publicznego klucza właściwego odbiorcy tworząc dla niego w ten sposób unikalny bezpieczny poufny klucz. Klucz ten, wraz z zakodowaną informacją, jest wysyłany w takiej formie do odbiorcy. Cechy charakteryzujące niniejszy wynalazek zostały wyszczególnione w części opisowej zastrzeżenia 1. W preferowanym wariancie sposób zakłada ustanowienie połączenia pomiędzy nadawcą a serwerem oraz wysłanie na serwer rzeczonego identyfikatora odbiorcy. Następnie sposób zakłada ustanowienie połączenia pomiędzy nadawcą a serwerem z zastrzeżeniem, że będzie to połączenie bezpieczne. W kolejnym przypadku sposób zakłada ustanowienie połączenia pomiędzy nadawcą a serwerem, przy czym serwer będzie wymagał od nadawcy wprowadzenia hasła. Kolejny przypadek przedstawia sposób zakładającą ustanowienie połączenia pomiędzy odbiorcą a serwerem i wysyłanie rzeczonego identyfikatora odbiorcy na serwer. W jednym przypadku sposób zakłada ustanowienie połączenia pomiędzy odbiorcą a serwerem z zastrzeżeniem, że będzie to połączenie bezpieczne. W szczególnym wypadku, sposób zakłada ustanowienie połączenia pomiędzy odbiorcą a serwerem, przy czym serwer będzie wymagał od odbiorcy wprowadzenia hasła. W preferowanym wariancie ustanowienie połączenia dla przypisanego klucza kodowania odbywa się u nadawcy, po czym klucz kodowania zostaje przesłany na serwer. W innym wariancie, kodowanie danych przy użyciu przypisanego klucza kodowania odbywa się u nadawcy. W szczególnym przypadku nadawca otrzymuje z serwera zakodowany przypisany klucz kodowania, po czym przesyła zakodowane dane oraz zakodowany przypisany klucz kodowania do odbiorcy przy pomocy sieci.

5 4 W innym przypadku odbiorca otrzymuje z serwera odkodowany przypisany klucz kodowania i u odbiorcy ma miejsce odkodowanie zakodowanych danych przy pomocy otrzymanego odkodowany przypisany klucz kodowania. Inny przypadek zakłada utworzenie przypisanego klucza kodowania na serwerze. W szczególnym przypadku kodowanie danych przy użyciu przypisanego klucza kodowania odbywa się na serwerze. Kolejny przypadek zakłada przesłanie przez serwer zakodowanych danych oraz zakodowanego przypisanego klucza kodowania do odbiorcy przy pomocy sieci. W kolejnym przypadku odkodowanie zakodowanych danych przy użyciu odkodowanego przypisanego klucza kodowania odbywa się na serwerze i serwer jest odpowiedzialny za przesłanie odkodowanych danych do odbiorcy W preferowanym wariancie, sposób ta zakłada: - utworzenie wartości kodu uwierzytelniania wiadomości (MAC) dla danych zanim zostaną zakodowane; - przesłanie wartości MAC razem z zakodowanymi danymi i zakodowanym przypisanym kluczem kodowania; oraz - utworzenie wartości MAC dla danych po odkodowaniu i uwierzytelnienie na podstawie przesłanej wartości MAC. W jednym przypadku zakodowanie przypisanego klucza kodowania wykorzystuje jedną lub więcej metod kodowania kluczy publicznych, algorytm Blowfish i poufny kod serwera. Niniejszy wynalazek oferuje sposób na wykorzystanie serwera do celów kodowania i przesyłu danych pomiędzy nadawcą a odbiorcą przy pomocy sieci; sposób ta zakłada następujące etapy: - otrzymanie od nadawcy identyfikatora odbiorcy; - dostęp do informacji o odbiorcy na podstawie otrzymanego od nadawcy identyfikatora odbiorcy oraz zakodowanie, łącznie z informacją o odbiorcy, przypisanego klucza kodowania, który będzie wykorzystany do odkodowania danych; Cechy charakterystyczne: - otrzymanie od odbiorcy zakodowanego przypisanego klucza kodowania i jego identyfikatora po przesłaniu zakodowanych danych i zakodowanego przypisanego klucza kodowania przez sieć jako potwierdzenie od odbiorcy; - dostęp do informacji o odbiorcy na podstawie otrzymanego od niego identyfikatora służącego do odkodowania zakodowanego przypisanego klucza kodowania. W jednym przypadku, sposób wykorzystania serwera zakłada utworzenie na serwerze przypisanego klucza kodowania, który zostanie przydzielony dla danego transferu.

6 1 2 3 W innym przypadku, sposób wykorzystania serwera zakłada otrzymanie od nadawcy przypisanego klucza kodowania przydzielonego dla danego transferu oraz przesłanie zakodowanego przypisanego klucza kodowania do nadawcy. W preferowanym wariancie, sposób wykorzystania serwera zakłada kodowanie danych na serwerze przy wykorzystaniu przypisanego klucza kodowania. W kolejnym preferowanym rozwiązaniu sposób wykorzystania serwera zakłada transfer zakodowanych danych wraz z zakodowanym przypisanym kluczem kodowania przez sieć, aby mogły zostać odebrane przez odbiorcę. W preferowanym wariancie sposób wykorzystania serwera zakłada transfer odkodowanego przypisanego klucza kodowania do odbiorcy. W kolejnym przypadku sposób wykorzystania serwera zakłada odkodowanie zakodowanych danych na serwerze wykorzystując do tego celu odkodowany przypisany klucz kodowania. Niniejszy wynalazek zakłada wykorzystanie komputera jako środka pośredniczącego podczas kodowania i przesyłania danych pomiędzy nadawcą i odbiorcą. Na środek pośredniczący składają się: - kod komputerowy służący do odbierania od nadawcy identyfikatora odbiorcy oraz tworzenia przypisanego klucza kodowania przydzielonego do danego transferu; - kod komputerowy służący do kodowania danych wykorzystując przypisany klucz kodowania; - kod komputerowy dający dostęp do informacji o odbiorcy na podstawie identyfikatora odbiorcy wysłanego przez nadawcę oraz służący do kodowania, wraz z informacjami o odbiorcy, rzeczonego przypisanego klucza kodowania; - kod komputerowy służący do przesyłania zakodowanych danych i zakodowanego przypisanego klucza kodowania przez sieć, aby mogły zostać odebrane przez odbiorcę. Cechy charakterystyczne: - kod komputerowy służący do odbierania od odbiorcy zakodowanego przypisanego klucza kodowania oraz identyfikatora odbiorcy, oraz do uzyskiwania dostępu do informacji o odbiorcy na podstawie identyfikatora odbiorcy wysłanego przez odbiorcę w celu odkodowania zakodowanego przypisanego klucza kodowania; oraz - kod komputerowy służący do odkodowania zakodowanych danych przy wykorzystaniu odkodowanego przypisanego klucza kodowania. Przykład niniejszego wynalazku zostanie teraz opisany wraz z odniesieniem do załączonych rysunków, z których:- Rysunek 1 przedstawia schemat systemu wykorzystującego niniejszy wynalazek kodując i przesyłając dane pomiędzy nadawcą a odbiorcą przy użyciu sieci;

7 Rysunek 2 przedstawia schemat blokowy modułów operacyjnych serwera wykorzystanego na rysunku 1; Rysunek 3 jest diagramem sekwencji działań, który przedstawia czynności wykonywane przez nadawcę oraz serwer zgodnie z założeniami niniejszego wynalazku, które są wymagane do wysłania danych na serwer przez nadawcę; Rysunek 4 jest diagramem sekwencji działań przedstawiającym czynności wykonywane przez odbiorcę oraz serwer w odpowiedzi na wiadomość otrzymaną z serwera. Nawiązując do rysunków 1 i 2, przedstawiają one system wykorzystujący jeden ze sposobów kodowania i przesyłania danych pomiędzy nadawcą a odbiorcą przy użyciu sieci. Zgodnie z rysunkami, system koduje i wysyła dane pomiędzy urządzeniem nadawcy 0 a urządzeniem odbiorcy 0. W tym przypadku urządzenie nadawcy 0 składa się z komputera 1 podłączonego do klawiatury 7, źródła danych 8 i zewnętrznego wyświetlacza. Źródło danych może zawierać czytnik dysków lub interfejs umożliwiający podłączenie do biblioteki danych; źródło danych przechowuje dane, które zostaną wysłane do odbiorcy. Komputer 1 posiada magistralę dostępu 6 z podłączeniem do mikroprocesora 2, pamięci 3, z interfejsem wyświetlacza 4, interfejsie urządzeń wprowadzania danych 9, przeglądarką 1 służącą do podłączenia do Internetu poprzez połączenie 111. Interfejs wyświetlacza 4 służy do podłączenia zewnętrznego wyświetlacza, a interfejs urządzeń wprowadzania danych 9 służy do podłączenia klawiatury 7 i źródła danych 8. Pamięć 3 służy do przechowywania identyfikatora nadawcy i hasła nadawcy, jednakże zarówno identyfikator, jak i hasło mogą zostać wprowadzone przy pomocy klawiatury 7 w odpowiedzi na komunikat wyświetlany na urządzeniu wyświetlającym. W niniejszym przykładzie urządzenie odbiorcy 0 składa się z telefonu komórkowego z dostępem do Internetu poprzez przeglądarkę internetową 2, która łączy się z Internetem połączeniem 211. Szczegóły dotyczące wykonywania połączenia są dobrze znane i opisane w literaturze, więc nie będą opisane w niniejszym dokumencie. Przeglądarka internetowa jest podłączona do magistrali dostępu 6, łączącej z mikroprocesorem 2, pamięcią 3, interfejsem wyświetlacza 4 oraz urządzeniem służącym do wprowadzania danych 9. Interfejs wyświetlacza podłączony jest do wbudowanego urządzenia wyświetlającego, a interfejs urządzeń służących do wprowadzania danych 9 podłączony jest do wbudowanej klawiatury 7. Pamięć 3 służy do przechowywania identyfikatora odbiorcy i hasła odbiorcy, jednakże zarówno identyfikator, jak i hasło mogą zostać wprowadzone przy pomocy klawiatury 7 w odpowiedzi na komunikat wyświetlany na urządzeniu wyświetlającym. Urządzenie 0

8 posiada klienta 212, który służy do wysyłania i odbierania wiadomości przez połączenie z Internetem 213. Serwer 0 także jest podłączony do Internetu poprzez połączenie 2. Rysunek 2 przedstawia szczegółowy schemat blokowy struktury serwera. Struktura serwera zostanie opisana w połączeniu z opisem działania systemu w niniejszym wynalazku. Odwołując się do rysunków 1 i 2, przed użyciem opisywanego systemu zarówno nadawca, jaki i odbiorca zostają zarejestrowani przez serwer 0, a ich dane SA przechowywane w bazie danych serwera 6. W opisywanym przypadku, przechowywane informacje składają się, co najmniej z identyfikatora i hasła nadawcy i odbiorcy. Nadawca zamierza przesłać odbiorcy dane znajdujące się w źródle danych 8. Aby nadawca mógł wykonać transfer danych, musi on znać identyfikator odbiorcy i adres internetowy serwera 0. Informacje te mogą być przechowywane w pamięci 3 urządzenia nadawcy lub mogą zostać wprowadzone ręcznie poprzez klawiaturę 7 w odpowiedzi na komunikat wyświetlany na urządzeniu wyświetlającym. Tak jak to zostało pokazane na rysunku 2, serwer 0 zawiera serwer WWW 1 podłączony do Internetu połączeniem 2. Serwer WWW podłączony jest do magistrali wejścia 3 i jest kontrolowany przez mikroprocesor 4. Kiedy nadawca łączy się z adresem internetowym serwera, ustanawiane jest bezpieczna połączenie, takie jak SSL. Szczegóły dotyczące takiego połączenia są znane wykwalifikowanym w tej dziedzinie osobom. Do momentu przeprowadzenia kontroli hasła przez moduł, mikroprocesor 4 nie udzieli nadawcy dostępu do systemu, ani dostępu do modułu bazy danych 6. Szczegóły dotyczące kontroli hasła są znane wykwalifikowanym w tej dziedzinie osobom i dlatego nie zostaną opisane w niniejszym dokumencie. Po dokonaniu kontroli hasła serwer 0 wyświetla nadawcy informację na ekranie. Wykonując polecenia na ekranie nadawca wysyła na serwer informację o identyfikatorze odbiorcy oraz dane, które mają zostać mu przesłane; dane pobierane są ze źródła danych 8. Wprowadzone dane są przetwarzane i przesyłane do modułów przedstawionych na rysunku 2 w jego górnej części. Po otrzymaniu identyfikatora nadawcy oraz danych do przesłania, mikroprocesor serwera 4 przekazuje dane do modułu generowania kodu uwierzytelniania wiadomości (MAC) 7. Jak powszechnie wiadomo, generator tworzy kod wykorzystując część lub całość danych oraz kryptograficzny algorytm skrótu. W opisywanym przypadku, znany algorytm skrótu wiadomości z funkcją haszującą wykorzystywany jest do generowania wartości skrótu (MD hash value) z danych. Wartość skrótu przekazywana jest do klienta 312 podłączonego do Internetu połączeniem 316 i zostaje przetworzona jako część wiadomości .

9 Otrzymane dane są kompresowane w module 8, zanim zostaną zakodowane w module 9 przy użyciu klucza sesji uzyskanego z modułu 3. Jak powszechnie wiadomo, klucz sesji jest generowany z losowych liczb, otrzymanych z generatora losowych liczb 311. Wygenerowany klucz sesji jest przypisany do konkretnych danych i ich transmisji, staje się on, zatem, przypisanym kluczem kodowania. Zakodowane dane są następnie przesyłane do klienta 312, aby zostały przetworzone jako część wiadomości . Klucz sesji z modułu 3 także zostaje zakodowany w module 313 przy użyciu publicznego klucza z sposobu publicznych/prywatnych kluczy kodowania, na przykład powszechnie znanego kodowania RSA. Następnie dane z modułu 313 są kodowane w module 314 przy użyciu algorytmu Blowfish, wykorzystującego hasło odbiorcy uzyskane z bazy danych 6. Hasło zostaje przyporządkowane do identyfikatora odbiorcy przesłanego z mikroprocesora na magistrali 31. Zakodowany klucz sesji przesyłany jest do klienta 312, po czym zostaje przetworzony jako część wiadomości . Klient 312 przetwarza wartość skrótu, zakodowane dane i zakodowany klucz sesji w znany sposób, tworząc w ten sposób wiadomość , która jest następnie przesyłana na odpowiedni adres odbiorcy, uzyskany z mikroprocesora znajdującego się na magistrali 31 po otrzymaniu go z bazy danych 6. Klient przypisuje w znany sposób unikalną etykietę do wiadomości i zapisuje informację o jej wysłaniu. Potwierdzenie wysłania wiadomości wysłane zostaje także do nadawcy wykorzystując serwer WWW 1 lub klienta Wiadomość wysłana przez serwer 0 może zostać odebrana w sposób standardowy poprzez klienta 212 zainstalowanego w telefonie komórkowym 0. Otrzymana wiadomość jest zaprogramowana w teki sposób, że może poinformować odbiorcę o nadchodzących danych, które mają być przez niego odebrane przy pomocy niniejszego wynalazku, lub automatycznie uruchomi przeglądarkę internetową 2 i nawiąże połączenie z serwerem 0. W obu przypadkach, pod nadzorem mikroprocesora 2, odbiorca łączy się z adresem internetowym serwera i ustanawiane zostaje bezpieczne połączenie, takie jak SSL. Szczegóły dotyczące takiego połączenia są znane wykwalifikowanym w tej dziedzinie osobom. Do momentu przeprowadzenia kontroli hasła przez moduł, mikroprocesor 4 nie udzieli nadawcy dostępu do systemu, ani dostępu do modułu bazy danych 6. Szczegóły dotyczące kontroli hasła są znane wykwalifikowanym w tej dziedzinie osobom i dlatego nie zostaną opisane w niniejszym dokumencie. Po udanej kontroli hasła, zakodowane dane, zakodowany klucz sesji i wartość skrótu, które są zakodowane w wiadomości , zostają wysłane bezpiecznym łączem na serwer 0 poprzez serwer WWW 1. Dane te są przetwarzane i przesyłane do modułów

10 przedstawionych na rysunku 2 w jego dolnej części. W przypadku, gdy wysyłanie lub odbieranie wiadomości będzie odbywać się z poziomu przeglądarki internetowej, zastosowanie klienta 213 nie jest konieczne. Po otrzymaniu danych, mikroprocesor serwera 4 przesyła zakodowany klucz sesji do modułu 3, w którym zastosowany zostaje odwrócony algorytm Blowfish w połączeniu z hasłem odbiorcy, uzyskanym z bazy danych 6 na magistrali 31 na podstawie identyfikatora odbiorcy. Dane z modułu 3 są następnie odkodowane w module 321 przy wykorzystaniu prywatnego klucza kodowania RSA, wykorzystanego do wysłania danych. Ze względu na opisane moduły, pierwotny klucz sesji modułu 3 zostaje odtworzony. Otrzymane zakodowane dane, będące w formie skompresowanej, zostają odkodowane w module 323 przy użyciu odkodowanego klucz sesji, zanim zostaną odkodowane w module 324. Tak jak to miało miejsce w przypadku modułu 7, wartość skrótu zostaje wygenerowana w module 32 z odkodowanych i zdekompresowanych danych pod nadzorem mikroprocesora 4; w celu uwierzytelnienia moduł 326 przeprowadza porównanie nowo-wygenerowanej wartości skrótu z wartością skrótu otrzymaną od odbiorcy, aby upewnić się, że są one tożsame. Zakładając, że wartość skrótu została uwierzytelniona w module 326, odkodowane dane z modułu 324 zostają odesłane do odbiorcy bezpiecznym łączem. Rysunek 3 jest diagramem sekwencji działań przedstawiającym proces przesyłania danych od nadawcy do serwera; przedstawione zostało działania niniejszego wynalazku. Początkowo nadawca zamierza wysłać dane konkretnemu odbiorcy znając jego identyfikator. Na etapie S1A nadawca kontaktuje się z serwerem w celu ustanowienia bezpiecznego połączenia, na przykład SSL. Ustanowienie takiego połączenia wymaga wykorzystania pewnych protokołów połączenia, przeprowadzenia wspomnianej wcześniej kontroli hasła na przykład w formie strony internetowej, wyświetlanej na urządzeniu wyświetlającym, wprowadzenia danych logowania na stronie internetowej, itd. Jak to zostało wspomniane już wcześniej, procedury ustanawiania połączenia oraz kontroli hasła są dobrze znane i nie zostaną tutaj opisane. Serwer w odpowiedzi na kontakt ze strony nadawcy także próbuje nawiązać połączenie w kroku S1B wykorzystując pewne protokoły połączenia i przeprowadzając kontrolę hasła. W kroku S2B serwer sprawdzi, czy ustanowione zostało połączenie, czyli czy wszystkie protokoły połączenia są obsługiwane i czy wszystkie hasła zostały poprawnie wprowadzone. Jeśli połączenie nie zostało ustanowione lub kontrola hasła nie została zakończona pomyślnie, serwer przechodzi do kroku S3B, w którym przetwarza informacje o błędzie. Ten krok może

11 1 2 3 wiązać się z próbą ponownego ustanowienia połączenia. Zakładając, że połączenie zostało ustanowione poprawnie, kolejnym krokiem jest S4B, w którym trwa oczekiwanie na identyfikator odbiorcy i dane do przesłania. Jeśli zajdzie taka potrzeba, na tym etapie może zostać zastosowany komunikat o przekroczeniu maksymalnego dozwolonego czasu na działanie. U nadawcy, w kroku S2A, także przeprowadzana jest kontrola nawiązania połączenia, czyli sprawdzenie czy wszystkie protokoły połączenia są obsługiwane i czy wszystkie hasła zostały poprawnie wprowadzone. Jeśli połączenie nie zostało ustanowione lub kontrola hasła nie została zakończona pomyślnie, serwer przechodzi do kroku S3A, w którym przetwarza informacje o błędzie. Ten krok może wiązać się z próbą ponownego ustanowienia połączenia. Zakładając, że połączenie zostało ustanowione poprawnie, kolejnym krokiem jest S4A, w którym następuje wysłanie identyfikatora odbiorcy i danych do transmisji. Jeśli zajdzie taka potrzeba, na tym etapie może zostać zastosowany komunikat o przekroczeniu maksymalnego dozwolonego czasu na działanie. W jednym przykładzie, na urządzeniu wyświetlającym wyświetlona zostaje strona internetowa służąca do przesyłu danych, na której wymagane jest wprowadzenie identyfikatora odbiorcy i załączenia danych, które mają zostać przesłane, na przykład dane w postaci pliku znajdującego się w źródle danych 8. Uzupełniona strona przesyłu danych zostaje następnie przesłana na serwer 0. Dane, które mają zostać zakodowane, mogą zostać wprowadzone bezpośrednio na stronie przesyłu danych. Zawartość strony przesyłu danych jest odbierana przez serwer 0 w kroku S4B, po którym następuje krok SB. Na tym etapie serwer generuje wartość skrótu, która jest unikalna dla przesyłanych danych, po czym przesyła tę wartość do klienta Proces kontynuuje w kroku S6B. W kroku S6B dane zostają skompresowane, na przykład do formatu zip. Następnie, w kroku S7B, na podstawie losowych liczb uzyskanych z generatora losowych liczb 311, tworzony jest klucz sesji, który zostaje przypisany do konkretnej transmisji danych. Kolejnym krokiem jest S8B, w którym następuje kodowanie danych przy pomocy klucza sesji; zakodowane dane zostają przesłane do klienta Proces kontynuuje w kroku S9B, w którym klucz sesji zostaje zakodowany przy użyciu klucza RSA. Następnie, w kroku SB, uzyskane zostaje hasło odbiorcy. Krok S11B polega na kodowaniu danych z etapu S9B przy pomocy algorytmu Blowfish i hasła uzyskanego w kroku SB. Powstały zakodowany klucz sesji jest następnie przesyłany do klienta W kolejnym kroku, którym jest S12B, wiadomość jest tworzona przez klienta 312 w znany sposób, aby w odpowiednim formacie mogła zostać przesłana przez HTML.

12 Kodowanie może się odbywać na przykład przy użyciu Base64. Dla zakodowanych danych i zakodowanego klucza sesji zastosowany może być także załącznik HTML lub wbudowany kod HTML. Następnie odbywa się wysyłanie wiadomości , a fakt jej wysłania zostaje zarejestrowany w standardowy sposób; nadawca otrzymuje potwierdzenie wysłania wiadomości, po czym proces zostaje zakończony. Pożądanym rozwiązaniem jest ustawienie wartości skrótu, zakodowanych danych i zakodowanego klucza sesji w wiadomości jako pola ukryte, a także zawarcie w niej linku HTML umożliwiającego odbiorcy kontakt zwrotny z serwerem. Link ten jest konfigurowany w taki sposób, aby automatycznie odesłać ukryte pola w formie HTML na serwer. Nagłówek wiadomości jest wybierany przez nadawcę, a wiadomość jest wysyłana na adres odbiorcy. W kroku SA nadawca otrzymuje potwierdzenie wysłania wiadomości i proces zostaje zakończony. Rysunek 4 jest diagramem sekwencji działań przedstawiającym procesy zachodzące pomiędzy odbiorcą a serwerem w odpowiedzi na wiadomość otrzymaną z serwera. W kroku S1A odbiorca 0 otrzymuje z serwera wiadomość , która zawiera, między innymi, zakodowane dane, zakodowany klucz sesji oraz wartość skrótu. Wiadomość może zostać pobrana z poziomu strony internetowej lub poprzez klienta 212 wykorzystując połączenie 213. W kroku S2A odbiorca otwiera wiadomość i kontaktuje się z serwerem w celu ustanowienia bezpiecznego połączenia, na przykład SSL. Jak zostało opisane powyżej, ustanowienie takiego połączenia wymaga wykorzystania pewnych protokołów połączenia, przeprowadzenia wspomnianej wcześniej kontroli hasła, opisanej w odniesieniu do modułu, na przykład w formie strony internetowej, wyświetlanej na urządzeniu wyświetlającym, wprowadzenia danych logowania na stronie internetowej, itd. Jak to zostało wspomniane już wcześniej, procedury ustanawiania połączenia oraz kontroli hasła są dobrze znane i nie zostaną opisane w niniejszym dokumencie. Serwer w odpowiedzi na kontakt ze strony odbiorcy także próbuje ustanowić połączenie w kroku S1B wykorzystując pewne protokoły połączenia i przeprowadzając kontrolę hasła. W kroku S2B serwer sprawdzi, czy ustanowione zostało połączenie, czyli czy wszystkie protokoły połączenia są obsługiwane i czy wszystkie hasła zostały poprawnie wprowadzone. Jeśli połączenie nie zostało ustanowione lub kontrola hasła nie została zakończona pomyślnie, serwer przechodzi do kroku S3B, w którym przetwarza informacje o błędzie. Ten krok może wiązać się z próbą ponownego ustanowienia połączenia. Zakładając, że połączenie zostało ustanowione poprawnie, kolejnym krokiem jest S4B, w którym trwa oczekiwanie

13 na identyfikator odbiorcy i inne informacje zawierające zakodowane dane do przesłania, zakodowany klucz sesji i wartość skrótu. Jeśli zajdzie taka potrzeba, na tym etapie może zostać zastosowany komunikat o przekroczeniu maksymalnego dozwolonego czasu na działanie. U nadawcy, w kroku S3A, także przeprowadzana jest kontrola nawiązania połączenia, czyli sprawdzenie czy wszystkie protokoły połączenia są obsługiwane i czy wszystkie hasła zostały poprawnie wprowadzone. Jeśli połączenie nie zostało ustanowione lub kontrola hasła nie została zakończona pomyślnie, serwer przechodzi do kroku S4A, w którym przetwarza informacje o błędzie. Ten krok może wiązać się z próbą ponownego ustanowienia połączenia. Zakładając, że połączenie zostało ustanowione poprawnie, kolejnym krokiem jest SA, w którym następuje wysłanie identyfikatora odbiorcy i pozostałych danych wspomnianych w poprzednich akapitach. Jeśli zajdzie taka potrzeba, na tym etapie może zostać zastosowany komunikat o przekroczeniu maksymalnego dozwolonego czasu na działanie. Informacje te mogą zostać przesłane w wiadomości w formie ukrytych pól HTML na serwer 0. Protokół dotyczący czasu i ustawień w kwestii wysyłania identyfikatorów, ukrytych pól, haseł, itp., może być zmieniany w zależności od danej sytuacji. Następnym etapem jest krok S B, w którym serwer otrzymuje z modułu 6 hasło odbiorcy, po czym, w kroku S6B, zakodowany klucz sesji zostaje odkodowany przy pomocy algorytmu Blowfish i hasła uzyskanego w kroku SB. Następnym etapem jest proces odkodowania RSA S7B, w którym dane z kroku S6B zostają odkodowane wykorzystując prywatny klucz serwera. W ten sposób zostaje utworzony klucz sesji. Następnie, w kroku S8B, skompresowane dane zostają odkodowane przy użyciu odkodowanego klucza sesji utworzonego w kroku S7B. Kolejnym etapem jest dekompresja danych w kroku S9B. W kroku S1B serwer generuje wartość skrótu, która jest unikalna dla danych z kroku S9B. Następnie, w kroku S111B, wartość skrótu z kroku S1B jest porównywana z wartością skrótu uzyskaną w kroku S4B. Po uwierzytelnieniu wartości skrótu, w kroku S113B niezakodowane dane od nadawcy zostają przesłane odbiorcy wykorzystując bezpieczne połączenie. Wysłanie danych zostaje zarejestrowane i proces zostaje zakończony. Jeśli wartość skrótu nie może zostać uwierzytelniona, w kroku S112B zostaje przetworzona informacja o błędzie. Może to wiązać się z zarejestrowaniem błędu i wysłaniem wiadomości o błędzie do odbiorcy, aby powiadomić go o możliwym uszkodzeniu danych. W kroku S6A odbiorca otrzymuje niezakodowane dane i proces zostaje zakończony. Wynalazek opisany powyżej zakłada, że cały proces kodowania i odkodowania przebiega na serwerze 0. W związku z ty, ani nadawca ani odbiorca nie potrzebują żadnego

14 dedykowanego oprogramowania, aby bezpiecznie wysłać i odebrać dane. W szczególności nie ma konieczności posiadania oprogramowania ani też wykorzystywania pamięci sprzętowej czy zasobów przetwarzania w celu dokonania kodowania RSA lub Blowfish. Ponadto, obsługa haseł odbywa się na serwerze, więc nadawca nie jest za nią odpowiedzialny. Z uwagi na fakt, że kodowanie i dekodowanie odbywa się na serwerze, po stronie nadawcy i odbiorcy nie są wymagane żadne dodatkowe czynności z tym związane. Jednakże, niniejszy wynalazek obejmuje także alternatywne rozwiązanie dla funkcji przedstawionych na rysunku 2 w kwadracie 317, które mają znajdują się po stronie nadawcy. Modyfikacja to pozwala na generowanie klucza sesji z liczb losowo wybranych przez generator a kompresowanie danych i kodowanie skompresowanych danych przy pomocy wygenerowanego klucza sesji odbywają się po stronie nadawcy. Ustanawiane jest bezpieczne połączenie z serwerem, tak jak opisano powyżej, jednakże w tym przypadku jedynie wygenerowany klucz sesji zostaje wysłany na serwer. Po kontroli hasła, opisanej powyżej, moduły S313 i S314 ponownie generują zakodowany klucz sesji, który w tym wypadku zostaje odesłany do nadawcy. Zakodowane dane, zakodowany klucz sesji i wartość skrótu zostają przekazane do klienta nadawcy (nieuwzględniony na rysunku), który także jest podłączony do Internetu. Klient tworzy wiadomość , tak jak to zostało opisane powyżej, zanim zostanie ona wysłana do nadawcy. W związku z tym kroki od SB do S8B uwzględnione na rysunku 3 odbywają się po stronie nadawcy. Dzięki temu obniżone zostają wymagania obliczeniowe na serwerze. Odbiorca otrzymuje wiadomość przy pomocy swojego klienta i może przetworzyć tę wiadomość tak jak zostało to pokazane na rysunku 4. Jednakże, niniejszy wynalazek zakłada także alternatywne rozwiązanie dla funkcji przedstawionych na rysunku 2 w kwadracie 322, które odbywają się po stronie odbiorcy po otrzymaniu wiadomości z serwera. W opisywanej modyfikacji odkodowanie danych, dekompresja danych, generowanie wartości skrótu i ich uwierzytelnianie odbywają się po stronie odbiorcy. Ustanawiane jest bezpieczne połączenie z serwerem, tak jak to zostało opisane powyżej, jednakże w tym wypadku jedynie zakodowany klucz sesji zostaje wysłany na serwer. Po kontroli hasła, moduły S3 i S321 ponownie odkodowują klucz sesji, który w tym wypadku zostaje odesłany do odbiorcy. Zakodowane dane zostają odkodowane przy użyciu odkodowanego klucza sesji i zdekompresowane, wartość skrótu zostaje wygenerowana i porównana w celu uwierzytelnienia z wartością skrótu otrzymaną w wiadomości . W związku z tym kroki od S8B do S113B na rysunku 4 odbywają się po stronie odbiorcy. Dzięki temu obniżone zostają wymagania obliczeniowe na serwerze.

15 Dobrym rozwiązaniem byłoby wprowadzenie obu modyfikacji opisanych powyżej w tym samym czasie. Jednakże, biorąc pod uwagę obecny wynalazek, kodowanie klucza sesji w połączeniu z hasłem odbiorcy może odbywać się na serwerze. Dobrym rozwiązaniem byłoby także zarejestrowanie grupy użytkowników, do których będą wysyłane wiadomości . Na przykład, dział IT danej firmy może zarejestrować wszystkich pracowników. W takim przypadku, jeśli nie powiedzie się kontrola hasła na serwerze, możliwe będzie odniesienie się do pozostałych haseł w tej grupie. W częściach wynalazku, w których wymagane jest specjalne oprogramowanie dla nadawcy i odbiorcy, może ono zostać pobrane z serwera podczas procesu rejestracji a następnie zainstalowane. Ze względu na fakt, że do odkodowania danych przy pomocy algorytmu Blowfish potrzebne jest poprawne hasło odbiorcy a poprawne odkodowanie jest sprawdzanie poprzez uwierzytelnianie wartości skrótu, dobrym rozwiązaniem byłaby możliwość zrezygnowania z kontroli hasła w kroku 2A przy połączeniu pomiędzy odbiorcą a serwerem. Jeśli odkodowanie nie powiedzie się, dobrym rozwiązaniem byłoby, aby serwer 0 przeprowadzał dalsze próby kontroli w celu uzyskania poprawnego hasła, na przykład, poprzez sprawdzanie wszystkich starych haseł odbiorcy w celu odkodowania danych. Jeśli jedno z tych haseł doprowadzi do wytworzenia poprawnej wartości skrótu, odkodowanie uznane zostanie za udane. Jednakże, jeśli żadne z haseł nie zadziała, oznacza to, że odbiorca nie jest właściwy lub dane zostały uszkodzone podczas transferu. Jeśli odbiorca nie posiada hasła lub nie został jeszcze zarejestrowany na serwerze 0, serwer może wygenerować jednorazowe hasło, które zostanie przekazane odbiorcy z zastosowaniem odpowiednich środków bezpieczeństwa, takich jak bezpieczna poczta, bezpieczne połączenie lub zabezpieczona wiadomość . Odbiorca będzie zobowiązany do zmienienia hasła na bezpieczne, które będzie wykorzystywane w przyszłości. Niniejszy wynalazek umożliwia kontrolę tożsamości nadawcy oraz odbiorcy, dzięki czemu nadawca ma możliwość wysłania danych do odbiorcy, który nie posiada zainstalowanego specjalnego oprogramowania, a odbiorca zna pochodzenie danych. Ponadto, wszelkie próby kodowania i odkodowania są rejestrowane, co pozwala nadawcy na sprawdzenie, czy odbiorca otrzymał odkodowane dane, natomiast odbiorca może sprawdzić, czy dane, których oczekuje, zostały wysłane przez nadawcę. Urządzeniami nadawcy i odbiorcy mogą być, między innymi, komputer, palmtop, laptop, telefon komórkowy, itd. Serwer jest zazwyczaj komputerem, lecz może być to także inne urządzenie pełniące rolę serwera.

16 Dzięki temu, że hasła przechowywane są na serwerze, niniejszy wynalazek pozwala na to, że ani nadawca ani odbiorca nie znają hasła drugiej strony. Konsekwencją tego jest fakt, że poziom bezpieczeństwa wymagany przez nadawcę i odbiorcę nie jest tak wysoki jak w przypadku innych form bezpiecznego transferu danych. Niniejszy wynalazek zakłada, że serwer jest odpowiedzialny za przechowywanie informacji o odbiorcy, takich jak hasło wykorzystywane przez serwer podczas kodowania danych. Serwer uzyskuje te informacje z pamięci danych, w której znajduje się lista identyfikatorów odbiorców i poufne informacje o odbiorcach. Informacje o odbiorcach mogą zawierać słowo lub frazę będącą hasłem, numer PIN, wartość skrótu lub jakąkolwiek inną informację wykorzystywaną do identyfikacji tożsamości. Siecią wykorzystywaną z niniejszym wynalazkiem może być Internet, lokalny Intranet taki jak sieć Ethernet, sieć telefoniczna, radiowa lub jakikolwiek inny rodzaj sieci umożliwiający transmisję danych. W razie wykorzystywania sieci Internet, zaleca się wykorzystywanie bezpiecznego połączenia SSL pomiędzy serwerem a nadawcą i/lub pomiędzy serwerem a odbiorcą. Nadawca i odbiorca mogą zostać zidentyfikowani przez serwer na podstawie ich adresów (lub innych adresów sieciowych). Jednakże, mogą oni posiadać również identyfikatory użytkowników, które nie są powiązane z ich adresami sieciowymi. Serwer może posiadać listę adresów sieciowych w swojej bazie danych i/lub może posiadać listę identyfikatorów użytkowników, gdy adresy sieciowe i/lub identyfikatory użytkowników są powiązane z poufnymi danymi o odbiorcach. W niniejszym wynalazku serwer 0 może posiadać poufny kod przypisany do tego serwera i znany tylko jemu. Poufny kod może być zawarty w modułach kodowania i dekodowania algorytmem Blowfish i może także, obok informacji o odbiorcy, zostać wykorzystany do kodowania. Te dwa rodzaje informacji mogą zostać połączone dla celów kodowania. Wykorzystanie poufnego kodu zapewnia podwyższony poziom bezpieczeństwa w systemie. Zalecane jest, aby serwer nie musiał przechowywać klucza sesji, ani żadnych innych danych wysłanych do odbiorcy. Dane takie mogą być przechowywane w pamięci ulotnej na serwerze i nadpisywane podczas kodowanie innych danych i kluczy. Ma to taką zaletę, że serwer nie musi posiadać dużych zasobów pamięci, w której będzie przechowywał stare i niepotrzebne dane i/lub klucze. Nośnikiem może być środek nietrwały, na przykład sygnał elektryczny, optyczny, mikrofale, sygnał radioelektryczny, elektromagnetyczny, akustyczny czy magnetyczny (na przykład sygnał TCP/IP w sieci IP takiej jak Internet). Nośnikiem może być także dyskietka, CD- ROM, dysk twardy lub urządzenie z programowalną pamięcią.

17 16 Pomimo faktu, że niniejszy wynalazek został opisany ze względu na preferowane ustawienia na dzień dzisiejszy, osoby zaznajomione z tą tematyką wiedzą, iż możliwe jest dokonywanie różnego rodzaju zmian bez odbiegania od założeń wynalazku, które zostały zdefiniowany w zgłoszeniu. Niniejszy wynalazek może być stosowany, miedzy innymi, przez dostawców usług telefonii komórkowej, którzy mogą wysyłać comiesięczne raporty użytkownikom swojej sieci w bezpieczny sposób, a użytkownicy będą mieli możliwość połączenia się z serwerem w celu pobrania zakodowanego raportu. W podobny sposób banki mogą przesyłać informacje o wpływach na konto swoim klientom, którzy w prosty sposób mogą połączyć się z serwerem w sposób opisany powyżej i pobrać dane w bezpieczny sposób. GCRYPT LIMITED, Wielka Brytania, Pełnomocnik

18 17 EP Z-6374/09 Zastrzeżenia patentowe 1. Sposób kodowania i przesyłu danych pomiędzy nadawcą (0) a odbiorcą (0) przy użyciu sieci; sposób ta składa się z następujących etapów: - serwer (0) otrzymuje od nadawcy (0) identyfikator odbiorcy; - utworzenie przypisanego klucza kodowania (3) przydzielonego do danej transmisji; - kodowanie danych przy użyciu przypisanego klucza kodowania (9); - serwer (0) pobiera informację o odbiorcy (6) na podstawie identyfikatora odbiorcy wysłanego przez nadawcę i koduje (314), wraz z informacją o odbiorcy, rzeczony przypisany klucz kodowania; - przesłanie zakodowanych danych i zakodowanego przypisanego klucza kodowania przez sieć do odbiorcy (0); znamienny tym, że: - serwer otrzymuje od odbiorcy zakodowany przypisany klucz kodowania i identyfikator odbiorcy; oraz - serwer pobiera informację o odbiorcy (6) na podstawie identyfikatora odbiorcy wysłanego przez odbiorcę w celu odkodowania zakodowanego przypisanego klucza kodowania (3); oraz - odkodowanie zakodowanych danych przy użyciu odkodowanego przypisanego klucza kodowania (323). 2. Sposób, zgodnie z zastrzeżeniem 1, zakładający ustanowienie połączenia (111, 2) pomiędzy nadawcą a serwerem i wysłanie rzeczonego identyfikatora odbiorcy na serwer. 3. Sposób, zgodnie z zastrzeżeniem 2, zakładający ustanowienie połączenia pomiędzy nadawcą a serwerem jako połączenie bezpieczne. 4. Sposób, zgodnie z zastrzeżeniem 2 lub 3, zakładający ustanowienie połączenia pomiędzy nadawcą a serwerem z uwzględnieniem możliwość kontroli hasła nadawcy () przez serwer.

19 18. Sposób, zgodnie z poprzednimi zastrzeżeniami, zakładający ustanowienie połączenia (211, 2) pomiędzy odbiorcą a serwerem i wysyłanie rzeczonego identyfikatora odbiorcy na serwer. 6. Sposób, zgodnie z zastrzeżeniem, zakładający ustanowienie połączenia pomiędzy odbiorcą a serwerem jako połączenie bezpieczne. 7. Sposób, zgodnie z zastrzeżeniem lub 6, zakładający ustanowienie połączenia pomiędzy nadawcą a serwerem z uwzględnieniem możliwość kontroli hasła odbiorcy () przez serwer. 8. Sposób, zgodnie z poprzednimi zastrzeżeniami, znamienny tym, że utworzenie przypisanego klucza kodowania odbywa się po stronie nadawcy a utworzony przypisany klucz kodowania wysyłany jest na serwer. 9. Sposób, zgodnie z poprzednimi zastrzeżeniami, znamienny tym, że kodowanie danych przy użyciu przypisanego klucza kodowania odbywa się po stronie nadawcy.. Sposób, zgodnie z zastrzeżeniem 9, znamienny tym, że nadawca otrzymuje z serwera zakodowany przypisany klucz kodowania i przesyła zakodowane dane i zakodowany przypisany klucz kodowania do odbiorcy za pośrednictwem sieci. 11. Sposób, zgodnie z zastrzeżeniami od 1 do 7, znamienny tym, że odbiorca otrzymuje z serwera odkodowany przypisany klucz kodowania, oraz odkodowanie danych przy użyciu odkodowanego przypisanego klucza kodowania odbywa się po stronie odbiorcy. 12. Sposób, zgodnie z zastrzeżeniami od 1 do 7, znamienny tym, że utworzenie przypisanego klucza kodowania odbywa się na serwerze. 13. Sposób, zgodnie z zastrzeżeniem 12, znamienny tym, że kodowanie danych przy użyciu przypisanego klucza kodowania odbywa się na serwerze. 14. Sposób, zgodnie z zastrzeżeniem 13, znamienny tym, że serwer przesyła zakodowane dane i zakodowany przypisany klucz kodowania do odbiorcy za pośrednictwem sieci. 1. Sposób zgodnie z zastrzeżeniami od 1 do oraz od 12 do 14, znamienny tym, że odkodowanie zakodowanych danych przy użyciu odkodowanego przypisanego klucza kodowania odbywa się na serwerze i serwer przesyła odkodowane dane do odbiorcy. 16. Sposób, zgodnie ze wszystkimi poprzedzającymi wnioskami, na którą składa się: - utworzenie wartości kodu uwierzytelniania wiadomości (MAC) (7) dla danych zanim zostaną zakodowane; - przesłanie wartości MAC razem z zakodowanymi danymi i zakodowanym przypisanym kluczem kodowania; oraz - utworzenie wartości MAC (32) dla danych po odkodowaniu i uwierzytelnienie (326) na podstawie przesłanej wartości MAC.

20 Sposób, zgodnie ze wszystkimi poprzedzającymi zastrzeżeniami, znamienny tym, że kodowanie przypisanego klucza kodowania wykorzystuje jedną lub więcej metod kodowania kluczy publicznych, algorytm Blowfish i poufny kod serwera. 18. Sposób wykorzystania serwera (0) do celów kodowania i przesyłania danych pomiędzy nadawcą (0) a odbiorcą (0) z wykorzystaniem sieci; składający się z następujących etapów: - odebranie od nadawcy (0) identyfikatora odbiorcy; - pobranie informacji o odbiorcy (6) na podstawie identyfikatora odbiorcy wysłanego przez nadawcę i kodowanie (314), wraz z informacją o odbiorcy, przypisanego klucza kodowania, wykorzystywanego do kodowania danych; znamienny tym, że: - otrzymanie od odbiorcy (0) zakodowanego przypisanego klucza kodowania i identyfikatora odbiorcy po przesłaniu przez sieć zakodowanych danych i zakodowanego przypisanego klucza kodowania, aby mogły zostać odebrane przez odbiorcę; - pobranie informacji o odbiorcy (6) na podstawie identyfikatora odbiorcy wysłanego przez odbiorcę w celu odkodowania zakodowanego przypisanego klucza kodowania; 19. Sposób wykorzystania serwera, zgodnie z zastrzeżeniem 18, zakładający utworzenie na serwerze (3) przypisanego klucza kodowania, przydzielonego do transferu.. Sposób wykorzystania serwera, zgodnie z zastrzeżeniem 18, zakładający odebranie od nadawcy przypisanego klucza kodowania, przydzielonego do transferu oraz przesłanie zakodowanego przypisanego klucza kodowania do nadawcy. 21. Sposób wykorzystania serwera, zgodnie z jednym z zastrzeżeń od 18 do, zakładający kodowanie danych na serwerze (9) przy użyciu przypisanego klucza kodowania. 22. Sposób wykorzystania serwera, zgodnie z każdym z zastrzeżeń od18 do 21, zakładający przesłanie zakodowanych danych i zakodowanego przypisanego klucza kodowania przez sieć, aby mogły zostać odebrane przez odbiorcę. 23. Sposób wykorzystania serwera, zgodnie z każdym z zastrzeżeń od 18 do 22, zakładający przesłanie odkodowanego przypisanego klucza kodowania do odbiorcy. 24. Sposób wykorzystania serwera, zgodnie z każdym z zastrzeżeń od 18 do 22, zakładający odkodowanie zakodowanych danych na serwerze (323) wykorzystując odkodowany przypisany klucz kodowania. 2. Środowisko komputerowe dla sposobu kodowania i przesyłu danych pomiędzy nadawcą (0) a odbiorcą (0) przy użyciu sieci, zawierające:

21 - kod komputerowy służący do odbierania od nadawcy identyfikatora odbiorcy i tworzenia przypisanego klucza kodowania (S7B) przydzielonego do transmisji; - kod komputerowy służący do kodowania danych przy użyciu przypisanego klucza kodowania (S8B); - kod komputerowy służący do odbierania informacji o odbiorcy (SB) na podstawie identyfikatora odbiorcy wysłanego przez nadawcę i kodowanie (S11B), wraz z informacją o odbiorcy, rzeczonego przypisanego klucza kodowania; - kod komputerowy służący do przesyłania zakodowanych danych i zakodowanego przypisanego klucza kodowania przez sieć (S12B), aby mogły zostać odebrane przez odbiorcę; znamienne tym, że: - kod komputerowy służący do odbierania od odbiorcy (S1B) zakodowanego przypisanego klucza kodowania i identyfikatora odbiorcy, oraz do odbierania informacji o odbiorcy (SB) na podstawie identyfikatora odbiorcy wysłanego przez odbiorcę w celu odkodowania zakodowanego przypisanego klucza kodowania (S6B); oraz - kod komputerowy służący do odkodowania zakodowanych danych (S8B) wykorzystując odkodowany przypisany klucz kodowania. GCRYPT LIMITED, Wielka Brytania, Pełnomocnik

22 21 EP Z-6374/09

23 22 EP Z-6374/09 2 Serwer WWW 1 3 MAC Kompresja Kodowanie Losowa liczba Klucz sesji Kontrola hasła Baza danych Mikroproces or Odkodowani e Blowfish Odkodowani e RSA Odkodowani e 326 Kontrola MAC Kodowanie RSA Dekompresja MAC Kodowanie Blowfish Klient Rys

24 23 EP Z-6374/09 NADAWCA SERWER START S1A S1B START Przetwa rzanie informa cji o błędzie S3B Tak Połączenie z serwerem Obsługa protokołów Kontrola hasła Błąd? Nie S2B S4B SB S2B Nie Połączenie z serwerem Obsługa protokołów Kontrola hasła S3B Błąd? Tak Oczekiwanie na identyfikator i dane Tworzenie wartości skrótu Wysłanie do klienta Przetwarzanie informacji o błędzie S4B Wysyłanie identyfikatora odbiorcy. Wysyłanie danych na serwer. S6B S7B Kompresja danych Tworzenie klucza sesji S8B Kodowanie danych kluczem sesji Wysłanie do klienta S9B Kodowanie klucza sesji publicznym kluczem RSA SB Pobranie hasła odbiorcy Potwierdzenie przesyłu danych SA S11B Kodowanie klucza sesji algorytmem Blowfish i hasłem odbiorcy Wysyłanie do klienta KONIEC S12B Wysłanie wiadomości i rejestracja Potwierdzenie dla nadawcy KONIEC Rys. 3

25 24 EP Z-6374/02 OBIORCA SERWER START Odebrania wiadomości Zakodowane dane Zakodowany klucz sesji Wartość skrótu S2A Przetwarzanie informacji o błędzie Połączenie z serwerem Obsługa protokołów Kontrola hasła Tak S4A Błąd? Nie S1A S3A S2B SB START Połączenie z serwerem Obsługa protokołów Kontrola hasła Błąd? Nie S3B Tak Oczekiwanie na identyfikator i dane Przetwarzanie informacji o błędzie Pobranie hasła odbiorcy S1B S4B Wysłanie identyfikatora odbiorcy Wysłanie zakodowanych danych na serwer Wysłanie wartości skrótu Wysłanie zakodowanego klucza sesji SA S6B S7B Odkodowanie klucza sesji algorytmem Blowfish i hasłem odbiorcy Odkodowanie klucza sesji publicznym kluczem RSA Odkodowanie danych kluczem sesji S8B Dekompresja danych S9B Tworzenie wartości skrótu S112B S1B Przetwarzanie informacji o błędzie Nie Uwierzytelni anie wartości skrótu S111B Odbiór danych S6A Tak Wysłanie wiadomości do odbiorcy i rejestracja S113B KONIEC KONIEC Rys. 4