SSL na mikrokontrolerach

Byłoby chyba najprościej. IMHO weź dowolną arm - platformę gdzie dostępny jest port linuxa i zasadniczo tyle w temacie.

Jeżeli się uprzesz na wkompilowany system lub nawet jego brak to też pewnie znajdziesz biblioteki do SSL, tylko po co ?

Dużo pary psu w d...

Kup za 55 euro

Masz tam dostępne wszystko. Włącznie z projektem tej płyty w Eaglu. Możesz kupić gotowe lub zrobićsobie samemu PCB i kupić elementy.

Jedyna wada to większy pobór prądu. Ale za to zabawy na 1 dzień.

Adam

Ssl jest np. w stosie Microchipa. Ale czy musisz koniecznie użwac ssl do tak prostej komunikacji? Stosunek kodu stosu+ssl do Twojego (user) kodu będzie jak 100:1. Ja używam szyfrowania xtea, algorytm jest prosty i bezpieczny jak na takie zastosowania, nawet wikipedia podaje go w C. Dla 8 bitowca w sam raz.

Am 06.02.2015 um 11:23 schrieb Atlantis:

Na Raspberry PI powinno odpalić bez problemu.

Waldek

W dniu 2015-02-06 o 15:38, Waldemar pisze:

Na Raspberry Pi pójdzie z całą pewnością, właśnie na nim eksperymentuję z tym deamonem/serverem mającym pośredniczyć w komunikacji. Docelowo mam zamiar wykorzystać jakąś mocniejszą platformę - myślę o CubieTruck, głównie ze względu na możliwość zainstalowania dysku twardego.

Tyle tylko, że ładowanie RasPi do projektu, w którym chodzi na tylko o odczytanie kilku czujników i wysłanie danych przez sieć będzie lekkim overkillem.

Am 06.02.2015 um 15:45 schrieb Atlantis:

Overkill overkillem, ale na małych kontrolerach SSL nie postawisz, a większe kosztują tyle, co raspi. Poszedłbym za radą Marka i zrobił jakieś prostsze kodowanie. Nie będziesz przecież przesyłał jakichś tajnych danych z tych sensorów. A jak ktoś podsłucha, że u ciebie w domu jest 24C, a nie 20 to ChMuWD ;-).

Waldek

W dniu 2015-02-06 o 15:45, Atlantis pisze:

Jak zastosowanie małego arma do migania diodą. Tylko, że takie rozwiązanie może być najszybsze i najtańsze, a więc trudno je nazwać overkillem.

Może AES128, niektórzy producenci procesorów udostępniają stosowne biblioteki, stosowane np w transmisji danych z czujników, wodomierzy i ciepłomierzy a więc nie jest to zbyt zasobożerne, idealne do embeded. jp

W dniu 2015-02-06 o 16:01, Waldemar pisze:

Nie przesadzajmy... Takie STM32 albo PIC32 są niewiele droższe od ośmiobitowych AVR-ów. Parę sztuk nawet leży u mnie w szufladzie. Właściwie jaki MCU to należałoby uznać za absolutne minimum do w miarę znośnej obsługi SSL-a?

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ąć. ;)

On 2015-02-06 17:57, Atlantis wrote: [...]

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³

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

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

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? :)

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