Végre sikerült időt szakítani arra, hogy összerakjam az MCU-n futó RSA kódot. Frankón működik! \o/

Az okozhatja nalad a kavarodast, hogy a legtobb elore elkeszitett docker image-ben a valasztott Linux distro az Alpine szokott lenni, de igazan nincs semmi szorosabb kapcsolat az Alpine es a kontenerek kozott.

Van egy RC változatom a LoRa-s protokollról, ha valaki ért az ilyesmihez, és szeretné kommentálni, akkor itt olvasható:
http://igor2.repo.hu/cgi-bin/minisvn.cgi?cmd=cat&repo=freestd32&path=/trunk/lib/ext/secpan.txt

Senki?

Gyors update (és egyben topic keepalive): a kliens oldal elvileg kész (kivéve az AYT-t, mert az nem létfontosságú, és elég operatív), most a szerver oldalon ügyködök.

Meselhetnel kicsit a projektrol, nem vagyok kepben mit csinalsz

Az alapfeladat az volt, hogy kellett egy vezetéknélküli adattovábbító apparátus. Több versenyző szállt harcba a dicsőségért: BLE, WiFi, LoRa, 2G, 3G, NB-IoT, stb. Ezeket egy idő után lefaragtam, ilyen-olyan problémák miatt: pl a 2G/3G/.../10000G az SIM-kártya függő; az NB-IoT nem lett volna annyira rossz, a fizikai paraméterei alapján sokáig esélyes volt, de a Mo-i lefedettség/támogatottság a béka segge alatt van a mai napig; WiFi túlkomplikált; BLE hatótávolsága kevés, és könnyen árnyékolódik; stb. Végül a LoRa jött ki nyertesnek. A LoRa-hoz jár egy LoRaWAN nevű szörnyűség. Dióhélyban: rengeteg korlátozás, és még titkosítatlan is, a kliensek passzívak, stb. Egy fos. Így kellett egy jóval megbízhatóbb protokoll rá. Lehetőleg ne legyen lehallgatható; duplikált üzenetek ne okozzanak fennakadást; legyen hibatűrő, és ne legyen egyoldalú a kommunikáció. No, ez lett végül a SecPAN. Néhány aspektus: a kezdeti kulcscsere RSA-n megy; a normál ügymenet AES-128-CTR titkosítást kap, és kötelező időszakos (csomag darabszámtól függő) újrakulcsolás van (ez fogja megakadályozni, hogy hosszú távon a duplikált üzenetek problémát okozzanak); raktam egy nagyobb CRC-t a csomagra (én CRC-16-CCITT-t rakok rá, a LoRa alapból valamelyik CRC-8-at); van ACK mechanizmus. Amit a user lát belőle, az gyakorlatilag egy datagram alapú kommunikáció, és a szerverrel tud beszélgetni. Az adat továbbítását a szerverre bíztam, hogy ne legyen elbonyolítva a protokol. A szerver úgyis valami erősebb cucc lesz, szóval azon nem aggódok. Nekem is egy Orange PI PC+ a szerver (Allwinner H3 + 1 GiB RAM + 8 GiB eMMC). A kliens egyik fő szempontja, hogy bele kell férnie egy mikrokontrollerbe. Az egyik kész hw-emen egy 32 KiB ROM-os MCU van (ez relatív-e nagynak számít), 8 KiB RAM + 1 KiB EEPROM (ez végszükség esetén kódmemóriának is jó). Ebbe bele fog férni a cucc. Muszáj lesz neki.

Ellenőrzésképp bevágtam minden releváns függvényt, és majdnem elérte a 10 KiB-ot a bináris. Vagyis még van 22 KiB szabad hely úgy, hogy a kliens pár kisebb hiányzó függvényt leszámítva kész (egy ilyen "nagyobb" az RNG). És ebben a 10 KiB-ban már benne van a teljes AES és RSA implementáció is, és kezdetben az RSA-tól tartottam egy picit, hogy bele fog-e férni. Jó, mondjuk "csalás", mert csak az RSA public kellett bele, de akkor is.

es mire lesz hasznalva, smart home?

Ha "home" lenne, akkor elég lett volna a BLE.

Annál azért ridegebb környéken kell helytállnia. Egy példány megy a medence gépházába, hogy remote tudjam csekkolni a vízhőmérsékletet. Egy meg a dézsa vízfűtő rendszeréhez kell, vezérlési és adatszolgáltatási feladatokat ellátni. Van egy móricka projekt is, ami egy szimpla óra, de ezen keresztül fog szinkronizált RTC adatokat kapni. Meg a jövőben más egyéb projektben is részt fog venni, de arról még korai elmélkedni.