Niedawno zabrałem się za eksperymenty z obsługą Ethernetu/Internetu z poziomu mikrokontrolerów AVR. Na razie zbudowałem na własne potrzeby prostą płytkę prototypową z ATmegą328 i ENC28J60 i zrobiłem na niej kilka przykładów. W tej chwili myślę o trochę bardziej użytecznych projektach. Pierwszym z nich ma być sieciowa stacja pogodowa, drugim system zdalnego sterowania oświetleniem (i nie tylko).
I właśnie o tym drugim projekcie chciałem porozmawiać. Generalnie koncepcja jest taka, że w pierwszym rzędzie zbuduję urządzenie będące głównym węzłem instalacji. Będzie mogło pracować w pełni samodzielnie, przyjmując polecenia w postaci pakietów UDP. Jednak możliwe będzie podpięcie kolejnych modułów za pośrednictwem magistrali CAN. Dzięki temu całość będzie widziana z sieci lokalnej jako jedno urządzenie, a nie zespół rozproszonych sterowników z własnymi numerami IP. Oczywiście system będzie można zaadaptować także do innych celów (inteligentna instalacja dzwonkowa, alarmowa itp.).

Z uwagi na to chciałbym w jakiś sposób zabezpieczyć komunikację z tym urządzeniem, aby ustrzec się przed możliwością analizy przechwyconych pakietów. Obiły mi się o uszy informacje o bibliotekach do obsługi AES na ośmiobitowych AVR-ach. Czy ktoś z Was miał z tym jakieś doświadczenie? Jakie zasoby sprzętowe są potrzebne w do szyfrowania informacji tym (lub innym) systemem? W tym głównym węźle planuję zastosować AT90CAN128, a więc będę miał do dyspozycji 128kB pamięci flash i 4kB RAM.

W 100% zgadzam się z przedmówcą, Raspberry Pi jest w tym wypadku świetnym rozwiązaniem. Sam mam u siebie prosty system sterowania m.in oświetleniem i monitorowania temperatury w pokoju (funkcjonalność mogę rozszerzać dowolnie). Urządzenia połączone są w ten sposób:
AVR <---> Raspberry Pi <---> Router domowy <---> Internet.

Na AVR realizuję takie rzeczy jak sterowanie pokojem czy pomiar temperatury, dane przesyłane są po UART z/do raspberry, które jest jednocześnie serwerem (dla lokalnej sieci domowej) oraz klientem mojego serwera www (globalnego). Dzięki temu będąc poza domem mogę np. sprawdzić temperaturę, a po lokalnym WiFi sterować oświetleniem; mogę to też zrobić spoza mojej sieci, ale mam wtedy opóźnienie do 2 minut - taki jest interwał między połączeniem RPi z moim globalnym serwerem.
Oczywiście oświetlenie i temperatura to takie najprostsze przykłady.

Rozwiązanie z RPi także daje tą zaletę, że system jest widziany jako pojedyncze urządzenie z własnym IP.

Raspberry Pi (albo coś podobnego) z cała pewnością będzie miało jakiś udział w tym projekcie, ale dopiero wtedy, gdy w przyszłości zdecyduję się dodać WebUI. Nic nie stoi tu na przeszkodzie, bo nie ma znaczenia skąd system będzie odbierał komendy w pakietach UDP. Dodatkowe szyfrowanie na pewno nie zaszkodzi, nawet jeśli ta część komunikacji będzie się odbywała wewnątrz sieci lokalnej.

W samym kodzie sterownika tak czy inaczej umieszczę zabezpieczenie przez zbyt szybkim przełączaniem stanu triaków. Komenda nie będzie wykonywana, jeśli timer ustawiony podczas poprzedniej zmiany nie zdąży się wyzerować. Tak więc nawet gdyby ktoś rozgryzł komunikację i ostrzelał mój system pakietami, to i tak nie spowoduje to żadnej anomalii - co najwyżej światło będzie gasło i włączało się z częstotliwością zależną od timera, a to da mi informację o tym, co się dzieje.

Co do DDoS, to nawet RPi może sobie nie poradzić z filrowaniem tego całego ruchu. Tow końcu bardzo mały komputerek...

Jak już mówiłem - jeśli wystawię system do publicznego internetu, to raczej właśnie za pośrednictwem jakiegoś pośredniczącego serwera, a nie bezpośrednio, przez przekierowanie na NAT. Pakiety UDP będzie można bezpośrednio przesyłać z wnętrza sieci lokalnej. Ich szyfrowanie to dodatkowe zabezpieczenie (+ rozwiązanie na czas testów) a nie alternatywa.

Jak chcesz zainteresuj się szyfrem Vigenere’a, czy też tzw. szyframi kroczącymi , obydwa rozwiązania są łatwe w implementacji , a i poziom szyfrowania ustala tylko twoja wyobraźnia Szyfru Cezara nie polecam bo to bardzo proste rozwiązanie które jest bardzo łatwo złamać .

Prosze: http://dominik.cc/projekty/avr-aes/

Hmm... Jedna rzecz mnie zastanawia.



Jak powinno wyglądać szyfrowanie paczki danych o dowolnej długości, większej niż 16 bajtów?

Dopełniamy łańcuch tekstowy jakimiś znakami, żeby jego długość zawsze była wielokrotnością 16? A może tworzymy bufor o określonej długości, będącej wielokrotnością 16, zapisujemy do niego łańcuch tekstowy a potem szyfrujemy całość po 16 bajtowym kawałku, a potem wysyłamy tak uzyskaną paczkę? Może jest gotowa funkcja szyfrująca i deszyfrująca całe bufory i nie trzeba wyważać otwartych drzwi?

wez xmege i po problemie http://www.atmel.com/Images/doc8106.pdf nawet programatora nie musisz kupowac

Nie wiem czy to ma sens. Przeciętna komenda wysyłana w pakiecie UDP jest bardzo krótka. Jeśli ograniczymy się do cyfr zapisanych w ASCII i rozdzielonych tokenami, będzie to kilka - kilkadziesiąt bajtów danych. Jeśli dodamy jakieś teksty, rozmiar wzrośnie do kilkudziesięciu - kilkuset bajtów. ATmega z software'ową obsługą AES potrafi ponoć poradzić sobie z kilkoma kB danych w ciągu sekundy, opóźnienie nie będzie więc duże. Zastosowanie XMegi miałoby może sens, gdybym musiał szyfrować duże paczki albo całe strumienie danych. Zresztą nie wiem czy przerzucanie się na nową platformę ma w tej chwili sens - na razie wolę uczyć się na ATmegach, a gdy one okażą się "za ciasne", trzeba będzie przerzucić się na jakieś ARM-y.

Tak swoją drogą zastanawiam się, czy faktycznie AES jest tutaj wymagany. Może wystarczy jakiś lżejszy algorytm szyfrujący? Oczywiście nie chciałbym przesadzać w drugą stronę i (jak to ktoś sugerował) stosować szyfr Cezara.

Tak sobie zresztą myślę... Czy zastosowanie takiego szyfrowania coś mi daje? Załóżmy, że ktoś przechwyci pakiet z zaszyfrowaną treścią. Czy przypadkiem spreparowanie pakietu o dokładnie takiej samej (niejawnej) treści nie spowoduje wykonania polecenia prze urządzenie? W końcu dane zostaną rozszyfrowane za pomocą klucza i pójdą do dalszego parsowania... Chyba, że ten system szyfrowania zawiera jakieś zabezpieczenie i wymaga np. zsynchronizowanych zegarów, które sprawią, że paczka po jakimś czasie przestanie być aktualna?

A co wlasciwie chcesz osiagnac, niezaprzeczalnosc danych (MAC, podpis), czy szyfrowanie?
AES nie zapewnia 'lifetime' pakietu. To robi sie juz na poziomie protokolu np wlasnie przez zsynchronizowanie zegarow. Po poprawnej operacji ustalasz dynamiczny TOKEN ktory dorzucasz do kazdego zestawu danych ktore szyfrujesz.