Szukam jakiegoś niezbyt drogiego modułu, który umożliwiłby mi wrzucenie
kilku danych na serwer za pośrednictwem Internetu. Ponieważ klient
będzie musiał "przedstawić się" serwerowi i w jakiś sposób udowodnić, że
jest tym za kogo się podaje, niezbędne będzie zastosowanie jakiegoś
szyfrowania.
Moduły WiFi ESP8266 posiadają możliwość zestawienia połączenie SSL (nie
wiem, czy ta funkcjonalność została już zaimplementowana w firmware z
komendami AT, ale na pewno jest dostępna w SDK). Czy któryś z
popularnych modułów został wyposażony w taką funkcję.

I jeśli już o tym mówimy (możliwe zresztą, że już kiedyś o to pytałem)
to czy istnieje moduł, na który można by napisać własny soft, podobnie
jak w przypadku ESP? Wiem, że kiedyś dostępne były moduły z
interpreterem jakiegoś języka skryptowego. Nokia chyba wypuściła coś, do
czego można było napisać kod w języku wzorowanym na Javie. Mi jednak
chodzi o podejście zbliżone do tego, które zostało przyjęte przez
twórców ESP - udostępnione SDK i możliwość kompilowania własnego
firmware'u dla modułu...
Jeśli potrzebuję SPI, I2C i kilku pinów GPIO, byłoby fajnie, gdyby dało
się wyrzucić MCU z projektu i wszystko zrobić na samym module.

do góry

On Thu, 30 Jul 2015 11:15:50 +0200, Atlantis <m...@w...pl>
wrote:
> Wiem, że kiedyś dostępne były moduły z
> interpreterem jakiegoś języka skryptowego. Nokia chyba wypuściła
coś, do
> czego można było napisać kod w języku wzorowanym na Javie. Mi jednak
> chodzi o podejście zbliżone do tego, które zostało przyjęte przez
> twórców ESP - udostępnione SDK i możliwość kompilowania własnego
> firmware'u dla modułu...

Czemu uważasz, że moduł z interpreterem (właściwie kompilatorem) np.
pythona jest gorszy od "firrmwaru", gdzie widzisz przeszkadzającą Ci
różnicę?
Drugie pytanie :dlaczego uwazasz, że prościej użyć skomplikowany
moduł z SSL zamiast użyć prosty moduł z jakimś łatwą i szybką
wnimplementacji kryptografią i prostą aplikacją po stronie serwera?

--
Marek

do góry

W dniu 2015-07-30 o 11:48, Marek pisze:

> Czemu uważasz, że moduł z interpreterem (właściwie kompilatorem) np.
> pythona jest gorszy od "firrmwaru", gdzie widzisz przeszkadzającą Ci
> różnicę?

Kod w formie kompilowanej będzie pewnie wykonywał się szybciej od
interpretowanego "w locie". Poza tym w grę wchodzi kwestia bardziej
wydajnego zagospodarowania dostępnych zasobów - widać to chociażby na
przykładzie ESP. Jednak więcej można upchnąć w kompilowanym kodzie C,
niż interpretowanym skrypcie LUA.


> Drugie pytanie :dlaczego uwazasz, że prościej użyć skomplikowany
> moduł z SSL zamiast użyć prosty moduł z jakimś łatwą i szybką
> wnimplementacji kryptografią i prostą aplikacją po stronie serwera?

SSL to jednak pewien przyjęty standard i jako taki będzie pewnie jeszcze
łatwiejszy z implementacji. W końcu pod Linuksem są dostępne odpowiednie
biblioteki.
Poza tym nie chodziło mi o to, żeby samemu pisać implementację SSL i
skompilować ją razem z nowym FW dla modułu. O kwestię kompilacji pytałem
przy okazji - po prostu miło byłoby, gdyby dało się (jak w przypadku
ESP) zrezygnować z zewnętrznego MCU i wszystkie operacje wykonywać
wewnątrz samego modułu. Oczywiście w takim wypadku pytanie o SSL
pozostaje nadal aktualne - zwyczajnie liczę, że opdowiednie funkcje
znalazłyby się w dołączonych bibliotekach - znów jak w przypadku ESP,

do góry

On Thu, 30 Jul 2015 12:21:53 +0200, Atlantis <m...@w...pl>
wrote:
> Kod w formie kompilowanej będzie pewnie wykonywał się szybciej od
> interpretowanego "w locie". Poza tym w grę wchodzi kwestia bardziej
> wydajnego zagospodarowania dostępnych zasobów - widać to chociażby
na
> przykładzie ESP. Jednak więcej można upchnąć w kompilowanym kodzie
C,
> niż interpretowanym skrypcie LUA.

Dobrze, że napisaleś " pewnie". Python np. w telitach *jest*
kompilowany do formy binarnej, podobnie jak java czy perl. Po
wrzuceniu skryptu jest kompilowany, przez co pierwsze uruchomienie
trwa długo, później już uruchamainy jest skompilowany skrypt, który
odpala szybko. Nie ustępuje to w praktyce (aby się tym przejmować)
temu co uważasz za "skompilowane wykonywane szybciej". Natomiast
jest wygodne w developingu: nie trzeba nic kompilować, kod źródłowy
bezpośrednio uploaduje się na moduł (lub moduł sam sobie go piobiera
np. z FTP).

> SSL to jednak pewien przyjęty standard i jako taki będzie pewnie
jeszcze
> łatwiejszy z implementacji. W końcu pod Linuksem są dostępne
odpowiednie
> biblioteki.
> Poza tym nie chodziło mi o to, żeby samemu pisać implementację SSL i
> skompilować ją razem z nowym FW dla modułu. O kwestię kompilacji
pytałem
> przy okazji - po prostu miło byłoby, gdyby dało się (jak w przypadku
> ESP) zrezygnować z zewnętrznego MCU i wszystkie operacje wykonywać
> wewnątrz samego modułu. Oczywiście w takim wypadku pytanie o SSL
> pozostaje nadal aktualne - zwyczajnie liczę, że opdowiednie funkcje
> znalazłyby się w dołączonych bibliotekach - znów jak w przypadku
ESP,

Ale konkretnie do czego potrzebny Ci SSL? Do przesłania kilku bajtów
raz na jakiś czas statusu z jakiegos czujnika (wnioskuję to zTwojej
historii ostatnich projektów publikowanych tu lub na elektrodzie).
Wcześniej piszesz, że chcesz wydajnie gospodarować zasoby a
proponujesz SSL, który jest overkillem dla małych mcu? No może trochę
przesadzam, ale wiadomo o co chodzi, kupujesz cały browar aby napić
się okazjonalnie piwa.

--
Marek

do góry

W dniu 2015-07-30 o 12:40, Marek pisze:

> Ale konkretnie do czego potrzebny Ci SSL? Do przesłania kilku bajtów raz
> na jakiś czas statusu z jakiegos czujnika (wnioskuję to zTwojej historii
> ostatnich projektów publikowanych tu lub na elektrodzie). Wcześniej
> piszesz, że chcesz wydajnie gospodarować zasoby a proponujesz SSL, który
> jest overkillem dla małych mcu? No może trochę przesadzam, ale wiadomo o
> co chodzi, kupujesz cały browar aby napić się okazjonalnie piwa.

No dobrze. Jednak SSL jest powszechnie przyjętym standardem, w
przeciwieństwie do wszelkich "lekkich" alternatyw. Po stronie serwera
mogę zaprząc do pracy jakiegoś gotowe narzędzie.
Poza tym zakładam, że moduł GSM będzie miał w sobie 32bitowy MCU, zdolny
do poradzenia sobie z takim zadaniem.

do góry

On Thu, 30 Jul 2015 14:30:57 +0200, Atlantis <m...@w...pl>
wrote:
> No dobrze. Jednak SSL jest powszechnie przyjętym standardem, w
> przeciwieństwie do wszelkich "lekkich" alternatyw. Po stronie
serwera
> mogę zaprząc do pracy jakiegoś gotowe narzędzie.
> Poza tym zakładam, że moduł GSM będzie miał w sobie 32bitowy MCU,
zdolny
> do poradzenia sobie z takim zadaniem.

Pytanie czy na pewno potrzebny Ci serwer ;-).

--
Marek

do góry

W dniu 2015-07-30 o 15:54, Marek pisze:

> Pytanie czy na pewno potrzebny Ci serwer ;-).

Coś przecież będzie musiało te dane odbierać i zapisywać w jakiejś
bazie. Ponieważ w tym wypadku dane będą leciały przez publiczny
Internet, a nie lokalną sieć schowaną za NAT-em, chciałbym zabezpieczyć
się przed możliwością podsłuchania transmisji i spreparowania fałszywki.
Wiem, że tutaj niby można zastosować jakiś prosty algorytm i z góry
ustalony klucz, "miksowany" z synchronizowanym RTC. Ale (jak już
mówiłem) SSL to standard i gdyby na rynku był dostępny obsługujący go
moduł, to praktyczne miałbym gotowca. A obsługa chyba nie jest zbyt
skomplikowana, skoro udało się ją zaimplementować w ESP (z
zastrzeżeniem, że możliwe jest otwarcie tylko jednego połączenia na raz).

do góry

W dniu 2015-07-30 o 11:15, Atlantis pisze:
> Szukam jakiegoś niezbyt drogiego modułu, który umożliwiłby mi wrzucenie
> kilku danych na serwer za pośrednictwem Internetu. Ponieważ klient
> będzie musiał "przedstawić się" serwerowi i w jakiś sposób udowodnić, że
> jest tym za kogo się podaje, niezbędne będzie zastosowanie jakiegoś
> szyfrowania.

SSL służy raczej do weryfikacji tożsamości serwera.
Jeśli klient ma jedynie przesłać jakieś informacje na serwer to do
danych dołącz czas lub ciąg losowy i zaszyfruj wszytko np. algorytmem
AES128.

Jeśli chcesz zweryfikować klienta a nie dane to wyślij mu losowy ciąg.
Niech on go zaszyfruje np. algorytmem AES128 i odeśle. Jest to bardzo
prosta i skuteczna metoda. Wymaga niewielkiej mocy obliczeniowej.

Paweł

do góry

On Thu, 30 Jul 2015 22:59:54 +0200, Pawel2420 <z...@n...pl>
wrote:
> SSL służy raczej do weryfikacji tożsamości serwera.

No właśnie Atlantis nie napisał jak chce weryfikować tożsamość
kliena, bo jeśli chce użyć SSL to rozumiem, że weryfikacja poprzez
certyfikaty klienta (jaki moduł to wspiera??). Chyba nie chodzi mu o
metodę user/hasło do serwisu dostępnego po ssl....

--
Marek

do góry

W dniu 2015-07-30 o 23:39, Marek pisze:
> On Thu, 30 Jul 2015 22:59:54 +0200, Pawel2420 <z...@n...pl> wrote:
>> SSL służy raczej do weryfikacji tożsamości serwera.
>
> No właśnie Atlantis nie napisał jak chce weryfikować tożsamość kliena,
> bo jeśli chce użyć SSL to rozumiem, że weryfikacja poprzez certyfikaty
> klienta (jaki moduł to wspiera??). Chyba nie chodzi mu o metodę
> user/hasło do serwisu dostępnego po ssl....
>
Moim zdaniem Atlantis polegnie implementując sprawdzanie certyfikatów w
modemie. To jest jednak jego urządzenie i jego decyzja.

Paweł

do góry