Implementarea securității în era IoT

Deși serverele sunt țintele principale, unele atacuri se concentrează pe dispozitive relativ simple și aparent inofensive. Cine ar considera termometrul electronic din interiorul unui acvariu drept o potențială amenințare la securitatea rețelei unei corporații? Pentru un cazinou, acesta s-a dovedit a fi problema. Hackerii s-au folosit de apărarea re­lativ slabă a termometrului pentru a obține un prim acces la rețeaua de bază. Din acea poziție vulnerabilă au obținut un acces mult mai bun și au găsit în scurt timp o bază importantă de date pe care au copiat-o. Breșa din sistem a fost desco­perită doar atunci când un consultant de securitate a analizat jurnalele de rețea și a găsit date trimise la un server de control de la distanță din Finlanda, utilizând protocoale care sunt utilizate în mod normal pentru a transmite fluxuri media.

Rețelele bancare au fost penetrate prin intermediul rețelelor de televiziune cu circuit închis (CCTV), care au fost instalate pentru a îmbunătăți securitatea fizică, iar hackerii au găsit modalități de a spiona utilizatorii casnici prin camerele de filmat instalate pe aspiratoarele de tip robot. Totuși, aceste atacuri pot fi evitate. Există posibili­tatea de a opri atacurile și de a vă proteja dispozi­tivele și rețeaua principală. Factorul cheie este acela de a furniza mai multe niveluri de bariere de securitate care vor îngreuna operațiile de spargere și vor consuma foarte mult timp pentru potențialii hackeri.
Astăzi, hackerii pot profita adesea de decizii slabe luate de echipele de dezvoltare. O greșeală obișnuită este ca dispozitivele să fie furnizate cu o parolă implicită care permite utilizatorilor de la distanță să se conecteze la o interfață de control. Astfel de parole pot fi adesea găsite în aplicațiile furnizate pentru a face aceste dispozitive IoT să fie ușor de configurat. O bună practică ar fi alocarea unei parole unice pentru fiecare dispozitiv. Dar, pe măsură ce producătorii își îmbunătățesc abilitățile de securitate de bază, infractorii cibernetici vor folosi tactici tot mai sofisticate, similare cu cele pe care le folosesc împotriva serverelor. Sistemele embedded nu mai pot fi ignorate, mai ales în acest mediu în schimbare, datorită pre­concepției că valoarea lor nu este suficient de importantă pentru hackeri. După cum au desco­perit proprietarii cazinourilor, orice dispozitiv IoT poate deschide o rețea la un atac dedicat.

Există numeroase tipuri de atac care pot fi organizate împotriva unui sistem în rețea.
De exemplu, o tehnică obișnuită folosită de hackeri este de a valorifica defectele software-ului. Dacă dispozitivul primește mai multe date dintr-un pachet decât au fost alocate unui dispozitiv tampon din stiva de sistem, baiții suplimentari se vor “revărsa” în structurile de date vecine. Atunci când o rutină ulterioară elimină acei baiți din stivă, datele pot fi utilizate de alte rutine, care se defectează sau realizează procese cu date greșite. Procesorul poate chiar interpreta aceste valori ca adrese țintă și să încerce să execute codul greșit. Un hacker familiarizat cu nivelul de memorie al dispozitivului va folosi aceste cunoștințe pentru a construi mici-programe, care să le ofere o cale către dispozitiv. O exploatare similară este aceea de a trimite date eronate dispozitivului, care determină neexecutarea subrutinelor utilizate pentru procesarea baiților și care pot face ca dispozitivul să fie vulnerabil.

Unele atacuri se concentrează mai mult pe protocoalele de comunicații, decât pe software-ul dispozitivului de bază și încearcă să suprasolicite sistemul pentru ca acesta să defecteze. Pe măsură ce dispozitivul încearcă să se recupereze, hackerii pot încerca să obțină acces. Dacă atacatorul este capabil să controleze echipamentele din rețeaua din apropiere sau chiar să obțină acces fizic direct, este posibil să poată sparge serverele legitime cu care dispozitivul dorește să comunice. Astfel de atacuri cunoscute sub numele de man-in-the-middle pot fi utilizate pentru a analiza datele care provin de pe dispozitiv și care ar putea fi utile pentru un atac viitor. În mod alternativ, hackerul poate încerca să încarce propriul firmware pe dispozitiv. Odată repornit cu firmware-ul malițios înlocuitor, dispozitivul va îndeplini orice funcție dorește hackerul.
În mod ideal, sistemul ar respinge încercările de comunicare ale mașinilor care nu pot demonstra că au drepturi de acces. Procedând astfel, dispozi­tivul ar respinge firmware-ul fals furnizat de hacker. De asemenea, ar putea ignora încercările de conectare la un atac denial-of-service și, astfel, ar putea evita crearea unei legături către resursele care obligă sistemul să se prăbușească. Ar putea evita și trimiterea de date sensibile către o mașină care nu poate fi autentificată sigur. Pentru pachetele pe care dispozitivul le acceptă, ar trebui verificate lungimea și corectitudinea acestora, respingând orice structuri malformate, care ar putea deschide o cale vulnerabilă către dispozitiv la un atac de supraîncărcare a memoriei tampon sau la un atac de injectare de comenzi. Cu toate acestea, implementarea tuturor acestor protecții în firmware-ul dispozitivului poate fi costisitoare pentru orice ‘codebase’ ¹⁾ de mari dimensiuni.

Abordarea ‘Dezvoltator dual’

O abordare mai realistă este împărțirea firmware-ului în secțiuni, unele care necesită o asigurare ridicată de securitate și altele care pot fi “acceptate” să cedeze atacului, deoarece nu vor compromite funcțiile sigure. De exemplu, nu este necesară verificarea proprietăților de securitate ale unei subrutine care pur și simplu împachetează datele de temperatură într-un format JSON, astfel încât acestea să poată fi transmise către o aplicație pentru telefon inteligent. Cu toate acestea, codul securizat va asigura că autentificarea este efec­tuată înainte ca aceste date să fie trimise oriunde.

Mecanismul de întreruperi Cortex-M23

Cantitatea de software de pe dispozitiv, care are nevoie de o securitate completă puternică nu trebuie să fie decât o fracțiune din totalul bazei de coduri. Totuși, această separare este eficientă numai dacă nu există portițe ascunse de la programul nesecurizat la rutinele de înaltă securitate pe care hackerii le pot exploata în atacuri de esca­ladare a privilegiilor de acces. De exemplu, dacă un atac de supraîncărcare a registrului tampon reușește să încarce în memorie datele “sigure” pe care le dorește (care fac ca identitatea atacatorului să fie cea a unui administrator de sistem), orice protecție este pierdută. Izolarea memoriei sigure de zonele nesigure este esențială și poate fi pusă în aplicare în siguranță, numai prin hardware.

Microcontrolerele embedded, cum ar fi cele din familia Microchip SAM L11, conțin hardware de securitate bazat pe extensia de arhitectură Arm® TrustZone®, sporită cu protecții patentate împo­triva atacurilor software. Suportul hardware din SAM L11 face posibilă construirea unei rădăcini de încredere și utilizarea acesteia pentru a extinde protecțiile de securitate la restul sistemului, pu­nând bazele unei zone de lucru complet securizate.
Rădăcina de încredere poate efectua operațiuni criptografice, care extind zona de încredere și mai mult, pentru a include și alte elemente ale sistemului, permițând protejarea comunicațiilor dintr-o rețea nesigură. Un controler criptografic încorporat simplifică operația de generare a cheilor de autentificare pentru o sesiune, precum și operațiile de criptare și decriptare. Controlerul poate ajuta, de asemenea, la verificarea autenti­cității, nu numai a mesajelor primite din rețea, ci și a programului pe care îl va rula sistemul.
Protecțiile criptografice oferă protecție chiar și împotriva hardware-ului falsificat. În acest caz, software-ul care rulează în zona de încredere poate interoga și alte componente de pe o placă de bază, realizând teste la care numai plăcile valide pot răspunde corect. Pentru a menține o rădăcină de încredere, hardware-ul SAM L11 implică un proces de pornire securizată.
Pentru ca acest proces de pornire să nu fie compromis, secvența inițială de pornire provine de la programul reținut într-o zonă de memorie ROM de pornire, care nu poate fi modi­ficată după fabri­care și deci nu poate fi ocolită în proces. După finalizarea pornirii inițiale, serviciile din programul de pornire din ROM, verifică firmware-ul rămas, necesar pentru a finaliza procesul de pornire pentru autenticitate. Face acest lucru, cu ajutorul acceleratorului criptografic, veri­fi­când dacă hash-ul stocat cu fiecare segment de firmware se potri­vește și că este în concordanță cu un hash²⁾ de referință codat fizic la fabricație. O nepotrivire a oricărei valori va reseta dispozitivul și va reîncepe procesul de pornire securizată. În acest fel, chiar dacă un hacker reușește să modifice firmware-ul stocat în memoria flash de pe chip, dispozitivul nu poate porni cu succes până când versiunea producătorului nu este reîncărcată.

Interacțiuni standard între stările sigure și nesigure

După ce dispozitivul a pornit cu succes și rulează un firmware cunoscut de încredere, tehnologia implementată Arm TrustZone pe SAM L11 acțio­nează pentru a menține o separare clară între software-ul securizat și posibilele pericole. Tehnologia Arm TrustZone utilizată de SAM L11 în programul procesorului Arm Cortex-M23 oferă un set de instrucțiuni sigure, care au grijă ca orice apelări de funcții efectuate prin programe nesigure, trimise în domeniul securizat, să poată fi verificate pentru probleme. Tehnologia Arm TrustZone permite crearea de domenii de securitate software, care restricționează accesul la memoria selectată, peri­ferice și I/O doar pentru software-ul de încredere, fără a compromite performanțele sistemului. Permițând colectarea și protejarea codului securi­zat, tehnologia Arm TrustZone simplifică sub­stanțial modul de evaluare a securității unui dispozitiv emdedded.
Pentru a diferenția și a izola programul securizat de codul nesecurizat, memoria de pe SAM L11 este partiționată în regiuni diferite de memorie, fiecare regiune fiind dotată cu siguranțe fizice pentru a rezista atacurilor software. Orice încercări de accesare a regiunilor marcate drept sigure de la un program nesigur sau o nepotrivire între programul care este executat și starea de securitate a sistemului, are ca rezultat o eroare, care oprește accesul și care poate declanșa o repornire de sistem. Această protecție este menținută chiar și în timpul depanării și subrutinelor de întrerupere.
De exemplu, implementarea tehnologiei Arm TrustZone menține două indicatoare de stivă, care separă execuția sigură de cea nesigură și care previn compromiterea datelor din stivă care ar putea fi încărcate într-o subrutină de întrerupere. În timpul depanării, programele sigure și cele vulnerabile sunt tratate diferit, folosind niveluri diferite de acces de depanare. Un dezvoltator care lucrează într-o secțiune care nu este sigură, nu poate modifica programul securizat sau accesa direct informațiile de depanare de pe aceasta. Astfel, se realizează o separare clară a responsabilităților, unde numai dezvoltatorii cu acreditări de securitate pot lucra pe programul protejat.
În mod obișnuit, un dezvoltator însărcinat cu dezvoltarea aplicațiilor securizate va oferi fișiere antet și rutine de bibliotecă, care permit programului nesecurizat să facă solicitări, cum ar fi criptarea unui pachet de rețea pentru a fi trimis pe internet. Aplicația securizată este apoi încărcată într-o regiune de memorie protejată. Atunci când un dezvoltator fără autorizație de securitate dezvoltă programul de rețea, va utiliza biblioteca și fișierele linker, care vor avea acces doar la nivelul de API (Application Programming Interface): programul securizat și datele sale vor fi o cutie neagră. Încer­cările de alterare/modificare a codului securizat pot fi forțate să eșueze la momentul de pornire, deoarece hash-ul codului nu se potrivește în timpul rulării. Acest lucru este posibil prin verificările efectuate în mod constant în procesul de pornire securizată oferit de SAM L11. De exemplu, manipu­larea pointerului pentru a face referire la o locație necorespunzătoare va genera o eroare.
Perifericele pot fi, de asemenea, numite ca fiind sigure sau nesigure, cu mențiunea că numai software-ul autorizat le poate accesa sau controla direct. Pentru perifericele care pot furniza servicii pentru ambele tipuri de regiuni, accesul la acestea este protejat într-un mod similar cu cel al apelurilor de funcții. Codul nesecurizat face o solicitare printr-un API furnizat de dezvoltatorul codului securizat. Acest lucru asigură că orice control direct al perifericului este menținut printr-un cod autentificat, care poate verifica dacă se încearcă o utilizare rău intenționată. De exemplu, codului nesigur i se poate permite să citească starea unui contor de temporizare, dar nu și să-l reseteze.
Perifericele externe și subsistemele pot face solici­tări către microcontroler numai dacă furni­zează o valoare hash care corespunde cu un certificat digi­tal, păstrat într-un spațiu de stocare a cheilor (integrat pe cip și securizat) împreună cu datele pe care le transmit. Acest lucru împiedică orice încercare a unui hacker de a utiliza un peri­feric compromis pentru a modifica funcționarea sistemului și, de asemenea, stă la baza siguranței producă­torilor că dispozitivul lor nu poate fi utilizat cu subsisteme contrafăcute. Chiar dacă atacatorul este capabil să examineze și să modifice 256 baiți de RAM destinați stocării cheilor de secu­ritate, SAM L11 conține mecanisme care vor reseta cheile și datele dacă detectează acest tip de activitate.

Rezultatul măsurilor de securitate interconectate pe SAM L11, care se extind de la protecția fizică a memoriei la tehnologia de separare Arm TrustZone, oferă OEM-urilor capacitatea de a construi o securitate holistică pentru dispozitivele embedded și de a se asigura că aplicațiile lor nu repre­zintă legătura slabă din rețeaua IoT.

Resurse adiționale:

¹⁾ codebase – colecție de coduri sursă necesară pentru a construi un anumit software (de sistem, de aplicație sau doar o componentă), în special pentru un dispozitiv care folosește pe scară largă biblioteci și aplicații software terțe.

²⁾ hash – În informatică, funcțiile hash sunt folosite pentru a accelera căutările în tabele, cum este cazul în bazele de date mari sau comparările de date. Valoarea unei funcții hash este denumită rezumat, valoare hash, cod hash, sumă hash sau doar hash.

Autor: Ramanuja Konreddy,
Inginer principal –  Marketing de produse în cadrul departamentului Microcontrolere pe 32-biți la Microchip

Microchip Technology   |   https://www.microchip.com