[Videó] IoT-eszközök védelme kártékony kódokkal szemben

HUP
 

Futóné Papp Dorottya (BME CrySyS Lab) a HWSW free! meetup sorozaton elhangzott előadásának felvétele.

Az internetre ma már számtalan beágyazott eszköz is csatlakozik: okos otthonok, autók, ipari robotok, stb. Ezekben az eszközökben is előfordulnak sérülékenységek, amiket a támadók különböző kártékony kódokkal használnak ki támadásokhoz. A védekezés azonban több kihívást is rejt magában. Egyrészt, az eszközök kevesebb erőforrással (memória, processzor) rendelkeznek, ezért a hagyományos védekezési megoldások nehezen alkalmazhatóak. Másrészt, a naprakész védelemhez naponta több ezer, beágyazott eszközökre készített kártékony kódot kell feldolgozni, ezért fontos a hatékonyság. Az előadás során ezeket a kérdéseket járjuk körbe és bemutatjuk az Ukatemi Technologies és a CrySyS Lab ezzel kapcsolatos megoldásait.

(A videó a HWSW free! meetupsorozat 2020. július 7-i IT-biztonsági állomásán készült.)

( Ar0n v | 2021. 02. 04., cs – 18:38 )

Szerkesztve: 2021. 02. 04., cs – 18:45

Hat ez lehetett volna kicsit specifikusabb es nem is ertem, hogy ez hogy lesz jo ... A legtobb beagyazott eszkoznek ez too much, illetve onmagaban nem elegseges.

"IoT-eszközök védelme kártékony kódokkal szemben"

Majd elkezd fileokrol beszelni. Legtobb IoT eszkoz azt se tudja mi az, hogy file. 

"2 fajl mennyire hasonlit egymashoz"

Ha erre alapul a megoldas, akkor az nagyon nem jo. De mondjuk van egy linuxot futtato SOC, alatta fs minden, hogy segit ez egy kartekony kod futtatasan ha az RAM-ban csucsul? Sehogy.

Erre a run-time code ellenorzes es secure boot a megoldas, igy csak signed kod tud futni az eszkozon.

Ez szerintem dead-end, mert gyerekjatek kijatszani.

Sajnos megnéztem. Nekem is ugyanez a véleményem.

 

"Legtobb IoT eszkoz azt se tudja mi az, hogy file. "

Egyelőre talán így van, de ez változik. Nagyon jön a Linux, mert a uC fejlesztők egyszerűen képtelenek lépést tartani a mindenféle protokollok, meg az igények fejlődésével. Ott maradnak nem Linux-os eszközök, ahol a darabszám miatt nincs pénz DRAM-ra, illetve, ahol kritikus a boot-idő.

Ja. Igazabol nekem az a bajom, hogy ugy van eloadva, hogy ez az ultimate megoldas, kozben meg ez talan egy vegso mentsvar lehet / jobb mint a semmi.

A gyarto meg kifizeti es vigan rateszi a plecsnit, hogy van benne antivirus (lol) es ugyanolyan szar marad az egesz.

Semmi értelme. Még elvileg sem. A vírusirtó arra a helyzetre van kitalálva, amikor az ember desktop-on, vagy telefonon mindenféle ismeretlen alkalmazást telepít.

Egy IoT rendszerben (még ha Linux-os is) az összes fájl eleve ismert. Bőven elég ezekre a fájlokra md5sum-ot futtatni időnként. Már persze ha nem a kernelt támadták meg, de ebben az esetben a vírusirtó is használhatatlan.

> Nagyon jön a Linux, mert a uC fejlesztők egyszerűen képtelenek lépést tartani a mindenféle protokollok

Nem feltetlen gondolom igaznak ezt.

Egreszt ott vannak az "okosizzok", "okosmerok", stb. Ezekbe nem feltetlen kell Linux bonyolultsagu rendszer (plane nem "operacios rendszer") - a protokollok java resze meg pont nem tul bonyolult ahhoz, hogy ezek kommunikalni tudjanak (talan a TCP/IP a legbonyolultabb reteg ezekben, alatta, felett egyszerubb).

Es akkor arrol meg nem is szoltunk, hogy az IoT nem jelent egyet a TCP/IP-vel, Wi-Fi-vel / Ethernettel. A legtobb Internetre aggatott eszkoz pont nem direktben eri el az Internetet sot - bar Internet of Things a megnevezes a legtobbszor ez nem is fedi a valosagot - akar a lokalis halozatot sem. Sokszor teljesen mas csatornan kommunikalnak es egy gateway koti oket ossze a TCP/IP vilaggal - viszont ettol meg IoT eszkozoknek mondjak oket.

Ezeken az eszkozokon szerintem tovabbra sem lesz jellemzo a Linux (es/vagy Wi-Fi/Ethernet) hasznalata, egyreszt energiaigengy maszrest ar szempontbol.

/sza2

Digital? Every idiot can count to one - Bob Widlar

RTOS-ok talan, de a legtobb bare metal - sokszor annyi eroforrast visz el az RTOS (+flash, +RAM, +ido), hogy egyszeru funkcio eseten nem erdemes meg azt sem alkalmazni. Altalanossagban az OS (RTOS) sokat tud rontani azon, hogy mennyit tud aludni egy ilyen eszkoz. Az Silabs EFR32 IC-k legmelyebb alvasban ~50nA-t fogyasztanak. Radiozas kozben (pl. adas, 20dBm) akar 30mA-t is - itt nem mindegy, hogy egy adas 2ms vagy az OS miatt 10ms.

 

Amikor valaki millio szamra keszit ilyen eszkozoket, ott eleg erzekenyek szoktak lenni ar tekinteteben, hogy inkabb veszik meg az 50 centtel olcsobb de cserebe csak 128k flashes chipet a 256k-s helyett.

/sza2

Digital? Every idiot can count to one - Bob Widlar

En is jobban szeretem a bare metal dolgokat ... Teny van igazsag abban amit irsz, de a sleep az rtos-el is is ugyanugy mukodik, ugyanugy ra van bizva a fejlesztore.

Amikor megebred valoban van egy kis overhead az OS miatt, sokminden tortenik *feleslegesen*, de ha jol van megoldva akkor nem szamottevo.

Btw pont ez a gecko szeria tok jol hozza a szamokat micriummal is.

Az ar az valoban mindig fontos ... de hogy fog igy elferni az a franya antivirus (lol)