În acest articol analizăm conceptele de bază ale furnizării unui regim de securitate încorporată puternic și fiabil pentru un sistem embedded bazat pe microcontroler. Analizăm principiile de securitate și oferim un nivel superior de înțelegere asupra suprafețelor de atac și a vectorilor pe care îi folosesc adversarii.
Introducere
Lumea online din zilele noastre, conectată în permanență, este o reală bucurie pentru adversari. Le oferă un teren de joacă global, plin de dispozitive pe care încearcă să le compromită. Securitatea unui dispozitiv încorporat (embedded) este esențială pentru a împiedica hackerii să preia controlul asupra acestuia. Chiar mai rău, un adversar poate iniția un atac și mai dăunător asupra sistemelor la care este conectat dispozitivul. Atacurile la distanță, însă, sunt doar unul dintre instrumentele pe care le au la dispoziție adversarii. Atacurile locale asupra dispozitivului hardware fizic sunt o altă metodă prin care pot obține informații secrete. Aceste atacuri includ accesul la parolele de autentificare în sistem sau chiar la proprietatea intelectuală asupra codului aplicației în sine.
Nu trebuie niciodată să lăsăm securitatea în plan secundar, indiferent de nivelul de complexitate care se adaugă la sistemul embedded. De asemenea, securitatea nu înseamnă doar chei criptografice și firmware încorporat, ci și date cu caracter personal. În cazul în care un adversar dobândește controlul asupra firmware-ului unui dispozitiv, este posibil ca acesta să poată genera codul sursă inițial. Înțelegând astfel cum funcționează codul, adversarul poate descoperi alte vulnerabilități și are ocazia de a introduce cod malware. Accesul la un singur dispozitiv IoT conectat, care este nesecurizat, poate compromite un întreg sistem IoT – a se vedea Figura 1.
Ce trebuie protejat
Înainte de a începe să investigăm tehnicile de securitate, să analizăm și să clasificăm lucrurile pe care trebuie să le protejăm. Hackerii pot avea în vedere trei aspecte diferite ale unui dispozitiv IoT. O țintă reprezintă un dispozitiv IoT care trebuie protejat. Un activ este conținutul țintei, care trebuie protejat. În figura 2 sunt identificate activele care trebuie securizate, precum și riscurile aferente fiecărei ținte, dacă aceasta este compromisă. Atunci când se implementează tehnici de securitate încorporate, această metodă de clasificare ne ajută să selectăm abordarea corectă pe care să o utilizăm.
Tipuri de atacuri
Atacurile asupra unui dispozitiv IoT pot proveni din diferite surse, clasificate larg ca fiind software sau hardware. Atacurile asupra software-ului unui dispozitiv pot avea loc fie local, fie prin intermediul unei conexiuni la rețea. Tipurile de atacuri hardware sunt împărțite suplimentar în invazive și neinvazive. Un atac neinvaziv are loc local și doar în unele cazuri necesită o conexiune electrică la circuitul imprimat principal al dispozitivului IoT. Un atac hardware invaziv implică acces fizic și electric la microcontrolerul dispozitivului. Lansarea unui atac invaziv este de obicei calea cea mai costisitoare pentru adversar și necesită cunoștințe de specialitate. Figura 3 exemplifică cele trei tipuri de atacuri descrise mai sus, precum și o analiză a tehnicilor și motivelor pentru care un adversar ar dori să le folosească.
Atacurile software tind să fie cele mai comune și implică exploatarea erorilor firmware, a slăbiciunilor cunoscute ale protocolului, prin intermediul canalelor de comunicare ale dispozitivului. Costurile aferente desfășurării acestor atacuri pot fi relativ scăzute, iar acestea se pot realiza ușor, deoarece se execută de la distanță. Cunoștințele privind vulnerabilitățile dispozitivului pot fi distribuite și comunicate în comunitatea de hackeri.
Securitatea pusă în practică
Din perspectiva unui producător de dispozitive, înțelegerea driverelor de securitate ale dispozitivului permite stabilirea funcțiilor de securitate necesare – cele trei scenarii creionate mai jos evidențiază unele dintre funcțiile de securitate necesare pentru fiecare. În următoarea secțiune sunt explicate numeroase funcții de securitate și implementarea lor practică.
Scenariul unu
Să luăm drept exemplu o companie care vinde firmware și pentru care principala sursă de venit este plata de redevențe. Firmware-ul produs de companie este un activ de proprietate intelectuală valoros, care trebuie protejat. Clienții folosesc firmware-ul împreună cu codul aplicației lor. Din perspectiva companiei, firmware-ul trebuie să fie izolat în siguranță de codul clientului. Compania lansează periodic actualizări ale firmware-ului, prin urmare există cerința de instalare și actualizare în siguranță a firmware-ului. În acest scenariu, funcțiile de securitate necesare includ izolarea, protecția drepturilor de proprietate intelectuală asupra software-ului, precum și rutine securizate de instalare și actualizare a firmware-ului.
Scenariul doi
Compania IndustrialAdvantage vinde echipamente costisitoare pentru controlul producției și dorește să ofere clienților săi un serviciu de actualizare de firmware. Există cerința ca pe echipamentele furnizate să ruleze exclusiv firmware-ul IndustrialAdvantage. Procesul de actualizare a firmware-ului trebuie gestionat cu grijă, cu verificări de autenticitate pe întreaga durată a procesului. Asigurarea că pe echipamente rulează exclusiv firmware-ul IndustrialAdvantage se poate realiza printr-o funcție numită secure boot (inițializare securizată). Funcția de instalare și actualizare în siguranță asigură integritatea și verificările de autenticitate.
Scenariul trei
Dispozitivele fabricate de Consumer Tech colectează datele utilizatorilor, ca parte dintr-un sistem mai complex. Compania are grijă să respecte permanent reglementările în domeniul protecției datelor personale, de exemplu GDPR. Consumer Tech dorește, de asemenea, să se asigure că dispozitivele produse de aceasta au un comportament solid și că pe dispozitive rulează exclusiv firmware Consumer Tech. În timpul comunicației dispozitiv – sistem gazdă, există posibilitatea expunerii datelor utilizatorilor, iar folosirea de tehnici criptografice, a identificării dispozitivului și a autentificării pot să prevină expunerea datelor cu caracter personal. Integritatea platformei este asigurată prin funcția secure boot.
Asigurarea unui cadru de securitate
Pentru dezvoltatorul de dispozitive embedded, accesul la un set cuprinzător și solid de funcții de securitate pentru platforma microcontrolerului unui dispozitiv este esențial. Un exemplu este ecosistemul „STM32Trust” pentru seria de microcontrolere STM32 de la STMicroelectronics – a se vedea Figura 4.
Funcțiile de securitate ale STM32Trust utilizate pe seriile de microncontrolere STM32L4 și STML5 sunt certificate Arm PSA Level 2 și SESIP Level 3. Funcțiile de securitate sunt fie încorporate direct în microcontroler, fie sunt disponibile sub formă de firmware și sunt configurate în funcție de dispozitiv.
În restul articolului ne vom concentra pe două funcții de securitate esențiale furnizate de STM32Trust și evidențiate în scenariile anterioare: secure boot (SB) și instalare/actualizare securizată (SBSFU).
Secure Boot
Principiul care stă la baza ‘secure boot’ este acela că, la resetarea dispozitivului, se execută codul secure boot, care verifică dacă firmware-ul aplicației este autentic înainte de a decide lansarea aplicației. Inițializarea securizată se bazează pe doi parametri. În primul rând, codul ‘secure boot’ este singurul cod care se execută după resetare. În al doilea rând, codul de boot este imuabil, respectiv nu poate fi modificat în niciun fel. Adresa codului de boot este unică, împiedicând accesul la o adresă alternativă de firmware după resetare. Împreună, aceste două aspecte creează o bază de încredere pentru dispozitiv. A se vedea Figura 5.
Se realizează verificările de integritate și autenticitate ale firmware-ului aplicației, prin comparație cu o semnătură. Verificarea de integritate compară un ‘hash’, denumit uneori un ‘digest’, generat din codul aplicației, cu o referință furnizată. Autenticitatea este verificată cu o semnătură calculată din valoarea ‘hash’ generată și o cheie privată. Semnătura este ulterior verificată folosind o cheie publică asociată. Valoarea ‘hash’ de referință și valoarea semnăturii trebuie să fie întotdeauna furnizate împreună cu firmware-ul.
Acestea sunt de obicei stocate într-un container, denumit metadata sau antet – a se vedea Figura 6. Metadatele nu necesită criptare, datorită metodei prin care sunt generate. Dacă are loc o încercare de utilizare a unui firmware malițios, nu există nicio posibilitate ca hash-ul firmware-ului să corespundă cu referința. Figura 6 ilustrează construcția semnăturii metadatelor, folosind digestul firmware cu ‘hash’ și cheia privată.
În Figura 7, codul ‘secure boot’ utilizează semnătura metadata pentru a confirma integritatea firmware-ului aplicației și autenticitatea acestuia. Dacă procesul de verificare a semnăturii verifică validitatea firmware-ului, procesul de ‘boot’ continuă cu încărcarea codului aplicației. Discrepanțele dintre firmware-ul aplicației și semnătură conduc la o eroare în procesul de inițializare.
Actualizarea securizată a firmware-ului
Pașii esențiali identificați pentru un proces de actualizare de firmware sunt:
- crearea actualizării pentru firmware-ul aplicației
- generarea metadatelor asociate
- transmiterea acestora către dispozitivul țintă
- metadatele sunt utilizate de funcția de ‘secure boot’ pentru a verifica integritatea și autenticitatea firmware-ului aplicației,
- dacă verificarea se realizează cu succes, procesul de ‘Secure Boot’ instalează noul firmware.
Noua semnătură metadata este creată într-o modalitate similară cu tehnica explicată pentru ‘secure boot’. Pentru multe dispozitive IoT/IIoT conectate la distanță, cea mai simplă metodă de transfer este prin intermediul unei actualizări ‘over-the-air’ (OTA). Dispozitivele fără conexiune la internet necesită o conexiune locală, de exemplu un card UART, SPI, USB sau microSD. Noul firmware al aplicației este imprimat în memoria flash a dispozitivului țintă, folosind un program de încărcare, care este de obicei inclus fie în codul ‘secure boot’, fie în firmware-ul aplicației. Noul firmware trebuie stocat local în timp ce firmware-ul existent încă rulează.
Figura 8 ilustrează procesul de actualizare de firmware la distanță. Trebuie să existe două ‘sloturi’ de memorie, unul pentru firmware-ul existent și unul pentru versiunea actualizată.
Etapa finală a procesului de actualizare implică verificarea noului firmware al aplicației. Dacă verificarea metadatelor se realizează cu succes, are loc schimbul dintre cea mai nouă versiune de firmware și firmware-ul existent al aplicației. Actualizarea este acum finalizată.
Concluzie
Securitatea dispozitivelor embedded nu mai este opțională. Fiecare dispozitiv trebuie protejat împotriva atacurilor malițioase și a posibilelor vulnerabilități. Securitatea dispozitivului începe de la inițializare ‘boot’, prin urmare includerea unor funcții de securitate, precum ‘secure boot’ și a unui proces securizat de instalare și actualizare a firmware-ului este vitală. STM32Trust oferă toate funcțiile de securitate de care are nevoie un dezvoltator de dispozitive embedded pentru asigurarea securității dispozitivelor sale și pentru conformitatea cu legislația.
Autor: Mark Patrick, Mouser Electronics