Jak zaimplementować SSL na mikrokontrolerach STM32 do komunikacji GSM?

Fri Feb 06, 2015 11:23 am   

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?

Fri Feb 06, 2015 11:50 am   

On 2015-02-06 11:23, Atlantis wrote:

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
https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino-WIFI/open-source-hardware

Po ethernecie podłącz swoje moduły , dodaj modem GSM lub WiFi na USB,
zaistaluj linuxa, napisz tylko aplikację jak na PC i tyle.

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

Fri Feb 06, 2015 11:51 am   

On Fri, 06 Feb 2015 11:23:17 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:


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.

--
Marek

Fri Feb 06, 2015 3:38 pm   

Am 06.02.2015 um 11:23 schrieb Atlantis:

Na Raspberry PI powinno odpalić bez problemu.

Waldek

Fri Feb 06, 2015 3:45 pm   

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.

Fri Feb 06, 2015 4:01 pm   

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

Fri Feb 06, 2015 4:54 pm   

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.



--
pozdrawiam
MD

Fri Feb 06, 2015 5:24 pm   

Atlantis wrote:


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

Fri Feb 06, 2015 5:57 pm   

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

Fri Feb 06, 2015 6:34 pm   

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

http://www.wolfssl.com/yaSSL/Products-cyassl.html
https://polarssl.org/
Nie używałem, jedynie planowałem użyć. Gdybyś grzebnął w kodzie to
pewnie na jakimś większym AVR-ku by to poszło. Problemem jest tutaj
przede wszystkim wielkość pamięci danych i, w mniejszym stopniu,
programu, a nie ilość MIPS-ów. W każdym razie do znośnego wysyłania
kilkuset bajtów np. co minutę powinien wystarczyć. Aczkolwiek IMO nie ma
co rzeźbić tylko wziąć jakiegoś małego ARM-a czy MIPS-a - nie ze względu
na zalety tych architektur tylko ze względu na to, że MCU oparte na tych
architekturach zazwyczaj będą miały wystarczająco dużo RAM-u i Flash-a
na pokładzie.

Fri Feb 06, 2015 7:28 pm   

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ł

Fri Feb 06, 2015 7:57 pm   

On 02/06/2015 05:57 PM, Atlantis wrote:

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

Fri Feb 06, 2015 8:03 pm   

On 02/06/2015 07:57 PM, Marek Wodzinski wrote:

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

Fri Feb 06, 2015 9:25 pm   

On Fri, 06 Feb 2015 17:57:56 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:


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

Fri Feb 06, 2015 9:34 pm   

On Fri, 06 Feb 2015 17:57:56 +0100, Atlantis <marekw1986NOSPAM@wp.pl>
wrote:

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