> Oczywiście zdaje sobie sprawę, że czegoś takiego nie zrobię na AVR-ach,
chiach...

Z ciekawości zaintsalowałem najnowszy nut/os 5.2 i w konfiguratorze dla
atmega128 są opcje odnośnie TLS/SSL.
Czy działa? Nie wiem.

Paweł

do góry

On 02/06/2015 05:57 PM, Atlantis wrote:
> Bardziej chodzi mi o komunikację w drugą stronę. Ktoś rozgryzie
> szyfrowanie, przyjrzy się protokołowi i będzie mógł wysyłać polecenie
> zgaszania/zapalenia światła albo podszyć się pod czujnik i wysłać
> serwerowi fałszywą informacją o jakimś zdarzeniu.
>
> Tego jednak wolałbym uniknąć. ;)

To wystarczy Ci wysyłać komendy i zwracać wartości podobnie jak w Keeloq
czy innych tego typu protokołach.
Czyli komenda/wartość + numerek zawsze zwiększający się + suma kontrolna
z całości i znanego tylko urządzeniom klucza. Wystarczająca obrona przed
'replay' jak i grzebaczami. Może nie zabezpieczy przed MITM (jeżeli
będzie to tylko transmisja jednostronna), ale aż tak paranoiczny chyba
nie jesteś? :-) Przy dwustronnej wystarczy, że serwer doda jeszcze
zmienny token, który trzeba odesłać razem z podpisanymi danymi. Fakt,
ktoś może to sobie słuchać, ale nie będzie w stanie wstrzyknąć swoich
danych/rozkazów.
A md5, sha1 czy inną funkcję skrótu, to sobie spokojnie na każdym
mikrokontrolerze policzysz.


Pozdrawiam

Marek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg

do góry

On 02/06/2015 07:57 PM, Marek Wodzinski wrote:
> Czyli komenda/wartość + numerek zawsze zwiększający się + suma kontrolna
> z całości i znanego tylko urządzeniom klucza. Wystarczająca obrona przed
> 'replay' jak i grzebaczami. Może nie zabezpieczy przed MITM (jeżeli
> będzie to tylko transmisja jednostronna)

Dokłądniej to MITM i tak będzie ograniczone do 'zgubienia' ramki i
ewentualnego jej odtworzenia w dowolnym dla atakującego momencie o ile
będzie blokował dalszą komunikację. Jak dla mnie w tym zastosowaniu
takie zachowanie jest bezcelowe. Inaczej jest z samochodami, gdzie po
zapamiętaniu takiego kodu można spróbować go otworzyć po odejściu
właściciela i ma to jakiś sens i wartość.


Pozdrawiam

Marek
--
"If you want something done...do yourself!"
Jean-Baptiste Emmanuel Zorg

do góry

On Fri, 06 Feb 2015 17:57:56 +0100, Atlantis <m...@w...pl>
wrote:
> Bardziej chodzi mi o komunikację w drugą stronę. Ktoś rozgryzie
> szyfrowanie, przyjrzy się protokołowi i będzie mógł wysyłać
polecenie

Jeśli zastosujesz aes lub xtea prawidłowo, nieudostępnisz przez
przypadek kluczy zapominając zablokować mcu przed odczytem firmwaru
to tylko atak z tekstem jawnym daje niezerową (ale na prawdę mało
prawdopodobną) szansę na złamanie. Myślisz, że ktoś będzie tak
zdeterminiwany by podszyć się pod Twoje czujniki? :)

--
Marek

do góry

On Fri, 06 Feb 2015 17:57:56 +0100, Atlantis <m...@w...pl>
wrote:
> Właściwie jaki MCU to należałoby uznać za absolutne minimum do w
miarę
> znośnej obsługi SSL-a?

Na upartego może być 8bit pic, stos mchp nie wyklucza w nagłówkach
włączenie ssl dla 8bitowca. Z tym, że na pewno trzeba wybrać mcu z
128kB flash bo sam stos z ssl zajmie z 80kB minimum.
Oczywiście nie ma co się nadymać, jednak 32 bitowy daje komfort
nieporównywalny z 8 bitowcem.

--
Marek

do góry

W dniu 2015-02-06 o 11:23, Atlantis pisze:
> Rozgryzam ostatnio wykorzystanie SSL-a przy komunikacji za pomocą
> socketów na Linuksie. Domyślnie ma to służyć do skomunikowania daemona,
> pośredniczącego w komunikacji pomiędzy moimi "zabawkami" na
> mikrokontrolerach i androidową aplikacją.
>
> Myślę jednak, że dobrze by było, gdyby urządzenie pracujące poza moją
> domową siecią (i przesyłające dane przy pomocy publicznego Internetu)
> również mogło przesyłać dane w sposób bezpieczny. Mam tutaj na myśli np.
> system nadzoru działki, połączony ze stacją pogodową i korzystający z
> modułu GSM.
>
> Oczywiście zdaje sobie sprawę, że czegoś takiego nie zrobię na AVR-ach,
> ale pewnie na jakimś STM32 już by się dało. W końcu niektóre z tych
> układów oferują sprzętową obsługę popularnych standardów szyfrowania.
> Istnieje może jakaś w miarę łatwa w obsłudze (i najlepiej darmowa dla
> niekomercyjnych zastosowań), która pozwoliłaby mi zastosować ten
> standard w swoim projekcie? Ktoś miał kiedyś do czynienia z czymś takim?
> Będę potrzebował jakiegoś RTOS-a?
>

PolarSSL + STM32:
RTOS nie jest potrzebny
http://www.st.com/web/catalog/tools/FM147/CL1794/SC9
61/SS1743/LN1734/PF257893
http://hobbymc.blogspot.com/2011/02/stm32-discovery-
porting-polar-ssl.html
Mieści się w pamięciach wewnętrznych (RAM+FLASH)

--
Michał

do góry