witam.

Mam dość ciekawy problem do rowiązania. Temat nie jest aż tak łatwy i oczywisty tak więc chce się was poradzić.

Mam urządzenia, które wysyłają mi dane do serwera poprzez POST. Dane te są identyczne i przesyłane sa jawnie - bo takie musza być aby serwer wiedział co dostaje. Ważną kwestią takiej komunikacji jest zabezpieczenie przed osobami, które podsłuchałyby ruch sieciowy i wysłaly np te same dane ponownie, lub ze zmienionymi parametrami. Jak sie przed tym chronić ? Miałem już kilka pomysłów, ale każde z nich jest na swój problematyczny. Wpadłem tez na pewne rozwiązanie, które oferuje kryptografia RSA, ale nie za bardzo wiem jak z tego korzystać a tym bardziej moze być to problem nie dla mnie a dla programistów C++ którzy programują te urzadzenia. Odrazu wspomne własnie o tym c++. Przy programowaniu niskopoziomowym, implementacja nawet takich algorytmów jak md5 nie jest taka łatwa a w niektórych wypadkach wymaga zastosowania np lepszego procesora w urzadzeniu co wiąze sie z kosztami. szukam jak najprostrzego i najlepszego rozwiązania, macie moze już w tym jakieś doświadczenie ?

Hmmm.... moze sie myle - ale chyba miedzy innymi od tego jest HTTPS

zgadza sie, to pierwsze o czym pomyślałem. Zapomniałem o tym napisać.

Wytłumaczcie mi, protokuł SSL trzeba jakos implemetować ? czy wystarczy wskazać dla danych post że maja isc pod adres https://strona.pl i tylko tyle ? Jak to jest z wydajnościa i faktycznym bezpieczeństwem w takim wypadku ?

edit:

chodzi o to czy z poziomu urzadzenia nie bedzie wymagana jakas specjalna implementacja dla wysyłanych danych i na odwrót.
Taki zaszyfrowany przekaz i tak można podsłuchać ? Co wtedy jesli nawet te zaszyfrowane dane ktos skopiuje i wyśle jeszcze raz do serwera ? skrypt znowu sie wykona ?

Nie wystarczy dodac tylko 's' na koncu protokolu. Jest to troche bardziej skomplikowane. Poczytaj w sieci - jest bardzo duzo tutoriali. Jezeli chodzi o bezpieczenstwo to z tego co mi sie wydaje to wlasnie po to powstal ten protokol

no dobra, szukam w necie informacji i nie za bardzo do mnie przemawiają... po to założyłem temat.

jakie mam wątpliwosci:

-czy szyfrowanie SSL nie zamuli łącza ? urzadzeń jest sporo i wysyłaja informacje co kilka sekund do serwera.
-powtórzę : "Taki zaszyfrowany przekaz i tak można podsłuchać ? Co wtedy jesli nawet te zaszyfrowane dane ktos skopiuje i wyśle jeszcze raz do serwera ? skrypt znowu sie wykona ?"
-co to znaczy, ze "Nie wystarczy dodac tylko 's' na koncu protokolu". Wiem, że certyfikat trzeeba wykupić i go zainstalować i wtedy dopiero działa. W takim razie jak wysyła się takie dane ?

a tak po za SSL, jak mozna byłoby jeszzce zabezpieczyć te dane ? Myślałem o wprowadzeniu jakiegoś losowego tokena. Wszystkie wysyłane dane oczywiście byłyby jawne ale + posiadały zmienną z tokenem. Urzadzenie i serwer miałoby liste stałych tokenów -np 1000. Serwer pobierając dane sprawdzałby token na swojej liście czy taki istnieje i sprawdzał dodatkowo jeszcze kiedy ostatni raz został uzyty - jesli np w cigu 10 minut to przerywa akcje. Ale tez nie wydaje mi sie to idalne... cholera wie jak to zabezpiczyć : | Mam za zadanie nie tyle co ukryć dane przed przechwyceniem - bo moga być jawne, ale musze zabepieczyć to tak aby uniemożliwić wykonanie 2 razy tej samej operacji, lub z celowo spreparowanymi danymi

Z tego co sie orientuje to wiekszy naklad pracy bedzie po stronie serwera bo musi to rozkodowac - ale nie sadze zeby to mialo stanowic problem


Chodzilo mi wlasnie o to ze trzeba miec certa.


czy te dane beda przesylane przez zalogowanych userow? jezeli nie, to czy mozesz zrobic im logowanie ?

hehe, nie czytasz chyba moich postów ;p

w żadnym momencie nie napisałem, że chodzi o jakieś logowanie czy uzytkowników. Caly czas pisze o tym, że te dane będa wysyłac cyklicznie urządzenia (pomiarowe) na mój serwer. Urządzenie wysyła dane pomiarowe metodą POST a serwer je odbiera i zapisuje. Dane musza być jawne - tak aby serwer mógł je rozponać -tak więc mieszanie odpada-zresztą to bez sensu. Chce uchronić się przed podłsuchem sieci, tak aby ktoś nie wysyłał mi spejcalnie 2 razy tego samego żadania. Chce aby każda taka wysyłka danych była tylko jednorazowa, ktorej nie wysle 2 raz na serwer niezależnie od tego jak spreparuje dane.

Tak po prawdzie mówiąc, nie ważne jak się zabezpieczysz, jeżeli ktoś będzie chciał i tak Ci zaszkodzi
Może port knocking?

czytam twoje posty bardzo dokladnie


wczesniej nigdzie nie napisales ze sa to urzadzenia pomiarowe. dla mnie urzadzenia (klienckie) w technologii webowej to w wiekszosci komuptery, palmtopy, telefony... zepsula mi sie czarodziejska kula i nie mialem jak odgadnac ze chodzi o urzadzenia pomiarowe

Na razie nic wiecej mi nie przychodzi do glowy...

To zrób tak, aby nie były jawne. Koduj je na podstawie klucza, które będzie znało tylko urządzenie i serwer. Dane przesyłane nie będą ich w sobie zawierać. Jeśli możesz wysłać je jako POST, to zakładam, że nie jest to cały Pan Tadeusz, więc implementacja prostego szyfrowania obustronnego nie będzie stanowić problemu.

naprawde nie ma innego wyjścia jak ssl ? coś nie chce mi sie wierzyć... to, że na wszystko znajdzie się hak to doskonale o tym wiem. Nie szukam idealnego rozwiązania, tylko takiego, które przynajmiej w jakimś stopniu utrudni/zniechęci ciekawskich przed kombinowaniem.

port knocking odpada. Urzadzenia nie mają stałych adresów a w dodatku nie łatwo byłoby to konrolowac. te urządzniea kupują ludzie, gdyby to było tylko dla mnie to pomysł nie głupi

!*!

masz jakąs propozycje ? jak zrobić takie kodowanie ? może sa jakieś gotowe ciekawe skrypty ? czytałem o RSA, ale tutaj może być problem z implementacją po stronie samego urzadzenia tak więc odpada.

Zrób to tak jak w PHP

Urządzenia zna klucz/sól na jej podstawie szyfruje dane i wysyła do serwera. Serwer wie jaki to był klucz/sól i odkodowuje dane.

plusy? klucz/sól nie są jawne, przesyłasz tylko dane do odszyfrowania.
wady? klucz/sól są stałe, chyba że obmyślisz sposób, aby były zmienne, choć to może być kłopotliwe.

To najprostszy sposób. A to czym je szyfrować, to już zależy od programistów C, oni już będą wiedzieli co nie obciąży urządzenia, to nawet nie muszą być znane sposoby, mogą napisać coś własnego. Chodzi o to aby klucz nigdy nie był przesyłany, a siedział w pamięci urządzenia.

no dobra, wiem na czym to polega jeśli chodzi o szyfrowanie jednostronne. Porównuje wtedy hashe czy sie z sobą zgadzają. Naprawde rozumiem idee i jest ona jak dla mnie w sam raz, ale jak jeszcze odkodowac te dane tak abym mógł je odczytać i zapisac na serwerze? Znasz jakis nawet najprostrzy sposób ? Jak zmieszac te dane tak aby później je odczytać ?

EDIT:

coś wyszukałem w sieci:

$myVarIWantToEncodeAndDecode

Define key (salt, broth etc..): $key = "#&$sdfdfs789fs7d";

To encode:

$encoded = base64_encode(mcrypt_encrypt(MCRYPT_RIJNDAEL_256, md5($key), $myVarIWantToEncodeAndDecode, MCRYPT_MODE_CBC, md5(md5($key))));

To decode:

$decoded = rtrim(mcrypt_decrypt(MCRYPT_RIJNDAEL_256, md5($key), base64_decode($encoded), MCRYPT_MODE_CBC, md5(md5($key))), "\0");

jak sądzisz? coś mi się wydaje że pod C może być to problem...

Dlatego napisałem o kodowaniu/szyfrowaniu, a nie hashowaniu. Załóżmy że zrobisz to tak:

[PHP] pobierz, plaintext 
$text = 'tajne dane';
$salt = 'WER322ef$$@@'; // to jest klucz który ma znać urządzenie, serwer i nikt więcej ;)
 
$a = base64_encode($text.$salt); // tekst zakodowany
 
$res = base64_decode($a.$salt) // tekst odkodowany
[PHP] pobierz, plaintext 

A co bedzie jak ktos skopiuje te zakodowane dane i wysle zakodowane jeszcze raz ? Nie musi znac ani klucza ani soli. No chyba ze zle zrozumialem idee, ale moim zdaniem to wsyztko jedno czy beda zakodowane czy nie.

To inna bajka. Nie wiem jakie to dane. System powinien sprawdzać skąd przyszły pomiary i czy już takie istnieją. Powyższe rozwiązanie zapobiega ich manipulacji, bo nawet jak je zakodujesz, będą błędne, nie znając klucza.

Z tego co zrozumialem to problemem nie jest podmiana danych - tylko mozliwosc ich przechwycenia i przeslania ich ponownie.

Ghost_78

sens ma taki, że nikt mi nie będzie manipulowąc danymi, a to juz duzy krok ku bezpieczeństwu.

Z ponowną wysylka to racja, ciągle pozostaje ten problem, ale nie jest już on aż tak trudny do rozwiązania. Każda poracja danych będzie zawierać miedzyinnymi date. Pomysł mam taki:

kazde urzadzenie ma swoj cache w unikalnym pliku txt. Zapisywane sa w nim dane pomiarowe z ostatniej godziny - reszta archiwizuje się do bazy danych. Jesli ktoś bedzie chciał przesłac to samo 2 razy, to sprawdzam, czy w tym pliku cache urzadzenia, istnieje juz taka data. Jesli tak to do widzenia : ) jesli dane bedą wysyłane w zaszyfrowanej postaci, to nie jest możliwe aby w zaszyfrowanym ciągu podmienić tak literki aby akurat zmienić date na poźniejszą. Dzięki za pomoc : )

To nie problem. W przesyłanych danych może być czas ich wysłania. Urządzenie łączy się z serwerem w celu pobrania godziny, ten odnotowuje ten fakt, sprawdzając czy inny klucz się zgadza jeśli tak odsyła jakieś dane w postaci innego klucza do urządzenia a te je weryfikuje, jeśli się zgadza, zapisuje godzinę w danych które mają trafić do bazy i wysyła je do serwera, ten ponownie sprawdza czas z danymi i tym co wcześniej pobrało urządzenie.

Jeśli ktoś przejmie informacje przesyłane do serwera, to nic z nimi nie zrobi, ponieważ czas ich wysłania nie będzie się zgadzał, a wątpię żeby ktoś pobrał w tej samej sekundzie dane i w tej samej je wysłał.

Trochę poplątane, ale da radę przy ograniczonych możliwościach i to ma sens jeśli autor wątku nie wypuszcza na rynek iPhona 8 ;)

!*!

Twoj skrypt coś nie tak działa...

$a = base64_encode($text2.$salt2); // tekst zakodowany

$res = base64_decode($a);

jeśli dla res wywale salt to i tak pokaze mi zakodowaną treść

Chodziło o to, abyś robił to w podobny sposób z solą, base64+sól trochę przestrzeliłem ;) W PHP za pomocą crypt, mcrypt, ale w C zapewne coś zjadą podobnego.

http://blog.justin.kelly.org.au/simple-mcr...unctions-for-p/

itd.

Oprócz szyfrowania danych w całości, możesz też w każdym poście dołączać tzw. sumę kontrolną tych danych (generowaną w jakiś sposób na podstawie daty, id urządzenia, unikatowego klucza itp). Po stronie serwera robisz to samo, obliczasz sumę kontrolną i porównujesz z przesłaną. Algorytm obliczania sumy kontrolnej musisz uzgodnić z programistami C/C++ bo to zależy od urządzenia, ale nawet układy Atmel AVR poradzą sobie np. z md5.

udało mi się już w php napisać fajny skrypt. Dzięki az naprowadzenie : ) Ciekawe własnie tylko czy chłopaki od C poradzą sobie z md5,base64 i mcrypt. Z tego co widziałem jak wygląda takie programowanie niskopoziomowe, to będa mieć porpost przzesrane... ciekawe też czy sprzęt wydoli

A nie prościej: kluczem ?

tak, czytałem o tym RSA. Tak czy siak jeśli szyfruje wszystkie dane to zabawa w klucze prywatne i publiczne nie jest potrzebne. Idea z jenym kluczem do szyfrowania dla urzadzenia i serwera jest dla mnie super : ) nie ma opcji tego złamać, bo tak naprawde klucz można bedzie wykraść tylko poprzez włamanie na serwer. W dodatku takie coś rozwiązje moje wszystkie problemy i mogę spac spokojnie : )

temat do zamknicia, jeszcze raz dzieki za pomoc : )

Problem rozwiązany, ale podam też inne rozwiązanie. Zobacz na jakiej zasadzie dane zabezpieczają m.in. systemy płatności. Masz jakieś dane do wysłania POSTem:

[PHP] pobierz, plaintext 
$post = array(
	'name' => 'Jan',
	'surname' => 'Kowalski'
);
[PHP] pobierz, plaintext 

Dokładasz do nich timestamp, czyli czas kiedy zostają przesłane:

[PHP] pobierz, plaintext 
$post['ts'] = time();
[PHP] pobierz, plaintext 

Na postawie tablicy danych budujesz sumę kontrolną, np.:

[PHP] pobierz, plaintext 
$post['checksum'] = md5(http_build_query($post));
[PHP] pobierz, plaintext 

Takiego posta przesyłasz do serwera. Po stronie serwera sprawdzasz czy przesłana suma kontrolna odpowiada obliczonej przez Ciebie (z pominięciem parametru checksum). Dodatkowo sprawdzasz wartość przesłanego znacznika czasu (czy pochodzi np. sprzed X sekund). Jeśli wszystko się zgadza - przetwarzasz żądanie. Jeśli ktoś przechwyci dane, zmodyfikuje i prześle ponownie to zatrzyma się na obliczaniu sumy kontrolnej. Jeśli ich nie zmodyfikuje, ale prześle je po upływie X sekund od momentu utworzenia znacznika czasu - zatrzyma się na sprawdzaniu znacznika. Jedyne co może zrobić to przesłać je ponownie w przeciągu X sekund. Wówczas wyjściem byłoby tworzenie w bazie tokenów pozwalających na wysłanie danych i usuwanie ich po przesłaniu danych.