Strona 1 z 2 12 OstatniOstatni
Pokaż wyniki 1 do 10 z 18

Temat: bezpieczna wymiana danych

  1. #1
    Zarejestrowany
    May 2010
    Postów
    184

    Domyślnie bezpieczna wymiana danych

    w jaki sposob moge zrealizowac bezpieczna wymiane danych?

    Stworzylem sobie taki algorytm:

    + uzywany jest szyfr asymetryczny
    + server ma 2 polowki kluczy, klient drugie 2.

    - klient laczy sie z serwerem
    - serwer wysyla klientowi losowe dane plain textem
    - klient szyfruje dane swoim kluczem dozuca wlasne dane w plain text i wysyla (dorzuca do nich dynamicznie wygenerowany klucz szyfrowania w postaci zaszyfrowanej, najlepiej dokleja do oryginalnych danych drugiej strony)
    - serwer porownuje otrzymane dane czy po zorszyfrowaniu sa zgodne z oryginalem, jak tak - klient ok
    - serwer odzyla klientowi jego zaszyfroawane dane (dorzuca do nich dynamicznie wygenerowany klucz szyfrowania w postaci zaszyfrowanej, najlepiej dokleja do oryginalnych danych drugiej strony)
    - klient je odszyfrowuje, i jesli sie zgadza - serwer ok
    - teraz obie strony uzywaja dynamicznego klucza do wymiany danych
    - pod koniec, obie strony niszcza dynamiczny klucz


    czy sa jakies bledy? Cos pominalem?

  2. #2
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    To co opisujesz to wlasnie mniej wiecej to co dzieje sie w TLS/SSL - klucz asymetryczny (pub+priv) jest uzywany tylko do bezpiecznej wymiany klucza symetrycznego ktory bedzie uzywany do szyfrowania/deszyfrowania wlasciwej transmisji. Nie wiem tylko po co robic to od zera skoro sa gotowe rozwiazania i pozwalaja na wiecej niz to co opisales.
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  3. #3
    Zarejestrowany
    May 2010
    Postów
    184

    Domyślnie

    uzywanie klucza symetrycznego to zly pomysl. Jak zlapie pakiety nim zaszyfrowane, i potem zlapie klucz, bede mogl je rozszyfrowac.
    Jak wymienie 2 klucze asymetryczne, nigdy tego nie rozszyfruje.

    Mozesz opisac jak dziala ssl krok po kroku? Glownie chodzi mi o hjakies certyfikaty, bo tego nie moge znalezc. Co to one sa?

  4. #4
    Zarejestrowany
    Jun 2010
    Postów
    226

    Domyślnie

    Może TO ci się przyda.
    Dość przejrzysty opis.

  5. #5
    Zarejestrowany
    May 2010
    Postów
    184

    Domyślnie

    Ogólny schemat działania metod szyfrowania z kluczem publicznym jest następujący:

    Każda ze stron generuje parę kluczy (publiczny+prywatny)
    Każda ze stron publikuje swój klucz publiczny w sieci (jest on dostępny dla wszystkich)
    Jeżeli A chce przesłać wiadomość do B to szyfruje ją kluczem publicznym B. Z własności algorytmu wynika, że tylko używając klucza prywatnego B można ją odtworzyć
    (to jest typowy schemat wymiany danych).
    Jeżeli B chce mieć pewność, że wymienia informacje rzeczywiście z A, to może np. poprosić A o zaszyfrowanie pewnego tekstu jego kluczem prywatnym. Jeżeli B będzie w stanie odtworzyć tekst używając klucza publicznego A to znaczy, że rozmawia rzeczywiście z właściwym partnerem.
    (to jest typowy schemat autentyfikacji partnera)
    Jeżeli B po odebraniu wiadomości od A chce zabezpieczyć się przed sytuacją, w której A zaprzeczy, że wysłał wiadomość, może poprosić A o zaszyfrowanie jej dodatkowo swoim kluczem prywatnym (a następnie kluczem publicznym B). B będzie w stanie ją odszyfrować (najpierw używając swojego klucza prywatnego, a następnie publicznego klucza A) i A nie będzie mógł zaprzeczyć, że wiadomość wysłał - wiadomość która dała się odszyfrować kluczem publicznym A musiała być zaszyfrowana jego kluczem prywatnym.
    (to jest typowy schemat podpisu cyfrowego)
    gowno prawda.

    jesli opublikuje klucz szyfrowania, to kazdy moze go uzyc i byc strona. klucze do szyfrowania zawsze musza byc prywatne, a te do deszyfrowania mozna rozdac - potem wyslac klucz szyfrowania bezpiecznym kanalem.

  6. #6
    Zarejestrowany
    Jun 2010
    Postów
    226

    Domyślnie

    Z tego co wyczytałem nie ma tu mowy o publikowaniu klucza prywatnego.
    Jeśli Cie to nie satysfakcjonuje to możesz użyć szyfrowania/ klucza kwantowego który wyklucza cokolwiek.
    Klucz jest wysyłany w postaci fotonów czyli nie można niczego odczytać bez zakłócania/ zniszczenia danych (zasada nieoznaczoności Heisenberga) , a jak nie to nie wiem co jeszcze chcesz wiedzieć

  7. #7
    Zarejestrowany
    May 2010
    Postów
    184

    Domyślnie

    Server ma tajny klucz prywatny ktory sluzy o deszyfrowania ruchu klient -> serwer, oraz jako dowod tozsamosci serwera.
    Klucz publiczny jest ogolnodostepny. Na poczatku jest tylko 1 para kluczy, lub 2 jesli chce ustalic czy klient jest ten co powinien.

    przypadem kiedy chce wiedziec ktory klient sie polaczyl:
    1. Klient sie laczy z serwerem.
    2. Server wysyla klientowi blok danych.
    3. Klient szyfruje te dane swoim kluczem prywatnym, dodaje wlasne dane (szyfruje kluczem publicznym serwera) i wysyla serwerowi.
    4. Serwer sprawdza kazdy klucz po kolei i ustala klienta w ten sposob. Deszyfruje swoim kluczem prywatnym dane od klienta i mu je odsyla.
    5. Klient sprawdza czy dane sie zgadzaja.
    6. 1 strona generuje pare kluczy, blok danych i wysyla drugiej dane i klucz publiczny (dane zaszyfrowane).
    7. 2ga strona odbiera dane i klucz publiczny, deszyfruje dane, i szyfruje je nowym kluczem ktory wlsanie dostala. Nastepnie odsyla zaszyfrowane dane zpowrotem.
    6. 1wsza strona porownuje dane, jak sie zgadzaja, ok.
    7. 2ga strona wysyla 1wszej stronie klucz symetryczne
    8. Obie strony niszcza klucze asymetryczne (te wygenerowane) i reszta odbiwa sie za pomoca klucza symetrycznego.


    jakies bledy? Nie chce uzywac ssl bo sie boje. No i nie potrafie i tak tego zaimplementowac.

  8. #8
    Zarejestrowany
    Jun 2006
    Skąd
    rand(.eu)
    Postów
    8,748

    Domyślnie

    Uzyj biblioteki do tego celu, nie pisz calosci samemu bo to nie ma sensu...

    Z tego co pamietam to SSL/TLS uzywa asymetrycznego szyfrowania tylko do wymiany losowego klucza symetrycznego ktorym pozniej szyfruje/deszyfruje caly ruch - symetryczne szyfrowanie jest o wiele wydajniejsze
    ctrl-alt-del.cc - soft reset site for IT admins and other staff :-)

  9. #9
    Zarejestrowany
    May 2010
    Postów
    184

    Domyślnie

    ale i tak najpierw musi wymienic klucz asymetryczny, bo co ztego jak wysle klucz asymetryczny, ktos zlapie pakiety sesji, a pozniej zhackuje serwer i odczyta jego klucz
    .
    Juz chyba zalapalem o co chodzi, 'polaczenie' mozna ustanowic w 3 krokach:

    klient sie laczy, i:

    + klient generuje pare kluczy, wysyla serwerowi klucz publiczny. Wymagany jest klucz prywatny serwera by rozszyfrowac nowy klucz publiczny uzywane w szyfrowaniu S -> K.

    + serwer generuje pare kluczy, i z uzyciem odebranego klucza wysyla klientowi klucz publiczny. Wymagana jest tu znajomosc klucza prywatnego klienta ktory nigdy nie zostal wyslany.

    + klient robi to samo co server, zeby nie uzywac pierwotnego klucza.

    Jedyne ryzyko to to ze ktos moze w kroku 1 wyslac serwerowi wlasny klucz, a nastepnie re-szyfrowac dane S -> K w efekcie miec do nich dostep. W kroku 3 nie moze wyslac danych do klienta, bo musialby miec klucz wyslany w punkcie 1 by odszyfrowac dane. Ale z tym mozna sobie poradzic, w tym przypadku chodzi mi o auth serwera - klienci beda bez kontroli.
    Wiec trzeba sie upewnic ze po 2giej wymianie obie strony maja dobre klucze. 1 strona wysyla dane zaszyfrowane nowym kluczem, 2ga strona je dostaje, reszyfruje i odsyla. Jak sie zgadza, wszsytko ok. Ta strona inicjujaca moze byc klient, bo to mu zalezy. Zalozmy ze ktos jest posrodku:
    - klient wysyla dane
    - hacker je przechwytuje, ale nie jest w stanie zdeszyfrowac. Nie moze ich podmienic z oczywistych przyczyn

    Jest jeszcze kwestia pozniejszej komunikacji, mozna wstrzykiwac pakiety z poprzednich sesji wiedzac co znacza (np wiesz ze pierwszy pakiet to jakas komenda resetujaca system albo cos w ten desen). Kazdy pakiet moze miec jakies dane dolaczane dynamicznie, ktore 2ga strona bedzie sprawdzac. Albo podpis (szyfrogram checksumy), tyle ze wtedy to bedzie masakra jesli chodzi o lacze. Lepiej wyliczyc czeksume tych danych kontrolnych wyslanych krok wczesniej, i ja dolaczac do kazdego pakietu. To ograniczy powtarzalnosc pakietu. Do czeksumy mozna jeszcze dolaczyc timestamp, i niech pakiet bedzie wazny tylko kilka minut, wtedy to juz chyba nic nie bedzie mozna temu zrobic.

  10. #10
    Zarejestrowany
    Jul 2008
    Skąd
    /dev/random
    Postów
    556

    Domyślnie

    kurde okropnie kombinujesz a takie przekombinowane projekty najczesciej wykladaja sie na implementacji i tam sa bledy pozwalajace je zlamac.

    Zrob sobie twofisha + wymiane kluczy do niego po rsa... czesto zmieniaj klucze twofisha jak i zmieniaj klucze RSA... Calosc podpisujesz certyfikatami.

    Obecnie masz silne procki i mozesz sobie pozwolic na taka zabawe w generowanie kluczy Nie ma szans by ktos to rozwalil w rozsadnym czasie...

    Do tego uzyj gotowego i sprawdzonego rozwiazania bo np. napisanie bigintow to naprawde nie latwe zadanie, a nawet te "sprawdzone" moga w pewnych okolicznosciach zle dzialac.

    Po prostu nie ma co kombinowac bo wszystko jest do zlamania, jednak jesli czas zlamania systemu jest akceptowalny to takie rozwiazanie stosujesz. Tak sie podchodzi do sprawy w kryptografii...

    Do tego jest tutaj istotnych kilka innych problemow ktorych nie uwzgledniasz bo skupiasz sie tylko na aspekcie samej transmisji danych Generalnie powiem tak nie wymyslisz nic lepszego niz zostalo do tej pory wymyslone
    Ostatnio edytowane przez tom : 12-27-2010 - 10:51
    --
    ToM's Super Fix IT "No Fucking Problem"

Strona 1 z 2 12 OstatniOstatni

Zasady Postowania

  • Nie możesz zakładać nowych tematów
  • Nie możesz pisać wiadomości
  • Nie możesz dodawać załączników
  • Nie możesz edytować swoich postów
  •  
Subskrybuj